🥇La surveillance est-elle morte ? — Vive la surveillance

Depuis 2008, notre entreprise se consacre principalement à la gestion d'infrastructures et au support technique 400 heures sur 15 pour les projets Web : nous avons plus de 15 clients, soit environ XNUMX % du commerce électronique russe. En conséquence, une architecture très diversifiée est prise en charge. Si quelque chose tombe, nous sommes obligés de le réparer dans les XNUMX minutes. Mais pour comprendre qu'un accident s'est produit, il faut surveiller le projet et réagir aux incidents. Comment faire cela ?

Je pense qu'il y a un problème dans l'organisation d'un système de contrôle approprié. S'il n'y avait eu aucun problème, mon discours consisterait en une seule thèse : "Veuillez installer Prometheus + Grafana et les plugins 1, 2, 3." Malheureusement, cela ne fonctionne plus ainsi. Et le principal problème est que tout le monde continue de croire en quelque chose qui existait en 2008, en termes de composants logiciels.

Concernant l'organisation du système de suivi, j'oserais dire que... les projets avec un suivi compétent n'existent pas. Et la situation est si grave que si quelque chose tombe, il y a un risque que cela passe inaperçu - après tout, tout le monde est sûr que « tout est surveillé ».
Peut-être que tout est surveillé. Mais comment?

Nous avons tous rencontré une histoire comme celle-ci : un certain développeur, un certain administrateur travaille, une équipe de développement vient vers eux et leur dit : « nous sommes libérés, maintenant surveillez ». Surveiller quoi ? Comment ça fonctionne?

D'ACCORD. Nous surveillons à l'ancienne. Et ça change déjà, et il s'avère que vous avez surveillé le service A, qui est devenu le service B, qui interagit avec le service C. Mais l'équipe de développement vous dit : « Installez le logiciel, il doit tout surveiller !

Alors qu’est-ce qui a changé ? - Tout a changé!

2008 Tout va bien

Il y a quelques développeurs, un serveur, un serveur de base de données. Tout part d'ici. On a quelques informations, on installe zabbix, Nagios, cactus. Et puis nous définissons des alertes claires sur le processeur, sur le fonctionnement du disque et sur l'espace disque. Nous effectuons également quelques vérifications manuelles pour nous assurer que le site répond et que les commandes arrivent dans la base de données. Et voilà, nous sommes plus ou moins protégés.

Si l'on compare la quantité de travail que l'administrateur effectuait alors pour assurer la surveillance, alors 98 % de celui-ci était automatique : la personne qui effectue la surveillance doit comprendre comment installer Zabbix, comment le configurer et configurer les alertes. Et 2% - pour les contrôles externes : que le site répond et fait une requête à la base de données, que de nouvelles commandes sont arrivées.

2010 La charge augmente

Nous commençons à faire évoluer le Web en ajoutant un moteur de recherche. Nous voulons nous assurer que le catalogue de produits contient tous les produits. Et cette recherche de produits fonctionne. Que la base de données fonctionne, que les commandes sont passées, que le site répond en externe et répond depuis deux serveurs et que l'utilisateur n'est pas expulsé du site pendant qu'il est rééquilibré vers un autre serveur, etc. Il y a plus d'entités.

Par ailleurs, l’entité associée aux infrastructures reste toujours la plus importante dans la tête du dirigeant. Il y a encore une idée dans ma tête que la personne qui fait le monitoring est celle qui va installer zabbix et pouvoir le configurer.

Mais en même temps, des travaux apparaissent sur la réalisation de contrôles externes, sur la création d'un ensemble de scripts de requête pour l'indexeur de recherche, d'un ensemble de scripts pour vérifier que la recherche change au cours du processus d'indexation, d'un ensemble de scripts qui vérifient que les marchandises sont transférées au service de livraison, etc. et ainsi de suite.

Remarque : j'ai écrit « un ensemble de scripts » 3 fois. Autrement dit, la personne responsable de la surveillance n'est plus celle qui installe simplement zabbix. C'est une personne qui commence à coder. Mais rien n’a encore changé dans les esprits de l’équipe.

