I was initially very skeptical, but I spent the effort researching what it is and also getting up-to-date with the Observability movement.
What I found in the fewest bullets as possible:
* The hype is obnoxious and unfortunately hides the really useful stuff. Here is my summary of the Observability movement in one sentence:
Record telemetry as unique, high-context events (unlike typical logs), containing many keys (as an alternative to having too many metrics), and provide convenient way to query instead of trying to frame it in a dashboard.
* The metrics and logging stuff is almost an afterthought. Think of it as bonus to the distributed tracing story.
* Distributed tracing is really, really useful for debugging and is should what application developers focus on first in their monitoring story. Don't inspect monitoring tools designed for infrastructure to help you much. The reason is simple - debugging is inherently reactive; most other tooling suggests you take proactive approaches which are useful for known issues. When you are debugging production systems you are trying to understand previously unknown issues.
* Otel is really simple; often automatic instrumentation is not worth the trouble and simpler libraries where you manually instrument your code are not hard at all to use. My experience is with Clojure, but YMMV.
* Otel backends can range from very affordable to very expensive so shop around. This is a benefit of having a standard!
I think distributed tracing is perfectly suitable for small projects, even one-service ones; I think one should add it to one before even thinking about deployment. And is mandatory for micro-services.
Comments
I was initially very skeptical, but I spent the effort researching what it is and also getting up-to-date with the Observability movement.
What I found in the fewest bullets as possible:
* The hype is obnoxious and unfortunately hides the really useful stuff. Here is my summary of the Observability movement in one sentence:
* The metrics and logging stuff is almost an afterthought. Think of it as bonus to the distributed tracing story.* Distributed tracing is really, really useful for debugging and is should what application developers focus on first in their monitoring story. Don't inspect monitoring tools designed for infrastructure to help you much. The reason is simple - debugging is inherently reactive; most other tooling suggests you take proactive approaches which are useful for known issues. When you are debugging production systems you are trying to understand previously unknown issues.
* Otel is really simple; often automatic instrumentation is not worth the trouble and simpler libraries where you manually instrument your code are not hard at all to use. My experience is with Clojure, but YMMV.
* Otel backends can range from very affordable to very expensive so shop around. This is a benefit of having a standard!
I think distributed tracing is perfectly suitable for small projects, even one-service ones; I think one should add it to one before even thinking about deployment. And is mandatory for micro-services.