-
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
Add definition for logging.metrics.enabled, pass config from agent to beats #26828
Add definition for logging.metrics.enabled, pass config from agent to beats #26828
Conversation
Add a log_metrics config option that defaults to true. When set to false the agent will pass -E logging.metrice.enabled=false to disable the underlying beats from adding metrics to their log streams.
3d635dd
to
2246233
Compare
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
Pinging @elastic/agent (Team:Agent) |
Can you share your thoughts on if we should set the default to true (as it is) or false? |
@urso and I briefly discussed this, setting it to true does not change existing behaviour and allows us to use the logs when providing support to users. |
@@ -33,6 +33,8 @@ inputs: | |||
# logs: true | |||
# # enables metrics monitoring | |||
# metrics: true | |||
# # running processes will emit metrics into logs | |||
# log_metrics: true |
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.
What is the difference between metrics
and logs_metrics
?
We already have the agent.logging.metrics.enabled
settings. Should we rather use that setting?
@michalpristas WDYT?
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.
need to check if these settings are passed to beats
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'm not against of reusing what we have. these settings are not forwarded to beats but used for constructing our logger.
This pull request is now in conflicts. Could you fix it? 🙏
|
where are we on this. any updates? |
Change the log metrics enablement config from a new option under metrics to agent.logging.metrics.enabled.
libbeat/logp/config.go
Outdated
// | ||
// Currently these options are not used through this object in beats (as monitoring is setup elsewhere). | ||
type MetricsConfig struct { | ||
Enabled bool `config:"enabled" yaml:"enabled"` |
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.
@urso, I noticed that the beats load through
beats/libbeat/cmd/instance/beat.go
Line 453 in 60e9e34
if b.Config.MetricLogging == nil || b.Config.MetricLogging.Enabled() { |
but the logging config does define these variables, do you think it makes sense to define it as part of the logging config so it can be retrieved by the agent?
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.
+1
/test |
{% if metrics_period -%} | ||
logging.metrics.period: {{ metrics_period }} | ||
{% if file_name -%} | ||
logging.files.name: {{ file_name }} |
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.
The export command being tested disables environment variable resolution.
beats/libbeat/cmd/export/config.go
Line 42 in 4727470
settings.DisableConfigResolver = true |
I think it's so
export config
can be used to copy the config and ignore the local environment.Originally the test was for
logging.metrics.period
but seeing as how this pr adds the definition for this attribute as a time.Duration
the export fails because the string could not be parsed as a duration.I instead changed the test to use a string type attribute so the export does not fail.
However going forward the export config
command will run into this issue if logging.metrics.period
or logging.metrics.enabled
are set to environment variables.
This should not effect other commands (which resolve environment variables).
tldr; attribute+test has changed because environment variable expansion is disabled for the export
commands
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 to me.
… beats (#26828) (#27343) Define logging.metrics.enabled and logging.metrics.period. When logging.metrics.enabled is set to false the elastic-agent will pass the setting to the underlying beats through a command line variable. (cherry picked from commit 393b2f0) Co-authored-by: Michel Laterman <82832767+michel-laterman@users.noreply.github.com>
What does this PR do?
Define logging.metrics.enabled and logging.metrics.period.
When logging.metrics.enabled is set to false the elastic-agent will
pass the setting to the underlying beats through a command line variable.
Checklist
I have commented my code, particularly in hard-to-understand areasI have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
Add
agent.monitoring.log_metrics: false
to elastic-agent.yml (in stand-alone mode) and ensure that the beat logs do not have metrics entries.i.e.: default behaviour with agent.monitoring.log_metrics missing:
setting log_metrics: false:
Related issues