I took it upon myself to write a library for my current employer (4yrs ago now?) that abstracted and standardized the way our Rust services instantiated and utilized the metrics and tracing fundamentals that OpenTelemetry provides. I recently added OTLP logging (technically using tracing events) to allow for forwarding baggage / context / metadata with the log lines. The `tracing` crate in rust also has a macro called `instrument` that allows you to mostly auto-instrument your functions for tracing, allowing the tracing context to be extracted and propagated into your function so the trace / span can be added to subsequent HTTP / gRPC requests.
We did all kinds of other stuff too, like adding a method for attaching the trace-id to our kafka messages so we can see how long the entire lifetime of the request takes (including sitting on the queue). It's been extremely insightful.
Signoz is newer to the game. I'm glad there are more competitors and vendors using OpenTelemetry natively. We originally talked to some of the big vendors and they were going to gladly accept OpenTelemetry, but they marked every metric as a "custom" metric and would charge out the wazoo for each of them, far in excess of whatever was instrumented natively with their APM plugin thingamabob.
The more the better. I love OpenTelemetry, and using it in Rust has been mostly great.
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!
(Except for this, that is: https://github.com/tokio-rs/tracing/issues/2519)
I've got a whole list of puzzling bugs in the tracing <-> opentelemetry <-> datadog linkage.
``` logs_2025-12-24_0003.jsonl ```
I asked Claude to keep it in an xdg folder and it chose
``` /home/{username}/.local/share/{applicationName}/telemetry/logs ```
I also have folders for metrics and traces but those are empty.
I have never had a need to look at the logs for the dotnet console app I have and the only reason I have looked at the logs on the asp dotnet app was to review errors when I ran into some error on my asp dotnet application, which frankly I don't need open telemetry for.
What am I missing here? Am I using it wrong?
If you use open telemetry, where do your logs, metrics, and traces go? Do you write your own custom classes to write them to a file on the disk? Do you pay for something like datadog (congratulations on winning the lottery I guess?)
I appreciate your reply. Thank you for helping me learn.
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.
Otel has value for things crossing microservices in production, much less in local for a single app.
Often, languages running on dotnet or the JVM already enjoy great tooling for quite a few years, and so locally they are much better than otel.
The problem had nothing to do with our network infrastructure, deployment, etc, etc, it was completely their end.
I get the impression this standard is 10x more complicated than it needs to be, but the stuff it replaced was 100x too complicated.
Honestly though, I feel like it's all just a big hack working around splunk and similar systems' inability to understand summary statistics.
Less politely: If I had shell on the telemetry servers, I could probably get the same functionality from a perl one-liner that's easier to understand + maintain.
