OpAMP explained: the control plane for observability agents

If you have come across OpenTelemetry through observability work, you probably associate it with traces, metrics and logs. You may also have deployed an OpenTelemetry Collector to receive that telemetry, process it and send it to one or more backends.

That solves an important part of the observability problem, but not all of it.

Imagine that you now have hundreds or thousands of collectors and agents spread across Kubernetes clusters, virtual machines, physical servers, remote sites and edge devices. How do you know what is running? Is each agent healthy? Which version and configuration is it using? How do you change that configuration or restart an agent without inventing a different integration for every product?

This is the problem that OpAMP — the Open Agent Management Protocol — is intended to address. It gives a central management service and a fleet of data-collection agents a standard way to talk to one another.

First, what do we mean by “OpenTelemetry”?

The name OpenTelemetry is used rather loosely. Before looking at OpAMP, it helps to separate four related but different ideas.

When we say…	We mean…
The OpenTelemetry project	The CNCF-hosted open-source project and community that develops specifications, semantic conventions and software for generating, collecting and transporting telemetry. OpAMP is defined by this project.
OTLP	The OpenTelemetry Protocol: the wire protocol used to send traces, metrics, logs and profiles between compatible components.
OpenTelemetry software	Deployable components produced by the project, most notably the language SDKs, instrumentation and the OpenTelemetry Collector.
An OpenTelemetry-based solution	The observability architecture that an organisation assembles from instrumentation, collectors, gateways, storage and analysis products. OpenTelemetry supplies important building blocks, but it is not itself a complete observability backend.

This distinction is important because OpAMP and OTLP do different jobs.

OTLP carries observability data.
OpAMP manages the agents and collectors that handle that data.

Put another way, OTLP is part of the data plane; OpAMP is part of the control plane.

A simple analogy is that OTLP is the freight network carrying goods, while OpAMP is the fleet-control system that knows which vehicles exist, whether they are healthy and what instructions they should follow.

So, what does OpAMP actually do?

OpAMP is a vendor-neutral management protocol defined by the OpenTelemetry project. It describes a conversation between two roles:

an OpAMP Server, which provides central management; and
an OpAMP Client, which represents a data-collection agent to that server.

The word agent is deliberately broad. It could be an OpenTelemetry Collector, Fluent Bit, Fluentd, Elastic Agent or another process that collects and routes telemetry.

The client tells the server about the agent by sending AgentToServer messages. These can contain its identity, version, supported capabilities, health, current status and configuration state. The server replies with ServerToAgent messages containing instructions such as configuration offers, commands, connection settings or package information.

These messages are encoded using Protobuf and can be exchanged over HTTP or WebSocket. WebSocket is useful when the server needs to contact an agent immediately; HTTP works well when a client-driven request and response model is sufficient.

The protocol can support:

agent discovery and identity;
reporting versions, operating-system details and other descriptive information;
health and status reporting;
regular heartbeats;
remote configuration and reporting whether that configuration was accepted;
restart commands;
managing connection details and credentials;
distributing agent packages and software updates; and
extensions for additional agent-specific capabilities.

That does not mean every OpAMP implementation must support every item. Clients and servers advertise their capabilities to each other. A server should only ask an agent to perform an operation that the agent says it understands.

This capability exchange is one of OpAMP’s most useful ideas. It provides a basis for working with mixed products and implementations without assuming that they all behave identically.

Why should someone working in observability care?

At small scale, managing collectors can look like an installation and configuration problem. At larger scale, it becomes a distributed-systems problem.

Collectors may be deployed by different teams, at different times, on different infrastructure. Some may run in Kubernetes, where a controller already provides strong deployment and reconciliation facilities. Others may run as Windows services, Linux daemons, sidecars or processes on remote devices. The observability estate quickly becomes more varied than the applications it is monitoring.

Without a common management protocol, each collector or vendor needs its own inventory mechanism, health API, configuration service, upgrade process and automation. Organisations then build the same control-plane features repeatedly, usually with slightly different behaviour and security models.

OpAMP offers a standard contract above those products. In principle, an OpAMP server can manage a mixed fleet of compliant agents, and an OpAMP client can work with a different compliant server. The actual level of interoperability will depend on the capabilities each side implements and should always be tested, but the protocol gives everyone the same starting point.

It also helps observability platforms observe themselves. If a collector fails or receives a bad configuration, healthy applications can suddenly appear silent. Reporting the health and state of the collection layer is therefore just as important as collecting telemetry from the applications.

Does the agent need OpAMP built into it?

No. Native support is one option, but it is not the only one.

The OpAMP client can be built into the agent, supplied as a plugin or sidecar, or run as a separate supervisor process. A supervisor speaks OpAMP to the central server and translates those generic messages into operations understood by the local agent.

That supervisor pattern is particularly useful for existing agents that do not yet implement OpAMP themselves. It lets an organisation introduce a common control plane without first modifying every data collector.

There is an important boundary here. The OpAMP specification defines communication between client and server. It does not define how a supervisor must start, stop, configure or inspect the process it manages. Those details remain agent- and operating-system-specific.

How the `fluent-opamp` project applies these ideas

The mp3monster/fluent-opamp project turns this architectural pattern into a working implementation for Fluent Bit and Fluentd. It includes both sides of the OpAMP conversation and a collection of supporting services for operating and experimenting with the control plane.

The project uses slightly different names from the specification:

the provider is the OpAMP Server; and
the consumer is the OpAMP Client and local agent adapter.

For a minimal end-to-end deployment, you need one provider and at least one consumer. They can run independently, so a central provider can manage consumers deployed across many machines and environments.

The provider: the central control plane

