Recommend installing `opentelemetry-instrumentation-asgi` under certain situations (opentelemetry-instrumentation-django)

[nenoNaninu]

trafficstars

Description

When I added the opentelemetry-instrumentation-django package and started the server with python manage.py runserver calling DjangoInstrumentor().instrument() in manage.py, inbound HTTP request spans were correctly created.

However, when using Django with Gunicorn, there was a problem: inbound HTTP request spans were not created. To solve this problem, I spent a lot of time reading the opentelemetry-instrumentation-django code and found that adding opentelemetry-instrumentation-asgi would solve this problem. I have arrived at the solution.

The current implementation silently turns off instrumentation in certain situations, such as using Gunicorn.

Instrumentation library users will expect the instrumentation to work correctly if the call to DjangoInstrumentor().instrument() succeeds and there are no warnings in the logs. Also, the documentation does not mention the need to add opentelemetry-instrumentation-asgi.

• https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html
• https://opentelemetry-python.readthedocs.io/en/latest/examples/fork-process-model/README.html

This wastes a lot of time for many developers. Therefore, I have added a log that shows how to deal with this problem instead of silently disabling instrumentation when it occurs.

Related: #2043 #2296

Type of change

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

How Has This Been Tested?

• No test, because only adding log.

Does This PR Require a Core Repo Change?

• [x] No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

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

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: nenoNaninu / name: nenoNaninu (71e4ec83b1acb4daa409db6c289f90a9b8b95401, 48cd643ffed0b3dfb1d09a12dab88ef75f817251, d40b00505ca70890bfee9a26f00923f9c171d2fc)

[xrmx]

Thanks for the PR, care to add a test too?

[nenoNaninu]

Is it essential to add test code to add a mere line of logging?

[xrmx]

Is it essential to add test code to add a mere line of logging?

It's not essential of course, but it'll help :)

[nenoNaninu]

If a test code is not essential, please review as is.

[srikanthccv]

I don't think we should log such a warning more than once. Please use warnings.warn instead.

[nenoNaninu]

If developers are using manage.py runserver in a local dev environment, it will probably output plain text logs, so warnings.warn will not be a problem. However, this problem only occurs when Django is started using like gunicorn. And it's not the local development environment that uses gunicorn etc.; it's the stg environment. The stg environment uses structured logs in most cases. So, it is easier to find the problem if the developer has a structured warning log using logger.warning rather than warnings.warn. I don't think it's worth throwing away the structured logs to warn only once.

Moreover, if multiple workers run using gunicorn, the warnings will be logged more than once even if we use warnings.warn.

[xrmx]

Moreover, if multiple workers run using gunicorn, the warnings will be logged more than once even if we use warnings.warn.

This will warn at each request not for each worker

[nenoNaninu]

This will warn at each request not for each worker

Of course, I know.

[nenoNaninu]

@srikanthccv @ocelotl I fixed to log a warning only once.