[HN Gopher] OpenTelemetry and vendor neutrality: how to build an...
___________________________________________________________________
OpenTelemetry and vendor neutrality: how to build an observability
strategy
Author : meysamazad
Score : 37 points
Date : 2024-09-15 14:05 UTC (3 days ago)
(HTM) web link (grafana.com)
(TXT) w3m dump (grafana.com)
| nicholasjarnold wrote:
| I can confirm that this is a pretty good way. Building out a
| basic distributed tracing solution with OTEL, jaeger and the
| relevant Spring Boot configuration and dependencies was quite a
| pleasant experience once you figure out the relevant-for-your-
| use-cases set of dependencies. It's one of those nice things that
| Just Works(tm), at least for Java 17 and 21 and Spring Boot 3.2
| (iirc) or greater.
|
| There appeared to be wide array of library and framework support
| across various stacks, but I can only attest personally to the
| quality of the above setup (Java, Boot, etc).
| ljm wrote:
| > once you figure out the relevant-for-your-use-cases set of
| dependencies
|
| > It's one of those nice things that Just Works(tm)
|
| did it Just Work(tm) or did you have to do work to make it Just
| Work(tm)?
| barake wrote:
| Java has really good OTel coverage across tons of libraries.
| It should mostly Just Work(tm), though you'll still need to
| consider sampling strategies, what metrics you actually want
| to collect, etc.
|
| Would say .NET isn't too far behind. Especially since there
| are built-in observability primitives and Microsoft is big on
| OTel. ASP.NET Core and other first party libraries already
| emit OTel compliant metrics and traces out of the box.
| Instrumenting an application is pretty straightforward.
|
| I have less experience with the other languages. Can say
| there is plenty of opportunity to contribute upstream in a
| meaningful way. The OpenTelemetry SIGs are very welcoming and
| all the meetings are open.
|
| _Full disclosure: work at Grafana Labs on OpenTelemetry
| instrumentation_
| roshbhatia wrote:
| In my experience, it just worked -- I was at an org that ran
| 3rd party java services alongside our normal array of
| microservices (that all used our internal instrumentation
| library that wrapped OTEL) and using the OTEL
| autoinstrumentation for those 3rd party services was pretty
| trivial to get setup and running (just wrap the command to
| run the app with the OTEL wrapper, hand it a collector url.)
| Granted -- we already had invested in OTEL elsewhere and were
| familiar with many of the situations in which it didn't just
| work.
| azthecx wrote:
| I had a very similar experience with a Quarks REST API where
| it's supported very well out of the box, we just had to point
| it to the appropriate otel collector endpoint and traces are
| created or propagated automatically.
| kbouck wrote:
| For anyone that has built more complex collector pipelines, I'm
| curious to know the tech stack: - otel collector?
| - kafka (or other mq)? - cribl? - vector? -
| other?
| azthecx wrote:
| What sort of complexity do you need? I've used them on my
| previous job and am implementing it on the current one. I have
| never heard of the last three you mention.
|
| Otel collector is very useful for gathering multiple different
| sources, eg I am at a big corporation and we both have
| department level Grafana stack (Prometheus Loki etc) and we
| need to also send the data to Dynatrace. With otel collector
| these things are a minor configuration away.
|
| For Kafka if you mean tracing through Kafka messages previously
| we did it by propagating it in message headers. Done at a
| shared team level library the effort was minimal.
| exabrial wrote:
| JMX -> Jolokia -> Telegraf -> the-older-TICK-stack-before-
| influxdb-rewrote-it-for-the-3rd-time-progressively-making-it-
| worse-each-time
| demurgos wrote:
| OpenTelemetry is nice overall as there are library for multiple
| platforms. I introduced it this year for a web game platform with
| servers in Node, Java, PHP and Rust and it all worked roughly
| similarly which made it good for consistency.
|
| I like how OpenTelemetry decouples the signal sink from the
| context, compared to other structured logging libs where you wrap
| your sink in layers. The main thing that I dislike is the auto-
| instrumentation of third-party libraries: it works great most of
| the time, but when it doesn't it's hard to debug. Maintainers of
| the different OpenTelemetry repos are fairly active and respond
| quickly.
|
| It's still relatively recent, but I would recommend OpenTelemetry
| if you're looking for an observability framework.
___________________________________________________________________
(page generated 2024-09-18 23:00 UTC)