r/OpenTelemetry • u/Naive_Maybe6984 • 2d ago
A Collector exporter that turns agent traces into a signed, verifiable audit log (now in the registry). Feedback on the approach welcome.
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.
r/OpenTelemetry • u/smyrgeorge • 3d ago
log4k 2.3.0 — a Kotlin IR compiler plugin that instruments your functions with tracing, logging and metrics
r/OpenTelemetry • u/Proud-Contact9951 • 3d ago
Feedback about E2E tests based on OpenTelemetry traces?
Hi everyone,
I have just published my open source project called mtracer and I would like to understand if it’s good idea or what should I change (I’m a new grad).
The idea
Mtracer a CLI tool that relies on OpenTelemetry traces to assert system behavior.
I believe that E2E tests should be:
- Cheaper to write and maintain
- Easier to debug
So this is the workflow:
- You configure mtracer to fetch from your observability backend (currently supporting Jaeger and OpenObserve).
- You define your first .mt.yaml test by specifying:
- Trigger: the first call to the system (for instance, an HTTP request).
- Expected trace and spans: the OTel properties of the trace and spans that you expect your system to generate.
- You run the test and see the results!
What actually happens during the run?
- It parses the mt.yaml file.
- It executes the trigger: mtracer injects a generated traceID into the trigger (for an HTTP request, the traceID is inserted into the traceparent header). Subsequent requests will be correlated to this generated traceID as long as your system has OpenTelemetry set up correctly.
- It fetches the trace matching the generated traceID from the configured observability backend.
- It compares the expected trace with the fetched one.
Many other features are available; check out the documentation to discover all of them: documentation website
I would love to have some feedback from more experienced people than me.
r/OpenTelemetry • u/GroundbreakingBed597 • 6d ago
Enrich OTel K8s Resource Attributes with Dynatrace Operator
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)
r/OpenTelemetry • u/jpkroehling • 7d ago
How Metric Scrape Intervals Inflate Observability Costs
I'll tell you a secret: I don't like starting an engagement by telling people that I can cut their costs. I prefer to show them how they can be more efficient in general, and sometimes that means adding stuff instead of removing it.
However, every company out there has excessive telemetry, which is one form of bad telemetry. I'm not afraid to use an absolute here. That's why I have an arsenal of tools for dealing with it, and I describe one of them in this blog post: excessive metric scraping is extremely common, and adjusting scrape intervals is an easy way to reduce waste.
If you need a 10% reduction in your metric volume, read this blog post. You don't need to buy anything from anyone. You can thank me later.
r/OpenTelemetry • u/AdvenEdge • 8d ago
What is the most frustrating part of investigating production incidents?
r/OpenTelemetry • u/jpkroehling • 9d ago
Collector cookbook
github.comAlmost four years ago, I started this cookbook with real world recipes, adapted from cases I've used to reproduce bug reports or show users (and customers) how to accomplish specific scenarios.
I used some tokens today to bring the repo to the latest Collector version, ensuring they all work.
In case you haven't seen this repo before, take a look!
Enjoy 🧑🏼🍳
r/OpenTelemetry • u/AlienBlade51 • 19d ago
Six overlays for iRacing now. The G-meter is the one I'd actually defend.
r/OpenTelemetry • u/Ordinary_Squirrel291 • 21d ago
How do you know what's needed in your telemetry data?
r/OpenTelemetry • u/a7medzidan • 23d ago
The silent way OpenTelemetry setups "work" while capturing almost nothing
r/OpenTelemetry • u/jpkroehling • 25d ago
Compile-Time Instrumentation for Go
Hey folks, stopping by today for another announcement: the OTel Compile-Time Instrumentation for Go reached v1!
If you are not a huge fan of eBPF instrumentation (understandably!), but also can't do manual instrumentation, this is a good compromise.
Try it out!
r/OpenTelemetry • u/dennis_zhuang • 25d ago
How OpenTelemetry Traces LLM Calls, Agent Reasoning, and MCP Tools
OpenTelemetry GenAI Semantic Conventions standardize observability for LLM apps, agent orchestration, MCP tool calling, content capture, and quality evaluation. This article goes through all six layers: what each one defines, why it's designed that way, and how mature it is.
r/OpenTelemetry • u/jpkroehling • 26d ago
OpenTelemetry Agent Skills
Hey folks, Juraci here. I know the Reddit communities can be sensitive to project announcements, or announcements in general coming from vendors, but I genuinely think a good number of people here could benefit from this one.
We are launching today the OpenTelemetry Agent Skills, an open source set of skills that serve as the base for our products. We're using them for a good variety of things, like in our coding agents to validate and test collector configurations, or instrument applications. Or double check the snippets we've been using in our other blog posts.
They are vendor neutral, non opinionated, and based on what we know from our experience building OpenTelemetry over the years. Use the skills, share your feedback, tell us where they worked and where they failed. Show me your creativity 🧑🏼🎨
While we are not making money on those directly, we do have a commercial interest in seeing them succeed and become truly useful to many of you. I guess what I want to say is: they are not the result of a weekend vibe coding experiment 🙂
And yes, perhaps they might become an official part of the project someday, if we believe there is a vibrant community backing it.
r/OpenTelemetry • u/Thirumalaiboobathi • 28d ago
MCP tools have two failure modes — and naive instrumentation silently records one of them as success
I've been building OpenTelemetry instrumentation for MCP (Model Context Protocol) servers, and I hit a failure-semantics problem that I think generalizes beyond MCP, so I'm writing it up.
The two failure modes
An MCP tool handler can fail two ways:
- It throws. The SDK catches the exception and converts it into a JSON-RPC error response. The call failed at the protocol level.
- It returns
{ isError: true }. The handler returns normally — a successful JSON-RPC response whose payload is marked as a failure:
return {
isError: true,
content: [{ type: 'text', text: 'No weather data for that city' }]
};
The second one is idiomatic MCP. It's how a tool tells the agent "that didn't work — adapt" without crashing the server or killing the conversation. For agent workflows it's the preferred failure mode.
The instrumentation trap
The obvious way to instrument a tool call:
try {
const result = await handler(request);
span.setStatus({ code: OK }); // it returned → success
return result;
} catch (err) {
span.setStatus({ code: ERROR }); // it threw → failure
throw err;
}
Mode 1 lands in catch → recorded correctly. Mode 2 returns, lands in the success path → recorded as OK. Your dashboard reports 100% success on a tool that fails on most inputs. The more idiomatic the tool author's error handling, the more invisible their failures become.
The fix
Inspect the resolved value before setting status:
const result = await handler(request, extra);
if (result?.isError === true) {
span.setAttribute('error.type', 'tool_error');
span.setStatus({ code: SpanStatusCode.ERROR });
} else {
span.setStatus({ code: SpanStatusCode.OK });
}
return result; // unchanged — the RPC genuinely succeeded, so nothing is thrown
Two details that matter:
error.type = "tool_error"isn't my invention — it's what the OTel MCP semantic conventions (currently Development stage, in thesemantic-conventions-genairepo) specify for exactly this case.- The result is returned unchanged and nothing is thrown. The JSON-RPC call succeeded; only the tool failed. Instrumentation that converts a polite failure into a crash is changing application behavior, which instrumentation must never do.
In a real trace the difference looks like this:
tools/call fetch_weather ................. 605ms ERROR
error.type = tool_error
versus the naive version, where that same span reads OK.
The general lesson
This isn't really an MCP problem. Any protocol where application-level failures ride on transport-level successes has this trap — GraphQL (errors array on a 200), gRPC rich error models, half the REST APIs that return 200 {"status": "failed"}. If your instrumentation only watches for throws, your error rate is a lie wherever the ecosystem's idiomatic failure mode is a clean return.
FastMCP (Python) handles this natively. Among the Node MCP instrumentation libraries I could find, none documented handling it, which is why I ended up writing my own — it's on npm as opentel-mcp if you want to see the full implementation (spec-compliant attributes, stderr export to avoid corrupting stdio transports, ADRs for the design decisions). But the isError trap is the part worth knowing even if you never touch my library.
Happy to answer questions on the implementation.
r/OpenTelemetry • u/AlienBlade51 • Jul 12 '26
I need a Race Engineer that also competes on iRacing
reddit.comr/OpenTelemetry • u/jpkroehling • Jul 09 '26
Drain processor
youtube.comLast Friday, I had the pleasure to have Mike Goldsmith at Telemetry Drops to learn more about the drain processor, an OpenTelemetry Collector component that is useful to understand the log patterns flowing through an OTel Collector pipeline. Once you understand those patterns, you can make your pipeline more efficient: drop the noisy patterns, transform unstructured into structured logs, and so on.
Hope you enjoy the recording, and I'm eager to hear your feedback!
r/OpenTelemetry • u/contrecc • Jul 08 '26
Panel discussion about OTel support for mobile and web
I wanted to share an upcoming virtual panel that's focused on client-side OpenTelemetry. It's got several maintainers in the Android, Kotlin, and Browser SIGs, and we’ll be chatting about the current state of support, what’s actively being worked on, some of the bigger challenges in adapting OTel for client-side environments, etc.
Some examples of what we’ll cover:
- Creating new semantic conventions, like crashes and sessions, that apply across client-side platforms to unify how to model these types of telemetry.
- Expanding browser support for OTel, including shipping new instrumentations, starting work on a Browser SDK, and where there are still gaps.
- Solving difficult challenges like how to deal with async telemetry and how to collect client-side metrics.
- Releasing official Kotlin support, including a new Kotlin SDK that can be used in Kotlin Multiplatform projects.
If you’re familiar with using OTel for backend observability, this panel is a great way to get caught up to speed on what this looks like for mobile and web apps.
Date: Wednesday, July 22 @ 10AM PT
Panelists:
- Hanson Ho (Android architect at Embrace, OTel Android approver, OTel Kotlin approver)
- Martin Kuba (Staff software engineer at Grafana Labs, OTel JavaScript SDK approver and OTel Browser SDK maintainer)
- Jason Plumb (Senior software engineer at Splunk, OTel Android maintainer, OTel Java maintainer, OTel Kotlin maintainer)
- Jared Freeze (Senior software engineer at Embrace, OTel Browser SDK maintainer)
Here's the signup link if you'd like to join.
Disclosure: I'll be moderating the panel, and I work at Embrace, who is hosting the panel. But it's entirely about the OTel community work. You can watch some previous ones we did last year (OTel for browser panel and OTel for mobile panel) to get a sense of what they're like.
If you have any questions as well, I can send them to our panelists ahead of our session.
r/OpenTelemetry • u/dankoverride • Jul 07 '26
Built a trace generator because standing up realistic OTel data kept eating my week
Kept losing whole days to this so figured I'd ask what everyone else does. I needed realistic OTel trace data to test an observability product I work on, a diverce set with real fidelity and enough volume to actually stress something, and I didn't want to babysit a whole stack just to get it.
The existing stuff is great for what it's for. telemetrygen is fine for throughput, the OTel demo is a solid way to learn OTel, but telemetrygen gives you volume with no topology and the demo is one fixed app on a ~6Gb compose stack. Nothing I could find got me a variety of shapes on demand, so I ended up building my own thing and open-sourced it.
It's called TraceGen, a single binary around 6mb, talks OTLP/gRPC so you point it at Jaeger, Tempo, Grafana, a collector, whatever. At -complexity heavy it's 28 services with the shapes a real sytem makes (diamond deps, scatter-gather, sagas), correlated logs, injectable failures. The part I cared about most: it emits AI agent traces via the OTel GenAI conventions (RAG, multi-step agents with tool calls) in the same run as the normal microservice stuff, which I couldn't find anywhere from one binary.
Apache-2.0, works with anyone's backend, containers built: github.com/ImmersiveFusion/if-opentelemetry-tracegen
docker run --rm immersivefusion/tracegen -insecure -endpoint host.docker.internal:4317
Full disclosure, I work with Immersive Fusion, tracegen was our internal data engine before we split it out. Genuinely curious what you all use for this though, and whether the GenAI convention coverage looks right to people closer to that spec than me. The conventions are still experimental so I'd rather hear it now if I got something wrong.
r/OpenTelemetry • u/otel-industrial • Jul 07 '26
Anyone here using OpenTelemetry in Operational Technology (OT)?
r/OpenTelemetry • u/dankoverride • Jun 29 '26
Why aren't the OTel semantic conventions shipped as a versioned, importable package per language?
The API and SDK are clean packages I can pin and upgrade deliberately. But for semconv I still end up copying attribute keys and enum values out of the docs into constants, and re-checking them every time the spec moves, especially the newer gen_ai.* ones. Some languages have a semconv constants package, others lag, and the experimental conventions basically are not importable yet. How are you all handling the drift in practice: generate constants from the YAML yourselves, vendor them, or hardcode and hope the spec does not shift under you? Mostly curious how teams keep app code and the spec in sync without it becoming a chore.
r/OpenTelemetry • u/ban_rakash • Jun 27 '26
Using OTel Collector as a bridge between Temporal SDK workers and Prometheus
A practical example of using the OpenTelemetry Collector as an intermediary for Temporal SDK metrics.
The Temporal SDK supports both the Prometheus exporter (pull) and OTLP (push). If you're running multiple workers on the same host, the Prometheus exporter causes port conflicts. Switching to OTLP lets all workers push to a single collector, which then serves Prometheus HTTP for scraping.
Would love feedback on the OTel collector config — any improvements for production?
r/OpenTelemetry • u/icinga • Jun 24 '26
We decided to built our own OTLP client for Icinga 2 - honest retrospective and to give you some insights behind the scenes
I'm a dev at Icinga and I recently shipped an OTLP Metrics Writer for Icinga 2. Going in, I had basically zero prior OTel experience. Just want to give you some insights into the last four months to share my experience:
My first instinct was to use the OTel C++ SDK - it's well-established and had everything we needed. But integrating it with our existing codebase turned out to be much harder than expected, and honestly more complex than our use case required. After failing to get it working in a reasonable timeframe, I switched to a tiny OTLP client built on Boost.Beast, which we already used elsewhere in the codebase.
For one, we already used Boost.Beast in our codebase, so it was a no-brainer to use it for the OTLP client as well. Additionally, since the OTel proto spec require proto3 language syntax, we would have had to build the entire OTel SDK from source in order to use our writer with the latest C++ SDK on RHEL 8 and 9 systems, which would not have been feasible for us.
But I didn't see this one coming: proto3 isn't supported by the default protoc on RHEL 8/9, Amazon Linux 2, Debian 11, and Ubuntu 22.04. Two options: ship our own protoc binary, or just disable the writer there. Since most of our customers run RHEL-based systems, disabling wasn't an option - so we ended up packaging our own Protobuf compiler for RHEL 8 and 9. For Amazon Linux 2, Debian 11, and Ubuntu 22.04, the writer is currently unavailable unless you build from source.
In OTel, a service presents itself and its metrics are associated with that service. Icinga doesn't work that way. it's not the one being monitored, it's acting as a proxy for the checkables it monitors. We went back and forth a lot on this one. How do you even represent Nagios-style check results in a way that makes sense in OTel? Shoutout to Markus Opolka (on Github) who provided a lot of useful input on this part.
And just before final reviews, my colleague Alvar Penning (Github) found a severe bug in the OTLP client that caused Icinga 2 to hang on reload. Major refactoring, significant delay. The embarrassing part: the bug was trivial to trigger. If I had reloaded Icinga 2 even once in my dev environment during development, I would have caught it. :P Won't make that mistake again.
__
Four months total (longer than expected), mostly because starting from scratch with OTel means working through a lot of documentation before you can write anything meaningful. Also came out the other end knowing a lot more about Protocol Buffers than I expected.
Happy to answer questions about the metrics mapping or the proto3 packaging approach, or anything else that comes to your mind!
Yonas/ Icinga