does anyone know a better way to turn result rows back into event rows?

[sideview]

So Splunk of course has an important but subtle distinction between 1) rows that are straight out of the index (these rows are events) and 2) rows that have been transformed or otherwise altered by the so called 'transforming' search commands, eg:stats (these are results).

In most cases this just causes small things like the automatic switching into the table view in the search UI, or the 'build report' link changing to 'show report' etc.

However it causes some problems when you're developing views, most notably in the event renderers.

This is because event renderers will only run against the event rows, but they are extremely useful (possibly more so) when used against result rows.

This is even though (as of 4.1.something) you can give EventsViewer a param <param name="entityName">results</param> and it will render the results as though they were events. Even when you do that it still wont run the event renderers against the result rows like one might expect.

So, what I always resort to in apps is this ugly little thing. (My apologies for any aneurisms this causes)

`foo NOT foo | append [<search> | stats something something] | eval eventtype="my_custom_event_renderer"`

and then I let the EventsViewer render the events. The append command has a neat side-effect of bleaching off the events-vs-results nature of the appended rows. So they get appended into an empty 'events' set and thus get laundered into events.

But that's a little nutty and I've always wondered if there was some search command that could do this without all the evil bits.

ie where I could take

<search> | stats count by user

and tack on

<search> | stats count by user | makeEvents

and the stats rows would then really become events. This would have obvious and strange implications for the MultiFieldViewer interactions in the sidebar as well as for the generic drilldown intention logic and even for the addterm intentions that are used when you click on 'event fields'.

(You can see the crazy bugs this would introduce just by trying the "foo NOT foo | append" trick yourself in the search UI. Then start clicking on values in the sidebar or in the events and watch what it does.)

However arguably the inconsistency has been in the product ever since EventsViewer was changed to allow <param name="entityName">results</param>.

Probably the better way to fix this overall would be to follow through and improve EventsViewer so that a) it processed event_renderer stanzas even when they were results, and b) it did the right things in 'results' mode wrt not sending intentions around as though things were 'events'. That would really be best as I'd have my cake, the system would become more consistent and complete, all without nasty "foo NOT foo" tricks and without breaking the core assumptions of the sidebar and the intentions...

hope this makes sense... But until the day that all happens, is there some less hideous search language trick I could use?

[woodcock]

You could pipe it to a file with "outputcsv" and the read in the same data with "inputcsv". The thing is, I don't know if the new data is considered rows or events.