[Draft] Update otelopscol to v0.156.0#2388
Conversation
| Parser: confgenerator.ParserShared{ | ||
| TimeKey: "timestamp", | ||
| TimeFormat: "%Y-%m-%dT%H:%M:%S.%L", | ||
| TimeFormat: "%Y-%m-%dT%H:%M:%S.%LZ", |
There was a problem hiding this comment.
I think you want %z to parse this as UTC, or else it will be parsed as a local time, no?
There was a problem hiding this comment.
Yes, you are right.
This also gives me insight that fluent-bit doesn't "fail to parse" a timestamp that has a "suffix" that is not within the described format. Being a bit more lenient that way.
| Parser: confgenerator.ParserShared{ | ||
| TimeKey: "time", | ||
| TimeFormat: "%Y-%m-%d %H:%M:%S.%L %z", | ||
| TimeFormat: "%Y-%m-%d %H:%M:%S.%L %Z", |
There was a problem hiding this comment.
This is a fun one. strptime's %z is documented as "An RFC-822/ISO 8601 standard timezone specification. RFC-822 allows "UT" / "GMT" / "EST" / "EDT" / "CST" / "CDT" / "MST" / "MDT" / "PST" / "PDT" / 1ALPHA. ISO 8601 allows only Z or ±nn:nn. Notably absent from this list is UTC.
I added a test using UT, and glibc's strptime actually does not parse UT or GMT as valid %z specifiers.
So I'm convinced that %Z is indeed the correct specifier for these logs, and the fact that %z worked with Fluent Bit was a happy accident.
There was a problem hiding this comment.
Great!
| formattedTime := ottl.FormatTime(ottl.ToTime(v, "%Y-%m-%dT%T.%sZ"), "%Y-%m-%d %T.%s") | ||
| return v.Set(ottl.Concat([]ottl.Value{formattedTime, ottl.StringLiteral("+0000")}, " ")) |
There was a problem hiding this comment.
Hm, is this guaranteed to actually produce a UTC time? Should we actually just be formatting with %z instead?
There was a problem hiding this comment.
We were creating timestamps for Windows Event Logs using the output format "%Y-%m-%d %T.%s +0000", which i assume because the fluent-bit windows event logs were always using UTC in the format +0000.
I set %z (which translates to Golang Z0700) which generates Z instead. I think this is better. We could somehow hack the format to %z -> 0700 to get +0000 but it doesn't seem worth it.
The original PR (#1969) i assume was trying to replicate exactly what Windows Event Logs API returns (AFAIU, xml logs are stored always with UTC 1 ) and how fluent-bit event logs timestamps are displayed.
Footnotes
2 participants
Description
Related issue
How has this been tested?
Checklist: