Using get_tracer removes all warnings filters

[rafikdraoui]

In #3041, a DeprecationWarning is ignored by adding a temporary warning filter and then later using warnings.resetfilters to remove it. However, warnings.resetfilters seems to clear every filters, including the default ones. This means that instrumenting code can enable noisy warning logging that is usually suppressed by default.

There is a context manager that can be used for temporarily changing the warning filters (https://docs.python.org/3/library/warnings.html#warnings.catch_warnings), but its documentation mentions that it is not thread-safe, so it maybe it wouldn't be appropriate for this library...

---

Describe your environment
Python 3.10, macOS and Linux (via Docker), otel-python v1.15.0 & 0.36b0

Steps to reproduce
Using the example Django app in this repo

1. Modify the view to emit a (normally ignored) warning and to log the current filters

diff --git a/docs/examples/django/pages/views.py b/docs/examples/django/pages/views.py
index e805f4318..8f9e3bdd8 100644
--- a/docs/examples/django/pages/views.py
+++ b/docs/examples/django/pages/views.py
@@ -28,4 +28,8 @@ trace.get_tracer_provider().add_span_processor(


 def home_page_view(request):
+    import warnings
+    warnings.warn("hello", ResourceWarning)
+    print("--- warnings.filters ---")
+    print(warnings.filters)
+    print("------------------------")
     return HttpResponse("Hello, world")

2. Start the server with python manage.py runserver --noreload

3. Open http://127.0.0.1:8000/,

4. Stop the server with ctrl-c

We see the following in the console:

With instrumentation:

...
~/.../opentelemetry-python/docs/examples/django/pages/views.py:32: ResourceWarning: hello
  warnings.warn("hello", ResourceWarning)
--- warnings.filters ---
[]
------------------------
[21/Dec/2022 12:34:56] "GET / HTTP/1.1" 200 12
{
  ... // otel trace
}
^Csys:1: ResourceWarning: unclosed <socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 8000)>
ResourceWarning: Enable tracemalloc to get the object allocation traceback

Without instrumentation (i.e. commenting out DjangoInstrumentor().instrument() in manage.py)

...
--- warnings.filters ---
[('default', None, <class 'DeprecationWarning'>, '__main__', 0), ('ignore', None, <class 'DeprecationWarning'>, None, 0), ('ignore', None, <class 'PendingDeprecationWarning'>, None, 0), ('ignore', None, <class 'ImportWarning'>, None, 0), ('ignore', None, <class 'ResourceWarning'>, None, 0), ('ignore', None, <class 'pkg_resources.PEP440Warning'>, None, 0)]
------------------------
[21/Dec/2022 12:34:56] "GET / HTTP/1.1" 200 12
^C 

Additional context

The default warnings filters are preserved when using versions 1.14.0 and 0.35b0.

[ccorbacho]

Just to add on this - this is actually quite a major regression.

For those of us where we are using third party services to process our logs, and at scale, activating all the deprecation warnings over a huge number of containers is causing a massive increase in the number of log lines being emitted from applications, which in turn pushes up our costs considerably (as these services will charge per lines of logs ingested), so we had to rollback to 1.14.0 and cannot upgrade until this is fixed.

(I suspect this may impact others in a similar situation - but even without a cloud vendor, it's now a huge amount of extra lines of logs having to be processed with all the deprecation warnings being emitted, so all the associated storage and CPU costs).

If this is going to take a long time to fix in a safe and proper way, can you revert the original change until then, as calling resetfilters() and turning on all the deprecation warnings is far more problematic than the original bug you were trying to fix?

[jeremydvoss]

I'm also getting this "ResourceWarning: unclosed" warning. Regardless of warning filtering, the memory allocation issue seems like something we should fix in general. The flask instrumentation seems to be the source of the issue for me.

Do we think this warning always existed but was simply filtered out before #3041 ?

EDIT: This issue of mine seems to be resolved with the revert of #3041, #3157

[samsamoa]

workaround:

def dont_reset_warnings():
    pass

warnings.resetwarnings = dont_reset_warnings

[srikanthccv]

This is fixed in 1.16