Le radar du port ne regarde pas dans tes conteneurs

La capitainerie voit tout ce qui bouge dans le bassin. Radars sur le chenal, journal de bord, horodatage de chaque mouvement de portique. Elle sait quel navire est entré, à quelle heure, et sur quel poste il s'est amarré.

Ce qu'elle ne sait pas, c'est que la cargaison de ton conteneur frigorifique est en train de se réchauffer. Le conteneur est posé rangée B, il tire du courant, tout va bien de son point de vue. La sonde à l'intérieur, c'est toi qui la poses, avant le départ, pas le jour où la marchandise arrive avariée.

Azure fonctionne pareil. La plateforme collecte d'office un socle de mesures sur chaque ressource et trace les opérations d'administration. Ce qui se passe à l'intérieur, journaux d'un service managé, journaux système d'une machine virtuelle, traces applicatives, n'arrive nulle part tant que personne ne l'a demandé.

Et rien ne se collecte à rebours.

Un paramètre de diagnostic activé pendant l'incident ne fait pas réapparaître les heures qui l'ont précédé. La supervision est une décision de conception, prise avant la mise en service, pas une case cochée après coup.

La plateforme de données, en une page

Azure Monitor n'est pas un produit unique. C'est une plateforme de données avec deux magasins, plusieurs chemins d'entrée et plusieurs consommateurs.

Les deux magasins ne se ressemblent pas. Une base de séries temporelles reçoit les métriques, valeurs numériques horodatées, disponibles presque tout de suite. Un ou plusieurs espaces de travail Log Analytics reçoivent les journaux, enregistrements structurés qu'on interroge en KQL.

Les chemins d'entrée sont au nombre de quatre : la plateforme elle-même, le paramètre de diagnostic, l'agent installé dans le système invité, et l'instrumentation applicative. Les trois derniers demandent une action explicite.

Les consommateurs, eux, sont ce que voient les humains : règles d'alerte, classeurs, tableaux de bord, exports vers un outil tiers.

