As more organizations move to use OpenTelemetry in production at scale, with multiple Collectors across heterogeneous environments, a new challenge arises: how to remotely manage, configure, and update this agent fleet in a consistent and secure way?
This is where Open Agent Management Protocol (OpAMP) comes into the picture: it provides a standardized protocol that lets a central backend automatically configure agents, push updates, monitor their health, and collect status information.
In a recent episode of OpenObservability Talks, I sat down with Andy Keller, OpAMP maintainer and Principal Engineer at BindPlane, to hear what OpAMP is and how it makes large-scale observability deployments much easier to operate and control. We also covered project status and roadmap, including a hot KubeCon update you don’t want to miss.
OpenObservability Talks: Operating OpenTelemetry at Scale with OpAMP
Why OpAMP: The management challenge at scale
As OpenTelemetry adoption has exploded, organizations are finding themselves managing increasingly complex collector deployments. Before OpAMP, the landscape was fragmented and challenging. Andy shared their journey: “We probably developed in-house three, four, maybe five different agent management protocols. Some were HTTP-based, long polling. We used WebSockets. We used protobufs. We used JSON.”
The problem becomes acute when you consider the scale and variety of deployments. We’re not just talking about a handful of collectors — organizations are deploying collectors everywhere from massive gateways to embedded devices. Each deployment model brings its own management challenges, and the teams responsible for deploying collectors are often different from the observability teams who need to configure them. This disconnect creates operational friction that can undermine your entire observability strategy.
Scale and variety of OTel Collector deployments
I found the sub-story about the diversity of OpenTelemetry collector deployments staggering. “We see anything from a couple massive OpenTelemetry gateways where really what you’re doing is managing the configuration of the gateway and doing all the processing there,” said Andy, “but then we also even see people deploying collectors to embedded devices. We have collectors in point of sale machines. We have collectors on laptops collecting Windows events for security tracking.”
The scale ranges from dozens to millions of collectors. When you factor in IoT and embedded use cases, the numbers become truly massive. As Andy noted, when you get into the embedded space, it gets to millions of collectors that you need to start reasoning about.
What is the Open Agent Management Protocol (OpAMP)
OpAMP (Open Agent Management Protocol) is a standardized protocol that provides remote management capabilities for observability agents, primarily the OpenTelemetry Collector (which is why it resides under the OpenTelemetry project). It enables central backends to automatically configure agents, push updates, monitor their health, and collect status information — all in real-time over WebSocket or HTTP connections.
Managing OpenTelemetry Collectors with OpAMP. Source: opentelemetry.io
What’s particularly interesting is how OpAMP has evolved beyond simple configuration management. As Andy explained: “It started to really focus on configuration management and with agent health and component health and things like that, really moving into this observability for your observability realm. Because observability is something that is so critical to operations that you need to know is your observability actually working?”
To me, this evolution reflects a crucial insight: your observability infrastructure is too important to be a black box. You need observability for your observability. OpAMP addresses this by providing real-time visibility into collector health, configuration drift, and operational status. There was a great talk at last year’s KubeCon North America 2025, in which Nike’s observability platform engineers shared how they built an enterprise-grade implementation of OpAMP for their scale and use case.
OpAMP protocol and components
OpAMP, as the name suggests, is first and foremost a network protocol specification, used to remotely manage large fleets of data collection Agents. The protocol is elegantly simple: just two messages — server-to-agent and agent-to-server — defined using Protocol Buffers. The specification lives in the opamp-spec repository under OpenTelemetry, while opamp-go provides the reference implementation in Go.
The architecture includes several key components. The OpAMP extension is a read-only component that reports current configuration and health status. The OpAMP supervisor sits as a separate process alongside the collector, implementing both read and write capabilities. As Andy described it: “It kind of sits between the management platform and the collector. It speaks to the collector on behalf of the management platform, and it can accept changes.”
The supervisor’s approach is particularly clever — it writes new configurations to disk, shuts down the collector, and restarts it with the new configuration. Critically, it includes safety mechanisms: “If it doesn’t start, it will revert the config and run with the last known good config so that we’re not breaking your telemetry pipelines remotely.”
Supervisor-based management with OpAMP. Source: gihub.com/open-telemetry
Beyond OTel Collector: OpAMP for Kubernetes, SDKs and more
What makes OpAMP powerful is its protocol-level flexibility. The configuration payload is intentionally generic — just a map of name-value pairs. This allows OpAMP to manage not just OpenTelemetry collectors, but any type of agent. In fact, it’s already used to manage SDKs and Kubernetes deployments.
To manage Kubernetes deployments, OpAMP utilizes the OpAMP Bridge, which acts as an intermediary between OpAMP-speaking management platforms and Kubernetes-native deployment mechanisms. Andy explained the architecture: “rather than communicating with [OTel] Collectors, you’re communicating with this OpAMP Bridge. The OpAMP Bridge is communicating within the cluster with the OpenTelemetry Operator, and that Operator reads CRDs and deploys Collectors.”
Andy mentioned that the OpenTelemetry Java SDK can also speak OpAMP and receive remote configuration. The use cases are compelling: imagine remotely adjusting sampling rates across your entire microservices architecture to investigate an issue, or enabling debug logging for specific services without redeploying. Reconfiguring SDKs, however, requires a different operational model, as we can’t shut down applications to reconfigure the SDK. SDKs require hot-reloading capabilities rather than the restart-based approach used for collectors.
Another interesting use case is managing a fleet of Fluent Bit agents. This brand-new project was recently open-sourced these days by Phil Wilkins, with Fluentd support planned next. Check out the GitHub repo and Phil’s blog post for more details.
The protocol’s agent-agnostic design is intentional. The remote config message is just a map of name-value pairs, where that value can be anything. This flexibility means OpAMP can manage security agents, custom telemetry collectors, or any other agent-based software. The protocol defines the communication contract, but doesn’t dictate what agents do with the configuration they receive.
Hot off the press: OpAMP Gateway Extension
One of the most exciting developments is the upcoming OpAMP Gateway Extension launching these days around KubeCon Europe 2026. This addresses a critical scaling challenge: WebSocket connection limits.
Andy described the problem and solution: “Let’s say I’ve got 100,000 collectors deployed across my many different clusters in my organization, instead of all the 100,000 [collectors] connecting to the management platform, I can deploy 100 OpAMP gateways, have 1,000 collectors connect to each one, and then those 100 connect to the management platform.”
OpAMP Gateway — Connection Fan-In. Source: bindplane.com
The OpAMP Gateway is an OpenTelemetry Collector extension. It runs inside a collector and acts as a multiplexer, aggregating OpAMP messages from thousands of edge collectors and relaying them through a smaller number of upstream connections. You can think about it as similar to how OpenTelemetry gateways work for telemetry data, but for the control plane.
The benefits are substantial: reduced connection overhead on management platforms (i.e., OpAMP Server), support for network-segmented environments where edge collectors can’t directly reach external management systems, and more efficient use of network resources. For organizations operating at IoT scale — millions of collectors — the gateway becomes essential infrastructure. The OpAMP Gateway Extension is launched in Alpha, check out the launch blog for more details.
OpAMP roadmap
OpAMP is currently in beta, with different components at varying maturity levels, and the community is actively working toward stability.
Configuration diff support is another priority — sending only configuration changes rather than complete configurations becomes critical when dealing with large, complex collector configurations. There’s also significant interest in true hot-reloading capabilities that wouldn’t require collector restarts.
Perhaps most intriguing is the telemetry policy OTEP (OpenTelemetry Enhancement Proposal) currently in draft. This would introduce policy as a concept distinct from configuration — communicating intent (like “filter out these log messages” or “add this attribute”) rather than specific implementation details. The SDK and collector could then implement the same policy differently based on their capabilities.
Andy expects additional SDKs to support OpAMP, expanding remote management capabilities to more languages and platforms.
Want to learn more? Check out the OpenObservability Talks episode: Operating OpenTelemetry at Scale with OpAMP.
Ambassador post originally published on Medium by Dotan Horovits.