Alert builder + Maintenance

/alerts heeft drie views: Alerts (live incidents), Rules (regel-builder), Maintenance (planned-downtime windows). De evaluator-worker tikt elke 60s en checkt elke geactiveerde regel.

Regels

Een regel is {target, metric, operator, threshold, duration, severity}. De worker fire’t pas als de conditie ≥duration_secs continuous geldt voor een (regel, agent) paar.

Targets

all — alle actieve agents in de tenant
agents — geselecteerde agent-id’s
tag — agents met deze tag (bv. production)

Metrics

Per-agent:

metric	bron	eenheid
`cpu_pct`	latest `cpu_metrics.cpu_percent`	%
`mem_pct`	latest `memory_metrics.mem_used / mem_total × 100`	%
`disk_pct`	MAX over `disk_metrics.used_bytes / total_bytes × 100` per mount, laatste 5min	%
`load_avg`	latest `cpu_metrics.load1`
`network_rx_mbps` / `network_tx_mbps`	SUM `network_metrics.{rx,tx}_bytes_per_sec` / 125000, laatste 90s	Mbps
`agent_offline`	EPOCH(NOW - last_seen_at)	sec
`container_status`	COUNT containers met status≠‘running’ (of specifieke container_name)
`process_running`	COUNT `process_samples` rijen met name=X laatste 2min

Fleet (multi-agent aggregaten):

metric	bron
`fleet_offline_count`	COUNT agents in target-set met `last_seen_at < NOW - 90s`
`fleet_critical_alerts`	COUNT unresolved critical alerts laatste 15min
`tag_offline_pct`	(offline / total) × 100 binnen target-set

Fleet-regels fire één alert per cycle, attributed aan de eerste agent in het doel.

Operators

>, >=, <, <=, ==, !=.

Duration

duration_secs=0 fire’t direct bij conditie-overschrijding. >0 vereist dat de conditie ≥X seconden onafgebroken geldt. De worker tracked dit per (rule_id, agent_id) in alert_rules.pending_since JSONB. Bij conditie-clear → key gedropt uit map.

Quick-start templates

In de UI (+ New rule modal) staan 8 templates. Klik om te populeren:

Sustained high CPU >85% for 1h
Memory >95% for 5m (critical)
Disk usage >90% (critical)
Load avg >10 for 10m
Agent offline >5m (critical)
Network TX >100 Mbps for 5m
Production container not running (target_type=tag, tag=production)
Fleet incident ≥3 production agents offline (fleet rule)

Maintenance windows

Tijdsgebonden silence van álle alert-bronnen (rules, process_dna, honeypot, heartbeat-silence) voor een target-set. Use case: rolling deploy van je flow → 30min window → geen pages.

maintenance_windows
  name            text not null
  starts_at       timestamptz
  ends_at         timestamptz
  target_type     'all' | 'agents' | 'tag'
  target_filter   jsonb   -- {agent_ids: [...]} | {tag: "..."}
  silence_categories text[]   -- leeg = alles silencen

Het belangrijke detail: ELKE alert die binnen het window valt, niet alleen rule-alerts, wordt onderdrukt. Dit gebeurt via een centrale InsertAlert(...) helper in de hub die elke insertion controleert tegen isUnderMaintenanceForCategory.

Categorieën die je per-window kan whitelisten in silence_categories (bv. wel security-alerts laten doorkomen tijdens een routine-upgrade):

rule — alert builder triggers
security — process DNA, honeypot
heartbeat — agent offline
compliance — control failures
cve — nieuwe CVE matches

Geen silence_categories (leeg array) = alle alerts silencen.

Notify channels

notify_channels op een regel is een array van webhook-id’s of strings. Bij een rule-fire:

Insert in alerts met category='rule'
NotifyWorker pickt op binnen 5s, send push naar ntfy voor severity=critical
Webhook-deliveries naar elke subscription die op alert.<severity> of alert.* is geabonneerd

Webhook payloads zijn HMAC-SHA256 gesigned met de subscription-secret in header X-Monsys-Signature. Failed deliveries retryen exponentieel tot 1h (webhook_outbox).

Audit

Elke POST/PUT/DELETE /api/v1/alert-rules* en */maintenance-windows* schrijft naar audit_log met method, path, status, resource_id, payload (secrets gescrubt via regex).