How to edit my transaction search to display the timestamp for each row in my table?

[sridharreddy]

Hi Somesh,

How
My search:

transaction part| timechart values(duration) as duration,values(rollno) as rollno

Result:

_time                   duration     rollno
2016-08-07 21:13:00     10.07        1
                        9.56         2
                        7.35         3
                        12.32        4

I need output in below format:

_time                   duration     rollno
2016-08-07 21:13:00     10.07        1
2016-08-07 21:13:00     9.56         2
2016-08-07 21:13:00     7.35         3
2016-08-07 21:13:00     12.32        4

thanks

[acharlieh]

Your first example seems to be 1 event, with two multi-valued fields, and your desired result seems to be 4 events with single valued fields.

Out of curiosity, what benefit is the timechart command giving you and what does the data look like coming out of the transaction command? If the goal is to bin events together based on time and each transaction is producing a duration and rollno then you might be interested in the bin command instead like so:

transaction part | bin bins=100 _time | table _time duration rollno

If you want exact time (per transaction) you could even just omit the bin command. Now you could also leverage a combination of eval using mvzip and mvexpand.

transaction part | timechart values(duration) as duration,values(rollno) as rollno | eval key = mvzip(duration,rollno,":") | mvexpand key | rex field=key "^(?<duration>[^:]*):(?<rollno>.*)$" | table _time duration rollno

The problem with this one (in addition to the possible syntax errors, as I'm doing this off the top of my head without throwing into a splunk instance right now), involves the implication that the first duration corresponds with the first rollno. The values stats function you're using in the timechart only cares about uniqueness of values and doesn't necessarily preserve order at all. Even using list(X) which preserves order and keeps all values (no guaranteed uniqueness), you're making implications about the Nth values correspond with each other, depending on your data could be problematic, but the first possible solution may even be easier than this.