Sur cette page

Flux de donnees

Comprendre comment les donnees circulent a travers la plateforme Mugnsoft est essentiel pour le depannage, la planification de capacite et la conception des integrations.

Vue d’ensemble

Les donnees dans Mugnsoft circulent selon trois chemins principaux :

  1. Flux de gestion – commandes de configuration et de controle du Webserver vers les composants
  2. Flux de supervision – resultats des controles des Monitors vers le Webserver et l’Integrator
  3. Flux d’integration – donnees transformees de l’Integrator vers les systemes tiers

1. Flux de gestion (Webserver vers les composants)

Le Webserver est le plan de controle central. Il gere le cycle de vie des composants et pousse la configuration :

graph LR User["👤 User
(WebUI / API)"] WS["Webserver"] MON["Monitor Probe"] INT["Integrator"] DA["Discovery Agent"] User --> WS WS -->|"push settings"| MON WS -->|"push settings"| INT WS -->|"push settings"| DA style WS fill:#4a90d9,stroke:#2c5ea0,color:#fff

Operations cles :

  • Pousser les definitions de moniteurs (creer, mettre a jour, supprimer des moniteurs)
  • Pousser les parametres des composants (niveau de log, retention, seuils)
  • Declencher l’execution d’un moniteur a la demande
  • Arreter les processus de moniteur en cours d’execution
  • Recharger les certificats TLS
  • Sauvegarder/restaurer les magasins KV

Toutes les commandes de gestion sont authentifiees avec des jetons JWT et transportees via mTLS.

2. Flux de supervision (Collecte de donnees)

Monitor vers Webserver (Modele Pull)

Le Webserver tire les donnees des sondes Monitor. Les Monitors ne poussent pas les resultats vers le Webserver de leur propre initiative.

sequenceDiagram participant MON as Monitor Probe participant DB as magasin cle-valeur integre (local) participant WS as Webserver MON->>MON: Execute check (cron schedule) MON->>DB: Store result WS->>MON: GET /monitor/monitorsStatus (periodic poll) MON-->>WS: JSON status data WS->>MON: GET /monitor/timelineGraph (on-demand) MON-->>WS: Historical data

Donnees stockees par execution de moniteur :

Bucket Contenu
STATUS Statut actuel (OK, MINOR, MAJOR, CRITICAL, ERROR, DOWN)
STATUS_PERF Metriques de performance (temps de reponse, recherche DNS, connexion TCP, negociation TLS, etc.)
STATUS_TRANS Donnees de chronometrage des transactions (pour les scenarios EUM multi-etapes)
STATUS_CHANGE Historique des changements de statut avec horodatages
STATUS_ERROR Messages d’erreur et details
STATUS_HISTALL Donnees historiques completes
STATUS_PATTERN Resultats de correspondance de motifs

Monitor vers Integrator (Modele Push)

Lorsqu’un Monitor est lie a un Integrator, il pousse les resultats directement apres chaque execution :

graph LR MON["Monitor Probe"] -->|"POST /integrator/data2integrator"| INT["Integrator"] style MON fill:#5cb85c,stroke:#3d8b3d,color:#fff style INT fill:#d9984f,stroke:#b07830,color:#fff

Le Monitor envoie une charge utile JSON contenant :

  • Nom du moniteur, type et identite de la sonde
  • Statut actuel et entier de statut (0=OK a 6=EXCEPTION)
  • Valeurs de performance (temps de reponse, DNS, TCP, TLS, etc.)
  • Details des transactions (pour les moniteurs EUM)
  • Configuration des canaux de notification (email, Slack, Teams, PagerDuty)
  • Etat d’alerte (indicateur de changement de statut, alertes activees/desactivees)

Discovery Agent vers Integrator

Le Discovery Agent pousse les metriques systeme et processus vers l’Integrator :

graph LR DA["Discovery Agent"] -->|"POST /integrator/data2integratorDisco"| INT["Integrator"] style DA fill:#9b59b6,stroke:#7d3c98,color:#fff style INT fill:#d9984f,stroke:#b07830,color:#fff

Les metriques incluent le CPU par processus, la memoire, les I/O, le trafic reseau et les metriques a l’echelle du systeme avec les informations de depassement de seuils.

3. Flux d’integration (Sortant)

L’Integrator recoit les donnees des Monitors et des Discovery Agents, puis les distribue vers de multiples destinations :

graph TD INT["Integrator"] INFLUX["InfluxDB"] SPLUNK["Splunk"] ELASTIC["Elasticsearch"] KAFKA["Kafka"] ZABBIX["Zabbix"] CSV["CSV / JSON
(local export)"] EMAIL["📧 Email"] SLACK["💬 Slack"] TEAMS["💬 Teams"] PD["🔔 PagerDuty"] SCRIPT["⚙️ Scripts"] INT -->|"push"| INFLUX INT -->|"push"| SPLUNK INT -->|"push"| ELASTIC INT -->|"push"| KAFKA ZABBIX -->|"pull"| INT INT --> CSV INT -->|"alert"| EMAIL INT -->|"alert"| SLACK INT -->|"alert"| TEAMS INT -->|"alert"| PD INT -->|"alert"| SCRIPT style INT fill:#d9984f,stroke:#b07830,color:#fff

Integrations en mode Push

Cible Protocole Format
InfluxDB v1/v2/v3 HTTP Write API Line protocol
Splunk HTTP Event Collector (HEC) JSON events
Elasticsearch Bulk API (_bulk) JSON documents
Kafka TCP (avec SASL/TLS) Line protocol
Canopsis HTTP API JSON events

Integrations en mode Pull

Cible Mecanisme
Zabbix Interroge l’API REST de l’Integrator (/integrator/{bucket}/allV) pour lire les donnees en cache

Export de donnees

Format Description
CSV Export en fichier local par moniteur
JSON Export en fichier local par moniteur

4. Flux d’alertes

Les alertes peuvent etre declenchees a deux niveaux :

Alertes au niveau du composant (Monitor / Discovery Agent)

Chaque Monitor et Discovery Agent peut envoyer des alertes directement, sans avoir besoin d’un Integrator :

graph LR MON["Monitor /
Discovery Agent"] EMAIL["📧 Email"] SLACK["💬 Slack"] TEAMS["💬 Teams"] PD["🔔 PagerDuty"] SCRIPT["⚙️ Custom Script"] MON --> EMAIL MON --> SLACK MON --> TEAMS MON --> PD MON --> SCRIPT style MON fill:#5cb85c,stroke:#3d8b3d,color:#fff

Alertes au niveau de l’Integrator

Lorsque les moniteurs sont lies a un Integrator, l’Integrator gere les alertes de maniere centralisee :

graph LR MON["Monitor"] -->|"data"| INT["Integrator"] --> ALERT["Email / Slack / Teams /
PagerDuty / Script"] style INT fill:#d9984f,stroke:#b07830,color:#fff

Declencheurs d’alertes :

  • En cas d’echec (emailOnF, slackOnF, etc.) – envoyer une alerte lorsque le statut n’est pas OK
  • En cas de changement de statut (emailOnSC, slackOnSC, etc.) – envoyer une alerte uniquement lors d’une transition de statut
  • Notifier apres – attendre N echecs consecutifs avant d’alerter (evite le clignotement)
  • Notifier pendant – continuer a alerter pendant N cycles apres le depassement initial

5. Flux d’authentification

Enregistrement des composants

sequenceDiagram participant COMP as New Component participant WS as Webserver COMP->>WS: POST /selfRegister (config + RSA public key) WS-->>COMP: 200 OK COMP->>WS: POST /selfRegisterCert (TLS certificate) WS-->>COMP: 200 OK

Cycle de vie des jetons JWT

sequenceDiagram participant C as Component / User participant WS as Webserver C->>WS: POST /api/auth (user) or POST /loginComponent WS-->>C: JWT token (15min user / 60d component) Note over C,WS: Token included in all requests:
Authorization: Bearer <token> C->>WS: GET /refresh_token (before expiry) WS-->>C: New JWT token

Horodatages et formats de donnees

Element Format
Horodatages Millisecondes Unix (epoch en ms)
Codes de statut 0=OK, 1=MINOR, 2=MAJOR, 3=CRITICAL, 4=CONFIG, 5=TIMEOUT, 6=EXCEPTION
Couleurs de statut Green (#5cb85c), Yellow (#D5D94F), Orange (#D9984F), Red (#d9534f), Blue (#428bca), Gray (#E1DFDF)
Retention des donnees Configurable par composant (par defaut : 336 heures / 14 jours)
Intervalle de sauvegarde Configurable (par defaut : 24 heures pour le Monitor, 8 heures pour le Webserver)

Traductions

Modele de securite