Mais le monde change, devient de plus en plus complexe. Une couche de virtualisation et plusieurs nouveaux systèmes sont ajoutés. Ils commencent à interagir les uns avec les autres. Qui a dit « ça sent les microservices » ? Mais chaque service ressemble toujours à un site Web individuellement. Nous pouvons nous y tourner et comprendre qu'il fournit les informations nécessaires et fonctionne de manière autonome. Et si vous êtes un administrateur constamment impliqué dans un projet qui se développe depuis 5-7-10 ans, ces connaissances s'accumulent : un nouveau niveau apparaît - vous l'avez réalisé, un autre niveau apparaît - vous l'avez réalisé...

Mais il est rare qu’on accompagne un projet pendant 10 ans.

CV du surveillant

Supposons que vous arriviez dans une nouvelle startup qui ait immédiatement embauché 20 développeurs, écrit 15 microservices, et que vous soyez un administrateur à qui on dit : « Créez CI/CD. S'il te plaît." Vous avez construit CI/CD et tout à coup vous entendez : « Il est difficile pour nous de travailler avec la production dans un « cube », sans comprendre comment l'application y fonctionnera. Faites-nous un bac à sable dans le même « cube ».
Vous créez un bac à sable dans ce cube. Ils vous disent immédiatement : « Nous voulons une base de données de scène qui soit mise à jour quotidiennement depuis la production, afin que nous comprenions qu'elle fonctionne sur la base de données, mais en même temps ne gâche pas la base de données de production.

Vous vivez dans tout cela. Il reste 2 semaines avant la sortie, ils vous disent : "Maintenant, surveillons tout ça..." Autrement dit. surveiller l'infrastructure du cluster, surveiller l'architecture des microservices, surveiller le travail avec les services externes...

Et mes collègues sortent de leur tête le schéma habituel et disent : « Eh bien, tout est clair ici ! Installez un programme qui surveillera tout cela. Oui, oui : Prometheus + Grafana + plugins.
Et ils ajoutent : « Vous avez deux semaines, assurez-vous que tout est sécurisé. »

Dans de nombreux projets que nous voyons, une personne est affectée au suivi. Imaginez que nous souhaitions embaucher une personne pour faire du suivi pendant 2 semaines et que nous rédigeons un CV pour elle. Quelles compétences cette personne devrait-elle posséder, compte tenu de tout ce que nous avons dit jusqu'à présent ?

Il doit comprendre le suivi et les spécificités de l'exploitation de l'infrastructure sidérurgique.
Il doit comprendre les spécificités de la surveillance de Kubernetes (et tout le monde veut aller au « cube », car on peut faire abstraction de tout, se cacher, car l'administrateur s'occupera du reste) - lui-même, son infrastructure, et comprendre comment surveiller les applications à l'intérieur.
Il doit comprendre que les services communiquent entre eux de manière particulière et connaître les spécificités de la manière dont les services interagissent les uns avec les autres. Il est tout à fait possible d'imaginer un projet où certains services communiquent de manière synchrone, car il n'y a pas d'autre moyen. Par exemple, le backend passe via REST, via gRPC vers le service de catalogue, reçoit une liste de produits et la renvoie. Vous ne pouvez pas attendre ici. Et avec d'autres services, cela fonctionne de manière asynchrone. Transférer la commande au service de livraison, envoyer un courrier, etc.
Vous avez probablement déjà nagé à cause de tout ça ? Et l’administrateur, qui doit surveiller cela, est devenu encore plus confus.
Il doit être capable de planifier et de planifier correctement - à mesure que le travail devient de plus en plus important.
Il doit donc créer une stratégie à partir du service créé afin de comprendre comment le suivre spécifiquement. Il a besoin d'une compréhension de l'architecture du projet et de son développement + une compréhension des technologies utilisées dans le développement.

