Supervision

Ce que couvre cette catégorie

Savoir que quelque chose est cassé avant qu’un client ne vous l’explique : contrôles de disponibilité, suivi des erreurs, métriques, journaux, traces et les alertes qui réveillent quelqu’un.

Les produits vont d’un simple contrôle qui interroge une URL aux plateformes qui ingèrent tout ce qu’émet une infrastructure. L’écart entre les deux tient surtout au volume de données et au prix.

L’analyse du comportement des clients relève de l’analytique. L’endroit où l’application tourne, c’est l’hébergement et cloud.

Commencer par l’extérieur

Le premier achat le plus utile est le plus simple : un contrôle qui charge votre site depuis plusieurs endroits et vous prévient quand il cesse de fonctionner.

Les contrôles externes attrapent les pannes que les tableaux de bord internes manquent, dont les certificats expirés, les enregistrements DNS cassés et une modification de pare-feu que personne n’a annoncée. Ils sont bon marché, et pour beaucoup de petites équipes ils couvrent l’essentiel.

Le suivi des erreurs vient en second. Savoir quelles exceptions atteignent de vrais utilisateurs, à quelle fréquence et depuis quelle version transforme un signalement vague en correctif. La qualité du regroupement distingue les produits ici, car un outil qui produit quatre mille alertes quasi identiques produit du bruit.

Les quatre sortes de données

• Contrôles de disponibilité, depuis l’extérieur, sur les parcours que les clients empruntent réellement.
• Erreurs, regroupées, avec la version et le contexte utilisateur joints.
• Métriques, numériques et peu coûteuses à conserver, pour les tendances et les seuils.
• Journaux, détaillés et chers, pour reconstituer ce qui s’est passé.
• Traces, qui suivent une requête à travers les services, pour trouver où le temps passe.

La plupart des équipes ont besoin des deux premiers tout de suite, des métriques peu après, et du reste quand un système est assez complexe pour que deviner ne marche plus.

La rétention est la contrainte discrète. Comparer aujourd’hui avec le même jour du mois dernier demande un mois de données, et les formules d’entrée en gardent souvent une semaine.

L’alerte est un problème de conception

Une alerte à laquelle personne ne donne suite habitue tout le monde à ignorer la suivante, et cette habitude est ce qui allonge les pannes.

Alertez sur ce que vivent les utilisateurs plutôt que sur chaque seuil interne. Une page qui charge lentement compte. Un processeur à quatre-vingts pour cent, seul, ne compte généralement pas.

Chaque alerte a besoin de trois choses : un responsable, une action documentée et un canal qui atteint le responsable quand il dort. Tout ce qui échoue à ce test devrait être une ligne de tableau de bord, pas une notification.

Faites ensuite une revue régulière. Les alertes s’accumulent, les conditions changent, et un élagage trimestriel est le travail de fiabilité le moins cher qui soit.

Coût, et pourquoi les factures grossissent sans prévenir

La tarification se fait par hôte, par utilisateur, par volume ingéré ou par événement, et le modèle au volume est celui qui réserve les surprises.

Un seul service qui journalise de façon verbeuse peut multiplier la facture alors que votre trafic reste plat. L’échantillonnage, le filtrage à la source et une rétention plus courte pour les données détaillées sont les leviers habituels, alors demandez ce que le produit propose avant d’en avoir besoin.

Les métriques personnalisées méritent une question précise, car elles sont souvent facturées par série unique et une étiquette mal choisie peut en créer des milliers. Demandez un plafond de dépense plutôt qu’une alerte, et consultez ce que cachent les pages de tarifs pour le reste du schéma.

L’exploiter soi-même

Les implémentations ouvertes sont capables et gratuites à licencier. Le coût d’exploitation est réel : stockage, rétention, mises à jour et quelqu’un d’astreinte pour le système de supervision lui-même.

Ce dernier point est celui à peser. Une pile auto-hébergée tend à tomber dans le même incident que ce qu’elle surveillait, c’est-à-dire exactement quand vous en avez le plus besoin.

Commencer petit sans se piéger

Une première installation de supervision devrait être ennuyeuse et terminée en un après-midi.

Deux contrôles externes sur les parcours qui comptent, le suivi des erreurs branché dans l’application, et un canal d’alerte qui atteint une personne. Cela couvre la majorité des incidents qu’un petit produit aura durant sa première année.

Ajoutez des métriques quand vous commencez à vous demander pourquoi quelque chose était lent plutôt que s’il était cassé. Ajoutez des traces quand le système a assez de pièces mobiles pour que la réponse ne soit plus évidente à la lecture d’un journal.

La seule décision qui mérite d’être prise tôt est l’endroit où les données sont collectées et leur format. Une instrumentation écrite selon un standard ouvert peut être redirigée plus tard vers un autre backend, tandis qu’une instrumentation écrite contre la bibliothèque d’un seul éditeur devient un argument contre tout changement.

Gardez une trace écrite de ce que signifie chaque alerte et de qui répond. Cette page vaut plus à trois heures du matin que n’importe quel tableau de bord.