Il y a deux ans, j'avais déjà posté Basculement simple pour un site Web про ok. Maintenant, il y a un certain développement du projet, et j'ai également publié code source côté serveur okerr sous licence ouverte, c'est pourquoi j'ai décidé d'écrire cette courte critique sur Habr.

[ en pleine taille ]

À qui cela peut intéresser

Cela peut vous intéresser si vous travaillez en petite équipe ou seul. Vous n'avez pas de surveillance et vous ne savez pas si vous en avez vraiment besoin. Soit vous avez essayé un système de monitoring sérieux et populaire « pour les grands », mais d’une manière ou d’une autre, il « n’a pas décollé » pour vous, soit il fonctionne dans une configuration presque par défaut et n’a pas beaucoup changé votre vie. Et aussi - si vous n'envisagez absolument pas d'affecter un employé entier (ou même un service) à la surveillance du tableau de bord de surveillance au moins quelques heures par jour ou à sa configuration.

Pourquoi okerr est inhabituel

Je montrerai ensuite les caractéristiques intéressantes de l'okerra qui le distinguent de certains autres systèmes de surveillance.

Okerr est une surveillance hybride

Lors de la surveillance interne, un « agent » s'exécute sur les machines surveillées, qui transmet les données au serveur de surveillance (par exemple, l'espace disque libre). Lorsqu'il est externe, le serveur effectue des vérifications sur le réseau (par exemple, ping ou disponibilité du site Web). Chaque approche a ses limites. Okerr utilise les deux options. Les vérifications à l'intérieur des serveurs sont effectuées par un agent très léger (30 Ko) ou par vos propres scripts et applications, et les vérifications du réseau sont effectuées via des capteurs okerr dans différents pays.

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

La partie serveur de toute surveillance est volumineuse et complexe, elle est difficile à installer et à configurer et nécessite des ressources. Avec okerr, vous pouvez installer votre propre serveur de surveillance (c'est gratuit et open source), ou vous pouvez simplement utiliser uniquement la partie client et utiliser le service de notre serveur. Également gratuit.

Si la surveillance permet de compenser et de dissimuler le manque de fiabilité des serveurs et des applications, alors une question philosophique se pose : qui est le gardien ? Comment la surveillance nous informera-t-elle d'un problème s'il est lui-même « mort » pour une raison quelconque, séparément ou avec vos autres ressources (par exemple, le canal vers le centre de données est tombé) ? Lorsque vous utilisez le service externe okerr - ce problème est résolu - vous recevrez une alerte même si l'ensemble du centre de données avec vos serveurs est sans électricité ou est attaqué par des zombies.

Bien entendu, il existe un risque que le serveur okerr lui-même soit indisponible, c'est vrai (comme vous le savez, 90 % de fiabilité s'obtient toujours simplement et « gratuitement », 99 % avec un minimum d'effort, et chaque neuf suivant est exponentiellement plus difficile). Mais d'une part, les chances que cela se produise sont plus faibles et, d'autre part, le problème peut passer inaperçu uniquement s'il coïncide avec des problèmes sur nos serveurs. Si nous avons une fiabilité de 99.9 % et que vous en avez 99.9 % (chiffres pas trop élevés), alors la probabilité d'une panne non détectée est de 0.1 % sur 0.1 % = 0.0001 %. Ajouter trois neuf à votre fiabilité presque sans effort et sans coût, c'est très bien !

Un autre avantage de la surveillance en tant que service est qu'un fournisseur d'hébergement ou un studio Web peut installer un serveur okerr et fournir un accès aux clients en tant que service supplémentaire payant ou gratuit. Vos concurrents disposent uniquement d'hébergement et de sites Web, mais vous disposez d'un hébergement fiable avec surveillance.

Okerr concerne les indicateurs

L'indicateur est une « ampoule ». Il a deux états principaux : vert (OK) ou rouge (ERR). Le projet contient de nombreux indicateurs regroupés (par exemple par serveur). Sur la page principale du projet, vous voyez immédiatement que soit tout est vert (et vous pouvez le fermer), soit quelque chose est allumé en rouge et doit être corrigé. Lors de la transition entre ces états, une alerte est envoyée. Une fois par jour, pendant votre mise en place, un résumé du projet est envoyé.

Chaque indicateur okerr a des conditions intégrées par lesquelles il change d'état (dans Zabbix, cela s'appelle un déclencheur). Par exemple, la charge moyenne ne doit pas dépasser 2 (bien sûr, cela est configurable). Et pour chaque vérification interne (charge moyenne, disque libre, ...) il y a un chien de garde. Si, pour une raison quelconque, nous ne recevons pas de confirmation à l'heure convenue, une erreur est enregistrée et une alerte est envoyée.

