> OpenTelemetry is a project that aims to standardize all telemetry collection, but by trying to please everyone and make something idiomatic for all languages the result is a bit of a hot mess.
Huh. I’m glad it isn’t just me. I’ve fallen over OT more than a few times. Sometimes seemingly trivial things would take embarrassingly large amounts of trial and error, and I’d often be left with the sense that I’m not totally clear on what I’m doing, why, and if my solutions are correct for the logging I want to do.
I’m perfectly willing to admit that I don’t know what I’m doing, but I guess in some sense I’m glad I’m not the only one.
One time I needed to deploy a rust-based api that serviced a React-based front end, and getting telemetry to work across both on GCP was a hellish nightmare. By the end I sincerely didn’t know why it started working. Dark times.
I've been heel dragging for over a year on OpenTelemetry for this reason. The org doesn't need it either. They saw something shiny and want it for no rational reason other than they think everyone else is doing it.
Realistically they need to focus that energy on more important things like maintenance and quality rather than shovelling more crap into the inferno that has to be maintained.
Good telemetry is an absolute game changer to be fair.
The annoying thing about OpenTelemetry is just how underbaked/rudimentary it is, and how opinionated the implementations are.
For C#, I consider Microsoft's Application Insights to be the gold standard. You get per request tracing, stack traces, hot paths, dependency operations etc. with absolutely no setup on your part.
I was looking for an alternative since my current place is on AWS and OpenTelemetry seemed like a flexible, Terraform-like alternative to the platform specific SDKs.
It's not that simple though... AWS doesn't provide any direct sinks to their services, instead you must send it to a collector running in a sidecar container, or if it's a lambda: create a custom layer.
X-Ray's surfacing of the traces sucks as well. It'll only show traces in 6 hour ranges. Hopping between 5 different products trying to find the right metric is not an enjoyable experience.
Reasonable telemetry i.e. logging which can be correlated across services, is probably good enough. I think we're hitting 15,000 logs a second so even sampling OT becomes financially infeasible.
I see it's because they use their own config loader library that uses hujson. Why even use the human-unfriendly JSON format if you're also going to make it machine-unfriendly by not conforming? If nothing else, why not at least acknowledge that in the documentation which still calls it JSON? If this is what Grug Brained development looks like, they can keep it.
The json parsing library that parses the config file allows either syntax. That was intentional since we get in the habit as go programmers of ending lines in structs/maps with commas, it's just for convenience.
Serious question though, why use "JSON" at all then? You can just admit it's JWCC, which is fine, at least that's a distinct term -- but even that's not a spec, it's just a blog post that very few people even know about. Even that same blog post endorses using TOML, the spec generally preferred for things that may need to be human-edited. It meets humans half-way a lot better than even JWCC, which is the kind of practicality I think even Grug would prefer.
Based on the people listed as contributers to Kawa, I see several Polish people there. Perhaps they chose that name intentionally because both Java and Kawa has the same coffee connection?
That's a bit more challenging since Google didn't exist yet when Polish people started using the word kawa. On the other hand there were certainly people around who knew.
Yes, why people don't think to check and change this, for their own project's visibility/searchability, shows how bad people are at PR / window dressing.
Huh. I’m glad it isn’t just me. I’ve fallen over OT more than a few times. Sometimes seemingly trivial things would take embarrassingly large amounts of trial and error, and I’d often be left with the sense that I’m not totally clear on what I’m doing, why, and if my solutions are correct for the logging I want to do.
I’m perfectly willing to admit that I don’t know what I’m doing, but I guess in some sense I’m glad I’m not the only one.
One time I needed to deploy a rust-based api that serviced a React-based front end, and getting telemetry to work across both on GCP was a hellish nightmare. By the end I sincerely didn’t know why it started working. Dark times.