frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

Open in hackernews

OpenTelemetry for Go: Measuring overhead costs

https://coroot.com/blog/opentelemetry-for-go-measuring-the-overhead/
77•openWrangler•7h ago

Comments

dmoy•6h ago
Not on original topic, but:

I definitely prefer having graphs put the unit at least on the axis, if not in the individual axis labels directly.

I.e. instead of having a graph titled "latency, seconds" at the top and then way over on the left have an unlabeled axis with "5m, 10m, 15m, 20m" ticks...

I'd rather have title "latency" and either "seconds" on the left, or, given the confusion between "5m = 5 minutes" or "5m = 5 milli[seconds]", just have it explicitly labeled on each tick: 5ms, 10ms, ...

Way, way less likely to confuse someone when the units are right on the number, instead of floating way over in a different section of the graph

Thaxll•5h ago
Logging, metrics and traces are not free, especially if you turn them on at every requests.

Tracing every http 200 at 10k req/sec is not something you should be doing, at that rate you should sample 200 ( 1% or so ) and trace all the errors.

anonzzzies•5h ago
A very small % of startups gets anywhere near that traffic so why give them angst? Most people can just do this without any issues and learn from it and a tiny fraction shouldn't.
williamdclt•5h ago
10k/s across multiple services is reached quickly even at startup scale.

In my previous company (startup), we’d use Otel everywhere and we definitely needed sampling for cost reasons (1/30 iirc). And that was using a much cheaper provider than Datadog

cogman10•5h ago
Having high req/s isn't as big a negative as it once was. Especially if you are using http2 or http3.

Designing APIs which cause a high number of requests and spit out a low amount of data can be quite legitimate. It allows for better scaling and capacity planning vs having single calls that take a large amount of time and return large amounts of data.

In the old http1 days, it was a bad thing because a single connection could only service 1 request at a time. Getting any sort of concurrency or high request rates require many connections (which had a large amount of overhead due to the way tcp functions).

We've moved past that.

orochimaaru•4h ago
Metrics are usually minimal overheard. Traces need to be sampled. Logs need to be sampled at error/critical levels. You also need to be able to dynamically change sampling and log levels.

100% traces are a mess. I didn’t see where he setup sampling.

phillipcarter•3h ago
The post didn't cover sampling, which indeed, significantly reduces overhead in OTel because the spans that aren't sampled aren't ever created, when you head sample at the SDK level. This is more of a concern when doing tail-based sampling only, wherein you will want to trace each request and offload to a sidecar so that export concerns are handled outside your app. And then it routes to a sampler elsewhere in your infrastructure.

FWIW at my former employer we had some fairly loose guidelines for folks around sampling: https://docs.honeycomb.io/manage-data-volume/sample/guidelin...

There's outliers, but the general idea is that there's also a high cost to implementing sampling (especially for nontrivial stuff), and if your volume isn't terribly high then you'll probably eat a lot more in time than paying for the extra data you may not necessarily need.

jhoechtl•3h ago
I am relatively new to the topic. In the sample code of the OP there is no logging right? It's metrics and traces but no logging.

How is logging in OTel?

shanemhansen•1h ago
To me traces (or maybe more specifically spans) are essentially a structured log with a unique ID and a reference to a parent ID.

Very open to have someone explain why I'm wrong or why they should be handled separately.

kiitos•1h ago
Traces have a very specific data model, and corresponding limitations, which don't really accommodate log events/messages of arbitrary size. The access model for traces is also fundamentally different vs. that of logs.
phillipcarter•6m ago
There are practical limitations mostly with backend analysis tools. OTel does not define a limit on how large a span is. It’s quite common in LLM Observability to capture full prompts and LLM responses as attributes on spans, for example.
phillipcarter•8m ago
Logging in OTel is logging with your logging framework of choice. The SDK just requires you initialize the wrapper and it’ll then wrap your existing logging calls and correlate term with a trace/span in active context, if it exists. There is no separate logging API to learn. Logs are exported in a separate pipeline from traces and metrics.

Implementation for many languages are starting to mature, too.

