Topologie & architecture

/topology affiche un graphe de nœuds (serveurs, équipements réseau, services externes) et arêtes (liaisons entre eux). Deux sources alimentent ce graphe :

Auto-détecté — Les agents Monsys signalent leurs propres IPs et ports d’écoute ; le hub déduit les liaisons potentielles entre les agents dans le même sous-réseau
Manuel — Ajoutez les services externes qui ne tournent pas d’agent (SaaS, uplink ISP, CDN, fournisseur cloud externe) via l’interface utilisateur ou l’API

Modèle de données

Table	Ce qu’il stocke
`topology_nodes`	Serveurs, VMs, commutateurs, services externes — 30+ types de nœuds
`topology_edges`	Liaisons avec protocole, port, encryption, importance
`topology_zones`	Zones réseau / VLANs / sous-réseaux / VPC cloud
`topology_certificates`	Certificats TLS liés aux arêtes (CN, SAN, expiration)
`topology_node_configs`	Configurations spécifiques à l’appareil (markdown), historique de versions
`topology_snapshots`	Sauvegardes JSONB pointues pour suivre les changements
`topology_changes`	Journal d’audit append-only de qui a fait quoi et quand
`topology_detected_connections`	Table intermédiaire : auto-détecté mais pas encore documenté

Isolement du locataire via Postgres RLS — Chaque ligne a un tenant_id et la politique correspond à current_setting('app.current_tenant') sur chaque requête.

Auto-bootstrap

TopologyMatcherWorker tourne toutes les 10 minutes et :

Crée un topology_node pour chaque agent actif qui n’en a pas encore (étiquette = nom, type = serveur, géré par Monsys = vrai)
Étend agent_connections × inventory_ports (seulement non-loopback) en lignes de détection par port dans topology_detected_connections

Un nouveau agent Monsys apparaît donc dans le diagramme dès qu’il pousse l’inventaire (~5 minutes après l’installation).

Détection vs. documentation

Les liaisons auto-détectées ont is_documented = false. Dans la tab Détection de l’interface utilisateur (ou GET /api/v1/topology/detected?unmatched=1) vous voyez pour chaque liaison :

Agent source + IP destination + port + protocole
Première/ dernière fois vue
Bouton Promote → pour choisir un nœud cible. Cela crée une vraie topology_edge avec is_documented = true.

Ainsi, le diagramme grandit de manière organique : chaque nouvelle liaison a un moment “approuver cela” pour l’opérateur.

API

Méthode	Chemin
`GET /api/v1/topology/nodes`	Liste des nœuds avec statut agent + dernier vu
`POST /api/v1/topology/nodes`	Nouveau nœud (manuel — SaaS, commutateur, …)
`PATCH /api/v1/topology/nodes/:id`	Mettre à jour (blanc liste sur champs éditables)
`DELETE /api/v1/topology/nodes/:id`	Supprimer
`GET /api/v1/topology/edges` · `POST` · `DELETE /:id`	CRUD arêtes
`GET /api/v1/topology/zones` · `POST`	CRUD zones
`GET /api/v1/topology/detected[?unmatched=1]`	Liste auto-détectée
`POST /api/v1/topology/detected/:id/promote`	Promouvoir → arête
`GET /api/v1/topology/snapshots` · `POST`	Sauvegardes
`GET /api/v1/topology/export/mermaid`	Téléchargement de graphique Mermaid

Interface utilisateur

L’interface utilisateur a 4 onglets :

Diagramme — Canvas React Flow avec drag-to-position (position stockée par drag-end via PATCH /nodes/:id), drag-to-connect entre nœuds (créer nouvelle arête), clavier Delete pour supprimer les arêtes
Détection — flux de promotion (voir ci-dessus)
Sauvegardes — Sauvegardes pointues avec comptage de nœuds/edges
Nœuds & arêtes — Vue tableau de lecture+suppression

Style des arêtes :

Solide vert = chiffré et documenté
Rouge solide + animé = critique
Orange tracé = auto-détecté mais pas documenté

Liens connexes

Diagrammes — Utilise cette topologie comme entrée pour l’export PNG/SVG/PDF avec algorithmes de disposition
Rayon d’explosion — Utilise les mêmes arêtes pour la portée 3-hops par hôte