Timestamp formats in logs

A log event leaves behind a timestamp attribute, which tells you the exact moment a certain event happened. Timestamps are critical for ordering events as they let you search logs for specific timeframes, letting you discover what and when an event happened.

Timestamps have many formats without a single standard. They appear at the beginning of the log event in most cases, but can sometimes appear much later in the log, or not at all.

• If a log is sent with a timestamp attribute, or if a timestamp attribute parsed from it, New Relic uses that timestamp for the log.
• If a JSON log is sent with a timestamp field, New Relic uses that timestamp when extracting JSON fields as attributes, and it takes precedence over any existing timestamp attribute.
• If timestamp isn't sent, New Relic uses the log's ingest time as the timestamp.

Most log forwarders pass along timestamp information from the log source, so you may not need to specify the timestamp yourself.

Supported logs timestamp format

There are two options for manually overriding default behavior to assign the timestamp value contained in the log.

1. If we receive a JSON formatted log containing a timestamp attribute in one of our supported time formats, the ingest timestamp will be overridden. Instead, the the timestamp value from the JSON attribute will be used.
2. You can use parsing rules to override the ingest timestamp value. Parsing rules let you extract out data to format your timestamp with one of our supported formats. You can also use datetime Grok type and a pattern to define the custom timestamp format in your log.

We support two timestamp formats:

Supported timestamps in JSON logs

If we receive a JSON formatted log with a timestamp attribute, we override the default ingest timestamp value with the original JSON value. If there's no timestamp field, or the field is incorrectly formatted, the log will be stored with the ingest timestamp. Keep in mind that a payload with timestamps older than 48 hours are dropped.

Timestamps are converted to Unix epoch milliseconds and stored internally as a long data type, with the reserved keyword timestamp. Depending on the JSON body format, ​the timestamp field can be allocated in four different places:

• Inside the simplified set of attributes of the JSON body message when sending a single JSON object.
• Inside the common object in the detailed set of attributes of the JSON body message when sending one or more JSON objects. The timestamp applies to all log messages of this JSON.
• Inside each log message in the logs object in the detailed set of attributes of the JSON body message when sending one or more JSON objects. The timestamps only apply to that log message.
• Inside the “message” JSON field when it is a valid JSON message. Our log management capabilities will parse any message attribute as JSON. The resulting JSON attributes in the parsed message will be added to the log.

Here are some examples of JSON logs with a valid timestamp attribute that override the ingest timestamp:

{
  "timestamp": 1701445572,
  "message": "This is my sample JSON log message with timestamp attribute in epoch format"
}

"timestamp" : 1701445572000,
"message":"This is my sample JSON log message with timestamp attribute in epoch format"

{
  "timestamp": "2023-12-01T15:46:26.607Z",
  "message": "This is my sample JSON log message with timestamp attribute in ISO8601 format"
}

"timestamp": 1701445586607,
"message":"This is my sample JSON log message with timestamp attribute in ISO8601 format"

Set log timestamp with parsing rules

You can use parsing rules at ingest to override the ingest timestamp with the value contained in the log. Parsing rules extract out our supported time formats with simple Grok expressions, or by using the datetime Grok type and pattern to define the custom timestamp format in your log.

The attribute name extracted by the expression must be timestamp and its data type must be string or long. If data type is not provided, the timestamp defaults to string. For epoch timestamps with microsecond or nanosecond precision, you must include the long datatype even though timestamp precision shortens to milliseconds.

If the timestamp in your log is a Unix epoch or ISO8601 formatted timestamp you can use the default Grok patterns to match them. For example:

• To extract a Unix epoch timestamp you can use any expression that matches the value, like NUMBER, NOTSPACE, DATA, or GREEDYDATA.
• To extract an ISO8601 formatted timestamp you should use the TIMESTAMP_ISO8601 Grok expression.

You can use the datetime Grok type to parse timestamps in non-supported formats. To do this you must include the datetime Grok type with the pattern matching your logs timestamp format. The pattern must use the Java Simple Date and Time Patterns found here. Below are examples that show how Grok expressions transform unsupported timestamp formats into supported formats:

Below are some examples on how to parse the timestamp from your logs using ingest Parsing rules:

%{TIMESTAMP_ISO8601:timestamp}

2023-12-05T16:50:48.421Z 146.190.212.184: This is my sample non-JSON log message with ISO8601 timestamp.

"ISO8601_TIMEZONE": "Z",
"message": "2023-12-05T16:50:48.421Z 146.190.212.184: This is my sample non-JSON log message with ISO8601 timestamp.",
"timestamp": 1701795048421

%{NUMBER:timestamp:long}

1701795958504 146.190.212.184: This is my sample non-JSON log message with epoch (with ms) timestamp.

"message": "1701795958504 146.190.212.184: This is my sample non-JSON log message with epoch (with ms) timestamp.",
"timestamp": 1701795958504

^%{DATA:timestamp:datetime;MM/dd/yyyy HH:mm:ss.SSS} %{IP:ip}

12/05/2023 17:12:45.347 146.190.212.184: This is my sample non-JSON log message with un-supported timestamp.

"ip": "146.190.212.184",
"message": "12/05/2023 17:12:45.347 146.190.212.184: This is my sample non-JSON log message with DATE_US timestamp.",
"timestamp": 1701796365347