Skip to content

Validation & lint

Three layers of checks, each stricter than the previous. A configuration must pass all three before it can be Published.

1. Syntax

YAML must parse. Errors here are reported with line and column. The editor's red gutter marker takes you to the offending location.

2. Semantic validation

The structure must make sense as an OpenTelemetry Collector config:

  • Components referenced in service.pipelines must exist in the receivers: / processors: / exporters: / connectors: blocks.
  • Pipelines must have at least one receiver and at least one exporter.
  • Component aliases must be unique within a type.
  • Connector pipeline pairing must be consistent.
  • Unsupported component kinds (typos, vendor-specific types Ampora does not know about) are flagged.

Validation errors point at the YAML path (service.pipelines.traces.processors[0]) and the file line. The visualiser also highlights the affected pipeline.

3. Lint

Lint rules are richer policy-style checks on top of validation. Defaults include:

  • no exporter with tls.insecure: true outside localhost / 127.0.0.1,
  • no pipeline with zero exporters (silent black hole),
  • no 0.0.0.0 listener without an explicit allow-list comment,
  • no debug exporter as the only exporter on a pipeline,
  • consistent batch placement (recommended near the start of the processors chain).

Lint findings are blocking by default but can be downgraded to warnings per rule per tenant.

Tenant-specific lint rules

Settings → Lint rules lets Admins extend the default set with tenant-scoped rules in the same expression DSL the policy engine uses. Examples:

  • "Every exporter must use TLS" — not (any (exporter has-key insecure) where exporter.insecure == true).
  • "Hostmetrics interval must be ≤ 60s".
  • "Service.namespace label must be present in every config".

The DSL grammar is on Custom policy DSL; lint and policy share the language.

Severity

Each lint finding has a severity:

  • Error — blocks Publish.
  • Warning — does not block, shown as yellow chips, surfaced in reviews.
  • Info — for stylistic guidance, never blocks.

Auto-fix

Some lint findings ship with an auto-fix. The chip has a "Apply fix" button that rewrites the YAML in place. Auto-fix never changes behaviour — it only normalises form (whitespace, missing processors: [] for an empty list, etc.).

Severity tuning

Per rule per tenant. Settings → Lint rules → {rule} → Severity selects between Error / Warning / Info. The change is audited.

Skipping a finding

In rare cases an operator must accept a known finding. Annotate the YAML with a # ampora.lint.disable: <rule-id> comment on the line that triggered it. The annotation is preserved through the visual editor.

The annotation itself is auditable — the audit log records the comment, the rule, the configuration version, and the actor who added it.