kubectl_h•2h ago
You have to do the tracing anyway if you are going to sample based on criteria that isn't available at the beginning of the trace (like an error that occurs later in the request) and tail sample. You can head sample of course, but that's going to be the most coarse sampling you can do and you can't sample based on anything but the initial conditions of the trace.

What we have started doing is still tracing every unit of work, but deciding at the root span the level of instrumentation fidelity we want for the trace based on the initial conditions. Spans are still generated in the lifecycle of the trace, but we discard them at the processor level (before they are batched and sent to the collector) unless they have errors on them or the trace has been marked as "full fidelity".

kiitos•1h ago
> Tracing every http 200 at 10k req/sec is not something you should be doing

You don't know if a request is HTTP 200 or HTTP 500 until it ends, so you have to at least collect trace data for every request as it executes. You can decide whether or not to emit trace data for a request based on its ultimate response code, but emission is gonna be out-of-band of the request lifecycle, and (in any reasonable implementation) amortized such that you really shouldn't need to care about sampling based on outcome. That is, the cost of collection is >> the cost of emission.

If your tracing system can't handle 100% of your traffic, that's a problem in that system; it's definitely not any kind of universal truth... !

jeffbee•5h ago
I feel like this is a lesson that unfortunately did not escape Google, even though a lot of these open systems came from Google or ex-Googlers. The overhead of tracing, logs, and metrics needs to be ultra-low. But the (mis)feature whereby a trace span can be sampled post hoc means that you cannot have a nil tracer that does nothing on unsampled traces, because it could become sampled later. And the idea that if a metric exists it must be centrally collected is totally preposterous, makes everything far too expensive when all a developer wants is a metric that costs nothing in the steady state but can be collected when needed.
mamidon•3h ago
How would you handle the case where you want to trace 100% of errors? Presumably you don't know a trace is an error until after you've executed the thing and paid the price.
phillipcarter•3h ago
This is correct. It's a seemingly simple desire -- "always capture whenever there's a request with an error!" -- but the overhead needed to set that up gets complex. And then you start heading down the path of "well THESE business conditions are more important than THOSE business conditions!" and before you know it, you've got a nice little tower of sampling cards assembled. It's still worth it, just a hefty tax at times, and often the right solution is to just pay for more compute and data so that your engineers are spending less time on these meta-level concerns.
jeffbee•3h ago
I wouldn't. "Trace contains an error" is a hideously bad criterion for sampling. If you have some storage subsystem where you always hedge/race reads to two replicas then cancel the request of the losing replica, then all of your traces will contain an error. It is a genuinely terrible feature.

Local logging of error conditions is the way to go. And I mean local, not to a central, indexed log search engine; that's also way too expensive.

phillipcarter•3h ago
I disagree that it's a bad criterion. The case you describe is what sounds difficult, treating one error as part of normal operations and another as not. That should be considered its own kind of error or other form of response, and sampling decisions could take that into consideration (or not).
jeffbee•2h ago
Another reason against inflating sampling rates on errors is: for system stability you never want to do more stuff during errors than you would normally do. Doing something more expensive during an error can cause your whole system, or elements of it, to latch into an unplanned operating point where they only have the capacity to do the expensive error path, and all of the traffic is throwing errors because of the resource starvation.
vanschelven•4h ago
The article never really explains what eBPF is -- AFAIU, it’s a kernel feature that lets you trace syscalls and network events without touching your app code. Low overhead, good for metrics, but not exactly transparent.

It’s the umpteenth OTEL-critical article on the front page of HN this month alone... I have to say I share the sentiment but probably for different reasons. My take is quite the opposite: most value is precisely in the application (code) level so you definetly should instrument... and then focus on Errors over "general observability"[0]

[0] https://www.bugsink.com/blog/track-errors-first/

