# OpenTelemetry OpenTelemetry is an open-source observability framework for cloud-native software that provides APIs, libraries, agents, and collector services for capturing distributed traces and metrics. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## WSO2 Releases Agent Manager as Enterprises Look to Control Growing AI Agent Sprawl DevFeed: [WSO2 Releases Agent Manager as Enterprises Look to Control Growing AI Agent Sprawl]() Original publisher: [Read original article]() Author: Craig Risi Published: 2026-09-18T12:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [AI Agent](), [Artificial Intelligence](), [Authorization](), [Security](), [Deployment](), [Kubernetes](), [Model Context Protocol](), [OpenTelemetry]() Tags: [agent-identity](), [agentic-ai-architecture](), [ai](), [ai-agent](), [ai-agents](), [ai-development](), [ai-ml-data-engineering](), [aiops](), [authorization](), [deployment](), [devops](), [governance](), [kubernetes](), [ml-data-engineering](), [model-context-protocol](), [news](), [opentelemetry](), [ws02-agent-manager](), [ws02-stratos]() ### AI overview WSO2 has released Agent Manager, an open-source platform for governing AI agents across models, frameworks, and deployment environments. The general availability release adds agent identity and authorization, MCP governance, lifecycle controls, a Kubernetes-native sandboxed runtime, and OpenTelemetry-based tracing and evaluation. ### Source excerpt WSO2 has announced the general availability of WSO2 Agent Manager, an open-source platform designed to provide centralized governance, identity management, security controls, and operational oversight for AI agents running across different models, frameworks, and deployment environments. By Craig Risi ## Building an Internal Developer Platform with Artificial Intelligence DevFeed: [Building an Internal Developer Platform with Artificial Intelligence]() Original publisher: [Read original article]() Author: Ben Linders Published: 2026-09-17T11:11:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [internal developer platform](), [AI Development](), [AI search](), [agent observability](), [OpenTelemetry](), [telemetry]() Tags: [agent](), [agents](), [artificial-intelligence](), [culture-methods](), [developer-experience](), [developer-platform](), [distributed-tracing](), [guardrails](), [internal-developer-platform](), [logging](), [logs](), [metrics](), [news](), [opentelemetry](), [platform-artificial-intelligence](), [platform-engineering](), [prometheus](), [traces]() ### AI overview This news article covers a KubeCon presentation about using AI agents as an internal developer platform. It discusses semantic search across sources such as Git, Slack, Jira, repositories, pull requests, and wiki pages; guardrails for controlling actions; and logs, metrics, and traces for understanding agent behavior. The speakers also describe OpenTelemetry conventions for GenAI and related observability tools. ### Source excerpt Agents are becoming the new developer platform, using semantic search with data from tools like Git, Slack, and Jira for context. Things to consider are setting guardrails to block or allow things, and using logs, metrics, and traces to understand agent behavior. By Ben Linders ## OpenTelemetry everywhere: Migrating a metrics platform at scale DevFeed: [OpenTelemetry everywhere: Migrating a metrics platform at scale]() Original publisher: [Read original article]() Author: Iris Grace Endozo, Farzad Vazirnia and Albert Kerr, Atlassian Published: 2026-09-17T11:00:00Z Content type: article Language: en Sources: [Cloud Native Computing Foundation]() Topics: [OpenTelemetry](), [migration](), [observability](), [telemetry](), [atlassian](), [Open Source]() Tags: [atlassian](), [blog](), [collector](), [metrics](), [migration](), [observability](), [opentelemetry](), [pipeline](), [scale](), [sidecar]() ### AI overview Atlassian describes replacing a large-scale gostatsd metrics pipeline with OpenTelemetry while preserving the existing StatsD interface for service teams. The migration uses purpose-built OpenTelemetry Collector distributions across collection, ingest, aggregation, and forwarding stages, with support for both StatsD and OTLP during the transition. ### Source excerpt Why we did this at all For most of the last decade our metrics pipeline ran on gostatsd, the open-source StatsD implementation we maintain. It primarily did two jobs: as sidecar on every host and the... ## Agent Anomaly Detection, now in Private Preview on the Gemini Enterprise Agent Platform DevFeed: [Agent Anomaly Detection, now in Private Preview on the Gemini Enterprise Agent Platform]() Original publisher: [Read original article]() Author: Achuth Narayan Rajagopal Published: 2026-09-17T01:25:27.608736Z Content type: release Language: en Sources: [Google Developers Blog]() Topics: [agent observability](), [OpenTelemetry](), [Security](), [Traces](), [API]() Tags: [agent](), [anomaly-detection](), [api](), [autonomous-agents](), [gemini](), [opentelemetry](), [security]() ### AI overview Google announces Agent Anomaly Detection in private preview on the Gemini Enterprise Agent Platform. The feature analyzes agents' reasoning traces, tool calls, logs, and execution flows to identify behavioral anomalies, suspicious intent, and policy violations. ### Source excerpt Agent Anomaly Detection is a new, out-of-band oversight layer for the Gemini Enterprise Agent Platform that analyzes OpenTelemetry traces and tool calls to catch behavioral risks without adding runtime latency to live requests. It utilizes a multi-tiered detection pipeline--combining lightweight statistical scanning with deep LLM-based reasoning--to identify logical anomalies and policy violations grounded in the OWASP Agentic Top 10. Developers can triage these automated findings within Security Command Center or leverage the exposed API to programmatically block subsequent tool calls when an agent breaches defined risk thresholds. ## Behind the Scenes: How the OpenTelemetry Plugin Maps Your Microservices in Real-Time DevFeed: [Behind the Scenes: How the OpenTelemetry Plugin Maps Your Microservices in Real-Time]() Original publisher: [Read original article]() Author: Egor Klimov Published: 2026-09-16T12:34:47Z Content type: article Language: en Sources: [The JetBrains Blog]() Topics: [OpenTelemetry](), [Microservices](), [observability](), [telemetry](), [Traces](), [ide]() Tags: [all-things-web](), [backstage](), [environment-variables](), [goland](), [ide](), [idea](), [intellij-idea](), [intellij-platform](), [jetbrains](), [microservices](), [observability](), [opentelemetry](), [performance-optimization](), [plugin-development](), [plugin-highlights](), [plugins](), [pycharm](), [research](), [rider](), [telemetry](), [traces](), [webstorm]() ### AI overview This article explains how the JetBrains OpenTelemetry Plugin generates a service map from runtime telemetry. It describes using logs, metrics, and especially standardized trace spans to visualize how microservices communicate, along with the plugin's lightweight local OpenTelemetry backend. ### Source excerpt We've all been there: you join a new project, and the first thing you ask for is the architecture diagram. You're handed a diagram that looks great, but after a week of debugging, you realize it's six months out of date. Service A hasn't talked to Service B since the spring, and there's a new [...] ## Kubernetes attributes processor reaches v1.0.0 milestone DevFeed: [Kubernetes attributes processor reaches v1.0.0 milestone]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-09-16T04:59:27Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [telemetry](), [releases](), [Kubernetes](), [Go Language]() Tags: [api](), [go](), [kubernetes](), [opentelemetry](), [releases](), [stable](), [telemetry]() ### AI overview The Kubernetes attributes processor has reached version 1.0.0 and fulfills OpenTelemetry's stability criteria for testing, benchmarking, documentation, and telemetry. The release also supports redistribution as a Go library or in binaries without API breakage. ### Source excerpt The Kubernetes attributes processor, which enriches your telemetry with Kubernetes metadata, has officially moved to v1.0.0! You can try it out on your custom distro, and it is also available as part of the latest opentelemetry-collector-contrib and opentelemetry-collector-k8s distro releases. Being v1.0.0 means the component is now verified to fulfill the 'stable' stability criteria including requirements around testing, benchmarking, documentation and telemetry stability. It also ensures you can redistribute it as a Go library or as part of your binaries without API breakage. ## Atlassian Automates Root Cause Analysis by Correlating Metrics, Logs and Traces DevFeed: [Atlassian Automates Root Cause Analysis by Correlating Metrics, Logs and Traces]() Original publisher: [Read original article]() Author: Craig Risi Published: 2026-09-15T12:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [incident](), [atlassian](), [telemetry](), [SIEM, Security, Observability](), [tracing](), [Cloud Native Ecosystem](), [OpenTelemetry]() Tags: [atlassian](), [atlassian-automated-rca](), [cloud-native](), [defects](), [devops](), [distributed](), [incident](), [incident-response](), [logging](), [logs](), [metrics](), [news](), [opentelemetry](), [root-cause-analysis](), [services](), [telemetry](), [traces](), [tracing]() ### AI overview Atlassian has outlined an approach to automating root cause analysis for large-scale cloud-native incidents. It correlates metrics, logs, distributed traces, and service topology to detect anomalies, align them in time, trace dependencies, and produce ranked hypotheses about likely fault origins and propagation paths. ### Source excerpt Atlassian has outlined a new approach to automating root cause analysis for large-scale cloud-native incidents, using correlation across metrics, logs, distributed traces, and service topology to generate ranked hypotheses about where failures originate and how they propagate. By Craig Risi ## Grab's LLM-Kit Framework Standardizes More Than 500 Internal Agent Services DevFeed: [Grab's LLM-Kit Framework Standardizes More Than 500 Internal Agent Services]() Original publisher: [Read original article]() Author: Hien Luu Published: 2026-09-15T09:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Framework](), [AI Agent](), [Deployment](), [Model Context Protocol](), [agent observability](), [FastAPI](), [OpenTelemetry](), [GitLab]() Tags: [agent](), [agents](), [ai](), [ai-agent](), [ai-ml-data-engineering](), [deployment](), [fastapi](), [framework](), [gitlab](), [grab-agent-platform](), [ml-data-engineering](), [model-context-protocol](), [news](), [opentelemetry](), [vault]() ### AI overview Grab's internal LLM-Kit framework standardizes more than 500 agent services by providing shared scaffolding for evaluation, tracing, secret handling, service discovery, and tool-server connections. The article reports that deploying a new agent service now takes about one hour instead of two weeks or more. ### Source excerpt Grab has implemented LLM-Kit, a framework that standardizes over 500 internal agent services. This system enhances service integration, evaluation, and secret handling, reducing the time to deploy new AI agents from two weeks to one hour. It centralizes infrastructure management, allowing runtime tool discovery and flexible model integration, while maintaining operational control. By Hien Luu ## Inside the LLM Call: GenAI Observability with OpenTelemetry DevFeed: [Inside the LLM Call: GenAI Observability with OpenTelemetry]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-09-14T16:56:42Z Content type: tutorial Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [agent observability](), [telemetry](), [AI Agent](), [Large Language Model]() Tags: [agent](), [ai-agent](), [claude-code](), [codex](), [observability](), [opentelemetry](), [token](), [tool](), [visibility]() ### AI overview This tutorial explains how OpenTelemetry Semantic Conventions for Generative AI record LLM calls, tool invocations, token counts, and related events. It demonstrates exporting telemetry from an LLM-powered application, viewing it with Aspire Dashboard, and considering sensitive-data implications of optional content capture. ### Source excerpt Your AI agent just took 45 seconds to answer a simple question. Was it the model? A slow tool call? A retry loop? Every time an application calls an LLM, a chain of model calls, tool invocations, and token exchanges happens behind the scenes -- and without observability, you are guessing. The OpenTelemetry Semantic Conventions for Generative AI give you that visibility. They standardize how GenAI operations are recorded -- the model being called, input and output token counts, and when opted in, the full content of prompts, completions, tool calls, and tool results. ## Datadog named the Company to Beat for observability platforms in 2026 Gartner® AI Vendor Race report DevFeed: [Datadog named the Company to Beat for observability platforms in 2026 Gartner® AI Vendor Race report]() Original publisher: [Read original article]() Author: Yanbing Li Published: 2026-09-14T00:00:00Z Content type: article Language: en Sources: [Datadog | The Monitor blog]() Topics: [observability](), [agent observability](), [observability ai agents](), [incident](), [MCP Server](), [observability pipelines](), [OpenTelemetry](), [Security](), [Artificial Intelligence]() Tags: [agent-observability](), [ai-agents](), [datadog](), [incident-response](), [mcp-server](), [observability](), [observability-pipelines](), [opentelemetry]() ### AI overview Datadog says it was named the Company to Beat for observability platforms in Gartner's August 2026 AI Vendor Race research and a Leader in the 2026 Gartner Magic Quadrant for Observability Platforms. The article presents Datadog's unified observability and security platform, including autonomous incident investigation, AI agent and LLM application observability, an MCP Server for querying telemetry, and Observability Pipelines with OpenTelemetry support. ### Source excerpt Datadog has been recognized as the Company to Beat for observability platforms in the August 2026 Gartner® AI Vendor Race research. ## Wrapture: a Python package for monkey patching, testing, and observability DevFeed: [Wrapture: a Python package for monkey patching, testing, and observability]() Original publisher: [Read original article]() Author: Simon Willison Published: 2026-09-11T13:51:32Z Content type: opinion Language: en Sources: [Simon Willison's Weblog]() Topics: [Python](), [Testing](), [observability](), [Instrumentation](), [tracing](), [OpenTelemetry](), [Flask](), [jupyterlab]() Tags: [code](), [graham-dumpleton](), [graham-dumpleton-6](), [how-to](), [instrumentation](), [monkey-patching](), [monkey-patching-10](), [observability](), [observability-10](), [open-source](), [open-source-320](), [opentelemetry](), [python](), [python-1-283](), [testing](), [testing-95](), [tracing]() ### AI overview This article reviews wrapture, an alpha Python package by Graham Dumpleton for monkey patching, unit testing, call recording, live and zero-code tracing, timing analysis, and OpenTelemetry export. It highlights tutorials and JupyterLab workshops covering the package and related instrumentation. ### Source excerpt Graham Dumpleton's new monkey patching package wrapture is shaping up to be an indispensable tool for Python developers. I'm not sure why I've seen so little buzz about it! Graham has been posting new tutorials for it almost daily since the initial release on August 31st. Here's everything he's published so far: Introducing wrapture - a new monkey patching library that serves both testing and observability (think New Relic style tracing) at the same time. Unit testing with wrapture - how to use it for the same kinds of thing as unittest.mock. Recording calls with wrapture - recording method calls as timelines and processing and displaying them as trees. Phased behaviour in wrapture - arranging patched methods to change behavior across multiple calls. Beyond callables in wrapture - monkey patching attributes, dictionaries, generators. Live tracing with wrapture - tracing a live application to see exactly how it works. Zero-code tracing with wrapture - configuring tracing in a separate TOML file without modifying Python code at all. Tracing Flask with wrapture - using the separate wrapture-instrumenation package to instrument a Flask application. That package also provides instrumentation for aiohttp.client, aiohttp.web, django, fastapi, flask, grpc, http.client, httpx, jinja2, requests, sqlalchemy, sqlite3, starlette, urllib.request, urllib3, uvicorn, werkzeug.serving, wsgiref.simple_server, xmlrpc.client, xmlrpc.server. Finding slow code with wrapture - wrapture's tools for recording timing information, both individually and aggregated across multiple calls. OpenTelemetry export in wrapture - exporting traces to OpenTelemetry. Graham also has a set of interactive workshops for wrapture, implemented as JupyterLab notebooks. Wrapture is still alpha software but it's already very usable - especially given you can configure and try it out with a TOML file without modifying any Python code at all. This feels like one of those Swiss Army Knife packages that, once mastered ## OpenTelemetry proposes environment variables for context propagation across processes DevFeed: [OpenTelemetry proposes environment variables for context propagation across processes]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-09-11T11:01:22Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [context](), [tracing](), [OpenTelemetry](), [Processes](), [CI/CD](), [data-processing]() Tags: [ci-cd](), [data-processing](), [environment-variables](), [opentelemetry](), [processes](), [spans](), [tracing](), [w3c]() ### AI overview The OpenTelemetry Specification has a release candidate for using environment variables to carry trace context and baggage between processes. The article explains how this can connect spans across workflow runners, shells, build tools, test processes, and similar workloads when protocol headers or message metadata are unavailable, and requests feedback before the specification becomes Stable. ### Source excerpt A trace does not always cross a network boundary. A workflow runner starts a shell, the shell launches a build tool, and the build tool starts test processes. Batch and data-processing systems create similar chains of child processes. Without a shared way to pass trace information across these boundaries, spans from each process can end up in separate traces. If context propagation is new to you, it is the mechanism that carries information from one service or process to the next. For tracing, this includes the trace and span identifiers that let new spans join the same trace. It can also carry baggage: application-defined key-value pairs that are passed to downstream work. ## OpenTelemetry Go Logs API and SDK reach release candidate status DevFeed: [OpenTelemetry Go Logs API and SDK reach release candidate status]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-08-31T15:40:58Z Content type: release Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [Go Language](), [releases](), [SDKs](), [Logging]() Tags: [api](), [beta](), [experimental](), [go](), [opentelemetry](), [release](), [sdk](), [version]() ### AI overview OpenTelemetry Go v1.47.0-rc.1 promotes the Logs API and SDK to release candidate status. The release moves these modules from beta stability toward stable v1 compatibility guarantees, while log exporters and logtest remain experimental and outside the RC scope. ### Source excerpt OpenTelemetry Go v1.47.0-rc.1 is here. This release promotes the Logs API and SDK to release candidate (RC), the final stage before we provide stable v1 compatibility guarantees. We believe the design is ready, and now we need the community to test it in real applications and integrations before those guarantees take effect. What is included in the release candidate? The RC covers these two modules: go.opentelemetry.io/otel/log go.opentelemetry.io/otel/sdk/log These modules move from v0.22.0, with beta stability, to v1.47.0-rc.1. The version aligns them with the other stable OpenTelemetry Go modules, which share a coordinated version number. The log exporters and logtest modules remain experimental and are not covered by this RC's stability scope. ## nixos-telemetry: A NixOS flake for opt-in observability pipelines DevFeed: [nixos-telemetry: A NixOS flake for opt-in observability pipelines]() Original publisher: [Read original article]() Author: palo Published: 2026-08-23T08:27:36Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [telemetry](), [OpenTelemetry](), [Tooling](), [log management](), [Prometheus](), [Grafana](), [Grafana Alloy]() Tags: [announcements](), [collector](), [config](), [grafana](), [grafana-alloy](), [loki](), [opentelemetry](), [prometheus](), [telemetry]() ### AI overview A discussion introduces nixos-telemetry, a NixOS flake that uses an OpenTelemetry collector to connect opt-in scrapers, storage, and visualization components. It supports local stacks, remote forwarding, and fan-out to multiple sinks through a unified option tree. ### Source excerpt Hi everyone, I'd like to share nixos-telemetry, a NixOS flake that makes setting up observability in your infrastructure easy. An OpenTelemetry collector sits at the center of each machine. Scrapers, storage, and visualization are all opt-in. You enable what you need; the collector wires the pipeline together automatically. Why? Wiring up telemetry in NixOS today means gluing together Telegraf, Prometheus, Loki, Grafana, Alloy, each with its own config format, ports, and inter-service dependencies. nixos-telemetry puts all of that behind a single telemetry.* option tree: Turn on the system with telemetry.enable = true. Every app is opt-in. Nothing starts that you didn't ask for. The collector starts automatically once a complete pipeline exists, a matching source and sink for the same signal type. No sink? It waits. Forward to a remote collector, run a full local stack, or both. Fan-out to multiple sinks is supported. What it looks like Full local stack on one machine: { telemetry.enable = true; telemetry.telegraf.enable = true; # host metrics telemetry.alloy.enable = true; # journald logs telemetry.prometheus.enable = true; # metrics storage telemetry.loki.enable = true; # logs storage telemetry.grafana.enable = true; # visualization (datasources auto-provisioned) } Forward to a remote collector: # machine 1 { telemetry.enable = true; telemetry.telegraf.enable = true; telemetry.opentelemetry.exporter.endpoints.remote = "100.64.0.1:4317"; } # machine 2 { telemetry.enable = true; telemetry.opentelemetry.receiver.endpoint = "0.0.0.0:4317"; } Full option reference: OPTIONS.md Thanks! Regarding Discourse LLM Policy : I must disclose that substantial parts of this project are llm generated. And because I coppied parts of the README in this post, substantial parts of this announcmement too. 27 posts - 7 participants Read full topic ## Observing AI Agent Decisions with OpenTelemetry DevFeed: [Observing AI Agent Decisions with OpenTelemetry]() Original publisher: [Read original article]() Author: Raul Junco Published: 2026-08-22T12:06:38Z Content type: article Language: en Sources: [System Design Classroom]() Topics: [agent observability](), [OpenTelemetry](), [Artificial Intelligence](), [telemetry](), [Back end]() Tags: [agent](), [ai](), [ai-agent](), [opentelemetry](), [telemetry](), [traces]() ### AI overview A practical guide to observing AI agent decisions with OpenTelemetry. It explains why conventional logs, metrics, and distributed traces may not show whether agents chose the correct workflow, and argues that decision recording and observation should be in place before production. ### Source excerpt A practical guide to observing AI decisions with OpenTelemetry ## Control trace volume with OpenTelemetry tail-based sampling DevFeed: [Control trace volume with OpenTelemetry tail-based sampling]() Original publisher: [Read original article]() Author: Bill Meyer; Eddie Cai Published: 2026-08-21T00:00:00Z Content type: tutorial Language: en Sources: [Datadog | The Monitor blog]() Topics: [OpenTelemetry](), [Traces](), [tracing](), [observability](), [Application Performance Management (APM)](), [configuration](), [Latency]() Tags: [apm](), [architecture](), [distributed-systems](), [how-to](), [latency](), [learn](), [metrics](), [observability](), [opentelemetry](), [rideshare](), [synthetic](), [traces]() ### AI overview A guide to using OpenTelemetry tail-based sampling to reduce exported trace volume while retaining errors, slow requests, and other diagnostically valuable traces. It explains the difference between head- and tail-based sampling, the role of Span Metrics, and the collector architecture required to evaluate complete traces. ### Source excerpt Learn how to configure tail-based sampling in the OpenTelemetry Collector to drop noisy traces, keep the ones that matter, and control APM costs. ## Connect client traces to your logs DevFeed: [Connect client traces to your logs]() Original publisher: [Read original article]() Author: Katerina Skroumpelou; Steven Eubank Published: 2026-08-18T07:00:00Z Content type: tutorial Language: en Sources: [Supabase Blog]() Topics: [Supabase](), [tracing](), [OpenTelemetry](), [client](), [Amazon API Gateway](), [browser](), [SIEM, Security, Observability]() Tags: [api](), [backend](), [browser](), [how-to](), [integration](), [opentelemetry](), [traces](), [tracing]() ### AI overview A walkthrough of connecting client-side traces to Supabase logs by propagating W3C Trace Context. It explains how to configure a tracer and client propagation so requests can be followed from the browser through Supabase's API Gateway and Edge Function logs, including with external log backends. ### Source excerpt supabase-js now propagates W3C Trace Context to Supabase, so a client trace and the matching Supabase log share one trace_id. ## Consuming OpenTelemetry Entity Events with an Event-Sourced Consumer DevFeed: [Consuming OpenTelemetry Entity Events with an Event-Sourced Consumer]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-08-14T07:10:08Z Content type: tutorial Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [observability](), [telemetry](), [systems]() Tags: [logs](), [metrics](), [observability](), [open-source](), [opentelemetry](), [services](), [systems](), [traces](), [volumes]() ### AI overview This post explains how to consume OpenTelemetry entity events, which represent the inventory and lifecycle changes of hosts, interfaces, switches, services, and volumes. It presents an open source consumer as a worked example and recommends an event-sourced pipeline that preserves both current state and history. ### Source excerpt Metrics, logs, and traces tell you how your systems behave. They are much quieter about what actually exists: which hosts, interfaces, switches, services, and volumes are out there right now, and, crucially, how that picture changed over the last hour, day, or quarter. That living inventory has stayed a blind spot in the open observability stack. OpenTelemetry's entity events, coming out of the Entities SIG and described in the Entity Data Model, are the piece that starts to close it. Entity events are a stream. The interesting question is "what do I do once they arrive?" This post walks through one answer, using an open source consumer as a worked example. ## What's new in the ClickHouse Grafana plugin DevFeed: [What's new in the ClickHouse Grafana plugin]() Original publisher: [Read original article]() Author: Alex Fedotyev Published: 2026-08-13T16:14:40Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [Grafana](), [OpenTelemetry](), [User Experience](), [dashboards]() Tags: [clickhouse](), [dashboards](), [grafana](), [logs](), [metrics](), [open-source](), [opentelemetry](), [pull-request](), [traces](), [user-experience]() ### AI overview ClickHouse Grafana plugin 4.20 improves log investigation with compact query mode, click-to-filter workflows, guided configuration, and a live SQL preview. It is designed for users sending OpenTelemetry data to ClickHouse and keeps full SQL available for advanced queries. ### Source excerpt ClickHouse Grafana plugin 4.20 brings compact query mode, click-to-filter log investigation, guided variable and annotation editors, and OpenTelemetry dashboards ## ClickStack and Hud bring runtime intelligence to AI-powered development DevFeed: [ClickStack and Hud bring runtime intelligence to AI-powered development]() Original publisher: [Read original article]() Author: May Walter, Hud.io Published: 2026-08-13T12:53:04Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [AI-assisted coding](), [observability](), [Model Context Protocol](), [OpenTelemetry](), [telemetry](), [Artificial Intelligence](), [Instrumentation](), [Deployment](), [Incident response](), [distributed-systems](), [clickhouse](), [log management]() Tags: [agents](), [ai](), [clickhouse](), [code](), [coding](), [deployment](), [developers](), [development](), [distributed-systems](), [engineering](), [incident](), [incident-response](), [infrastructure](), [instrumentation](), [integration](), [mcp](), [metrics](), [monitoring](), [observability](), [open]() ### AI overview ClickHouse and Hud announce an integration that combines ClickStack service-level observability with Hud's function-level runtime context for AI-assisted software development. Shared trace IDs and MCP servers help coding agents assess risky changes before deployment, monitor releases, and investigate incidents using production context. ### Source excerpt ClickStack and Hud now share trace IDs, pairing service-level observability with function-level runtime forensics so coding agents can assess risky changes before they ship, catch regressions right after deploy, and fix them with real production context. ## Building open-source observability together: The OpenSearch Observability TAG turns one DevFeed: [Building open-source observability together: The OpenSearch Observability TAG turns one]() Original publisher: [Read original article]() Author: Dotan Horovits Published: 2026-08-11T17:01:57Z Content type: article Language: en Sources: [OpenSearch]() Topics: [observability](), [Open Source](), [OpenTelemetry](), [Prometheus](), [agent observability]() Tags: [agent-observability](), [blog](), [cncf](), [community](), [metrics](), [observability](), [open-source](), [opensearch](), [opentelemetry](), [prometheus]() ### AI overview The OpenSearch Observability Technical Advisory Group marks its first anniversary after a year of community-driven guidance, RFC reviews, architecture decisions, and collaboration across organizations. The article highlights work involving OpenTelemetry, Prometheus, Perses, KEDA, Kubernetes, and the OpenSearch Observability Stack, and explains how contributors can participate in the group's second year. ### Source excerpt The OpenSearch Observability TAG's first year: 10+ orgs shipped OTLP ingestion, Prometheus metrics, an open-source Observability Stack, and AI agent observability. The post Building open-source observability together: The OpenSearch Observability TAG turns one appeared first on OpenSearch. ## Centralize cross-account Amazon ECS telemetry with an ADOT gateway DevFeed: [Centralize cross-account Amazon ECS telemetry with an ADOT gateway]() Original publisher: [Read original article]() Author: Rahul Kumar Published: 2026-08-06T16:13:46Z Content type: tutorial Language: en Sources: [Containers]() Topics: [Amazon Elastic Container Service](), [telemetry](), [OpenTelemetry](), [SIEM, Security, Observability](), [Amazon CloudWatch](), [Amazon Web Services](), [Windows](), [.NET Framework](), [Traces](), [log management](), [Amazon Elastic Kubernetes Service]() Tags: [amazon-cloudwatch](), [amazon-eks](), [amazon-elastic-container-service](), [amazon-elastic-kubernetes-service](), [aws](), [intermediate-200](), [logs](), [metrics](), [net-framework](), [observability](), [opentelemetry](), [technical-how-to](), [telemetry](), [traces](), [windows]() ### AI overview This tutorial presents a centralized AWS Distro for OpenTelemetry gateway for collecting telemetry from Amazon ECS workloads across multiple AWS accounts. It replaces per-task sidecars, supports Windows .NET Framework tasks, receives OTLP over private connectivity, and exports traces to AWS X-Ray plus metrics and logs to Amazon CloudWatch. ### Source excerpt Running an OpenTelemetry collector as a sidecar in every Amazon ECS task does not scale across a multi-account estate, and it cannot run at all on Windows. Learn how to replace per-task sidecars with a single centralized ADOT gateway that ingests OTLP from workloads across accounts and exports traces to AWS X-Ray and metrics and logs to Amazon CloudWatch. ## Metric cardinality limits in OpenTelemetry: a practical guide DevFeed: [Metric cardinality limits in OpenTelemetry: a practical guide]() Original publisher: [Read original article]() Author: OpenTelemetry Authors; Docs CC BY Published: 2026-08-06T07:43:47Z Content type: article Language: en Sources: [Blog on OpenTelemetry]() Topics: [OpenTelemetry](), [SDK](), [telemetry](), [dashboards]() Tags: [cardinality](), [dashboards](), [filter](), [guide](), [memory](), [metric](), [metrics](), [opentelemetry](), [practical](), [production]() ### AI overview This practical guide explains how OpenTelemetry metric cardinality limits protect process memory from unbounded growth. When a metric stream overflows, total values remain correct, but attribute-based filtering and grouping can undercount, affecting dashboards, SLOs, and alerts. ### Source excerpt OpenTelemetry metrics are designed to be safe to use in production. One part of that safety is the cardinality limit in the metrics SDK. The limit protects your process from unbounded memory growth when a metric receives too many unique attribute combinations. That protection is useful, but it has a consequence many users do not expect: when a metric stream overflows, the total value remains correct, while queries that filter or group by attributes can undercount. This can affect dashboards, service-level objectives (SLOs), and alerts that looked correct before overflow started. ## Connecting OpenTelemetry Traces with Sentry Errors in One Trace Waterfall DevFeed: [Connecting OpenTelemetry Traces with Sentry Errors in One Trace Waterfall]() Original publisher: [Read original article]() Author: Johannes Daxböck; Neel Shah Published: 2026-08-05T09:00:00Z Content type: tutorial Language: en Sources: [Sentry Blog]() Topics: [OpenTelemetry](), [tracing](), [telemetry](), [SDKs]() Tags: [errors](), [instrumentation](), [logs](), [opentelemetry](), [sdk](), [sdks](), [sentry](), [tracing]() ### AI overview Sentry's OtlpIntegration connects OpenTelemetry traces with Sentry errors and other events, allowing them to appear together in a trace waterfall. It reads the active OTel trace context and associates it with Sentry events while configuring an OTLP exporter for Sentry. ### Source excerpt The OtlpIntegration bridges OTel traces and Sentry errors. Keep your OTel setup, add Sentry for errors, and see both in one trace waterfall. [Next page]()