Slow and periodic feedback kills

Les notes ci-dessous sont tirées du DevOps Handbook, dont j’avais déjà parlé il y a quelques temps, et touchent principalement à l’agrégation des journaux et des métriques.

In short, slow and periodic feedback kills.
– The Principles of Flow

La récupération de métriques augmente la confiance que l’on peut avoir dans la solution. L’analyse de ces métriques garantit un juste retour d’informations, sous réserve qu’elles soient exploitées correctement. Ceci peut être réalisé en deux étapes:

• La première étape consiste à agréger ces données dans un dépôt centralisé,
• La seconde étape exigera une structuration correcte des données envoyées.

Collecte des données

La collecte des données doit récupérer des données des couches métiers, applicatives et d’environnement. Ces données couvrent les évènements, les journaux et les métriques - indépendamment de leur source - le pourcentage d’utilisation du processeur, la mémoire utilisée, les disques systèmes, l’utilisation du réseau, …

• Métier : Le nombre de ventes réalisées, le nombre de nouveaux utilisateurs, les résultats de tests A/B, …
• Application : Le délai de réalisation d’une transaction, le temps de réponse par utilisateur, …
• Infrastructure : Le trafic du serveur Web, le taux d’occupation du CPU, …

Côté client, il convient de récupérer les erreurs applicatives, les transactions que l’utilisateur effectue, …

Au niveau du développement, on est parti pour agréger les informations liées aux pipelines de déploiement: statuts des builds, temps de mise à disposition d’une fonctionnalité, fréquence des déploiements, statuts des environnements, …

Outil d’agrégation

Le choix de l’outil d’agrégation doit permettre de collecter, enregistrer, visualiser, alerter, détecter des anomalies et appliquer des transformations statistiques. Par exemple : Nagios, Zabbix, LogStash, Datadog ou Riemann. Il faut aussi voir aussi du côté de StatsD, Grafana et Graphite.

As Adrian Cockcroft pointed out, “Monitoring is so important that our monitoring systems need to be more available and scalable than the systems being monitored.

– Part IV - The Technical Practice of Feedback - Create Telemetry to enable seeing and solving problems (page 200)

Par exemple, si un serveur Nginx arrête de répondre aux requêtes, il serait possible de corréler cet incident avec d’autres métriques : augmentation du temps de réponse (Application), mémoire disponible en baisse sur le serveur (Infrastructure) ou temps nécessaire à la réalisation d’une transaction sur la base de données.

Histoire de schématiser, toute équipe se retrouve à un moment où un autre dans la situation suivante : personne ne veut appuyer sur le gros bouton rouge issu de l’automatisation de la chaîne de production et qui dit “Déploiement” (en clignotant). Et pour cause : une fois que nous aurons trouvé une joyeuse victime qui osera braver le danger, il y aura systématiquement des imprévus, des petits détails qui auront été oubliés sur le côté de la route, et qui feront lâchement planter les environnements. Et puisque nous n’aurons pas (encore) de télémétrie, le seul moment où nous comprendrons qu’il y a un problème, sera quand un utilisateur viendra se plaindre.

D’où l’intérêt d’avoir une source de données mettant à disposition une agrégation de données de télémétrie.

Métriques, monitoring & alerting

Les métriques, le monitoring et l’alerting sont trois concepts interconnectés qui forment ensemble la base d’un système de monitoring. Ils fournissent un aperçu sur la santé des systèmes et permettent de comprendre :

• Les tendances d’usage et de comportement
• L’impact sur les changements effectués.
• Si une métrique tombe en dehors des valeurs de seuils normales, le système peut transmettre une notification pour accélérer la prise en charge par un opérateur.

Pour résumé, les métriques sont des données brutes, non-interprétées et non traitées, tandis que le monitoring consiste à ajouter une couche d’informations sur ces métriques.

Métriques

Les métriques représentent les mesures brutes pouvant être observées et collectées. Ces mesures peuvent être des ressources de bas-niveau (RAM, CPU, espace de stockage, utilisation de l’espace de swap, …) ou plus haut-niveau (unité de travail, fonctionnalités spécifiques, nombre de requêtes services par seconde, …).

Monitoring

Les métriques représentent les données de nos systèmes ; le monitoring consiste à collecter, agréger, visualiser et analyser ces valeurs récupérées, en vue d’améliorer la compréhension de nos composants, ainsi que leurs caractéristiques, puis d’initier l’envoi automatique d’informations lorsque certaines valeurs atteignent des seuils spécifiques.

La différence entre les métriques et le monitoring revient à différencier les données des informations.

