Parfois, vous devez effectuer rapidement une surveillance pour un nouveau service, mais il n'y a aucune infrastructure / expertise prête à l'emploi. Dans ce guide, dans une demi-heure, nous mettrons en œuvre un outil pour surveiller tous les services Web en utilisant uniquement les outils Ubuntu intégrés: bash, cron et curl. Nous utiliserons le télégramme pour envoyer des alertes.
"Cerise sur le gâteau" sera l'implication émotionnelle des utilisateurs. Il est vérifié auprès des gens - cela fonctionne.
Lorsque nous avons créé un chatbot dans le service de télémédecine Doctor Near pour déterminer le niveau de stress des utilisateurs, nous avions besoin d'une surveillance. En quelques heures, un mini-projet a été réalisé, qui non seulement fonctionne très bien, mais ajoute également des commentaires positifs.
Pour commencer, obtenez un référentiel avec des scripts:
git clone https://github.com/rshekhovtsov/msms.git
Accédez au dossier msms, puis travaillez-y.
Si le télégramme est bloqué, utilisez un proxy. L'option la plus simple et la plus fiable est le torse:
sudo apt install tor sudo apt install torsocks
Par exemple, nous allons configurer la surveillance de la page de démarrage de google.com en trois étapes.
ÉTAPE 1. Créez un bot dans le télégramme et obtenez l'ID utilisateur
Pour ajouter un nouveau destinataire, vous devez lui demander de démarrer le bot en télégramme, d'exécuter destinataires-setup.sh et d'ajouter l'identifiant au fichier.
ÉTAPE 2. Configurer la surveillance
La description du service se produit en créant un fichier ini dans le dossier des services. Cinq paramètres doivent être définis:
- MSMS_SERVICE_NAME : nom du service - sera utilisé dans les alertes et les journaux de surveillance.
- MSMS_SERVICE_ENDPOINT : le point de terminaison du service sur lequel nous contacterons curl.
- MSMS_CURL_PARAMS : paramètres de boucle supplémentaires, voir l'exemple ci-dessous.
- MSMS_EXPECTED : réponse de service attendue. Utilisé si la réponse est courte.
- MSMS_EXPECTED_FILE : nom de fichier avec la réponse de service attendue. Si spécifié, remplace MSMS_EXPECTED.
- MSMS_RECIPIENTS : fichier avec une liste de destinataires de notification.
La demande sur google.com renvoie un html fixe avec une redirection, nous l'utiliserons comme réponse attendue du serveur:
curl google.com > services/google-response.html
Créez le fichier services / google.ini:
MSMS_SERVICE_NAME='google front page'
Dans
MSMS_CURL_PARAMS vous pouvez spécifier tout ce que la boucle peut faire, y compris:
- DĂ©sactivez les messages curl pour ne pas obstruer la console et consigner:
-s - Définissez le délai de connexion avec le service en cours de vérification (en secondes):
--connect-timeout 3 - Définir le délai de réponse:
-m 7 - Désactivez la vérification des certificats pour SSL (par exemple, si un certificat auto-signé est utilisé):
--insecure - Spécifiez le type de demande http:
-X POST - Spécifiez les en-têtes:
-H "Content-Type: application/json" - Spécifiez le corps de la demande sous forme de chaîne ou de fichier. Exemple de fichier:
-d @request.json
Nous avons désactivé les notifications et défini des délais d'expiration de 3 secondes. à la connexion et 7 sec. pour recevoir une réponse du service.
Attention : spécifiez les valeurs des paramètres entre guillemets simples, comme dans l'exemple. Malheureusement, bash est plutôt fragile dans ce sens, et un
papillon volant accidentellement au mauvais endroit peut entraîner la
mort de l'univers avec des erreurs difficiles Ă diagnostiquer.
Nous avons mis en place un suivi. VĂ©rifiez que tout va bien:
sudo chmod +x ./monitoring.sh torsocks ./monitoring.sh
Le script doit afficher un message de la forme:
2020-01-10 12:14:31 health-check "google front page": OK
ÉTAPE 3. Ajustez l'horaire
Configurer un planning de surveillance dans cron:
sudo crontab -e
Ajoutez une ligne pour vérifier google.com toutes les minutes:
*/1 * * * * torsocks < >/monitoring.sh >> < >/monitoring.log 2>&1
Ajoutez une alerte tous les jours à 11h00, confirmant la surveillance elle-même. Pour ce faire, passez le paramètre DAILY au script:
0 11 * * * torsocks < >/monitoring.sh DAILY >> < >/monitoring.log 2>&1
2>&1 - technique standard de redirection des erreurs vers le flux de sortie principal. En conséquence, ils seront également inclus dans le journal de surveillance.
Enregistrez les modifications et rattrapez-les avec la commande:
sudo service cron reload
Vous pouvez en savoir plus sur la configuration de cron, par exemple,
ici .
Ainsi, chaque minute, un script de surveillance sera lancé, qui sera accessible via gol sur google.com. Si la réponse reçue diffère de la réponse attendue, le script enverra une notification dans le télégramme à la liste des destinataires. Le journal d'audit est conservé dans le fichier monitoring.log
Si vous avez besoin d'ajouter un autre service, nous créons simplement un nouveau fichier ini pour lui dans le dossier des services et, si nécessaire, créons une liste séparée de destinataires. Tout le reste fonctionnera automatiquement.
Si le service vérifié est devenu indisponible, une alerte sera envoyée toutes les minutes. Si vous ne pouvez pas restaurer rapidement le service, vous pouvez désactiver temporairement les notifications dans les propriétés du bot dans le télégramme.
Examinons maintenant de plus près les fonctionnalités supplémentaires et la mise en œuvre des scripts.
Modèles de messages et engagement émotionnel
Pour rendre la communication avec le bot plus vivante, nous l'avons appelé Manechka, ajouté l'avatar d'image correspondant et engagé des spécialistes des relations publiques pour créer des textes de message. Vous pouvez utiliser nos réalisations ou changer à votre goût.
Par exemple, comme ceci:
ou mĂŞme ainsi:
Pourquoi pas?
Le nom du robot et l'avatar sont définis via
@botfather .
Les modèles de message se trouvent dans le dossier des
modèles :
- curl-fail.txt : message envoyé lorsque curl a renvoyé un code d'erreur différent de zéro. Parle généralement de l'impossibilité de tendre la main au service.
- daily.txt : message quotidien confirmant que la surveillance du service fonctionne.
- service-fail.txt : message envoyé lorsque la réponse du service est différente de celle attendue.
Examinons les possibilités de personnalisation à l'aide de l'exemple de modèles de messages intégrés.
Les modèles utilisent des emojis. Malheureusement, habr ne les affiche pas.
Pour sélectionner les emojis, il est pratique d'utiliser la recherche sur
emojipedia.org :
Vous copiez et collez simplement le caractère approprié dans le texte du modèle (c'est l'unicode habituel).
- curl-fail.txt:
, ... \"$MSMS_SERVICE_NAME\" \`CURL EXIT CODE: $EXIT_CODE\`
Nous avons utilisé le nom de service que nous avons spécifié (variable MSMS_SERVICE_NAME ) et une variable de script interne avec le code de terminaison curl ( EXIT_CODE ). Nous avons également formaté le message en utilisant le balisage du télégramme : les caractères `` '' encadrent le texte d'une largeur fixe. Puisque les guillemets et les apostrophes sont des caractères bash officiels, nous leur échappons avec le caractère "\". Les noms de variables sont précédés d'un signe "$".
RĂ©sultat:
- service-fail.txt:
, ... \"$MSMS_SERVICE_NAME\" , : \`$RESPONSE\`
RĂ©sultat:
Ici, nous utilisons une autre variable de script: RESPONSE . Il contient la réponse du service.
- daily.txt:
, ! , c : \"$MSMS_SERVICE_NAME\" ... ?
RĂ©sultat:
Passons à l'implémentation des scripts.
Script de surveillance
monitoring.sh facilite la découverte automatique - prend tous les fichiers ini du dossier services et exécute pour chacun le script principal avec la logique de vérification et d'envoi des alertes:
Pour générer un message quotidien sur l'état de surveillance, le script peut recevoir le paramètre DAILY.
Veuillez noter qu'au démarrage du script, le dossier en cours se transforme en services. Cela permet aux fichiers ini de spécifier les chemins d'accès aux fichiers par rapport aux services.
Script pour vérifier et envoyer des alertes
msms.sh contient la logique de base de la vérification d'un service et de l'envoi d'alertes.
Travailler avec un télégramme:
Nous créons une URL pour accéder à l'API REST du télégramme à l'aide de la clé privée stockée dans le fichier.
La fonction send_message utilise curl pour envoyer des messages à cette API REST, en prenant l'ID du destinataire dans le fichier que nous avons spécifié dans ini. Dans les données que nous envoyons, nous indiquons que nous utilisons le balisage de message:
parse_mode="Markdown" .
Imprimez la date-heure actuelle et chargez le fichier ini.
echo $(date '+%Y-%m-%d %H:%M:%S')
La ligne magique
. $2 . $2 exécute le fichier ini transmis en tant que deuxième paramètre comme un script ordinaire, en entrant les valeurs spécifiées dans les variables d'environnement.
Téléchargez la réponse attendue à partir du fichier si le paramètre
MSMS_EXPECTED_FILE est
MSMS_EXPECTED_FILE :
if [ -n "$MSMS_EXPECTED_FILE" ]; then MSMS_EXPECTED="$(cat "$MSMS_EXPECTED_FILE")" fi
Effectuez une vérification de service avec l'envoi d'alertes, si nécessaire:
RESPONSE="$(eval curl $MSMS_CURL_PARAMS \"$MSMS_SERVICE_ENDPOINT\")" EXIT_CODE=$? if [[ $EXIT_CODE != 0 ]]; then echo health-check \"$MSMS_SERVICE_NAME\" FAILED: CURL EXIT WITH $EXIT_CODE MESSAGE="$(cat ../templates/curl-fail.txt)" MESSAGE=$(eval echo $MESSAGE) send_message "$MESSAGE" elif [[ "$RESPONSE" != "$MSMS_EXPECTED" ]]; then echo health-check \"$MSMS_SERVICE_NAME\" FAILED: "$RESPONSE" MESSAGE="$(cat ../templates/service-fail.txt)" MESSAGE=$(eval echo $MESSAGE) send_message "$MESSAGE" else echo health-check \"$MSMS_SERVICE_NAME\": OK fi
D'abord, nous affectons la variable
RESPONSE au résultat de la commande curl pour ce service.
Expression
EXIT_CODE=$? met le résultat de la dernière commande, c'est-à -dire boucle. Si vous devez envoyer une alerte, le modèle est lu à partir du fichier correspondant et l'envoi aux destinataires se
send_message aide de
send_message .
Le dernier bloc traite le paramètre DAILY:
if test "$1" = "DAILY"; then echo health-check \"$MSMS_SERVICE_NAME\" DAILY MESSAGE="$(cat ../templates/daily.txt)" MESSAGE=$(eval echo $MESSAGE) send_message "$MESSAGE" fi
Il envoie un message confirmant l'intégrité de la surveillance elle-même.
Obtention d'une liste d'ID utilisateur
destinataires-setup.sh appelle l'API de télégramme pour obtenir les derniers messages adressés au bot:
curl -s https://api.telegram.org/bot$(cat telegram-api-key.txt)/getUpdates \ | python recipients-setup.py
Il utilise la magie de python pour bien lister la sortie. Ceci est facultatif, vous pouvez simplement prendre l'id souhaité de json, que la commande affichera:
torsocks curl -s https://api.telegram.org/bot$(cat telegram-api-key.txt)/getUpdates
Conclusion
Ainsi, vous pouvez utiliser des scripts et des modèles de message prêts à l'emploi, en configurant uniquement des services et des listes observables pour les notifications; Vous pouvez créer une nouvelle "identité" pour le bot; et vous pouvez prendre votre décision sur la base de la proposition.
Comme options pour un développement ultérieur, la configuration et la gestion de la surveillance dans le bot lui-même se suggèrent, mais ici, vous ne pouvez pas vous passer de python. Si quelqu'un met la main sur moi - vous savez où télécharger la demande de pull :-)