Then doing a join to see if the transactions part 2 is found in the last 60 seconds, thus giving me sufficient overlap to identify if there is a completed transaction.
I thought what I was doing with that search was finding part 1 of the transaction between 15 and 60 seconds out from the current time. Wondering if you could assist again, the search is returning false alerts.
Also test this to make sure, but I'm confident removing now will be fine (if it works now, it's accidental and due to having the word "now" in the events, but if you don't need it, don't rely on it. Since you can look for those at the current time, you can just leave "now" out entirely. That will search for only events that have the literal word "now" in them. You shouldn't have a problem out of making the first be -60s to -15s and the second being -60s to now - you can use the same start time because the transaction will fix that, it's the ending ones that matter.Īlso, probably just a typo but you have "now" in your subsearch. I'm fairly certain, anyway - test and you can be sure one way or the other. As you have it configured now it will only connect the dots between events that have a start in the first half of a minute and an end in the last half of the minute, so if it starts at twelve seconds after and finishes nineteen seconds after, you'll miss it. This all depends on your actual use case and expectations, so I won't tell you that you don't need realtime. At that point, being a minute or two behind on detection doesn't hurt your responsiveness, and makes it much easier omit false positives due to timing. Getting alerted in realtime is awesome, but pointless if it takes you a couple of minutes to respond to the alert. When dealing with this stuff, think about how quickly you can realistically action a problem. Realtime searches insert themselves as far up the pipeline as possible (They're actually injected in the indexing pipeline before most of the parsing) but there's still a non-zero delta between log write > visible search result. There is a delay between log write > forwarder read > forwarder send > indexer receive > indexer write. Worth noting: When trying to deal with near-realtime, you're going to start bumping into the potential of false positives caused by the fact that it takes time for data to end up in Splunk. This gives you a means to say "Show me open transactions which started more than X seconds ago" which sounds like what you're looking for. filter for items which have not ended, and which have existed for more than 10 seconds.generate a field to show the time difference between when the search is run, and the most recent timestamp of the item.Items which are ended will have a sum(end) > 0 This gives you an easy way to filter for open items. Do a stats for each TAG198, grabbing the earliest and latest timestamps for events, and a sum of the start/end flags.Create fields to indicate if the event is a starting or ending event.| search ended=0 AND time_since_last_seen>10 | eval time_since_last_seen=now()-last_seen | stats earliest(_time) as _time latest(_time) as last_seen sum(start) as started sum(end) as ended by TAG198 | eval start=if(searchmatch("Submitted order"), 1, 0), end=if(searchmatch("Murex - Received ExecutionReport"), 1, 0) Try a non-transaction approach: sourcetype="enable-integration" ("Submitted order" OR "Murex - Received ExecutionReport")
0 kommentar(er)
