Discovery, sort by timestamp and then field (int)

[elvarb (Elvar)]

I have logs that come in that are only accurate down to a second.

The logs are generated when different part of an application is run, so when a function is run it has a unique ID to group those messages together and there is also an incremental int field for ordering. The issue is that there can be multiple lines each second and since Kibana discovery is only order on timestamps the line numbers are often out of order.

Is it possible to do order by (timestamp, line_no) ?

[timroes]

Hi Elvar,

currently that is unfortunately not possible. We have an open feature request #696 for that, that you can follow to stay informed about updates.

A workaround could be, to index the timestamp + the unique ID suffixed that way you have both in one field to sort for them.

Cheers,
Tim

[elvarb (Elvar)]

I hacked this differently, the line_no field rarely goes over 10, but sometimes it goes over 12000.

Used the ruby filter to create a new string field with 3 numbers, always

ruby {
   	code => "event.set('line_ns', event.get('line_no').to_s.rjust(3, '0')[-3..-1])"
}

So line_no field of 1 becomes 001, and line_no field of 12034 becomes 034. Then I combined the timestamp field in the log with the new line_no field, that way I could parse it so that the line_no becomes the nanoseconds.

mutate {
	add_field => { "timestamp_line" => "%{timestamp} %{line_ns}" }
}

date {
	match => [ "timestamp_line", "dd.MM.yyyy HH:mm:ss SSS"]
}

The only risk is when events come in on the same second and it moves from 999 to 1000, very very unlikely.

Using your method of creating a new field I dont think I would be able to sort it in the Discovery panel, seem to be only be able to sort by timestamp and int, not strings.

[timroes]

That's correct (regarding the sortability). But why don't you just join those two numeric values into another numeric value? As long as you make sure, that you use the same amount of digits for the line_ns which you do, you can just place them behind of each other and treat them as a new numeric value and index it as a long?

[elvarb (Elvar)]

Because each log has a unique log_id, and within each log_id are multiple entries with line_no, each starting from 1 to some number.

... though... there is another field called uix_seq_no which is auto increment it seems, seems to be the most obvious to use that. I'm just not sure about the actual behavior of that field, does it grow during the lifetime of the system, does it reset with version upgrades, or with reboots or something else.

For now I'll use the timestamp, when I'm sure about the uix_seq_no field I'll shift to that.