Do you want this to capture firstName only if subscriberFirstName also exists? It seemed to me you wanted to capture firstName always, and subscriberFirstName when available. ... View more

Oops, edited to correct 🙂 ... View more

source="/tmp/getsysgfiles/server_cpu.g" | eval _time=strptime(Time,"%Y/%m/%d/%H/%M") | addinfo | where _time>=info_min_time and _time<info_max_time | timechart sum(two) span=1m I removed your rex command, as it didn't seem to be extracting a field anyway. But, really, you should work at getting the timestamp correct at index time. Is there a reason the timestamp you want to use here differs from the event time Splunk has for the event? ... View more

You can do this somewhat with streamstats , but things get tricky because you are thinking in chronological order, and Splunk process events in reverse-chronological order by default. You can get around this sometimes with reverse , but using that for large datasets is a bad idea. To show this in action: | makeresults | append [ |makeresults | eval _time=180, _raw="event4"] | append [| makeresults | eval _time=193, _raw="event3"] | append [| makeresults | eval _time=195, _raw="event2"] | append [| makeresults | eval _time=200, _raw="event1"] | reverse | streamstats current=false window=1 last(_time) AS last_time | eval time_diff=last_time-_time | search time_diff>=5 And your search may look like: 1.1.1.1 11 2.2.2.2 22 ciscoasafw index=firewall | reverse | streamstats current=false window=1 last(_time) AS last_time | eval time_diff=last_time-_time | search time_diff>=5 ... View more

Your regexes get gross in rex , because of slashies, but they are doable. I'm not sure what you mean by "capture both together but in different fields", but this will capture both (when they exist), and put both values in one field after rex , in SPL: | makeresults | eval _raw="{\"userDetails\":{\"uuid\": \"Lots of different values and fields\" ,\"offlineString\":\"firstName:NAME|lastName:NAME|OTHER FIELDS\",\"much more info\",\\\"subscriberFirstName\\\":\\\"NAME\\\",\\\"subscriberLastName\\\":\\\"NAME\\\",\"tons more data\"}" | rex "firstName:(?<firstName>[^|]+)" | rex "subscriberFirstName\\\\\":\\\\\"(?<subscriberFirstName>[^\\\]+)" | eval firstNames=mvappend(firstName, subscriberFirstName) ... View more

Actually I think you can do this. The previous answer's explanation is valid, but using it you can do this: props.conf: [<sourcetype>] SHOULD_LINEMERGE = false REPORT-embedded_message = embedded_message KV_MODE = json props.conf: [embedded_message] SOURCE_KEY = message REGEX = "(?<_KEY_1>[^:]+)":\s*"(?<_VAL_1>.*?)" In action: ... View more

My seach above doesn't rely on any of the Palo Alto TA, but the regex I included was one from that TA. If you aren't getting results from that search it tells me you probably don't have any CONFIG lines in your events. Can you search: index=pan_logs | rex "(?<config>CONFIG)" | search config=* This will tell you if you have any events at all with the literal string CONFIG . If you don't, those events aren't making it to Splunk, so the Palo Alto TA has nothing to work with. ... View more

Change your search string in the script to search source=source1 field1=* earliest=-1d@d latest=@d . The REST API, which the SDK uses, does not add the implied search command to the front of your search strings like the UI does. Also, add | fields <field1> <field2> . This should ensure that Splunk grabs the fields you care about, even if running in fast mode (which may be what is happening here). ... View more

You can not. You can make changes to [default] , but it will set the defaults for all indexes, not just the ones you potentially want to match. These defaults can obviously be overridden for individual indexes. ... View more

