8 ms·

I've found their django instrumentation to be kinda useless for larger apps. The only choices you get is full auto instrumentation, which breaks most non-trivi

I've found their django instrumentation to be kinda useless for larger apps. 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.

rm 26d ago
Could you please elaborate a bit on what is not working for you?
- gertburger 26d ago
  (I haven't attempted to use opentelemetry-instrumentation-django in at least a year so my information might be dated and my memory is patchy :P) 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-contrib/issues/2301 https://github.com/open-telemetry/opentelemetry-python-contr...
  - rm 26d ago
    Thanks for the write up, appreciated. A couple of things: - users are not forced to use auto-instrumentation. People can import the Middleware and use it as they see fit. I see that the instrumentor is configuring the middleware using some private attributes, I guess that can be extracted into a public function so it would be easier to do so - speaking of the middleware, the chances that it'll become a public symbol are scarce as are the chances that the interfaces will change. So if one has some testing before going to production it should be fine
nunez 26d ago
Not the OP, but turning on auto-instrumentation for a Golang app running in Kubernetes breaks the app if the app is either: - Running an old version of Golang (older than 1.18 if memory serves), or - has libraries that the eBPF probes don't like. And while I like OTel, I agree with the OP that you are absolutely going deep-sea diving if you're going to do anything beyond the examples provided (which is very easy to do!)

rm 26d ago

Could you please elaborate a bit on what is not working for you?

gertburger 26d ago
(I haven't attempted to use opentelemetry-instrumentation-django in at least a year so my information might be dated and my memory is patchy :P) 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-contrib/issues/2301 https://github.com/open-telemetry/opentelemetry-python-contr...
- rm 26d ago
  Thanks for the write up, appreciated. A couple of things: - users are not forced to use auto-instrumentation. People can import the Middleware and use it as they see fit. I see that the instrumentor is configuring the middleware using some private attributes, I guess that can be extracted into a public function so it would be easier to do so - speaking of the middleware, the chances that it'll become a public symbol are scarce as are the chances that the interfaces will change. So if one has some testing before going to production it should be fine

nunez 26d ago

Not the OP, but turning on auto-instrumentation for a Golang app running in Kubernetes breaks the app if the app is either: - Running an old version of Golang (older than 1.18 if memory serves), or - has libraries that the eBPF probes don't like. And while I like OTel, I agree with the OP that you are absolutely going deep-sea diving if you're going to do anything beyond the examples provided (which is very easy to do!)