because the "@timestamp" fields in ECS logging only support millisecond-precision, a sequence number is needed to keep the order of events. Adding this sequence number in FileBeat does not seem possible - only workarounds exist which include disabling multithreading (see https://discuss.elastic.co/t/sequence-number-for-ecs-events-received-by-tcp/291348 ).
In case of the co.elastic.logging.jboss.logmanager.EcsFormatter this should be trivial as the ExtLogRecord from which the JSON is built already includes a method getSequenceNumber.
Adding the sequence number would solve a range of other issues regarding to log event order.
Hi,
because the "@timestamp" fields in ECS logging only support millisecond-precision, a sequence number is needed to keep the order of events. Adding this sequence number in FileBeat does not seem possible - only workarounds exist which include disabling multithreading (see https://discuss.elastic.co/t/sequence-number-for-ecs-events-received-by-tcp/291348 ).
Thus, the ECS formatter should add the sequence number ( https://www.elastic.co/guide/en/ecs/current/ecs-event.html#field-event-sequence ).
In case of the
co.elastic.logging.jboss.logmanager.EcsFormatterthis should be trivial as theExtLogRecordfrom which the JSON is built already includes a methodgetSequenceNumber.Adding the sequence number would solve a range of other issues regarding to log event order.