Alert builder + Maintenance

/alerts propose trois vues : Alerts (incidents live), Rules (constructeur de règles), Maintenance (fenêtres downtime). Le worker d’évaluation tique toutes les 60s et vérifie chaque règle activée.

Règles

Une règle est {target, metric, operator, threshold, duration, severity}. Le worker ne fire que si la condition tient ≥duration_secs continu pour une paire (règle, agent).

Targets

all — tous les agents actifs du tenant
agents — agent-id sélectionnés
tag — agents avec ce tag (ex. production)

Metrics

Par agent :

metric	source	unité
`cpu_pct`	dernière `cpu_metrics.cpu_percent`	%
`mem_pct`	dernière `memory_metrics.mem_used / mem_total × 100`	%
`disk_pct`	MAX sur `disk_metrics.used_bytes / total_bytes × 100` par mount, 5min	%
`load_avg`	dernière `cpu_metrics.load1`
`network_rx_mbps` / `network_tx_mbps`	SUM `network_metrics.{rx,tx}_bytes_per_sec` / 125000, 90s	Mbps
`agent_offline`	EPOCH(NOW - last_seen_at)	sec
`container_status`	COUNT containers status≠‘running’ (ou container_name spécifique)
`process_running`	COUNT `process_samples` rows avec name=X, 2min

Fleet (agrégats multi-agents) :

metric	source
`fleet_offline_count`	COUNT agents in target-set avec `last_seen_at < NOW - 90s`
`fleet_critical_alerts`	COUNT unresolved critical alerts last 15min
`tag_offline_pct`	(offline / total) × 100 dans la target-set

Les règles fleet émettent une seule alerte par cycle, attribuée au premier agent de la cible.

Operators

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

Duration

duration_secs=0 fire dès dépassement. >0 exige que la condition tienne ≥X secondes consécutives. Le worker tracke par (rule_id, agent_id) dans alert_rules.pending_since JSONB. Au clear → key supprimée.

Templates quick-start

Dans l’UI (modale + New rule), 8 templates. Clic pour pré-remplir :

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)

Fenêtres de maintenance

Silence temporaire de toutes les sources d’alerte (rules, process_dna, honeypot, heartbeat-silence) pour une target-set. Use-case : rolling deploy de vos flows → window 30min → pas de 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[]   -- vide = tout silence

Détail important : chaque alerte tombant dans la window, pas seulement les rule-alerts, est supprimée. Cela passe par un helper central InsertAlert(...) dans la hub qui contrôle chaque insertion contre isUnderMaintenanceForCategory.

Catégories whitelistables dans silence_categories (ex. laisser passer les security-alerts pendant un upgrade routine) :

rule — triggers de l’alert builder
security — process DNA, honeypot
heartbeat — agent offline
compliance — control failures
cve — nouveaux CVE matches

Pas de silence_categories (array vide) = tout silence.

Canaux de notification

notify_channels sur une règle est un array d’IDs webhook ou strings. Sur rule-fire :

Insert dans alerts avec category='rule'
NotifyWorker ramasse en 5s, push vers ntfy pour severity=critical
Webhook deliveries vers chaque subscription abonnée à alert.<severity> ou alert.*

Les payloads webhook sont signés HMAC-SHA256 avec le secret de subscription dans le header X-Monsys-Signature. Failed deliveries retryées en exponential jusqu’à 1h (webhook_outbox).

Audit

Chaque POST/PUT/DELETE /api/v1/alert-rules* et */maintenance-windows* écrit dans audit_log avec method, path, status, resource_id, payload (secrets scrubbés via regex).