Réalité de production (Living Diagram)

The Reality panel compares production with your model

Reality (la « Réalité ») transforme votre diagramme C4 en une vue vivante de ce qui tourne réellement. Connectez des sources de production en lecture seule — Kubernetes, Datadog, New Relic — et Archyl découvre vos services réels et leurs dépendances, puis les réconcilie avec votre modèle organisé. Votre diagramme cesse d'être un instantané et se met à refléter la production.

Reality est en lecture seule et sans effet destructeur : le scan ne modifie jamais votre infrastructure, et il ne modifie jamais votre modèle C4 de lui-même. Tout ce qui est découvert constitue une proposition que vous approuvez.

Comment ça marche

Reality maintient trois plans bien distincts :

  • Model (le modèle) — votre architecture C4 organisée (l'intention). Vous seul la modifiez.
  • Reality (la réalité) — un miroir continuellement rafraîchi de ce qui est observé en production (les faits).
  • Binding (la liaison) — le lien entre les deux, que vous confirmez.

Les scanners n'écrivent jamais que dans les plans Reality et Binding. Promouvoir une ressource découverte dans votre modèle est toujours un clic explicite.

Étape 1 — Connecter une source dans votre organisation

Les identifiants vivent dans le marketplace de votre organisation : vous configurez donc chaque source une seule fois et n'importe quel projet peut l'utiliser.

Rendez-vous dans Organization → Marketplace et connectez l'une des sources suivantes :

Kubernetes

Une connexion en lecture seule à l'API de votre cluster.

  • API Server URL — p. ex. https://10.0.0.1:6443
  • Read-only ServiceAccount Token — créez un ServiceAccount lié au ClusterRole intégré view, puis générez un jeton
  • Skip TLS Verification — à définir sur true uniquement pour les clusters de dev auto-signés

Archyl n'écrit jamais dans votre cluster — il n'appelle que des endpoints en lecture (describe/list).

Datadog

  • API Key et Application Key (avec accès APM en lecture)
  • Site — datadoghq.com, datadoghq.eu, us5.datadoghq.com, … (doit correspondre à la région de votre compte)

Datadog lit sa Service Map APM, y compris les dépendances externes inférées (bases de données, files d'attente, services tiers).

New Relic

  • User API Key (NRAK-…) — utilisée pour lire les entités et les relations
  • Account ID (optionnel)
  • Region — US ou EU (doit correspondre à votre compte)

New Relic lit les applications APM et les services OpenTelemetry ainsi que leurs relations CALLS.

Étape 2 — Ajouter la source à un projet

Ouvrez le diagramme d'un projet et cliquez sur Reality dans la barre d'outils (en haut à droite). Le panneau Reality s'ouvre sur la droite.

  1. Cliquez sur Add source (ajouter une source).
  2. Choisissez l'une de vos intégrations connectées.
  3. Ajoutez le scope (la portée) du projet — un namespace Kubernetes ou un environment Datadog/New Relic (p. ex. production). Laissez le champ vide pour tout inclure.
  4. Cliquez sur Add & scan (ajouter et scanner).

Un projet peut avoir un nombre quelconque de sources — Kubernetes et Datadog, une seule, ou plusieurs.

Étape 3 — Scanner

Chaque source se scanne indépendamment. Utilisez l'icône refresh (rafraîchir) d'une source pour la re-scanner. La découverte est idempotente : un nouveau scan met à jour ce qui existe déjà au lieu de le dupliquer, et tout ce qui a disparu de la production est signalé (jamais supprimé).

Les sources d'observabilité peuvent accuser un retard : les services apparaissent généralement en quelques minutes, mais les relationships (relations) sont calculées par analyse des traces et peuvent nécessiter 10 à 30 minutes de trafic soutenu avant de se renseigner.

Étape 4 — Réconcilier les ressources

L'onglet Resources (ressources) regroupe ce qui a été découvert :

  • Unmodeled in production (non modélisé en production) — tourne en production mais n'est pas encore sur votre diagramme. Pour chacun, vous pouvez :
    • Bind (lier) — le rattacher à un élément C4 existant suggéré.
    • Promote (promouvoir) — le transformer en un nouvel élément C4 (voir ci-dessous).
    • Ignore (ignorer) — l'écarter (réversible).
  • Drifted (dérivé) — lié à votre modèle mais dont l'état de production a divergé (p. ex. en mauvaise santé, ou disparu).
  • In your model (dans votre modèle) — correspondances confirmées entre la production et le C4.
  • Orphan (orphelin) — présent dans votre modèle mais sans contrepartie en production.

Utilisez le champ filter (filtre) pour rechercher par nom, type ou namespace.

Promouvoir un service au niveau container

La promotion crée un nouveau container C4 à partir d'un service découvert. Comme les containers vivent à l'intérieur d'un système, ouvrez d'abord le système souhaité (descendez jusqu'au niveau container). Si aucun système n'est ouvert, Promote est désactivé avec une indication. Le nouveau container apparaît dans le système que vous consultez.

Étape 5 — Réconcilier les connexions

L'onglet Connections (connexions) liste les dépendances découvertes (qui appelle qui). Une connexion est promotable dès lors que ses deux extrémités sont dans votre modèle (liées ou promues). Cliquez sur Promote pour la tracer comme une véritable relation sur votre diagramme. Les connexions promues disparaissent automatiquement de la liste des propositions.

La lentille Reality sur le diagramme

Tant que le panneau Reality est ouvert, le canvas active une surcouche en direct : les éléments C4 adossés à une ressource de production confirmée affichent un petit health dot (point de santé) (et un nombre d'instances) en haut à droite. Cela reste sans effet destructeur — c'est une surcouche, pas une modification. Les services promus s'affichent comme des nœuds normaux et nets.

Sécurité et limites

  • Read-only (lecture seule) — Reality n'écrit jamais dans vos systèmes de production et ne modifie jamais automatiquement votre modèle C4. Vous approuvez chaque changement.
  • Per-source isolation (isolation par source) — scanner une source n'affecte jamais les données d'une autre.
  • Reversible (réversible) — les liaisons peuvent être défaites, les éléments ignorés sont récupérables, et les éléments promus sont des éléments C4 normaux que vous pouvez modifier ou supprimer.
  • Trust levels (niveaux de confiance) — les relations sont étiquetées selon leur origine : observed (observée, depuis la télémétrie, le signal le plus fort) vs config-derived (dérivée de la configuration, issue de la configuration du cluster). Les sources de télémétrie (Datadog, New Relic, Kubernetes + un service mesh) fournissent le graphe de dépendances le plus complet.