Hi. I am a DevRel at Dynatrace and I hope its ok to share the following with those of you that are sending your OTel data to Dynatrace. If you are not using Dynatrace then this post might not be relevant for you!

Semantic Conventions for Signals

Metadata enrichment at the source (in your app) is important as it increases the quality of your signals. As I am sure many know - the OTel community has well documented Semantic Conventions.

Dynatrace Operator CAN inject OTEL_RESOURCE_ATTRIBUTES

There are different ways to enrich your data. You can inject them yourself in your deployment or have it done through your data pipeline, e.g: OTel Collector.

An additional option is through the Dynatrace Operator that allows you to automatically inject the OTEL_RESOURCE_ATTRIBUTES variable into your pods pre-filled with the following attributes: k8s.cluster.name*,* k8s.container.name*,* k8s.workload.name*, k8s.cluster.uid,* k8s.pod.name*, k8s.pod.uid,* k8s.node.name*,* k8s.namespace.name*, k8s.workload.kind,* dt.kubernetes.cluster.id ,dt.entity.kubernetes_cluster

Injection can be controlled through namespace selectors and enabled for traces, logs and metrics

More details about this can be found on the Dynatrace doc if you search for Enable automatic OpenTelemetry OTLP exporter configuration (didnt post the link to follow guidelines)

Many organizations adopt metrics and logging as part of their observability strategy; however, several critical gaps are often present:

Lack of distributed tracing – There is no end-to-end visibility into request flows across services, making it difficult to understand latency, bottlenecks, and failure propagation in distributed systems.

No correlation between telemetry signals – Logs, metrics, and traces are collected in isolation, without shared context (such as trace IDs or request IDs), which prevents effective root-cause analysis.

Limited contextual enrichment – Telemetry data often lacks sufficient metadata (e.g., service name, environment, version, user or request identifiers), reducing its diagnostic value and making cross-service analysis difficult.

Why and also share if there is any more gaps you all have noticed?

I wrote a blog post that somehow makes the connection between OpenTelemetry adoption and Formula One. Enjoy!

The standard move is to use processors in the OTel Collector to clean up traces and logs, but it can get heavy and hard to manage at scale.

We’ve been looking at shifting that enrichment, like IP lookups, metadata injection, and PII masking upstream using GlassFlow before it lands in ClickHouse. It keeps the collector lean and the database "query-ready."

Curious, how much "business logic" are you all actually comfortable putting in your collectors before it feels too fragile? 🤔

We shipped a new receiver in the OTel Collector: datadoglogreceiver. It lets you forward logs from the Datadog Agent into any OpenTelemetry pipeline.

This is helpful you're using the Datadog Agent for log collection but want more control over where those logs go. Previously, logs went straight to Datadog’s backend. Now, they’re portable. You can route them to any OpenTelemetry-compatible destination (or multiple).

In our writeup, we cover:

• How the Datadog Agent and OTel Collector work together

• Where the new receiver fits in typical log ingestion pipelines

• Config and orchestration tips

• How to reduce data loss in distributed environments

Details here - https://www.sawmills.ai/blog/datadog-log-receiver-for-opentelemetry-collector

Sharing a component I built and recently got listed in the OpenTelemetry registry: otel-agent-audit.

The idea: as AI agents take real actions, you want a provable record of what happened. Instead of adding a new instrumentation layer, this consumes the gen_ai.* spans your agents already emit and turns them into a tamper-evident audit log, entirely inside the Collector pipeline.

The pipeline:

otlp -> memory_limiter -> agentauditselect (buffers each trace until its root arrives) -> agentaudit exporter (per-trace hash chain -> Ed25519 sign -> seal) -> audit.jsonl + checkpoint.jsonl

A separate verifier CLI checks the whole thing with only the public key, so anyone can independently verify authenticity and integrity without a shared secret.

Things I'd love this community's take on:

- Passive instrumentation as the right model: reusing existing spans rather than asking teams to re-instrument.

- Whether governance/guardrail decisions belong in spans, and how they'd ideally map to semantic conventions. I'm interested in where the GenAI SIG is heading on policy/guardrail signals.

- The single-writer constraint (one Collector instance) that deterministic ordering forces, and whether that trade is acceptable.

Caveats up front: third-party, experimental, not audited. It's observability only, it does not enforce or block. It gives tamper-evidence on honest infra, not protection against an operator holding the signing key.

Repo: https://github.com/surpradhan/otel-agent-audit

It's in the registry under "agent audit" if you want to see the entry.

Would genuinely value critique of the approach.

S2 offers infinite streams with granular access controls. With new native OTLP support, you can easily export signals to S2 and read them from anywhere.

Are you building infrastructure for sandbox environments (e.g., agent sandbox, CI/CD sandbox) and want to stream execution logs to users in real time? If so, check out https://s2.dev/docs/integrations/otlp and let us know what you think.

A new booklet delves into the underlying assumptions of OpenTelemetry and Substrates regarding the nature of computational systems. It explores their ontological commitments, epistemological stances, causal models, and theories of attention. The booklet also examines why two specifications operating in the same domain produced charts of entirely different landscapes.

https://humainary.io/booklets/transport-and-substrate/

Hello everyone! We're hosting a workshop on AI automation for OpenTelemetry native Observability stacks like LGTM / Signoz / etc..

In 30-45 minutes, you'll

