-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only log publish event messages in trace log level under elastic-agent #34391
Conversation
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
Pinging @elastic/elastic-agent (Team:Elastic-Agent) |
agent := underAgent.Load() | ||
if agent { | ||
trace := underAgentTrace.Load() | ||
if !trace { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should also apply this to any debug level log lines in processors, since they can/will happen for every event in the pipeline.
For example I've seen this one be printed for every log line processed (an example is also in the description of elastic/elastic-agent#1955):
beats/libbeat/processors/actions/copy_fields.go
Lines 81 to 82 in 5337e63
errMsg := fmt.Errorf("Failed to copy fields in copy_fields processor: %s", err) | |
f.logger.Debug(errMsg.Error()) |
Searching for instances of Debug
in libbeat/processors shows there aren't that many instances of this to handle, so we may as well deal with them now before somebody forgets to set ignore_missing
on a drop_fields processor and makes debug logging unusable again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am torn on that. I agree that when it happens it floods the logs, but it really is an issue and maybe we should log it at debug.
The reason for not logging Publish event:
at debug is that it logs when it is successful, not only on failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until we have a way to set the log level per integration in Fleet my concern is that processor errors will prevent us from seeing the debug logs of the agent itself.
I think fundamentally I agree the processor errors are true errors, but I also think that with the current log level configuration mechanism in Fleet we should move them to trace to protect ourselves from not being able to debug the agent itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay I have added that logic to the processors as well.
This pull request is now in conflicts. Could you fix it? 🙏
|
This pull request is now in conflicts. Could you fix it? 🙏
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, we can keep iterating on this as we find noise.
I don't believe this will fully resolve the problem though, because Fleet doesn't expose the trace level yet. We need to deal with that to fully close the issue, otherwise we've just hidden these log lines entirely for Fleet managed agents.
…evel under elastic-agent (#34434) * Only log publish event messages in trace log level under elastic-agent (#34391) * Only log publish event messages in trace log level under elastic-agent. * Add changelog entry. * Fix changelog. * Add same logic to processors. (cherry picked from commit 15ff7d1) # Conflicts: # libbeat/processors/actions/append.go * Remove append processor. --------- Co-authored-by: Blake Rouse <blake.rouse@elastic.co>
#34391) * Only log publish event messages in trace log level under elastic-agent. * Add changelog entry. * Fix changelog. * Add same logic to processors.
What does this PR do?
Changes the behavior of the publishing pipeline to only log the
Publish event:
messages when the Elastic Agent is running in trace mode.This change has no effect on beats not running under the Elastic Agent.
Why is it important?
When this was enabled in debug mode it make it impossible to read the debug logs. This change only shows these messages when running with trace enabled.
Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files[ ] I have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related issues