OTel isn't going well (and I made a spreadsheet about it)

bilalq 21 minutes ago | parent | next [-]

OTel is so frustrating. If it wasn't shaping to be the clear winner in the space, I wouldn't complain about it as much. But today:

1. Every major vendor is still in some weird alpha/beta support for OTel even after all this time.

2. The performance hit is substantial and makes you question what the point of performance instrumentation is if you need twice as much compute/RAM to run the same workload now.

3. Serverless runtimes pay a heavy penalty for cold starts with OTel.

4. You're basically forced to run both gateway collectors and edge collectors for any realistic usage.

5. You still need to configure destination exporters in unique ways. This leaves you questioning what the value of OTel was.

6. Vendors that go beyond the scope of what OTel covers still need their own bespoke instrumentation. What was the point of any of this then?

▲

brikym 6 hours ago | parent | prev | next [-]

I've never found instrumentation to be a huge issue. Sure it takes more effort but you get a lot more value once you understand _business_ events.

▲

hn_acker 9 hours ago | parent | prev | next [-]

(TFA author is not me.)

▲

jiggawatts 2 hours ago | parent | prev [-]

The alternative is vendor lockin, $$$, and spotty support for complex environments with zero chance of ever getting 100% coverage.

At least with Open Telemetry, anyone can write an OTLP "source" using free, open specifications, and it'll "just work" with dozens of third-party "sinks". That's huge!

Sure, there's a lot of experimental tags on semantic conventions, but at the end of the day, that's not that critical. It's just data: most sinks don't "interpret" these tags, they just display them as-is, so changes aren't breaking changes.

▲

GauntletWizard 44 minutes ago | parent [-]

The alternative is Prometheus (which is freaking great) and Jaegar (which is freaking great), each alone. This is better, because Otel is trying to put two distinct things (monitoring and metrics, distributed tracing) into one package, because they know how to use neither.

Neither Prometheus metrics nor Jaeger traces are magic bullets. Neither of them are complicated, either, and in fact the fact that they're not complicated is their greatest strength. You can and should understand every facet of what they entail. You should build the (very small) shims that they need for your company's framework every time. It's not hard. It's not hard because it's not complicated. The fact that it's not complicated seems to break people's brains. They are accurate because they're simple and they're easy to work with because they're simple, and OTel is neither.

	▲	firesteelrain 26 minutes ago \| parent [-]
		I’ve built custom Prometheus metrics very easily and had node exporter pick up the .prom files. Python and bash scripts reading and translating. Node exporter runs on my Prometheus server next to Blackbox Exporter. Blackbox Exporter handles TLS expiry metrics.