Comment contrôler simplement l'état du site

Pour surveiller à distance les performances des serveurs, les professionnels utilisent des systèmes logiciels spéciaux, tels que Zabbix ou Icinga . Mais, si vous êtes propriétaire ou administrateur novice d'un ou deux sites Web avec une petite charge, il n'est pas nécessaire d'avoir de grands systèmes de surveillance. Le paramètre principal est de savoir si le site sert rapidement les utilisateurs. Par conséquent, vous pouvez surveiller le travail du site à l'aide d'un simple programme à partir de n'importe quel ordinateur connecté à Internet.



Écrivons ce script maintenant - la surveillance la plus simple de la disponibilité et de la vitesse du site. Ce programme peut être exécuté sur un ordinateur personnel, un smartphone, etc. Le programme n'a que deux fonctions:

• affiche à l'écran le temps pendant lequel votre site donne des pages aux utilisateurs,
• en cas de réponses lentes du site ou d'erreurs, le programme écrit des données dans un fichier (un «log», ou un fichier log). Ces données méritent d'être vérifiées de temps en temps pour résoudre les problèmes au tout début. Par conséquent, nous prendrons soin d'enregistrer ces journaux sous une forme claire et pratique pour une visualisation rapide.

Je décrirai chaque étape en détail afin que même un débutant qui ne connaît que peu l'écriture de fichiers batch (bat et cmd sur DOS et Windows, sh sur des systèmes comme UNIX) puisse le comprendre sans aucun problème et être capable d'adapter le script à ses besoins. Mais je vous demande de ne pas utiliser ce script sans réfléchir, car s'il n'est pas utilisé correctement, il peut ne pas donner de résultats appropriés et, en outre, engloutir beaucoup de trafic .

Je vais décrire un script pour un système d'exploitation tel que Linux et son utilisation sur un ordinateur personnel. Selon les mêmes principes, cela peut se faire sur d'autres plateformes. Et pour ceux qui ne font que regarder les possibilités de Linux, un autre exemple peut être intéressant: quel outil simple et puissant sont ses scripts.

1. L'organisation d'abord

Nous allons créer un dossier séparé pour ce programme et y créer 3 fichiers. Par exemple, j'ai ce dossier / home / me / Progs / iNet / monitor (ici moi est le nom de mon utilisateur, Progs / iNet est mon dossier pour les programmes liés à Internet, et monitor est le nom de ce programme, du mot moniteur, c.-à-d. Étant donné que je suis le seul utilisateur de cet ordinateur, je conserve ces fichiers dans mes dossiers personnels (/ home) dans une section distincte du disque, ce qui me permet de les enregistrer lors de la réinstallation du système). Dans ce dossier, il y aura des fichiers:

• README.txt - voici une description (en cas de sclérose): quel type de programme, informations de base, etc.
• mon.sh - il y aura un programme qui interroge le site.
• server.log - ici, il enregistrera les indicateurs d'état du site. Dans notre cas, il s'agit simplement de la date, de l'heure et de la durée de la réponse du site (plus des informations supplémentaires si le serveur répond avec une erreur à notre demande).

(Pour faciliter l'édition et, le cas échéant, la restauration de fichiers, vous pouvez inclure ce dossier dans le système de contrôle de version de Git; ici, je ne le décrirai pas).

2. Toujours et détendu

Nous exécuterons le fichier mon.sh avec un petit intervalle régulier, par exemple, 60 secondes. J'ai utilisé l'outil standard fourni par le système d'exploitation (plus précisément, l'environnement de bureau).

