Monitoring integration

"Does it feed our NMS?" — yes, without asking permission first: metrics are on by default and render from state the daemon already keeps, so scraping costs nothing and not scraping costs less. This guide wires the four consumers most integrations want: Prometheus, a liveness probe, an event pipeline, and a SIEM.

Prometheus

scrape_configs:
  - job_name: atlas
    metrics_path: /metrics
    static_configs:
      - targets: ['node-a:9800', 'node-b:9800']

The exposition covers links, peers, mesh, quotas and transport classes in base units (seconds, 0–1 ratios, bits/second) with disciplined labels. Starter rules that catch what actually goes wrong:

groups:
- name: atlas
  rules:
  - alert: AtlasLinkDown
    expr: atlas_link_up == 0
    for: 1m
    annotations: {summary: "{{ $labels.link }} on {{ $labels.interface }} is down"}
  - alert: AtlasBondDegraded
    expr: sum by (interface) (atlas_link_up) < 2
    for: 2m
    annotations: {summary: "{{ $labels.interface }} is running on a single link"}
  - alert: AtlasPeerSilent
    expr: time() - atlas_peer_last_handshake_seconds > 300
    annotations: {summary: "no handshake with {{ $labels.peer }} for 5m"}
  - alert: AtlasQuotaBurning
    expr: atlas_link_quota_used_ratio > 0.8
    annotations: {summary: "{{ $labels.link }} has spent 80% of its data budget"}

The second rule is the one people wish they had written earlier: a bond that has quietly degraded to one link is working perfectly and one failure from silence — no single-link metric will ever page you about it.

Liveness probes

GET /api/health is a complete probe, not a ping: it verifies the daemon is alive, the data path is genuinely moving, links are being probed on cadence and peers are established — 200 with named checks, or 503 naming what failed.

# Anything that understands exit codes:
curl -fsS http://node-a:9800/api/health >/dev/null

# Kubernetes-style, or any orchestration with HTTP probes:
livenessProbe: {httpGet: {path: /api/health, port: 9800}}

Below the HTTP layer, the systemd unit already feeds a hardware-grade watchdog from data-path liveness — the deployment guide covers it. The HTTP probe is for your orchestration; the watchdog is for the node itself.

Event pipelines

Metrics say that; the journal says why. Every state transition is a structured entry with a stable machine code — link.down, link.quota_warn, peer.session_established, config.committed — which makes event-driven tooling honest to build:

# Tail flap events into anything that reads JSON lines
atlasd journal -c link --follow --json | your-pipeline

# Or poll over HTTP with cursor paging
curl "http://node-a:9800/api/journal?category=link&severity=warn&since=1h"

Build automation against the code field, never the human-readable message — messages are prose and may improve; codes are contracts.

SIEM: syslog / CEF opt-in · default off

[syslog]
enabled = true
target = "udp://siem.example.internal:514"   # or tcp://…, or unix:///dev/log
format = "cef"                               # or "rfc5424"
min_severity = "notice"

The same journal events, in the format your collector already parses; the stable event codes become the CEF signature id / syslog MSGID, so correlation rules survive daemon upgrades. Delivery is a bounded queue drained by one writer — a dead collector never stalls the daemon, and dropped events are counted and reported into the stream once it returns.

Everything else

Anything the above doesn't fit can read the source of it all: /tmp/atlas/<iface>.json, rewritten every second, no HTTP required. It is the same document the dashboard, CLI and API serve — one state, many doors, no privileged view.