If sourcetype A only contains field_A and sourcetype B only contains field_B, create a new field called field_Z which is either field_A or field_B, depending on which is present in an event. Typically, you can join transactions with common fields like: … | transaction usernameīut when the username identifier is called different names (login, name, user, owner, and so on) in different data sources, you need to normalize the field names. You need to build transactions from multiple data sources that use different field names for the same identifier. This search retrieves only the events it needs to and is much more efficient. If all your events have the same IP value, this search should be: sourcetype=x ip=1.2.3.4 | transaction field=ip maxpause=15s Here we are retrieving all events of sourcetype=x, building up transactions, and then throwing away any that don’t have an ip=1.2.3.4. Consider this search: sourcetype=x | transaction field=ip maxpause=15s | search ip=1.2.3.4 No matter what search commands you use, it’s imperative for performance that you make the base search as specific as possible. If instead of an end condition, trade_id values are not reused within 10 minutes, the most viable solution is: … | transaction trade_id maxpause=10m | chart count by durationįinally, a brief word about performance. However, if trade_id values are reused but the last event of each trade is indicated by the text “END”, the only viable solution is: … | transaction trade_id endswith=END | chart count by duration … | stats range(_time) as duration by trade_id In many cases, there may be a unique identifier available, and leveraging stats can be a more efficient approach.įor example, to compute statistics on the duration of trades identified by the unique identifier trade_id, the following searches yield the same answer: … | transaction trade_id This is because search performance for stats is typically better than for the transaction command. However, it is important to note that if neither of these cases is applicable, it is generally recommended to use the stats command instead. When it is desirable to see the raw text of the events rather than an analysis on the constituent fields of the events.When unique field values (also known as identifiers) are not sufficient to discriminate between discrete transactions.The transaction command is most useful in two specific cases: Unlike stats, transact ions retain t he raw event text and field values from the original events, but they don’t com pute any statistics over the grouped events, other than the duration (the delta of the _time field betwe en the oldes t and newest events in the transaction) and the event count (the total number of events in the transaction). Like stats, the transaction command can group events based on common field values, but it can also use more complex constraints such as the total period of the transaction, delays between events within the transaction, and required beginning and ending events. Typically, the raw event text is discarded. You can only group events with stats if they have at least one common field value and if you have no othe r constraints. That speed, h owever, has some li mitations. It’s faster than transactions, especially in a distributed environment.
The rule of thumb: If you can use stats, use stats.
But when should you use transactions, and when should you use stats? The most common approach uses either the transaction or stats comm ands. Identify and Group Events into Transactions Introduction
0 kommentar(er)