Mon environnement de bureau est Xfce. C'est l'une des options les plus populaires pour Linux. J'aime Xfce car il vous permet de personnaliser presque complètement l'environnement entier - comme vous le souhaitez. Dans le même temps, Xfce est un peu plus compact et plus rapide que deux autres systèmes bien connus - Gnome et KDE. (D'autres options sont également intéressantes - par exemple, l'environnement LXDE est encore plus rapide et plus facile que Xfce, mais jusqu'à présent pas si riche en fonctionnalités).

L'outil dont nous avons besoin, dans le cas de Xfce, est un plug-in pour le panneau de travail Generic Monitor. Habituellement, il est déjà installé, mais sinon, l'installateur le trouvera facilement: «Genmon» (description: xfce4-genmon-plugin ). Il s'agit d'un plugin qui peut être ajouté au panneau et défini dans les paramètres: (1) la commande à exécuter et (2) la fréquence de son exécution en secondes. Dans mon cas, la commande:

/home/me/Progs/iNet/monitor/mon.sh

(ou, de manière équivalente, ~ / Progs / iNet / monitor / mon.sh).

3. Lorsque le programme n'est pas encore terminé, il y a déjà des erreurs

Si vous avez maintenant terminé toutes ces étapes - créé des fichiers et lancé le plug-in dans le panneau - alors vous voyez le résultat du lancement de notre programme là-bas (message d'erreur: le fichier mon.sh n'est pas un programme). Ensuite, pour rendre le fichier exécutable, accédez à notre dossier et définissez-lui l'autorisation d'exécuter -

• ou gestionnaire de fichiers: Propriétés - Autorisations - Autoriser l'exécution de ce fichier en tant que programme;
• ou une commande du terminal: chmod 755 mon.sh

Et dans le fichier lui-même, nous écrivons les premières lignes:

#!/bin/bash # Monitor server responses (run this every 60 seconds): # info=$(curl -I -o /dev/stdout -w '%{time_total}' --url https://example.ru/ -m 9 -s) errr=$(echo $?) 

Au lieu de "example.ru", remplacez le nom de votre site, dont vous observerez l'état. Et si cela fonctionne sur http, mettez http au lieu de https. La ligne #! / Bin / bash signifie qu'il s'agit d'un script à lancer par le programme Bash ( bash est probablement le plus courant pour exécuter des scripts sous Linux). Pour travailler à travers un autre shell, il est indiqué à la place de Bash. Les lignes restantes avec un pointu au début sont des commentaires. La première ligne de code elle-même est info = $ () et dans ces crochets se trouve la commande curl avec paramètres. Une telle construction - quelque chose = $ (quelque chose) - signifie "exécuter la commande entre crochets et affecter le résultat à la variable de gauche". Dans ce cas, j'ai nommé la variable «info». Cette commande entre parenthèses - curl (dans le jargon désigné par certains comme «Kurl») - envoie une requête au réseau à l'adresse spécifiée et nous renvoie la réponse du serveur. (Ma connaissance a dit, expliquant: "Comment la grue grogne - et reçoit une réponse d'une autre grue dans le ciel.") Considérez les options:

 curl -I -o /dev/stdout -w '%{time_total}' --url https://example.ru/ -m 9 -s 

-Je signifie que nous ne demandons pas la page entière, mais seulement ses "en-têtes HTTP". Chaque fois que nous n'avons pas besoin du texte entier de la page pour nous assurer que le site fonctionne. Étant donné que nous vérifierons souvent le site, il est important de réduire au maximum la taille des données transmises. Cela permet d'économiser du trafic, de l'électricité et de la charge sur le serveur - et de la faune.

Soit dit en passant, faites attention à la quantité de trafic disponible (non utilisé par mois) sur l'hébergement. Ci-dessous, vous verrez combien de données sont transmises et vous pouvez calculer si vous avez suffisamment de réserves; le cas échéant, la période de vérification du site peut être augmentée à 5, 10 ou même 30 à 60 minutes. Bien que dans ce cas, l'image ne sera pas aussi complète - et des interruptions mineures peuvent passer inaperçues; mais, en général, lors de la surveillance d'un site, il est plus important de détecter les problèmes à long terme qu'une seule interruption. De plus, quel trafic pouvez-vous vous permettre sur l'ordinateur appelant? Dans mon cas - un ordinateur de bureau avec un trafic illimité - ce n'est pas si important; mais pour un appareil mobile ou un tarif avec des limites, cela vaut la peine de calculer et, éventuellement, d'augmenter les intervalles d'inspection.

4. L'étape suit l'étape sauf la première étape

Allons plus loin: -o / dev / stdout signifie "envoyer la réponse reçue par Kurl du serveur vers tel ou tel fichier". Et dans ce cas, ce n'est pas un fichier sur le disque, mais / dev / stdout - Périphérique de sortie standard. Habituellement, le «périphérique de sortie standard» est notre écran où nous pouvons voir les résultats du programme. Mais dans le script, nous dirigeons souvent cette «sortie standard» pour un traitement ultérieur (maintenant - enregistrez-la dans la variable info). Et ensuite, le plus souvent, nous enverrons les résultats des équipes à des variables ou les transmettrons aux équipes suivantes d'une chaîne. Pour créer des chaînes à partir de commandes, utilisez l'opérateur de tuyau ("Pipe"), affiché sous la forme d'une barre verticale ("|").

-w '% {time_total} eyayu' : ici -w signifie "formater et donner telle ou telle information supplémentaire à un périphérique de sortie standard." Plus précisément, nous sommes intéressés par time_total - combien de temps la transmission de la demande-réponse entre nous et le serveur a pris. Vous savez probablement qu'il existe une commande plus simple, ping, pour demander rapidement un serveur et en obtenir une réponse, pong. Mais Ping vérifie seulement que le serveur d'hébergement est vivant, et le signal va et vient pendant tant de temps. Cela montre la vitesse maximale d'accès, mais ne nous dit toujours rien sur la rapidité avec laquelle le site produit du contenu réel. Ping peut fonctionner rapidement et, en même temps, le site peut ralentir ou ne pas fonctionner du tout - en raison d'une charge élevée ou de certains problèmes internes. Par conséquent, nous utilisons exactement Kurla et obtenons l'heure réelle à laquelle le serveur affiche notre contenu.

(Et par ce paramètre, vous pouvez juger si le serveur fonctionne efficacement pour vos tâches, si son temps de réponse typique est pratique pour les utilisateurs. Y a-t-il des problèmes - par exemple, mes sites sur de nombreux sites d'hébergement ont ralenti au fil du temps, et j'ai dû chercher un autre hébergement).

Avez-vous remarqué les étranges lettres "eyu" après {time_total}? Je les ai ajoutés en tant qu’étiquette unique, qui ne figurera probablement pas dans les en-têtes qui nous sont envoyés depuis le serveur (bien que en supposant que les utilisateurs de vos programmes seront et ne seront pas mauvais et la route vers l’abîme. Ne faites pas ça! .. Ou, quand vous le faites , au moins avoir honte de vous). Grâce à cette étiquette (j'espère), nous pouvons alors facilement extraire les informations dont nous avons besoin de tout un tas de lignes dans la variable info. Donc, curl -w '% {time_total} ehayu' (avec les paramètres restants corrects) nous donnera quelque chose comme:

0,215238eyayu

C'est le nombre de secondes qu'il a fallu pour accéder au site, plus notre étiquette. (En plus de ce paramètre, dans la variable info, nous serons principalement intéressés par le «Code d'état» - le code d'état, ou, simplement, le code de réponse du serveur. Habituellement, lorsque le serveur émet le fichier demandé, le code est «200». Lorsque la page est introuvable , c'est le fameux 404. Quand il y a des erreurs sur le serveur, c'est le plus souvent 500 avec quelque chose).

5. Créativité - le père de l'auto-test

Les paramètres restants de notre boucle sont les suivants:

 --url https://example.ru/ -m 9 -s 

ce que cela signifie: demander telle ou telle adresse; le temps de réponse maximum est de 9 secondes (vous pouvez définir moins, car un utilisateur rare attendra une réponse du site pendant si longtemps qu'il trouvera rapidement le site ne fonctionne pas). Et "-s" signifie silencieux, c'est-à-dire que curl ne nous dira pas de détails inutiles.

Soit dit en passant, il n'y a généralement pas beaucoup d'espace sur le panneau du bureau, par conséquent, pour déboguer un script, il est préférable de l'exécuter à partir du terminal (dans son dossier à l'aide de la commande ./mon.sh). Et pour notre plugin de panel, nous mettrons une longue pause entre les lancements de la commande - disons, 3600 secondes.

Pour le débogage, nous pouvons exécuter cette boucle sans encadrer les crochets et voir ce qu'elle produit. (À partir de cela et calculer la consommation de trafic). Nous verrons principalement un ensemble d'en-têtes HTTP, tels que:

 HTTP/1.1 302 Found Server: QRATOR Date: Sun, 11 Feb 2019 08:06:57 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Keep-Alive: timeout=15 X-Powered-By: PHP/7.2.14-1+ubuntu16.04.1+deb.sury.org+1 Location: https://habr.com/ru/ X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=63072000; includeSubDomains; preload X-Cache-Status: HIT 0.033113 

La première ligne ici, nous voyons «HTTP / 1.1 302 Found» - ce qui signifie: le protocole de transfert de données est «HTTP / 1.1», le code de réponse du serveur est «302 Found». Lorsque vous demandez une autre page, il peut s'agir du code «301 déplacé en permanence», etc. Dans un autre exemple, la réponse normale de mon serveur est «HTTP / 2 200». Si votre serveur répond normalement différemment, remplacez-le par cette réponse au lieu de «HTTP / 2 200» dans ce script.

La dernière ligne, comme nous le voyons, Kurl donne, en combien de secondes nous avons reçu la réponse du serveur, avec notre étiquette attribuée.

Intéressant: nous pouvons configurer le site pour qu'il rende compte de nos demandes (et uniquement sur elles!) Des informations supplémentaires sur son état - par exemple, dans l'en-tête HTTP "fait maison". Disons quelle est la charge des processeurs du site, combien de mémoire libre et d'espace disque il a, et à quelle vitesse la base de données fonctionne. (Bien sûr, pour cela, le site doit être dynamique, c'est-à-dire que les demandes doivent être traitées par le programme - en PHP, Node.JS, etc. Une autre option consiste à utiliser un logiciel spécial sur le serveur). Mais peut-être que nous n'avons pas encore vraiment besoin de ces détails. Le but de ce script est simplement de surveiller régulièrement les performances globales du site. En cas de problème - nous traiterons déjà le diagnostic par d'autres moyens. Par conséquent, nous écrivons maintenant le script le plus simple qui fonctionnera pour n'importe quel site, même statique, et sans paramètres supplémentaires sur le serveur. À l'avenir, si vous le souhaitez, il sera possible d'étendre les capacités du script; en attendant, faites la base.

La chaîne errr = $ (echo $?) Signifie: écrire le résultat de la commande "echo $?" Dans la variable errr. La commande echo signifie imprimer du texte sur le périphérique de sortie standard (stdout) et les caractères "$?" - Il s'agit du code d'erreur actuel (restant de la commande précédente). Donc, si notre boucle ne peut soudainement pas atteindre le serveur, elle donnera un code d'erreur différent de zéro, et nous le découvrirons en vérifiant la variable errr.

6. Opportunité

Ici, je veux faire une petite digression des questions techniques pour rendre la lecture du texte plus intéressante. (Si vous n'êtes pas d'accord, sautez trois paragraphes). Je dirai que toute activité humaine est appropriée à sa manière. Même lorsqu'une personne frappe intentionnellement son front contre un mur (ou sur le sol ... sur le clavier ...), cela a sa propre opportunité. Par exemple, il fournit un débouché pour l'énergie émotionnelle - peut-être pas de la «meilleure» manière, mais comment cela peut. (Oui, et le concept même de "meilleur" est inutile du point de vue de ce moment dans cet endroit - parce que le meilleur et le pire ne sont possibles qu'en comparaison avec autre chose).

J'écris ce texte maintenant, au lieu de cas apparemment plus importants pour moi - pourquoi? Tout d'abord, afin de faire le point, de passer en revue et de trier en interne ce que j'ai appris en écrivant des scripts au cours de ces deux jours ... Retirez-le de la RAM et stockez-le. Deuxièmement, de cette façon, je me repose un peu ... Troisièmement, j'espère que cette explication mâchée sera utile à quelqu'un d'autre (et à moi-même, peut-être un jour). Comment, peu importe s'il s'agit du meilleur rappel, mais distinct au sujet des scripts et des demandes de serveur.

Quelqu'un me corrigera peut-être quelque chose et le résultat deviendra encore meilleur. Quelqu'un recevra une information utile. Est-ce approprié? Peut-être ... c'est ce que je peux faire maintenant et je le fais. Demain, je vais peut-être me réveiller et réévaluer les actions en cours ... mais cette réévaluation fournira également quelque chose d'utile pour la vie future.

Ainsi, une fois la demande satisfaite, nous avons deux données:

• le bloc principal d'informations provenant du serveur (si, bien sûr, la réponse du serveur est venue), nous l'avons écrit dans la variable info;
• code d'erreur de la commande curl (0, si aucune erreur) - écrit dans la variable errr.

Précisément parce que les deux totaux - à la fois des informations et un code d'erreur - sont nécessaires, je les ai écrits dans des variables et je n'ai pas immédiatement transmis les totaux de Kurl à d'autres équipes via le canal. Mais maintenant, dans ce script, il est temps de grimper les tuyaux:

 code=$(echo "$info" | grep HTTP | grep -v 'HTTP/2 200') date=$(echo "$info" | grep -i 'date:') dlay=$(echo "$info" | grep  | sed -e 's///') 

Dans chacune de ces lignes, nous écrivons une autre variable - nous enregistrons les résultats de l'exécution des commandes. Et dans chaque cas, ce n'est pas une équipe, mais une chaîne; le premier lien est le même partout: echo "$ info" - renvoie au flux du périphérique de sortie standard (stdout) le bloc d'informations que nous avons enregistré, reçu de curl. Plus loin dans le tuyau, ce flux est transmis à la commande grep. Grep sélectionne parmi toutes les lignes uniquement celles dans lesquelles il correspond au motif. (L'option -i signifie "insensible à la casse"). Comme vous pouvez le voir, dans le premier cas, nous sélectionnons la ligne contenant "HTTP". Cette ligne, tirée du tas du reste, est transmise par le canal à la commande grep -v 'HTTP / 2 200' . Ici, l' option -v est l'opposé de l'option -e , elle filtre les lignes où se trouve un tel modèle. Total, dans la variable de code, il y aura une ligne avec le code de réponse du serveur (tel que «HTTP / 1.1 302 trouvé»), mais uniquement s'il ne s'agit pas de «HTTP / 2 200». Je filtre donc les lignes que mon site envoie dans le cas normal, et ne sauvegarde que les réponses "anormales". (Si vous avez une réponse normale du serveur, remplacez-la ici).

De même, dans la date variable, nous écrivons la ligne dans laquelle le serveur a publié sa date et son heure actuelles. C'est quelque chose comme " date: dim, 11 fév 2019 08:06:57 GMT " (généralement dans le fuseau horaire GMT, alias UTC). Nous devons écrire la date (mais seulement une fois par jour!) Dans notre fichier journal ("journal d'état du serveur") - server.log. Et en même temps, nous afficherons cette fois sur l'écran. Vous pouvez écrire une date-heure dans le journal depuis votre ordinateur, mais pour plus de commodité, nous les prenons, car le serveur les a quand même envoyées.

Il en va de même pour notre troisième variable, dlay (du mot anglais delay - delay). Nous sélectionnons la ligne dans notre étiquette d'appel d'offres "eeyu" dans laquelle nous avons gardé la durée d'attente d'une réponse du serveur. Nous supprimons cette étiquette, qui n'est plus nécessaire, à l'aide de la commande sed - et enregistrons le résultat.

Maintenant, si nous imprimons ces variables pour vérification - par exemple, en ajoutant les lignes à notre script:

 printf 'errr: %s\n' "$errr" printf 'code: %s\n' "$code" printf '%s\n' "$date" printf 'dlay: %s\n' "$dlay" 

vous devriez obtenir quelque chose comme:

 errr: 0 code: date: Mon, 11 Feb 2019 12:46:18 GMT dlay: 0.236549 

Total: le code d'erreur de curl est zéro (ce qui signifie qu'il a bien fonctionné). Code d'état du serveur - non enregistré (comme c'était normal). Date et heure. La durée de la réponse. Il reste à afficher correctement ce dont vous avez besoin à l'écran et, si nécessaire, à écrire dans un fichier.

C'est le plus intéressant: quoi, dans quelles conditions et comment enregistrer?

7. Conclusions délicates

Afin de ne pas vous ennuyer avec plus de détails, je vais vous le dire brièvement (et il y a suffisamment de bons répertoires sur toutes ces commandes sur Internet). Soit dit en passant, la brièveté est l'un des principaux objectifs que nous atteindrons en écrivant dans ce journal. Ensuite, il sera pratique pour la visualisation et ne prendra jamais beaucoup d'espace disque (contrairement aux autres journaux qui augmentent en mégaoctets par jour).

Premièrement: nous nous assurons d'écrire la date dans le journal une seule fois, et non sur chaque ligne. Pour ce faire, sélectionnez individuellement dans notre date variable la date actuelle (curr) et l'heure (time):

 curr=$(echo "$date" | sed -e 's/\(20[0-9][0-9]\).*$/\1/') time=$(echo "$date" | sed -e 's/^.*\ \([0-9][0-9]:.*\)\ GMT\r$/\1/') 

Et nous considérons également les lignes avec les dates du fichier journal et prenons la dernière date (précédent):

 prev=$(cat /home/me/Progs/iNet/monitor/site.log | grep -e 'date:' | tail -1) 

Si notre date actuelle (curr) n'est pas égale à la précédente (du fichier, prev), alors un nouveau jour est venu (ou, disons, le fichier journal était vide); puis écrivez la nouvelle date dans le fichier:

 if [[ $curr != $prev ]]; then printf '%s\n' "$curr" >>/home/me/Progs/iNet/monitor/site.log printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log 

... et en même temps nous enregistrons les informations actuelles: heure, délai de réception d'une réponse du site, code de réponse du site (si ce n'est pas ordinaire):

  printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log 

Cela vous aidera à naviguer: telle ou telle journée a commencé avec telle ou telle vitesse du site. Dans d'autres cas, n'encombrons pas le fichier avec des entrées inutiles. Bien sûr, nous l'écrirons si nous obtenons un code d'état de serveur inhabituel:

 elif [[ -n $code ]]; then printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log 

Et aussi écrire si le temps de réponse du serveur est plus long que d'habitude. Mon site était généralement responsable de 0,23 à 0,25 seconde, donc j'enregistre les réponses qui ont pris plus de 0,3 seconde:

 elif (( $(echo "$dlay > 0.3" | bc -l) )); then printf '%s %s\n' "$time" "$dlay" >>/home/me/Progs/iNet/monitor/site.log 

Enfin, une fois par heure, j'enregistre simplement l'heure reçue du serveur - comme signe qu'il est vivant, et en même temps comme une sorte de balisage du fichier:

 else echo "$time" | grep -e :00: | cat >>/home/me/Progs/iNet/monitor/site.log fi 

Nous obtenons le contenu du fichier où le balisage avec les enregistrements horaires aide visuellement, sans lire, pour voir quand la charge est supérieure ou inférieure (plus d'enregistrements par heure):

 19:42:28 0.461214 19:53:29 0.443956 20:00:29 20:09:30 2.156462 20:10:29 0.358294 20:45:29 0.313378 20:51:30 0.563886 20:54:30 0.307219 21:00:30 0.722343 21:01:30 0.310284 21:09:30 0.379662 21:10:31 1.305779 21:12:35 5.799455 21:23:31 1.054537 21:24:31 1.230391 21:40:31 0.461266 21:42:37 7.140093 22:00:31 22:12:37 5.724768 22:14:31 0.303500 22:42:37 5.735173 23:00:32 23:10:32 0.318207 date: Mon, 11 Feb 2019 00:00:34 0.235298 00:01:33 0.315093 01:00:34 01:37:41 5.741847 02:00:36 02:48:37 0.343234 02:56:37 0.647698 02:57:38 1.670538 02:58:39 2.327980 02:59:37 0.663547 03:00:37 03:40:38 0.331613 04:00:38 04:11:38 0.217022 04:50:39 0.313566 04:55:45 5.719911 05:00:39 

Et enfin, nous affichons des informations sur l'écran. Et aussi, si curl a échoué, nous affichons et écrivons un message à ce sujet (et en même temps exécutons Ping et connectez-vous pour vérifier si le serveur est vivant):

 printf '%s\n%s\n%s' "$time" "$dlay" "$code" if (( $errr != 0 )); then date >>/home/me/Progs/iNet/monitor/site.log date printf 'CURL Request failed. Error: %s\n' "$errr" >>/home/me/Progs/iNet/monitor/site.log printf 'CURL Request failed. Error: %s\n' "$errr" pung=$(ping -c 1 178.248.237.68) printf 'Ping: %s\n----\n' "$pung" >>/home/me/Progs/iNet/monitor/site.log printf 'Ping: %s\n' "$pung" fi 

Remplacez l'adresse IP dans la chaîne de ping par la véritable adresse IP de votre site.

8. Postface

Le résultat du travail:



Sur la gauche du panneau, vous pouvez voir l'heure en UTC et la réactivité actuelle du site. A droite se trouve le journal: il est visible au rallye, même avec un défilement rapide, pendant quelles heures la charge était plus ou moins. Vous pouvez également remarquer des réponses anormalement lentes (pics; bien qu'il ne soit pas encore clair d'où ils viennent).

C’est tout. Le script s'est avéré être simple, chêne, et il peut être amélioré: travail sur l'optimisation, la portabilité, l'amélioration des notifications et des affichages, en tenant compte du proxy et du cache ...

Mais déjà dans ce type de programme, il peut probablement donner une idée de l'état de votre site. Et que ce soit un site judicieusement approprié, utile aux gens et à toutes les créatures!



PS. Suite à la discussion (le 02/12/2019):

Comme je l'espérais, les experts ont écrit de nombreux commentaires intéressants.

Après y avoir réfléchi, je peux répondre à la question rsashka , quel est l'avantage de ce script.

D'autres outils, tels que NetData (merci à tchspprt pour l'astuce!), Fournissent un large éventail de données qui ne seront pas stockées longtemps. NetData est un bon outil lorsque vous travaillez tous les jours, entretenez des sites Web de manière professionnelle. Bon pour diagnostiquer les problèmes actuels.

Un script comme le mien est de garder un œil sur tout en faisant d'autres choses. Le script ne nécessite pas d'étude et de paramètres spéciaux. Ce n'est pas mauvais pour les laïcs. Et ses journaux prennent si peu de place qu'ils ne peuvent pas être effacés du tout. Ils peuvent s'accumuler au fil des années, et au cours des années N + 1, vous pouvez voir: "Wow, en 2019, mon temps de réponse était une fois et demie plus bas! .."

Autrement dit, une telle solution a sa propre niche - principalement pour les administrateurs non-système en permanence. (Comme le dit tchspprt : "Il s'agit de comment nourrir le chat d'un voisin en vacances").

andreymal a conseillé une manière intéressante de prendre en compte puis de visualiser la charge du site, sans fonds supplémentaires, simplement via les journaux d'accès sur le site. Et vous pouvez y créer de superbes graphismes. Je vais probablement essayer cette option et publier sur Github ce qui s'est passé.

Unforgiven a conseillé une autre solution intéressante - probablement une solution simple (installez prometheus, blackbox et alermanager via docker composer). Sur mon VPS simple et bon marché ne suffit pas pour cette mémoire; et Linux avec un ancien noyau - Docker ne démarre pas. Mais merci pour l'option!

Un autre conseiltchspprt : Graphite + Prométhée + Grafana. Ou fournissez au script de superbes graphismes (gnuplot ou rrdtool).

Mcalexvrn recommande un outil simple: uptimerobot . Je vous remercie!

Je remercie tout le monde pour un tel éventail d'informations! Qu'il soit utile aux gens ...