What is Myriarch?

Myriarch is an open-source OpAMP server and fleet manager for OpenTelemetry Collectors. Facts on scope, license, maturity and version.

Myriarch is an open-source OpAMP server and fleet manager for OpenTelemetry Collectors. OpAMP is the Open Agent Management Protocol of the OpenTelemetry project. Git is the source of truth for blueprints, fleets, rollout policies and the allowed collector versions; the web UI and the REST API operate within that frame, and every operator action is audited. It is an independent project under the Apache-2.0 license, currently alpha, and the latest release is v0.2.0.

At a glance

What it isA server (myriarchd) that is an OpAMP server and control plane for OpenTelemetry Collectors, plus the tools myrctl, myriarch-updater and myriarch-sim
Runs onLinux and Windows hosts through the installers, and Kubernetes with the Helm charts myriarch and myriarch-collector (signed OCI charts)
ForOperators who run many OpenTelemetry Collectors on Linux and Windows hosts, in containers and on Kubernetes, at edge sites, in data centers and in the cloud
SizeDesigned for around 1,000 collectors, with headroom up to 5,000 (design targets, not measured limits)
LicenseApache-2.0 for the code, CC BY 4.0 for the documentation
MaturityAlpha. Interfaces, configuration and the GitOps format (myriarch.dev/v1alpha1) can still change
Latest releasev0.2.0
NeedsPostgreSQL for state, events and leader election; no other stateful component
HostingSelf-hosted: you run the server and PostgreSQL; the documentation describes no hosted service
Sourcegithub.com/myriarch/myriarch

What it does

  • Keeps the frame in Git. Blueprints (layered, parameterized collector configurations), fleets (which agents get which blueprint and which collector version), rollout policies, executors and the inventory live in a Git repository. The server reads it, validates the whole revision and applies it only if it is completely valid. See Git as the source of truth.
  • Renders and offers configuration. The server renders one content-addressed configuration per collector from the blueprints and offers it over OpAMP.
  • Rolls changes out in waves. Configuration and version rollouts run in waves with approvals, health gates, failure thresholds, pause, abort, rollback and maintenance windows. See Rollouts.
  • Updates collector versions through executors. The host agent myriarch-updater, a webhook or an AWX call installs the new version; the target is complete only when the collector reports it. See Executors.
  • Shows the fleet. Every collector with version, health, effective configuration, components and host attributes, live; new upstream releases are detected and breaking changes are extracted from the changelogs.
  • Audits. Every operator action, API call and rollout step is recorded. Sign-in works with OpenID Connect or a bootstrap administrator, with the roles viewer, operator and admin, and API tokens.

What it does not do

  • It does not replace the OpAMP Supervisor or the collector. Collectors keep running under the upstream OpAMP Supervisor, and the project does not plan its own collector distribution or an in-process client that replaces the supervisor (roadmap).
  • It does not edit declared objects in the web UI. Blueprints, fleets and policies stay in Git. The UI can choose a target collector version only if Git allows it and only inside the range Git defines.
  • It does not yet offer multi-tenancy, and the update of the supervisor itself through myriarch-updater is a later item (roadmap).

How it relates to the OpAMP Supervisor and the Collector

The upstream OpAMP Supervisor starts and monitors a collector and speaks OpAMP for it. It manages configuration, health and restarts, but it cannot replace the collector binary. Myriarch is the server side: it adds configuration rendering from Git, rollouts in waves, version updates through executors and an audit trail, and it leaves the protocol, the supervisor and the collector upstream. The facts about the upstream software, each with a public source and a date, are in the upstream notes. A side-by-side view with the alternatives is on the comparison page. The parts of an OpAMP setup, and how a configuration reaches a collector, are explained in OpAMP, the Supervisor and the Collector.

Myriarch is not affiliated with or endorsed by The Linux Foundation or the OpenTelemetry project; OpenTelemetry, Kubernetes and CNCF are trademarks of The Linux Foundation and are named only to describe compatibility (ADR-0028, brand rules).

Maturity and support levels

Myriarch as a whole is alpha. In v0.2.0, container mode of myriarch-updater, Linux hosts (systemd) and the server Helm chart are beta; Windows hosts and the collector Helm chart are experimental. What the levels mean is in Support levels and tested platforms; what has to hold before the project calls itself beta is in the roadmap. Every release is signed keyless and carries build provenance; verify it before you run it.

Key terms

The terms that the documentation uses, in short:

OpAMP
The Open Agent Management Protocol of the OpenTelemetry project, a network protocol with which a server manages a fleet of telemetry agents: status reporting, remote configuration and package offers.
OpAMP Supervisor
The upstream process that starts and monitors a collector and speaks OpAMP for it. It manages configuration, health and restarts, but it cannot replace the collector binary.
GitOps frame
What a Git repository declares: blueprints, fleets, rollout policies and the allowed collector versions. The web UI chooses inside this frame, for example a target version from the allowed range, and never edits the declared state.
Blueprint
A layered, parameterized collector configuration. The server renders it into one content-addressed configuration per agent.
Fleet
A group of agents selected by their attributes. It decides which blueprint, which parameter values and which collector version the agents get, and which rollout policies apply.
Rollout
A controlled change of the configuration or the collector version of a fleet: in waves, with approvals, health gates, failure thresholds, pause, abort and rollback.
Executor
The way a collector version update is started: the host agent myriarch-updater, a webhook, an AWX job, or by hand. The server learns the result from the version that the collector itself reports.
Programs
myriarchd is the server (OpAMP endpoint, REST API, web UI, GitOps syncer and rollout engine). myrctl validates and renders a GitOps repository. myriarch-updater is the host agent for collector binary updates. myriarch-sim is the load simulator.

Where to go next