Live data from Hacker News

OpenTelemetry for Rust Developers

signoz.io

11–12 of 12 posts

Re: OpenTelemetry for Rust Developers

#11
post #5

Speaking of opentelemetry, I try to use open telemetry with my personal projects in an asp dotnet as well as with a dotnet console app. I don't have the required corporate background in opentelemetry. I had to write my own file log exporter. I didn't write it myself -- I used Claude to write it for me in jsonl format which seemed like a good way to have each row in json and for the console app, I get a file something…

Open Telemetry is a "narrow waist".

That is, it defines a relatively small, interoperable interface that a lot of distinct products from many different vendors can "sink" their telemetry into, and then on the other end of this narrow waist a bunch of different consumers can "source" the data from.

Think of it as a fancy alternative to ILogger and similar abstractions that is cross-platform and cross-vendor. Instead of Microsoft-specific or Java-specific (or whatever-specific) sources with their own protocols and conventions, there's a single standard for the data schema that everybody can talk. It's like TCP/IP or JSON.

So your question is in some sense nonsense. It's like asking "what do you use TCP/IP for?" or "where do you put your JSON"?

The answer is: wherever you want! That's the whole point.

In Azure, you would use Application Insights, as a random example. New Relic, DataDog, Prometheus, Zipkin, Elasticsearch, or... just your console output. Simple text log files. A SQL database. Wherever!

In more practical terms, for a solo developer working on personal projects, use Aspire.NET with Visual Studio 2026. You'll get a free "local" alternative to an APM like Application Insights or DataDog that collects the traces. Keep using the "standard" interfaces like ILogger, they forward everything to OTel if you're using it.

Re: OpenTelemetry for Rust Developers

#12
post #2

The OpenTelemetry spec is absolutely what folks have been waiting for for as long as I've been in computing (~20 years). A single standard that is implemented in nearly every popular language with very close feature parity. It's honestly wonderful to work with compared to the old vendor supplied frameworks. I took it upon myself to write a library for my current employer (4yrs ago now?) that abstracted and standardiz…

That library you built sounds great. The kind of things that I love to read the code of, if I'm using it in a project. I was divided between adding instrument macro, but decided on manual instrumentation for the demonstration.

Regarding monitoring Kakfa execution times, absolutely agreed. In my previous job, monitoring Celery had helped us understand consumer bottlenecks, because we couldn't see background job traces containing the celery consumer spans. And when they did appear, they were hours late. So the entire trace took 8 hours instead of the expected couple minutes.

Happy to hear you've been enjoying OTel and Rust!

Post reply on HN