Django instrumentation competes with django-configurations

[PeterJCLaw]

Describe your environment

Python 3.11, Django 4.1, django-configurations 2.4

Steps to reproduce

DjangoInstrumentor's instrumentation logic calls Django's settings.configure() method if settings are not already present, meaning that in projects which manage their own settings configuration it must be run after the settings have already been loaded. django-configurations is an example of one such settings management approach.

What is the expected behavior?

Ideally DjangoInstrumentor wouldn't try to force Django settings, instead allowing the Django project to handle this itself and then performing the relevant instrumentation as part of Django's app ready hooks.

Currently I'm importing django-configurations so that it can do its thing first and then running the auto-instrumentations I want. I'm not sure yet what impact this is having on the metrics I'll get/what I'm losing from the auto-instrumentation as a result.

Certainly this means that using the opentelemetry-instrument CLI wrapper isn't an option.

If Django's ready hooks aren't sufficient then an alternative here might be to move much of the logic contained within DjangoInstrumentor._instrument() to being separate helpers, so that projects which have more complex settings arrangements can still make use of the other parts of the auto-instrumentation.

What is the actual behavior?

If auto-instrumentation of Django is run first, which seems to be what's expected, then any attempted use of any Django settings (including by Django itself) fails (with an AttributeError) as the settings object has not been correctly populated.

[lzchen]

Transferring to contrib

[yashaswi2000]

Hii, would like to take this up