Manage collector groups

A collector group lets you manage several collectors as one logical unit. You wire the shared sources, routes, and destinations once on the group, and every member renders that config into its own local collector config on the next sync. Use a group for redundancy behind a load balancer, for horizontal scale-out of a heavy source, or just to keep a fleet’s config consistent without copy-pasting.

This page walks the whole lifecycle: create a group, add collectors, wire shared config, and see it on the topology canvas.

1. Create a group

Open Collector Groups under Collect in the sidebar and click New Collector Group:

Name (required) — how the group reads in lists and on the canvas (Production US-East, Edge fleet).
Description — optional, one line on what the group is for.
Environment and Tags — optional metadata for organising and filtering groups as the fleet grows.

Create it. The group starts empty — no members, no shared config yet.

2. Add collectors

Open the group and go to the Members tab → Add Collectors. Pick one or more enrolled collectors and add them.

A newly added member immediately picks up whatever the group already has wired. Remove a collector from the group (the trash action on its Members row) and it reverts to whatever per-collector config it held before joining — typically empty. Removing a collector never deletes or un-enrolls it; it just detaches it from the group’s shared config.

3. Wire shared config

The group’s tabs are where the fan-out happens. Everything you assign here materialises on every member:

Sources — Assign Source to Group adds a receiver that every member runs. Good for a source every host in the fleet has locally (a host-metrics scraper, a shared log path).
Destinations — Assign Destination to Group adds an exporter every member sends to. A group-scoped destination is the cleanest way to point a whole fleet at one Grafana Cloud stack or OTLP endpoint.
Routing — build the routes that connect the group’s sources through pipelines to its destinations. The same route editor as a single collector, evaluated on every member.
Processors — the pipeline steps available to the group’s routes.

Changes fan out on the next config sync — the same poll-driven delivery a single collector uses. Each member’s Last applied timestamp on its detail page confirms it picked up the group change.

4. See the group on the canvas

Open Topology. A group renders as a single collapsible container rather than N loose nodes:

Collapsed — the group’s name, its member count, a rolled-up health summary (how many members are online / warning / offline), and the group’s aggregate throughput. One glance tells you the fleet’s state.
Expanded — the member collectors listed inside the container, each with its own status, while the group’s shared routes stay drawn once as the group’s egress — so a ten-member group sending to one destination is one edge, not ten overlapping ones.

This keeps a large fleet legible: you reason about the group as a unit and drop into individual members only when one needs attention.

Delete a group

Deleting a group (the trash action on the Collector Groups list) removes the group and its group-level source and destination activations. It does not affect the collectors themselves — they stay enrolled and revert to their own per-collector config. Delete is for retiring the shared template, not for decommissioning hardware.