I have a particularly challenging log format and would appreciate any inputs on how to tackle this problem. Problem Looking for a feasible props.conf setup that will correctly index the log below Example (blank lines only added for readability):   SINGLE_LINE_LOG_EVENT SINGLE_LINE_LOG_EVENT OTHER_SINGLE_LINE_LOG_EVENT Tue 06 Jun 10:00:00 UTC 2023 ANOTHER_SINGLE_LINE_LOG_EVENT Tue 06 Jun 10:00:01 UTC 2023 LARGE_MULTILINE_EVENT   The first three lines are all single events and should be parsed accordingly. But they have no timestamp The fourth and fifth line together form a single event Lines 6 and 7 also form a single event, but the event from line 7 is a multiline event that shall be parsed as a single event I am prepared to make the sacrifice that the lines without timestamp get assigned the CURRENT timestamp, if there is no other solution for this. What I have already tried I tried using the following (the Regex looks for the timestamp)   MUST_NOT_BREAK_AFTER = .{3}\s.{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\sUTC\s\d{4} MUST_BREAK_AFTER = .{3}\s.{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\sUTC\s\d{4}    As well as this (I tried various combinations of this, with different capture groups. Note that the file in question only has newlines and no carriage returns, hence no '\r')   SHOULD_LINEMERGE = false LINE_BREAKER = ([\n].{3}\s.{3}\s\d{2}\s\d{2}:\d{2}:\d{2}\sUCT\s\d{4})     ... View more

We are using a clustered SH setup. I have a dashboard that lists all triggered alerts. When a user clicks on one of the list items, I would like to use the sid as a token to use as argument for loadjob in another dashboard. The query is as simple as:     | loadjob <long-sid>     However currently when a row is clicked, the result is always "Search did not return any events. " I have configurered the tokens correctly and permissions also do not seem to be the issue. If I click the "open in search" button at the bottom of the dash I get the results of "| loadjob <sid>" as expected"   ... View more

I have a scheduled savedsearch that may return a result such as this _time, host, _raw 2023-01-01, host A, <some message> 2023-01-02, host A, <some message> 2023-01-03, host A, <some message> In this example, the content of <some message> causes an alert to fire, which is what I expect. Now, assume that a new event occurs and the next scheduled search returns this (changes in bold): 2023-01-01, host A, <some message> 2023-01-02, host A, <some message> 2023-01-03, host A, <some message> 2023-01-04, host A, <some message> 2023-01-05, host A, <some message> Problem: The next scheduled search will return the entire list (5 events) and thus trigger an alert containing these 5 events. However, 3 of these events were contained in a previous alert and are thus superfluous. Desired outcome: The new alert should only be triggered based on the two "new" events (in bold) What I have tried: Set trigger type to "for each event" and suppress for fields _time and host because I would assume that the combination of _time and host will uniquely identify the event to suppress I also tried to learn about dynamic input lookups, but the documentation seems to be lost / unavailable (http://wiki.splunk.com/Dynamically_Editing_Lookup_Tables) ... View more

Dear all, I have the use case that my splunk universal forwarder does not continuously monitor my logs. Because of this nature, I am using batch mode to have the files deleted after ingestion. Now, I occasionally receive log files which I have already received at an earlier point in time. Problem is: The features crcSalt, initCrcLength etc. are only available in monitor mode. This means that I am not able to benefit from splunks features to prevent duplicate ingestion of the same data. Any help on a solution for this is greatly appreciated. ... View more