Similar to how the *nix app prefaces all of it's searches with 'index=os', you can do the same thing with your app. If you are on a *nix instance, take a look at $SPLUNK_HOME/etc/apps/unix/default/data/ui/views/flashtimeline.xml and you will see the following config for the search bar starting on line 11 - <module name="SearchBar" layoutPanel="splSearchControls-inline"> <param name="q">index=os</param> <param name="useAssistant">true</param> <param name="useTypeahead">true</param> <param name="useOwnSubmitButton">False</param> ... You can modify your own app's flashtimeline.xml view in the same way ... View more

Yes that should be fine, The app will attempt to fall back to the 32 bit version if the 64 bit version fails to run, but assuming your box is setup to run the 64 bit version ok then there should be no issues ... View more

batch inputs work much the same way as monitor inputs, so the troubleshooting instructions here will enable you to see what Splunk is doing when it reads these files. Set up the DEBUG logging as instructed, and add it in for the archiveProcessor too, that's the one that will open up your files. You'll see the resulting logs in splunkd.log Also, be aware that due to the unknown 'real' size of a compressed file, Splunk will only process one file at a time, so it may actually be working, just a lot slower than you would expect. ... View more

Your second suspicion is correct, the event will be indexed with a different timestamp - the one identifed in the events preceding the 'problem' timestamp. If you are actually indexing historical data at the same time as current data, then you should ensure that let Splunk know this by using the settings identified in the event - MAX_DIFF_SECS_AGO or MAX_DIFF_SECS_HENCE in props.conf ... View more

This is possible and every EAI endpoint has a sub /acl endpoint on which to POST. You should find some good information in the 'Object Sharing and ACL presentation/mutations' section below, if it's still not clear to you how to do it after going through that info, please reply and let us know exactly what you're running and what kind of result you're getting. Object Sharing and ACL presentation/mutations All endpoints that list user objects should support object sharing and access control list (ACL) presentation and mutation. ACL Presentation An ACL consists of the following fields: modifiable Required. A boolean flag indicating whether the ACL is modifiable or not. owner Required. Username of the owner of this object, if an object is not owned by a user should be set to 'nobody' perms Required. A dictionary that maps action to a list of roles which can perform that action sharing The level at which this object is shared, can be one of: system, app, user, global Example: <s:key name="acl"> <s:dict> <s:key name="modifiable">false</s:key> <s:key name="owner">admin</s:key> <s:key name="sharing">user</s:key> <s:key name="perms"> <s:dict> <s:key name="read"><s:list><s:item>admin</s:item></s:list></s:key> <s:key name="write"><s:list><s:item>admin</s:item></s:list></s:key> </s:dict> </s:key> <s:dict/> </s:key> ACL Modification A request to modify the ACL of an object should POST on the 'acl' custom action of an object (url: ...endpoint/entity-name/acl). The entire ACL should be provided rather than a diff. The following parameters should be provided: perms.<action> A comma delimited list of roles which can perform the given action owner The username of the new owner of the object sharing The level at which this object is shared, can be one of: system, app, user, global ... View more

You can find both guidance and searches to investigate your indexed data volume here. There are a number of searches on that page that will break down your indexed volume by host, source, sourcetype and index over time. By editing the search, you can look at weekly, daily or hourly totals, depending on your needs. As for filtering events to keep your volumes down, that is all explained in our documentation here. This is resource intensive and will impact the speed at which your Splunk instance can index data, so if possible I would implement any filtering at the app level, rather than relying on splunk to do it ... View more

Every time Splunk adds up it indexing total for the previous 24 hours, it will compare that total with the peak it has previously recorded. If the new figure is higher, the existing record is replaced. If not, the record remains the same. It should never be reset, unless the indexes are cleaned. ... View more

Changing the system time on your servers shouldn't affect your scheduled searches or your data in any way. As long as you are extracting the timestamp from the events, and indexing them according to that time, Splunk should continue to work as normal and use those timestamps in the index. Likewise, assuming that your are one of the standard scheduling methods for your scheduled searches - every hour, every 4 hours, etc - or a simple cron schedule, then they should also continue to work as normal. The only concerns I would have, is if you have any timezone offsets applied to your data, or if you were using the current system time as your event timestamp - then you may see some adverse effects after you make your update. In fact, you may have to apply some timezone offsets to your data so that the events and timelines are displayed correctly in the UI ... View more

ftk is correct, there's no way to specify the current_only flag with the CLI. For a large scale implementation, deployment server is definitely the way you should be heading. With that in place, all you would need to do at installation time is just a vanilla install, and then the first time you start it up run the command to enable the deployment client. It will then go off and grab all the configs you need - splunk set deploy-poll <IP address or hostname>:<port> In the next major version we will be adding a flag to the CLI MSI install that will allow you to configure the deployment feature at install time, but for now it will have to be an extra step. ... View more