Filter duplicate logs out of some logger's logs that might otherwise endlessly log

[DylanRussell]

Description

Filter duplicate logs out of some logger's logs on the export logs path that might otherwise endlessly log or cause a recursion depth exceeded issue in cases where logging itself results in an exception.

Fixes #4688
Fixes #2701
Fixes #4323

Type of change

Please delete options that are not relevant.

• [x ] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Unit tests

Does This PR Require a Contrib Repo Change?

• [x ] No.

Checklist:

• [ x] Followed the style guidelines of this project
• [ x] Changelogs have been updated
• [ x] Unit tests have been added
• [ x] Documentation has been updated

[emdneto]

Left comment

[cijothomas]

Isn't context based suppression the right way to prevent self-logging?
https://github.com/open-telemetry/opentelemetry-python/blob/main/opentelemetry-sdk/src/opentelemetry/sdk/metrics/_internal/export/__init__.py#L546

[DylanRussell]

I don't think we want to suppress it entirely.. just stop it from endlessly logging // going into the recursive loop...

Also how does that suppression key work exactly ? I couldn't figure it out, and I'm not sure it covers all the scenarios..

[cijothomas]

Isn't the issue about "telemetry-induced-telemetry", where the act of exporting a telemetry triggers the creation of another telemetry? If yes, contextual suppression would be the best solution from my understanding..

(Sorry I am not familiar with this repo, but working on similar problem in other OTel languages, and found this PR!)

[DylanRussell]

Currently in auto instrumentation any call to the logging module in python gets picked up the OTLP root logging handler and exported as a OTLP LogRecord. There is an environment variable to disable that behavior entirely: _OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED

But the issue reported that I am fixing is when we internally invoke the logging module because the logs exporter is down / failed, and that results in an endless stream of logs or a recursive overflow.. I think we do generally want our own internal calling of the logging module to result in an OTLP log export..

[emdneto]

If we suppress, there won't be any feedback to the user