Datamodels have an explicit (and finite) set of fields already, so scripting something to find all your available fields and use FIELDALIAS to remove the {} wouldn't really accomplish anything for you anyway. What you'll really have to do is examine your datamodels (homegrown, CIM, or whatever) and determine which fields in your events represent the fields in the datamodel it belongs to. This may sound tedious, but it's the method Splunk uses for normalization of datamodels. ... View more

Do you want to find events like: fieldyoucareabout= otherfield1=value1 otherfield2=value2 Or instead: otherfield1=value1 otherfield2=value2 ... View more

If you want to compare the components of the strings prior to the comma, that should be fairly easy. | rex field=con_splunkUL "(?<con_splunkUL_pre>[^,]+)," | rex field=con_UL "(?<con_UL_pre>[^,]+)," | eval MonitoringStatus=if(con_splunkUL_pre=con_UL_pre, "Monitored", "Not Monitored") ... View more

I've seen vulnerability scans report an Apache Struts vulnerability against Splunk, but left didn't get an explanation as to how that finding was determined. ... View more

Oops, edited to correct that. 🙂 ... View more

Excellent. Please accept the answer so that this question doesn't still appear to be open. And again, I strongly suggest you use fields <list of fields you definitely want> instead of just removing _raw. But I obviously don't know your entire use case. ... View more

The event as you posted it is in syntax highlighted view, not raw , so the patterns you used in your props.conf are likely incorrect. Try this: TIME_PREFIX=time":\s*" The above is based on my assumption that your raw data actually looks more like "time": "<timestamp>" If that doesn't work please add the raw event, instead of the syntax highlighted representation. ... View more

MAX_TIMESTAMP_LOOKAHEAD is relative to the position determined by TIME_PREFIX , so the initial setting of 32 should not have been too low to be valid. MAX_TIMESTAMP_LOOKAHEAD = <integer> * Specifies how far (in characters) into an event Splunk should look for a timestamp. * This constraint to timestamp extraction is applied from the point of the TIME_PREFIX-set location. * For example, if TIME_PREFIX positions a location 11 characters into the event, and MAX_TIMESTAMP_LOOKAHEAD is set to 10, timestamp extraction will be constrained to characters 11 through 20. * If set to 0, or -1, the length constraint for timestamp recognition is effectively disabled. This can have negative performance implications which scale with the length of input lines (or with event size when LINE_BREAKER is redefined for event splitting). * Defaults to 150 (characters). ... View more

What do you see in the fields shown that indicates the start and end of the values that should be included in your sum? Based on your question it's unclear, as there appears to be no commonality between the rows /post/em/sec/w and /gt/ey/sec/d/3 (which is what I assume you meant instead of /gt/ey/sec/d, which doesn't exist). ... View more

As referenced by above comments, there is definitely a limit to the number of results returned by a base search. You should use a reporting function in your base search, unless you know the results will always be under the limit (and even then it's still best to do so). Sometimes it can be tricky to find a common report function that allows all your dependent panels to use the same base search, but you should definitely strive to do so. Unfortunately in this example the base search will contain all the logic: index=summary_price source=summary-price-quotation-view | stats count and the post-process search in the panel will be empty. ... View more

Not an answer, but a side comment: you don't need the leading | in the search string of the panel that uses the base search. ... View more

Try: index=palo_logs [| inputlookup servers.csv | stats values(src_ip) AS src_ip | eval search=mvjoin(src_ip, “ OR “)] Because the subsearch returns a field named search , the contents of that field will be dropped inline into your search string, yielding something like index=palo_logs <ip1> OR <ip2>... . It’s worth noting that this may yield an inefficient search, and you may want to try this to make it more efficient: index=palo_logs [| inputlookup servers.csv | eval src_ip=“TERM(“.src_ip.”) | stats values(src_ip) AS src_ip | eval search=mvjoin(src_ip, “ OR “)] This was written up on a phone, so it probably has a typo or two or more. ... View more

What iis your search string when you search individual addresses? If it doesn’t include src_ip=<ip> and instead is just index=palo_logs <ip1> OR <ip2> then it makes sense why my search didn’t work. If that’s the case I’ll post a different answer to handle that. ... View more

Run it exactly as I specified it in the previous comment, don’t add the index= portion. ... View more

What does this return: | inputlookup servers.csv | table src_ip ... View more

return only returns the first result. To see this in action try running the portion of your search within the square brackets by itself. Instead try index=palo_logs [| inputlookup servers.csv | table src_ip] The subsearch has a limit of 10k rows, which some work around by piping to format . You may not need that, but adding it for completeness. ... View more

The error indicating timeout while replicating search bundles is likely unrelated to the question asked previously. In your case a larger bundle size may just be taking longer than Splunk expects to replicate out to the search peers. This may have been recently triggered by the search bundle growing due to a new app or lookup, or even just network slowness. The bundles themselves are just tar files. You can copy one to a temporary directory and untar it to see which, if any, knowledge objects are unnecessarily large. Lookup files are a likely culprit. ... View more

@acharlieh makes a very good point. Considering that point, to configure this to be the timestamp used for the event at indextime, your props.conf may look like: [<sourcetype>] TIME_PREFIX = \[ TIME_FORMAT = %d/%b/%Y:%H:%M:%S %z The time format above includes the GMT offset ( %z ), so if your results at search time appear to be off by exactly 5 hours that will explain why. I suggest leaving this in place, if possible, and setting your timezone in your user account settings to display events in your local timezone. Of course, you can't do this if you have other events indexed in the local timezone already. ... View more

Assuming your date string is the only thing that will ever be between square brackets, this seems like it should work for you: | rex "\[(?<start_date>[^ ]+)" | rex field=start_date mode=sed "s/([^:]+):(.+)/\1 \2/" To see this in action with a run anywhere example: | makeresults | eval _raw="00.111.222.1 va10n40596.abcdefgt.com - - 443 [02/Jan/2018:18:25:41 -0500]" | rex "\[(?<start_date>[^ ]+)" | rex field=start_date mode=sed "s/([^:]+):(.+)/\1 \2/" ... View more

Can you include the output of index="A" | script python extractname | table * , and the output of index="B" ? ... View more