Linebreaking should be configured like this: [weblogic:audit] LINE_BREAKER = ([\n\r]+)#### Audit Record Begin SHOULD_LINEMERGE = false Use LINE_BREAKER properly instead of relying on SHOULD_LINEMERGE . From props.conf doc: * NOTE: You get a significant boost to processing speed when you use LINE_BREAKER to delimit multi-line events (as opposed to using SHOULD_LINEMERGE to reassemble individual lines into multi-line events). * When using LINE_BREAKER to delimit events, SHOULD_LINEMERGE should be set to false, to ensure no further combination of delimited events occurs. * Using LINE_BREAKER to delimit events is discussed in more detail in the web documentation at the following url: http://docs.splunk.com/Documentation/Splunk/latest/Data/Configureeventlinebreaking ... View more

Which version of Splunk are you running on each instance? The SSL configurations changed between versions. ... View more

The reason splunk isn't automatically extracting this out is (probably) because the message field is JSON embedded in other JSON, as opposed to a sub-structure of the same JSON. I'm willing to bet the message field contains escaped quotes if you view the raw event. Here's a run-anywhere example of what I mean: | makeresults | eval _raw="{\"message\": \"{\\\"level\\\": \\\"0\\\"}\"}" | spath Gives a sample _raw of: {"message": "{\"level\": \"0\"}"} And a message value of: {"level": "0"} Which you could run spath against and get the results you want: | makeresults | eval _raw="{\"message\": \"{\\\"level\\\": \\\"0\\\"}\"}" | spath | spath input=message If the message field was part of the actual JSON structure (instead of JSON embedded in other JSON), _raw would look more like this: {"message": {"level": "0"}} Which would parse properly into message.level . The run-anywhere search to show this in action is: | makeresults | eval _raw="{\"message\": {\"level\": \"0\"}}" | spath So how do you make this "just work" without having to run a separate spath each time you search? I don't think there is a way. Even if you knew that you only cared about the message field and nothing else and you used SEDCMD to rewrite _raw when you index the data, it would still contain escaped quotes that are going to prevent JSON parsing from being successful. ... View more

Edited my answer. My initial search caused there to always be events, but DURATION was absent, which is why my search worked when testing but not for you. I've updated it to work even when no events are present. ... View more

No, this is not something you can do. ... View more

The Palo Alto TA separates the different types of logs into different sourcetypes ( pan:config , pan:traffic , etc). It does this by way of a TRANSFORM defined for the pan:log sourcetype. It sounds like you have your logs coming in as sourcetype AAA , and your indexer is changing this via a TRANSFORM to pan:log . The issue with this is the Palo Alto TA TRANSFORMS will never run against your data unless they first hit the indexer with the pan:log sourcetype. It will not work for them to come in initially as something other than pan:log (or pan_log , as you've seen referenced as well). And this does require the TA to be in place on the indexer (or heavy forwarder, if that's where the logs go through one before reaching the indexer). My suggestion is to find a way to get those logs sourcetyped correctly as pan:log when they are first brought in to Splunk. ... View more

Your search didn’t paste correctly. Please use the code button (101010) to make it format properly. ... View more

Converted to an answer, since it helped you track down the root cause. I don’t believe there is a way to enforce search terms that would work with tstats. I think search terms are generally advised against, anyway. The advice is to do all permissions by index, splitting into a new index if necessary to accomplish this. ... View more

It's also unclear from your posted data what the values of each field are in the event. Is the Business Name ABC foods 6697 VALE TAP AND PAY 0000 ? ... View more

Does your lookup table have the numbers at the front of the line? It's displayed with two leading numbers, which seems to indicate the 2nd number per line is actually in your file. ... View more

The docs suggest this would use info_min_time first, if present (which it sounds like it would be), and is true by default anyway: addtime Syntax: addtime=<bool> Description: Use this option to specify whether to prefix a time field on to each event. Some commands return results that do not have a _raw field, such as the stats, chart, timechart commands. If you specify addtime=false, the Splunk software uses its generic date detection against fields in whatever order they happen to be in the summary rows. If you specify addtime=true, the Splunk software uses the search time range info_min_time. This time range is added by the sistats) command or _time. Splunk software adds the time field based on the first field that it finds: info_min_time, _time, or now(). Default: true ... View more