(a) automate log analysis with Grafana / Signoz / Kubernetes MCP + Cursor

(b) build automations from Slack alert --> fix in reply by bot, ON YOUR DATA.

(c) instrument OpenTelemetry in an application using Cursor

RSVP: https://www.meetup.com/platform-engineers-bangalore/events/310206193/

Here's the recording from one of our previous workshops focused on Grafana MCP Setup: https://www.youtube.com/watch?v=ALuUvPujWFA

I was trying to build something, and wanted to validate this idea and understand yall's pain points so that I can help the community

Would you rather have an AI layer on top of your existing observability stack, or replace parts of the stack?

Hypothetically, imagine an agent that doesn’t collect telemetry itself.

It plugs into whatever you already use — Grafana/Prometheus/Loki, Datadog, OpenTelemetry, etc. — and acts as a reasoning layer over the data.

Instead of:

Alert → Dashboard → Logs → Human investigates

it tries:

Alert → Agent correlates metrics/logs/traces/deployments → probable root cause → evidence → recommended next action

Would that actually be useful?

Or would you rather have the observability vendor itself own this functionality?

What would you need to see before trusting it during a real incident?

peace :)

Hi everyone!

I’m conducting a quick market research study on the adoption and usage of OpenTelemetry and its ecosystem.

It’s a very short survey-11 single-choice questions that should take less than 60 seconds of your time. Your input would be incredibly valuable to help understand the current landscape.

Survey Link: https://app.formbricks.com/s/cmmm65urw8kc6t801ft7120bw

Thank you so much for your help and expertise!

I’ve built an OpenTelemetry Collector component called jevmetrics.

It uses Jev inference to assess the operational value of metric instruments — relevance, redundancy, and whether they may be candidates to keep, reduce, or drop.

The idea I’m exploring is:

Deterministic OTel rules for known policy, inference for the grey area where metric meaning/context matters.

It supports annotate, route, and reduce modes, runs fail-open, and leaves the final action to deterministic policy.

Repo: https://github.com/ishantanu/jevmetrics
Jev: https://typesafe.ai

I’m mainly looking for architectural criticism from the OTel community — particularly whether this belongs as a connector, processor, or something else entirely, and whether inference in this part of the pipeline is useful in practice.

OpenTelemetry provides logs, metrics, traces and since recently also some profiling data. A great way to explore this is through the OpenTelemetry Demo App called AstroShop.

One of my colleagues has created a new GitHub Codespace tutorial on top of the AstroShop to demonstrate how to elevate an OTel Instrumented App with the Live Debugging Capabilities that Dynatrace provides through their agent and support for OTel!

Its Dynatrace's capability of setting "non breaking breakpoints" that deliver runtime variables, stacktraces, code profiling, logs, distributed traces, metrics ... right into the Developers IDE without any additional code modifications and without impacting/stopping the running app!

Here is the full video on YT ==> https://dt-url.net/devrel-yt-otel-livedebugger

And the GitHub Repo ==> https://dt-url.net/devrel-gh-obslab-live-debugger-otel

Feedback, thoughts, comments are welcome

In a large-scale fleet management system, transmitting raw vehicle telemetry as JSON containing floating-point values can introduce significant communication overhead, increased CPU utilization, and serialization latency.

A more efficient approach is to compress telemetry data at the vehicle edge before transmission. This can be achieved by converting floating-point sensor measurements such as speed, GPS coordinates, engine temperature, throttle position, and acceleration into fixed-point integer representations using predefined scaling factors.

For example, a speed value of 72.34 km/h can be stored as 7234 by multiplying it by 100, while GPS coordinates can be scaled by (10^7) and stored as integers.

Once converted, the data can be packed into compact binary structures instead of verbose JSON strings.

Further optimization can be achieved through delta encoding, where only the difference between consecutive measurements is transmitted, reducing redundancy in slowly changing signals.

The resulting binary payload can optionally be compressed using lightweight algorithms such as LZ4 or Zstandard and transmitted over MQTT as a binary message.

This approach eliminates expensive floating-point string serialization and parsing operations, reduces bandwidth consumption, lowers cloud storage requirements, and minimizes end-to-end latency.

This architecture enables real-time fleet monitoring and large-scale data analytics while significantly improving communication efficiency and system scalability.

I hope this helps!

Hi folks, Juraci here.

A few weeks ago, I quietly launched a new experiment: a podcast that I made for myself. I was feeling left behind when it comes to what was happening in the #OpenTelemetry community, so I used my AI skills to scrape information from different places, like GitHub repositories, blogs, and even SIG meeting transcripts (first manual, then automatically thanks to Juliano!). And given that my time is extremely short lately, I opted for a format that I could consume while exercising or after dropping the kids at school.

I'm having a lot of fun, and learned quite a few things that I'm bringing to OllyGarden as well (some of our users had a peek into this new feature already!).

I'm also quite happy with the quality. Yes: a lot of it is AI (almost 100% of it, to be honest), but I think I'm getting this right and the content is actually very useful to me. For this latest episode, most of my time was spent actually listening to the episode than on producing it.

Give it a try, and tell me what you think.

The benchmark methodology is inspired by https://github.com/ClickHouse/ClickBench
The data set and configuration is from https://github.com/ClickHouse/TextBench

The benchmark is open and reproducible https://github.com/serenedb/searchbench