Je m'appelle Anton Baderin. Je travaille au Centre de Haute Technologie et je fais de l'administration système. Il y a un mois, notre conférence d'entreprise s'est terminée, où nous avons partagé notre expérience accumulée avec la communauté informatique de notre ville. J'ai parlé de surveillance des applications Web. Le matériel était destiné aux niveaux junior ou intermédiaire, qui n'avaient pas construit ce processus à partir de zéro.
La pierre angulaire de tout système de surveillance est la résolution des problèmes commerciaux. Surveiller pour le plaisir de surveiller n’intéresse personne. Que veulent les entreprises ? Pour que tout fonctionne rapidement et sans erreurs. Les entreprises veulent être proactives, afin que nous puissions identifier nous-mêmes les problèmes du service et les résoudre le plus rapidement possible. Ce sont en fait les problèmes que j’ai résolus toute l’année dernière sur un projet pour l’un de nos clients.
À propos du projet
Le projet est l'un des plus grands programmes de fidélité du pays. Nous aidons les chaînes de vente au détail à augmenter la fréquence des ventes grâce à divers outils marketing tels que les cartes bonus. Au total, le projet comprend 14 applications fonctionnant sur dix serveurs.
Au cours du processus d'entretien, j'ai remarqué à plusieurs reprises que les administrateurs n'abordent pas toujours correctement la surveillance des applications Web : beaucoup se concentrent encore sur les métriques du système d'exploitation et surveillent occasionnellement les services.
Dans mon cas, le système de surveillance du client était auparavant basé sur Icinga. Cela n’a en aucun cas résolu les problèmes ci-dessus. Souvent, le client lui-même nous informait des problèmes et, le plus souvent, nous ne disposions tout simplement pas de suffisamment de données pour en découvrir la raison.
En outre, la futilité de son développement ultérieur était clairement comprise. Je pense que ceux qui connaissent Icinga me comprendront. Nous avons donc décidé de repenser complètement le système de surveillance des applications Web pour le projet.
Prométhée
Nous avons choisi Prometheus sur la base de trois indicateurs principaux :
- Un grand nombre de métriques disponibles. Dans notre cas, il y en a 60 95. Bien entendu, il convient de noter que nous n’en utilisons pas la grande majorité (probablement environ XNUMX %). En revanche, ils sont tous relativement bon marché. Pour nous, c’est l’autre extrême par rapport au Icinga utilisé précédemment. Dans ce document, l'ajout de métriques était particulièrement pénible : celles existantes coûtaient cher (il suffit de regarder le code source de n'importe quel plugin). Tout plugin était un script en Bash ou Python, dont le lancement est coûteux en termes de ressources consommées.
- Ce système consomme une quantité relativement faible de ressources. 600 Mo de RAM, 15 % d'un cœur et quelques dizaines d'IOPS suffisent pour toutes nos métriques. Bien sûr, vous devez exécuter des exportateurs de métriques, mais ils sont tous écrits en Go et ne sont pas non plus très gourmands en énergie. Je ne pense pas que dans les réalités modernes, ce soit un problème.
- Offre la possibilité de migrer vers Kubernetes. Compte tenu des projets du client, le choix est évident.
WAPITI
Auparavant, nous ne collections ni ne traitions les journaux. Les lacunes sont claires pour tout le monde. Nous avons choisi ELK car nous avions déjà de l'expérience avec ce système. Nous y stockons uniquement les journaux d’applications. Les principaux critères de sélection étaient la recherche en texte intégral et sa rapidité.
Сlickhouse
Initialement, le choix s'est porté sur InfluxDB. Nous avons réalisé la nécessité de collecter les journaux Nginx, les statistiques de pg_stat_statements et de stocker les données historiques de Prometheus. Nous n'aimions pas Influx car il commençait périodiquement à consommer une grande quantité de mémoire et plantait. De plus, je voulais regrouper les requêtes par remote_addr, mais le regroupement dans ce SGBD se fait uniquement par balises. Les tags sont chers (mémoire), leur nombre est conditionnellement limité.
Nous avons recommencé nos recherches. Il fallait une base de données analytique avec une consommation de ressources minimale, de préférence avec une compression des données sur disque.
Clickhouse répond à tous ces critères, et nous n'avons jamais regretté notre choix. Nous n'y écrivons pas de quantités extraordinaires de données (le nombre d'insertions n'est que d'environ cinq mille par minute).
NouvelleRelique
NewRelic a toujours été avec nous parce que c'était le choix du client. Nous l'utilisons comme APM.
Zabbix
Nous utilisons Zabbix exclusivement pour surveiller la Black Box de diverses API.
Définir une approche de surveillance
Nous voulions décomposer la tâche et ainsi systématiser l'approche du suivi.
Pour ce faire, j'ai divisé notre système selon les niveaux suivants :
- matériel et VMS ;
- système opérateur;
- services système, pile logicielle ;
- Annexe;
- logique métier.
Pourquoi cette approche est pratique :
- nous savons qui est responsable du travail de chaque niveau et, sur cette base, nous pouvons envoyer des alertes ;
- nous pouvons utiliser la structure lors de la suppression des alertes - il serait étrange d'envoyer une alerte sur l'indisponibilité de la base de données lorsque la machine virtuelle dans son ensemble n'est pas disponible.
Puisque notre tâche est d'identifier les violations dans le fonctionnement du système, nous devons, à chaque niveau, mettre en évidence un certain ensemble de métriques auxquelles il convient de prêter attention lors de la rédaction des règles d'alerte. Passons ensuite aux niveaux « VMS », « Système d'exploitation » et « Services système, pile logicielle ».
Machines virtuelles
L'hébergement nous alloue un processeur, un disque, de la mémoire et un réseau. Et nous avons eu des problèmes avec les deux premiers. Donc les métriques :
Temps volé au processeur - lorsque vous achetez une machine virtuelle sur Amazon (t2.micro, par exemple), vous devez comprendre que vous ne disposez pas d'un cœur de processeur entier, mais seulement d'un quota de son temps. Et lorsque vous l'épuiserez, le processeur vous sera retiré.
Cette métrique vous permet de suivre ces moments et de prendre des décisions. Par exemple, est-il nécessaire de prendre un tarif plus élevé ou de répartir le traitement des tâches en arrière-plan et des requêtes API sur différents serveurs ?
IOPS + temps d'attente du processeur - pour une raison quelconque, de nombreux hébergements cloud pèchent en ne fournissant pas suffisamment d'IOPS. De plus, un planning avec de faibles IOPS n'est pas un argument pour eux. Par conséquent, cela vaut la peine de collecter iowait CPU. Avec cette paire de graphiques - avec de faibles IOPS et une attente d'E/S élevée - vous pouvez déjà parler à l'hébergement et résoudre le problème.
Système d'exploitation
Métriques du système d'exploitation :
- quantité de mémoire disponible en % ;
- activité d'utilisation du swap : vmstat swapin, swapout ;
- nombre d'inodes disponibles et d'espace libre sur le système de fichiers en %
- charge moyenne ;
- nombre de connexions dans deux états ;
- Conntrack la plénitude de la table ;
- La qualité du réseau peut être surveillée à l'aide de l'utilitaire ss, le package iproute2 - obtenez un indicateur des connexions RTT à partir de sa sortie et regroupez-le par port de destination.
Au niveau du système d'exploitation également, nous avons une entité telle que les processus. Il est important d'identifier dans le système un ensemble de processus qui jouent un rôle important dans son fonctionnement. Si, par exemple, vous disposez de plusieurs pgpools, vous devez alors collecter des informations pour chacun d'eux.
L'ensemble de métriques est le suivant :
- processeurs ;
- la mémoire est avant tout résidente ;
- IO - de préférence en IOPS ;
- FileFd - ouvert et limite ;
- échecs de page importants - de cette façon, vous pouvez comprendre quel processus est échangé.
Nous déployons toute la surveillance dans Docker et nous utilisons Advisor pour collecter des données de métriques. Sur d'autres machines, nous utilisons Process-Exporter.
Services système, pile logicielle
Chaque application a ses propres spécificités et il est difficile de distinguer un ensemble spécifique de mesures.
L'ensemble universel est :
- taux de demande ;
- nombre d'erreurs ;
- latence;
- saturation
Nos exemples les plus frappants de surveillance à ce niveau sont Nginx et PostgreSQL.
Le service le plus chargé de notre système est la base de données. Dans le passé, nous avions souvent du mal à comprendre ce que faisait la base de données.
Nous avons constaté une charge élevée sur les disques, mais les journaux lents n’ont pas vraiment montré quoi que ce soit. Nous avons résolu ce problème en utilisant pg_stat_statements, une vue qui collecte les statistiques des requêtes.
C'est tout ce dont l'administrateur a besoin.
Nous construisons des graphiques de l'activité des requêtes de lecture et d'écriture :
Tout est simple et clair, chaque demande a sa couleur.
Un exemple tout aussi frappant est celui des journaux Nginx. Il n’est pas surprenant que peu de gens les analysent ou les mentionnent dans la liste des incontournables. Le format standard n'est pas très informatif et doit être élargi.
Personnellement, j'ai ajouté request_time, Upstream_response_time, body_bytes_sent, request_length, request_id. Nous traçons le temps de réponse et le nombre d'erreurs :
Nous construisons des graphiques du temps de réponse et du nombre d'erreurs. Souviens-toi? Ai-je parlé d’objectifs commerciaux ? Rapidement et sans erreurs ? Nous avons déjà abordé ces questions avec deux graphiques. Et vous pouvez déjà appeler les administrateurs de service en les utilisant.
Mais il reste encore un problème : assurer l’élimination rapide des causes de l’incident.
Résolution des incidents
L’ensemble du processus, depuis l’identification jusqu’à la résolution d’un problème, peut être divisé en plusieurs étapes :
- identifier le problème ;
- notification à l'administrateur de service ;
- réponse à un incident ;
- élimination des causes.
Il est important que nous le fassions le plus rapidement possible. Et si, aux étapes d'identification d'un problème et d'envoi d'une notification, nous ne pouvons pas gagner beaucoup de temps - de toute façon, deux minutes y seront consacrées, alors les suivantes sont tout simplement un champ d'amélioration non labouré.
Imaginons que le téléphone de l'officier de service sonne. Qu'est ce qu'il va faire? Cherchez des réponses aux questions : qu'est-ce qui s'est cassé, où s'est-il cassé, comment réagir ? Voici comment nous répondons à ces questions :
Nous incluons simplement toutes ces informations dans le texte de la notification, lui donnons un lien vers une page wiki qui décrit comment répondre à ce problème, comment le résoudre et le faire remonter.
Je n’ai toujours rien dit sur la couche applicative et la logique métier. Malheureusement, nos applications n'implémentent pas encore la collecte de métriques. La seule source d'informations provenant de ces niveaux sont les journaux.
Quelques points.
Tout d’abord, écrivez des journaux structurés. Il n'est pas nécessaire d'inclure du contexte dans le texte du message. Cela les rend difficiles à regrouper et à analyser. Logstash met beaucoup de temps à normaliser tout cela.
Deuxièmement, utilisez correctement les niveaux de gravité. Chaque langue a sa propre norme. Personnellement, je distingue quatre niveaux :
- pas d'erreur;
- erreur côté client ;
- l’erreur est de notre côté, nous ne perdons pas d’argent, nous ne prenons pas de risques ;
- L'erreur est de notre côté, nous perdons de l'argent.
Permettez-moi de résumer. Vous devez essayer de créer une surveillance basée sur une logique métier. Essayez de surveiller l'application elle-même et de fonctionner avec des mesures telles que le nombre de ventes, le nombre d'enregistrements de nouveaux utilisateurs, le nombre d'utilisateurs actuellement actifs, etc.
Si l’ensemble de votre entreprise ne représente qu’un seul bouton dans le navigateur, vous devez vérifier s’il clique et fonctionne correctement. Tout le reste n’a pas d’importance.
Si vous ne l'avez pas, vous pouvez essayer de le rattraper dans les journaux d'application, les journaux Nginx, etc., comme nous l'avons fait. Vous devez être le plus près possible de l’application.
Les mesures du système d'exploitation sont bien sûr importantes, mais les entreprises ne s'y intéressent pas et nous ne sommes pas payés pour elles.
Source: habr.com