OTel isn’t going well

Post by jandrewrogers » Sat, Aug 22, 2026, 3:37 PM UTC

sweetgiorni wrote: post #42

fuzzy2 wrote: post #34

Earlier quoted context omitted.

I just don’t get this sentiment. How would you represent metrics as traces? You cannot. Even reconstructing traces from logs would be challenging at best. How would you get, say, Garbage Collector metrics from logs or traces? You cannot. There is no magic bullet. Observability isn’t something you can just slap on and call it a day. While traces and logs might share superficial similarities, they are not the same. And…

> How would you represent metrics as traces? Just instrument your meter implementation so each observation produces a span. Boom, free metric-derived traces.

Post by skrtskrt » Sat, Aug 22, 2026, 4:14 PM UTC

jandrewrogers wrote: post #79

twic wrote: post #58

Earlier quoted context omitted.

Logs and metrics are both derived from events. A log takes the whole event and records it somewhere. A metric takes some numeric value from the event, aggregates it over time, and records it periodically. You can reconstruct a metric from logs for the underlying events. A trace is a period of execution between two events. You could record a trace as a pair of log entries, or one log entry at the end. You can then rec…

This is the literally the "everything is a graph" argument from database architecture. The conceptual abstraction fails badly because it has to be implemented on real silicon that imposes constraints not considered in the abstraction. Logs, metrics, and traces are all derived from raw events but none of them are intrinsically discrete events in a systems engineering sense. They are all different data models with diff…

Post by cyberax » Sat, Aug 22, 2026, 4:24 PM UTC

bilalq wrote: post #46

cyberax wrote: post #43

Earlier quoted context omitted.

A typical setup is to run a separate OpenTelemetry collector process on the same host as the app. The app connects to it via localhost on a standard port (although you can override it using env vars). The collector process then sends the metrics/traces/logs to the observability sink. But there's nothing at all preventing you from sending telemetry directly to the observability sink. It's just outbound HTTP or GRPC, a…

In a lambda runtime, are you blocking client responses until logs/traces/metrics flush?

Post by nunez » Sat, Aug 22, 2026, 4:28 PM UTC

GauntletWizard wrote: post #5

jiggawatts wrote: post #4

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…

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 c…

Post by bilalq » Sat, Aug 22, 2026, 4:28 PM UTC

ojkelly wrote: post #60

bilalq wrote: post #46

Earlier quoted context omitted.

In a lambda runtime, are you blocking client responses until logs/traces/metrics flush?

Use the lambda layer [0] it sends the telemetry after the response is sent, so it doesn’t block. [0] https://github.com/open-telemetry/opentelemetry-lambda