Why Ampora¶

Teams that run OpenTelemetry Collectors in production hit the same three problems regardless of cloud, scale, or industry. Ampora is built around those three problems.

1. Collector configurations are hard to read and risky to change¶

A non-trivial collector config is a deeply nested YAML document referencing receivers, processors, exporters, connectors, extensions, and several pipelines per signal. Reviewers cannot tell from a diff whether a change rewires data flow, drops a span attribute, or duplicates a telemetry stream.

Ampora parses the YAML, normalises it into a graph, and renders the pipelines as interactive swimlanes for traces, metrics, logs, and profiles. Unused components are flagged. Validation errors point to a line and path. Reviewers see the behaviour of a change, not just the diff.

2. Managing many collectors over many hosts is painful¶

A real fleet runs across containers, virtual machines, edge devices, and multiple clusters. Configuration management tools (Ansible, Salt, Chef) work but treat the collector as just another file on disk. There is no view of which version is actually running where, no acknowledgement that the agent applied the new config, and no way to react when it didn't.

Ampora speaks OpAMP, the Open Agent Management Protocol. Agents connect to the server over a long-lived WebSocket and report the config they have effectively applied (EffectiveConfig), their health, and their component status. The server pushes new configs, signed packages, and connection settings only to agents that signal the matching capability. Drift between assigned and effective configuration is visible in seconds, not hours.

3. Rollouts are risky without staging, diffs, health gates, and rollback¶

A bad change rolled to a whole fleet is an incident. Most teams cope by making changes rarely and being scared of them — exactly the opposite of what modern observability practice asks for.

Ampora gives rollouts a first-class lifecycle:

• Versioned configurations. Published versions are immutable.
• Diffs at both textual and semantic levels — the latter explains "added an exporter to the metrics pipeline" rather than "line 42 changed."
• Targeted rollouts. Static or label-based dynamic groups select agents. Batch sizes or percentage steps control rollout pace.
• Health gates halt the rollout if too many agents fail to apply, lose connection, or report unhealthy after the change.
• Rollback to the last stable version is one click, audited, and reverses the assignment without losing the rollout history.

Compared to common alternatives¶

What Ampora optimises for¶

• OpenTelemetry-first. Collector configuration stays natural and exportable — no proprietary DSL as the primary model.
• YAML is the source of truth. Visualisations are derived. We never reformat YAML on round-trip.
• Agent safety over comfort. Risky remote functions (binary updates, credential rotation, package transfer) require explicit capability and policy approval; defaults are conservative.
• Schrittweise Rollouts statt Big Bang. Always.
• Diffability before maximum UI polish. The most important screen is the diff between two configs.

When not to use Ampora¶

• You operate a handful of collectors and a single config file is fine. Use a config-management tool and call it a day.
• You only run Datadog Agents, Splunk Universal Forwarders, or Filebeat — none of those speak OpAMP. Ampora can manage any OpAMP-compatible agent, but speaks no proprietary management protocols.
• You need a full APM with code-level instrumentation. That is a different product category; Ampora is agent management, not backend.