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
anomaly_cpu_pct / anomaly_mem_pct / anomaly_load_avg	z-score van het 15-min gemiddelde t.o.v. de per-host baseline voor het huidige UTC-uur	σ

Anomalie-regels vergelijken niet met een vaste drempel maar met het normale gedrag van die host op dat uur van de dag. De BaselineWorker herrekent twee keer per dag een uur-van-dag profiel (gemiddelde + stddev over de laatste 30 dagen) per agent. Een regel anomaly_cpu_pct > 3 vuurt dus pas als de CPU meer dan 3σ boven het gebruikelijke niveau zit voor dit uur. Hosts zonder baseline (jonger dan een paar dagen) blijven stil; een stddev-vloer (5 % CPU, 3 % geheugen, 0.3 load) voorkomt dat een idle host bij elke rimpel alarmeert.

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:

1. Insert in alerts met category='rule'
2. NotifyWorker pickt op binnen 5s, send push naar ntfy voor severity=critical
3. 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).