Add IP Fabric screenshot placeholders for documentation
This commit is contained in:
@@ -20,7 +20,7 @@ La distinction qui compte le plus, quand on vient du monde du monitoring, c'est
|
||||
|
||||
Cette distinction est précisément ce qui place l'outil dans la couche « topologie comme source de vérité » de la stack AIOps décrite dans la série de blog : un agent qui doit raisonner sur le réseau a besoin de cet état structuré avant d'avoir besoin de métriques.
|
||||
|
||||
[[CAPTURE: vue d'ensemble du dashboard IP Fabric]]
|
||||

|
||||
|
||||
## Comment fonctionnent discovery et snapshots, à haut niveau
|
||||
|
||||
@@ -32,7 +32,7 @@ Un **snapshot**, c'est le résultat d'une exécution de discovery, figé à un i
|
||||
|
||||
C'est ce modèle de snapshots qui rend possibles plusieurs des cas d'usage ci-dessous : comme l'historique n'est jamais jeté, une question du type « qu'est-ce qui a changé depuis hier » a une réponse directe, sans qu'il ait fallu anticiper et bricoler son propre système de diff.
|
||||
|
||||
[[CAPTURE: écran de liste des snapshots / paramètres de discovery]]
|
||||

|
||||
|
||||
## Cas d'usage
|
||||
|
||||
@@ -42,7 +42,7 @@ C'est le cas d'usage qui a tout déclenché pour moi, et celui référencé dire
|
||||
|
||||
Sur mon lab EVPN/VXLAN, ça veut dire que j'ai une réponse toujours à jour à la question « qu'est-ce qui est connecté à quoi », sans avoir à me fier à ma mémoire ou à un schéma périmé. C'est la couche qu'un agent IA devrait interroger en premier, avant tout le reste, s'il doit raisonner correctement sur le réseau — c'est tout l'enjeu du problème de « l'agent aveugle » évoqué dans la série de blog : un agent qui travaille sur une topologie obsolète se trompe avec assurance, il n'est pas prudemment incertain.
|
||||
|
||||
[[CAPTURE: diagramme de topologie IP Fabric du lab]]
|
||||

|
||||
|
||||
### Les intent checks
|
||||
|
||||
@@ -50,7 +50,7 @@ Les intent checks sont des règles qu'on définit une seule fois, du genre « pa
|
||||
|
||||
C'est là qu'IP Fabric bascule du « descriptif » (ce qui existe) au « normatif » (ce qui existe est-il correct). Ça rejoint naturellement le principe de standardisation que je répète souvent dans la série de blog : les intent checks permettent d'imposer la cohérence de nommage et de configuration automatiquement, plutôt que de compter sur un humain pour repérer une dérive.
|
||||
|
||||
[[CAPTURE: tableau de résultats des intent checks, coloré succès/échec]]
|
||||

|
||||
|
||||
### Le path lookup
|
||||
|
||||
@@ -58,7 +58,7 @@ Avec une source, une destination et, en option, un protocole/port, IP Fabric sim
|
||||
|
||||
Ça transforme un « pourquoi cet hôte ne peut-il pas joindre cet autre hôte » (normalement une investigation multi-équipements et multi-commandes `show`) en une seule requête. Ça permet aussi de vérifier la posture de sécurité : un path lookup indique si une ACL ou une règle de pare-feu bloque le trafic quelque part sur le chemin.
|
||||
|
||||
[[CAPTURE: diagramme de path lookup entre deux hôtes du lab]]
|
||||

|
||||
|
||||
### La comparaison de snapshots
|
||||
|
||||
@@ -66,7 +66,7 @@ Comme chaque exécution de discovery est conservée sous forme de snapshot, IP F
|
||||
|
||||
C'est la réponse concrète à « qu'est-ce qui a vraiment changé », d'ordinaire la question la plus difficile à répondre après un incident. Plutôt que de reconstituer une chronologie de mémoire ou à partir de tickets de changement épars, le diff est déjà là.
|
||||
|
||||
[[CAPTURE: vue de diff entre deux snapshots avec éléments ajoutés/retirés]]
|
||||

|
||||
|
||||
### L'accès programmatique : SDK Python et serveur MCP
|
||||
|
||||
@@ -76,4 +76,4 @@ Plus pertinent encore pour l'angle AIOps de la série de blog : IP Fabric propos
|
||||
|
||||
Je n'ai pas encore branché ça sur mon lab ; c'est un chantier à venir, et de futures sections ici.
|
||||
|
||||
[[CAPTURE: liste des outils du serveur MCP ou exemple de requête d'un agent]]
|
||||

|
||||
|
||||
Reference in New Issue
Block a user