Notre rythme de travail habituel est de vérifier nos emails le matin, et de regarder le résumé parmi d'autres lettres (nous le programmons au début du travail). Si tout va bien, nous faisons d'autres choses importantes (mais pour être sûr, nous pouvons rapidement consulter le tableau de bord okerra et nous assurer que tout est vert à ce moment-là). Si une alerte arrive, nous réagissons.

Bien sûr, il est possible de conserver simplement des indicateurs « informatifs » (pour voir le portrait du réseau issu de la surveillance), mais tout est fait pour créer simplement, facilement et rapidement des indicateurs spécifiques à la surveillance automatique et à l'envoi d'alertes.

Le but pour lequel vous configurez okerr est dans les alertes, afin que vous puissiez créer un indicateur en une minute, il pourrait « dormir » pendant un an, accepter simplement les mises à jour, et quand un an plus tard quelque chose tombe en panne, il s'allume et envoie une alerte. La minute que vous avez passée à créer un indicateur a porté ses fruits : vous avez immédiatement pris connaissance du problème, avant tout le monde. Il est possible qu'ils l'aient réparé avant que quiconque ne le remarque. Quelque chose qui s'élève rapidement n'est pas considéré comme tombé !

sécurité

Il serait dommage de mettre en place une surveillance dans un souci d'augmentation de la fiabilité, mais du coup, vous êtes attaqué sur le réseau via celui-ci, et il existe de nombreuses vulnérabilités réseau dans différents outils de surveillance (Zabbix, Nagios).

Agent (okerrmod du package okerrupdate) exécuté sur le système 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 pirater le réseau, car en principe il n'écoute pas le réseau. prise.

Couverture de surveillance complète

Désormais, notre règle est que nous nous informons de tous les problèmes techniques auprès d'okerr. Si soudainement la règle est violée (okerr n'a pas averti de son apparition imminente (si cela est possible) ou du fait que cela s'est déjà produit) - nous ajoutons des contrôles à okerr.

Contrôles externes

Un ensemble assez typique :

