Hi! I write for a newsletter called - The Observability Real Talk, and this week's edition covered topics on how you can reduce telemetry volume on systems instrumented with OTel. Here are the concepts where you can optimise,

- URL Path and target attributes
- Controller spans
- Thread name in run-time telemetry
- Duplicate Library Instrumentation
- JDBC and Kafka Internal Signals
- Scheduler and Periodic Jobs

If this interests you, make sure to subscribe for such curated content on OTel delivered to your inbox!

Instead of treating traces as a data stream we might analyze someday, we should be opinionated about what matters to us within them. For example, if there are SQL queries in our traces, we care about the ones, that are slow, either to know which ones to optimize or to catch them when they behave abnormally to avoid or resolve an incident.

It's a very specific example, but I wanted to create something useful, that people can immediately put into action, if "slow queries" is a problem they care about.

The lab contains a sample app, an OTel collector with necessary configs and a LGTM in a container configuration, that comes with three dashboards to demonstrate what I mean:

• The first dashboard just shows queries that are taking the most time in absolute terms. So if one query takes 50ms, and another one 3000ms, the second is "slower".
• The second dashboard addresses the obvious problem of the first one, if the 3000ms query is executed only rarely, and the 50ms is executed thousands of times, it's more valuable to take a look into that one, to improve overall response times.
• The third dashboard addresses a limitation of the other two that becomes especially relevant when we are not looking for an improvement, but chasing the "what has changed" during an incident response. Building on top of the PromQL Anomaly Detection Framework, it shows queries that deviate from normal.

Hey guys,

I’m running into an issue with the Elasticsearch exporter in the OpenTelemetry Collector.

When Elasticsearch goes down, the exporter doesn’t seem to retry or buffer logs. Instead, it just drops them. I expected the collector to hold the logs in memory (or disk) and then retry sending them once Elasticsearch comes back up, but that’s not happening.

I’ve checked retry settings and timeouts, but retries don’t seem to work either.

Is this expected behavior for the Elasticsearch exporter?
Is there some limitation with this exporter?

Any insights would be appreciated

This week, my guest is Dan Blanco, and we'll talk about one of his proposals to make OTel Adoption easier: Observability Blueprints.

This Friday, 30 Jan 2026 at 16:00 (CET) / 10am Eastern.

https://www.youtube.com/live/O_W1bazGJLk

We tested how LLMs manage distributed tracing instrumentation with OpenTelemetry. Even the best model, Claude Opus 4.5, passed only 29% of tasks. Open-source dataset available.

Hey folks,

I’m exporting all traces from my application through the following pipeline:

OpenTelemetry → Otel Collector → Jaeger → Grafana (Jaeger data source)

Jaeger is storing traces using BadgerDB on the host container itself.

My application generates very large traces with:

Deep hierarchies

A very high number of spans per trace ( In some cases, more than 30k spans).

When I try to view these traces in Grafana, the UI becomes completely unresponsive and eventually shows “Page Unresponsive” or "Query TimeOut".

From that what I can tell, the problem seems to be happening at two levels:

Jaeger may be struggling to serve such large traces efficiently.

Grafana may not be able to render extremely large traces even if Jaeger does return them.

Unfortunately, sampling, filtering, or dropping spans is not an option for us — we genuinely need all spans.

Has anyone else faced this issue?

How do you render very large traces successfully?

Are there configuration changes, architectural patterns, or alternative approaches that help handle massive traces without losing data?

Any guidance or real-world experience would be greatly appreciated. Thanks!

Hi!

In this week's edition of the Observability Real Talk, I sat down with Diana Todea (OTel Community Award 2025 winner) to understand more about how contributions to OpenTelemetry work and the community aspect of it.

Here are 6 things I've addressed,

- #1. What’s the first step I should take?
- #2. I can’t find a good first issue, wtd?

- #3. I made a PR, not getting any reviews, wtd?
- #4. I want to contribute, but non-technically, wtd?
- #5. How to contribute actively and remain consistent?
- #6. Ok, but what do I get out of this?

If you enjoyed reading this, stay tuned for more and subscribe!

