Vor zwei Jahren habe ich bereits einen Beitrag verfasst Ein einfacher Failover für Webseiten über okerr. Jetzt gibt es einige Entwicklungen im Projekt, und ich habe auch den Quellcode des Serverteils von okerr eine unter einer offenen Lizenz veröffentlicht, daher habe ich mich entschieden, diesen kurzen Überblick auf Hubr zu schreiben.

[ Vollbild ]

Für wen könnte das interessant sein

Es könnte für Sie von Interesse sein, wenn Sie in einem kleinen Team oder sogar alleine arbeiten. Sie haben kein Monitoring und sind sich unsicher, ob es wirklich nötig ist. Oder Sie haben bereits ein beliebtes seriöses Monitoring-Tool "für große Jungs" ausprobiert, aber es hat für Sie irgendwie "nicht gefruchtet" oder läuft fast in der Standardkonfiguration und hat Ihr Leben nicht großartig verändert. Außerdem, wenn Sie definitiv nicht vorhaben, einen ganzen Mitarbeiter (oder sogar ein Team) dafür abzuziehen, um mindestens ein paar Stunden am Tag im Dashboard des Monitorings zu überwachen oder es einzurichten.

Was macht okerr einzigartig

Als Nächstes werde ich interessante Merkmale von okerr zeigen, die es von einigen anderen Monitorings unterscheiden.

Okerr ist ein hybrides Monitoring

Bei der internen Überwachung läuft auf den beobachteten Maschinen ein „Agent“, der Daten an den Überwachungsserver überträgt (zum Beispiel freien Speicherplatz auf den Festplatten). Bei der externen Überwachung überprüft der Server über das Netzwerk (zum Beispiel Ping oder Verfügbarkeit von Websites). Jeder Ansatz hat seine eigenen Einschränkungen. Okerr nutzt beide Varianten. Die Überprüfungen innerhalb der Server erfolgen durch einen sehr leichten (30Kb) Agenten oder Ihre eigenen Skripte und Anwendungen, die Netzwerküberprüfungen über die Okerr-Sensoren in verschiedenen Ländern durchführen.

Okerr ist nicht nur Software, sondern auch ein Service.

Der Serverteil jeder Überwachung ist groß und komplex, er ist schwer zu installieren und zu konfigurieren und benötigt Ressourcen. Mit Okerr können Sie Ihren eigenen Überwachungsserver einrichten (er ist kostenlos und Open Source), oder Sie können einfach nur den Client-Teil nutzen und den Service unseres Servers verwenden. Auch kostenlos.

Wenn das Monitoring ausreicht, um den Mangel an Zuverlässigkeit bei Servern und Anwendungen auszugleichen, stellt sich die philosophische Frage: Wer überwacht den Wächter? Wie kann das Monitoring uns über ein Problem informieren, wenn es selbst aus irgendeinem Grund 'gestorben' ist, sei es allein oder zusammen mit anderen Ressourcen (zum Beispiel wenn die Verbindung zum Rechenzentrum ausfällt)? Mit dem externen Dienst okerr wird dieses Problem gelöst: Sie erhalten einen Alarm, selbst wenn das gesamte Rechenzentrum mit Ihren Servern stromlos ist oder einem Zombieangriff ausgesetzt wird.

Natürlich besteht das Risiko, dass der okerr-Server selbst nicht erreichbar ist, das ist richtig (wie bekannt, werden 90 % der Zuverlässigkeit immer einfach und 'kostenlos' erreicht, 99 % mit minimalem Aufwand, und jede weitere Neun ist exponentiell schwieriger). Aber erstens sind die Chancen dafür geringer und zweitens könnte das Problem nur unbemerkt bleiben, wenn es zeitlich mit Problemen auf unseren Servern zusammenfällt. Wenn wir eine Zuverlässigkeit von 99,9 % haben und Sie ebenfalls 99,9 % (nicht gerade hohe Zahlen), dann liegt die Wahrscheinlichkeit eines unentdeckten Ausfalls bei 0,1 % von 0,1 % = 0,0001 %. Sich drei Neun in die Zuverlässigkeit fast ohne Aufwand und Kosten hinzuzufügen, ist wirklich nicht schlecht!

Ein weiterer Vorteil von Monitoring als Service besteht darin, dass ein Hosting-Anbieter oder eine Web-Agentur einen Server von okerr einrichten und ihren Kunden diesen Zugang als kostenpflichtige oder kostenlose Zusatzleistung anbieten kann. Ihre Konkurrenz hat nur Hosting und Websites – Sie hingegen bieten zuverlässiges Hosting mit Monitoring.

Okerr – das steht für Indikatoren

Ein Indikator ist wie eine „Lampe“. Er hat zwei Hauptzustände – grün (OK) oder rot (ERR). Im Projekt gibt es viele gruppierte Indikatoren (zum Beispiel nach Servern). Auf der Hauptseite des Projekts sehen Sie sofort, ob alles grün ist (dann können Sie schließen) oder ob etwas rot leuchtet und korrigiert werden muss. Bei einem Wechsel zwischen diesen Zuständen wird eine Benachrichtigung versendet. Einmal täglich, während Sie einstellen, wird eine Zusammenfassung des Projekts geschickt.

