GELF timestamp field missing millisecond precision
Tags:
GELF
#1
coffee-squirrel
We have nxlog CE pushing to a GELF TCP input in Graylog, and the timestamp field received from nxlog appears to not have the milliseconds (i.e. it ends in ".000"), resulting in out-of-order messages in Graylog within a 1-second window. Other sources (Graylog Collectors, apps pushing directly, etc.) include the original millisecond value as expected. For Graylog inputs receiving nxlog messages we've had to set up an extractor to extract the timestamp from the message itself. Are there any options to keep millisecond precision with nxlog?
#1
coffee-squirrel
We have nxlog CE pushing to a GELF TCP input in Graylog, and the timestamp field received from nxlog appears to not have the milliseconds (i.e. it ends in ".000"), resulting in out-of-order messages in Graylog within a 1-second window. Other sources (Graylog Collectors, apps pushing directly, etc.) include the original millisecond value as expected. For Graylog inputs receiving nxlog messages we've had to set up an extractor to extract the timestamp from the message itself. Are there any options to keep millisecond precision with nxlog?
The GELF specification had this:
timestamp: UNIX microsecond timestamp (decimal); SHOULD be set by client library.
It looks like it's now changed to the following in the latest spec:
timestamp: Seconds since UNIX epoch with optional decimal places for milliseconds;
The code for xm_gelf needs to be modified in order to enable this.
