Splunk is not Excel But seriously. For Splunk every result row is... well, a separate row. Depending on the actual use case you could cheat a bit but the way to do so would depend on the detaile...
See more...
Splunk is not Excel But seriously. For Splunk every result row is... well, a separate row. Depending on the actual use case you could cheat a bit but the way to do so would depend on the detailed desired outcome. You could do something like <your_initial_search> | stats values(_raw) as "Event Details" by UID (and maybe do some magic with custom CSS in dashboard to "un-align" the table a bit). But that will give you just raw events. If you want to have separate fields from those "content" events... that's gonna get tricky and ugly (and un-splunky because the result will not have any internal logical consistency and will be only for presentation purposes). An example using my windows events index: index=winevents This is just the base search - nothing to write home about | sort EventID That should also be pretty obvious - we want the events grouped by EventID field. You can add subsequent sort field(s) if you want them sorted within those groups. | streamstats window=1 current=f last(EventID) as previousID Now the magic starts. We're copying the EvenID value from previous event to the current one. The previous one is called previousID. | eval splittable=if(NOT EventID=previousID,mvappend("1","0"),0) If the current EventID is the same as previous one (which we carried over in last step) it means that it's not the first result with given EventID. If those values are different (or - in case of the very first result row, the previousID is empty; that's why the condition is in the form of NOT a=b instead of a!=b), this is a first row of results for given EventID. Depending on which case it is, we create a temporary field with either a single value (whether it's a zero, or anything else is not important; I just chose zero) or two values of which the second one must be the same as for the "not-first" row. We're doing this because Splunk cannot just arbitrarily add rows. So we're doing the trick with multiple values in one result (so called multivalue field) so we can split that result into two separate ones. And this we do by calling: | mvexpand splittable Now the first row for each unique EventID, which we marked with two values in the field called "splittable" got split into two separate rows with one value each. The row which had just one value was left unchanged. What is also important is that the order of the split results remains the same as the order of the values in the field on which we're calling mvexpand. So now all that's left is to find the "header" row and clean all "non-header" values. And clean the "header" field (in our case the EventID field) for all "non-header" rows. | foreach * [ eval <<FIELD>>=case(splittable=1 AND "<<FIELD>>"="EventID",EventID,splittable=1,"",splittable=0 AND "<<FIELD>>"="EventID","",1=1,<<FIELD>>) ] We may now remove the temporary fields which we don't need anymore (this step is optional if we're limiting displayed fields to a strictly defined set; if we just list all fields, we might want to do this so we don't drag temporary fields along) | fields - splittable previousID And now we can present the results as table with either | table EventID host _time field1 field2 and so on or simply | table EventID * OK. So this exercise was fun but I wouldn't do that this way. After doing all this you're getting a set of results where you have no relationship between the EventID field from one result and the actual "contents" of the events in other results - you can't aggregate the data, (re)sort them or do anything else, maybe except some general statistics. This kind of result is unusable. As I said at the beginning - Splunk is not Excel and you can't "merge fields". The only way this could work would be if someone wrote a custom visualization which would do some JS magic comparing values from neighboring rows and fiddling with CSS but so far I don't think anyone did such thing.