Voir chaque décision, changer sans risque.

Les journaux sont en JSON structuré et ne contiennent aucune donnée personnelle en clair : les identifiants sont hachés, les invites et les corps ne sont jamais journalisés, et une clé d'API refusée est nommée par son identifiant, jamais par sa valeur. Chaque ligne est corrélée par trace_id, y compris une erreur fatale, elle aussi structurée.

Le niveau se règle dans observability.log_level (debug, info, warn, error, fatal) et se recharge à chaud. Côté appelant, chaque réponse d'erreur porte un request_id et un trace_id : le détail reste au journal, où l'exploitation le retrouve à partir de l'identifiant que le client lui transmet.

Les métriques sont indexées par opération du contrat, par amont et par tenant : débit, latence par quantile, codes de réponse, requêtes en cours, jetons. Les dimensions viennent du contrat et du jeton, rien n'est à configurer, et un tableau de bord cherche POST /orders, pas /orders/8f21c.

La cardinalité est bornée par construction : mille chemins distincts et mille tenants produisent un nombre de séries borné, ce que les tests vérifient. Les métriques sont exposées sur /metrics et exportées en OTLP ; des familles dédiées couvrent les rechargements, le cache, la délégation, l'inférence et les flux ouverts.

Le traceparent W3C est propagé, ou créé s'il manque, du bord jusqu'à l'amont et au modèle : une trace traverse la passerelle sans rupture de contexte. Chaque politique exécutée y ajoute un attribut, une dégradation y est marquée, et les appels externes de politique apparaissent en spans enfants. Sur les requêtes échantillonnées, les étapes routage, identité et politiques ont leur propre span.

L'export passe par observability.otlp_endpoint vers votre collecteur OTLP ; un point vide désactive l'export, et c'est une configuration valide. L'échantillonnage est adaptatif : observability.sampling.max_per_second plafonne les traces racines par réplique, et la décision du parent est respectée.

Le catalogue d'API se construit depuis les contrats chargés par la passerelle, jamais depuis une saisie à part : facettes, panneau latéral par opération, chaîne de politiques en miniature, trafic par opération et export. Le propriétaire d'une opération se déclare au contrat par x-flexway-owner - une équipe et un canal d'équipe, jamais une personne - et une date de retrait par x-flexway-sunset, qui exige deprecated: true.

L'onglet Conformité calcule des règles sur le catalogue, comme les opérations sans propriétaire ou dépréciées sans date ; une date de retrait posée sur une opération non dépréciée est refusée dès le chargement. Ces informations ne sont jamais lues sur le chemin de la requête.

Un portail développeur - catalogue, essai et clés pour les consommateurs de vos API - est à venir, comme une surface distincte de la console.

Le tableau de bord du trafic se lit par opération, amont et tenant, face à la période précédente, avec évolution et répartition. Le détail d'une opération montre débit, erreurs par code, latences et répartition par tenant ; deux fenêtres choisies librement peuvent être superposées sur les mêmes courbes, et chaque rechargement de configuration y laisse un repère.

Une trace de bout en bout s'ouvre depuis la console. Sans backend de traces, la console reçoit l'OTLP de la passerelle et garde par échantillonnage de queue les requêtes lentes ou en erreur dans des bornes de nombre, de durée et de taille par réplique, affichées en cascade avec la durée du routage, de l'identité, des politiques et des tentatives vers l'amont. Un journal des erreurs récentes se filtre par opération, amont et tenant.

La console fonctionne sans backend de métriques externe : elle collecte les métriques poussées par la passerelle, garde 35 jours de détail et des agrégats journaliers sur 13 mois, sur un volume persistant. Si vous avez déjà vos backends (metrics.url, traces.url), elle les lit à la place.

L'écran Amonts montre l'état des coupe-circuits, les éjections et les délais de chaque amont, avec le prochain essai prévu, les transitions et les codes écrits par la passerelle. Il se lit en cartes ou en tableau, avec une bande sur 24 h et un détail par amont.

La santé de la passerelle elle-même se lit par réplique : statut de chacune selon sa règle et la fraîcheur de son dernier rapport, réplique en drainage annoncée, et une règle qui signale une réplique devenue silencieuse. Une réplique qui s'arrête proprement se distingue ainsi d'une réplique perdue.