![]() 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. "searchtext" source="mylog.log" | transaction maxpause=1s a, b, c, d | search value=1 value=2 eventcount=2 | where mvcount(field)=1 | where b!=0 | eval lookupfield=logfield | lookup my_lookup_table lookupfield | stats count by _time, field1, field2, field3, field4, field5, field6, lookuptablefield, field7, field8 | fields - countĪlternatively, if the lookuptablefield is being treated as a multivalue field, you can use mvexpand on the lookuptablefield, then use dedup on all of your other fields to get down to what you need: "searchtext" source="mylog.Identify and Group Events into Transactions Introduction You can optionally use table after stats if you need to for some reason. I would try using stats count and then use fields to get rid of the count field. I can't see your imgur link because my company blocks but I'll offer up some suggestions. Hopefully I'm understanding your question correctly. Maybe I am just using the table and dedup commands out of order? Or is there another function that would do a better job at this? I'm kind of stuck on needing the table command because I want the fields to be in a specific order. "searchtext" source="mylog.log" | transaction maxpause=1s a, b, c, d | search value=1 value=2 eventcount=2 | where mvcount(field)=1 | where b!=0 | eval lookupfield=logfield | lookup my_lookup_table lookupfield | table _time, field1, field2, field3, field4, field5, field6, lookuptablefield, field7, field8 Here is a basic representation of what my search looks like: So it should actually be something like this: Since multiple fields can roll up and have the same exact description, I'd like the table to only show it once rather than multiple times since that makes it more confusing. What I am trying to point out is it shows the same "description" multiple times because there is more than one entry in the lookup table that corresponds with the field value that I put in my lookup table (this is expected because the field I am trying to display is a "rollup" general description that multiple things can fall under.) If I try to dedup on the field that I only want to see one description of, it shortens my results but leaves the multiple duplicate descriptions. ![]() The problem is, when I use the table function, it leaves me with results like this: In this case, it is intentional that multiple items in the table can roll up into having the same description. ![]() ![]() I am basically inputting the value from my search which corresponds to column A, into the lookup table and trying to return the value from column C (assume "one" is a description for something). The problem I am having is that my lookup table looks like this: I use a lookup table to input a field from one of my search results (column A in my lookup table), and then output to a table to make the data easy to read (column B and C give a more high level description of column A). I am trying to find a way to clean up the display of one of my searches. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |