Comment nous avons construit la surveillance sur Prometheus, Clickhouse et ELK

Je m'appelle Anton Baderin. Je travaille au Center for High Technologies et je suis engagé dans 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 avec la communauté informatique de notre ville. J'ai parlé de la surveillance des applications Web. Le matériel était destiné au niveau junior ou intermédiaire, qui n'a pas construit ce processus à partir de zéro.

La pierre angulaire de tout système de surveillance est la solution aux problèmes commerciaux. La surveillance à des fins de surveillance n'a d'intérêt pour personne. Que veut l'entreprise? Pour que tout fonctionne rapidement et sans erreur. Les entreprises veulent de la proactivité, afin que nous puissions nous-mêmes identifier les problèmes du service et les éliminer le plus rapidement possible. C'est en effet la tâche que j'ai résolue toute l'année dernière sur le projet d'un de nos clients.

À propos du projet

Le projet est l'un des plus importants programmes de fidélisation du pays. Nous aidons les détaillants à augmenter leur fréquence de vente grâce à divers outils marketing tels que les cartes bonus. Au total, le projet comprend 14 applications qui s'exécutent sur dix serveurs.

Au cours des entretiens, j'ai remarqué à plusieurs reprises que les administrateurs ne sont pas toujours les bons pour surveiller les applications Web: jusqu'à présent, beaucoup s'attardent sur les métriques du système d'exploitation et surveillent parfois les services.

Dans mon cas, Icinga était la base du système de suivi des clients auparavant. Elle n'a pas résolu les problèmes ci-dessus. Souvent, le client lui-même nous a informés des problèmes et au moins nous n'avions tout simplement pas assez de données pour aller au fond de la raison.

En outre, on comprenait clairement la futilité de son développement ultérieur. 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 du projet.

Prométhée

Nous avons choisi Prometheus en fonction de trois indicateurs clés:

1. Un grand nombre de métriques disponibles. Dans notre cas, il y en a 60 000. Bien sûr, il convient de noter que la grande majorité d'entre eux que nous n'utilisons pas (probablement environ 95%). En revanche, ils sont tous relativement bon marché. Pour nous, c'est un autre extrême par rapport à Icinga précédemment utilisé. Dans ce document, l'ajout de métriques était une douleur particulière: celles disponibles étaient coûteuses (il suffit de regarder le code source de tout plugin). Tout plug-in était un script Bash ou Python, dont le lancement n'est pas bon marché en termes de ressources consommées.
2. Ce système consomme une quantité relativement faible de ressources. Toutes nos mesures ont 600 Mo de RAM, 15% d'un cœur et quelques dizaines d'IOPS. Bien sûr, vous devez exécuter des exportateurs de métriques, mais elles sont toutes écrites en Go et ne diffèrent pas non plus en gloutonnerie. Je ne pense pas que dans les réalités modernes, ce soit un problème.
3. Il permet de passer à Kubernetes. Compte tenu des plans du client, le choix est évident.

ELK

Auparavant, nous ne collections ni ne traitions les journaux. Les défauts sont clairs pour tout le monde. Nous avons choisi ELK, car nous avions déjà de l'expérience avec ce système. Nous n'y stockons que des journaux d'application. Les principaux critères de sélection étaient la recherche en texte intégral et sa rapidité.

Clickhouse

Au départ, le choix s'est porté sur InfluxDB. Nous avons reconnu 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 se bloquait. De plus, je voulais regrouper les demandes par remote_addr, et regrouper dans ce SGBD uniquement par balises. Tags de la route (mémoire), leur nombre est conditionnellement limité.

