MyObservability
🟦 Open Agent Management Protocol (OpAMP) & FleetAMP
OpAMP is a management protocol for telemetry agents. FleetAMP is a vendor-neutral control plane I am building on top of OpAMP to make OpenTelemetry Collector fleet management easier, safer, and scalable.
What is OpAMP?
The Open Agent Management Protocol (OpAMP) is an open protocol from the OpenTelemetry ecosystem for remotely managing large fleets of telemetry agents such as the OpenTelemetry Collector.
OpenTelemetry solves the telemetry data plane problem: collecting, processing, and exporting logs, metrics, and traces. OpAMP complements it with a management/control plane for the agents that perform that work.
OpAMP does not replace OTLP. OTLP transports telemetry; OpAMP manages the telemetry agent.
Why do we need OpAMP?
Without a management plane, Collector operations often become a combination of SSH, Ansible, Kubernetes manifests, pipelines, scripts, and manually maintained configuration files. These approaches can deploy Collectors, but they do not by themselves provide a standard agent-management protocol.
OpAMP creates a common communication channel between a managed agent and a management server. This enables centralized inventory, health visibility, configuration delivery, configuration status, and other management capabilities supported by the agent.
Basic OpAMP flow
OpAMP capabilities
Capabilities are negotiated: a management server should only request operations that a connected agent says it supports.
| Capability area | Purpose |
|---|---|
| Agent description | Report identity, version, host and descriptive attributes |
| Health/status | Report whether the managed agent is operating normally |
| Remote configuration | Receive configuration from the management server when supported |
| Effective configuration | Report the configuration actually in effect |
| Remote-config status | Report applying, applied or failed state |
| Available components | Describe supported Collector components when reported |
| Own metrics | Allow reporting of agent self-observability information when supported |
| Heartbeat/status reporting | Maintain management-plane visibility of the agent |
A key design principle is therefore:
For example, FleetAMP does not send remote configuration to an agent that does not advertise accepts_remote_config.
Collector directly connected vs OpAMP Supervisor
A Collector can expose management information through its OpAMP extension, but full remote configuration requires the connected implementation to advertise the appropriate capability. For the FleetAMP lab, the OpenTelemetry OpAMP Supervisor is used for full configuration management.
The Supervisor receives remote configuration, manages the Collector process, and reports the resulting configuration status back through OpAMP.
FleetAMP
FleetAMP is my open-source project for building a vendor-neutral telemetry-agent fleet-management platform. OpAMP provides the protocol; FleetAMP provides the control-plane experience and operational workflows around it.
The goal is to let platform/observability teams manage Collectors centrally while keeping telemetry routing independent of a single observability backend.
How FleetAMP helps users
| User need | FleetAMP direction |
|---|---|
| Know which Collectors exist | Central managed-agent inventory |
| Know whether they are alive | Connected, disconnected and retired lifecycle |
| Inspect health | Agent health and last-seen visibility |
| Understand capabilities | Capability discovery per managed agent |
| Manage configuration | Immutable desired configuration artifacts |
| Avoid unsupported operations | Capability-gated remote configuration |
| Prevent invalid configuration | YAML + optional real Collector validation |
| Verify deployment | Desired vs effective configuration |
| Track delivery | Pending, sent, applying, applied, failed, unsupported |
| Review historical activity | Persistent lifecycle event history and time filtering |
| Manage teams/fleets | Labels, groups and selectors (planned) |
| Safer large rollouts | Canary/staged rollout and rollback (planned) |
| Enterprise governance | OIDC/RBAC, audit and CMDB/CSDM enrichment (planned) |
FleetAMP is intentionally designed so that the core domain is not tied to OpAMP. Protocol-specific logic lives behind management adapters, allowing other telemetry-agent management mechanisms to be added later.
FleetAMP high-level architecture
FleetAMP design principles
Vendor neutral: FleetAMP manages telemetry agents; it does not require telemetry to be sent to a particular backend.
Protocol isolation: OpAMP-specific protobuf/WebSocket logic remains in the OpAMP adapter. FleetAMP core works with a generic ManagedAgent model.
Desired vs effective state: FleetAMP keeps the configuration it wants an agent to run separately from the configuration reported by the agent as actually running.
Capability safety: Operations such as remote configuration are performed only when the managed agent advertises support.
Validate before deploy: Configuration is checked before it is stored/assigned. FleetAMP currently performs YAML validation and can optionally invoke the real otelcol-contrib validate command.
Replaceable persistence: Storage is abstracted behind interfaces. Lightweight persistence is useful during development; SQLite/PostgreSQL can provide stronger production persistence later.
Runtime independence: The domain model can represent agents running on VMs, bare metal, containers or Kubernetes.
Configuration deployment flow
Agent lifecycle and visibility
FleetAMP maintains lifecycle state independently of the telemetry backend:
Current agent snapshots and append-only lifecycle events allow the UI/API to answer questions such as which agents are active now? and which agents connected during the last hour/day/week?
Current FleetAMP status
Working today in the project/lab: OpAMP connectivity, generic managed-agent inventory, health/capability discovery, Supervisor-managed Collector connectivity, remote configuration, desired/effective configuration visibility, configuration validation, lifecycle retirement, persistent agent/event history, and REST/UI visibility.
Next areas include durable configuration/assignment storage, stronger Kubernetes/runtime metadata, configuration history/drift, groups/selectors, staged rollout/rollback, Git integration, OIDC/RBAC, CMDB/CSDM enrichment, richer visualization and additional agent adapters.
Example enterprise direction
This enables a future model where platform teams define standard building blocks while application teams receive controlled, scoped configuration for their own Collector fleets.
FleetAMP Home Page & Agent Page
Home Page
Agent Page
Group Page
References
- OpenTelemetry OpAMP specification
- OpenTelemetry OpAMP Go implementation
- OpenTelemetry Collector OpAMP Supervisor
- FleetAMP
Note: FleetAMP is under active development. Sections marked as planned describe the intended architecture and should not be interpreted as production-ready features.