opentelemetry-dotnet
opentelemetry-dotnet copied to clipboard
open-telemetry
Regression: Upgrading from OTel Exporters 1.0.0-rc9.4 to 1.0.0-rc9.5 and 1.0.0-rc9.6 results in `MethodAccessException`
Bug Report
@dependabot made the following upgrades to packages (all synced from a common Directory.Build.props variable) :
- Bumps
OTelExporterVersionfrom 1.0.0-rc9.4 to 1.0.0-rc9.5. - Updates OpenTelemetry.Extensions.Hosting from 1.0.0-rc9.4 to 1.0.0-rc9.5
- Updates OpenTelemetry.Instrumentation.AspNetCore from 1.0.0-rc9.4 to 1.0.0-rc9.5
- Updates OpenTelemetry.Instrumentation.Http from 1.0.0-rc9.4 to 1.0.0-rc9.5
- Updates OpenTelemetry.Instrumentation.SqlClient from 1.0.0-rc9.4 to 1.0.0-rc9.5
We're also using:
OpenTelemetry.Exporter.Jaeger 1.3.0 OpenTelemetry.Exporter.Prometheus 1.2.0-rc5
Runtime version: .NET Core & ASP.NET Core 3.1 / .NET & ASP.NET Core 6 .0
Symptom
.Configure(app =>
{
app.UseRouting();
app.UseOpenTelemetryPrometheusScrapingEndpoint(); // now throws a MethodAccessException under 1.0.0-rc9.5
app.UseEndpoints(endpoints =>
{
endpoints.MapGet("/", async context => await context.Response.WriteAsync("hi!"));
endpoints.MapControllers();
});
})
Throws the following error:
MethodAccessException: Attempt by method 'Microsoft.AspNetCore.Builder.PrometheusExporterApplicationBuilderExtensions.UseOpenTelemetryPrometheusScrapingEndpoint(Microsoft.AspNetCore.Builder.IApplicationBuilder, OpenTelemetry.Metrics.MeterProvider)' to access method 'System.ServiceProviderExtensions.GetOptions<OpenTelemetry.Exporter.PrometheusExporterOptions>(System.IServiceProvider)' failed.
Rolling those other packages back to 1.0.0-rc9.4 fixes the issue.
What is the expected behavior?
The Prometheus metrics endpoint should start up without issue and /metrics served correctly.
What is the actual behavior?
A crash that causes the ASP.NET process to exit.
Reproduce
https://github.com/Aaronontheweb/OTelAspNetReproduction/blob/master/OTelRepro/Program.cs <-- running this bare minimum dotnet new webapp ASP.NET 6.0 sample will reproduce the error.
This is bug is being thrown by the Prometheus exporter, but it looks like it was upgrading one of the other packages that created the issue - most likely the OpenTelemetry.Extensions.Hosting
Prometheus Exporter package has been split into two:
It will work fine if you use the AspNetCore package.
The error is due to the fact that Prometheus exporter packages rely on access to some internal methods of the OTel SDK. Starting 1.4.0-alpha.1 version of the OTel SDK, those internal methods are not exposed to the old "single" Prometheus exporter package.
since the version 1.0.0-rc9.5 and above the versioning is broken for me
Service
-> OpenTelemetry.Instrumentation.Http 1.0.0-rc9.5
-> OpenTelemetry (>= 1.4.0-alpha.1)
-> OpenTelemetry.Api (>= 1.4.0-alpha.1)
-> System.Diagnostics.DiagnosticSource (>= 6.0.0 && < 8.0.0)
the latest is resolved to 7.0.0-..., which is fatal for an app running with net6.0.
is it really needed, or can be downgraded, or conditionally compiled maybe?
the latest is resolved to 7.0.0-..., which is fatal for an app running with net6.0.
Not sure I follow this part... Can you clarify further what exactly is the issue?
despites from the suprising fact that rc depends on alpha? ^^
in short I have in obj/project.assets.json a System.Diagnostics.DiagnosticSource in a version 7.0.0-rc.1.22426.10. If I reference it explicitely in version 6.0.0, the app doesn't compile because of nuget downgrade.
For nuget seems to be obvious that if you have already non stable packages, the deps of them also should be resolved to last available non stable. But if you have to run it under net6.0 runtime, the app can't load the 7.0.0 dlls
Or its just my head not big enough to overcome this behavior ^^
System.Diagnostics.DiagnosticSource in a version 7.0.0-rc.1.22426.10. If I reference it explicitely in version 6.0.0, the app doesn't compile because of nuget downgrade.
This is suprising. You can use DS 7.* in a .NET 6.0 App. Is this causing an issue? Is that reproducible when you remove OTel things completely, and just add DS 7.*?
I think it can work, but I suspect any other dependency requires it to be of 6.0.0. Or maybe some conditional OTel target doesn't work as expected. Is referencing 7.0.0 really required by OTel? I really had enough hassle with nuget in my life, just downgraded to rc9.3 for now
Is referencing 7.0.0 really required by OTel?
Yes.
any other dependency requires it to be of 6.0.0
Can you given an example? Without giving specifics, we cannot suggest any workaround.
I really dont' know how to construct an example. My theory is here:
MyApp
-> MyAppDep
-> System.Diagnostics.DiagnosticSource 6.0.0
-> OTel rc
-> OTelDep alpha
-> System.Diagnostics.DiagnosticSource
^ declared (>= 6.0.0 && < 8.0.0) but wants 7.0.0
MyApp actually compiles with latest OTel rc, but exits at start with this output:
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
UPDATE, noticed 7.0.0.0 instead of 7.0.0-rc.1.22426.10
could be caused by jfrog?
Is referencing 7.0.0 really required by OTel?
Yes.
any other dependency requires it to be of 6.0.0
Can you given an example? Without giving specifics, we cannot suggest any workaround.
I am seeing exactly this issue too.
The original issue , which is about "app.UseOpenTelemetryPrometheusScrapingEndpoint();" throwing exception should be resolved with: https://github.com/open-telemetry/opentelemetry-dotnet/issues/3591#issuecomment-1238803913
Closing this issue with the above.
@AndyHutchND For other issues - please open a new issue with specifics, so we can triage and track it separately.