VictoriaMetrics / VictoriaMetrics

VictoriaMetrics: fast, cost-effective monitoring solution and time series database
https://victoriametrics.com/
Apache License 2.0
11.99k stars 1.19k forks source link

When using fluentbit to configure VictoriaLogs as the log data storage service, the written log time format does not support '2018-05-30 09:39:52.000681' #6721

Open zoutao0909 opened 1 month ago

zoutao0909 commented 1 month ago

Is your question request related to a specific component?

VictoriaLogs

Describe the question in detail

  1. When collecting logs through fluentbit, there may be a need to parse the time in the log and specify this time as the _time field in the VictoriaLogs data. My configuration is as follows:
    [Output]
    Name http
    Match *
    host localhost
    port 9428
    uri /insert/jsonline?_stream_fields=stream&_msg_field=log&_time_field=date
    format json_lines
    json_date_format iso8601

Here, output to VictoriaLogs specifies json_date_format iso8601. When my time is ‘2024-07-29 14:57:14.415002’, the default time zone is +08:00, and the data finally written to VictoriaLogs is _time=2024-07-29T14:57:14.415002Z. The final time is 8 hours more than the actual time.

  1. In fluentbit, you can configure json_date_format java_sql_timestamp (for example: 2018-05-30 09:39:52.000681), but when I configure it this way, VictoriaLogs has a parsing error:

VictoriaMetrics/app/vlinsert/jsonline/jsonline.go:60 jsonline: cannot read line #0 in /jsonline request: cannot get timestamp: cannot unmarshal rfc3339 timestamp from date="2024-07-29 14:57:14.415002"

Expected result: VictoriaLogs can support the time data parsing of json_date_format java_sql_timestamp (for example: 2018-05-30 09:39:52.000681). When there is no time zone information in the time data, according to VictoriaLogs The current time zone of the service is converted to UTC time, instead of the default conversion to UTC time as it is now, but no time zone conversion is performed, resulting in inconsistency between the recorded time and the actual time when the log is generated.

Troubleshooting docs

ARBURIUS commented 1 month ago

The same problem. @zoutao0909 did you find how to resolve the problem?

zoutao0909 commented 1 month ago

The same problem. @zoutao0909 did you find how to resolve the problem?

There is no better way. In order to adapt to this situation, my current processing is: because the written time data is only converted in format, not in time zone, so when I specify the time during the query, I also convert the format of the incoming time without converting the time zone, so that the data found can meet my expectations. At the same time, the format conversion is also required when the data is displayed, without converting the time zone.

However, this makes it impossible to use the tail query supported in the new version, because tail seems unable to query data in the future