OpenTelemetry profiles enters public alpha (opentelemetry.io)

by tanelpoder 30 comments 205 points
Read article View on HN

30 comments

[−] petterroea 50d ago
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

[−] darkwater 50d ago
I think that the "issue" around otel is that instrumentation is easy and free (as both in beer and freedom) but then for the dashboarding part is where there are literally tens of different SaaS solutions, all more or less involved with the OTel development itself, that want you to use their solution (and pay $$$ for it). And even if you can go a loooong way with a self-hosted Grafana + Tempo, even Grafana Labs are putting more and more new features behind the Grafana Cloud subscription model.
[−] tuo-lei 50d ago
do you have any suggestions for alternatives then (besides Sentry)? I do feel OTel have pretty wide support in general in term of traces.
[−] jamiemallers 50d ago
[dead]
[−] d0963319287 50d ago
[flagged]
[−] BigRedEye 50d ago
At Perforator, we also started from Google's beautiful pprof, but then eliminated all nested repeated fields, converging to https://github.com/yandex/perforator/blob/main/perforator/pr.... Repeated fields in protobufs are really memory & CPU hungry.

This layout allows us to quickly merge hundreds of millions of samples into a single profile. The only practical limit is protobuf's 2GB message size cap.

[−] genthree 51d ago
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.

[−] SEJeff 50d ago
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

[−] secondcoming 51d ago

> Continuously capturing low-overhead performance profiles in production

It suprises me that anything designed by the OTel community could ever meet 'low-overhead' expectations.

[−] ollien 50d ago
Very excited for this. We've used the Elixir version of this at $WORK a handful of times and have found it exceptionally useful.
[−] vicistack 50d ago
[dead]
[−] hikaru_ai 50d ago
[dead]