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.
- By default, New Relic assigns the value of the log
timestampattribute (a reserved keyword) at the exact time the log is ingested. This is referred to as the ingest time. - When logs don't have a
timestampattribute, New Relic assigns a timestamp at time of ingest. - Logs in a JSON format contain some attribute that identifies the timestamp, like
timestamp,log_timestamp,time, etc. - If we receive JSON logs with with a supported timestamp format, we override our ingest timestamp with the JSON attribute.
Supported logs timestamp format
There are two options for manually overriding default behavior to assign the timestamp value contained in the log.
- If we receive a JSON formatted log containing a
timestampattribute 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. - You can use parsing rules to override the ingest
timestampvalue. Parsing rules let you extract out data to format your timestamp with one of our supported formats. You can also usedatetimeGrok type and apatternto 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 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:
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, orGREEDYDATA. - To extract an ISO8601 formatted timestamp you should use the
TIMESTAMP_ISO8601Grok 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:
|
| Grok expression |
|---|---|---|
11/17/2023 23:55:25.674 | MM/dd/yyyy HH:mm:ss.SSS |
|
11-17-2023 23:55:25 | MM-dd-yyyy HH:mm:ss |
|
11/17/2023 09:55:25 AM | MM/dd/yyyy h:mm:ss a |
|
Below are some examples on how to parse the timestamp from your logs using ingest Parsing rules: