-
Notifications
You must be signed in to change notification settings - Fork 765
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
[api+sdk] Groundwork for cross-cutting builder extensions #5265
[api+sdk] Groundwork for cross-cutting builder extensions #5265
Conversation
…ng extensions into SDK.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #5265 +/- ##
==========================================
- Coverage 83.38% 83.04% -0.35%
==========================================
Files 297 273 -24
Lines 12531 11982 -549
==========================================
- Hits 10449 9950 -499
+ Misses 2082 2032 -50
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
LGTM.
This is not yet released see open-telemetry/opentelemetry-dotnet#5265 for more background. For now we include a temporary copy with hacks to call internal bits. This allows AgentBuilder to be a native opentelemetry builder and we'd inherit all extension methods from the OpenTelemetry community
* Move our AgentBuilder to IOpenTelemetryBuilder This is not yet released see open-telemetry/opentelemetry-dotnet#5265 for more background. For now we include a temporary copy with hacks to call internal bits. This allows AgentBuilder to be a native opentelemetry builder and we'd inherit all extension methods from the OpenTelemetry community * clean up AddElasticOpenTelemetry()
* Move our AgentBuilder to IOpenTelemetryBuilder This is not yet released see open-telemetry/opentelemetry-dotnet#5265 for more background. For now we include a temporary copy with hacks to call internal bits. This allows AgentBuilder to be a native opentelemetry builder and we'd inherit all extension methods from the OpenTelemetry community * clean up AddElasticOpenTelemetry() * stage * add netstandard2.0 and 2.1 * add net462 * add net6.0 * update release folder name now that we have multiple TFMs * rename TraceParentRe
Could the migration path be clarified? I currently have this, to set up telemetry with HotChocolate, as explained a few snippets down from this heading: builder.Services
.AddOpenTelemetry()
.WithTracing(fun b ->
b.AddHotChocolateInstrumentation().SetResourceBuilder(otlResourceBuilder)
|> ignore
let connStr =
builder.Configuration.GetValue<string> "APPLICATIONINSIGHTS_CONNECTION_STRING"
if not (String.isNullOrEmpty connStr) then
b.AddAzureMonitorTraceExporter(fun o -> o.ConnectionString <- connStr) |> ignore
|> ignore
)
|> ignore After updating |
Wondering the same thing as @cmeeren. Any advice would be appreciated, @CodeBlanch :) |
@cmeeren @StachuDotNet This is interesting. It seems the same code in C# works fine but for some reason with F# it warns. I added this to discuss on our SIG meeting today. I'm considering just removing the obsoletion. I'll report back after our discussion. |
Relates to #5137
Changes
IOpenTelemetryBuilder
in API (extensions).IOpenTelemetryBuilder
extensions in SDK which now drive the "With" operations we have today.Details
The goal is to allow components to author extensions which target all signals (see #4940):
We don't want to force things to take a dependency on
OpenTelemetry.Extensions.Hosting
to do this. This is whyIOpenTelemetryBuilder
has been introduced.We don't want to force things to take a dependency on SDK to do this. This is why
IOpenTelemetryBuilder
is going intoOpenTelemetry.Api.ProviderBuilderExtensions
.The "With" extensions in SDK are being added to handle "type switching" which will result anytime a cross-cutting extension is invoked:
Today:
Future:
A secondary goal this also lays groundwork for is to offer a new bootstrap pattern for .NET Framework (really manual/non-host sdk management) which uses the "With" pattern our hosting package offers. This was explored a bit on #5137 and mentioned here. That pattern is more concise, allows the cross-cutting extensions to be used more widely, and (hopefully) simplifies our documentation.
Public API Changes
Merge requirement checklist
Unit tests added/updatedThere are existing unit tests in Hosting for the extensions being added to SDK. I decided to leave them there for now. They really should be moved into the SDK tests now but that is going to take some refactoring. I'll do that separately so as to not explode the diff.CHANGELOG.md
files updated for non-trivial changes