Rappelons un cas tout à fait normal : certains services sont en PHP, certains services sont en Go, certains services sont en JS. Ils travaillent d’une manière ou d’une autre les uns avec les autres. C'est de là que vient le terme « microservice » : il y a tellement de systèmes individuels que les développeurs ne peuvent pas comprendre le projet dans son ensemble. Une partie de l’équipe écrit des services en JS qui fonctionnent de manière autonome et ne sait pas comment fonctionne le reste du système. L'autre partie écrit des services en Python et n'interfère pas avec le fonctionnement des autres services ; ils sont isolés dans leur propre domaine. Le troisième consiste à écrire des services en PHP ou autre chose.
Toutes ces 20 personnes sont réparties en 15 services, et il n'y a qu'un seul administrateur qui doit comprendre tout cela. Arrêt! nous venons de diviser le système en 15 microservices car 20 personnes ne peuvent pas comprendre l'ensemble du système.

Mais il faut le surveiller d'une manière ou d'une autre...

Quel est le résultat ? En conséquence, il y a une personne qui propose tout ce que toute l'équipe de développeurs ne peut pas comprendre, et en même temps, elle doit aussi savoir et être capable de faire ce que nous avons indiqué ci-dessus - l'infrastructure matérielle, l'infrastructure Kubernetes, etc.

Que puis-je dire... Houston, nous avons des problèmes.

Le suivi d'un projet logiciel moderne est un projet logiciel en soi

De la fausse croyance selon laquelle la surveillance est un logiciel, nous développons une croyance aux miracles. Mais les miracles, hélas, ne se produisent pas. Vous ne pouvez pas installer Zabbix et vous attendre à ce que tout fonctionne. Cela ne sert à rien d’installer Grafana et d’espérer que tout ira bien. L'essentiel du temps sera consacré à l'organisation des contrôles du fonctionnement des services et de leur interaction entre eux, en vérifiant le fonctionnement des systèmes externes. En fait, 90 % du temps sera consacré non pas à l’écriture de scripts, mais au développement de logiciels. Et cela doit être géré par une équipe qui comprend le travail du projet.
Si, dans cette situation, une personne est mise sous surveillance, un désastre se produira. C’est ce qui arrive partout.

Par exemple, plusieurs services communiquent entre eux via Kafka. La commande est arrivée, nous avons envoyé un message concernant la commande à Kafka. Il existe un service qui écoute les informations sur la commande et expédie les marchandises. Il existe un service qui écoute les informations sur la commande et envoie une lettre à l'utilisateur. Et puis de nombreux autres services apparaissent, et nous commençons à être confus.

Et si vous le donnez également à l'administrateur et aux développeurs au moment où il reste peu de temps avant la sortie, la personne devra comprendre l'ensemble de ce protocole. Ceux. Un projet de cette envergure prend beaucoup de temps, et cela doit être pris en compte dans le développement du système.
Mais très souvent, notamment dans les startups, on voit comment le suivi est reporté à plus tard. «Maintenant, nous allons faire une preuve de concept, nous allons lancer avec, la laisser tomber - nous sommes prêts à faire des sacrifices. Et puis nous surveillerons tout cela. Lorsque (ou si) le projet commence à rapporter de l'argent, l'entreprise souhaite ajouter encore plus de fonctionnalités - parce qu'il a commencé à fonctionner, il doit donc être déployé davantage ! Et vous êtes au point où vous devez d’abord surveiller tout ce qui précède, ce qui ne prend pas 1% du temps, mais bien plus. Et en passant, des développeurs seront nécessaires pour le suivi, et il sera plus facile de les laisser travailler sur de nouvelles fonctionnalités. En conséquence, de nouvelles fonctionnalités sont écrites, tout se gâte et vous vous retrouvez dans une impasse sans fin.

Alors, comment suivre un projet dès le début, et que faire si vous recevez un projet qui doit être suivi, mais que vous ne savez pas par où commencer ?

Tout d’abord, vous devez planifier.

Digression lyrique : très souvent, ils commencent par la surveillance des infrastructures. Par exemple, nous avons Kubernetes. Commençons par installer Prometheus avec Grafana, en installant des plugins pour surveiller le « cube ». Non seulement les développeurs, mais aussi les administrateurs ont la malheureuse pratique de : « Nous allons installer ce plugin, mais le plugin sait probablement comment le faire. » Les gens aiment commencer par les choses simples et directes, plutôt que par les actions importantes. Et la surveillance des infrastructures est simple.

Tout d’abord, décidez ce que vous souhaitez surveiller et comment, puis sélectionnez un outil, car les autres personnes ne peuvent pas penser à votre place. Et devraient-ils le faire ? D'autres personnes pensaient à un système universel - ou n'y pensaient pas du tout lorsque ce plugin a été écrit. Et ce n’est pas parce que ce plugin compte 5 5001 utilisateurs qu’il est utile. Peut-être deviendrez-vous le 5000ème simplement parce qu'il y avait déjà XNUMX personnes auparavant.

Si vous commencez à surveiller l'infrastructure et que le backend de votre application cesse de répondre, tous les utilisateurs perdront la connexion avec l'application mobile. Une erreur apparaîtra. Ils viendront vers vous et vous diront « L'application ne fonctionne pas, que faites-vous ici ? » - "Nous surveillons." — "Comment surveiller si vous ne voyez pas que l'application ne fonctionne pas ?!"

Je pense que vous devez commencer la surveillance exactement à partir du point d’entrée de l’utilisateur. Si l’utilisateur ne voit pas que l’application fonctionne, c’est tout, c’est un échec. Et le système de surveillance devrait d’abord en avertir.
Et ce n’est qu’à ce moment-là que nous pourrons surveiller l’infrastructure. Ou faites-le en parallèle. C'est plus facile avec l'infrastructure - ici, nous pouvons enfin simplement installer zabbix.
Et maintenant, vous devez aller aux racines de l’application pour comprendre où les choses ne fonctionnent pas.

Mon idée principale est que le suivi doit être parallèle au processus de développement. Si vous détournez l'équipe de surveillance pour d'autres tâches (création de CI/CD, sandboxing, réorganisation de l'infrastructure), la surveillance commencera à prendre du retard et vous ne pourrez peut-être jamais rattraper le développement (ou tôt ou tard, vous devrez l'arrêter).

Tout par niveaux

C’est ainsi que je vois l’organisation d’un système de surveillance.

1) Niveau d'application :

surveiller la logique métier des applications ;
surveiller les paramètres de santé des services ;
suivi de l'intégration.

2) Niveau des infrastructures :

surveillance au niveau de l'orchestration ;
surveillance des logiciels système ;
surveillance du niveau de fer.

3) Encore une fois au niveau de l'application - mais en tant que produit d'ingénierie :

collecter et surveiller les journaux d'application ;
APM ;
tracé.

4) Alerte :

organisation d'un système d'alerte;
organisation d'un système de devoirs;
organisation d’une « base de connaissances » et d’un workflow pour le traitement des incidents.

Il est important: on donne l'alerte non pas après, mais tout de suite ! Il n'est pas nécessaire de lancer une surveillance et de déterminer « d'une manière ou d'une autre plus tard » qui recevra les alertes. Après tout, quelle est la tâche de la surveillance : comprendre où dans le système quelque chose ne fonctionne pas bien et en informer les bonnes personnes. Si vous laissez cela jusqu'à la fin, alors les bonnes personnes sauront que quelque chose ne va pas simplement en disant « rien ne fonctionne pour nous ».

Couche Application - Surveillance de la logique métier

Nous parlons ici de vérifier le fait même que l'application fonctionne pour l'utilisateur.

Ce niveau doit être fait pendant la phase de développement. Par exemple, nous avons un Prometheus conditionnel : il va au serveur qui effectue les vérifications, extrait le point de terminaison, et le point de terminaison va vérifier l'API.

Lorsqu'on leur demande souvent de surveiller la page d'accueil pour s'assurer que le site fonctionne, les programmeurs donnent une poignée qui peut être tirée à chaque fois qu'ils ont besoin de s'assurer que l'API fonctionne. Et les programmeurs en ce moment prennent et écrivent encore /api/test/helloworld
La seule façon de s’assurer que tout fonctionne ? - Non!

La création de tels contrôles est essentiellement la tâche des développeurs. Les tests unitaires doivent être écrits par les programmeurs qui écrivent le code. Parce que si vous le divulguez à l'administrateur, "Mec, voici une liste des protocoles API pour les 25 fonctions, s'il te plaît, surveille tout !" - rien ne marchera.
Si vous imprimez « hello world », personne ne saura jamais que l’API devrait fonctionner et fonctionne effectivement. Chaque changement d'API doit entraîner une modification des contrôles.
Si vous rencontrez déjà un tel problème, arrêtez les fonctionnalités et affectez des développeurs qui rédigeront ces chèques, ou acceptez les pertes, acceptez que rien n'est vérifié et échouera.

Conseils techniques :

Assurez-vous d'organiser un serveur externe pour organiser les contrôles - vous devez être sûr que votre projet est accessible au monde extérieur.
Organisez les contrôles sur l'ensemble du protocole API, et pas seulement sur les points de terminaison individuels.
Créez un point de terminaison prometheus avec les résultats du test.

Couche application - surveillance des métriques de santé

Nous parlons maintenant de mesures de santé externes des services.

Nous avons décidé de surveiller tous les « handles » de l'application à l'aide de contrôles externes, que nous appelons depuis un système de surveillance externe. Mais ce sont les « poignées » que l’utilisateur « voit ». Nous voulons être sûrs que nos services eux-mêmes fonctionnent. Il y a une meilleure histoire ici : K8s effectue des contrôles de santé, afin qu'au moins le « cube » lui-même puisse être convaincu que le service fonctionne. Mais la moitié des chèques que j'ai vus portent la même impression « hello world ». Ceux. Alors il tire une fois après le déploiement, il répond que tout va bien, c'est tout. Et le service, s’il fournit sa propre API, dispose d’un grand nombre de points d’entrée pour cette même API, qu’il faut également surveiller, car nous voulons savoir si cela fonctionne. Et nous le surveillons déjà à l’intérieur.

Comment implémenter cela correctement techniquement : chaque service expose un point de terminaison sur ses performances actuelles, et dans les graphiques de Grafana (ou de toute autre application), nous voyons l'état de tous les services.

Chaque changement d'API doit entraîner une modification des contrôles.
Créez immédiatement un nouveau service avec des mesures de santé.
Un administrateur peut s'adresser aux développeurs et leur demander « ajoutez-moi quelques fonctionnalités pour que je comprenne tout et ajoute des informations à ce sujet à mon système de surveillance ». Mais les développeurs répondent généralement : « Nous n’ajouterons rien deux semaines avant la sortie. »
Faites savoir aux responsables du développement qu'il y aura de telles pertes, faites-le savoir également à la direction des responsables du développement. Parce que quand tout tombe, quelqu'un appellera toujours et demandera de surveiller le « service en baisse constante » (c)
À propos, demandez aux développeurs d'écrire des plugins pour Grafana - ce sera une bonne aide pour les administrateurs.

Couche Application - Surveillance de l'intégration

La surveillance de l'intégration se concentre sur la surveillance des communications entre les systèmes critiques pour l'entreprise.

Par exemple, il existe 15 services qui communiquent entre eux. Ce ne sont plus des sites distincts. Ceux. nous ne pouvons pas exploiter le service tout seul, obtenir /helloworld et comprendre que le service est en cours d'exécution. Étant donné que le service Web de commande doit envoyer des informations sur la commande au bus - depuis le bus, le service d'entrepôt doit recevoir ce message et continuer à l'utiliser. Et le service de distribution de courrier électronique doit traiter cela d'une manière ou d'une autre, etc.

Par conséquent, nous ne pouvons pas comprendre, en examinant chaque service individuellement, que tout fonctionne. Parce que nous avons un certain bus à travers lequel tout communique et interagit.
Par conséquent, cette étape devrait marquer l’étape de test des services pour l’interaction avec d’autres services. Il est impossible d'organiser la surveillance des communications en surveillant le courtier de messages. S'il existe un service qui émet des données et un service qui les reçoit, lors de la surveillance du courtier, nous ne verrons que les données qui volent d'un côté à l'autre. Même si nous parvenions d'une manière ou d'une autre à surveiller l'interaction de ces données en interne - qu'un certain producteur publie les données, que quelqu'un les lit, ce flux continue d'aller vers Kafka - cela ne nous donnera toujours pas d'informations si un service envoyait le message dans une seule version. , mais l'autre service ne s'attendait pas à cette version et l'a ignorée. Nous n’en saurons rien, puisque les services nous diront que tout fonctionne.

Ce que je recommande de faire :

Pour une communication synchrone : le point de terminaison envoie des requêtes aux services associés. Ceux. nous prenons ce point de terminaison, extrayons un script à l'intérieur du service, qui va à tous les points et dit "Je peux tirer là, et tirer là, je peux tirer là..."
Pour la communication asynchrone : messages entrants - le point de terminaison vérifie le bus pour les messages de test et affiche l'état de traitement.
Pour la communication asynchrone : messages sortants - le point de terminaison envoie des messages de test au bus.

Comme cela arrive habituellement : nous avons un service qui envoie des données dans le bus. Nous venons à ce service et vous demandons de nous parler de sa santé d'intégration. Et si le service a besoin de produire un message quelque part plus loin (WebApp), alors il produira ce message de test. Et si nous exécutons un service côté OrderProcessing, il publie d'abord ce qu'il peut publier de manière indépendante, et s'il y a des éléments dépendants, il lit alors un ensemble de messages de test du bus, comprend qu'il peut les traiter, le signale et , si nécessaire, publiez-les plus loin, et à ce sujet, il dit - tout va bien, je suis en vie.

Très souvent, nous entendons la question « comment pouvons-nous tester cela sur des données de combat ? » Par exemple, nous parlons du même service de commande. La commande envoie des messages à l'entrepôt où les marchandises sont radiées : nous ne pouvons pas tester cela sur les données de combat, car « mes marchandises seront radiées ! Solution : Planifiez l’intégralité de ce test dès le début. Vous disposez également de tests unitaires qui font des simulations. Alors, faites-le à un niveau plus profond où vous disposez d’un canal de communication qui ne nuit pas au fonctionnement de l’entreprise.

Couche d'infrastructure

La surveillance des infrastructures est quelque chose qui a longtemps été considéré comme une surveillance en soi.

La surveillance des infrastructures peut et doit être lancée en tant que processus distinct.
Vous ne devriez pas commencer par surveiller l’infrastructure d’un projet en cours, même si vous le souhaitez vraiment. C'est une douleur pour tous les développeurs. "Je vais d'abord surveiller le cluster, je vais surveiller l'infrastructure" - c'est-à-dire Premièrement, il surveillera ce qui se trouve en dessous, mais n'entrera pas dans l'application. Parce que l'application est une chose incompréhensible pour les développeurs. Cela lui a été divulgué et il ne comprend pas comment cela fonctionne. Et il comprend l’infrastructure et commence par elle. Mais non, vous devez toujours d’abord surveiller l’application.
N'exagérez pas avec le nombre d'alertes. Compte tenu de la complexité des systèmes modernes, les alertes volent constamment et vous devez d’une manière ou d’une autre vivre avec cet ensemble d’alertes. Et la personne d’astreinte, après avoir consulté une centaine de prochaines alertes, décidera : « Je ne veux pas y penser ». Les alertes ne doivent informer que des éléments critiques.

Niveau d'application en tant qu'unité commerciale

Points clés:

WAPITI. Il s'agit de la norme de l'industrie. Si, pour une raison quelconque, vous ne regroupez pas les journaux, commencez à le faire immédiatement.
APM. APM externes comme moyen de fermer rapidement la surveillance des applications (NewRelic, BlackFire, Datadog). Vous pouvez installer cette chose temporairement pour au moins comprendre d'une manière ou d'une autre ce qui se passe chez vous.
Tracé. Dans des dizaines de microservices, il faut tout tracer, car la requête ne vit plus seule. Il est très difficile d'ajouter plus tard, il est donc préférable de planifier immédiatement le traçage pendant le développement - c'est le travail et l'utilité des développeurs. Si vous ne l'avez pas encore implémenté, implémentez-le ! Voir Jaeger/Zipkin

Alerte