nikolay_sivko•4h ago
I'm the author. I wouldn’t say the post is critical of OTEL. I just wanted to measure the overhead, that’s all. Benchmarks shouldn’t be seen as critique. Quite the opposite, we can only improve things if we’ve measured them first.
politician•4h ago
I don't want to take away from your point, and yet... if anyone lacks background knowledge these days the relevant context is just an LLM prompt away.
vanschelven•4h ago
It was always "a search away" but on the _web_ one might as well use... A hyperlink
sa46•4h ago
Funny timing—I tried optimizing the Otel Go SDK a few weeks ago (https://github.com/open-telemetry/opentelemetry-go/issues/67...).

I suspect you could make the tracing SDK 2x faster with some cleverness. The main tricks are:

- Use a faster time.Now(). Go does a fair bit of work to convert to the Go epoch.

- Use atomics instead of a mutex. I sent a PR, but the reviewer caught correctness issues. Atomics are subtle and tricky.

- Directly marshal protos instead of reflection with a hand-rolled library or with https://github.com/VictoriaMetrics/easyproto.

The gold standard is how TiDB implemented tracing (https://www.pingcap.com/blog/how-we-trace-a-kv-database-with...). Since Go purposefully (and reasonably) doesn't currently provide a comparable abstraction for thread-local storage, we can't implement similar tricks like special-casing when a trace is modified on a single thread.

malkia•4h ago
There is an effort to use arrow format for metrics too - https://github.com/open-telemetry/otel-arrow - but no client that exports directly to it yet.
rastignack•2h ago
Would the sync.Pool trick mentionned here: https://hypermode.com/blog/introducing-ristretto-high-perf-g... help ? It’s lossy but might be a good compromise.
otterley•4h ago
Out of curiosity, does Go's built-in pprof yield different results?

The nice thing about Go is that you don't need an eBPF module to get decent profiling.

Also, CPU and memory instrumentation is built into the Linux kernel already.

coxley•3h ago
The OTel SDK has always been much worse to use than Prometheus for metrics — including higher overhead. I prefer to only use it for tracing for that reason.
reactordev•3h ago
Mmmmmmm, the last 8 months of my life wrapped into a blog post but with an ad on the end. Excellent. Basically the same findings as me, my team, and everyone else in the space.

Not being sarcastic at all, it’s tricky. I like that the article called out eBPF and why you would want to disable it for speed but recommends caution. I kept hearing from executives a “single pane of glass” marketing speak and I kept my mouth shut about how that isn’t feasible across the entire organization. Needless to say, they didn’t like that non-answer and so I was canned. What an engineer cared about is different from organization/business metrics and often the two were confused.

I wrote a lot of great otel receivers though. VMware, Veracode, Hashicorp Vault, GitLab, Jenkins, Jira, and the platforms itself.

phillipcarter•3h ago
> I kept hearing from executives a “single pane of glass” marketing speak

It's really unfortunate that Observability vendors lean into this to reinforce it too. What the execs usually care about is engineering workflows consolidating and allowing teams to all "speak the same language" in terms of data, analysis workflows, visualizations, runbooks, etc.

This goal is admirable, but nearly impossible to achieve because it's the exact same problem as solving "we are aligned organizationally", which no organization ever is.

That doesn't mean progress can't be made, but it's always far more complicated than they would like.

reactordev•3h ago
For sure, it’s the ultimate nirvana. Let me know when an organization gets there. :)

Show HN: Chawan TUI web browser

https://chawan.net/news/chawan-0-2-0.html
101•shiomiru•2h ago•10 comments

Snorting the AGI with Claude Code

https://kadekillary.work/blog/#2025-06-16-snorting-the-agi-with-claude-code
102•beigebrucewayne•11h ago•30 comments

What Happens When Clergy Take Psilocybin

https://nautil.us/clergy-blown-away-by-psilocybin-1217112/
18•bookofjoe•1h ago•8 comments

Benzene at 200

https://www.chemistryworld.com/opinion/benzene-at-200/4021504.article
159•Brajeshwar•7h ago•88 comments

Show HN: Canine – A Heroku alternative built on Kubernetes

https://github.com/czhu12/canine
120•czhu12•4h ago•57 comments

Retrobootstrapping Rust for some reason

https://graydon2.dreamwidth.org/317484.html
62•romac•2h ago•24 comments

Show HN: Nexus.js - Fabric.js for 3D

https://punk.cam/lab/nexus
30•ges•2h ago•5 comments

Working on databases from prison

https://turso.tech/blog/working-on-databases-from-prison
643•dvektor•10h ago•418 comments

OpenTelemetry for Go: Measuring overhead costs

https://coroot.com/blog/opentelemetry-for-go-measuring-the-overhead/
77•openWrangler•7h ago•32 comments

Blaze (YC S24) Is Hiring

https://www.ycombinator.com/companies/blaze-2/jobs/dzNmNuw-junior-software-engineer
1•faiyamrahman•1h ago

Open-Source RISC-V: Energy Efficiency of Superscalar, Out-of-Order Execution

https://arxiv.org/abs/2505.24363
42•PaulHoule•6h ago•10 comments

Breaking Quadratic Barriers: A Non-Attention LLM for Ultra-Long Context Horizons

https://arxiv.org/abs/2506.01963
33•PaulHoule•3h ago•17 comments

Show HN: Zeekstd – Rust Implementation of the ZSTD Seekable Format

https://github.com/rorosen/zeekstd
164•rorosen•1d ago•28 comments

ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development

https://arxiv.org/abs/2506.11016
59•lelanthran•7h ago•39 comments

Nanonets-OCR-s – OCR model that transforms documents into structured markdown

https://huggingface.co/nanonets/Nanonets-OCR-s
265•PixelPanda•16h ago•61 comments

Transparent peer review to be extended to all of Nature's research papers

https://www.nature.com/articles/d41586-025-01880-9
96•rntn•4h ago•39 comments

Show HN: dk – A script runner and cross-compiler, written in OCaml

https://diskuv.com/dk/help/latest/
47•beckford•8h ago•5 comments

Is gravity just entropy rising? Long-shot idea gets another look

https://www.quantamagazine.org/is-gravity-just-entropy-rising-long-shot-idea-gets-another-look-20250613/
240•pseudolus•22h ago•208 comments

Adding public transport data to Transitous

https://www.volkerkrause.eu/2025/06/14/transitous-adding-data.html
43•todsacerdoti•2d ago•0 comments

Denmark tests unmanned robotic sailboat fleet

https://apnews.com/article/denmark-robot-sailboats-baltic-sea-bfa31c98cf7c93320115c0ad0e6908c5
14•domofutu•2h ago•1 comments

The Renegade Richard Foreman

https://yalereview.org/article/jennifer-krasinski-richard-foreman
13•prismatic•6h ago•5 comments

Why SSL was renamed to TLS in late 90s (2014)

https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html
499•Bogdanp•1d ago•220 comments

WhatsApp introduces ads in its app

https://www.nytimes.com/2025/06/16/technology/whatsapp-ads.html
162•greenburger•9h ago•236 comments

Start your own Internet Resiliency Club

https://bowshock.nl/irc/
513•todsacerdoti•15h ago•286 comments

Maya Blue: Unlocking the Mysteries of an Ancient Pigment

https://www.mexicolore.co.uk/maya/home/maya-blue-unlocking-the-mysteries-of-an-ancient-pigment
69•DanielKehoe•2d ago•16 comments

Occurences of swearing in the Linux kernel source code over time

https://www.vidarholen.net/contents/wordcount/#fuck*,shit*,damn*,idiot*,retard*,crap*
132•microsoftedging•2d ago•212 comments

OpenAI and Microsoft tensions are reaching a boiling point

https://www.wsj.com/tech/ai/openai-and-microsoft-tensions-are-reaching-a-boiling-point-4981c44f
38•jmsflknr•2h ago•5 comments

Darklang Goes Open Source

https://blog.darklang.com/darklang-goes-open-source/
134•stachudotnet•7h ago•61 comments

The Members of the Dull Men's Club

https://www.theguardian.com/society/2025/jun/09/meet-the-members-of-the-dull-mens-club-some-of-them-would-bore-the-ears-off-you
63•herbertl•4h ago•34 comments

Jokes and Humour in the Public Android API

https://voxelmanip.se/2025/06/14/jokes-and-humour-in-the-public-android-api/
273•todsacerdoti•22h ago•148 comments