Jeder okerr-Indikator verfügt über integrierte Bedingungen, die seinen Zustand ändern (in Zabbix nennt man dies Trigger). Beispielsweise sollte die durchschnittliche Auslastung nicht mehr als 2 betragen (dies lässt sich natürlich anpassen). Für jede interne Überprüfung (durchschnittliche Auslastung, freier Speicherplatz usw.) gibt es einen Watchdog. Wenn wir aus irgendeinem Grund nicht innerhalb der festgelegten Zeit eine bestätigende Antwort erhalten, wird ein Fehler protokolliert und eine Alarmmeldung versendet.

Unser üblicher Arbeitsablauf sieht vor, dass wir morgens die E-Mails überprüfen; dabei schauen wir unter anderem auf die Zusammenfassung (deren Zeit wir auf den Arbeitsbeginn festlegen). Wenn alles in Ordnung ist, befassen wir uns mit anderen wichtigen Aufgaben (aber wir können zur Sicherheit schnell auf das okerr-Dashboard schauen, um sicherzustellen, dass auch in diesem Moment alles grün ist). Wenn ein Alarm eintrifft, reagieren wir entsprechend.

Natürlich besteht die Möglichkeit, lediglich 'informative' Indikatoren zu führen, um die Netzwerkübersicht aus dem Monitoring zu sehen, aber alles ist so gestaltet, dass es einfach, leicht und schnell ist, Indikatoren speziell für die automatische Überwachung und das Versenden von Alarmen zu erstellen.

Der Sinn, warum Sie okerr einrichten, liegt in den Alerts. Damit können Sie in weniger als einer Minute einen Indikator erstellen, der möglicherweise ein Jahr lang „schläft“ und lediglich Updates entgegennimmt. Wenn jedoch nach einem Jahr etwas kaputtgeht, wird dieser aktiviert und sendet einen Alert. Die Minute, die Sie einmal für die Erstellung des Indikators investiert haben, hat sich ausgezahlt, denn Sie erfahren sofort von dem Problem, noch bevor es jemand anderem auffällt. Vielleicht haben Sie es sogar behoben, bevor es jemand bemerkt hat. Schnell Hochgefahrenes zählt nicht als gefallen!

Sicherheit

Es wäre schade, wenn Sie Monitoring zur Verbesserung der Zuverlässigkeit einrichten, und am Ende werden Sie dadurch über das Netzwerk angegriffen. Es gibt viele Netzwerksicherheitsanfälligkeiten bei verschiedenen Monitoring-Tools (Zabbix, Nagios).

Agent (okerrmod aus dem Paket okerrupdate), der auf dem System läuft, ist kein Netzwerkserver, sondern ein Client. Daher gibt es auf dem überwachten Server keine zusätzlichen offenen Ports, und der Client arbeitet problemlos hinter einer Firewall oder einem NAT und ist sehr schwer (ich würde sagen „unmöglich“) über das Netzwerk zu hacken, da er prinzipiell keinen Netzwerksocket abhorcht.

Vollständige Monitoring-Abdeckung

Aktuell haben wir die Regel, dass wir über alle technischen Probleme von okerr informiert werden. Sollte die Regel ausnahmsweise verletzt werden (wenn okerr uns nicht über eine bevorstehende Störung informiert oder wenn diese bereits eingetreten ist) — fügen wir entsprechende Überprüfungen in okerr hinzu.

Externe Überprüfungen

Ein recht typisches Set:

ping
HTTP-Status
Überprüfung der Gültigkeit und Aktualität des SSL-Zertifikats (warnt, wenn es bald abläuft)
offener TCP-Port und der Banner darauf
HTTP-Grep (auf der Seite sollte [nicht] ein bestimmter Text vorhanden sein)
SHA1-Hash zur Erkennung von Änderungen auf der Seite.
DNS (DNS-Eintrag muss einen bestimmten Wert haben)
WHOIS (warnt, falls die Domain bald abläuft)
Antispam DNSBL (Überprüfung des Hosts gegen über 50 Anti-Spam-Blacklists)

Interne Überprüfungen

Ebenfalls ein recht typisches Set (aber leicht erweiterbar).

df (freier Speicherplatz auf Festplatten)
Lastdurchschnitt
opentcp (offene, hörende TCP-Sockets — informiert, wenn etwas gestartet oder abgestürzt ist)
Uptime — einfach die Uptime des Servers. Informiert, wenn sich dieser nach unten ändert (d.h. der Server wurde neu gestartet)
client_ip
dirsize — wir verwenden es, um zu überwachen, wann bei unseren Root-Dateisystemen der virtuellen Maschinen die zulässige Größe überschritten wird, ohne strikte Begrenzungen einzuführen, und um die Größen der Benutzerhomeverzeichnisse zu kontrollieren.
empty und nonempty — überwachen Dateien, die leer sein sollten (oder nicht). Zum Beispiel sollte das Fehlerprotokoll des Servers okerr leer sein, und wenn auch nur eine Zeile darin steht, erhalte ich eine Benachrichtigung und prüfe nach. Das mail.log auf dem Mailserver hingegen sollte NICHT leer sein (nach N Minuten nach der Rotation). Manchmal war es leer, nach einem Systemupdate, als logrotate rsyslog nicht korrekt neu starten konnte.
linecount — die Anzahl der Zeilen in einer Datei (wie wc -l). Wir verwenden es als sanftere Alternative zu empty, wenn das Fehlerprotokoll zwar langsam, aber doch wachsen kann (zum Beispiel, wenn der Googlebot auf bestimmte, geschlossene Seiten zugreift). Es gibt eine Grenze von 2 Zeilen in 20 Minuten. Wenn es darüber hinausgeht, gibt es einen Alarm.

Interessante interne Prüfungen

Falls Sie bis hierhin «quergelesen» haben, wird es jetzt spannender, wenn Sie genauer hinsehen.

Backups

Überwacht die Backups im Verzeichnis. Unsere Backup-Dateien haben Namen wie „ServerName-20200530.tar.gz“. Für jeden Server wird in okerr ein Indikator ServerName-DATUM.tar.gz erstellt (das tatsächliche Datum wird durch die Zeile „DATUM“ ersetzt). Sowohl die Existenz eines aktuellen Backups als auch dessen Größe werden überwacht (zum Beispiel darf es nicht kleiner als 90 % des vorherigen Backups sein).

Was muss getan werden, damit ein neues Backup überwacht wird, nachdem wir es angefangen haben zu erstellen und in dieses Verzeichnis zu legen? Nichts! Dies ist ein sehr praktischer Ansatz, wenn man „nichts“ tun muss, denn:

„Nichts“ zu tun ist ziemlich schnell, das spart Zeit.
Es ist schwierig, zu vergessen, „nichts“ zu tun.
Es ist schwierig, „nichts“ falsch zu machen oder einen Fehler zu machen. Nichts zu tun ist die zuverlässigste Methode.

Wenn plötzlich keine neuen Backup-Dateien mehr erscheinen, gibt es eine Alarmmeldung. Wenn Sie beispielsweise einen der Server abgeschaltet haben und es daher keine Backups mehr geben sollte, müssen Sie den Indikator löschen (über die Web-Oberfläche oder über die Shell mittels API).

maxfilesz

