Regex for cri-o logs does not cover Zulu time indicated with Z

[jonaskello]

The regex for cri-o log format as specified here is ^(?P<time>[^ Z]+) (?P<stream>stdout|stderr) (?P<logtag>[^ ]*) ?(?P<log>.*)$

The standardized log format for cri-o is RFC3339Nano in which both of these strings are valid

• 2024-06-25T13:06:07.246385666+02:00
• 2024-06-22T02:44:44.420821048Z

However the regex per above does not cover the latter string (with the Z to indicate Zulu/GMT timezone). We encountered this format on a AKS cluster.

See also this reference which has the following example (that highlights that both Z and +02:00 are valid suffixes for the time:

        // Some valid layouts are invalid time values, due to format specifiers
	// such as _ for space padding and Z for zone information.
	// For example the RFC3339 layout 2006-01-02T15:04:05Z07:00
	// contains both Z and a time zone offset in order to handle both valid options:
	// 2006-01-02T15:04:05Z
	// 2006-01-02T15:04:05+07:00
	t, _ = time.Parse(time.RFC3339, "2006-01-02T15:04:05Z")
	fmt.Println(t)
	t, _ = time.Parse(time.RFC3339, "2006-01-02T15:04:05+07:00")
	fmt.Println(t)
	_, err := time.Parse(time.RFC3339, time.RFC3339)
	fmt.Println("error", err) // Returns an error as the layout is not a valid time value

I propose that the regex is changed to this: ^(?P<time>[^ ]+) (?P<stream>stdout|stderr) (?P<logtag>[^ ]*) ?(?P<log>.*)$ so the full time is parsed until the space. This should work for any format AFAIK.

[jonaskello]

In order to fix this routes would probably also have to be updated somehow:

routes:
          - output: parser-docker
            expr: 'body matches "^\\{"'
          - output: parser-crio
            expr: 'body matches "^[^ Z]+ "'
          - output: parser-containerd
            expr: 'body matches "^[^ Z]+Z"'

Or the containerd parser could be deprecated/removed as modern containerd versions adhere to cri-o format so there should be no need for a separate parser for containerd (see this issue).

[povilasv]

@jonaskello could you check if the new version fixes this issue for you?

We recently switched to container parser #1195

[jonaskello]

Yes this would solve it as it removes the need for regex! Thanks!