-
Notifications
You must be signed in to change notification settings - Fork 318
Register config-inversion for InstrumenterConfig
#9953
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
Changes from all commits
7966580
c919872
ea05e22
0e726e3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,8 @@ | ||
| package datadog.trace.api.telemetry; | ||
|
|
||
| import org.slf4j.Logger; | ||
| import org.slf4j.LoggerFactory; | ||
|
|
||
| /** | ||
| * NOOP implementation of ConfigInversionMetricCollector. Used as a default when the real collector | ||
| * is not registered during build tasks like instrumentJava. | ||
|
|
@@ -8,6 +11,9 @@ public final class NoOpConfigInversionMetricCollector implements ConfigInversion | |
| private static final NoOpConfigInversionMetricCollector INSTANCE = | ||
| new NoOpConfigInversionMetricCollector(); | ||
|
|
||
| private static final Logger log = | ||
| LoggerFactory.getLogger(NoOpConfigInversionMetricCollector.class); | ||
|
|
||
| private NoOpConfigInversionMetricCollector() {} | ||
|
|
||
| public static NoOpConfigInversionMetricCollector getInstance() { | ||
|
|
@@ -16,6 +22,6 @@ public static NoOpConfigInversionMetricCollector getInstance() { | |
|
|
||
| @Override | ||
| public void setUndocumentedEnvVarMetric(String configName) { | ||
| // NOOP - do nothing | ||
| log.debug("Environment variable {} is undocumented", configName); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the circumstance where we would expect to have a NOOP implementation used? I would expect none, and if that's the case, should we log an error message saying that the actual implementation should be registered? 🤔
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So this PR came about because I was looking at recent debug logs and noticed a bunch of these messages: I tracked this back to the missing initialization in So I would argue we still need logging in the "no-op" implementation to help in the future, even if ideally that will never be called. I chose debug as that is less likely to cause disruption and is best suited for this kind of triaging. (I usually reserve use of warn/error for things that users need to know about and can fix themselves.) Also there may well be situations (build/tooling) where we don't have telemetry, but this debug logging would be useful - especially as we often have debug on in CI.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Makes sense, thanks for the info! |
||
| } | ||
| } | ||
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.
❓ If we register the Collector in
InstrumenterConfig, which gets initialized inConfig.java, should we remove the registration that already exists inConfig.java(ref)?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.
Also, out of curiosity, what is the added benefit of registering in
InstrumenterConfiginstead of justConfig?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.
See #9953 (comment) - without this registration config-inversion is not applied to
InstrumenterConfig, which means new integrations don't cause any CI alerts about documenting them - for example the 'hikari' and 'dbcp2' integrations.(This is because an instance of
InstrumenterConfigis created beforeConfig's static initializer runs.)In the future as
Configis broken apart there will hopefully be a better place to do this registration, but for now we have to do this in bothInstrumenterConfigandConfigto cover a couple of different user-cases.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.
Also I intentionally left the existing registration in
Configbecause a) it doesn't matter which runs first because the implementation is a singleton and b) if someone refactors this in the future then I think it's clearer to have both registrations in the codeEventually it would be nice have a clear place to register this kind of thing once - but right now there is this intentional split-brain situation between
InstrumenterConfig(controls instrumentation, baked into native images and not re-evaluated) andConfig(controls non-instrumentation, re-evaluated in native imeges)