Aller au contenu

Architecture

DumbMonit est livré dans un seul conteneur. À l’intérieur, un processus Rust sert l’interface web et l’API, et démarre puis supervise un processus enfant (VictoriaMetrics). La configuration et l’état vivent dans SQLite.

ComposantOùRôle
Serveurcrates/serverLe binaire Rust unique : API HTTP (axum), authentification, planificateur, moteur d’alertes, canaux de notification, rapports.
Interface webweb/Application SvelteKit monopage (Svelte 5, Tailwind 4, uPlot), compilée en fichiers statiques et embarquée dans le binaire avec rust_embed.
Séries temporellescrates/server/src/tsdb/Écrivain par lots et proxy de requêtes pour VictoriaMetrics. embedded.rs démarre et supervise le VictoriaMetrics fourni (données dans /data/vm) ; DUMBMONIT_VM_URL désigne une instance externe à la place.
Configuration et étatcrates/server/src/db/SQLite avec migrations numérotées : surveillances, identifiants, utilisateurs, règles, état des alertes, silences, canaux.
Collecteurscrates/collectors, crates/server/src/collectors/Une implémentation du trait Collector par type de surveillance ou de service, enregistrée dans un Registry. Le planificateur ne connaît que le trait.
Types partagéscrates/protoSample, Target, Credential, le trait Collector et ProbeError, et le protocole d’agent.
Agentcrates/agentAgent Linux, macOS, FreeBSD et Windows qui envoie les métriques de la machine ; il peut aussi servir de relais et exécuter les collecteurs d’un site distant.
Alertescrates/server/src/alerting/Règles, machine à états des alertes, suppression par parent, silences, références apprises.
Notificationscrates/server/src/notify/Canaux (messagerie, push, astreinte, e-mail, webhooks), décrits à l’interface par catalog.rs.
Secretscrates/server/src/crypto.rsAES-256-GCM pour les identifiants et jetons stockés dans SQLite ; la clé vient de /data/secret.key ou de DUMBMONIT_SECRET.
surveillances / services ──(SNMP, API HTTP, sondes)──► collecteurs ┐
│ échantillons
agents ──(envoi, jeton par machine)──► /api/ingest ──────────────┤
agent relais (collecteurs d'un site distant) ────────────────────┤
▼
écrivain tsdb (lots) ──► VictoriaMetrics
│
navigateur / scripts / assistants ◄─ /api/* ◄─ proxy de requêtes ◄────┘
│
└─► moteur d'alertes ──► canaux de notification
SQLite (configuration, utilisateurs, état des alertes, silences) est lu et
écrit par l'API, le planificateur et le moteur d'alertes.
  1. Le planificateur exécute chaque surveillance activée à son intervalle, par le registre de collecteurs. Les agents et relais envoient leurs mesures à /api/ingest avec un jeton propre à chaque machine.
  2. Les collecteurs renvoient des échantillons nommés dumbmonit_<type>_* avec une étiquette target (l’identifiant de la surveillance). L’écrivain les envoie par lots à VictoriaMetrics.
  3. Le moteur d’alertes évalue les règles sur les séries stockées. phase est l’état du moteur ; effective_phase est ce que voient les utilisateurs (suppressed quand une surveillance parente est en panne). Une surveillance injoignable déclenche une alerte ; une erreur de configuration est affichée mais pas notifiée.
  4. Les notifications partent par les canaux de la politique de notification.
  5. L’interface et les scripts lisent tout par /api/* : il n’y a pas de moitié privée de l’API.
  • Un nouveau type de surveillance est une implémentation de Collector et un appel à Registry::register. Les formulaires de l’interface sont générés à partir de GET /api/collectors.
  • Un nouveau canal de notification est un émetteur et une entrée dans notify/catalog.rs ; l’interface construit le formulaire à partir de GET /api/notify/kinds.
  • Un appareil SNMP qui n’a besoin que d’un profil n’exige pas de Rust : un fichier YAML dans profiles/.

Voir Développement pour la compilation et Modèle de sécurité pour les frontières de confiance.