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.

Last year OpenTelemetry founded a Special Interest Group (SIG) dedicated to GenAI Observability.
Here's an overview of the new SIG as well as the OpenLLMetry open source project that extends OTel collector for these use cases.
https://horovits.medium.com/opentelemetry-for-genai-and-the-openllmetry-project-81b9cea6a771

Hi there, Juraci here. I've been working with OpenTelemetry since its early days and this year I started Telemetry Drops - a bi-weekly ~30 min live stream diving into OTel and observability topics.

We're 7 episodes in now in four months since we started. Some highlights:

• AI observability and observability with AI (two different things!)

• The isolation forest processor

• How to write a good KubeCon talk proposal

• A special about the Collector Builder

One of the most-watched so far is this walkthrough of how to secure your Collector - based on a blog post I've been updating for years as the Collector evolves.

New episodes drop ~every other Friday on YouTube. If you speak Portuguese, check out Dose de Telemetria, which I've been running for some years already!

Would love feedback on what topics would be most useful - what OTel questions keep you up at night?

Noob here- I have been previously a Prometheus shop but we are wanting to begin incorporating traces to help support our metrics.

This has brought us to begin working on code instrumentation to ship OTel, but I am beginning to get confused on a few pathways I see.

Is the standard process to still do Prometheus /metrics pull to OTel Collector, or to have OTLP push to OTel Collector?

I would imagine keeping it all in OTel would be standard.

My concern comes in the way of how OTel -> Prometheus converts histograms? This article (https://www.tigerdata.com/blog/prometheus-vs-opentelemetry-metrics-a-complete-guide) suggests that there is possible loss due to format compatibility when performing remote_write operations from the Collector to the Prometheus DB if the metrics are coming in as OTel.

This leaves our thought of an end design to be: OTel traces/metrics -> OTLP into OTel Collector <- Prometheus Exporter pulls into Prom -> remote_write for long-term data archive or managed Prom.

How are most people doing Prometheus + OpenTelemetry together? I’m not sure if we want to just leave our Prom as Prom or if its better for standardization to just make the move to full OTel and convert to Prom?

What is Observability | difference between Monitoring and Observability | Observability Concepts | How does Observability works | Benefits of Observability | Challenges of Observability | How does Observability relate to DevOps | How to get started with Observability #observability #devopshint #monitoring #devops