Multi-Source VictoriaLogs Example

A single Valerter instance tails two VictoriaLogs backends (prod and staging) and routes alerts per source.

Routing Matrix

The config.yaml file defines 2 sources and 3 rules covering the three routing patterns:

Rule	vl_sources	Spawns tasks for	Use case
prod_critical_errors	[prod]	(rule, prod)	Pin a rule to one backend
staging_deploy_failures	[staging]	(rule, staging)	Pin a rule to another backend
auth_failures_all_envs	(omitted)	(rule, prod) + (rule, staging)	Fan out across every source

Each (rule, source) pair runs as an isolated task with per-source reconnect with ±10% jitter. A flapping staging backend does not stop alerts on prod. The throttle cache is shared by a rule’s sources, but the default key {rule}-{source}:global contains the source name, so each source still gets its own bucket. A custom throttle.key without {{ vl_source }} (e.g. {{ rule_name }}) dedups the rule’s alerts across sources instead.

Source Name Constraints

Source names must match ^[a-zA-Z0-9_]+$ (alphanumeric or underscore only). No dashes, dots, or colons. The constraint avoids ambiguity in the default throttle key format.

Stream Cap

defaults.max_streams (default 50) caps the total number of (rule, source) pairs spawned. Disabled rules do not contribute. Breaching the cap fails the config at load with the actual count and the cap value. Tune the limit if you fan many rules across many sources.

Run It

# Set the basic_auth secrets referenced via ${...} in this example
export VL_PROD_USER="prod_user"
export VL_PROD_PASS="prod_password"

# Edit webhook_url in config.yaml to point at your real Mattermost hook.
# `webhook_url: "${WEBHOOK_URL}"` works too, but WEBHOOK_URL must then be
# exported before `--validate`, which builds every notifier.

# Validate the config
valerter --validate -c examples/multi-source/config.yaml

# Run it
valerter -c examples/multi-source/config.yaml

Observability

The valerter_vl_source_up{vl_source} gauge reports per-source reachability. It exists only for the sources targeted by at least one enabled rule: it starts at 0, goes to 1 on the first successful tail connection, and goes back to 0 only after 3 consecutive connection failures, so a single transient error does not flip it. All per-rule metrics carry a vl_source label so dashboards can group or filter by source. See docs/metrics.md for the metrics reference, and MIGRATION.md to migrate v1.x dashboards and alerts.