gertburger
Joined 18 years ago
Joined 18 years ago
> This Post violated the X Rules
If I recall the primary issue was the forced loading of the django settings file by otel.
I get that fully automated instrumentation should be turn-key and the current approach kinda works on basic applications.
But most production django applications are monoliths and generally larger apps. They have non-trivial configuration processes which are often multi step and source settings from multiple places.
Otel should not assume it can just randomly load a the django settings at an arbitrary time point in the startup process.
In one of our apps the MIDDLEWARE setting specifically is dynamically generated and re-ordered based on enabled features. That application's startup process also has multiple stages and the initialisation of django occurs much later, after dependant config loaders etc have been initialised.
What would allow us to integrate with opentelemetry-instrumentation-django much more easily is a set of smaller primitives that we can configure and call at the appropriate time.
opentelemetry-instrumentation-django has (had?) a lot of logic hidden inside a large "inject" function which could not easily be extracted into the constituent parts and applied in a compatible manner.
https://github.com/open-telemetry/opentelemetry-python-contr...
The only choices you get is full auto instrumentation, which breaks most non-trivial apps, or zero assistance/documentation.
There is no in-between where I can inject the functionality required in a way that is compatible with the application.
A checkout is a working space after all, why can't it be (temporarily) dirty whilst you work?
This forced me to dual stack just for AWS services to intercommunicate...
Why would it want access to view AND MANAGE my contacts? This seems a bit odd.