Le système de monitoring doit permettre :

• De récolter des données à partir de plusieur sources,
• D’ajouter des paramètres de visualisation, afin que les administrateurs puissent reconnaître des motifs particuliers

Dans le cas d’un système de type push, la récolte a besoin d’autant d’agents installés sur chacune des ressources à surveiller. Idéalement, l’installation d’un agent doit se passer sans douleur et être la plus simple possible. Comme les évènements se passent en continu, le système de réception doit être le plus robuste possible : il doit être capable de supporter la charge de toutes les données que chacune des ressources envoie vers lui.

Dans le cas d’un système pull, le serveur doit pouvoir contacter chaque ressource et récupérer les mêmes métriques que s’il s’agissait d’un agent indépendant. Certaines responsabilités d’agrégation sont inversées, mais un certain niveau de complexité subsiste, surtout sur certaines ressources nécessitent des mécanismes d’authentification.

Alerting

L’objectif premier de l’alerting est d’amener l’attention d’un opérateur sur le statut d’un des systèmes.

L’alerting consiste à interpréter des changements dans les métriques. Une alerte est composée de deux éléments :

• La définition d’un seuil ou d’une condition,
• Une action à réaliser lorsque la valeur d’une métrique tombe en dehors de valeurs acceptables (= ne répondant pas aux conditions définies et/ou valeurs de seuils).

Informations à tracer

Les informations que l’on collectera suivront les évolutions de notre infrastructure. Pour schématiser, on peut placer des métriques à plusieurs niveaux :

• Hôte: est-ce que la machine qui héberge les services a tout le confort dont elle a besoin ?
• Application : est-ce que l’application tourne correctement ?
• Couche réseau : est-ce que tous les paquets passent bien ?
• Pool de serveurs (en cas de mise à l’échelle horizontale) : est-ce qu’une nouvelle instance peut être démarrée sans embarquer toute la ferme ?
• Dépendances : est-ce que tous les services (internes ou externes) dont dépendent nos applications tournent correctement ?
• Expérience utilisateur : est-ce que nos utilisateurs ont toute la réactivité dont ils peuvent avoir besoin ?

Dans le livre Google SRE (Site Reliability Engineering), il est question des four golden signals of monitoring :

• La latence, qui consiste à mesurer le temps que met un service à répondre à une interrogation
• Le trafic, qui s’assure du taux d’occupation du service, et qui capture la charge ou la demande du service, ce qui permet de savoir ce sur quoi il est occupé (ou ce qui prend du temps à être traité).
• Le nombre d’erreurs (d’où l’importance de catégoriser correctement les alertes
• La saturation, qui mesure combien une ressource est utilisée - cette mesure dépend généralement de la latence et du trafic, puisqu’une augmentation de ces deux valeurs tend à augmenter la saturation de la ressource.

Métrique du système hôte

• Charge CPU
• Mémoire : utilisation du swap, nombre d’évènements de type OOM killer
• Espace disque et réactivité des espaces de stockage
• Nombre de processus

Métriques applicatives

Il s’agit de métriques associées litérallement au bon fonctionnement de l’application :

• Temps nécessaire à compléter les requêtes
• Nombre de requêtes par seconde
• Défaillances applicatives ou redémarrages des services
• Utilisation des ressources disponibiles
• Métriques de connectivité

Pour la plupart des infrastructures, la connectivité réseau est un ensemble de données à explorer : il s’agit de jauges quant à la disponibilité des services, permettant également de s’assurer que les systèmes restent accessibles. Le réseau doit être vérifié pour assurer les performances requises :

Connectivité

• Taux d’erreur et/ou de pertes de paquets
• Latence
• Utilisation de la bande passante

Ceci autant pour les services internes qu’externes.

Pool/collections de serveurs

(Ce point concerne surtout la mise à l’échelle horizontale d’un parc de serveurs). Pour résumer, il s’agit de l’utilisation du parc de ressources, des indicateurs d’ajustements et du nombre d’instances dégradées.

Dépendances externes

L’idée ici est simplement d’utiliser les endpoints d’API pouvant être disponibles (statuts d’un service et disponibilité, etc.).

Expérience utilisateur

Ici, on est surtout sur la réactivité d’une interface, et donc sur la couche la plus élevée/proche de l’utilisateur.

Conclusions

J’avoue être encore un peu perdu sur le ou les outils à déployer pour arriver à un tel résultat. Sentry + Zabbix devraient former un bon duo, mais je ne suis pas sûr qu’ils arrivent à un résultat aussi complet que toute la documentation que j’ai pu trouver ci-dessus.