Architecture

Composants

agent (Rust, sur chaque hôte)
  │  HTTPS batches : métriques · cœurs battants · inventaire · alertes · événements de piège
  ▼
hub-api  (Go + Gin)  ──►  TimescaleDB  (Postgres avec extension Timescale)
                     ├──  Redis        (limitation de vitesse · cache)
                     ├──  NATS         (bus de messages interne)
                     └──  Ollama       (LLM locale pour "Expliquez cela")
hub-api  ──►  tableau de bord (Next.js)
        └──  push d'urgence par websocket  ──►  agent

Pourquoi pas Prometheus

Toutes les données doivent être dans une seule base de données — les joints entre alertes et métriques sont alors SQL, pas PromQL plus logique d’applications. Les hypertables TimescaleDB fournissent les performances chronologiques sans introduire un deuxième système opérationnel.

Compromis : nous perdons la découverte de service basée sur le pull de Prometheus et l’écosystème d’exportateurs. Pour surveiller le plateforme elle-même , nous exposons /metrics à api.monsys.ai sous forme de exposition Prometheus.

Pourquoi Caddy

Auto-TLS via Let’s Encrypt sans configuration. Les sous-domaines sont stables, il n’y a donc pas de raison pour gérer manuellement le cycle TLS comme avec nginx.

Pourquoi Rust pour l’agent

L’agent tourne sur chaque hôte surveillé : empreinte et fiabilité dominent. Rust fournit une bibliothèque statique liée de ~12 MB sans dépendances runtime, mémoire prévisible sous charge (pas de pauses GC qui ressemblent à des pics CPU), et le système de types attrape les erreurs que un daemon longue durée ne doit pas avoir.

Pourquoi Ed25519 pour les jetons d’action d’urgence

Nous voulons donner au agent aucun droits root permanents. Les jetons donnent la même puissance opérationnelle pendant quelques minutes qu’un incident dure et expirent ensuite. En cas de compromission du hub, les nonces bloquent les replays ; en cas de compromission de l’agent, il n’y a pas de clés longues sur la table.