Skipped malformed docker-compose log lines #1297
Conversation
| if len(messageSlice) != 2 { | ||
| return fmt.Errorf("malformed docker-compose log line") | ||
| logger.Debugf("skipped malformed docker-compose log line: %s", line) |
There was a problem hiding this comment.
Should we check if the malformed message is actually "Attaching to..." to avoid silently ignoring messages here?
There was a problem hiding this comment.
It could be checked that to narrow the skipped messages.
So for any other unexpected message, should we return error as it was before? @jsoriano
There was a problem hiding this comment.
What is the concern with missing unknown log format lines? ISTM that given that the vetting done later depends on knowing what we are looking for, unknown things will always be at risk of being missed.
There was a problem hiding this comment.
The messages that should be interesting for this purpose should be the ones with this format:
<container_name> | [<json> | string ]- Sometimes I've seen messages directly without being a JSON.
elastic-package-stack-elastic-agent-1 | {"log.level":"info", .. }
elastic-package-stack-elastic-agent-1 | Message
So, it looks reasonably to me skipping those other messages that do not have that format.
|
/test |
1 similar comment
|
/test |
|
buildkite test this |
💚 Build Succeeded
History
cc @mrodm |
5 participants
Closes #1296
When running
elastic-packagealong with docker-compose v1.* , the first line of thedocker-compose logscommand is always like:Attaching to <container>. For instance:This message is not actual log and
elastic-package test systemwas failing due to that. Expected messages should be like:This PR changes this behaviour to avoid raising an error and instead it logs a debug message. Those log lines that are not log-like messages are skipped.