viraptor 2 days ago

You can do almost 1:1 the same thing (compared to the post) in Python and use it as a wsgi/whatever middleware. It's really not any different. The callback changes to a resource manager, but that's about it.

etimberg 2 days ago

Agreed. There are a ton of edge cases and auto instrumentation basically doesn't work. I love Honeycomb but the setup for DataDog is 100x easier

tempest_ 2 days ago

Sentry has been nice.

I do not know what unholy monkey patching they do with that sentry_sdk.init call and I try not to think about it but for web apps it is fire and forget.

rtpg 2 days ago

Honeycombs old tooling for Python was miles better than the Otel nonsense. Embarrassing to see so many companies drop their well designed libs for Otel instead of something like wrapping Otel so that their better libs can still be used at the top level

jgalt212 2 days ago

Is that because js is inherently async, and Python is synchronous?

  • phillipcarter 2 days ago

    The python problems with opentelemetry are mostly due to python being a bit of a mess. Yes, the async model is weird and that in turn makes it harder to instrument compared to something like .NET. But then the combination of libraries and environments change out from under you, you update your autoinstrumentation agent, and now the app crashes. And you find some GitHub issue saying that flask brings in this new dependency that somehow breaks something else and so now you can't instrument flask apps.

    ^^^ most of the above is just what I've dealt with as a maintainer in OTel, and it's maddening. FWIW that's all been finally dealt with, but python just feels like something ready to keel over at a moment's notice to me. Far more fragile a language and ecosystem than anything else.

    • krashidov 2 days ago

      Agreed. This could be a personal skill issue, but I've started a new job where Django is the main codebase and getting decent OTel has been a struggle.

      In fact, everything with Python has been a struggle