How the Parser Works
The timestamp parser is unique from the rest of the parsers in that it only makes sense to use the timestamp parser on a subset of an actual event. The reason for this is because an event contains more than a timestamp. The first question to answer is why would you want to use this option? The reason is for when you wish to use the time within an event instead of the time on the client or the time on the Log Insight server. This makes it possible to trust the time within the event — something that Log Insight does not do by default (intentionally). Remember that by default Log Insight uses server time during ingestion of events for timestamps. If an agent is used and the agent client time is within 10 minutes the agent client time is used instead of the server-time. If the agent cannot process events real-time then the timestamp parser makes it possible to properly set the timestamp on ingested events. Again, the timestamp parser time must be within 10 minutes of the Log Insight server time.
To use timestamp parser you need to leverage a field_decoder. For example:
By default, the timestamp parser has built-in knowledge about a variety of timestamp formats and can parse them automatically. If the parsing does not work automatically, you can see the format option. For example:
format=%a %b %d %Y %I:%M %p
All of the supported format options are listed below.
'%a': Abbreviated weekday name, for example: Thu
'%A': Full weekday name, for example: Thursday
'%b': Abbreviated month name, for example: Aug
'%B': Full month name, for example: August
'%d': Day of the month, zero-padded (01-31), for example: 03
'%e': Day of the month, space-padded ( 1-31), for example: 3
'%f': Fractional seconds of time, for example: .036 'f' specifier assumes that '.' or ',' character should exist before fractional seconds and there is no need to mention that character in the format. If none of these characters precedes fractional seconds, timestamp wouldn't be parsed.
'%H': Hour in 24h format (00-23), for example: 14
'%I': Hour in 12h format (01-12), for example: 02
'%m': Month as a decimal number (01-12), for example: 08
'%M': Minute (00-59), for example: 55
'%p': AM or PM designation, for example: PM
'%S': Second (00-61), for example: 02
'%Y': Year, for example: 2001
'%z': ISO 8601 offset from UTC in timezone (1 minute=1, 1 hour=100)., for example: +100
// Additional specifiers are accepted by the Timestamp parser, but their values are ignored and do not affect the parsed time
'%C': Year divided by 100 and truncated to integer (00-99), for example: 20
'%g': Week-based year, last two digits (00-99), for example, 01
'%G': Week-based year, for example, 2001
'%j': Day of the year (001-366), for example: 235
'%u': ISO 8601 weekday as number with Monday as 1 (1-7), for example: 4
'%U': Week number with the first Sunday as the first day of week one (00-53), for example: 33
'%V': ISO 8601 week number (00-53), for example: 34
'%w': Weekday as a decimal number with Sunday as 0 (0-6), for example: 4
'%W': Week number with the first Monday as the first day of week one (00-53), for example: 34
'%y': Year, last two digits (00-99), for example: 01
As you can see, the timestamp parser provides additional agent functionality around how timestamps are handled server-side. While a variety of timestamp format are built into the parser, the format option can be used to support and timestamp format. Remember that the timestamp parser is unique in that it only works for a subset of an event. Have you tried the timestamp parser?
© 2015, Steve Flanders. All rights reserved.