[Surveillance Nightingale] La gestion des alarmes, super !

La surveillance est la méthode, l'alarme est le moyen et la solution est le but.

Mais avez-vous déjà rencontré ce genre de confusion ? J'ai collecté beaucoup d'indicateurs, mais je ne sais pas quels indicateurs doivent générer des alarmes, ni comment envoyer ces alarmes aux équipes ou individus correspondants, ni comment faire évoluer les alarmes.

Lorsque j'utilisais Prometheus+Altermanager auparavant, j'ai créé un groupe DingTalk pour chaque équipe, puis j'ai ajouté un tas de balises, j'ai fait correspondre différentes balises et je les ai envoyées à différents groupes. Si je souhaite mettre à niveau les alarmes, il y en aura beaucoup. problèmes. Le temps est accompli grâce à la mise à niveau du seuil, mais il est difficile de gérer la même alarme via la mise à niveau du temps.

Mais la gestion des règles d'alarme de Nightingale n'est pas si compliquée (ils font les choses compliquées pour vous), et elle est aussi très élégante. J'ai rencontré Nightingale pour la première fois dans "[Nightingale Monitoring]", et c'est toujours aussi fort ! 》​​Mentionné : Grafana est meilleur dans la gestion des panneaux de surveillance, et N9e est meilleur dans la gestion des règles d'alarme.

Aujourd’hui, regardons comment joue Nightingale.

Règles d'alarme

Les soldats et les chevaux ne bougent pas encore, la nourriture et l'herbe passent en premier.

Pour alerter, il faut d'abord savoir quels sont nos besoins, c'est-à-dire comprendre quels indicateurs doivent être alertés.

Par exemple, au niveau du système, nous devons considérer le CPU, la mémoire, le disque, les E/S et d'autres indicateurs ; au niveau de l'application, nous devons considérer la saturation, le taux de défaillance et le retard de l'application ; nous devons considérer cette fois le nombre de transactions ayant échoué, où elles ont échoué, etc.

À différents niveaux, les indicateurs de surveillance et les stratégies d'alarme considérés seront différents.

Les règles d'alarme de Nightingale sont divisées en règles intégrées et règles personnalisées.

Les règles intégrées sont conçues pour abaisser le seuil d'utilisation par tous et fournir à chacun un ensemble de règles universelles. Le contenu principal est le suivant :

Les règles d'alarme intégrées ne prendront effet que si vous les intégrez dans vos règles. Si vous aimez une certaine règle, vous pouvez la cloner dans les règles actives. Par exemple, j'ai cloné la règle d'alarme Linux TIME_WAIT dans le groupe d'activité par défaut.

Ensuite, accédez à l'aperçu des règles d'alarme et vous verrez qu'une nouvelle règle d'alarme a été ajoutée au groupe d'activité par défaut.

Après avoir vu cela, avez-vous une inspiration en tête ?

Nous pouvons créer plusieurs groupes d'entreprises en fonction de la situation réelle, et pouvons-nous ensuite gérer séparément les règles d'alarme impliquant plusieurs groupes d'entreprises ?

Supposons que nous ayons deux équipes, le front office et le middle office, nous pouvons classer les indicateurs séparément.

En principe, les règles importées par défaut ne sont pas efficaces et nécessitent quelques configurations supplémentaires.

Cliquez sur le nom de la règle d'alarme pour accéder à la page de configuration.

Nous pouvons personnaliser les conditions d'alarme, les sources de données, les niveaux d'alarme et d'autres configurations. Les informations que nous avons configurées ci-dessus sont résumées comme suit :

La source de données de l'alarme est local_prometheus, qui indique de quel cluster provient votre alarme.
• La condition d'alarme est que l'alarme ne sera déclenchée que lorsque le nombre total de TIME_WAIT est supérieur à 20 000.
• Le niveau d'alarme est le niveau 2, qui est le niveau général important.
• La fréquence d'exécution est d'une fois toutes les 15 secondes. Si la règle d'alarme est toujours respectée pendant 60 secondes en continu, l'alarme sera déclenchée

L'étape suivante est une configuration supplémentaire, comme suit :

La configuration effective. est utilisé pour configurer la règle d'alarme. Quelle période et quel groupe d'activité prend effet ? La configuration des notifications consiste à configurer le support de notification, c'est-à-dire, si une alarme se produit, quels canaux doivent être utilisés pour l'envoyer à quel endroit.

Cependant, vous pouvez également effectuer des configurations supplémentaires dans la configuration des notifications :

• Démarrez la notification de récupération, c'est-à-dire que si l'alarme est récupérée, le responsable sera également averti via ce canal.
• Groupe de réception d'alarme, également connu sous le nom de groupe professionnel.
• Observez la durée. Une fois l'alarme restaurée, observez le temps nécessaire pour envoyer une notification de récupération au groupe d'entreprise. Quelles alarmes volatiles peuvent être évitées ?
• Répétez la notification, c'est-à-dire que pendant cette période, si l'alarme n'a pas été résolue, elle sera renvoyée. Bien entendu, l’escalade des alarmes n’est pas impliquée ici.

Après avoir vu cela, avez-vous une certaine compréhension de la gestion des règles d'alarme ordinaires ?

En plus de cloner les règles d'alarme intégrées, nous pouvons également personnaliser les règles d'alarme, mais la configuration globale est la même que ci-dessus.

Bloquer les alarmes

Généralement, les alarmes bloquées ne sont pas des alarmes très importantes.

Dans quelles circonstances l'alarme sera-t-elle bloquée ?