• ping
• statut http
• vérifier la validité et la fraîcheur du certificat SSL (préviendra s'il est sur le point d'expirer)
• ouvrez le port TCP et la bannière dessus
• http grep (la page [ne doit pas] contenir de texte spécifique)
• hachage sha1 afin de détecter les changements de page.
• DNS (l'enregistrement DNS doit avoir une valeur spécifique)
• WHOIS (avertira si le domaine est sur le point de se détériorer)
• Antispam DNSBL (vérification de l'hôte par rapport à plus de 50 listes noires antispam à la fois)

Contrôles internes

Aussi, un ensemble assez standard (mais facilement extensible).

• df (espace disque libre)
• charge moyenne
• opentcp (ouvrir les sockets d'écoute TCP - vous avertira si quelque chose a démarré ou s'est écrasé)
• disponibilité - juste la disponibilité sur le serveur. Préviendra s'il a changé (c'est-à-dire que le serveur est surchargé)
• ip_client
• dirsize - nous l'utilisons pour suivre quand les rootfs de notre machine virtuelle dépassent la taille autorisée, sans introduire de restrictions strictes, et la taille des répertoires personnels des utilisateurs
• vide et non vide - surveille les fichiers qui doivent être vides (ou non vides). Par exemple, le journal des erreurs du serveur okerr lui-même doit être vide, et s'il contient ne serait-ce qu'une ligne, je recevrai une notification et la vérifierai. Mais mail.log sur le serveur de messagerie ne doit PAS être vide (N minutes après la rotation). Et parfois, il était vide pour nous après une mise à jour du système, lorsque logrotate ne parvenait pas à redémarrer rsyslog correctement.
• linecount - nombre de lignes dans le fichier (comme wc -l). Nous l'utilisons comme un remplacement plus doux du vide, lorsque le journal des erreurs peut encore croître, mais seulement lentement (par exemple, Googlebot atteint certaines pages fermées). Il y a une limite de 2 lignes en 20 minutes. S'il est plus élevé, il y aura une alerte

Des contrôles internes intéressants

Si vous lisiez jusqu’ici « en diagonale », il sera désormais plus intéressant de lire plus attentivement.

sauvegardes

Surveille les sauvegardes dans le répertoire. Nos fichiers de sauvegarde portent des noms tels que « ServerName-20200530.tar.gz ». Pour chaque serveur dans okerr, l'indicateur ServerName-DATE.tar.gz est créé (la date réelle passe à la ligne « DATE »). La présence même d'une nouvelle sauvegarde et sa taille sont également surveillées (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 après avoir commencé à la créer et à la placer dans ce répertoire ? Rien! Il s’agit d’une approche très pratique lorsque vous ne devez « rien faire » car :

• Ne « rien » c’est assez rapide, ça fait gagner du temps
• Il est difficile d’oublier de « ne rien faire »
• Il est difficile de « ne rien faire » de mal, avec une erreur. Rien n'est la méthode la plus fiable

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

maxfilesz

Garde une trace de la taille des fichiers les plus volumineux (généralement : /var/log/*). Cela vous permet de détecter des problèmes imprévisibles, par exemple des mots de passe forcés ou l'envoi de spam via le serveur.

statut d'exécution/ligne d'exécution

Ce sont deux modules proxy importants pour exécuter d’autres programmes sur le serveur. Runstatus rapporte le code de sortie du programme à l'indicateur. Par exemple, okerr ne nécessite pas de module pour vérifier que les services systemd sont en cours d'exécution. Cela se fait via runstatus (voir ci-dessous). Runline - signale au serveur la ligne produite par le programme. Par exemple, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" dans la configuration Runline sur notre serveur crée un indicateur servername:temp avec la température du processeur.

sql

Exécute une requête numérique vers MySQL et rapporte le résultat à l'indicateur. Dans un cas simple, vous pouvez faire, par exemple, "SELECT 1" - cela vérifiera que le SGBD dans son ensemble fonctionne.

Mais une application bien plus intéressante consiste par exemple à suivre le nombre de commandes dans une boutique en ligne. Si vous savez que vous avez 100 commandes ou plus par heure, vous pouvez définir la limite minimale à 100 ou 80. Ensuite, si vos ventes chutent soudainement, vous recevrez une alerte et vous pourrez le comprendre.

Notez que la raison imprévisible pour laquelle cela s’est produit n’a pas d’importance :

• Le serveur est tout simplement indisponible (hors tension ou sans réseau), et l'alerte venait du fait que l'indicateur était « pourri ».
• Le serveur est surchargé avec quelque chose, il fonctionne lentement ou des paquets sont perdus, c'est gênant pour les utilisateurs et ils partent sans faire d'achats
• Le serveur est inclus dans les listes de spam et le courrier provenant de celui-ci n'est pas accepté, les utilisateurs ne peuvent pas s'inscrire
• Le budget de la campagne publicitaire est épuisé, les banderoles ne tournent pas.

Il peut y avoir un certain nombre de raisons, et elles ne peuvent toutes être prévues à l’avance, et il est techniquement difficile de les suivre. Mais vous pouvez facilement surveiller le paramètre final (ordres) et déterminer à partir d'eux que la situation est suspecte et mérite d'être traitée.

Indicateurs logiques

Permet l'utilisation d'expressions booléennes (syntaxe Python) via un module valider(article sur Habré). Les données du projet et ses indicateurs sont disponibles pour expression. Par exemple, dans le chapitre ci-dessus sur la vérification SQL, vous avez peut-être remarqué un point faible : pendant la journée, nous pouvons avoir 100 ventes par heure, mais la nuit - 20, et c'est courant, ce n'est pas un problème. Que dois-je faire? L'indicateur paniquera constamment la nuit.

Vous pouvez créer deux indicateurs, jour et nuit. Rendez les deux « silencieux » (ils n’enverront pas d’alertes). Et créez un indicateur logique qui nécessite que l'indicateur de jour soit OK avant 20h00, et après 20h00 il suffit que l'indicateur de nuit soit OK.

Un autre exemple d'utilisation d'un indicateur logique est escalade. Par exemple, un chef de projet se désabonne des alertes (il n'a pas besoin de le faire, les administrateurs doivent répondre aux problèmes normaux), mais s'abonne à un indicateur logique qui devient rouge si un indicateur du projet n'est pas corrigé dans le temps imparti.

De plus, il est possible de fixer l'heure autorisée pour le travail, par exemple de 3h à 5h du matin. Cela ne nous importe pas si les serveurs et les sites tombent en panne pendant cette période. Mais à 5 heures, ils doivent travailler. S'ils ne fonctionnent pas à un autre moment, alertez. L'indicateur logique permet également de prendre en compte la redondance des serveurs. Si vous disposez de 00 serveurs Web, les administrateurs peuvent désactiver 5 à 1 serveurs à tout moment. Mais s'il y a moins de 2 serveurs sur 3 en combat, il y aura une alerte.

Les exemples ci-dessus ne sont pas des fonctions correctes, ni certaines fonctionnalités qui doivent être activées et configurées. Okerra n'a pas toutes ces fonctions, mais il existe un module logique qui vous permet d'implémenter cette fonctionnalité (à peu près comme dans un langage de programmation - si nous avons des opérateurs arithmétiques, alors nous n'avons pas besoin d'une fonction spéciale pour calculer 20 % de TVA à partir de la langue, vous pouvez toujours le faire vous-même en fonction de vos besoins).

L'indicateur logique est probablement l'un des rares sujets relativement complexes d'okerr, mais la bonne nouvelle est que vous n'êtes pas obligé de le maîtriser avant d'en avoir besoin. Mais en même temps, ils élargissent considérablement les capacités, tout en gardant le système lui-même assez simple.

Ajouter vos propres chèques

J'aimerais vraiment transmettre l'idée qu'okerr n'est pas un ensemble de milliers de chèques prêts à l'emploi pour toutes les occasions, mais au contraire - avant tout - un moteur simple avec une simple capacité de créer vos propres chèques. Créer vos propres chèques dans okerr n'est pas une tâche pour les pirates informatiques, les co-développeurs système ou au moins les utilisateurs avancés d'okerr, mais une tâche réalisable pour tout administrateur ayant installé Linux pour la première fois il y a un mois.

Les contrôles sur le salaire minimum se font via le module état d'exécution:

Cette ligne dans la configuration état d'exécution vous avertira si /bin/true ne démarre soudainement pas ou renvoie autre chose que 0.

true_OK=/bin/true

Juste une ligne - et nous y voilà déjà un peu étendu fonctionnalité okerr.

Même un tel contrôle a déjà sa valeur : si soudainement votre serveur tombe en panne, l'indicateur correspondant sur le serveur okerr ne sera pas mis à jour à temps, et une fois le temps écoulé, une alerte apparaîtra.

Cette vérification signalera que le serveur Apache2 est tombé en panne (enfin, on ne sait jamais...) :

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

Ainsi, si vous parlez n'importe quel langage de programmation et que vous pouvez au moins écrire des scripts shell, vous pouvez déjà ajouter vos propres vérifications.

Plus difficile - vous pouvez écrire (dans n'importe quelle langue) votre propre module pour okerrmod. Dans le cas le plus simple, cela ressemble à ceci :

#!/usr/bin/python3

print("STATUS: OK")

N'est-ce pas très difficile ? Le module doit effectuer la vérification lui-même et afficher les résultats sur STDOUT. Un module plus complexe donne par exemple ceci :

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

Il met à jour plusieurs indicateurs à la fois (séparés par une ligne vide), les crée si nécessaire, indique les détails de vérification et une balise grâce à laquelle il est facile de retrouver les indicateurs nécessaires dans le tableau de bord.

Telegram

Il existe un robot Telegram @OkerrBot. Vous n'avez pas besoin d'encombrer votre téléphone avec des applications distinctes (je n'aime pas que pour Pyaterochka vous ayez besoin d'une application avec une carte, pour Lenta une autre, pour MTS une troisième, et ainsi de suite pour tout le monde, tout le monde, tout le monde). Un télégramme suffit. Grâce au télégramme, vous pouvez immédiatement recevoir des alertes, vérifier l'état du projet et donner l'ordre de revérifier tous les indicateurs problématiques. Nous avons quitté le théâtre/l’avion, n’avons pas pris le pouls pendant deux heures, avons allumé le téléphone, appuyé sur un bouton du chatbot et nous sommes assurés que tout allait bien.

Pages d'état

De nos jours, les pages de statut sont presque indispensables pour toute entreprise disposant d'informatique, d'une attitude responsable envers la fiabilité et qui traite ses clients/utilisateurs avec respect.

Imaginez une situation : un utilisateur veut faire quelque chose, consulter des informations ou passer une commande, et quelque chose ne fonctionne pas. Il ne sait pas ce qui se passe, de quel côté est le problème et quand il sera résolu. Peut-être que votre entreprise a simplement un site Web non fonctionnel ? Ou est-ce qu'il est tombé en panne il y a six mois et sera réparé dans deux ans ? Mais il faut acheter un réfrigérateur maintenant, il est déjà dans le panier... Et c'est une tout autre affaire lorsqu'une personne voit que quelque chose ne va pas chez vous (au moins il est clair que le problème n'est pas de son côté), que le le problème a été découvert, que vous y travaillez déjà et que vous avez peut-être même noté l'heure approximative de la correction. L'utilisateur peut s'abonner et recevoir une notification par e-mail lorsque le problème est résolu et il peut faire ce qu'il veut (acheter un réfrigérateur).

Les problèmes et les temps d’arrêt arrivent à tout le monde. Mais les utilisateurs et les partenaires font davantage confiance à ceux qui sont plus transparents et responsables dans leur approche.

Ici revue de 10 autres projets qui permettent de créer des pages de statut. Voici des exemples de ce à quoi ressemblent ces pages de projets Python и Dropbox. page d'état okerr.

Basculement

Afin de ne pas allonger encore cet article, je ferai encore une fois référence à mon article précédent - Basculement simple pour un site Web . Si vous pouvez créer un serveur en double, alors en utilisant le basculement, vous n'aurez pratiquement pas de temps d'arrêt long - dès qu'un problème est détecté, les utilisateurs seront automatiquement redirigés vers un serveur de sauvegarde fonctionnel. Et il me semble qu'il s'agit d'une fonctionnalité très intéressante et lumineuse qui est rarement disponible nulle part.

Faibles exigences système

Pour les serveurs okerr, nous utilisons des machines avec RAM à partir de 2 Go. Pour les capteurs réseau, même 512 Mo suffisent. La part client est généralement quasi nulle. (Sac plastique okerrupdate pèse 26 Ko, mais nécessite Python3 et les bibliothèques standards). Le client s'exécute à partir d'un script cron, il n'a donc aucune consommation de mémoire persistante. Parmi les machines que nous avons surveillées, nous avons des capteurs (VPS super bon marché avec 512 Mo de RAM) et un Raspberry Pi. C’est possible même sans la partie client envoyer des mises à jour via curl! (voir ci-dessous)

En tenant compte de cela - okerr, probablement le plus gratuit système de surveillance parmi ceux disponibles, car même pour utiliser un autre système open source gratuit comme Zabbix ou Nagios, il faut lui allouer des ressources (serveur), et c'est déjà de l'argent. De plus, une certaine maintenance du serveur est encore nécessaire. Avec okerr, cette partie peut être supprimée. Ou vous n’êtes pas obligé de le supprimer et d’utiliser votre propre serveur, selon ce que vous préférez.

API et intégration dans des logiciels propriétaires

Architecture simple et ouverte. okerr en a un assez simple API, avec lequel il est facile de travailler. Besoin de créer 1000 indicateurs ? Un script shell de 3 à 4 lignes fera cela. Besoin de reconfigurer 1000 indicateurs ? C'est aussi très simple. Par exemple, nous souhaitons revérifier tous nos certificats HTTPS à partir d’un capteur russe :

#!/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 l'indicateur à l'aide de notre module client, 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/

Vous pouvez mettre à jour les indicateurs directement depuis votre programme. Par exemple, envoyer des signaux de battement de cœur pour qu'okerr sache qu'il est en cours d'exécution et déclenche une alarme en cas de panne ou de blocage. À propos, c'est exactement ce que font les composants okerr : okerr se surveille lui-même et les problèmes dans presque tous les modules seront détectés et généreront une alerte concernant le problème. (Et dans ce cas "presque" - ils sont recoupés depuis un autre serveur)

Voici le code (simplifié) dans notre bot télégramme :

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))

Il existe une bibliothèque pour mettre à jour les indicateurs des programmes Python okerrupdate, pour toutes les autres langues, il n'y a pas de bibliothèques, mais vous pouvez soit appeler le script okerrupdate, soit faire une requête HTTP au serveur okerr.

Comment okerr nous aide

Okerr a changé nos vies. En effet. Peut-être qu'un autre système de surveillance pourrait faire la même chose, mais travailler avec okerr est facile et simple pour nous et il possède toutes les fonctions dont nous avions besoin (nous avons ajouté ce qu'il n'avait pas). À propos, s'il manque certaines fonctionnalités, demandez-les et je les ajouterai (je ne le promets pas, mais je veux qu'okerr soit le meilleur système de suivi pour les petits et moyens projets). Ou mieux encore, ajoutez-le vous-même – c'est simple.

Nous avons réussi à vivre selon le principe « se renseigner sur tous les problèmes auprès des kerra ». Si soudainement un problème survient dont nous n'avons pas été informés par okerr, nous ajoutons un chèque à okerr. (dans ce cas, par « nous », j'entends nous en tant qu'utilisateurs du système, et non co-développeurs). Au début, c’était courant, mais c’est devenu très rare aujourd’hui.

Surveillance

Grâce à okerr, nous surveillons la taille des journaux sur tous les serveurs. Il est bien sûr impossible de lire attentivement chaque ligne du journal avec vos yeux, mais le simple fait de surveiller le taux de croissance donne déjà beaucoup. Grâce à cela, nous avons découvert le spam et les recherches de mots de passe par force brute, et lorsque certaines applications « deviennent folles », quelque chose ne fonctionne pas pour elles et elles le répètent encore et encore (en ajoutant à chaque fois quelques lignes au journal). ).

Certificats SSL. Presque immédiatement après le lancement Permet de chiffrer notre client a commencé à fournir des certificats SSL gratuits à ses clients (environ un millier d'entre eux). Et cela s’est avéré être un véritable enfer pour l’administration ! Le fait est que les sites sont « en direct », les clients leur demandent périodiquement de faire quelque chose, les programmeurs le font. Ils peuvent par exemple transférer en toute liberté le site vers un autre DocumentRoot. Ou ajoutez une réécriture inconditionnelle à la configuration de l'hôte virtuel. Naturellement, après cela, le renouvellement automatique des certificats échoue. Maintenant, tous les hôtes SSL sont ajoutés automatiquement à okerr via un autre de nos utilitaires utiles du package. a2conf. Lançons simplement a2okerr.py — et si plusieurs nouveaux sites apparaissent sur le serveur, ils apparaîtront automatiquement dans okerr. Si soudainement, pour une raison quelconque, le certificat n'est pas renouvelé, trois semaines avant l'expiration du certificat, nous sommes au courant et nous découvrirons pourquoi il n'est pas mis à jour, pour un tel chien. a2certbot.py à partir du même package - cela aide beaucoup (il vérifie immédiatement les problèmes les plus probables - et écrit ce qui a été bien vérifié et où il y a le plus probablement un problème).

Nous surveillons la date d'expiration de tous nos domaines. Et tous nos serveurs de messagerie qui envoient du courrier sont également vérifiés par rapport à plus de 50 listes noires différentes. (Et parfois ils tombent dedans). Au fait, saviez-vous que les serveurs de messagerie de Google sont également sur liste noire ? Juste à des fins d'auto-test, nous avons ajouté mail-wr1-f54.google.com aux serveurs surveillés, et il est toujours sur la liste noire SORBS ! (Il s’agit de la valeur des « anti-spammeurs »)

Sauvegardes - J'ai déjà écrit ci-dessus à quel point il est facile de les surveiller avec okerr. Mais nous surveillons à la fois les dernières sauvegardes sur notre serveur et (à l'aide d'un utilitaire distinct qui utilise okerr) les sauvegardes que nous téléchargeons sur Amazon Glacier. Et oui, des problèmes surviennent de temps en temps. Pas étonnant qu'ils regardaient.

Nous utilisons l'indicateur d'escalade. Cela montre si un problème n’a pas été résolu depuis longtemps. Et moi-même, lorsque je résous certains problèmes, je peux parfois les oublier. L'escalade est un bon rappel, même si vous vous surveillez.

Dans l’ensemble, je pense que la qualité de notre travail a augmenté d’un ordre de grandeur. Il n’y a presque pas de temps d’arrêt (ou le client n’a pas le temps de s’en apercevoir. Chut !), tandis que la quantité de travail a diminué et les conditions de travail sont devenues plus calmes. Nous sommes passés d'un travail d'urgence consistant à colmater les trous avec du ruban adhésif à un travail calme et mesuré, lorsque de nombreux problèmes sont prévus à l'avance et qu'il est temps de les prévenir. Même les problèmes survenus sont également devenus plus faciles à résoudre : d'une part, nous les découvrons avant que les clients ne paniquent, et d'autre part, il arrive souvent que le problème soit lié à un travail récent (pendant que je faisais une chose, j'en ai cassé une autre) - donc il fait chaud. C'est plus facile pour les traces de s'en occuper.

Mais il y a eu un autre cas...

Saviez-vous que dans la populaire Debian 9 (Stretch), un paquet aussi populaire que phpmyadmin est toujours (pendant plusieurs mois !) dans le statut vulnérable ? (CVE-2019-6798). Lorsque la vulnérabilité est apparue, nous l’avons rapidement couverte de différentes manières. Mais j'ai mis en place une surveillance de la page security-tracker dans okerr pour savoir quand une « belle » solution sortira (via la somme SHA1 du contenu). L'indicateur m'a fait trembler plusieurs fois, la page a changé, mais comme vous pouvez le constater, il n'indique toujours pas (depuis janvier 2019 !) que le problème est résolu. Peut-être qu'au fait, quelqu'un sait quel est le problème qu'un paquet aussi important soit encore vulnérable pendant plus d'un an ?

Une autre fois dans une situation similaire : suite à une vulnérabilité dans SSH, il a fallu mettre à jour tous les serveurs. Et lorsque vous définissez une tâche, vous devez contrôler son exécution. (Les subordonnés ont tendance à mal comprendre, à oublier, à se confondre et à faire des erreurs). Par conséquent, nous avons d'abord ajouté une vérification de version SSH à okerr sur tous les serveurs, et via okerr, nous nous sommes assurés que les mises à jour étaient déployées sur tous les serveurs. (Pratique ! J'ai choisi ce type d'indicateur, et on voit immédiatement quel serveur a quelle version). Lorsque nous étions sûrs que la tâche était terminée sur tous les serveurs, nous avons supprimé les indicateurs.

À plusieurs reprises, il y a eu une situation où un certain problème survenait, puis disparaissait tout seul. (probablement familier à tout le monde ?). Au moment où vous le remarquez, au moment où vous vérifiez – et il n’y a rien à vérifier – tout fonctionne déjà bien. Mais ensuite ça casse à nouveau. Cela s'est produit, par exemple, avec les produits que nous avons téléchargés sur Amazon Marketplace (MWS). À un moment donné, l'inventaire chargé était incorrect (mauvaises quantités de marchandises et mauvais prix). Nous l'avons compris. Mais pour le comprendre, il était important de se renseigner immédiatement sur le problème. Malheureusement, MWS, comme tous les services Amazon, est un peu lent, il y avait donc toujours un décalage, mais nous avons quand même pu comprendre au moins approximativement le lien entre le problème et les scripts qui le provoquent (nous avons fait une vérification, bloqué à l'okerr et l'a vérifié immédiatement en recevant une alerte).

Un cas intéressant a récemment été ajouté à la collection par un hébergeur européen important et coûteux, que notre client utilise. Du coup, TOUS nos serveurs ont disparu des radars ! Tout d'abord, le client lui-même (plus rapide qu'okerra !) a remarqué que le site avec lequel il travaillait ne s'ouvrait pas et a créé un ticket à ce sujet. Mais ce n’est pas un seul site qui est tombé en panne, mais tous ! (Natasha, on a tout laissé tomber !). Ici, Okerr a commencé à envoyer de longs enveloppements de pieds avec tous les indicateurs qui s'allumaient pour lui. Panique, panique, on tourne en rond (que faire d'autre ?). Puis tout s'est levé. Il s’avère qu’il y avait une maintenance de routine dans le centre de données (une fois tous les plusieurs années) et, bien sûr, nous aurions dû être prévenus. Mais un problème leur est arrivé et ils ne nous ont pas prévenus. Eh bien, plus de crises cardiaques, moins de crises cardiaques. Mais une fois que tout est restauré, vous devez tout revérifier ! Je ne peux pas imaginer comment je ferais cela avec mes mains. Okerr a tout testé en quelques minutes. Il s'est avéré que la plupart des serveurs étaient simplement temporairement indisponibles, mais ils fonctionnaient. Certains étaient surchargés, mais ils se sont également tenus debout comme il se doit. Parmi toutes les pertes, nous avons perdu deux sauvegardes qui, selon la couronne, auraient dû être créées et chargées pendant que cette banane pleine était en cours. Je n'ai même pas pris la peine de les créer, juste un jour plus tard, des alertes sont arrivées indiquant que tout allait bien, des sauvegardes étaient apparues. J'aime beaucoup cet exemple car okerr s'est avéré très utile dans une situation à laquelle nous n'avions même pas pensé à l'avance, mais c'est le but du suivi : résister à l'imprévisible.

Pour les capteurs Okerr, nous utilisons l'hébergement le moins cher possible (où la qualité et la fiabilité ne sont pas importantes, elles s'assurent mutuellement). Nous avons donc récemment trouvé un très bon hébergement et super bon marché, les benchmarks sont géniaux. Mais... parfois, il s'avère que les connexions sortantes de la machine virtuelle sont établies à partir d'une autre IP (voisine). Des miracles. Module Client_ip avec https://diagnostic.opendns.com/myip obtient la mauvaise adresse IP. Et d'après les journaux du serveur de l'indicateur, il est clair que la mise à jour provenait également de cette adresse IP voisine. Parlons maintenant du support. C'est bien que nous ayons remarqué cela en temps de paix. Mais, par exemple, il arrive souvent que l'accès soit enregistré selon la liste blanche IP - et si le serveur clignote parfois ainsi pendant une courte période - vous pouvez essayer de détecter ce problème pendant très longtemps.

Bon, encore une chose – puisque nous parlons d’hébergement VPS – nous utilisons toujours des hébergements bon marché (hetzner, ovh, scaleway). Je l'aime beaucoup tant en termes de benchmarks que de stabilité. Nous utilisons également Amazon EC2, beaucoup plus cher, pour d'autres projets. Ainsi, grâce à okerr, nous avons notre propre opinion éclairée. Ils tombent tous les deux. Et je ne dirais pas que sur la longue période de nos observations, les hébergements bon marché comme Hetzner se sont révélés nettement moins stables que EC2. Par conséquent, si vous n’êtes pas lié aux autres fonctionnalités d’Amazon, pourquoi payer plus ? 🙂

Quelle est la prochaine?

Si à ce stade je ne vous ai pas encore fait fuir Okerr, alors essayez-le ! Vous pouvez accéder directement à ce lien compte démo okerr (Cliquez maintenant !) Mais gardez à l’esprit qu’il n’existe qu’un seul compte démo pour tout le monde, donc si vous faites quelque chose, quelqu’un d’autre sur le même compte peut interférer avec vous en même temps. Ou (mieux) inscrivez-vous via le lien vers OK hors site - tout est simple, sans SMS. Si vous n'aimez pas utiliser votre véritable messagerie, vous pouvez en utiliser une jetable, comme mailinator (je recommande getnada.com). Ces comptes peuvent être supprimés au fil du temps, mais ils pourront être testés.

Après inscription, il vous sera demandé de suivre une formation (effectuer plusieurs tâches de formation peu difficiles). Les limites initiales sont très petites, mais pour une formation ou un serveur elles suffisent. Après avoir terminé la formation, les limites (par exemple, le nombre maximum d'indicateurs) seront augmentées.

D'après la documentation - tout d'abord WIKI côté serveur et côté client (wiki okerrupdate). Mais si quelque chose n'est pas clair, écrivez au support (at) okerr.com ou laissez un ticket - nous essaierons de tout résoudre rapidement.

Si vous l'utilisez sérieusement et que ces limites augmentées ne suffisent pas, écrivez au support et nous l'augmenterons (gratuitement).

Souhaitez-vous installer le serveur okerr sur votre serveur ? Ici dépôt okerr-dev. Nous vous recommandons d'installer sur une machine virtuelle propre, vous pouvez alors simplement le faire avec un script d'installation. Sur votre machine virtuelle - aucune restriction :-). Eh bien, encore une fois, si quelque chose arrive, nous essaierons toujours de vous aider.

Nous souhaitons que ce projet décolle, pour que le monde devienne plus fiable grâce à nous. Grâce aux logiciels et services gratuits, le monde est devenu plus convivial et se développe de manière plus dynamique. Les sources peuvent être stockées dans github gratuit, pour le courrier, vous pouvez utiliser Gmail gratuit. Nous utilisons gratuitement Freshworks pour le soutien. Pour tout cela, vous n’avez pas besoin de payer pour les serveurs, vous n’avez pas besoin de télécharger et de configurer, et vous n’avez pas besoin de résoudre divers problèmes opérationnels. Chaque nouveau projet, chaque équipe dispose immédiatement d'un courrier, de référentiels et d'un CRM. Et tout cela est de très haute qualité, gratuit et immédiat. Nous voulons qu'il en soit de même pour le suivi - les petites entreprises et les projets pourraient utiliser okerr gratuitement et même au stade de la naissance et de la croissance, avoir la fiabilité des projets sérieux pour adultes.

Source: habr.com