News for hackers. Stuff that matters.
Re:OpenTelemetry Tracing in < 200 lines of code by krashidov on Tuesday September 17, 2024 @07:01PM (#41573813)
It's so easy in node. I miss node.

Setting this up in the mess that is Python/Gunicorn/asgi/wsgi/celery/Django has not been as easy

Re:OpenTelemetry Tracing in < 200 lines of code by tempest_ on Tuesday September 17, 2024 @09:30PM (#41574789)
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.

Re:OpenTelemetry Tracing in < 200 lines of code by krashidov on Wednesday September 18, 2024 @03:37AM (#41576881)
hmm do you use Sentry for logging? We use sentry as well but only for errors. Also the trace ids don't match with the logging traces so I have to fix that too
Re:OpenTelemetry Tracing in < 200 lines of code by optiomal_isgood on Wednesday September 18, 2024 @05:38AM (#41577687)
> I do not know what unholy monkey patching they do

A year ago I had to patch its package for an internal use case. Their codebase is fairly well-written I thought (at least the JS SDK).

e.g. this is where they add the `fetch` breadcrumb https://github.com/getsentry/sentry-javascript/blob/develop/...

e.g. where the actual monkey patching happens https://github.com/getsentry/sentry-javascript/blob/e1783a65...

Re:OpenTelemetry Tracing in < 200 lines of code by tempest_ on Wednesday September 18, 2024 @06:04PM (#41586064)
My experience in principally in python and the number of integrations that are auto used on common dependent libs and frameworks is long https://docs.sentry.io/platforms/python/integrations/
Re:OpenTelemetry Tracing in < 200 lines of code by viraptor on Tuesday September 17, 2024 @10:19PM (#41575061)
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.
Re:OpenTelemetry Tracing in < 200 lines of code by rtpg on Wednesday September 18, 2024 @04:13AM (#41577136)
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
Re:OpenTelemetry Tracing in < 200 lines of code by jgalt212 on Wednesday September 18, 2024 @05:30AM (#41577642)
Is that because js is inherently async, and Python is synchronous?
Re:OpenTelemetry Tracing in < 200 lines of code by phillipcarter on Wednesday September 18, 2024 @10:02AM (#41579855)
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.

Re:OpenTelemetry Tracing in < 200 lines of code by krashidov on Wednesday September 18, 2024 @12:27PM (#41581980)
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

Re:OpenTelemetry Tracing in < 200 lines of code by etimberg on Wednesday September 18, 2024 @09:58AM (#41579822)
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