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
anomaly_cpu_pct / anomaly_mem_pct / anomaly_load_avg	z-score de la moyenne sur 15 min par rapport à la baseline de l’hôte pour l’heure UTC courante	σ

Les règles d’anomalie ne comparent pas à un seuil fixe mais au comportement normal de cet hôte à cette heure de la journée. Le BaselineWorker recalcule deux fois par jour un profil par heure (moyenne + écart-type sur les 30 derniers jours) par agent. Une règle anomaly_cpu_pct > 3 ne se déclenche donc que si le CPU dépasse de plus de 3σ le niveau habituel pour cette heure. Les hôtes sans baseline (moins de quelques jours d’historique) restent silencieux ; un plancher d’écart-type (5 % CPU, 3 % mémoire, 0.3 load) évite qu’un hôte inactif alerte à la moindre ondulation.

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 :

1. Insert dans alerts avec category='rule'
2. NotifyWorker ramasse en 5s, push vers ntfy pour severity=critical
3. 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).