CRI Logging Docs & Spec Inaccurate Example for Partial Logs

[PettitWesley]

Enhancement Description

Hello, I apologize if this is not the right repo. I'm a maintainer of the popular k8s log collector Fluent BIt.

The spec for the CRI log format could be improved.

https://github.com/kubernetes/design-proposals-archive/blob/main/node/kubelet-cri-logging.md

Specifically, this example log file is incorrect and can not be parsed:

2016-10-06T00:17:09.669794202Z stdout F The content of the log entry 1
2016-10-06T00:17:09.669794202Z stdout P First line of log entry 2
2016-10-06T00:17:09.669794202Z stdout P Second line of the log entry 2
2016-10-06T00:17:10.113242941Z stderr F Last line of the log entry 2

The reason is that the " Last line of the log entry 2" is marked as stderr, but the previous lines were stdout. This means it must be a separate partial message. Also, i believe the log time stamp should be the same for all partial messages.

The spec also lacks information and examples on whether or not partial lines from stdout and stderr can be interleaved.

Please see my Fluent Bit example/troubleshooting guidance here which shows how an example k8s log file with partial log messages is read and recombined: https://github.com/aws/aws-for-fluent-bit/pull/823/files

[PettitWesley]

/sig node

[haircommander]

Is the desired intent here to fix the documentation to better reflect the reality?

[PettitWesley]

@haircommander Yea, the docs need to be updated to reflect clearly and specifically how it actually works. I could open a PR to edit them if you link me the repo...

[haircommander]

so that repo is archived and I find it unlikely it will be updated. You could add a blurb to https://kubernetes.io/docs/concepts/cluster-administration/logging/ describing the CRI format and maybe adding a note that serves as an errata to the archived repo?

[PettitWesley]

@haircommander you mean this repo right? https://github.com/kubernetes/website

I will submit a PR.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale