Surveillance du pauvre ou surveillance du serveur depuis la console

Bienvenue à tous, chers lecteurs. Dans cet article je vais vous parler de mon «vélo», sur lequel je fais le suivi de diverses choses sans quitter la console.

J'ai rencontré une fois une situation où un grand nombre de projets et de serveurs différents se sont développés, et mes mains n'ont pas réussi à mettre en place une surveillance normale.

Et dans le monde moderne, une surveillance «correcte» implique le déploiement de tout un tas de logiciels, la configuration de tout cela. Eh bien, vous savez là-bas ... docker, pile élastique et c'est parti. Pour moi, c'était un gros frais généraux. J'en voulais un ou deux en production.

J'ai regardé Moniteur simple sur un python, il était le plus proche de moi en esprit, mais il manquait pas mal de fonctionnalités. Et en même temps, je voulais apprendre le Go ... eh bien, en général, vous savez vous-même comment tout commence habituellement.

J'ai donc pris le soudage Go et assemblé ce vélo .

Cli Monitoring est écrit en Go et est un ensemble de binaires, chacun recevant des données de stdin, effectue une tâche spécifique et affiche le résultat dans stdout.

Il existe au total quatre types de fichiers binaires: métriques , processeurs , filtres et sorties .

Les métriques , comme leur nom l'indique, collectent toutes les données et vont généralement en premier dans la chaîne.
Les processeurs sont au milieu et modifient en quelque sorte les données ou effectuent d'autres fonctions utilitaires.
Les filtres sont presque comme des processeurs, mais contrairement à eux, ils sautent ou ne sautent pas de données, selon la condition.
Les sorties sont à la sortie de la chaîne et sont utilisées pour envoyer des notifications à différents services.

L'ensemble de la chaîne de commandes a généralement la forme:

some_metric | processor_1 | processor_2 ... | cm_p_message | output_1 | output_2 ...

Tout élément de cette chaîne peut être n'importe quelle commande Linux, tant qu'il reçoit des données dans stdin et les envoie à stdout sans mise en mémoire tampon. Il n'y a qu'un seul petit MAIS lié aux sauts de ligne, mais plus à ce sujet plus tard.

Le nom des binaires est formé comme cm_ {type} _ {nom} , où type est l'un des trois: m, p, f ou o , et nom est le nom de la commande.

Par exemple, cm_m_cpu est une métrique qui génère des statistiques sur un processeur au format json vers stdout.

Et le fichier cm_p_debounce est un processeur qui ne laisse sortir qu'un seul message à chaque fois à un intervalle donné.

Il y a un processeur spécial cm_p_message qui doit être devant la première sortie. Il crée un message du format requis pour un traitement ultérieur par ses sorties.

Pour gérer json dans la console et diverses conditions, j'ai utilisé l'utilitaire jq . C'est quelque chose comme sed, seulement pour json.

C'est à quoi ressemble, par exemple, la surveillance du processeur à la fin.

 cm_m_cpu | cm_p_eot2nl | jq -cM --unbuffered 'if .LoadAvg1 > 1 then .LoadAvg1 else false end' | cm_p_nl2eot | cm_f_regex -e '\d+' | cm_p_debounce -i 60 | cm_p_message -m 'Load average is {stdin}' | cm_o_telegram 

Et donc surveiller le nombre de messages dans la file d'attente RabbitMQ

 while true; do rabbitmqctl list_queues -p queue_name | grep -Po --line-buffered '\d+'; sleep 60; done | jq -cM '. > 10000' --unbuffered | cm_p_nl2eot | cm_f_true | cm_p_message -m 'There are more than 10000 tasks in rabbit queue' | cm_o_opsgenie 

Vous pouvez donc contrôler que rien n'a été écrit dans le fichier en 10 secondes

 tail -f out.log | cm_p_nl2eot | cm_p_watchdog -i 10 | cm_p_debounce -i 3600 | cm_p_message -m 'No write to out.log for 10 seconds' -s 'alert' | cm_o_telegram 

Ne vous précipitez pas pour fermer l'écran, nous allons maintenant analyser ce qui se passe ici dans le premier exemple.

1) La métrique cm_m_cpu affiche une fois par seconde (spécifié par le paramètre -i, par défaut une seconde) des chaînes au format json. Par exemple, {"LoadAvg1": 2.0332031, "LoadAvg2": 1.9018555, "LoadAvg3": 1.8623047}

2) cm_p_nl2eot est l' une des commandes utilitaires qui convertit le caractère EOT en caractère LF. Le fait est que pour éviter les problèmes de sauts de ligne, j'ai décidé de m'assurer que tous mes binaires lisent les données jusqu'au caractère ascii EOT (End of Transmission). Cela vous permet de transférer en toute sécurité des données multilignes entre les équipes.

Par conséquent, lorsque d'autres commandes sont appelées, elles doivent être entourées sous la forme:
cm_p_eot2nl | toute autre équipe | cm_p_nl2eot.

3) Ensuite, un appel à l'utilitaire jq , qui vérifie le champ LoadAvg1 et s'il est supérieur à 1, puis l'affiche plus loin, si moins, affiche faux

4) Ensuite, nous devons jeter le message entier faux de la chaîne. Pour ce faire, nous appliquons le filtre cm_f_regex , qui prend une chaîne en entrée, la met en correspondance avec une expression régulière et, dans le cas d'une correspondance, l'affiche davantage. Sinon, la chaîne est simplement supprimée

Le grep ordinaire pourrait être utilisé, mais tout d'abord il met en mémoire tampon la sortie, et la syntaxe complète devient un peu plus longue (grep --line-buffered), deuxièmement cm_f_regex facilite l'affichage des correspondances de groupe. Par exemple:

cm_f_regex -e '(\d+)-(\d+)' -o '{1}/{2}'

Convertit la ligne 123-345 en ligne 123/345

5) Le processeur cm_p_debounce , dans ce cas, prend notre valeur LoadAvg1 et l'affiche plus loin dans la chaîne seulement une fois toutes les 60 secondes. Ceci est nécessaire pour ne pas vous spammer. Vous pouvez définir tout autre intervalle.

6) Presque tout est prêt. Il ne reste plus qu'à former un message et à l'envoyer aux télégrammes. Le message est généré par la commande spéciale cm_p_message . Il accepte simplement une chaîne en entrée, crée json avec les champs Gravité, Message et autres, puis le sort pour le traitement de sortie. Si nous ne lui passions pas l'option -m, alors stdin serait le message, c'est-à-dire le numéro de millet est notre LoadAvg1. Ce n'est pas très informatif.

7) L' équipe cm_o_telegram envoie simplement le message reçu au télégramme. Les paramètres de télégramme sont stockés dans un fichier ini.

La configuration

Tous les paramètres qui acceptent les binaires peuvent être spécifiés dans le fichier ini. Les paramètres spécifiés par l'argument de ligne de commande ont priorité sur le fichier ini.

Le format de fichier init est:

[global]
host_name=override host name for this machine

[telegram]
cid=....
token=....

[opsgenie]
apiToken=...
apiEndpoint=...
......

[debounce]
i=3600

Le fichier ini lui-même est sélectionné dans l'ordre suivant:

1) Le fichier cm.config.ini dans le répertoire de travail courant
2) Le fichier /etc/cm/config.ini si le fichier de l'élément 1 n'est pas trouvé

La production

Sur un vrai serveur, je crée un fichier, par exemple, cpu.sh, dans lequel toute la chaîne de commandes nécessaire est écrite. Ensuite, dans la couronne, je prescris quelque chose comme ceci:

*/5 * * * * flock -n /etc/cm/cpu.lock /etc/cm/cpu.sh > /dev/null

Si quelque chose tombe, le troupeau relancera la commande. Et c'est tout! La simplicité dont je ne manquais pas tant.

C'est un tel outil, peut-être que quelqu'un le trouvera pratique. Pour moi, la commodité est qu'il n'est pas nécessaire de faire beaucoup de choses inutiles juste pour surveiller les choses nécessaires. Et tout est configuré de manière pratique: il a cloné le référentiel, ajouté le chemin d'accès aux fichiers binaires dans $ PATH et c'est tout.

Veuillez ne pas juger strictement. L'outil a été écrit pour moi, l'ensemble des commandes n'est pas encore grand. Mais je serai heureux de toute rétroaction et suggestions. Merci à tous pour votre attention.