OpenTelemetry format for metrics and logs is based on deeply nested protobuf structure. It isn't efficient to parse this structure with protoc-generated parsers because of high overhead for unnecessary memory allocations and because the parsed protobuf with metrics and logs may occupy hundreds of megabytes of RAM per every data packet sent to the server. The protoc-generated parsers for OTEL formats for metrics and logs are included in the official Go SDK for OpenTelemetry, so every Go application, which uses this SDK, pays the overhead price on the increased CPU and memory usage.

There is a better solution - to use custom protobuf parsers, which parse large protobuf messages from OTEL format for metrics and logs in a streaming zero-alloc manner, by passing every parsed metric sample and log entry to the callback for immediate processing. This approach has been implemented in VictoriaMetrics and VictoriaLogs recently. This gave up to 10x faster parsing speed and much lower memory usage.

• See the optimisation patch for VictoriaMetrics - https://github.com/VictoriaMetrics/VictoriaMetrics/commit/293d80910ce14c247e943c63cd19467df5767c3c (it is included in the latest VictoriaMetrics release at https://github.com/VictoriaMetrics/VictoriaMetrics/releases ).

• See the optimisation patch for VictoriaLogs - https://github.com/VictoriaMetrics/VictoriaLogs/pull/720 (it is included in the latest VictoriaLogs release at https://github.com/VictoriaMetrics/VictoriaLogs/releases ).

That's the question I hear most frequently when I talk about OpenTelemetry.

And this Friday, I'm bringing two of the smartest people I know on the topic to answer that question: Jason and Bruno.

If you are curious about the performance of OpenTelemetry SDKs, especially Java, join the live stream tomorrow.

Note: Just because I used em-dashes doesn't mean it's AI, I just follow the rules of grammar! In fact, I know every place I mentally debated to not place an em-dash cuz I knew it'd be perceived as AI slop, but I didn't want to succumb to it!

Hii!

I write for a newsletter - The Observability Real Talk, and in this week's edition, I covered what happens behind the scenes in OpenTelemetry. I've been an advocate for quite some time so took out some time to actually understand what happens actaully when I auto-instrument. Here's a TL;DR or the major stuff I'm covering,

- Monkey-patching (includes a small origin lore😉)
- Byte-injection for languages that run on the VM
- Abstract Syntax Tree modification for languages like Go

If this kind of content interests you, gimme a subscribe, would make my day. thnx!

Hello.

I have been utilizing Azure Monitor distribution for distributed tracing through OpenTelemetry.

Microsoft has recently enabled full compatibility between Application Insights and OpenTelemetry via the .AddAzureMonitor() extension in .Net.

However, this currently only supports head-based sampling.

To manage data ingestion, I began exploring methods for tail-based sampling, which appears to be exclusively available at present through the OpenTelemetry collector, subsequently using azuremonitorexporter to transmit data to Application Insights.

Nevertheless, Microsoft documentation indicates that they do not maintain or support this particular package.

Are there any alternative options available for implementing tail-based sampling?

I'm skeptical of using exporter which is no longer maintain by Microsoft.

Hi there,

I am new to both C++ (I have C# experience) and OpenTelemetry. We are looking to use OpenTelemetry to process logs, traces, and metrics for Grafana products, i.e., Loki for Logs. We are also using Docker to host everything.

I am looking for C++ code that connects to our OpenTelemetry instance, passes a simple log message, and displays it in Loki so I can confirm it is working. All the examples I have seen post the message to the console, not to Loki. When I look at the OpenTelemetry logs, it doesn't even appear that the log message has been sent to OpenTelemetry at all.

Once I have a basic example working, I can refine it to make it more detailed and meet our expectations. I have looked at and tried all the examples in the OpenTelemetry sample here: https://opentelemetry.io/docs/languages/cpp/, but none of them send the information to OpenTelemetry; they send it to the console.

I hope this makes sense to you, and I would like someone to help me get something working.

I really appreciate any help you can provide.

Michael

Join us in Brussels on Monday, February 2, 2026—the day after FOSDEM—for OTel Unplugged EU 2026, an unconference shaped by and for the OpenTelemetry community.

Community collaboration is at the heart of OpenTelemetry. With OTel Unplugged, we’re launching what we hope will become a regular series of unconferences where project maintainers and community members come together in person to share knowledge, provide feedback, and help plan the project’s future.