[bug] Enabling SuppressDownstreamInstrumentation can sometimes in certain conditions disable ILogger

[michaeldimoudis]

Package

OpenTelemetry

Package Version

Package Name	Version
OpenTelemetry.Api	1.9.0
OpenTelemetry	1.9.0
OpenTelemetry.Instrumentation.AWS	1.1.0-beta.6

Runtime Version

net48

Description

Hi, I just want to record a very weird bug that only happens in certain conditions.

We have some very old .NET Framework background services. The DI used is Ninject.

We have added OpenTelemetry, with Microsoft.Extensions.Logging, and hooked it all up so we can use LoggerFactory.Create() with OpenTelemetry and inject ILogger<ClassName>.

This all works on basically all of our legacy .NET Framework ASP.NET and various background services.

However we have 1 particular background service with a very weird issue. We do add the AddAWSInstrumentation() to Tracing, and whenever we set SuppressDownstreamInstrumentation = true, after the first 1 or 2 logs or written to, ILogger gets disabled (as per screenshot).

For this 1 background service, this is consistanly the case, however we have never experienced this in our .NET Framework ASP.NET web applications or some other background services, even though they are all bootstrapped the same and using the same code.

I tried to look into the OpenTelemetry source code, but could not find any correlation.

Steps to Reproduce

Setting SuppressDownstreamInstrumentation = true, after a while ILogger<ClassName> gets disabled. Not setting that property to true, ILogger<ClassName> never gets disabled.

Expected Result

For ILogger<ClassName> to not get disabled when SuppressDownstreamInstrumentation = true.

Actual Result

ILogger<ClassName> gets disabled when SuppressDownstreamInstrumentation = true and after the first log is written.

Additional Context

Old legacy .NET Framework code using Ninject, and only happens on 1 particular service even though we have other services bootstrapped the exact same way...

All I am expecting in this bug report is if a) someone else stumbles into this problem, and b) if a maintainer closer to the code has a light bulb moment that might know how and why this can occur.