Grafana Cloud: Fleet Management now also manages upstream OTel collectors via OpAMP

Anyone already running a fleet of OpenTelemetry Collectors in production knows the problem: keeping YAML configuration aligned across dozens or hundreds of instances, working out which ones are healthy, and applying common policies without duplicating pipelines everywhere. Grafana Cloud has extended Fleet Management, its control panel for telemetry collectors, to support the OpAMP (Open Agent Management Protocol) protocol on a stable basis.

What changes compared to before

Fleet Management was originally built to manage Grafana Alloy, Grafana's own OpenTelemetry Collector distribution. Grafana Cloud's Fleet Management now generally supports OpAMP, letting organisations manage upstream OpenTelemetry Collector distributions centrally without migrating to Grafana Alloy. In practice, anyone already using an upstream OTel distribution can bring it under centralised management without rewriting anything.

Technically, Fleet Management exposes the /v1/opamp endpoint for OpenTelemetry Collector deployments that use OpAMP, and collectors query it to receive remote configuration and report their own status. However, this requires the OpAMP supervisor on the collector side: the OpAMP Agent extension can only report status to Fleet Management, whereas receiving and applying remote configuration requires the OpAMP supervisor.

The multiple-configuration sticking point

The practical problem when several remote pipelines converge on the same collector is name collision: two independently written pipelines may use the same component name while expecting different behaviours. Fleet Management resolves this with an automatic merge: it post-processes the remote configuration with an algorithm that prefixes the pipeline name to OTel pipeline and component identifiers, updating the references accordingly, and then deduplicates components with the same type and the same configuration, avoiding collisions when two pipelines reuse the same name with different behaviours.

Gateway pattern and mixed infrastructure

For those with heterogeneous fleets, the two-tier pattern remains available: edge collectors that gather telemetry, and gateways that apply shared processing (labelling, tail sampling, filtering) before forwarding the data on. The interesting point is that adoption can be gradual: agents already in use, such as Fluent Bit or Telegraf, can remain in place at the edge and send data to OTel gateways managed via Fleet Management, without having to replace everything in one go.

For those already working with infrastructure as code, Terraform support is also available for registering collectors and pipelines as versioned resources. The practical starting point remains the same as ever: register a collector, assign it a YAML pipeline, and check its status in the Fleet Management inventory.