The provider keeps track of the consumers that connect to it. It receives their identity, capabilities, health, status and heartbeat information, then sends back appropriate OpAMP instructions.

It also provides the things an operator needs around the protocol itself:

a browser-based fleet console;
HTTP APIs;
command and remote-configuration workflows;
provider metrics;
optional MCP endpoints;
authentication options; and
file-based state snapshots and restoration.

The implementation supports OpAMP over HTTP and WebSocket. Its default deployment uses port 8080 because the same service also hosts the web and integration surfaces.

The consumer: the Fluent-aware adapter

The consumer is the bridge between generic OpAMP messages and the way Fluent Bit or Fluentd actually works.

It can launch and track the Fluent process, discover version information, poll local health endpoints and report what it finds to the provider. When an instruction comes back, it dispatches that instruction to the appropriate local handler.

The consumer has two useful lifecycle modes:

Mode	What it does	When it is useful
`Supervisor`	Launches the agent and directly manages its lifecycle.	A new deployment in which the OpAMP consumer can own the agent process.
`Observer`	Finds and attaches to a process that is already running.	Introducing OpAMP around an existing deployment without changing how the process is initially started.

Observer mode is less invasive, but it does not make operating-system integration disappear. If OpAMP is used to request a restart, the consumer still needs to know how that service should really be restarted on the host.

Which agents are covered?

Fluent Bit and Fluentd have implemented consumer adapters. The project also includes a simulator for development, demonstrations and repeatable testing.

The architecture leaves room for more agent types. Elastic Agent is on the project roadmap, while the OpenTelemetry Collector is a natural extension target for the same control-plane model. These should not be mistaken for currently completed adapters in this repository.

What is complete and what is still evolving?

The repository’s feature-status document is deliberately open about this. Strong areas include agent identification, capability exchange, health, heartbeat, disconnect handling, server error responses, restart commands and custom messages.

Remote configuration is still being developed. Package management and some of the more advanced connection-management features are either longer-term work or outside the current plan.

This makes fluent-opamp useful as a practical implementation and test bed, but it is not claiming that every feature described by the OpAMP specification is finished. The simulator helps exercise successful responses, ignored messages and error paths, but it is a development tool rather than a production agent.

More than a provider and consumer

The repository has grown into a small control-plane platform. The extra components are optional; the core OpAMP loop still consists of the provider and one or more consumers.

The Config Service provides an editor and validation service, primarily for Fluent Bit YAML with some Fluentd support. It can run independently or be integrated into the provider.
The Catalog Service discovers known configuration files, shows their metadata and opens them in the editor or a read-only viewer.
The CLI supports local start, stop, status and demonstration workflows.
The consumer simulator launches multiple scripted consumers for testing and demonstrations.
The MCP surface exposes selected provider operations to MCP-capable clients.
The agent broker adds a collaboration layer using Slack, LangGraph and MCP.

These components make a useful architectural point. OpAMP defines the machine-to-machine management conversation. User interfaces, configuration catalogues, policy, approvals and natural-language interaction sit above that protocol as control-plane product features.

Where MCP and ChatOps fit

The project also explores what happens when a conversational interface is placed in front of the control plane.

An operator might ask through Slack to show unhealthy Fluent Bit instances or restart a particular Fluentd process. The broker interprets that request, uses MCP to discover and call a constrained provider tool, and lets the provider reach the selected consumer through its existing OpAMP relationship.

The layers remain distinct:

Slack or another collaboration tool captures the operator’s intent.
The broker and MCP tooling turn that intent into a defined operation.
The provider applies fleet identity, capability and state information.
OpAMP carries the management instruction to the correct consumer.
The consumer performs the agent-specific local action and reports the outcome.

This is more than a convenient user interface. The broker can act as a narrower security boundary, exposing a carefully selected set of tools without making every provider API externally available.

Natural language should not bypass normal operational safeguards. Configuration changes, restarts and shutdowns still need identity, authorisation, scope restrictions, approvals where appropriate and an auditable result.

A typical interaction from beginning to end

Here is what the flow looks like in practice:

A consumer starts and represents a Fluent Bit or Fluentd process.
It connects to the provider and sends its unique identity, description and supported capabilities.
It continues to send heartbeats, health information and meaningful status changes.
An operator selects the agent through the web console, API, CLI or optional ChatOps route.
The provider checks the agent’s capabilities and sends an appropriate ServerToAgent instruction.
The consumer translates that instruction into a local agent operation.
If the operation changes the agent’s state, the consumer reports the new state to the provider.
Meanwhile, the agent continues sending the telemetry it collects to its normal gateway or observability backend. That data does not need to pass through the OpAMP provider.

That last point is worth repeating: OpAMP controls the collection agent; it does not replace OTLP and it is not the observability data pipeline.

Why this project is useful

fluent-opamp makes OpAMP tangible. It shows that the protocol is relevant beyond a discussion focused only on the OpenTelemetry Collector.

It is useful as:

a concrete demonstration of an OpAMP control plane;
a bridge for bringing existing Fluent Bit and Fluentd deployments into that model;
a reference for supervisor and observer integration patterns;
a test bed for capabilities, commands, configuration and fleet simulation;
a platform for exploring the relationship between OpAMP, MCP and ChatOps; and
a starting point for supporting more collection agents.

It also exposes the questions that any production control plane must answer: How is configuration versioned and rolled back? How are credentials delivered? How is an agent’s identity established? Who is allowed to issue a command? What happens when only part of a fleet accepts a change? How is the result audited?

OpAMP does not answer every one of those product and governance questions. What it provides is a common protocol on which consistent answers can be built.