Überwacht die Größe der größten Dateien (gewöhnlich: /var/log/*). Dies ermöglicht es, unvorhersehbare Probleme zu erfassen, wie etwa Passwortübergriffe oder das Versenden von Spam über den Server.

runstatus/runline

Dies sind zwei wichtige Proxy-Module, um andere Programme auf dem Server auszuführen. Runstatus gibt den Exit-Code des Programms aus. Zum Beispiel benötigt okerr kein Modul, um zu prüfen, ob die systemd-Dienste laufen. Das geschieht über runstatus (siehe unten). Runline gibt die Zeile aus, die das Programm auf dem Server zurückgibt. Zum Beispiel, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" Im Runline-Config auf unserem Server wird ein Indikator servername:temp mit der Temperatur des Prozessors erstellt.

sql

Führt eine numerische Abfrage an MySQL durch und gibt das Ergebnis im Indikator aus. Im einfachsten Fall kann man beispielsweise "SELECT 1" verwenden — dies prüft, ob die Datenbank insgesamt funktioniert.

Aber eine viel interessantere Anwendung ist, zum Beispiel die Anzahl der Bestellungen in einem Onlineshop zu überwachen. Wenn Sie wissen, dass Sie in der Stunde etwa 100 Bestellungen haben, können Sie eine minimale Schwelle von 100 oder 80 festlegen. Wenn Ihre Verkäufe plötzlich sinken, erhalten Sie eine Benachrichtigung und können die Ursache klären.

Beachten Sie — es spielt keine Rolle, aus welchem unvorhersehbaren Grund dies passiert ist:

Der Server ist einfach nicht erreichbar (stromlos oder offline), und die Benachrichtigung kam von dem, dass der Indikator „verfallen“ ist.
Der Server ist überlastet, arbeitet langsam oder es treten Paketverluste auf. Das führt dazu, dass Benutzer unzufrieden sind und ohne Kauf gehen.
Der Server steht auf Spam-Listen und seine E-Mails werden nicht akzeptiert. Nutzer können sich nicht registrieren.
Das Budget der Werbekampagne ist erschöpft, die Banner werden nicht angezeigt.

Die Gründe können vielfältig sein, und nicht alle sind im Voraus abzusehen. Technisch ist es schwierig, alles nachzuhalten. Doch man kann bequem die Endparameter (Bestellungen) im Blick behalten und anhand dieser erkennen, dass die Situation verdächtig ist und es sich lohnt, näher zu untersuchen.

Logische Indikatoren

Ermöglicht die Verwendung von logischen Ausdrücken (Python-Syntax) über das Modul evalidate(Artikel auf Habré). Für die Ausdrücke sind die Projektdaten und deren Indikatoren verfügbar. In dem Kapitel über die SQL-Überprüfung haben Sie vielleicht eine Schwachstelle bemerkt – tagsüber haben wir möglicherweise 100 Verkäufe pro Stunde, nachts hingegen nur 20, was gewöhnlich ist und kein Problem darstellt. Wie gehen wir damit um? Der Indikator wird nachts ständig Alarm schlagen.

Sie können zwei Indikatoren erstellen, einen für den Tag und einen für die Nacht. Beide können „stumm“ gemacht werden (sie senden keine Benachrichtigungen). Außerdem kann ein logischer Indikator eingerichtet werden, der bis 20:00 Uhr erfordert, dass der Tag-Indikator in Ordnung ist, während nach 20:00 Uhr lediglich der Nacht-Indikator in Ordnung sein muss.

Ein weiteres Beispiel für die Verwendung eines logischen Indikators ist die Eskalation. Zum Beispiel könnte der Projektmanager von Benachrichtigungen absehen (da er sie nicht benötigt, sollten die Administratoren auf gängige Probleme reagieren), aber sich für einen logischen Indikator anmelden, der rot wird, wenn irgendein Indikator im Projekt innerhalb der vorgegebenen Zeit nicht behoben wird.

Außerdem besteht die Möglichkeit, eine zulässige Zeit für Wartungen festzulegen, zum Beispiel von 3 bis 5 Uhr morgens. Uns stört es nicht, wenn Server und Websites zu dieser Zeit „ausfallen“. Aber um 5:00 Uhr müssen sie funktionieren. Wenn sie zu einem anderen Zeitpunkt ausfallen — gibt es einen Alert. Der logische Indikator berücksichtigt auch die Serverredundanz. Wenn Sie 5 Web-Server haben, können die Administratoren 1-2 Server jederzeit ausschalten. Aber wenn weniger als 3 von 5 Servern aktiv sind — wird ein Alert ausgelöst.

Die oben genannten Beispiele sind keine Funktionen von okerr, sondern auch keine Features, die aktiviert und konfiguriert werden müssen. All diese Funktionen sind nicht in okerr vorhanden; stattdessen gibt es ein logisches Modul, das es ermöglicht, diese Funktionalität zu realisieren (Ähnlich wie in einer Programmiersprache — wenn wir arithmetische Operatoren haben, benötigen wir keine spezielle Funktion der Sprache zur Berechnung von 20% MWSt; das kann man problemlos nach eigenen Bedürfnissen selbst umsetzen).

Der logische Indikator ist wahrscheinlich eines der wenigen relativ komplexen Themen in okerr, aber die gute Nachricht ist, dass Sie sie nicht beherrschen müssen, bis es wirklich notwendig ist. Doch sie erweitern die Möglichkeiten erheblich, während das System selbst einfach bleibt.

Eigene Prüfungen hinzufügen

Ich möchte betonen, dass okerr nicht eine Sammlung von tausend fertigen Prüfungen für alle Lebenslagen ist, sondern umgekehrt — in erster Linie eine einfache Engine mit der Möglichkeit, eigene Prüfungen zu erstellen. Das Erstellen eigener Prüfungen in okerr ist keine Aufgabe für Hacker, Mitentwickler des Systems oder zumindest fortgeschrittene Benutzer von okerr, sondern eine machbare Aufgabe für jeden Admin, der vor einem Monat zum ersten Mal Linux installiert hat.

Checks for minimum levels are performed through the module runstatus:

This line in the config runstatus will notify if /bin/true does not start or returns a value other than 0.

true_OK=/bin/true

Just one line — and we've already expanded our functionality of okerr. Even such a check has its value: if your server goes down, the corresponding indicator on the okerr server will not update in time, and after some time an alert will occur.

This check will notify that the apache2 server has crashed (just in case...):

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

So, if you know any programming language and can at least write shell scripts, you can already add your own checks.

More complicated — you can write your own module for okerrmod (in any language). In its simplest form, it looks like this:

Isn't it really that complicated? The module must perform the check and output the results to STDOUT. A more complex module, for example, produces the following:

#!/usr/bin/python3

print("STATUS: OK")

$ 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.52NAME: pi:df-/boot TAGS: df METHOD: numerical|maxlim=90 DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free STATUS: 84.32

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49,52 %, 13,9 G/28,2 G verwendet, 13,0 G frei
STATUS: 49,52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84,32 %, 53,1 M/62,9 M verwendet, 9,9 M frei
STATUS: 84,32

Er aktualisiert mehrere Indikatoren gleichzeitig (durch Leerzeilen getrennt), erstellt sie bei Bedarf und gibt die Prüfdaten sowie das Tag an, um die relevanten Indikatoren im Dashboard schnell zu finden.

Es gibt einen Telegram-Bot @OkerrBot. Sie müssen Ihr Telefon nicht mit zusätzlichen Apps überladen (ich persönlich finde es unangenehm, dass für einen Supermarkt eine App mit einer Karte benötigt wird, für einen anderen eine weitere, und so weiter). Ein Telegram-Kanal reicht aus. Über Telegram können Sie sofort Alarme erhalten, den Status des Projekts überprüfen und den Befehl zur Überprüfung aller problematischen Indikatoren auslösen. Verlassen Sie das Theater/Flugzeug, haben zwei Stunden lang nicht auf dem Puls geachtet, schalten das Telefon an, drücken einen Knopf im Chatbot und stellen fest, dass alles in Ordnung ist.

Statusseiten

Heutzutage sind Statusseiten fast ein Muss für jedes Unternehmen, das IT hat, Wert auf Zuverlässigkeit legt und seine Kunden/Nutzer respektiert.

Stellen Sie sich vor, ein Nutzer möchte etwas tun, Informationen suchen oder eine Bestellung aufgeben, und irgendetwas funktioniert nicht. Er weiß nicht, woran es liegt, auf welcher Seite das Problem ist und wann es behoben wird. Vielleicht hat Ihre Firma einfach eine nicht funktionierende Webseite? Oder sie ist seit einem halben Jahr defekt und wird erst in zwei Jahren repariert? Der Kühlschrank muss jedoch jetzt gekauft werden, er liegt bereits im Warenkorb… Ganz anders ist es, wenn der Nutzer sieht, dass etwas bei Ihnen nicht stimmt (zumindest ist klar, dass das Problem nicht auf seiner Seite liegt), dass das Problem erkannt wurde, dass Sie daran arbeiten und vielleicht sogar eine ungefähre Zeit für die Behebung angegeben haben. Der Nutzer kann sich anmelden und eine Benachrichtigung per E-Mail erhalten, wenn das Problem behoben ist und er das tun kann, was er wollte (den Kühlschrank kaufen).

Probleme und Ausfallzeiten haben alle. Aber Nutzer und Partner vertrauen eher denen, die transparenter sind und verantwortungsvoll mit solchen Situationen umgehen.

Hier Überblick über 10 andere Projekte, die Statusseiten anbieten. Hier sind Beispiele, wie diese Seiten bei den Projekten aussehen Python und Dropbox. Statusseite von okerr.

Failover

Um diesen Artikel nicht weiter auszudehnen, verweise ich erneut auf meinen vorherigen Artikel — Ein einfacher Failover für Webseiten . Wenn Sie einen redundanten Server einrichten können, sollte es mit Hilfe von Failover keinen langen Ausfall geben — sobald ein Problem erkannt wird, werden die Nutzer automatisch auf den funktionierenden Backup-Server umgeleitet. Ich halte das für eine sehr interessante und auffällige Funktion, die nur selten zu finden ist.

Geringe Systemanforderungen

Für die Server von okerr verwenden wir Maschinen mit mindestens 2 GB RAM. Für die Netzwerk-Sensoren sind sogar 512 MB ausreichend. Der Client benötigt in der Tat fast keine Ressourcen. (Das Paket okerrupdate hat 26 KB, benötigt jedoch Python3 und die Standardbibliotheken). Der Client wird über ein Cron-Skript gestartet, was bedeutet, dass er null dauerhaften Speicherverbrauch hat. Unter den beobachteten Maschinen haben wir Sensoren (super günstige VPS mit 512 MB RAM) und Raspberry Pi. Es ist sogar möglich, Updates ohne den Client zu senden über curl! (siehe unten)

In Anbetracht dessen ist okerr wahrscheinlich die kostengünstigste Lösung Mit okerr Monitoring müssen Sie nichts investieren, selbst wenn Sie eine andere kostenlose Open-Source-Lösung wie Zabbix oder Nagios nutzen möchten, da Sie dafür Ressourcen (Server) bereitstellen müssen, was Geld kostet. Außerdem braucht der Server etwas Pflege. Bei okerr können Sie diesen Aufwand reduzieren oder Ihren eigenen Server nutzen, ganz wie Sie möchten.

API und Integration in die eigene Software

Einfache und offene Architektur. okerr verfügt über eine sehr unkomplizierte API, die einfach zu handhaben ist. Möchten Sie 1000 Indikatoren erstellen? Ein Shell-Skript mit 3-4 Zeilen erledigt das. Müssen Sie 1000 Indikatoren neu konfigurieren? Auch das ist ganz leicht. Zum Beispiel wollen wir alle unsere HTTPS-Zertifikate genau mit dem russischen Sensor überprüfen:

#!/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

Der Indikator kann jederzeit aktualisiert werden, entweder über unser Kundenmodul oder einfach über curl, ganz ohne es.

# 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/

Sie können die Indikatoren direkt aus Ihrem Programm aktualisieren. Zum Beispiel, indem Sie Herzschlagsignale senden, damit okerr weiß, dass es läuft und einen Alarm auslöst, wenn es abgestürzt oder eingefroren ist. Übrigens funktioniert okerr genau so — okerr überwacht sich selbst, und Probleme in fast jedem Modul werden erkannt und generieren eine Problemmeldung. (Und für den Fall des 'fast' — sie werden von einem anderen Server über Kreuz überprüft)

So sieht der Code (vereinfacht) in unserem Telegram-Bot aus:

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

Um die Indikatoren aus Python-Programmen zu aktualisieren — gibt es eine Bibliothek okerrupdate, für andere Programmiersprachen gibt es keine Bibliothek, aber man kann entweder das Skript okerrupdate aufrufen oder eine HTTP-Anfrage an den okerr-Server senden.

Wie uns okerr hilft

Okerr hat unser Leben wirklich verändert. Sicher, es könnte auch ein anderes Überwachungssystem sein, aber die Zusammenarbeit mit Okerr ist einfach und angenehm. Es bietet alle Funktionen, die wir benötigt haben (alles, was gefehlt hat, haben wir selbst ergänzt). Übrigens, falls eine Funktion fehlt – frag einfach nach, und ich füge sie hinzu (ich verspreche nichts, aber ich möchte, dass Okerr das beste Überwachungssystem für kleine und mittlere Projekte wird). Noch besser, fügt es selbst hinzu – das ist ganz einfach.

Wir haben es geschafft, nach dem Prinzip zu leben: "Alle Probleme aus Okerr erfahren". Wenn ein Problem auftritt, von dem wir nicht über Okerr erfahren – fügen wir einen Check in Okerr hinzu. (Dabei meine ich mit "wir" uns als Nutzer des Systems, nicht als Mit-Entwickler). Zunächst geschah das häufig, aber inzwischen ist es sehr selten geworden.

Überwachung

Mit okerr überwachen wir die Loggrößen auf allen Servern. Jede Zeile des Logs mit Aufmerksamkeit zu lesen, ist natürlich unmöglich, aber die bloße Überwachung der Wachstumsrate liefert bereits viele Informationen. Damit haben wir Spam-Versendungen und Brute-Force-Angriffe auf Passwörter entdeckt, sowie Situationen, in denen einige Anwendungen "aus dem Ruder laufen", wenn sie etwas nicht schaffen und immer wieder versuchen (jedes Mal fügen sie ein paar Zeilen zum Log hinzu).

SSL-Zertifikate. Fast unmittelbar nach dem Start LetsEncrypt begann unser Kunde, seinen eigenen Kunden kostenlose SSL-Zertifikate (etwa tausend davon) anzubieten. Und das stellte sich als regelrechte Hölle im Management heraus! Die Websites sind "lebendig", die Kunden bitten gelegentlich um Änderungen, die Programmierer setzen diese um. Sie können zum Beispiel problemlos die Website in ein anderes DocumentRoot verschieben. Oder eine bedingungslose Rewrite-Regel in die Konfiguration des virtuellen Hosts einfügen. Natürlich bricht nach so etwas die automatische Zertifikatserneuerung zusammen. Jetzt werden alle SSL-Hosts automatisch über unser weiteres nützliches Tool aus dem Paket in okerr hinzugefügt. a2conf. Einfach ausführen a2okerr.py — und wenn auf dem Server mehrere neue Websites erscheinen, werden sie automatisch in okerr sichtbar. Sollte das Zertifikat aus irgendeinem Grund nicht aktualisiert werden, sind wir drei Wochen vor dem Ablaufdatum des Zertifikats informiert und machen uns Gedanken, warum es nicht aktualisiert wird. Seltsame Sache. a2certbot.py aus demselben Paket — hilft dabei sehr (prüft sofort die wahrscheinlichsten Probleme und gibt an, was gut funktioniert hat und wo wahrscheinlich ein Problem besteht).

Wir überwachen die Ablaufdaten aller unserer Domains. Alle unsere Mailserver, die E-Mails versenden, werden zudem über 50+ verschiedene Blacklists überprüft. (Und manchmal landen sie dort). Übrigens, wussten Sie, dass auch Google-Mailserver in Blacklists sind? Zur Selbstüberprüfung haben wir mail-wr1-f54.google.com zu den überwachten Servern hinzugefügt, und er ist tatsächlich auf der SORBS-Blacklist! (Das wirft ein Licht auf die Wertigkeit von „Antispam-Diensten“.)

Backups — ich habe oben bereits beschrieben, wie einfach es ist, sie mit okerr zu überwachen. Aber wir beobachten auch die aktuellen Backups auf unserem Server und (mit Hilfe eines speziellen Tools, das okerr verwendet) die Backups, die wir auf Amazon Glacier hochladen. Und ja — gelegentlich treten Probleme auf. Deshalb beobachten wir sie.

Wir verwenden einen Eskalationsindikator. Dieser zeigt an, wenn ein Problem über längere Zeit nicht gelöst wurde. Ich selbst kann, wenn ich Aufgaben erledige, manchmal die Übersicht verlieren. Die Eskalation dient als gutes Erinnerungswerkzeug, selbst wenn ich auf mich achte.

Insgesamt denke ich, dass die Qualität unserer Arbeit erheblich gestiegen ist. Es gibt fast keine Ausfallzeiten (oder der Kunde bemerkt sie nicht. Nur tsst!), während der Arbeitsaufwand geringer geworden ist und die Arbeitsbedingungen ruhiger sind. Wir sind von hektischer, reaktiver Arbeit mit Flickschusterei zu einer ruhigen und planvollen Arbeitsweise übergegangen, bei der viele Probleme im Voraus erkannt werden und es Zeit gibt, sie zu verhindern. Selbst bei bereits eingetretenen Problemen ist die Behebung einfacher geworden: Erstens erfahren wir von ihnen, bevor die Kunden in Panik geraten, und zweitens ist es oft so, dass das Problem mit einer kürzlichen Arbeit zusammenhängt (während ich an einem Ende gearbeitet habe, habe ich das andere kaputtgemacht) – sodass es leichter ist, es direkt zu beheben.

Hier war noch ein Fall...

Wusstest du, dass das beliebte Debian 9 (Stretch) einen so weit verbreiteten Paket wie phpmyadmin immer noch (seit vielen Monaten!) im Status vulnerable hat? (CVE-2019-6798). Als die Schwachstelle bekannt wurde, haben wir sie schnell auf verschiedene Weisen geschlossen. Ich habe jedoch in okerr das Monitoring für die Seite security-tracker aktivieren lassen, um zu wissen, wann eine „schöne“ Lösung (über den SHA1-Hash des Inhalts) veröffentlicht wird. Mehrmals hat der Indikator mich gewarnt, die Seite hat sich geändert, aber wie Sie sehen können – seit Januar 2019! – steht dort immer noch nicht, dass das Problem gelöst ist. Vielleicht weiß übrigens jemand, was das für ein Problem ist, dass dieses wichtige Paket seit über einem Jahr verwundbar ist?

Ein weiteres Mal in einer ähnlichen Situation: Nach einer Schwachstelle in SSH mussten alle Server aktualisiert werden. Und wenn man eine Aufgabe festlegt, muss man die Ausführung überwachen. (Untergebene neigen dazu, Dinge anders zu verstehen, zu vergessen, durcheinander zu kommen und Fehler zu machen.) Daher haben wir zunächst in okerr die Überprüfung der SSH-Version auf allen Servern hinzugefügt und über okerr sichergestellt, dass die Updates auf allen Servern installiert werden. (Praktisch! Ich wählte diesen Indikatortyp und konnte sofort sehen, auf welchem Server welche Version läuft). Als wir sichergestellt hatten, dass die Aufgabe auf allen Servern ausgeführt war – haben wir die Indikatoren entfernt.

Es gab schon einige Situationen, in denen ein Problem auftritt und sich dann von selbst löst. (Das dürfte den meisten bekannt sein.) Bis man es bemerkt und überprüft — und dann gibt es nichts mehr zu überprüfen — alles funktioniert wieder einwandfrei. Doch bald ist es dann wieder kaputt. So erging es uns zum Beispiel mit Produkten, die wir in den Amazon Marketplace (MWS) hochgeladen haben. Irgendwann waren die hochgeladenen Bestände nicht korrekt (falsche Mengen und Preise). Wir haben alles geklärt. Um das zu verstehen, war es jedoch wichtig, sofort von dem Problem zu erfahren. Leider ist MWS, wie alle Amazon-Services, etwas träge, weshalb es immer eine Verzögerung gab. Trotzdem ist es uns gelungen, zumindest grob den Zusammenhang zwischen dem Problem und den Skripten, die es verursachen, zu erkennen (wir haben eine Überprüfung implementiert, sie mit der Fehlerbehandlung verknüpft und sofort nach Erhalt eines Alerts geprüft).

Kürzlich gab es einen interessanten Vorfall mit einem großen und teuren europäischen Host-Anbieter, den unser Kunde nutzt. Plötzlich verschwanden ALLE unsere Server von den Radar! Zuerst bemerkte der Kunde selbst – schnell (fast sensationell!) – dass die Website, mit der er arbeitete, nicht mehr erreichbar war und öffnete ein Ticket dazu. Aber nicht nur eine Website war betroffen, sondern alle! (Natascha, wir haben alles abgeschaltet!). Daraufhin erhielt Okerr eine lange Liste mit allen Warnindikatoren, die bei ihm aufleuchteten. Panik, Panik, wir liefen im Kreis (was sollte man sonst tun?). Dann kam alles wieder in Ordnung. Es stellte sich heraus, dass im Rechenzentrum planmäßige Wartungsarbeiten (alle paar Jahre einmal) durchgeführt wurden und sie uns leider nicht rechtzeitig informiert hatten. Aber, nun ja, ob mit oder ohne Herzinfarkt, das ist auch egal. Nach der Wiederherstellung musste jedoch alles erneut geprüft werden! Ich kann mir nicht vorstellen, wie ich das manuell gemacht hätte. Okerr hat in wenigen Minuten alles getestet. Es stellte sich heraus, dass die meisten Server vorübergehend nicht erreichbar waren, aber dennoch funktionierten. Einige gingen in die Überlastung, aber standen ebenfalls wieder auf. Von all den Verlusten – haben wir zwei Backups verloren, die nach einem Zeitplan erstellt und hochgeladen werden sollten, während dieses totale Durcheinander lief. Ich hatte gar nicht in Betracht gezogen, sie neu zu erstellen; nach einem Tag kamen die Alarme, dass alles in Ordnung sei, die Backups waren wieder da. Ich finde dieses Beispiel sehr interessant, weil Okerr sich als äußerst nützlich in einer Situation erwies, die wir nicht im Voraus bedacht hatten. Aber genau dafür ist Monitoring da – um dem Unvorhersehbaren entgegenzuwirken.

Für die Okerr-Sensoren verwenden wir die günstigsten Hosting-Services, wo Qualität und Zuverlässigkeit keine Rolle spielen, da sie sich gegenseitig absichern. Kürzlich haben wir jedoch ein sehr flexibles Hosting-Angebot gefunden, das super günstig ist, mit beeindruckenden Benchmarks. Aber... manchmal kommt es vor, dass die ausgehenden Verbindungen von der virtuellen Maschine über eine andere (benachbarte) IP ausgeführt werden. Wunder der Technik. Das Modul client_ip erhält https://diagnostic.opendns.com/myip nicht die richtige IP. Aus den Server-Logs des Indikators ist auch ersichtlich, dass das Update ebenfalls von dieser benachbarten IP gekommen ist. Wir klären das gerade mit dem Support. Gut, dass wir das in einer ruhigen Phase bemerkt haben. Es kommt jedoch häufig vor, dass der Zugang in einer Whitelist von IPs festgelegt wird – und wenn der Server manchmal vorübergehend so flackert, kann es lange dauern, dieses Problem zu erkennen.

Und noch etwas – wo wir gerade über VPS-Hosting sprechen: Wir nutzen immer kostengünstige Anbieter (hetzner, ovh, scaleway). Sowohl in Bezug auf Benchmarks als auch auf Stabilität sind wir sehr zufrieden. Für andere Projekte setzen wir auch auf das deutlich teurere Amazon EC2. Dank okerr haben wir eine fundierte Meinung. Beide Anbieter haben ihre Ausfälle. Und ich würde nicht sagen, dass die günstigen Anbieter wie hetzner über einen längeren Zeitraum hinweg deutlich weniger stabil waren als EC2. Wenn Sie also nicht auf andere Funktionen von Amazon angewiesen sind – warum mehr bezahlen? 🙂

Wie geht es weiter?

Wenn ich Sie an dieser Stelle noch nicht von Okerr abgeschreckt habe – probieren Sie es aus! Über diesen Link können Sie auf den Demokonto von okerr (Klicken Sie jetzt!). Bedenken Sie jedoch – das Demokonto ist für alle Nutzer gemeinsam, daher könnte es sein, dass jemand anderes Ihnen zur selben Zeit in diesem Konto dazwischenfunkt. Oder (noch besser) registrieren Sie sich über den Link auf der Okerr-Website – ganz einfach, ohne SMS. Wenn Sie Ihre echte E-Mail nicht verwenden möchten – können Sie eine temporäre, wie mailinator, nutzen (Ich empfehle getnada.com). Solche Konten können im Laufe der Zeit gelöscht werden – aber für Tests ist es ausreichend.

Nach der Registrierung werden Sie aufgefordert, ein Training zu absolvieren (einige nicht allzu schwierige Aufgaben zu erledigen). Die anfänglichen Limits sind sehr gering, aber für das Training oder einen Server ausreichend. Nach Abschluss des Trainings werden die Limits (zum Beispiel die maximale Anzahl an Indikatoren) angehoben.

Aus der Dokumentation — in erster Linie WIKI für die Server- und Client-Seite (okerrupdate wiki). Wenn etwas unklar ist, wenden Sie sich bitte an support(at)okerr.com oder hinterlassen Sie ein Ticket — wir werden versuchen, alles schnell zu lösen.

Wenn Sie es ernsthaft nutzen und die erhöhten Limits nicht ausreichen, schreiben Sie ebenfalls an den Support, wir werden sie kostenlos erhöhen.

Möchten Sie den okerr-Server auf Ihrem eigenen Server installieren? Hier ist das okerr-dev-Repository. Wir empfehlen, auf einer sauberen virtuellen Maschine zu installieren, dann können Sie dies einfach mit einem Installationsskript tun. Auf Ihrer eigenen virtuellen Maschine gibt es keine Einschränkungen :-). Und wieder — wenn etwas ist, versuchen wir immer zu helfen.

Wir möchten, dass dieses Projekt erfolgreich ist, um die Welt durch uns sicherer zu machen. Dank kostenloser Software und Dienstleistungen wird die Welt freundlicher und entwickelt sich dynamischer. Quellcodes können kostenlos auf GitHub gespeichert werden, für E-Mails kann Gmail verwendet werden. Wir nutzen kostenloses freshworks für den Support. Für all dies müssen keine Server bezahlt, keine Downloads durchgeführt und keine unterschiedlichen Betriebsprobleme gelöst werden. Jedes neue Projekt und jedes Team hat sofort Zugang zu E-Mails, Repositories und CRM. Und all dies ist von sehr hoher Qualität, kostenlos und steht sofort zur Verfügung. Wir wünschen uns, dass es für das Monitoring genauso ist – kleine Unternehmen und Projekte sollten kostenlos okerr nutzen können und auch in der Gründungs- und Wachstumsphase die Zuverlässigkeit haben, wie bei großen ernsthaften Projekten.

Quelle: habr.com