A useful naming collision
OpAMP stands for Open Agent Management Protocol. Here, “agent” means a managed telemetry component, such as an OpenTelemetry Collector. It has nothing to do with an LLM tool-using agent. The industry reuses words; good engineers check the boundary before assuming the meaning.
At fleet scale, you need to know which collectors are connected, which configuration they run, whether an update was applied and whether the agent is healthy. A management protocol can help a control plane distribute and observe configuration consistently.
Separate data plane and control plane
The collector moves telemetry data: that is the data plane. The system that reports status and distributes managed configuration is the control plane. Treat both as production infrastructure: authenticate connections, authorize configuration changes, version the configuration and have a rollback path.
service → collector → telemetry backend
↑
management/control plane
Start with boring operational discipline
You do not need a large fleet before learning the lesson. Collector configuration is code. Review it, test it, deploy it progressively and observe the collector itself. A telemetry outage during a production incident is a very expensive surprise.
Try it
Inspect observability/otel-collector.yaml in the Workbench. It receives OTLP traces on port 4318 and exports them to Tempo; Compose mounts that configuration read-only. This is a single local collector, not an OpAMP fleet. For any collector or sidecar configuration you use, identify the owner, configuration source, rollout method, health signal and rollback mechanism. If any answer is “we edit it when things break,” write the safer next step.
Keep this with you
Observability is also a service. Operate its agents with the same care as your applications.