Description
In 0b4b0a7, some metadata fields for partial messages were introduced, however as of now they are not used by all plugins and especially the journald driver.
https://github.com/moby/moby/blob/master/daemon/logger/journald/journald.go#L108-L110
Only a CONTAINER_PARTIAL_MESSAGE indicator is set, but the other fields are omitted.
In various issues, it was suggested to use the fluentd concat plugin or similar approaches to reassemble those messages. However they become hard to use when a certain log volume is present, as the downstream services can no longer reliably detect message boundaries. Having the metadata fields present will greatly improve that situation.
Describe the results you expected:
All data from the PartialLogMetaData struct present in journald logs.
If needed, i can create a PR for this, but first I wanted to hear some feedback, as this might not be desired for any reson.
Description
In 0b4b0a7, some metadata fields for partial messages were introduced, however as of now they are not used by all plugins and especially the journald driver.
https://github.com/moby/moby/blob/master/daemon/logger/journald/journald.go#L108-L110
Only a
CONTAINER_PARTIAL_MESSAGEindicator is set, but the other fields are omitted.In various issues, it was suggested to use the fluentd concat plugin or similar approaches to reassemble those messages. However they become hard to use when a certain log volume is present, as the downstream services can no longer reliably detect message boundaries. Having the metadata fields present will greatly improve that situation.
Describe the results you expected:
All data from the PartialLogMetaData struct present in journald logs.
If needed, i can create a PR for this, but first I wanted to hear some feedback, as this might not be desired for any reson.