What Time_Key does in a Fluent Bit parser
Use Time_Key, Time_Format, and Time_Keep to distinguish event time from collection time and preserve the original timestamp for troubleshooting.
Time_Key tells a Fluent Bit parser which record field contains the event's timestamp. When parsing succeeds, that value becomes the event time carried through the pipeline. This matters when logs arrive late or are replayed: collection time and the time the application recorded an event may differ substantially.
Configure the parser and attach it to an input
Suppose the application writes:
{"timestamp":"2024-01-15T10:30:00+0800","msg":"Order created"}
In parsers.conf:
[PARSER]
Name app_json
Format json
Time_Key timestamp
Time_Format %Y-%m-%dT%H:%M:%S%z
Time_Keep On
In the main configuration:
[SERVICE]
Parsers_File /etc/fluent-bit/parsers.conf
[INPUT]
Name tail
Path /var/log/myapp/app.log
Parser app_json
Tag myapp
[OUTPUT]
Name stdout
Match myapp
Adjust the parser-file path to your installation. Defining a parser does not apply it automatically; the input must reference its name.
Distinguish the timestamp from a record field
| Setting | Purpose |
|---|---|
Time_Key |
Selects the field to parse as event time |
Time_Format |
Describes the input time representation using strptime-style directives |
Time_Keep |
Retains the original time field after successful extraction when enabled |
Fluent Bit carries an event timestamp separately from the record map. It does not universally create a field named @timestamp. A destination output or later transformation may serialize that timestamp into a field with that name.
Keep the original field while validating a parser. Compare it with the event timestamp and the destination's displayed timezone. The sample's +0800 is an explicit UTC offset; it represents the same instant as 2024-01-15T02:30:00Z.
Make failures visible
Without a successfully parsed application timestamp, time may come from the input or collection path. A format mismatch can produce parser warnings or a record that fails parsing, depending on the parser and input. Do not assume every malformed timestamp silently falls back in an identical way. Test missing fields, invalid dates, timezone offsets, and fractional seconds against the installed version.
For timestamps without an offset, configure a deliberate timezone interpretation; the parser provides Time_Offset for a fixed offset. Prefer an offset in the log itself when daylight-saving changes matter. The parser configuration reference describes the time options and supported formats.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan