I have found some great ways with just stats but what you just explained I think will actually achieve what I need, and potentially to even greater effect. I have been tryouts Ng to understand how to get rid of transaction for about 4 years. Here's a couple of examples of using different sideways thinking to get what you want instead of transaction. Transaction seems to meet a need simply and easily, but it's a resource hog like no other verb in Splunk. In real life, there are a lot of ways to construct a search. If you need to pull data from additional kinds of records, then you can use either streamstats or eventstats to copy the desired info and then discard the records you don't need. ( This same model structure is used when trying to report on user activity when a load balancer is repeatedly assigning the same IP to different users.) Get all the relevant events, create a synthetic key if you don't have a real one, sort into _time or reverse _time order, then use streamstats by key, with an optional time_window if you want to limit the overall duration between the open and close event types. Streamstats is the first thing you should think of when matching event types (open and close, for example) by _time and one or more keys. (Three different kinds of events where the keys on one pair were different from the keys on a different pair, In that case, the native complexity of transaction's internal methods also avoided SPL complexity, so I left that code in place.) In four years of being in the Splunk Trust, I've only seen ONE - exactly ONE - case where transaction was the best performer, and that was a multiple key situation, iirc. Streamstats with the time_window keyword can handle the desired span and maxpause utility. For that situation you use a combination of stats and streamstats.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |