Il y a deux ans, j'avais déjà écrit un article Un failover simple pour un site web sur okerr. Le projet a maintenant progressé et j'ai également publié le code source de la partie serveur d'okerr d'être sous une licence ouverte, c'est pourquoi j'ai décidé d'écrire sur Habr ce petit aperçu.

À qui cela peut-il intéresser

Cela pourrait vous intéresser si vous travaillez en petite équipe ou même seul. Vous n'avez pas de système de surveillance et vous n'êtes pas sûr s'il est vraiment nécessaire. Ou bien vous avez essayé un logiciel de surveillance populaire et sérieux « pour les grands » mais cela ne vous a pas vraiment convaincu, ou il fonctionnait en configuration presque par défaut sans vraiment changer votre vie. Et aussi — si vous n'envisagez pas de consacrer un employé entier (voire un département) à surveiller le tableau de bord ou à le configurer pendant même quelques heures par jour.

Qu'est-ce qui rend okerr atypique

Je vais maintenant vous montrer les fonctionnalités intéressantes d'okerr qui le distinguent de certains autres services de surveillance.

Okerr est un service de surveillance hybride

Lors de la surveillance interne, un « agent » tourne sur les machines surveillées, transmettant des données au serveur de surveillance (par exemple, l'espace disque libre). Dans le cas de la surveillance externe, le serveur effectue des vérifications sur le réseau (par exemple, ping ou accessibilité du site web). Chaque approche a ses propres limites. Okerr utilise les deux options. Les vérifications à l'intérieur des serveurs sont réalisées par un agent très léger (30Ko) ou par vos propres scripts et applications, tandis que les vérifications réseau se font grâce aux capteurs okerr dans différents pays.

okerr n'est pas seulement un logiciel, mais aussi un service

La partie serveur de toute surveillance est grande et complexe, difficile à installer et à configurer, et elle nécessite des ressources. Avec okerr, vous pouvez mettre en place votre propre serveur de surveillance (il est gratuit et open source), ou vous pouvez simplement utiliser la partie client et profiter du service de notre serveur. Également gratuit.

Si la surveillance permet de compenser, de pallier le manque de fiabilité des serveurs et des applications, se pose alors une question philosophique : qui surveille le gardien ? Comment la surveillance nous informera-t-elle d'un problème si elle-même « meurt » pour une raison quelconque, seule ou avec d'autres de vos ressources (par exemple, si la connexion au data center tombe) ? Avec le service externe okerr, ce problème est résolu : vous recevrez une alerte même si tout le data center avec vos serveurs est sans électricité ou subit une attaque de zombies.

Bien sûr, il y a un risque que le serveur okerr soit lui-même inaccessible, c'est vrai (comme on le sait, 90 % de la fiabilité s'obtient souvent simplement et « gratuitement », 99 % — avec un minimum d'efforts, et chaque chiffre supplémentaire est exponentiellement plus difficile). Mais, d'une part, la probabilité de cela est plus faible, et d'autre part, le problème ne peut passer inaperçu que si cela coïncide dans le temps avec des problèmes sur nos serveurs. Si nous avons une fiabilité de 99,9 % et que vous avez 99,9 % (ce ne sont pas des chiffres très élevés), alors la chance d'une panne non détectée — c'est 0,1 % de 0,1 % = 0,0001 %. Ajouter trois neuf de fiabilité presque sans efforts et sans coûts — c'est plutôt bien !

Un autre avantage du monitoring en tant que service est que le fournisseur d'hébergement ou le studio web peut installer un serveur okerr et offrir l'accès aux clients comme un service supplémentaire payant ou gratuit. Vos concurrents n'ont qu'un hébergement et des sites — et vous avez un hébergement fiable avec surveillance.

Okerr — c'est à propos des indicateurs

Un indicateur — c'est une « ampoule ». Il a deux états principaux — vert (OK) ou rouge (ERR). Dans le projet — il y a de nombreux indicateurs regroupés (par exemple, par serveurs). Sur la page principale du projet, vous voyez immédiatement si tout est vert (et vous pouvez fermer) ou si quelque chose clignote en rouge et doit être corrigé. Lors du passage entre ces états, une notification est envoyée. Une fois par jour, pendant que vous configurez, un résumé du projet est envoyé.

Chaque indicateur okerr a des conditions intégrées selon lesquelles il change d'état (dans Zabbix, cela s'appelle un trigger). Par exemple, la charge moyenne ne doit pas dépasser 2 (bien sûr, cela peut être configuré). Et pour chaque vérification interne (charge moyenne, espace disque libre, …) — il y a un watchdog. Si, pour une raison quelconque, nous n'avons pas reçu de confirmation réussie dans le temps imparti — une erreur est enregistrée et une alerte est envoyée.

Notre processus habituel commence par une vérification matinale des e-mails, où nous consultons le résumé (nous fixons son heure au début de la journée). Si tout est en ordre, nous nous occupons d'autres tâches importantes (mais nous pouvons rapidement consulter le tableau de bord d'okerr pour être sûrs que tout est toujours au vert). En cas d'alerte, nous réagissons.

Bien sûr, il est possible de maintenir des indicateurs « d'information » (pour voir l'état du réseau à partir de la surveillance), mais tout a été conçu pour que les indicateurs soient simples, faciles et rapides à créer pour la surveillance automatique et l'envoi d'alertes.

Le but pour lequel vous configurez okerr réside dans les alertes, afin que vous puissiez en une minute créer un indicateur. Celui-ci peut rester « inactif » pendant un an, simplement recevoir des mises à jour, et lorsque quelque chose casse un an plus tard, il s'allume et envoie une alerte. La minute que vous avez passée à créer cet indicateur a porté ses fruits ; vous avez su immédiatement qu'il y avait un problème, avant tout le monde. Il se peut même que vous ayez réparé le problème avant que quelqu'un ne s'en rende compte. Ce qui est rapidement relevé n'est pas considéré comme tombé !

Sécurité

Ce serait dommage si vous mettez en place une surveillance pour améliorer la fiabilité, et que finalement — vous êtes attaqué à travers elle, car il y a de nombreuses vulnérabilités réseau dans divers outils de surveillance.Zabbix, Nagios).

L'agent (okerrmod du package okerrupdate), qui fonctionne sur le système — ce n'est pas un serveur réseau, mais un client. Par conséquent, il n'y a pas de ports ouverts supplémentaires sur le serveur surveillé, le client fonctionne facilement derrière un pare-feu ou un NAT et il est très difficile (je dirais « impossible ») de le pirater via le réseau, car il n'écoute tout simplement pas de socket réseau.

Couverture complète de la surveillance

Actuellement, nous avons la règle suivante — nous apprenons tous les problèmes techniques grâce à okerr. Si jamais cette règle est violée (okerr ne prévient pas de son imminence (si possible) ou qu'il est déjà là) — nous ajoutons des vérifications dans okerr.

Vérifications externes

Un ensemble assez typique :

ping
statut http
vérification de la validité et de la fraîcheur du certificat SSL (préviendra si la date d'expiration approche)
port TCP ouvert et la bannière qui y est associée
http grep (une certaine texte [ne] doit pas se trouver sur la page)
hash sha1 pour détecter les modifications de la page.
DNS (l'enregistrement DNS doit avoir une certaine valeur)
WHOIS (préviendra si le domaine arrive bientôt à expiration)
Antispam DNSBL (vérification de l'hôte sur plus de 50 listes noires anti-spam)

Vérifications internes

C'est aussi un ensemble assez typique (mais facilement extensible).

df (espace libre sur les disques)
load average
opentcp (sockets TCP à l'écoute ouverts — vous avertira si quelque chose a démarré ou s'est arrêté)
uptime — simplement le temps de disponibilité du serveur. Vous avertira s'il change à la baisse (c'est-à-dire si le serveur est redémarré)
client_ip
dirsize — nous l'utilisons pour surveiller quand nos rootfs de machines virtuelles dépassent la taille autorisée, sans appliquer de restrictions rigides, ainsi que pour les tailles des répertoires personnels des utilisateurs.
empty et nonempty — surveillent les fichiers qui doivent être vides (ou non vides). Par exemple, le fichier error log du serveur okerr — doit être vide, et s'il contient même une ligne, je recevrai une notification et vérifierai. En revanche, mail.log sur le serveur de messagerie ne doit pas être vide (après N minutes après la rotation). Parfois, il était vide après une mise à jour système, quand logrotate ne pouvait pas redémarrer rsyslog correctement.
linecount — nombre de lignes dans un fichier (comme wc -l). Nous l'utilisons comme un remplacement plus doux pour empty, lorsque le error log peut quand même croître, mais lentement (par exemple, chez nous, Googlebot s'acharne sur certaines pages fermées). Il y a une limite de 2 lignes en 20 minutes. Si cela dépasse, il y aura une alerte.

Vérifications internes intéressantes

Si à ce stade vous avez lu « en diagonale », il sera maintenant plus intéressant de lire plus attentivement.

backups

Surveille les sauvegardes dans le répertoire. Nous nommons les fichiers de sauvegarde comme « ServerName-20200530.tar.gz ». Pour chaque serveur, un indicateur ServerName-DATE.tar.gz est créé dans okerr (la date réelle est remplacée par la ligne « DATE »). Cela surveille à la fois la présence d'une nouvelle sauvegarde et sa taille (par exemple, elle ne peut pas être inférieure à 90 % de la sauvegarde précédente).

Que faut-il faire pour qu'une nouvelle sauvegarde commence à être suivie, une fois que nous avons commencé à la créer et à la déposer dans ce répertoire ? Rien ! C'est une approche très pratique, lorsqu'il faut faire « rien », parce que :

Faire « rien » — c'est assez rapide, cela fait gagner du temps.
Il est difficile d'oublier de faire « rien ».
Il est difficile de faire « rien » de manière incorrecte, avec erreur. Rien — c'est la méthode la plus fiable.

Si jamais des fichiers de sauvegarde récents cessent d'apparaître — il y aura une alerte. Si, par exemple, vous avez désactivé l'un des serveurs, et qu'il ne devrait plus y avoir de sauvegardes — vous devrez supprimer l'indicateur (via l'interface web ou depuis le shell via l'API).

maxfilesz

Surveille la taille des plus gros fichiers (généralement : /var/log/*). Cela permet de détecter des problèmes imprévus, comme des tentatives de piratage par mot de passe ou l'envoi de spam via le serveur.

runstatus/runline

Ce sont deux modules proxy importants pour exécuter d'autres programmes sur le serveur. Runstatus indique le code de sortie du programme. Par exemple, dans okerr, il n'y a pas (pas besoin) d'un module pour vérifier que les services systemd fonctionnent. Cela se fait via runstatus (voir ci-dessous). Runline — indique au serveur la ligne que le programme fournit. Par exemple, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" dans la config de Runline sur notre serveur, crée un indicateur servername:temp avec la température du processeur.

sql

Exécute une requête numérique sur MySQL et communique le résultat à l'indicateur. Dans le cas le plus simple, on peut faire, par exemple, «SELECT 1» — cela vérifiera que la base de données fonctionne globalement.

Mais une application beaucoup plus intéressante serait, par exemple, de suivre le nombre de commandes dans une boutique en ligne. Si vous savez que vous avez 100 commandes par heure, vous pouvez définir une limite minimale à 100 ou 80. Ainsi, si soudainement vos ventes chutent — vous recevrez une alerte et pourrez y remédier.

Remarquez — peu importe pour quelle raison imprévisible cela s'est produit :

Le serveur est simplement inaccessible (hors tension ou hors réseau), et l'alerte est venue du fait que l'indicateur «a expiré».
Le serveur est chargé, fonctionne lentement ou perd des paquets, les utilisateurs sont frustrés et repartent sans acheter.
Le serveur est sur des listes de spam et les e-mails de lui ne sont pas acceptés, les utilisateurs ne peuvent pas s'inscrire.
Le budget de la campagne publicitaire est épuisé, les bannières ne s'affichent plus.

Il peut y avoir de nombreuses raisons, et on ne peut pas toutes les prévoir à l'avance, et techniquement il est difficile de les suivre. Mais il est facile de surveiller un paramètre final (les commandes) et de déterminer à partir de là si la situation est suspecte et mérite d'être examinée.

Indicateurs logiques

Permet d'utiliser des expressions logiques (syntaxe Python) via le module evalidate(un article sur Habré). Pour l'expression, les données du projet et de ses indicateurs sont accessibles. Par exemple, dans le chapitre sur le contrôle SQL ci-dessus, vous avez peut-être remarqué une faiblesse — pendant la journée, nous pouvons avoir environ 100 ventes par heure, mais la nuit, seulement 20, et c'est normal, pas un problème. Que faire ? L'indicateur va constamment paniquer la nuit.

Vous pouvez créer deux indicateurs, un diurne et un nocturne. Les deux peuvent être «silencieux» (ils n'enverront pas de notifications). Et créer un indicateur logique qui exige que l'indicateur diurne soit OK avant 20h00, et après 20h00, il suffit que l'indicateur nocturne soit OK.

Un autre exemple d'utilisation d'un indicateur logique est l'escalade. Par exemple, le chef de projet se désinscrit des alertes (ce n'est pas nécessaire pour lui, les administrateurs doivent réagir aux problèmes courants), mais il s'inscrit à un indicateur logique qui devient rouge si un quelconque indicateur du projet n'est pas corrigé dans le temps imparti.

De plus, il est possible de définir un temps autorisé pour les travaux, par exemple, de 3h à 5h du matin. Nous ne nous soucions pas si les serveurs et les sites « tombent » à ce moment-là. Mais à 5h00, ils doivent fonctionner. S'ils ne fonctionnent pas à tout autre moment, une alerte se déclenche. De même, l'indicateur logique permet de prendre en compte la redondance des serveurs. Si vous avez 5 serveurs web, les administrateurs peuvent éteindre 1 à 2 serveurs à tout moment. Mais si moins de 3 sur 5 serveurs sont en service, une alerte sera générée.

Les exemples ci-dessus ne sont pas des fonctions d'okerr, pas des caractéristiques à activer et configurer. Toutes ces fonctionnalités ne sont pas disponibles dans okerr, mais il y a un module logique qui permet de mettre en œuvre cette fonctionnalité (En gros, comme dans un langage de programmation — si nous avons des opérateurs arithmétiques, il n'est pas nécessaire d'avoir une fonction spéciale dans le langage pour calculer 20% de TVA, on peut toujours le faire soi-même selon ses besoins).

L'indicateur logique est probablement l'un des rares sujets relativement complexes dans okerr, mais la bonne nouvelle est que vous n'avez pas besoin de les maîtriser tant qu'un besoin ne se fait pas sentir. Cependant, ils étendent considérablement les possibilités tout en gardant le système lui-même assez simple.

Ajout de vos propres contrôles

Je voudrais vraiment faire passer le message que okerr n'est pas un ensemble de mille contrôles prêts à l'emploi pour toutes les situations, mais au contraire — avant tout — un moteur simple avec une possibilité simple de créer vos propres vérifications. Créer vos propres vérifications dans okerr n'est pas une tâche pour des hackers, des co-développeurs du système, ou même des utilisateurs avancés d'okerr, mais une tâche réalisable pour tout administrateur qui a installé Linux pour la première fois il y a un mois.

Les vérifications de base sont réalisées via le module runstatus:

Cette ligne dans la configuration runstatus enverra une notification si jamais /bin/true ne démarre pas ou renvoie un code autre que 0.

true_OK=\/bin\/true

Une seule ligne — et voilà, nous avons déjà un peu élargi la fonctionnalité d'okerr.

Même une telle vérification a déjà sa valeur : si jamais votre serveur tombe en panne, l'indicateur correspondant sur le serveur okerr ne sera pas mis à jour à temps et, après un certain temps, une alerte apparaîtra.

Cette vérification vous alertera que le serveur apache2 est tombé (on ne sait jamais...) :

apache_OK="systemctl is-active --quiet apache2"

Donc, si vous maîtrisez n'importe quel langage de programmation, vous pouvez au moins écrire des scripts shell — vous pouvez déjà ajouter vos propres vérifications.

Plus compliqué — vous pouvez écrire (dans n'importe quel langage) votre propre module pour okerrmod. Dans le cas le plus simple, il ressemble à ceci :

#!/usr/bin/python3

print("STATUS: OK")

Ce n'est pas si compliqué, n'est-ce pas ? Le module doit effectuer la vérification elle-même et afficher les résultats sur STDOUT. Un module plus compliqué donne, par exemple, ceci :

$ okerrmod --dump df
NAME: pi:df-\
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G\/28.2G utilisés, 13.0G libres
STATUS: 49.52

NAME: pi:df-\/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M\/62.9M utilisés, 9.9M libres
STATUS: 84.32

Il met à jour plusieurs indicateurs en même temps (séparés par une ligne vide), crée des indicateurs si nécessaire, indique les détails de la vérification et les tags pour retrouver facilement les indicateurs dans le tableau de bord.

Il y a un bot Telegram @OkerrBot. Vous n'avez pas besoin d'encombrer votre téléphone avec des applications séparées (je n'aime pas non plus, qu'il faille une application pour Pyaterochka, une autre pour Lenta, une troisième pour MTS, et ainsi de suite pour tout le monde). Un seul Telegram — c'est suffisant. Via Telegram, vous pouvez recevoir des alertes immédiatement, vérifier le statut du projet et donner l'ordre de revérifier tous les indicateurs problématiques. Vous sortez du théâtre\/avion, n'avez pas tenu le pouls pendant deux heures, allumez Telegram, appuyez sur un bouton dans le chatbot et assurez-vous que tout va bien.

Pages de statut

De nos jours, les pages de statut sont presque indispensables pour toute entreprise ayant des IT, un engagement envers la fiabilité et un respect pour ses clients\/utilisateurs.

Imaginez la situation : un utilisateur souhaite faire quelque chose, consulter des informations ou passer une commande, et rien ne fonctionne. Il ne sait pas d'où vient le problème, de quel côté il est et quand il sera résolu. Peut-être que votre site est tout simplement hors service ? Ou qu'il est en panne depuis six mois et qu'il ne sera réparé que dans deux ans ? Pourtant, il doit acheter son réfrigérateur maintenant, il est déjà dans le panier... Et c'est tout à fait différent lorsque l'utilisateur voit que quelque chose ne va pas de votre côté (au moins, il est clair que le problème ne vient pas de lui), que le problème a été identifié, que vous travaillez déjà dessus et qu'un temps de réparation approximatif a peut-être même été communiqué. L'utilisateur peut s'abonner et recevoir un avis par e-mail lorsque le problème sera résolu et qu'il pourra faire ce qu'il voulait (acheter son réfrigérateur).

Des problèmes et des temps d'arrêt, cela arrive à tout le monde. Cependant, les utilisateurs et partenaires font davantage confiance à ceux qui sont plus transparents et qui abordent ces situations avec responsabilité.

Voici aperçu de 10 autres projets qui permettent de créer des pages d'état. Voici des exemples de la manière dont ces pages apparaissent dans des projets Python et Dropbox. Page d'état okerr.

Basculement

Pour ne pas alourdir cet article encore plus, je renverrai à mon article précédent — Un failover simple pour un site web . Si vous pouvez créer un serveur de secours, avec un système de basculement, vous n'aurez généralement pas de longs temps d'arrêt — une fois le problème détecté, les utilisateurs seront automatiquement redirigés vers le serveur de secours fonctionnel. Et cela me semble être une fonctionnalité très intéressante et unique, qui est peu courante.

Exigences système faibles

Pour les serveurs okerr — nous utilisons des machines avec 2 Go de RAM. Pour les capteurs réseau, même 512 Mo suffisent. La partie cliente — presque rien. (Le paquet okerrupdate pèse 26 Ko, mais nécessite Python3 et des bibliothèques standard). Le client s'exécute à partir d'un script cron, il consomme donc zéro mémoire de façon continue. Parmi les machines surveillées, nous avons des capteurs (super VPS bon marché de 512 Mo RAM) et des Raspberry Pi. On peut même envoyer des mises à jour sans la partie cliente via curl! (voir ci-dessous)

Compte tenu de cela — okerr est probablement le plus gratuit Un système de surveillance existant, car même pour utiliser un autre système open source gratuit comme Zabbix ou Nagios, il faut lui allouer des ressources (serveur), ce qui coûte de l'argent. De plus, un certain entretien du serveur est requis. Avec okerr, cet aspect peut être écarté. Vous pouvez également choisir de ne pas l'éliminer et d'utiliser votre propre serveur — selon ce qui vous convient le mieux.

API et intégration dans vos propres logiciels

Une architecture simple et ouverte. Okerr dispose d'une architecture assez simple API, facile à manipuler. Vous avez besoin de créer 1000 indicateurs ? Un script shell de 3-4 lignes suffira. Vous devez reconfigurer 1000 indicateurs ? C'est tout aussi simple. Par exemple, nous voulons vérifier à nouveau tous nos certificats HTTPS avec un capteur basé en Russie :

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

Vous pouvez mettre à jour un indicateur en utilisant notre module client, ou même sans lui, simplement via curl.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

Il est possible de mettre à jour les indicateurs directement depuis votre programme. Par exemple, en envoyant des signaux heartbeat pour que okerr sache qu'il est en marche, et pour déclencher une alarme s'il tombe ou se fige. D'ailleurs, les composants okerr fonctionnent ainsi — okerr surveille lui-même, et les problèmes dans presque n'importe quel module seront détectés et généreront une alerte. (Et dans le cas de ce « presque », ils sont vérifiés en croisé avec un autre serveur)

Voici un tel code (simplifié) dans notre bot Telegram :

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Pour mettre à jour les indicateurs à partir de programmes Python — il existe une bibliothèque okerrupdate, pour tous les autres langages — il n'y a pas de bibliothèque, mais vous pouvez soit appeler le script okerrupdate, soit effectuer une requête HTTP au serveur okerr.

Comment okerr nous aide

Okerr a changé notre vie. Vraiment. Peut-être qu'un autre système de surveillance pourrait également le faire, mais travailler avec okerr est facile et simple, et il contient toutes les fonctionnalités dont nous avions besoin (ce qui manquait — nous l'avons ajouté). D'ailleurs, si une fonctionnalité manque — demandez, et je l'ajouterai (je ne promets rien, mais j'aimerais que okerr soit le meilleur système de surveillance pour les projets petits à moyens). Ou, encore mieux, ajoutez-le vous-même — c'est simple.

Nous avons réussi à vivre selon le principe « Apprendre de tous les problèmes via okerr ». Si un problème se produit et que nous ne l'avons pas appris d'okerr, nous ajoutons une vérification dans okerr. (Dans ce cas, par « nous », je fais référence à nous en tant qu'utilisateurs du système, et non aux co-développeurs). Au début, c'était fréquent, mais maintenant cela devient très rare.

Surveillance

Grâce à okerr, nous surveillons la taille des journaux sur tous les serveurs. Lire attentivement chaque ligne du journal est bien sûr impossible, mais simplement suivre la vitesse de croissance est déjà très utile. Grâce à cela, nous avons détecté à la fois l'envoi de spam et les tentatives de bruteforce pour deviner les mots de passe, ainsi que des applications qui « deviennent folles », où quelque chose ne fonctionne pas et qui répètent sans cesse (ajoutant à chaque fois quelques lignes dans le journal).

Certificats SSL. Très rapidement après le lancement LetsEncrypt notre client a commencé à fournir à ses clients des certificats SSL gratuits (environ mille d'entre eux). Et cela s'est avéré être un véritable cauchemar en matière d'administration ! Le fait est que les sites sont « vivants », les clients demandent régulièrement des modifications, et les programmeurs les réalisent. Ils peuvent très facilement déplacer un site vers un autre DocumentRoot par exemple. Ou ajouter une redirection sans condition dans la configuration de l'hôte virtuel. Naturellement, après cela, la mise à jour automatique des certificats échoue. Maintenant, tous nos hôtes SSL sont ajoutés automatiquement à okerr via un autre utilitaire utile de notre ensemble. a2conf. Nous lançons simplement a2okerr.py — et si plusieurs nouveaux sites apparaissent sur le serveur, ils apparaissent automatiquement dans okerr. Si, pour une raison quelconque, le certificat ne se met pas à jour, trois semaines avant son expiration — nous sommes au courant et nous nous demandons pourquoi il ne se met pas à jour, ce petit chien. a2certbot.py du même ensemble — cela aide beaucoup dans ce cas (il vérifie immédiatement les problèmes les plus probables et indique ce qui a été vérifié avec succès et où il y a probablement un problème).

Nous surveillons la date d'expiration de tous nos domaines. Et tous nos serveurs de messagerie, qui envoient des emails, sont également vérifiés sur plus de 50 listes noires différentes. (Et parfois ils y figurent). D'ailleurs, saviez-vous que les serveurs de messagerie de Google figurent également sur des listes noires ? Juste pour des tests, nous avons ajouté mail-wr1-f54.google.com aux serveurs suivis, et il est effectivement sur la liste noire SORBS ! (C'est une question de la valeur des « antispammeurs »)

Les sauvegardes — comme je l'ai déjà mentionné, il est très simple de les suivre avec okerr. Mais nous surveillons également les sauvegardes récentes sur notre serveur, et (à l'aide d'un petit utilitaire qui utilise okerr) — les sauvegardes que nous téléchargeons sur Amazon Glacier. Et oui — il y a parfois des problèmes. Il n'est pas surprenant que nous restions vigilants.

Nous utilisons un indicateur d'escalade. Cela montre si un problème n'est pas résolu depuis longtemps. Et moi-même, lorsque je traite certaines tâches, je peux parfois les oublier. L'escalade — c'est un bon rappel, même si je m'observe moi-même.

Dans l'ensemble, je pense que la qualité de notre travail s'est considérablement améliorée. Il y a presque pas de temps d'arrêt (ou le client ne peut pas le remarquer. Chut !), et la charge de travail a diminué, rendant les conditions de travail plus sereines. Nous sommes passés d'un travail chaotique avec des réparations d'urgence à un travail calme et mesuré, où de nombreux problèmes peuvent être anticipés à l'avance avec du temps pour les prévenir. Même les problèmes qui se sont produits — il est également devenu plus facile de les corriger : d'une part, nous en prenons connaissance avant que les clients ne déclenchent une panique, d'autre part, il arrive souvent que le problème soit lié à un travail récent (en faisant une chose, j'en ai cassé une autre) — donc il est plus facile de le résoudre sur le vif.

Encore un autre cas a eu lieu…

Saviez-vous que dans le populaire Debian 9 (Stretch), un paquet aussi populaire que phpmyadmin est toujours (depuis plusieurs mois !) en statut vulnérable ? (CVE-2019-6798). Lorsque la vulnérabilité est sortie — nous avons rapidement pris différentes mesures pour la couvrir. Mais j'ai mis en place un suivi dans okerr pour la page du security-tracker, afin de savoir quand une solution « élégante » sera publiée (via la somme de contenu SHA1). À plusieurs reprises, l'indicateur m'a alerté, la page a changé, mais comme vous le voyez — jusqu'à présent (depuis janvier 2019 !) il n'est pas indiqué que le problème est résolu. Peut-être que, d'ailleurs, quelqu'un sait de quel problème il s'agit, pourquoi un paquet si important est vulnérable depuis plus d'un an ?

Une autre fois dans une situation similaire : après une vulnérabilité dans SSH, il fallait mettre à jour tous les serveurs. Et quand on donne une tâche, il faut surveiller son exécution. (Les subordonnés ont tendance à mal comprendre, à oublier, à se mélanger, à faire des erreurs). Donc, d'abord, nous avons ajouté dans okerr une vérification de la version de SSH sur tous les serveurs, et via okerr, nous avons veillé à ce que les mises à jour soient appliquées sur tous les serveurs. (Pratique ! J'ai choisi ce type d'indicateur, et on voit immédiatement sur quel serveur quelle version est installée). Lorsque nous nous sommes assurés que la tâche était accomplie sur tous les serveurs, nous avons supprimé les indicateurs.

À quelques reprises, il y a eu des situations où un certain problème survenait, puis disparaissait tout seul. (Cela doit sûrement parler à tout le monde ?). Jusqu'à ce que tu le remarques, jusqu'à ce que tu vérifies — et là, il n'y a déjà plus rien à vérifier — tout fonctionnait déjà bien. Mais ensuite, ça se dégradait à nouveau. Nous avons rencontré cela, par exemple, avec les produits que nous avons téléchargés sur Amazon Marketplace (MWS). À un moment donné, les inventaires téléchargés étaient incorrects (pas les bonnes quantités de produits et pas les bons prix). Nous avons compris le problème. Mais pour y parvenir, il était important de connaître le problème immédiatement. Malheureusement, MWS, comme tous les services d'Amazon, est un peu lent, donc il y avait toujours un décalage, mais nous avons réussi à établir au moins approximativement le lien entre le problème et les scripts qui le provoquent (nous avons mis en place une vérification, l'avons liée à okerr, et avons vérifié dès que nous avons reçu une alerte).

Récemment, un grand et coûteux hébergeur européen, utilisé par notre client, a ajouté un cas intéressant à notre collection. Tout à coup, tous nos serveurs ont disparu des radars ! Au début, le client a remarqué par lui-même (plus rapidement qu'un éclair !) que le site sur lequel il travaillait ne s'ouvrait pas et a ouvert un ticket à ce sujet. Mais le problème n'était pas juste sur un site, mais sur tous ! (Natasha, nous avons tout perdu !). À ce moment, Okerr a commencé à envoyer de longs rapports avec tous les indicateurs qui avaient été activés. Panique, panique, nous courons en rond (que faire d'autre ?). Puis tout est revenu à la normale. Il s'est avéré qu'il y avait des travaux de maintenance dans le centre de données (une fois tous les plusieurs années) et que nous aurions dû être avertis, évidemment. Mais quelque chose s'est mal passé de leur côté et ils ne nous ont pas prévenus. Quoi qu'il en soit, il y a eu un infarctus de plus ou de moins. Mais après avoir tout restauré, il faut tout vérifier à nouveau ! Je n'imagine pas comment je l'aurais fait moi-même. Okerr a tout testé en quelques minutes. Il s'est avéré que la plupart des serveurs étaient simplement temporairement hors service, mais fonctionnaient. Certains se sont redémarrés, mais ont également retrouvé leur état normal. Parmi toutes les pertes, nous avons perdu deux sauvegardes qui devaient être créées en cron et chargées pendant cette période de chaos total. Je n'ai même pas essayé de les créer, car après une journée, des alertes sont arrivées disant que tout allait bien et que les sauvegardes étaient revenues. J'aime beaucoup cet exemple, car Okerr s'est révélé très utile dans une situation que nous n'avions même pas envisagée à l'avance, mais c'est justement le but de la surveillance : faire face à l'imprévisible.

Pour les capteurs Okerr, nous utilisons les hébergements les moins chers (la qualité et la fiabilité n'ont pas d'importance, ils se couvrent les uns les autres). Récemment, nous avons trouvé un hébergeur très dynamique à un prix super bas, les benchmarks sont incroyables. Mais... il s'avère parfois que les connexions sortantes depuis la machine virtuelle se font à partir d'une autre (voisine) adresse IP. Des merveilles. Le module client_ip avec https://diagnostic.opendns.com/myip ne reçoit pas la bonne adresse IP. Et même dans les journaux du serveur, il est visible que la mise à jour est également arrivée de cette adresse IP voisine. Nous sommes en train de résoudre cela avec le support. Heureusement, nous avons remarqué cela en temps normal. Cependant, il est souvent le cas que l'accès est enregistré dans une liste blanche d'adresses IP — et si le serveur clignote parfois pendant un court moment de cette façon — il peut être très long de tenter de repérer ce problème.

Et encore une chose — étant donné que nous parlons des hébergements VPS — nous utilisons toujours des solutions abordables (hetzner, ovh, scaleway). En termes de benchmarks et de stabilité, nous sommes très satisfaits. Nous utilisons également des services beaucoup plus coûteux comme Amazon EC2 pour d'autres projets. Ainsi, grâce à okerr, nous avons notre propre avis fondé. Les deux peuvent tomber en panne. Et je ne dirais pas qu'au fil de nos observations, les hébergements pas chers comme hetzner se sont révélés beaucoup moins stables qu'EC2. Donc, si vous n'êtes pas attachés à d'autres fonctionnalités d'Amazon — pourquoi payer plus cher ? 🙂

Et après ?

Si à ce stade je ne vous ai pas encore trop découragé d'Okerr — alors essayez ! Vous pouvez accéder directement à un compte de démonstration okerr (Cliquez maintenant !). Mais gardez à l'esprit que le compte démo est commun à tous, donc si vous faites quelque chose — quelqu'un d'autre dans ce même compte peut vous déranger en même temps. Ou (mieux) inscrivez-vous via le lien vers le site officiel d'okerr — c'est simple, sans SMS. Si vous n'aimez pas utiliser votre véritable e-mail — vous pouvez opter pour un e-mail temporaire, comme mailinator (Je recommande getnada.com). De tels comptes peuvent être supprimés avec le temps — mais cela conviendra pour un test.

Après vous être inscrit, il vous sera proposé de suivre une formation (effectuer quelques tâches d'apprentissage assez simples). Les limites initiales sont très faibles, mais suffisent pour un apprentissage ou pour un serveur. Après avoir terminé la formation — les limites (comme le nombre maximal d'indicateurs) seront augmentées.

Dans la documentation — en premier lieu WIKI pour la partie serveur et pour le client (okerrupdate wiki). Mais si quelque chose n'est pas clair — écrivez à support (at) okerr.com ou laissez un ticket — nous essaierons de résoudre tout cela rapidement.

Si vous envisagez d'utiliser sérieusement et que ces limites élevées ne suffisent pas — faites-le savoir au support, nous les augmenterons (gratuitement).

Vous souhaitez installer le serveur okerr sur votre propre serveur ? Voici le dépôt okerr-dev. Nous recommandons d'installer sur une machine virtuelle propre, ainsi vous pourrez le faire simplement avec un script d'installation. Sur votre propre machine virtuelle — aucune restriction :-). Et encore une fois — si vous avez besoin d'aide — nous serons toujours là pour vous assister.

Nous voulons que ce projet décolle, que le monde devienne plus sûr grâce à nous. Grâce aux logiciels et services gratuits, le monde est devenu plus amical et se développe plus rapidement. Les sources peuvent être stockées sur le github gratuit, pour le mail on peut utiliser le gmail gratuit. Nous utilisons gratuitement freshworks pour le support. Il n'est pas nécessaire de payer pour des serveurs, de télécharger ou de configurer quoi que ce soit, ni de résoudre divers problèmes d'exploitation. Chaque nouveau projet, chaque équipe — a immédiatement un mail, des dépôts et un CRM. Tout cela est de très bonne qualité, gratuit et disponible immédiatement. Nous voulons que le monitoring fonctionne de la même manière — des petites entreprises et des projets pourraient utiliser okerr gratuitement et même en phase de démarrage et de croissance, avoir la fiabilité de grands projets sérieux.

Source : habr.com

Aperçu du système de surveillance hybride Okerr