Observabilité

L’observabilité est ce qui permet de surveiller le parc d’API. Tout le trafic passe par la gateway, donc c’est là, et nulle part ailleurs, qu’on voit d’un seul endroit une attaque en cours, un service qui se dégrade, un partenaire qui s’est mis à appeler dix fois plus depuis ce matin.

D’où le test qui juge cette couche, et il est sévère : quand un service va mal, d’où part l’alerte ? Si la plateforme prévient, la couche fait son travail. Si c’est l’équipe du service qui découvre la panne par sa propre supervision, et qui l’apprend à l’équipe plateforme, l’observabilité de la plateforme est défaillante. Elle a vu passer les mêmes erreurs et les mêmes latences, elle n’en a rien fait.

Pendant un incident, ensuite, une seule question compte : la dégradation vient-elle de la gateway, du backend, du fournisseur d’identité, du réseau, ou d’un consommateur particulier ? Une plateforme est observable quand cette question trouve sa réponse en quelques minutes, avec les données déjà en place. Des tableaux de bord de volumétrie montrent qu’un problème existe, ils ne le localisent pas.

Trois signaux, un manque récurrent

Les métriques, agrégées et peu coûteuses, servent les tendances et les alertes. Les journaux, détaillés, servent l’analyse d’un cas précis, à condition d’être structurés. Les traces suivent une requête à travers les composants avec le temps passé dans chacun : ce sont elles qui localisent, et ce sont elles qui manquent le plus souvent.

Sans trace distribuée, la localisation se fait en corrélant à la main des horodatages entre plusieurs outils, en pleine pression d’incident. Toutes les gateways récentes savent produire ces traces, et l’absence de traçage est un choix par omission, plus un obstacle technique.

Le format, en revanche, se vérifie produit par produit. OpenTelemetry s’est imposé chez les gateways open source et natives du cloud, alors que les trois grandes offres de cloud public restent sur leur télémétrie propriétaire : Application Insights chez Azure, X-Ray chez AWS, Cloud Trace chez Google. La question à poser à l’éditeur n’est donc pas « savez-vous tracer » mais « vers quel collecteur, dans quel format, et à quel coût de sortie ».

Quatre dimensions à la gateway

Chaque appel doit être enregistré avec au minimum :

• le consommateur, au sens de l’identité applicative, client OAuth2 ou clé d’API, jamais la seule adresse IP : sans lui, impossible d’attribuer une dégradation.
• la route en gabarit, /clients/{id} et non l’URL concrète, sous peine d’exploser le nombre de séries de mesure.
• le code de retour, en séparant les familles : une hausse de 401 est un problème d’authentification, une hausse de 429 un consommateur au-delà de son quota, une hausse de 502 un backend en difficulté.
• la latence décomposée : temps total, temps backend, temps propre à la gateway. La décomposition permet d’attribuer, le total permet seulement de constater.

L’identifiant de corrélation

Chaque requête entrante porte un identifiant unique, propagé à tous les composants et présent dans tous les journaux. La gateway le génère quand il manque et le conserve quand il est fourni, ce qui permet à un partenaire de retrouver son appel avec son propre identifiant. Il est renvoyé au consommateur dans un en-tête de réponse : un signalement de support qui le contient se traite en quelques secondes de recherche.

Le point de vigilance est la traversée de l’asynchrone : files de messages, traitements différés. C’est là que l’identifiant se perd, et c’est souvent là que se cachent les minutes manquantes d’une latence.

Journaliser sans fuiter

Le filtrage doit exister avant le premier incident, parce que le réflexe en incident est d’augmenter la verbosité, précisément le moment où une fuite se produit. Ne jamais consigner :

• le jeton d’accès : consigner son sujet, son émetteur et son identifiant jti quand il est présent, à défaut une empreinte du jeton, jamais sa valeur, qui est un identifiant utilisable.
• les en-têtes d’autorisation, y compris dans les traces de débogage.
• les corps contenant des données personnelles, sauf filtrage explicite, rétention courte et accès restreint. La troncature ne met pas mécaniquement hors du périmètre : ce qui compte est la possibilité de réidentifier avec les autres données à disposition, pas la nature du champ.

Les indicateurs qui servent

La moyenne de latence est l’indicateur le plus trompeur du domaine : 120 ms de moyenne peuvent contenir un pour cent d’appels à huit secondes, et ce sont eux qui remontent au support.

La sonde qui voit ce que l’interne ne voit pas

L’instrumentation décrite plus haut est interne. Elle ignore ce que vit réellement le consommateur : résolution DNS, établissement TLS, réseau intermédiaire. Une surveillance synthétique, un appel réel exécuté de l’extérieur à intervalle régulier avec un vrai jeton, détecte les pannes invisibles de l’intérieur : certificat expiré, entrée DNS erronée, règle de pare-feu. Elle échoue en même temps que les clients, ce qui en fait la première alerte utile.