Par exemple, lorsque nous publions une application, nous rencontrerons inévitablement des problèmes. A ce moment-là, nous pouvons établir quelques règles de blocage à l'avance pour éviter de générer des messages d'alarme.

Les règles de blindage sont également divisées par composants métier. Nous pouvons ajouter une nouvelle règle comme suit pour créer une règle de blocage des alarmes du centre de messagerie.

De cette façon, dans un créneau horaire fixe, les informations d'alarme ne seront plus envoyées.

Certains étudiants diront peut-être : est-ce un peu gênant de les ajouter un par un comme ceci ?

Si c'est une alarme active qui a été générée, elle peut être bloquée en un clic.

S'il s'agit d'une alarme historique, elle peut également être bloquée en un clic.

Quoi d'autre ?

Si vous souhaitez bloquer quelque chose, ajoutez-le vous-même !

Mise à niveau de l'alarme

Que dois-je faire si une alarme n'a pas été traitée dans un délai donné ?

Soit ce n'est pas un avertissement important - supprimez la règle et laissez-la inutile.

Ou c'est une alarme qui ne peut pas être résolue - mettez-la à niveau et informez-en davantage de personnes.

Dans Nightingale, les mises à niveau d'alarme peuvent être mises en œuvre dans les règles d'abonnement.

Par exemple, notre configuration est la suivante :

Si l'événement d'alarme du serveur = notification n'est pas résolu dans l'heure, nous mettrons à niveau le niveau d'alarme au niveau un et enverrons les informations d'alarme à un niveau supérieur. groupe.

Les règles ici peuvent également être classées et gérées par des équipes métiers.

De plus, il fournit également des alarmes actives et des alarmes historiques. Vous pouvez vérifier les informations d'alarme actuelles et les enregistrements d'alarme historiques.

Auto-guérison de l'alarme

Plus vous travaillez longtemps en exploitation et en maintenance, vous constaterez en fait que le traitement de nombreuses choses est répétitif. Certaines tâches simples et répétitives peuvent être traitées via des scripts automatisés, ce qui améliore non seulement l'efficacité du travail. , mais améliore également l'efficacité des opérations à un certain niveau. Réduisez dans une certaine mesure le risque d'opération humaine.

Nightingale fournit une fonction d'auto-guérison d'alarme. Bien que la fonction soit bonne, ne soyez pas gourmand.

Lorsque vous faites face à une alarme, vous devez d'abord en découvrir la véritable raison, afin de pouvoir résoudre le problème. Ainsi, pour l’auto-réparation de l’alarme, vous devez comprendre que le risque de l’opération automatisée que vous effectuez est très faible et que vous l’avez essayé plusieurs fois. N'utilisez pas l'opération cd /opt/aaa;rm -rf ./.

Dans Nightingale, utilisez le modèle ibex pour implémenter l'auto-guérison des alarmes. Actuellement, le côté serveur ibex doit être déployé par lui-même et le côté agent ibex a été intégré à Categraf.

Déployez ibex-server

Allez sur https://github.com/flashcatcloud/ibex/releases pour télécharger le package binaire Après le téléchargement, il contient les fichiers suivants :

# ll
total 21536
drwxr-xr-x 3 root root 4096 Apr 19 10:44 etc
-rwxr-xr-x 1 root root 16105472 Nov 152021 ibex
-rw------- 1 root root5931963 Jun32022 ibex-1.0.0.tar.gz
drwxr-xr-x 2 root root 4096 Nov 152021 sql

Importer la base de données :

mysql -uroot -p <sql/ibex.sql

Puis modifiez le fichier de configuration /etc/server.conf, en modifiant principalement la configuration de la base de données.

Démarrez enfin le serveur :

nohup ./ibex server &> server.log &

Configurez le client

Dans la configuration du système​->Configuration des notifications​->Configuration du module d'auto-réparation d'alarme Adresse du serveur correspondante :

Test Auto-guérison

Ensuite, accédez au script d'auto-guérison d'alarme​-> et ajoutez un script comme suit :

Enregistrez et quittez, cliquez sur Créer une tâche :

Si la configuration à l'intérieur n'a pas besoin d'être modifiée ou après avoir modifié la configuration correspondante, choisissez de l'exécuter immédiatement :

À ce stade, pensez-vous que tout va bien ?

Quoi qu'il en soit, je n'ai pas réussi. À ce stade, je dois me plaindre de ce module :

• Y a-t-il des prérequis pour le déploiement d'ibex-server ?
• Y a-t-il des conditions préalables pour l'agent bouquetin (categraf) ?
• L'exécution du script d'auto-réparation a échoué. Il n'y a pas de journal d'échec spécifique ni sur le client ni sur le serveur
• Comment mettre l'entrée de configuration d'auto-réparation d'alarme de la version N9e V6 dans le module de notification de message ? Bizarre
• Le document officiel de ce module est un peu trop simple

Donc, je n'ai pas réussi ici, le front-end a lancé un timeout.

Aucun journal dans le backend.

Résumé

À l'heure actuelle, Nightingale peut relativement compléter la gestion des règles d'alarme, la distribution des canaux d'alarme, la suppression et la mise à niveau des messages d'alarme, et FlashDuty peut accéder à différentes alarmes de cluster, ce qui est suffisant dans la plupart des entreprises.

Seulement lors du test de l'auto-réparation de l'alarme, je n'ai pas testé avec succès. Cela devrait être lié à mon environnement :

• Le module global de N9e est déployé sur les K8 à l'aide de Helm, mais le côté serveur ibex est déployé directement sur l'hôte sous forme binaire
• Cependant, il n'y a pas de raison spécifique Après le dépannage , trop peu d'informations de dépannage étaient disponibles.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!