OpAMP, the Supervisor and the Collector
What OpAMP is, what the OpAMP Supervisor does and cannot do, how remote configuration reaches a collector, and where myriarch fits, with dated sources.
Concepts
The ideas behind myriarch: OpAMP and the Supervisor, Git as the source of truth, agents, blueprints, fleets, inventory, rollouts and executors.
These pages explain what the objects of a myriarch installation are and why they behave the way they do. They are written to be read in order, but each page stands on its own. For the exact field lists, defaults and error codes see the GitOps schema reference. For step-by-step instructions see the how-to guides. The architecture shows how the components fit together, and the security model describes the controls behind them. OpAMP, the Supervisor and the Collector comes first if OpAMP is new to you; for the whole path from an empty repository to the first rollout, follow Manage many OpenTelemetry Collectors with OpAMP and Git.
| Page | What it explains |
|---|---|
| OpAMP, the Supervisor and the Collector | What OpAMP is, the parts of an OpAMP setup, how remote configuration reaches a collector, and what the Supervisor cannot do. |
| Git as the source of truth | The repository layout, the object envelope, how myriarchd reads and applies a revision, and the rule “Git sets the frame, the UI operates within it”. |
| Agents | Collectors, updaters and OpAMP Bridge agents, how an agent is identified, the attributes that fleets and templates work on, server labels and the config sync states. |
| Blueprints | Layered collector configurations: parameters, fragments, removal, the rendering algorithm, templates, the canonical form and the hash. |
| Fleets | Selectors, assignment and priority, bootstrap versus rollout, choosing the target collector version in the UI within a frame set in Git, and how OpAMP Bridge agents are protected. |
| Inventory | Server-side labels and parameter overrides for agents that match exact attribute values. |
| Rollouts | Rollout policies, waves, targets and success, maintenance windows, failure handling, the planner and the live progress of an update. |
| Executors | How collector version updates are started: none, updater, webhook, awx and manual, with payloads, signatures and secrets. |
The five kinds of GitOps objects fit together like this:
Inventory ──labels, parameters──┐
▼
Agent ──attributes──▶ Fleet ──▶ Blueprint (rendered per agent into one config)
│
├──▶ RolloutPolicy (how a change reaches the fleet)
└──▶ Executor (how a collector version is changed)
An agent reports its attributes. The fleet whose selector matches (the highest priority wins) decides which blueprint is rendered, which parameter values apply, which collector version is wanted, and which policy and executor are used. The inventory adds labels and parameter overrides for individual agents before the fleet is chosen.
Git as the source of truth
How a Git repository describes blueprints, fleets, policies, executors and inventory, and how myriarchd reads, validates and applies it.
Agents
Collectors, updaters and Bridge agents as the server sees them: how agents are identified, the attribute view, server labels and configuration sync states.
Blueprints
Layered, parameterized collector configurations: parameters, fragments, rendering, templates, merge rules, the canonical form and the hash.
Fleets
How fleets select agents, how the highest priority wins, when the offered configuration changes and how the target collector version is chosen.
Inventory
Server-side labels and parameter overrides for agents that match exact attribute values.
Rollouts
How changes reach a fleet: rollout policies, waves, targets and success, maintenance windows, failure handling, the planner and the live progress of an update.
Executors
How collector version updates are started: the executors none, updater, webhook, awx and manual, their payloads, signatures, secrets and the host allowlist.