flowchart LR A["Ressource Azure
métriques de plateforme"] --> MET["Base de métriques"] B["Journal d'activité
plan de contrôle"] --> DS["Paramètre de diagnostic"] C["Service managé
journaux de ressource"] --> DS D["Système invité
machine virtuelle"] --> AMA["Agent Azure Monitor
règle de collecte"] E["Code applicatif"] --> AI["Application Insights"] DS --> W["Espace de travail
Log Analytics"] AMA --> W AI --> W DS --> ST["Compte de stockage"] DS --> EH["Event Hubs
outil tiers"] MET --> AL["Règles d'alerte"] W --> AL W --> VIS["Classeurs et tableaux de bord"] MET --> VIS AL --> AG["Groupes d'action"] classDef auto fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef manuel fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef dest fill:#2c3338,stroke:#1f2428,color:#f5f2ec; class A,B auto; class C,D,E,DS,AMA,AI manuel; class MET,W,ST,EH,AL,AG,VIS dest;

Les blocs en cuivre clair sont ceux que personne ne branche par défaut. Ce sont aussi ceux qui manquent le jour de l'enquête.

Retiens la ligne de partage : la plateforme mesure ses propres ressources, tu es responsable de tout ce qui se passe dedans. C'est le modèle de responsabilité partagée appliqué à l'observabilité.

Métriques ou journaux, et pourquoi ça change tout

Sur le quai, la balance du portique donne un tonnage toutes les secondes. Le registre du chef d'escale, lui, raconte qui a signé quoi et pourquoi le chargement a pris quarante minutes de retard. Ce ne sont pas les mêmes objets, et on ne leur pose pas les mêmes questions.

Critère Métriques Journaux
Nature Séries numériques horodatées, dimensions limitées Enregistrements structurés, champs libres
Fraîcheur Quasi temps réel Quelques minutes d'ingestion
Rétention Fixe, de l'ordre de quelques mois Réglable, jusqu'à plusieurs années
Coût Inclus pour les métriques de plateforme Facturé à l'ingestion et à la conservation
Interrogation Agrégats, graphiques, seuils KQL complet, jointures, corrélation
Bon pour Détecter vite, déclencher une mise à l'échelle Comprendre, auditer, remonter à la cause
Mauvais pour Expliquer pourquoi Alerter à la seconde

La conséquence pratique tient en une phrase : on alerte sur des métriques quand on veut de la vitesse, on alerte sur des journaux quand la condition ne peut pas s'exprimer en une seule courbe.

Une métrique de plateforme reste disponible quelques mois sans configuration ni facture d'ingestion. Si tu veux la garder au-delà, ou la croiser avec des journaux dans une même requête, il faut l'exporter vers un espace de travail, et là elle devient une donnée de journal comme les autres, avec le coût associé.

Les métriques répondent à « est-ce que ça va mal ». Les journaux répondent à « pourquoi ». Une supervision qui n'a que les premières sonne juste et n'explique rien.

D'où vient la donnée, et ce qu'il faut brancher

Le port fournit le radar. Les sondes dans les conteneurs, les compteurs sur les groupes froids et le registre de ton propre entrepôt, c'est ton affaire, et ça se pose lot par lot.

Source Collectée par défaut Ce qu'il faut faire Où ça atterrit
Métriques de plateforme Oui Rien Base de métriques
Journal d'activité Oui, rétention courte Un paramètre de diagnostic pour le conserver et le croiser Espace de travail, stockage, Event Hubs
Journaux de ressource Non Un paramètre de diagnostic par ressource Espace de travail, stockage, Event Hubs
Compteurs et journaux du système invité Non Agent Azure Monitor et règle de collecte Espace de travail
Requêtes, dépendances, exceptions applicatives Non Application Insights, instrumentation automatique ou bibliothèque Espace de travail
Métriques Prometheus d'un cluster Non Collecte managée vers un espace de travail Azure Monitor Espace de travail Azure Monitor

Le journal d'activité enregistre le plan de contrôle : qui a créé, modifié ou supprimé quoi, avec quelle identité et quel résultat. Il est conservé quatre-vingt-dix jours et consultable tel quel. Pour le garder plus longtemps, écrire des requêtes dessus ou l'utiliser dans une alerte fine, il faut l'exporter.

Les journaux de ressource décrivent l'intérieur du service : requêtes reçues par une passerelle, accès à un coffre de secrets, exécutions d'une base. Sans paramètre de diagnostic, ils n'existent pas.

az monitor diagnostic-settings create \
  --name vers-log-analytics \
  --resource "$RESOURCE_ID" \
  --workspace "$WORKSPACE_ID" \
  --logs '[{"categoryGroup":"allLogs","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

Une commande par ressource, c'est tenable pour une démonstration et intenable pour un parc. La bonne réponse est celle de la gouvernance : une stratégie Azure Policy avec l'effet DeployIfNotExists, portée au groupe d'administration, qui crée le paramètre manquant sur toute ressource nouvelle. Le règlement portuaire s'applique à tous les quais, y compris ceux ouverts la semaine prochaine.

Le système invité est le cas le plus souvent oublié. Une machine virtuelle expose ses métriques de plateforme (processeur, disque, réseau) sans rien faire, mais la mémoire disponible, le journal des événements Windows, le syslog Linux ou un fichier applicatif demandent l'agent Azure Monitor et une règle de collecte de données. La règle dit ce qu'on ramasse et vers quelle destination, et elle s'associe à un ensemble de machines, ce qui la rend gouvernable. L'ancien agent Log Analytics a été retiré, ce chemin est désormais le seul.

Application Insights couvre le dernier étage : requêtes entrantes, dépendances sortantes, exceptions, traces distribuées. Instrumentation automatique pour les plateformes applicatives managées, bibliothèque ou distribution OpenTelemetry pour le reste. Les ressources sont aujourd'hui adossées à un espace de travail, ce qui permet d'écrire une requête qui traverse le code et l'infrastructure sans changer d'outil.

La règle qui fâche, et qu'on répète parce qu'elle coûte cher : sans paramètre de diagnostic, il n'y a pas de journal. Pas de journal partiel, pas de journal dégradé. Rien.

Concevoir l'espace de travail

Le nombre de registres tenus au port n'est pas un détail administratif. Un registre unique se consulte d'un coup mais mélange les concessionnaires. Un registre par terminal cloisonne bien et oblige à courir de bureau en bureau quand une enquête traverse le port.

C'est la décision structurante de tout le sujet, et la plus pénible à défaire, parce que la donnée déjà ingérée ne se déplace pas.

Décision Un seul espace Plusieurs espaces Ce qui tranche
Corrélation Tout est joignable dans une requête Requêtes inter-espaces, plus lourdes et bornées Fréquence des enquêtes transverses
Souveraineté Une seule région de stockage Un espace par région contrainte Obligation légale sur le lieu de conservation
Cloisonnement RBAC par ressource et par table Séparation nette entre entités Exigence d'isolement entre filiales ou clients
Coût Volume agrégé, paliers d'engagement atteints plus tôt Volumes dispersés, remises moins accessibles Volume total ingéré par jour
Rétention Réglage fin table par table Réglage global plus simple à tenir Hétérogénéité des durées exigées
Exploitation Un objet à gouverner Autant d'objets à maintenir Taille de l'équipe

La documentation de conception pousse au regroupement, et c'est le bon réflexe par défaut. On ne multiplie les espaces que sur une contrainte réelle : la région imposée, la séparation juridique, ou une exigence de rétention irréconciliable.

Le contrôle d'accès évite le faux dilemme. En mode contexte de ressource, une personne qui a le droit de lire une ressource lit les journaux de cette ressource, sans droit sur l'espace entier. On ajoute au besoin un contrôle au niveau de la table, pour les données sensibles. Cloisonner ne veut donc pas dire multiplier les espaces.

La rétention se pilote à deux étages. La rétention interactive garde la donnée immédiatement interrogeable, et elle est courte par défaut. Au-delà, la donnée bascule en conservation longue durée, nettement moins chère, où elle n'est plus directement requêtable : il faut lancer une tâche de recherche ou restaurer une plage pour la relire. Ce détail décide de ta capacité à répondre à un audit six mois plus tard.

Les plans de table sont le levier de coût le plus efficace, et le moins connu.

Plan Ce qu'on y met Ce qu'on y perd
Analytics Ce sur quoi on enquête et on alerte Rien, c'est le plan complet
De base Journaux volumineux consultés ponctuellement Requêtes limitées, pas de règle d'alerte
Auxiliaire Journaux verbeux gardés pour la conformité Capacités d'interrogation encore réduites

L'erreur classique consiste à tout ingérer en plan complet, puis à découvrir la facture, puis à couper la collecte au hasard. La bonne séquence est inverse : classer les tables par usage réel, puis choisir le plan.

La facture d'ingestion et de rétention pèse vite, et elle se joue au moment où l'on décide quoi collecter. Le raisonnement complet est dans le billet consacré à la maîtrise du coût, lié plus bas.

Le nombre d'espaces de travail est une décision d'architecture, pas d'exploitation. Regroupe par défaut, sépare sur contrainte prouvée, et règle l'accès par le RBAC plutôt que par la multiplication des magasins.

Interroger : KQL, trois requêtes qui servent

Un registre ne vaut que par la vitesse à laquelle on y retrouve une ligne. KQL est un langage de lecture : on part d'une table, on filtre, on agrège, on projette, dans cet ordre.

Qui a supprimé quoi cette semaine, la première question posée après tout incident inexpliqué.

AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue has "DELETE"
| where ActivityStatusValue == "Success"
| project TimeGenerated, Caller, CallerIpAddress, ResourceGroup, OperationNameValue
| order by TimeGenerated desc

Quelles requêtes applicatives se dégradent, avec le taux d'échec et le centile 95, par point d'entrée.

AppRequests
| where TimeGenerated > ago(1h)
| summarize total = count(),
            echecs = countif(Success == false),
            p95 = percentile(DurationMs, 95)
          by Name
| where total > 100
| extend taux_echec = round(100.0 * echecs / total, 2)
| order by p95 desc

Quelles machines ont cessé de donner signe de vie, sachant que l'absence de donnée est une information et qu'elle ne déclenche aucun seuil.

Heartbeat
| where TimeGenerated > ago(24h)
| summarize dernier_signal = max(TimeGenerated) by Computer
| where dernier_signal < ago(15m)
| order by dernier_signal asc

Cette troisième requête mérite qu'on s'y arrête. Une règle qui surveille « processeur au-dessus de 90 % » ne se déclenche jamais sur une machine éteinte, puisqu'elle n'envoie plus rien. Détecter le silence demande une règle écrite exprès.

Deux réflexes d'écriture réduisent la facture et le temps de réponse : filtrer sur TimeGenerated en tout premier, et nommer les tables plutôt que de lancer une recherche en texte libre sur l'espace entier.

Une requête qu'on écrit pendant l'incident est une requête qu'on écrit mal. Les enquêtes fréquentes se rangent en requêtes enregistrées et en classeurs, avant d'en avoir besoin.

Alerter : la seule question qui compte

Le port ne fait pas sonner la sirène parce qu'une grue a ralenti. Il la fait sonner quand quelqu'un doit se lever et faire quelque chose maintenant. Une sirène qui hurle six fois par jour finit derrière une porte fermée, et le jour où elle a raison, personne ne l'entend.

Une règle d'alerte se compose toujours des mêmes pièces : un signal, une condition avec sa fenêtre d'évaluation, une gravité de 0 à 4, et un groupe d'action qui définit qui reçoit quoi et par quel canal.

Ce qu'on veut détecter Type de règle Signal Limite
Un seuil franchi sur une ressource Alerte de métrique Métrique de plateforme ou personnalisée Ne voit que ce qui est déjà une métrique
Un taux d'erreur applicatif Alerte de recherche dans les journaux Requête KQL planifiée Latence d'ingestion, coût par exécution
Une suppression ou un changement de droits Alerte de journal d'activité Opération du plan de contrôle Ne dit rien de l'état interne
Un incident déclaré par le fournisseur Alerte d'intégrité du service Service Health Dépend de la publication par Azure
Une ressource déclarée dégradée Alerte d'intégrité de ressource Resource Health Vue plateforme, pas vue métier
Un comportement anormal dans un cluster Règle d'alerte Prometheus Métriques Prometheus managées Réservé aux charges instrumentées ainsi

Seuil statique ou dynamique. Le seuil fixe convient quand la valeur cible est connue et stable, comme un espace disque restant. Le seuil dynamique s'appuie sur l'historique de la métrique pour apprendre son rythme, et convient au trafic, qui n'a pas la même tête un mardi midi et un dimanche à trois heures. En contrepartie, il lui faut de l'historique et une saisonnalité lisible.

Le cycle de vie. Une alerte de métrique se résout d'elle-même quand la condition redevient normale. Une alerte de journal peut le faire aussi, à condition de l'avoir configurée ainsi. Sans quoi la console se remplit d'alertes actives qui décrivent des problèmes réglés depuis trois semaines.

sequenceDiagram participant RES as Ressource participant MON as Azure Monitor participant REG as Règle participant ACT as Groupe action participant OPS as Astreinte RES->>MON: métriques et journaux MON->>REG: évaluation périodique REG->>REG: condition franchie sur la fenêtre REG->>ACT: alerte déclenchée en gravité 1 ACT->>OPS: notification et ticket Note over ACT: une règle de traitement peut la taire en maintenance OPS->>RES: correction RES->>MON: valeur revenue sous le seuil MON->>REG: nouvelle évaluation REG->>ACT: alerte résolue

Les règles de traitement des alertes méritent d'être connues : elles suppriment les notifications pendant une fenêtre de maintenance planifiée, ou appliquent un groupe d'action à un périmètre entier sans le recopier dans chaque règle.

Reste la question qui décide de tout, et elle n'est pas technique. Pour chaque règle : qui est réveillé, que doit-il faire dans les cinq minutes, et que se passe-t-il s'il ne fait rien. Sans réponse aux trois, la règle produit du bruit. Une alerte qui n'appelle aucune action se transforme en tableau de bord.

Alerte sur ce que l'utilisateur ressent, pas sur chaque compteur. Une poignée de règles liées au service rendu vaut mieux que trois cents règles de ressource dont plus personne ne connaît l'auteur.

Restituer : classeurs, tableaux de bord, Defender

Le journal de bord sert aux enquêtes. Le tableau de la capitainerie, lui, doit se lire en trois secondes depuis l'autre bout de la salle. Ce sont deux objets différents.

Les classeurs combinent texte, requêtes, métriques et paramètres dans un document interactif. C'est l'outil de l'enquête outillée et du rapport récurrent : on y range les requêtes qu'on écrit toujours pendant les incidents, avec un sélecteur d'abonnement et de période.

Les tableaux de bord répondent à un autre besoin, l'affichage permanent et partagé. Azure propose ses tableaux natifs, et une offre Grafana managée pour les équipes qui vivent déjà dedans, avec l'avantage de mélanger des sources qui ne sont pas toutes Azure.

Defender for Cloud occupe une place à part et se confond souvent avec la supervision. Il évalue la posture de sécurité des ressources, produit un score et des recommandations, et active des plans de protection par type de ressource. Ses alertes de sécurité rejoignent la même console d'alertes, et l'ensemble alimente un SIEM quand l'organisation en exploite un. Supervision et sécurité partagent la plomberie, elles ne répondent pas aux mêmes questions.

Un classeur sert à chercher, un tableau de bord sert à montrer. Confondre les deux produit des écrans muraux illisibles et des enquêtes menées à la souris.

Scénario B : Slack, le lundi de la rentrée

Le 4 janvier 2021, premier lundi travaillé après les fêtes, Slack devient inutilisable pour une large partie de ses utilisateurs. L'entreprise a publié un compte rendu d'ingénierie détaillé, Slack's Outage on January 4th 2021, signé Laura Nolan.

Le contexte est celui d'une reprise d'activité. Après deux semaines de trafic très bas, l'usage remonte brutalement en début de matinée. Le compte rendu décrit d'abord un problème de réseau : de la perte de paquets sur l'infrastructure du fournisseur de cloud, liée au comportement de mise à l'échelle des passerelles de transit, qui s'étaient ajustées à la baisse pendant la période creuse et n'ont pas suivi la remontée.

La suite est un enchaînement, pas une cause unique. La dégradation réseau fait échouer des contrôles d'intégrité, des serveurs pourtant sains sont retirés du service, et le mécanisme chargé de provisionner de la capacité supplémentaire se retrouve lui-même saturé. Le système qui devait résoudre le problème faisait partie du problème.

Le point qui nous intéresse ici est ailleurs. Le compte rendu raconte ce que les équipes voyaient et ne voyaient pas pendant l'incident : les tableaux de bord se dégradent au moment précis où ils sont nécessaires, les signaux arrivent en désordre, et distinguer la cause des effets prend un temps considérable alors que tout sonne en même temps.

C'est le cas rare d'un post-mortem public qui traite de l'observabilité pendant la crise, et pas seulement de la reconstitution après coup. Trois leçons se transposent directement sur Azure.

La première : ton outillage d'observation ne doit pas dépendre de ce qu'il observe. Un tableau de bord hébergé derrière le service en panne s'éteint avec lui.

La deuxième : la période creuse est un piège. Les seuils calibrés sur un trafic bas déclenchent en rafale à la reprise, et les mécanismes élastiques mettent du temps à revenir à l'échelle. Les seuils dynamiques aident, à condition d'avoir vu passer plusieurs cycles.

La troisième : une alerte par symptôme métier vaut cinquante alertes par composant. Quand tout tombe en même temps, la seule information utile est celle qui dit ce que les utilisateurs ne peuvent plus faire.

Le moment où la supervision compte le plus est aussi celui où elle est la plus fragile. Conçois-la en te demandant ce qui reste debout quand le reste ne l'est plus.

Points clés

  • La plateforme collecte les métriques de ses ressources et le plan de contrôle. Journaux de ressource, système invité et traces applicatives demandent une action explicite, et rien ne se collecte rétroactivement.
  • Le paramètre de diagnostic se déploie par stratégie avec l'effet DeployIfNotExists, pas ressource par ressource à la main.
  • Le nombre d'espaces de travail est une décision d'architecture. Regroupe par défaut, sépare sur contrainte de souveraineté ou d'isolement, et cloisonne l'accès par le RBAC en contexte de ressource.
  • Les plans de table et la rétention à deux étages sont les vrais leviers de coût. On classe les tables par usage avant de choisir, pas après la facture.
  • Une règle d'alerte sans réponse à « qui fait quoi dans les cinq minutes » est un tableau de bord déguisé en sirène.

Dans la série

Palier 1 : Ouvrir le port. Domaine : Supervision.

Pour aller plus loin