In case you have access to _internal index, you can use following search . You add filter as per your requirement. index=_internal source=*scheduler* | stats count by savedsearch_name, status ... View more

It worked!!! ... View more

The problem with that particular field is it is not returning any values once I select it to the search query, but it is assigned with few values from the logs. I am not caring whether it is in selected fields or Interesting fields set. Is there any way I can set the extraction properly so that I can get the results once I select it? ... View more

Hey @rangineniarunkumar, Were you able to look through this documentation yet? http://docs.splunk.com/Documentation/AddOns/released/JMX/Releasenotes I saw this similar app as well in case that works while an expert is able to answer the original question. https://splunkbase.splunk.com/app/668/ ... View more

rangineniarunkumar, Are you troubleshooting the migrated data to the new instance? or the new data flowing into the new instance? I would go through the instance and see what settings the old instance is running. splunkdata system/local etc/apps etc/deployment-apps (if it is all one single system does everything?) If this instance configurations managed from a deployment-server, then you can point the new instance to deployment-server and that will take care of some of the configurations. If this also a search head, then check all your dashboards etc. to see if any hard coded urls with your old hostname etc. ... View more

We have a cluster of 3 Search Heads. Does the same still apply. Do we load the file to one of the 3 and index from there? ... View more

This happens when you do not tell splunk everything about your timestamps and you allow it to try to figure it out automatically. You must, at a minimum, use TIME_FORMAT (so you are on the right track). You need to deploy this to your indexers and restart all splunk instances there. Even so, only events that are indexed after the change will be effected: old broken events will stay broken. ... View more

I have newly added an script and inputs.conf file is already present but modified it !!!!!!!!!! ... View more

verify your inputs you are missing // [WinEventLog://HardwareEvents] disabled = 0 start_from = oldest current_only = 0 checkpointInterval = 5 index=xyz [WinEventLog://HardwareEvents] disabled = 0 start_from = oldest current_only = 0 checkpointInterval = 5 index=xyz here is a screenshot after applying the windows setup monitoring as above and verifying data is indexed: ... View more

I tried to deploy the splunk_TA_Windows app from deployment server to the Host with splunk forwarder after the changes in inputs.conf, where I am able to see events indexed from "[WinEventLog://Security]", "[WinEventLog://Application]"and "[WinEventLog://System]" but not from "setup" and "HardwareEvents". Do we need to make any other changes in Splunk_TA_windows app on Deployment server in order to get the missing logs to be indexed on splunk. I did not find any script related to"HardwareEvents" or "Setup" at Splunk_TA_windows/samples where as we have for application,security and system Can anyone help me with this??. ... View more

I would handle this with ACL to block his connection attempts entirely but if firewalls cannot be used, then you can just /dev/null it like this on the Splunk Indexers: In props.conf: [host:Invader.IP.Address.Here] TRANSFORMS-setnull = setnull In transforms.conf: [setnull] REGEX = . DEST_KEY = queue FORMAT = nullQueue See more here: http://docs.splunk.com/Documentation/Splunk/6.6.0/Forwarding/Routeandfilterdatad ... View more

If _indextime is earlier than _time , then one of the following is true: The timestamping entity (the process writing to the file on the forwarder) is writing the wrong time. This is usually because the host OS has the wrong time. This is usually because the admin of that device neglected to setup NTP . The timestamping entity is using a proper TZ but is not writing this TZ in the timestamp. This can be fixed by using the TZ= feature and deploying this to the forwarder (if post 6.0) or the Indexers (if pre-6.0). The timestamping entity is using the wrong TZ and is writing this TZ in the timestamp. In the short-term, this can be fixed using the TZ_ALIAS= feature, but the proper fix is to correct the timestamping entity's insanity. You have not correctly told Splunk where to find the timestamp (DO NOT EVER allow it to automatically timestamp: tell it exactly where and in what format the timestamp is) so it is mistaking non-timestamp data as a timestamp, misinterpreting the timestamp, or giving up on finding it and timestamping it with the previous event's timestamp or the current Indexer time. ON RARE OCCASION the indexer has the wrong time (see the first point about NTP ) and so _indextime is wrong. Many people get tired of playing whack-a-mole on this problem and elect to let the Indexer's timestamp such that _inedextime is always used for _time by using DATETIME_CONFIG = CURRENT OR to let the forwarder do it by using DATETIME_CONFIG = NONE : http://docs.splunk.com/Documentation/Splunk/6.5.2/Data/Configuretimestamprecognition I personally would not take the last approach but work to fix it PROPERLY, but sometimes "close enough is good enough". ... View more

This is a very open ended question, you could start with Troubleshoot the input process and the monitoring console overview . Either custom alerts or applications like Meta Woot! could assist with tracking which index received data and which point in time... ... View more