That might mean that you have an automatic lookup configured but either the lookup table doesn't exist or you don't have access to it. Anything under Settings -> Lookups -> Automatic lookups (might want to check under the "All" app context)? I believe those are configured in props on the back end, so you should be able to run a btool too splunk btool props list --debug | grep fgt_traffic ... View more

Well, if the format is consistent, then something like this should work your base search | rex "GET\s+(?<cool_field>\S+)" Essentially find in the raw data where there is GET followed by a space (or spaces), then capture everything that is not a space after that and store it in a new field called "cool_field" If the events are not in a consistent enough format where that would work, then maybe include some of the events where it doesn't work too and I'm sure we can adjust ... View more

My 2 cents... It might help to take a step back to be sure you understand how search head clustering works at a high-level. The deployer is not part of the cluster. It is used to push config to the cluster members. With that in mind, the only apps/config on the deployer that get pushed to cluster members are under etc/shcluster/apps (and users). That config gets copied to etc/apps on the search head member. Config changes outside of that directory structure on the deployer won't get pushed to the cluster. So for example, modifying props.conf under etc/system/local on the deployer will only affect the deployer itself. The cluster members won't know anything about those. Also, it's important to note that apps under shcluster/apps can include default and local settings. When the config is pushed to cluster members, the precedence rules are applied at the deployer level and the resulting config is pushed to the default directory on the cluster members. If changes are then made in splunk web or via rest etc on a search head members, those changes are stored under that app's local directory which gets replicated. That can make troubleshooting a bit tricky, so it's important to keep in mind. My recommendation would be to store your config various apps, yes. We like to keep each app pretty narrow in its scope to give us more flexibility when modifying/testing changes. For example, we have an app for just the outputs config. Another for the license master. Maybe one for common search head config. Etc. And then of course, you'll have the "actual" apps you'll be pushing to the cluster as well. Another piece of advice might be to have a sort of staging server. Some apps require further set up after install. And others just various config - maybe disabling searches you don't need, or modifying accelerated data models, etc. It's best to get all of that done on a standalone server. Once it's set up and functioning the way you want, copy it to shcluster/apps on the deployer to push out. And some links that might be helpful http://docs.splunk.com/Documentation/Splunk/6.3.3/DistSearch/PropagateSHCconfigurationchanges http://docs.splunk.com/Documentation/Splunk/latest/Indexer/Configuresearchheadwithserverconf ... View more

So in your example above, would this be 1 of the 2 times it switches from 1 to 3? 2016-03-09 01:47:45 id=1234 event=1 2016-03-09 01:47:46 id=1234 event=3 If so, maybe something like this [your base search] | sort id _time | autoregress event as prevEvent p=1 | autoregress _time as prevTime p=1 | delta _time as delta_seconds p=1 | where event=3 AND prevEvent=1 | table id event _time prevTime prevEvent | convert ctime(prevTime) So sort in ascending time order (and group id's together in case there are multiple). Then for each event, use autoregress to store the event and time of the previous event. And also use delta to give the difference (in seconds) between the current event and the last event. Then filter for any rows where event is 3 and the previous event was 1. And table out the info. ... View more

I feel like there's probably a better way to accomplish what you're trying to get after, but it's late and my brain is shutting down. But to answer your question maybe, I think this should work. | timechart span=h count | stats sum(count) as total dc(_time) as numRows | eval percent=total/numRows*2*100 that should get you the distinct count of values for _time, which after the timechart should be one for each row. ... View more