[AzureMonitorAutoConfigure] Honor SDKStats disable-all for regular Statsbeat - #50382
Conversation
…atsbeat Resolve the all-disable setting once during initialization and skip both customer SDKStats and regular Statsbeat startup, including exporter disk retry tasks. Preserve public-disable behavior and application telemetry. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: Successfully started running 1 pipeline(s). 34 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
🟡 Changes recommended
A new test shuts down a different span exporter instance than the one used by the tracer provider, which can hide lifecycle issues and should be corrected before approval.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR completes the “SDKStats disable-all” startup behavior in azure-monitor-opentelemetry-autoconfigure so that APPLICATIONINSIGHTS_SDKStats_DISABLED_ALL suppresses both customer-facing SDKStats and internal Statsbeat startup (including Statsbeat exporter construction/background tasks), while retaining the Statsbeat module needed for trace export.
Changes:
- Resolve the all-disable flag once during initialization and reuse it for both customer SDKStats and internal Statsbeat startup gating.
- Add/expand tests to cover precedence, case-insensitive values, startup suppression side-effects (threads/directories), and continued application span export.
- Update changelog to document the bug fix.
File summaries
| File | Description |
|---|---|
| sdk/monitor/azure-monitor-opentelemetry-autoconfigure/src/main/java/com/azure/monitor/opentelemetry/autoconfigure/AzureMonitorExporterBuilder.java | Compute SDKStats all-disable once and skip internal Statsbeat startup when enabled. |
| sdk/monitor/azure-monitor-opentelemetry-autoconfigure/src/test/java/com/azure/monitor/opentelemetry/autoconfigure/AzureMonitorExporterBuilderTest.java | Add tests validating disable-all precedence and that Statsbeat startup side effects are suppressed. |
| sdk/monitor/azure-monitor-opentelemetry-autoconfigure/src/test/java/com/azure/monitor/opentelemetry/autoconfigure/AzureMonitorStatsbeatTest.java | Parameterize Statsbeat test scenarios to validate combinations of local/global/public disable settings. |
| sdk/monitor/azure-monitor-opentelemetry-autoconfigure/CHANGELOG.md | Document the internal Statsbeat suppression under SDKStats all-disable. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 75d7bae6-73a7-4fdc-b4a9-d9362fd2053b
Description
Complete the startup all-disable behavior introduced by #49451. The setting previously disabled customer-facing SDKStats but left regular Statsbeat running.
Resolve the existing all-disable value once during initialization and use it for both customer SDKStats and regular Statsbeat. Skip the entire regular Statsbeat startup path, including exporter construction, so disk retry/cleanup tasks and metadata polling are not started either. Retain the Statsbeat object needed by trace export.
Preserve existing lookup precedence and case handling, default-enabled behavior, customer-only public disable, application telemetry, Live Metrics, and heartbeat. This is a startup-only change; runtime/no-restart toggling is outside scope. Related to #46769.
Validation: 44 targeted tests passed, along with Checkstyle and SpotBugs. Coverage includes real startup suppression, no stats-specific worker threads or storage setup, continued application span export, defaults, mixed-case true/false, global fallback and explicit-value precedence, and public disable leaving regular Statsbeat enabled. The startup regression fails when the original unconditional startup is restored.
No SDK regeneration or API changes.
All SDK Contribution checklist:
General Guidelines and Best Practices
Testing Guidelines