OpenTelemetry collectors gain management without Alloy
OpenTelemetry collectors can now be managed centrally in Grafana Cloud without first switching to Grafana Alloy, according to Grafana’s Marko Bachvarovski. Grafana says support for the Open Agent Management Protocol (OpAMP), a protocol for remotely managing software agents, is generally available in Fleet Management. The change extends a workflow previously built around Alloy to supported upstream OpenTelemetry Collector distributions, meaning supported packages of the community collector software.
OpenTelemetry, often shortened to OTel, provides tools for collecting telemetry, the measurements and records used to understand how software behaves. Its collectors receive, process and forward that information. Alloy is Grafana’s distribution of the OpenTelemetry Collector. For teams already operating other supported distributions, the announcement means central management need not begin with replacing their collector software, rewriting their configuration in Alloy’s format or changing where collectors run.
The underlying operational problem is broader than any one product: as a monitoring deployment grows, teams need common rules without losing settings specific to individual services or environments. They also need to know whether the collectors themselves are working. Grafana’s implementation brings configuration targeting and collector health into one management workflow, while preserving OTel YAML, the structured text format used to describe collector settings.
Shared configuration without identical workloads
Fleet Management lets teams define telemetry pipelines, sequences of collection and processing steps, in OTel YAML and assign them to matching collectors. A shared processing rule can therefore be updated centrally, while additional collection remains limited to the teams, services or environments that need it. Grafana also illustrates a configuration test passing a syntax check, which checks the structure of the configuration rather than demonstrating its behaviour under every workload.
For teams using infrastructure as code, the practice of managing infrastructure through stored configuration files, Grafana describes support for Terraform, a tool that applies those files. Teams can create YAML-based pipelines and register active collectors through this workflow. Configuration and enrollment can consequently become repeatable processes tracked in version control, a system that records changes to files over time.
Enrollment also sets up collector self-monitoring. According to Grafana, enrolled OTel Collectors automatically send metrics, numerical measurements; logs, recorded events; and traces, records of requests moving through software, to Grafana Cloud. This applies regardless of operating system or deployment mode. Collectors outside Kubernetes, a system for managing applications packaged in containers, also receive a host monitoring pipeline to help teams examine the underlying machine alongside the collector.
Those monitoring pipelines are not fixed destinations or mandatory collection policies. Grafana says teams can edit them, disable them or redirect their data to another backend, the receiving system that stores or analyses telemetry. That distinction matters when reviewing what an enrolled collector sends and where it goes.
Why combining configuration needs more than a syntax check
A collector can receive several Fleet Management pipelines as well as retain local configuration. The resulting settings must function together. Bachvarovski explains that Alloy defines components, individual processing or collection building blocks, in blocks connected through references to their outputs. OTel Collectors instead define components at the top level of the configuration and refer to them from one or more telemetry pipelines.
There is a second important difference: Alloy keeps local and remote configuration separate, whereas OTel Collectors combine them into one effective configuration. If multiple sources define a component with the same name, one definition can override another and alter pipeline behaviour. Independently authored pipelines can therefore conflict even when their authors intended different behaviour for their identically named components.
Grafana addresses this with a merge algorithm, a procedure for combining configuration, that post-processes remote settings. It adds the Fleet Management pipeline name to OTel pipeline and component identifiers, then updates the references to those identifiers. Where components have both the same type and the same configuration, it deduplicates them, retaining a shared definition instead of unnecessary copies. Grafana also shows a read-only view of the remote configuration matched to a collector.
This mechanism is intended to let teams maintain remote pipelines as reusable pieces rather than manually build a separate configuration file for every possible combination. The transferable lesson is that central configuration needs explicit rules for names, references and merging. Accepting valid YAML alone does not explain how separately written configurations will interact.
Separate local collection from shared processing
Fleet Management supports different deployment patterns. One option Grafana describes for large or mixed fleets is the gateway pattern, which separates collectors into two layers. Edge collectors close to applications gather telemetry from services, Kubernetes pods (groups of application containers) and nodes (the machines running them). They forward it to gateway collectors, which apply shared processing before sending it to a backend.
At the gateway, teams might add team labels to metrics, filter logs or apply tail sampling to traces, choosing which request records to retain after observing how those requests progressed. Keeping these policies at the gateway avoids placing the same processing logic on every edge collector. Fleet Management can target collection pipelines to the edge and processing pipelines to gateways, managing both centrally without combining their responsibilities.
The two layers do not have to run identical software. Grafana says existing agents such as Fluent Bit or Telegraf can remain at the edge and forward telemetry to OTel gateways through compatible protocols. Fleet Management then manages the supported OTel gateways and their shared processing settings. That is an incremental route to adopting OpenTelemetry, not a claim that every existing agent becomes directly manageable through Fleet Management.
Gateways are optional: supported collectors that send directly to a backend can also use the OpAMP-based workflow. Grafana’s suggested starting point is to enroll one collector, assign a YAML pipeline and inspect its health before extending the approach across environments. The announcement does not enumerate every supported distribution, so compatibility should be checked rather than assumed.