OpenTelemetry profiles enters public alpha • Hacker News Board

Re: OpenTelemetry profiles enters public alpha

#21

Post by tuo-lei » Fri, Mar 27, 2026, 2:26 AM UTC

petterroea wrote: post #19

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…

do you have any suggestions for alternatives then (besides Sentry)? I do feel OTel have pretty wide support in general in term of traces.

Re: OpenTelemetry profiles enters public alpha

#22

Post by rrrix1 » Fri, Mar 27, 2026, 2:51 AM UTC

nesarkvechnep wrote: post #8

genthree wrote: post #4

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…

People don’t care about syslog. 98% of my colleagues haven’t heard of it.

Except every sysadmin and security engineer ever

Re: OpenTelemetry profiles enters public alpha

#23

Post by AbanoubRodolf » Fri, Mar 27, 2026, 3:08 AM UTC

SEJeff wrote: post #9

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

[flagged]

Re: OpenTelemetry profiles enters public alpha

#24

Post by petterroea » Fri, Mar 27, 2026, 4:36 AM UTC

tuo-lei wrote: post #21

petterroea wrote: post #19

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…

do you have any suggestions for alternatives then (besides Sentry)? I do feel OTel have pretty wide support in general in term of traces.

I know a lot of shops that prefer the datadog stack, which apparently does have its own sentry-like exception capturing system. To me, exception capturing is an obvious core feature and it is humiliating to discuss OTel with people who agree, and use datadog and are satisfied.

Re: OpenTelemetry profiles enters public alpha

#25

Post by antonvs » Fri, Mar 27, 2026, 5:45 AM UTC

secondcoming wrote: post #2

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

Do you feel better now?

Re: OpenTelemetry profiles enters public alpha

#26

Post by nesarkvechnep » Fri, Mar 27, 2026, 5:48 AM UTC

malux85 wrote: post #10

nesarkvechnep wrote: post #8

Earlier quoted context omitted.

People don’t care about syslog. 98% of my colleagues haven’t heard of it.

You are drawing a global conclusion from a tiny sample!

I really hope that I am because I care about it and like to use it whenever I can.

Re: OpenTelemetry profiles enters public alpha

#27

Post by nesarkvechnep » Fri, Mar 27, 2026, 5:48 AM UTC

rrrix1 wrote: post #22

nesarkvechnep wrote: post #8

Earlier quoted context omitted.

People don’t care about syslog. 98% of my colleagues haven’t heard of it.

Except every sysadmin and security engineer ever

Never met one who knew about syslog but I'm glad that there's a high chance I'm not right generally.

Re: OpenTelemetry profiles enters public alpha

#28

Post by hikaru_ai » Fri, Mar 27, 2026, 7:17 AM UTC

[dead]

Re: OpenTelemetry profiles enters public alpha

#29

Post by jamiemallers » Fri, Mar 27, 2026, 9:16 AM UTC

petterroea wrote: post #19

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…

[dead]

Re: OpenTelemetry profiles enters public alpha

#30

Post by BigRedEye » Fri, Mar 27, 2026, 10:52 AM UTC

tanelpoder wrote: post #15

rnrn wrote: post #14

Earlier quoted context omitted.

> For example, they invented the .eh_frame walking technique to get stack traces from binaries without frame pointers enabled. This is not an accurate summary of what they developed. Using .eh_frame to unwind stacks without frame pointers is not novel - it is exactly what it is for and perf has had an implementation doing it since ~2010. The problem is the kernel support for this was repeatedly rejected so the kernel…

True, I should have been more specific about the context: Their invention is about pushing down the .eh_frame walking to kernel space, so you don't need to ship large chunks of stack memory to userspace for post-processing. And eBPF code is the executor of that "pushed down" .eh_frame walking. The GitHub page mentions a patent on this too: https://patents.google.com/patent/US11604718B1/en

I believe this is a case of convergent invention – the idea of pushing DWARF/.eh_frame unwinding into eBPF seems to have occurred to several people around the same time. For example, there's a working implementation discussed as early as March 2021: https://github.com/iovisor/bcc/issues/1234#issuecomment-7875...