I think you want to keep each line as a separate event. At reporting time you may want to group them logically (via stats or other search commands). Have you tried implementing the above configurations to see what they get you? ... View more

Please format your sample data using the code button (shown as 101010). My post assumed there are tabs, but others believe that to be incorrect. It would be easier if it was definitively shown in your post. ... View more

This will parse into the fields you've mentioned (assuming key=value), but does nothing to make them CIM compliant: transforms.conf: [kasperskycefcomponents] REGEX = ^CEF:(?<cef_cefVersion>[^|]+)\|(?<cef_vendor>[^|]+)\|(?<cef_product>[^|]+)\|(?<cef_version>[^|]+)\|(?<cef_signature>[^|]+)\|(?<cef_name>[^|]+)\|(?<cef_severity>[^|]+)\|(?<ceffields>.*)$ [kasperskyceffields] SOURCE_KEY = ceffields REGEX = (\t|^)(?<_KEY_1>[^=]+)=(?<_VAL_1>[^\t]+)(\t|$) props.conf: [<sourcetype name>] SHOULD_LINEMERGE = false KV_MODE = none REPORT-kasperskycef = kasperskycefcomponents,kasperskyceffields There are better ways to do this if you know that you care about specific fields, but the above is a general solution to the CEF you posted. If I was incorrect about there being tabs between key=value pairs, transforms.conf would look like this instead: [kasperskycefcomponents] REGEX = ^CEF:(?<cef_cefVersion>[^|]+)\|(?<cef_vendor>[^|]+)\|(?<cef_product>[^|]+)\|(?<cef_version>[^|]+)\|(?<cef_signature>[^|]+)\|(?<cef_name>[^|]+)\|(?<cef_severity>[^|]+)\|(?<ceffields>.*)$ [kasperskyceffields] SOURCE_KEY = ceffields REGEX = (?<_KEY_1>[^ =]+)=(?<_VAL_1>[^=]+)( |$) ... View more

Can you just have your search filter those events before returning them? remove Instead of * Streamstats doesn't remove anything from the search pipeline, it adds to the existing events, so it seems like an inefficient method to accomplish what you're trying. ... View more

You can use streamstats for that: query | streamstats time_window=1h count time_window Syntax: time_window=<span-length> Description: Specifies the window size for the streamstats calculations, based on time. The time_window argument is limited by range of values in the _time field in the events. To use the time_window argument, the events must be sorted in either ascending or descending time order. You can use the window argument with the time_window argument to specify the maximum number of events in a window. For the <span-length>, to specify five minutes, use time_window=5m. To specify 2 days, use time_window=2d. Default: None. However, the value of the max_stream_window attribute in the limits.conf file applies. The default value is 10000 events. Note: this may not be a very efficient search, depending on how much data you have. You should probably consider using stats on a smaller time period bucket (perhaps 1min) before piping the results into streamstats , so that you don't run into performance or limits issues. streamstats also retains the raw event and existing extracted fields, so including stats before it would limit that to only fields you actually care about. query | bin span=1min _time | stats count BY _time | streamstats time_window=1h sum(count) AS count ... View more

Did you run the search in verbose mode? tone isn't one of the fields my regexes made available, so I wonder if your sourcetype is making use of KV_MODE=auto to get that one. ... View more

What I'm asking is if they are multiline events, and if so, could you group the lines into how you would like them to exist within each event. I'm not sure your specific grouping needs will be easily accomplished in Splunk. The ability to group events relies on a single definition of when to break into a new event. It may be possible with some regex, but it isn't the typical use case. ... View more

Your search references $field_db_name$ , which doesn't appear to be set in any inputs. Is this a typo, or is it intended to be set by an input that isn't actually present? ... View more

Glad to hear it. Please accept the answer below to mark this question as closed, and you may also want to upvote the original solution, considering it contained the actual solution. ... View more

Can you include some of the log lines that aren't being parsed as you want? ... View more

This seems to be a duplicate. ... View more

You can use some trickery to accomplish what you're looking for. Try having your checkbox set a value that is essentially a "no-op" in your search. For example, if your panel runs a typical indexed search like index=main sourcetype=firewall src=$src$ dest=$dest$ , you could have your checkbox set its value to the implied search command. The search would then look like this: $checkbox$ index=main sourcetype=firewall src=$src$ dest=$dest$ . When your checkbox is selected the $checkbox$ token will get replaced with the search command and the search will kick off. The key to having the search not running in the background is to make sure that the query contains a token that isn't defined until your checkbox is selected. ... View more

Try something like this: <your base search> [| makeresults | addinfo | eval latest=now() | eval today_7_am=relative_time(latest, "@d+7h") | eval yesterday_7_am=relative_time(latest, "-1d@d+7h") | eval earliest=if(today_7_am<latest, today_7_am, yesterday_7_am) | table earliest] That does a simple comparison of your calculated earliest times to determine which was actually in the past, and chooses that one. ... View more

This may only be a partial answer, but try: <your base search> | rex field=tmp "(?<json>\{.+)" | spath input=json Based on previous answers post. ... View more

The fields index, host, source, and sourcetype are the only fields that it is appropriate to have your input define. This is true no matter the type of input (modular, scripted, monitor, etc). The other default indexed fields (_time, punct) are calculated by Splunk at index time. If you want other indexed fields, you would have to add the configuration to Splunk to determine the values of these fields at index time. However, you almost certainly don't need to do this, and should instead make use of Splunk's search-time capabilities to parse your data. ... View more

It's important to note that in @somesonie2's response he used timechart instead of stats in the append search. The search posted in the original question used stats , which would definitely drop _time from the results, preventing you from using timechart further down the search. ... View more

Thanks for posting your answer, so others can see how you accomplished this. You should also accept the answer, so the question looks closed to others. ... View more

I would add an | eval insavedsearch="true" to your scheduled search. You control the search that's executed when the scheduled time comes, so why not make use of that control? If you have a need for the same search, minus that eval to be available in an ad-hoc-able savedsearch, consider using a macro for the common portions, and add the eval just to the scheduled version. ... View more

To get the info for the serach that's running, you may try using sid instead of time . | addinfo will give you the sid in the field info_sid . Edit: it looks like your original question already states this. Reading comprehension fail. 🙂 ... View more

Your disabled configuration lines appear to have a typo. They should be disabled = 0 (or false), not disable . You can verify your configuration by running splunk btool inputs list --debug and looking for the ones you attempted to enable to see if they still show disabled = 1 (or true). ... View more