Correct timestamp recognition

Correct timestamp recognition

Whenever the Splunk Server begins to index a new source, it sets timestamps in this order:

• It sets the current date as a fallback date.
• It then attempts to extract a date in the "source::" string. If it succeeds, it sets that date as the fallback date.
• When timestamping each event, if it has a date, that date is used and becomes the new fallback date.
• If an event's timestamp has a time but no date, the fallback date is used.

If Splunk is not extracting the timestamp in an event correctly, you can either create a custom datetime.xml file that instructs Splunk how to recognize that timestamp, OR you can add new timestamp rules to the default datetime.xml file.

etc/bundles/local/props.conf

This example would tell Splunk to use a custom timestamp parser, modified from the default $SPLUNK_HOME/etc/datetime.xml .

[my_custom_sourcetype]
DATETIME_CONFIG = /etc/custom_datetime.xml

Attributes

• DATETIME_CONFIG*

Filename

Default: /etc/datetime.xml

The configuration file that specifies the patterns Splunk should treat as dates and times. The path is prefixed by $SPLUNK_HOME .

Training Splunk to Recognize Timestamps

Splunk's commandline interface provides an interactive timestamp training process that produces regex-based expressions to be added to the datetime.xml file.

splunk train dates

Positional timestamp extraction

If your event contains more than one timestamp you have the option of telling which one the Splunk Server should extract when setting its timestamp. This is especially useful with events that contain syslog host-chaining.

Positional timestamp extraction is configured in $SPLUNK_HOME/etc/bundles/local/props.conf using the following directive:

    [source::<path>]
    TIME_PREFIX = <regex> 

The regular expression should match on whatever data immediately precedes the desired timestamp.

• Was this topic useful?
• Post a comment