Organisation d'un système de notification : dans des conditions de surveillance de beaucoup de choses, il devrait y avoir un système unifié d'envoi de notifications. C’est possible à Grafana. En Occident, tout le monde utilise PagerDuty. Les alertes doivent être claires (par exemple d'où elles viennent...). Et il est conseillé de contrôler que les notifications soient reçues
Organisation d'un système de garde : les alertes ne doivent pas être envoyées à tout le monde (soit tout le monde réagira en foule, soit personne ne réagira). Les développeurs doivent également être disponibles : assurez-vous de définir les domaines de responsabilité, de donner des instructions claires et d'y écrire qui appeler exactement le lundi et le mercredi, et qui appeler le mardi et le vendredi (sinon, ils n'appelleront personne même dans le en cas de gros problème - ils auront peur de vous réveiller ou de vous déranger : les gens n'aiment généralement pas appeler et réveiller les autres, surtout la nuit). Et expliquez que demander de l’aide n’est pas un indicateur d’incompétence (« Je demande de l’aide, ça veut dire que je suis un mauvais travailleur »), encouragez les demandes d’aide.
Organisation d'une « base de connaissances » et d'un workflow pour le traitement des incidents : pour chaque incident grave, une autopsie doit être planifiée et, à titre temporaire, les actions qui permettront de résoudre l'incident doivent être enregistrées. Et faites en sorte que les alertes répétées soient un péché ; ils doivent être corrigés dans le code ou dans les travaux d'infrastructure.

Pile technologique

Imaginons que notre pile soit la suivante :

collecte de données - Prometheus + Grafana ;
analyse des journaux - ELK ;
pour APM ou Tracing - Jaeger (Zipkin).

Le choix des options n'est pas critique. Parce que si au début vous avez compris comment surveiller le système et rédigé un plan, vous commencez alors à choisir des outils adaptés à vos besoins. La question est de savoir ce que vous avez choisi de surveiller en premier lieu. Parce que peut-être que l’outil que vous avez choisi au début ne répond pas du tout à vos besoins.

Quelques points techniques que je vois partout ces derniers temps :

Prometheus est poussé à l'intérieur de Kubernetes - qui a inventé ça ?! Si votre cluster plante, que ferez-vous ? Si vous avez un cluster complexe à l'intérieur, il devrait y avoir une sorte de système de surveillance à l'intérieur du cluster, et un autre à l'extérieur, qui collectera les données de l'intérieur du cluster.

À l'intérieur du cluster, nous collectons les journaux et tout le reste. Mais le système de surveillance doit être extérieur. Très souvent, dans un cluster où Promtheus est installé en interne, il existe également des systèmes qui effectuent des contrôles externes du fonctionnement du site. Que faire si vos connexions avec le monde extérieur sont interrompues et que l'application ne fonctionne pas ? Il s’avère que tout va bien à l’intérieur, mais cela ne facilite pas les choses pour les utilisateurs.

résultats

Le suivi du développement n'est pas l'installation d'utilitaires, mais le développement d'un produit logiciel. 98 % de la surveillance actuelle concerne le codage. Codage dans les services, codage des contrôles externes, contrôle des services externes, et c'est tout.
Ne perdez pas le temps de vos développeurs en supervision : cela peut prendre jusqu'à 30 % de leur travail, mais cela en vaut la peine.
Devops, ne vous inquiétez pas de ne pas pouvoir surveiller quelque chose, car certaines choses sont une façon de penser complètement différente. Vous n'étiez pas programmeur et surveiller le travail est exactement leur travail.
Si le projet est déjà en cours d'exécution et n'est pas surveillé (et que vous êtes un gestionnaire), allouez des ressources pour le suivi.
Si le produit est déjà en production et que vous êtes un développeur à qui on a demandé de «mettre en place une surveillance», essayez d'expliquer à la direction sur quoi j'ai écrit tout cela.

Il s'agit d'une version étendue du rapport de la conférence Saint Highload++.

Si vous êtes intéressé par mes idées et réflexions à ce sujet et sur des sujets connexes, alors vous pouvez ici lire la chaîne ????

Source: habr.com

La surveillance est-elle morte ? — Vive la surveillance