Skip to content

Tiny, tiny typo #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
briankung wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Tiny, tiny typo #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/posts/rust-tracing-opentelemetry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ to your `main` function. If you are running a web application you can use integr

But you want more than console output, right? Tracing links the various "spans" and log events from a single HTTP request together and we want to see them collected in a dashboard so we can track what happened during each request, query the data and so on. At this point you might read about the [`tracing-opentelemetry`]() and [`opentelemetry`]() crates. The `opentelemetry` crate lists yet more crates which you can use to export traces to various backends. One of these is [Jaeger](https://www.jaegertracing.io/) which is a popular open source tool, with a nice UI. You can easily run it locally using Docker, it's often used in blog articles and many of the code samples on `crates.io` use it.

This is roughly where I was about a year ago. I was working on a system which I'd integrated with Rust `tracing` and copied one of those samples to export to Jaeger using the [`opentelemetry-jaeger`](https://crates.io/crates/opentelemetry-jaeger) crate. But ideally we wanted to provide a binary to users and allow them to choose their own telemetry backend. OpenTelemetry didn't seem to be providing a lot of value if we had to comile against a different integration crate each time 🤔.
This is roughly where I was about a year ago. I was working on a system which I'd integrated with Rust `tracing` and copied one of those samples to export to Jaeger using the [`opentelemetry-jaeger`](https://crates.io/crates/opentelemetry-jaeger) crate. But ideally we wanted to provide a binary to users and allow them to choose their own telemetry backend. OpenTelemetry didn't seem to be providing a lot of value if we had to compile against a different integration crate each time 🤔.

On revisiting this issue and doing a bit more research, I realised that OpenTelemetry defines [its own protocol](https://opentelemetry.io/docs/reference/specification/protocol/), OTLP (hence the "Open" 🙄), and that it is *directly supported* by Jaeger as well as by many [commercial vendors](https://opentelemetry.io/ecosystem/vendors/). In fact, Jaeger has now deprecated its own clients in favour of OTLP, so the `opentelemetry-jaeger` crate is really redundant.

Expand Down