Skip to content

Author and validate a config

You will create a small but realistic OpenTelemetry Collector configuration in Ampora, watch the validator catch a deliberate mistake, and publish it as an immutable version ready for rollout.

Time: ~ 10 minutes.

Prerequisites

  • You completed Connect your first agent so you understand the inventory view.
  • You are logged in as an Admin or Operator.

1. Create the configuration container

  1. Configurations → New configuration.
  2. Name it edge-collector.
  3. Description (optional): "Edge collectors that ingest OTLP and forward to the central tier."
  4. Click Create. You land on the empty draft editor.

2. Paste a starter config

Paste this YAML into the editor:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu: {}
      memory: {}
      disk: {}

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024
  resource/edge:
    attributes:
      - key: deployment.tier
        value: edge
        action: upsert

exporters:
  otlp/central:
    endpoint: central-collector.example.internal:4317
    tls:
      insecure: false
  prometheusremotewrite/central:
    endpoint: https://prom.example.internal/api/v1/write

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resource/edge]
      exporters: [otlp/central]
    metrics:
      receivers: [otlp, hostmetrics]
      processors: [batch, resource/edge]
      exporters: [prometheusremotewrite/central]
    logs:
      receivers: [otlp]
      processors: [batch, resource/edge]
      exporters: [otlp/central]

Save as draft.

3. Read the swimlane

Switch to Pipeline view. You should see three swimlanes (one per signal), each rendered as a graph:

  • traces: otlp → batch → resource/edge → otlp/central
  • metrics: (otlp, hostmetrics) → batch → resource/edge → prometheusremotewrite/central
  • logs: otlp → batch → resource/edge → otlp/central

Hover any node to see the underlying YAML for that component highlighted in the editor pane.

4. Break it on purpose

Edit the config and rename the batch processor in the traces pipeline to batch-trace:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch-trace, resource/edge]   # ← typo
      exporters: [otlp/central]

Save. The validator panel turns red. The error reads:

service.pipelines.traces.processors[0]: referenced component batch-trace is not defined in processors:.

The Pipeline view also flags the broken pipeline with a warning chip.

5. Fix it

Restore batch-trace to batch and save. Validation goes green again.

6. Run the linter

The linter is a richer set of rules on top of the validator. Click Lint. Default rules check for things like:

  • exporters with tls.insecure: true outside a localhost endpoint,
  • pipelines with no exporter,
  • duplicate component names across signal types,
  • receivers that bind to all interfaces (0.0.0.0) without a documented reason — controlled by tenant policy.

Add or relax rules in Settings → Lint rules (Admin only).

7. Diff against the previous version

The first save creates a base. Edit the file again — say, raise hostmetrics.collection_interval to 60s — and save.

Open Versions and click Compare:

  • Textual diff — the unified diff with line numbers.
  • Semantic diff — the meaning of the change:

    processors.hostmetrics.collection_interval: 30s → 60s

Semantic diff is the field reviewers should be reading on PRs. It collapses formatting noise (re-indented YAML, anchor expansion) into actual behaviour changes.

8. Publish

Once the validator and linter are green and you are happy with the diff:

  1. Click Publish.
  2. A modal asks for a release note ("Reduce hostmetrics interval to 60s").
  3. Confirm.

The version becomes immutable and gets a content hash. The container shows it in the Versions list with a Published badge. The same hash will appear on every agent that runs this config — that is how Ampora knows when an agent has actually applied your change.

What you learned

  • How drafts, versions and publishes work.
  • How the validator and linter surface errors in YAML.
  • How the swimlane visualises pipelines per signal.
  • How textual and semantic diffs differ and which to trust for review.

Next