OpenTelemetry profiles enters public alpha

secondcoming

> Continuously capturing low-overhead performance profiles in production It suprises me that anything designed by the OTel community could ever meet 'low-overhead' expectations.

genthree

Relatedly: Has anyone profiled the performance and reliability characteristics of rsyslogd (Linux and FreeBSD distributed syslogger, maybe other platforms too) in its mode where it’s shipping logs to a central node? I’ve configured and used it with relatively small (high single digit nodes, bursts of activity to a million or two requests per minute or so) set-ups but have wondered if there’s a reason it’s not a more common solution for distributed logging and tracing (yes it doesn’t solve the UI problem for those, but it does solve collecting your logs) Like… has anyone done a Jepsen-like stress test on rsyslogd and shared the results? I’ve half-assedly looked before and not been able to find anything.

ollien

Very excited for this. We've used the Elixir version of this at $WORK a handful of times and have found it exceptionally useful.

SEJeff

I wonder how this compares to grafana pyroscope, which is really good for this sort of thing and already quite mature: https://grafana.com/oss/pyroscope/ https://github.com/grafana/pyroscope

petterroea

This is cool, OTel is getting somewhere. I've found OTel to still have rough edges and it's not really the one stop shop for telemetry we want it to be at $work yet. In particular, no good (sentry-style) exception capturing yet. They also recently changed a lot of metric names(for good reason it seems), which breaks most dashboards you find on the internet. I have been warned by people that OTel isn't mature yet and I find it to still be true, but it seems the maintainers are trying to do something about this nowadays