Nous avons recommencé la recherche. Nous avions besoin d'une base 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é ce choix. Nous n'y écrivons aucune quantité de données en suspens (le nombre d'insertions n'est que d'environ cinq mille par minute).

NewRelic

NewRelic a toujours été avec nous depuis 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 suivi

Nous voulions décomposer la tâche et ainsi systématiser l'approche de suivi.

Pour ce faire, j'ai divisé notre système selon les niveaux suivants:

• Matériel et VMS;
• système d'exploitation
• services système, pile logicielle;
• application
• logique métier.

Ce qui rend cette approche pratique:

• nous savons qui est responsable du travail de chacun des niveaux et, sur cette base, nous pouvons envoyer des alertes;
• nous pouvons utiliser la structure lors de la suppression d'alertes - il serait étrange d'envoyer une alerte sur l'inaccessibilité de la base de données lorsque la machine virtuelle est généralement inaccessible.

Étant donné que notre tâche consiste à identifier les irrégularités dans le système, nous devons à chaque niveau sélectionner un certain ensemble de paramètres auxquels vous devez prêter attention lors de la rédaction des règles de l'alerte. Ensuite, nous passerons par les niveaux de «VMS», «Système d'exploitation» et «Services système, pile logicielle».

Machines virtuelles

L'hébergement nous donne un processeur, un disque, une mémoire et un réseau. Et avec les deux premiers, nous avons eu des problèmes. Donc, les métriques:

Temps volé du 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 complet, mais uniquement 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 gros ou de répartir le traitement des tâches et requêtes en arrière-plan dans l'API sur différents serveurs.

IOPS + CPU iowait time - pour une raison quelconque, de nombreuses sociétés d'hébergement cloud pèchent en ne fournissant pas IOPS. De plus, un programme avec un faible IOPS n'est pas un argument pour eux. Par conséquent, il vaut la peine de collecter le processeur iowait. Avec cette paire de graphiques - avec des IOPS faibles et des attentes d'E / S élevées - vous pouvez déjà parler à l'hébergement et résoudre le problème.

Système d'exploitation

Mesures du système d'exploitation:

• quantité de mémoire disponible en%;
• activité utilisant swap: vmstat swapin, swapout;
• le nombre d'inodes disponibles et d'espace libre sur le système de fichiers en%
• charge moyenne;
• nombre de connexions dans deux états;
• plénitude de la table conntrack;
• la qualité du réseau peut être surveillée à l'aide de l'utilitaire ss, package iproute2 - recevez de sa sortie un indicateur des connexions RTT et regroupez par dest-port.

Toujours au niveau du système d'exploitation, nous avons une entité telle que les processus. Il est important de mettre en évidence dans le système un ensemble de processus qui jouent un rôle important dans son travail. Si, par exemple, vous avez plusieurs pgpool, vous devez collecter des informations pour chacun d'eux.

L'ensemble des métriques est le suivant:

• CPU
• la mémoire est principalement résidente;
• IO - de préférence dans IOPS;
• FileFd - ouvrir et limiter;
• échecs de pages importants - afin que vous puissiez comprendre quel processus est en train de permuter.

Toute la surveillance est déployée dans Docker, nous utilisons advisor pour collecter des données métriques. Sur d'autres machines, nous utilisons un exportateur de processus.

Services système, pile de logiciels

Chaque application a ses propres spécificités et il est difficile de distinguer un ensemble de métriques.

L'ensemble universel sont:

• taux de demande;
• nombre d'erreurs;
• latence
• saturation.

Les 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. Nous avions souvent des problèmes pour comprendre ce que fait la base de données.

Nous avons vu une charge élevée sur les disques, mais les slogans ne montraient vraiment rien. Nous avons résolu ce problème avec pg_stat_statements, une vue qui collecte des statistiques sur les demandes.

C'est tout ce dont l'administrateur a besoin.

Nous traçons l'activité des requêtes de lecture et d'écriture:

Tout est simple et clair, chaque demande a sa propre couleur.

Un exemple tout aussi frappant est celui des journaux Nginx. Sans surprise, peu les analyse ou les mentionne dans la liste des requis. Le format standard n'est pas très informatif et doit être étendu.

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 traçons le temps de réponse et le nombre d'erreurs. Tu te souviens? Ai-je parlé des objectifs commerciaux? Pour rapidement et sans erreurs? Nous avons déjà résolu ces problèmes avec deux graphiques. Et sur eux, vous pouvez déjà appeler les administrateurs de garde.

Mais un autre problème subsistait: assurer l'élimination rapide des causes de l'incident.

Gestion des incidents

L'ensemble du processus, de l'identification à la résolution d'un problème, peut être divisé en plusieurs étapes:

• identification des problèmes;
• notification de l'administrateur en service;
• réaction à l'incident;
• élimination des causes.

Il est important que nous le fassions le plus rapidement possible. Et si nous ne pouvons pas gagner beaucoup de temps aux étapes de l'identification d'un problème et de l'envoi d'une notification - ils partiront en tout cas pendant deux minutes, alors les prochains ne sont qu'un champ vierge pour des améliorations.

Imaginons simplement que le téléphone sonne en service. Que va-t-il faire? Recherchez les réponses aux questions - qu'est-ce qui est cassé, où est-il cassé, comment réagir? Voici comment nous répondons à ces questions:

Nous incluons simplement toutes ces informations dans le texte de notification, nous lui donnons un lien vers une page wiki qui décrit comment répondre à ce problème, comment le résoudre et escalader.

Je n'ai toujours rien dit sur la couche application et la logique métier. Malheureusement, la collecte de métriques n'a pas encore été implémentée dans nos applications. La seule source d'au moins certaines informations de ces niveaux est les journaux.

Quelques points.

Tout d'abord, écrivez des journaux structurés. Pas besoin d'inclure le contexte dans le corps du message. Il est donc difficile de les regrouper et de les analyser. Logstash prend beaucoup de temps pour normaliser tout cela.

Deuxièmement, utilisez correctement les niveaux de gravité. Chaque langue a sa propre norme. Personnellement, je distingue quatre niveaux:

1. aucune erreur;
2. erreur côté client;
3. une erreur est de notre côté, nous ne perdons pas d'argent, nous ne supportons pas de risques;
4. l'erreur est de notre côté, nous perdons de l'argent.

Je résume. Il est nécessaire d'essayer de construire une surveillance précisément à partir de la 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'inscriptions de nouveaux utilisateurs, le nombre d'utilisateurs actuellement actifs, etc.

Si l'ensemble de votre entreprise est un seul bouton dans votre navigateur, vous devez vérifier s'il est compressé et fonctionne correctement. Tout le reste n'est pas important.

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 aussi proche que possible de l'application.

Les métriques du système d'exploitation sont bien sûr importantes, mais elles ne sont pas intéressantes pour les entreprises, nous ne sommes pas payés pour elles.