Document that AddOpenTelemetryProvider does not register default instrumentation or exporters#8930
Open
Evangelink wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).
Changes:
- Auto-registers MTP tracing/metrics instrumentation (
Microsoft.Testing.Platform) insideOpenTelemetryProviderprior to invoking user configuration delegates. - Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
- Simplifies the public sample by removing redundant
AddTestingPlatformInstrumentation()calls.
Show a summary per file
| File | Description |
|---|---|
| src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs | Adds .AddSource(...) and .AddMeter(...) by default so zero-config calls actually instrument MTP telemetry. |
| src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs | Updates XML docs to reflect auto-wiring and clarify what callers still must configure. |
| src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md | Updates package docs to describe exporter responsibility and the zero-config behavior more accurately. |
| samples/public/MTPOTel/Program.cs | Removes redundant instrumentation calls to demonstrate the simplified API surface. |
Copilot's findings
- Files reviewed: 4/4 changed files
- Comments generated: 2
Comment on lines
+29
to
+30
| /// be added by the caller via <paramref name="withTracing"/> and <paramref name="withMetrics"/>; without an | ||
| /// exporter, telemetry is collected but not emitted anywhere.</remarks> |
| - **Observability**: enables you to route test execution data, via your own OpenTelemetry exporter configuration, into observability backends (e.g. Jaeger, Prometheus, Grafana) | ||
| - **Standards-based**: leverages the OpenTelemetry .NET SDK so that data is sent only to the telemetry exporters and endpoints that you configure | ||
|
|
||
| > Note: this package does not register any exporter by default. Without one, traces and metrics are still collected but are not emitted anywhere — add an exporter (for example `AddOtlpExporter`, `AddConsoleExporter`, or a vendor-specific exporter) via the `withTracing` and `withMetrics` delegates of `AddOpenTelemetryProvider`. |
…TelemetryProvider Fixes microsoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Evangelink
force-pushed
the
dev/amauryleve/fix-otel-default-instrumentation
branch
from
7630129 to
59104d9
Compare
Evangelink
changed the title
Member
Author
|
Filed #8931 to track the Roslyn analyzer follow-up (warn when |
Evangelink
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #8409.
Problem
AddOpenTelemetryProviderdocumented that omittingwithTracing/withMetricswould use "default OpenTelemetry settings", but it actually built emptyTracerProvider/MeterProviderinstances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path —builder.AddOpenTelemetryProvider();produced no MTP telemetry.Approach
Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a
Program.csto wire exporters either way, so the convenience gain was small.OpenTelemetryProviderExtensions.cs: XML docs onAddOpenTelemetryProvidernow state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, includingAddTestingPlatformInstrumentation()to subscribe to MTP.AddTestingPlatformInstrumentationdocs describe both use sites (inside the delegates and on aTracerProviderBuilder/MeterProviderBuilderconfigured outside the helper).PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.No public API surface change, no runtime behavior change — docs and sample only.
Verification
Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.