Vor zwei Jahren habe ich bereits einen Post verfasst Ein einfacher Failover für die Website über okerr. Derzeit gibt es einige Entwicklungen im Projekt, und ich habe außerdem den Quellcode des Serverteils von okerr veröffentlicht unter einer offenen Lizenz, daher habe ich beschlossen, diesen kleinen Überblick auf Habr zu schreiben.

[ Vollbild ]

Für wen könnte das interessant sein

Es könnte für Sie interessant sein, wenn Sie in einem kleinen Team oder sogar allein arbeiten. Sie haben kein Monitoring und sind sich unsicher, ob es notwendig ist. Oder Sie haben irgendeine beliebte, ernsthafte Überwachung "für große Jungs" ausprobiert, aber sie hat für Sie irgendwie "nicht funktioniert" oder läuft fast in der Standardkonfiguration und hat Ihr Leben nicht wesentlich verändert. Und noch — wenn Sie definitiv nicht planen, einen ganzen Mitarbeiter (noch dazu eine Abteilung) dafür abzustellen, dass dieser mindestens ein paar Stunden am Tag das Dashboard überwacht oder es einrichtet.

Was ist an okerr ungewöhnlich

Im Folgenden zeige ich interessante Merkmale von okerr, die es von einigen anderen Überwachungssystemen unterscheiden.

Okerr ist eine hybride Überwachung

Bei interner Überwachung läuft auf den überwachten Maschinen ein "Agent", der Daten an den Überwachungsserver überträgt (z. B. freien Speicherplatz auf Festplatten). Bei externer Überwachung führt der Server Netzwerkprüfungen durch (z. B. Ping oder Verfügbarkeit der Webseite). Jeder Ansatz hat seine eigenen Einschränkungen. Okerr verwendet beide Varianten. Die Prüfungen innerhalb der Server werden von einem sehr leichten (30 Kb) Agenten oder Ihren eigenen Skripten und Anwendungen durchgeführt, während die Netzwerkprüfungen über okerr-Sensoren in verschiedenen Ländern erfolgen.

okerr ist nicht nur Software, sondern auch ein Service

Der Serverteil jeder Überwachung ist groß und komplex, er ist schwierig 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 verwenden und unseren Serverdienst nutzen. Auch kostenlos.

Wenn das Monitoring es ermöglicht, den Mangel an Zuverlässigkeit bei Servern und Anwendungen auszugleichen, stellt sich die philosophische Frage – wer bewacht den Wächter? Wie wird uns das Monitoring über ein Problem informieren, wenn es selbst aus irgendeinem Grund "gestorben" ist, sei es isoliert oder zusammen mit anderen Ihrer Ressourcen (zum Beispiel, wenn die Verbindung zum Rechenzentrum ausfällt)? Mit dem externen Dienst okerr wird dieses Problem gelöst – Sie erhalten eine Benachrichtigung, selbst wenn das gesamte Rechenzentrum mit Ihren Servern ohne Strom ist oder einem Zombie-Angriff ausgesetzt ist.

Natürlich besteht das Risiko, dass der Server von okerr selbst nicht verfügbar ist, das ist wahr (wie bekannt, sind 90 % Zuverlässigkeit immer einfach und "kostenlos" zu erreichen, 99 % mit minimalem Aufwand, und jede zusätzliche Neun ist exponentiell schwieriger). Aber erstens sind die Chancen dafür geringer, und zweitens könnte das Problem 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 zu hohe Zahlen), dann beträgt die Chance eines unentdeckten Ausfalls – 0,1 % von 0,1 % = 0,0001 %. Es ist sehr gut, sich nahezu ohne Aufwand und Kosten drei Nullen zur Zuverlässigkeit hinzuzufügen!

Ein weiterer Vorteil des Monitorings als Dienstleistung besteht darin, dass der Hosting-Anbieter oder die Web-Agentur einen okerr-Server bei sich einrichten kann und den Kunden als kostenpflichtigen oder kostenlosen Zusatzdienst zur Verfügung stellt. Ihre Mitbewerber bieten nur Hosting und Websites an – und Sie haben zuverlässiges Hosting mit Monitoring.

Okerr – das sind die Indikatoren.

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

Jeder okerr-Indikator hat eingebaute Bedingungen, nach denen er seinen Zustand ändert (im Zabbix nennt man das trigger). Zum Beispiel darf die durchschnittliche Last nicht mehr als 2 betragen (das ist natürlich einstellbar). Und für jede interne Überprüfung (durchschnittliche Last, freier Speicherplatz, ...) gibt es einen Watchdog. Wenn wir aus irgendeinem Grund innerhalb der festgelegten Zeit keine erfolgreiche Bestätigung erhalten haben, wird ein Fehler registriert und eine Benachrichtigung gesendet.

Das übliche Arbeitsmuster bei uns ist die morgendliche E-Mail-Prüfung, wo wir unter anderem eine Zusammenfassung überprüfen (deren Zeitpunkt wir auf Arbeitsbeginn setzen). Wenn alles in Ordnung ist, widmen wir uns anderen wichtigen Aufgaben (aber zur Sicherheit können wir schnell das Dashboard von okerr überprüfen und sicherstellen, dass in diesem Moment alles grün ist). Wenn ein Alert eingeht, reagieren wir.

Natürlich besteht die Möglichkeit, einfach 'Informations'-Indikatoren zu halten (um das Netzwerkbild aus dem Monitoring zu sehen), aber alles ist so gestaltet, dass es einfach, leicht und schnell ist, Indikatoren speziell für automatisches Monitoring und das Versenden von Alerts zu erstellen.

Der Sinn, warum Sie okerr einrichten, liegt in den Alerts. Damit Sie in einer Minute einen Indikator erstellen können, der vielleicht ein ganzes Jahr 'geschlafen' hat und einfach Updates angenommen hat. Wenn Sie dann in einem Jahr ein Problem haben, wird er aktiviert und sendet einen Alert. Die Minute, die Sie einmal in die Erstellung eines Indikators investiert haben, hat sich bezahlt gemacht, denn Sie wurden sofort, früher als alle anderen, über das Problem informiert. Möglicherweise haben Sie das Problem sogar behoben, bevor jemand anders es bemerkt hat. Schnell hochgeholt zählt nicht als gefallen!

Sicherheit

Es wäre schade, wenn Sie Monitoring zur Erhöhung der Zuverlässigkeit einrichten und mit der Folge, dass Sie dadurch attackiert werden, und dass es in verschiedenen Monitoring-Tools zahlreiche Netzwerkanfälligkeiten gibt (Zabbix, Nagios).

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

Umfassende Monitoring-Abdeckung

Derzeit haben wir die Regel — wir erfahren von allen technischen Problemen über okerr. Wenn diese Regel einmal verletzt wird (okerr hat nicht gewarnt, dass es bald eintritt (falls möglich) oder dass es bereits eingetreten ist) — fügen wir Überprüfungen in okerr hinzu.

Externe Prü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 Banner darauf
HTTP-Grep (auf der Seite darf [nicht] ein bestimmter Text stehen)
SHA1-Hash, um Veränderungen der Seite festzustellen.
DNS (DNS-Eintrag muss einen bestimmten Wert haben)
WHOIS (warnt, wenn die Domain bald abläuft)
Antispam DNSBL (Überprüfung des Hosts sofort über 50+ Anti-Spam-Blacklist)

Interne Prüfungen

Auch ein recht typisches Set (aber leicht erweiterbar).

df (freier Speicherplatz auf den Festplatten)
Lastdurchschnitt
opentcp (offene hörende TCP-Sockets - wird benachrichtigen, wenn etwas gestartet oder abgestürzt ist)
uptime - einfach die Uptime des Servers. Wird benachrichtigen, wenn sie nach unten verändert wird (d.h. der Server wurde neu gestartet)
client_ip
dirsize - wir verwenden es, um zu verfolgen, wann unsere rootfs-Virtualisierungen die erlaubte Größe überschreiten, ohne strenge Einschränkungen einzuführen, und um die Größen der Benutzerverzeichnisse.
empty und nonempty - überwachen Dateien, die leer (oder nicht leer) sein sollten. Beispielsweise sollte das Fehlerprotokoll des Servers okerr leer sein. Wenn es auch nur eine Zeile enthält, erhalte ich eine Benachrichtigung und überprüfe. Das mail.log auf dem Mailserver sollte NICHT leer sein (nach N Minuten nach der Rotation). Manchmal war es jedoch leer, nach einem Systemupdate, wenn logrotate rsyslog nicht korrekt neustarten konnte.
linecount - Anzahl der Zeilen in einer Datei (wie wc -l). Wir verwenden es als weichere Alternative zu empty, wenn das Fehlerprotokoll doch langsam wachsen kann (zum Beispiel, wenn ein Googlebot auf einige geschützte Seiten zugreift). Es gibt ein Limit von 2 Zeilen in 20 Minuten. Wenn es darüber hinausgeht, wird ein Alert ausgelöst.

Interessante interne Prüfungen

Wenn Sie vorher «quer gelesen» haben, wird es jetzt interessanter, genauer hinzuschauen.

Backups

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

Was ist zu tun, damit das neue Backup überwacht wird, nachdem wir mit der Erstellung begonnen haben und in dieses Verzeichnis legen? Nichts! Das ist ein sehr praktischer Ansatz, wenn man «nichts» machen muss, weil:

«Nichts» zu tun ist recht schnell und spart Zeit.
Es ist schwer zu vergessen, «nichts» zu tun.
Es ist schwer, «nichts» falsch zu machen, mit einem Fehler. Nichts ist die zuverlässigste Methode.

Wenn jedoch plötzlich keine aktuellen Backup-Dateien mehr auftauchen, wird ein Alert ausgelöst. Wenn Sie beispielsweise einen der Server deaktiviert haben und es keine Backups mehr geben sollte, müssen Sie den Indikator entfernen (über die Weboberfläche oder über die API aus der Shell).

maxfilesz

Überwacht die Größe der größten Dateien (in der Regel: /var/log/*). Dies ermöglicht das Erkennen unvorhersehbarer Probleme, wie das Ausprobieren von Passwörtern oder den Versand von Spam über den Server.

runstatus/runline

Dies sind zwei wichtige Proxy-Module zum Starten anderer Programme auf dem Server. Runstatus berichtet über den Exit-Code des Programms. Zum Beispiel gibt es im Fall von okerr kein (nicht benötigtes) Modul zur Überprüfung, dass die systemd-Dienste laufen. Dies erfolgt über runstatus (siehe unten). Runline – berichtet an den Server die Zeile, die das Programm ausgibt. Zum Beispiel, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" Im Runline-Config auf unserem Server wird der Indikator servername:temp mit der Temperatur des Prozessors erstellt.

sql

Führt eine numerische Anfrage an MySQL aus und berichtet das Ergebnis im Indikator. Im einfachsten Fall kann man zum Beispiel "SELECT 1" machen – dies prüft, ob die Datenbank allgemein funktioniert.

Aber eine viel interessantere Anwendung – zum Beispiel die Überwachung der Anzahl der Bestellungen in einem Online-Shop. Wenn Sie wissen, dass Sie pro Stunde 100 Bestellungen haben, können Sie eine minimale Grenze von 100 oder 80 setzen. Wenn dann plötzlich Ihre Verkäufe sinken – erhalten Sie einen Alert und können das Problem angehen.

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

Der Server ist einfach nicht erreichbar (ausgeschaltet oder offline), und der Alert kam von dem, dass der Indikator 'verfallen' ist.
Der Server ist irgendwie belastet, arbeitet langsam oder es gibt Paketverluste, was unangenehm für die Nutzer ist und sie ohne Käufe gehen.
Der Server ist auf Spam-Listen geraten und Mails von ihm werden nicht akzeptiert, Nutzer können sich nicht registrieren.
Das Budget der Werbekampagne ist aufgebraucht, die Banner werden nicht angezeigt.

Es kann viele Ursachen geben, und man kann nicht alle im Voraus vorsehen, es ist auch technisch schwierig, das zu verfolgen. Aber es ist einfach, den endgültigen Parameter (Bestellungen) zu verfolgen und daran zu erkennen, dass die Situation verdächtig ist und es wert ist, sich damit zu befassen.

Logische Indikatoren

Ermöglicht die Verwendung logischer Ausdrücke (Python-Syntax) über das Modul evalidate(Artikel auf Habré). Für den Ausdruck stehen die Projektdaten und deren Indikatoren zur Verfügung. Zum Beispiel haben Sie möglicherweise im obigen Kapitel über die SQL-Überprüfung ein Schwachstelle bemerkt – tagsüber haben wir bis zu 100 Verkäufe pro Stunde, aber nachts sind es nur 20, was normal ist, kein Problem. Wie damit umgehen? Der Indikator wird nachts ständig Alarm schlagen.

Es können zwei Indikatoren erstellt werden, einen Tages- und einen Nachtindikator. Beide sollten "stumm" sein (sie werden keine Benachrichtigungen senden). Zudem sollte ein logischer Indikator erstellt werden, der bis 20:00 Uhr verlangt, dass der Tagesindikator in Ordnung ist, während nach 20:00 Uhr es ausreicht, wenn der Nachtindikator in Ordnung ist.

Ein weiteres Beispiel für die Verwendung eines logischen Indikators ist Eskalation. Zum Beispiel, ein Projektmanager meldet sich von Alerts ab (er benötigt diese nicht, die Administratoren sollten auf gewöhnliche Probleme reagieren), abonniert jedoch den logischen Indikator, der rot wird, wenn irgendein Indikator im Projekt nicht innerhalb der festgelegten Zeit behoben wurde.

Außerdem besteht die Möglichkeit, eine erlaubte Arbeitszeit festzulegen, zum Beispiel von 3 bis 5 Uhr morgens. Es kümmert uns nicht, wenn die Server und Websites in dieser Zeit "ausfallen". Aber um 5:00 Uhr müssen sie laufen. Wenn sie zu anderen Zeiten nicht funktionieren — Alarm. Der logische Indikator ermöglicht es auch, die Reserve von Servern zu berücksichtigen. Wenn Sie 5 Webserver haben, können die Administratoren 1-2 Server jederzeit ausschalten. Aber wenn weniger als 3 von 5 Servern aktiv sind — gibt es einen Alarm.

Die obigen Beispiele sind keine Funktionen von okerr, sondern keine speziellen Features, die aktiviert und konfiguriert werden müssen. All diese Funktionen sind in okerr nicht vorhanden, dafür gibt es ein logisches Modul, das es ermöglicht, diese Funktionalitäten zu realisieren (Ähnlich wie in einer Programmiersprache — wenn wir arithmetische Operatoren haben, benötigen wir keine besondere Funktion zur Berechnung von 20% Mehrwertsteuer, das kann man immer selbst zu seinen Bedürfnissen machen).

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

Hinzufügen eigener Überprüfungen

Ich möchte wirklich den Gedanken vermitteln, dass okerr kein Set aus tausend fertigen Überprüfungen für alle Lebenslagen ist, sondern umgekehrt — in erster Linie — eine einfache Engine mit der Möglichkeit, eigene Überprüfungen zu erstellen. Das Erstellen eigener Überprüfungen in okerr ist keine Aufgabe für Hacker, Mitentwickler des Systems oder wenigstens fortgeschrittene Benutzer von okerr, sondern eine machbare Aufgabe für jeden Administrator, der vor einem Monat zum ersten Mal Linux installiert hat.

Überprüfungen auf Minimalniveau werden über das Modul runstatus:

Diese Zeile in der Konfiguration runstatus benachrichtigt, falls /bin/true plötzlich nicht gestartet werden kann oder einen anderen Wert als 0 zurückgibt.

true_OK=\/bin\/true

Nur eine einzige Zeile – und schon haben wir ein wenig erweitert die Funktionalität von okerr.

Selbst eine solche Überprüfung hat bereits ihren Wert: Wenn Ihr Server plötzlich ausfällt, wird die entsprechende Anzeige auf dem okerr-Server nicht rechtzeitig aktualisiert, und nach einer gewissen Zeit tritt ein Alert auf.

Diese Überprüfung wird Sie informieren, dass der Server apache2 ausgefallen ist (man weiß ja nie…):

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

Wenn Sie also eine Programmiersprache beherrschen, können Sie zumindest Shell-Skripte schreiben – dann können Sie bereits eigene Überprüfungen hinzufügen.

Komplexer wird es, wenn Sie (in jeder Sprache) ein eigenes Modul für okerrmod schreiben. Im einfachsten Fall sieht es so aus:

#!/usr/bin/python3

print("STATUS: OK")

Ist das nicht wirklich nicht so schwer? Das Modul muss die Überprüfung selbst durchführen und die Ergebnisse auf STDOUT ausgeben. Ein komplexeres Modul gibt beispielsweise Folgendes aus:

$ okerrmod --dump df
NAME: pi:df-\/ 
TAGS: df
METHOD: numerisch|maxlim=90
DETAILS: 49.52%, 13.9G\/28.2G genutzt, 13.0G frei
STATUS: 49.52

NAME: pi:df-\/boot
TAGS: df
METHOD: numerisch|maxlim=90
DETAILS: 84.32%, 53.1M\/62.9M genutzt, 9.9M frei
STATUS: 84.32

Es aktualisiert mehrere Anzeigeindikatoren gleichzeitig (durch eine Leerzeile getrennt), erstellt sie bei Bedarf, gibt die Details der Überprüfung und das Tag an, mit dem die benötigten Anzeigen im Dashboard leicht gefunden werden können.

Es gibt einen Telegram-Bot @OkerrBot. Sie müssen Ihr Telefon nicht mit zusätzlichen Anwendungen überlasten (ich mag es nicht, dass man für die Pierskette eine App mit Karte, für die Lenta eine andere und für MTS die dritte benötigt, und so weiter für alle). Ein Telegramm reicht aus. Über Telegram können Sie Alerts sofort empfangen, den Status des Projekts überprüfen und das Kommando zur erneuten Überprüfung aller problematischen Anzeigen geben. Sie verlassen das Theater\/Flugzeug, haben zwei Stunden nicht auf den Puls geachtet, schalten den Fernseher ein, drücken einen Knopf im Chatbot und stellen sicher, dass alles in Ordnung ist.

Statusseiten

Heutzutage sind Statusseiten bereits fast ein Muss für jedes Unternehmen, das IT hat, ein verantwortungsvolles Verhältnis zur Zuverlässigkeit pflegt und seine Kunden\/Nutzer respektiert.

Stellen Sie sich vor, der Benutzer möchte etwas tun, Informationen ansehen oder eine Bestellung aufgeben, und es funktioniert etwas nicht. Er weiß nicht, woran es liegt, auf welcher Seite das Problem ist und wann es behoben wird. Könnte es sein, dass Ihre Firma einfach eine nicht funktionierende Website hat? Oder es ist seit einem halben Jahr kaputt und wird in zwei Jahren repariert? Aber den Kühlschrank muss man jetzt schon kaufen, er befindet sich bereits im Warenkorb… Und es ist etwas ganz anderes, wenn der Benutzer sieht, dass bei Ihnen etwas nicht in Ordnung ist (zumindest ist klar, dass das Problem nicht auf seiner Seite liegt), dass das Problem erkannt wurde, dass Sie bereits daran arbeiten und vielleicht sogar eine ungefähre Zeit für die Behebung angegeben haben. Der Benutzer 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, Ausfallzeiten — die hat jeder. Aber Benutzer und Partner vertrauen eher denen, die transparenter sind und verantwortungsbewusst damit umgehen.

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

Failover

Um diesen Artikel nicht noch länger zu machen, werde ich erneut auf meinen vorherigen Artikel verweisen — Ein einfacher Failover für die Website . Wenn Sie einen redundanten Server einrichten können, dann haben Sie mit Hilfe von Failover prinzipiell keine langen Ausfallzeiten — sobald das Problem erkannt wird, werden die Benutzer automatisch auf den funktionsfähigen Backup-Server umgeleitet. Und ich denke, das ist eine sehr interessante, auffällige Funktion, die es nur selten gibt.

Geringe Systemanforderungen

Für okerr-Server verwenden wir Maschinen mit RAM ab 2GB. Für Netzsensoren reichen sogar 512MB aus. Der Client-Bereich — fast nichts. (Das Paket okerrupdate wiegt 26 Kb, benötigt aber Python3 und Standardbibliotheken). Der Client wird über ein Cron-Skript gestartet, sodass die Speicherverbrauch konstant null ist. Unter den überwachten Maschinen haben wir Sensoren (super günstige VPS mit 512MB RAM) und Raspberry Pi. Man kann sogar ohne Client-Teil Updates über Curl senden! (siehe unten)

In Anbetracht dessen — ist okerr wahrscheinlich die kostengünstigste Das Monitoring-System aus den verfügbaren, denn um ein anderes kostenloses Open-Source-System wie Zabbix oder Nagios zu nutzen, müssen Ressourcen (Server) bereitgestellt werden, und das kostet Geld. Außerdem erfordert die Verwaltung des Servers dennoch einen gewissen Aufwand. Mit okerr kann dieser Teil entfallen. Es ist aber auch möglich, den eigenen Server zu nutzen – je nachdem, was Ihnen besser gefällt.

API und Integration in eigene Software

Ein einfaches und offenes Architektur. Okerr hat eine ziemlich einfache API, mit der man leicht arbeiten kann. Möchten Sie 1000 Indikatoren erstellen? Ein Shell-Skript von 3-4 Zeilen erledigt das. Müssen 1000 Indikatoren neu konfiguriert werden? Das ist auch sehr einfach. 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

Ein Indikator kann sowohl über unser Client-Modul als auch ohne es einfach über Curl aktualisiert werden.

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

Indikatoren können direkt aus Ihrem Programm aktualisiert werden. Zum Beispiel, indem Sie Heartbeat-Signale senden, damit okerr weiß, dass es läuft, und eine Warnung auslöst, wenn es abgestürzt oder eingefroren ist. Übrigens machen die Komponenten von okerr genau das – okerr überwacht sich selbst, und Probleme in fast jedem Modul werden erkannt und lösen eine Problemmeldung aus. (Für den Fall, dass dieses "fast" zutrifft – sie werden von einem anderen Server gegengeprüft)

So sieht ein solcher 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))

Für das Aktualisieren von Indikatoren aus Python-Programmen gibt es eine Bibliothek okerrupdate, für alle anderen Sprachen gibt es keine Bibliothek, aber man kann entweder das Skript okerrupdate aufrufen oder eine HTTP-Anfrage an den Server okerr senden.

Wie uns okerr hilft

Okerr hat unser Leben verändert. Wirklich. Es ist möglich, dass ein anderes Monitoring-System dies ebenfalls tun könnte, aber mit okerr zu arbeiten ist für uns einfach und unkompliziert, und es bietet alle Funktionen, die wir benötigten (das, was fehlte, haben wir hinzugefügt). Übrigens, wenn eine Funktion fehlt – fragen Sie, und ich werde sie hinzufügen (ich verspreche nichts, aber ich möchte, dass okerr das beste Monitoring-System für kleine bis mittlere Projekte wird). Oder, noch besser, fügen Sie selbst hinzu – es ist einfach.

Wir haben es geschafft, nach dem Prinzip zu leben: "Über alle Probleme von okerr zu erfahren". Wenn plötzlich ein Problem auftrat, von dem wir nicht von okerr erfahren haben, fügen wir eine Überprüfung in okerr hinzu. (In diesem Fall verstehe ich "wir" als die Benutzer des Systems und nicht als Mitentwickler). Anfangs war das häufig der Fall, aber mittlerweile ist es sehr selten geworden.

Überwachung

Über okerr überwachen wir die Größen der Logs auf allen Servern. Jedes einzelne Log-Zeile mit den Augen sorgfältig zu lesen, ist natürlich unmöglich, aber das bloße Überwachen der Wachstumsrate bringt schon viel. Dadurch haben wir Spam-Versand und Brute-Force-Angriffe auf Passwörter entdeckt, und wenn einige Anwendungen "durchdrehen", haben sie Probleme und wiederholen immer wieder (jedes Mal ein paar Zeilen mehr im Log hinzufügend).

SSL-Zertifikate. Fast sofort nach dem Start. LetsEncrypt beginnten unsere Kunden, ihren eigenen Clients kostenlose SSL-Zertifikate (etwa tausend davon) anzubieten. Und das stellte sich als echter Albtraum für die Verwaltung heraus! Die Sache ist die, dass die Websites "lebendig" sind, die Kunden regelmäßig um etwas bitten, die Programmierer das tun. Sie können die Website beispielsweise völlig problemlos 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 Aktualisierung der Zertifikate. Jetzt werden alle unsere SSL-Hosts automatisch über noch ein weiteres nützliches Tool aus unserem Paket in okerr hinzugefügt. a2conf. Wir starten einfach a2okerr.py — und wenn auf dem Server einige neue Websites erscheinen, erscheinen sie automatisch in okerr. Wenn aus irgendeinem Grund das Zertifikat nicht aktualisiert wird, sind wir drei Wochen vor dem Ablauf des Zertifikats im Bilde und kümmern uns darum, warum es nicht aktualisiert wird, das Mistding. a2certbot.py aus demselben Paket hilft dabei sehr (überprüft sofort die wahrscheinlichsten Probleme und zeigt an, was gut geprüft wurde und wo wahrscheinlich ein Problem liegt).

Wir überwachen das Ablaufdatum all unserer Domains. Und alle unsere Mail-Server, die E-Mails versenden, werden zudem in über 50 verschiedenen Blacklists überprüft. (Und manchmal landen sie darin). Übrigens, wussten Sie, dass die Mail-Server von Google ebenfalls in Blacklists stehen? Einfach zum Selbsttest haben wir mail-wr1-f54.google.com zu den überwachten Servern hinzugefügt, und er ist tatsächlich in der Blacklist von SORBS! (Das ist eine Anmerkung zur Bedeutung der "Anti-Spam-Filter")

Backups – weiter oben habe ich bereits geschrieben, wie einfach es ist, sie mit okerr zu überwachen. Aber wir überwachen auch die aktuellen Backups auf unserem Server und (mithilfe eines separaten Tools, das okerr nutzt) die Backups, die wir in Amazon Glacier hochladen. Und ja – gelegentlich treten Probleme auf. Kein Grund, nicht aufmerksam zu bleiben.

Wir verwenden einen Eskalationsindikator. Damit sieht man, wenn ein Problem lange Zeit nicht gelöst wurde. Und ich selbst kann beim Lösen von Aufgaben manchmal auch vergessen, sie zu beachten. Die Eskalation ist eine gute Erinnerungsstütze, selbst wenn man selbst darauf achtet.

Insgesamt bin ich der Meinung, dass die Qualität unserer Arbeit um ein Vielfaches gestiegen ist. Downtime gibt es nahezu nicht (na ja, oder der Kunde bemerkt sie nicht rechtzeitig. Nur tsst!), während gleichzeitig das Arbeitsvolumen geringer und die Arbeitsbedingungen ruhiger geworden sind. Wir sind von hektischer Arbeit mit patchworkartigen Lösungen zu einer ruhigen und gleichmäßigen Arbeitsweise übergegangen, bei der viele Probleme im Voraus vorhergesagt werden und es Zeit gibt, sie zu verhindern. Selbst bereits eingetretene Probleme sind jetzt einfacher zu beheben: Erstens erfahren wir von ihnen, bevor die Kunden Panik schieben, und zweitens ist es oft so, dass das Problem mit einer kürzlich durchgeführten Arbeit zusammenhängt (während ich das eine machte, zerbrach ich das andere) – deshalb lässt sich das Problem leichter direkt im Anschluss beseitigen.

Aber es gab auch einen weiteren Fall…

Wussten Sie, dass in dem beliebten Debian 9 (Stretch ein so beliebtes Paket wie phpmyadmin immer noch (schon seit vielen Monaten!) im Status vulnerable ist? (CVE-2019-6798). Als die Schwachstelle bekannt wurde, haben wir sie schnell auf verschiedene Weise abgedeckt. Aber ich habe in okerr das Monitoring der Seite des security-tracker eingerichtet, um zu wissen, wann eine "schöne" Lösung (über den SHA1-Hash des Inhalts) herauskommt. Mehrmals hat der Indikator mich gewarnt, die Seite hat sich geändert, aber wie Sie sehen – bis jetzt (seit Januar 2019!) ist dort nicht angegeben, dass das Problem behoben wurde. Vielleicht weiß jemand, was genau das Problem ist, dass ein so wichtiges Paket über ein Jahr lang vulnerable bleibt?

Eine ähnliche Situation: Nach einer Schwachstelle in SSH mussten alle Server aktualisiert werden. Wenn man eine Aufgabe vergibt, sollte man die Ausführung kontrollieren. (Mitarbeiter neigen dazu, es nicht so zu verstehen, zu vergessen, durcheinander zu kommen, Fehler zu machen). Daher haben wir zunächst in okerr die Überprüfung der SSH-Version auf allen Servern hinzugefügt und über okerr überwacht, dass die Updates auf allen Servern durchgeführt wurden. (Praktisch! Ich habe diesen Typ von Indikator ausgewählt, und sofort sieht man, auf welchem Server welche Version ist). Als wir sicher waren, dass die Aufgabe auf allen Servern erledigt war, haben wir die Indikatoren entfernt.

Ein paar Mal gab es die Situation, dass ein bestimmtes Problem auftritt und dann von selbst verschwindet. (Vermutlich kennt das jeder?). Bis man es bemerkt und überprüft, gibt es schon nichts mehr zu prüfen – alles funktioniert bereits gut. Aber dann bricht es wieder zusammen. Bei uns war das zum Beispiel mit Produkten, die wir im Amazon Marketplace (MWS) hochgeladen haben. Irgendwann waren die hochgeladenen Bestände falsch (falsche Mengen und falsche Preise). Wir haben es geklärt. Aber um es zu klären, war es wichtig, sofort von dem Problem zu erfahren. Leider ist MWS, wie alle Amazon-Dienste, etwas langsam, daher gab es immer eine Verzögerung, aber trotzdem gelang es uns, wenigstens grob den Zusammenhang zwischen dem Problem und den Skripten, die es verursachen, zu erkennen (wir haben eine Überprüfung gemacht, sie an okerr angehängt und sofort beim Empfang des Alerts überprüft).

Ein interessanter Fall, den ein großer und teurer europäischer Hosting-Anbieter, den unser Kunde nutzt, kürzlich in die Sammlung aufgenommen hat. Plötzlich verschwanden ALL unsere Server von den Radar! Zuerst bemerkte der Kunde selbst „per Hand“ (schneller als Okerr!), dass die Website, an der er arbeitete, nicht mehr erreichbar war und er eröffnete ein Ticket dazu. Aber es war nicht nur eine Website betroffen, sondern alle! (Natascha, wir haben alles fallen lassen!). Da begann auch Okerr, lange Berichte mit allen Indikatoren zu senden, die bei ihm aufgeleuchtet waren. Panik-Panik, wir liefen im Kreis (was soll man sonst tun?). Dann kam alles wieder hoch. Es stellte sich heraus, dass im Rechenzentrum planmäßige Arbeiten durchgeführt wurden (alle paar Jahre) und man uns natürlich hätte warnen sollen. Aber dann ist ihnen wohl ein Missgeschick passiert und sie haben es nicht getan. Ein Herzinfarkt mehr, ein Herzinfarkt weniger. Nach der Wiederherstellung muss jedoch alles überprüft werden! Ich kann mir nicht vorstellen, wie ich das manuell gemacht hätte. Okerr hat in ein paar Minuten alles getestet. Es stellte sich heraus, dass der Großteil der Server nur vorübergehend nicht verfügbar war, aber funktionierte. Einige hatten einen Neustart, standen jedoch auch wieder auf, wie es sein sollte. Von allen Verlusten haben wir zwei Backups verloren, die nach dem Cron erstellt und zu dem Zeitpunkt hochgeladen werden sollten, als dieser komplette Wahnsinn stattfand. Ich habe sie nicht einmal erstellt, nur einen Tag später kamen Alerts, dass alles OK ist, die Backups waren wieder da. Mir gefällt dieses Beispiel sehr, weil Okerr in einer Situation, an die wir im Voraus nicht einmal gedacht hatten, sehr hilfreich war, aber genau das ist die Aufgabe von Monitoring – dem Unvorhersehbaren entgegenzuwirken.

Für die Sensoren von Okerr verwenden wir die kostengünstigsten Hosting-Anbieter (Qualität und Zuverlässigkeit sind dort nicht wichtig, sie sichern sich gegenseitig ab). Neulich fanden wir ein sehr agiles Hosting zu super Preisen, die Benchmarks sind beeindruckend. Doch manchmal stellt sich heraus, dass ausgehende Verbindungen von der virtuellen Maschine mit einer anderen (benachbarten) IP ausgeführt werden. Wunder der Technik. Das Modul client_ip mit https://diagnostic.opendns.com/myip empfängt nicht die richtige IP. Auch in den Server-Logs des Indikators ist zu erkennen, dass das Update ebenfalls von dieser benachbarten IP kam. Wir klären das jetzt mit dem Support. Gut, dass wir das in friedlicher Zeit bemerkt haben. Aber es kommt häufig vor, dass der Zugang in einer Whitelist von IPs festgelegt wird – und wenn der Server manchmal kurz so blinkt – kann es sehr lange dauern, dieses Problem zu erkennen.

Und noch etwas — da wir gerade über VPS-Hosting sprechen — verwenden wir immer kostengünstige Anbieter (hetzner, ovh, scaleway). Sowohl in Benchmarks als auch in der Stabilität sind wir sehr zufrieden. Für andere Projekte nutzen wir auch das wesentlich teurere Amazon EC2. Nun, dank okerr haben wir unsere fundierte Meinung. Beide fallen aus. Und ich würde nicht sagen, dass die günstigen Hostingdienste wie hetzner über die lange Zeit unserer Beobachtungen deutlich weniger stabil sind als EC2. Also, wenn Sie nicht auf andere Funktionen von Amazon angewiesen sind — warum mehr bezahlen? 🙂

Was folgt jetzt?

Wenn ich Sie an dieser Stelle noch nicht stark von Okerr abgeschreckt habe — probieren Sie es aus! Direkt über diesen Link können Sie auf das Demokonto von okerr (Klicken Sie jetzt!). Bedenken Sie jedoch — es gibt nur ein Demokonto für alle, also kann, während Sie etwas machen, jemand anderes Ihnen in diesem gleichen Konto in die Quere kommen. Oder (besser) registrieren Sie sich über den Link auf der Website von okerr — ganz einfach, ohne SMS. Wenn Sie Ihre echte E-Mail nicht verwenden möchten — Sie können eine Einmal-E-Mail verwenden, wie zum Beispiel mailinator (ich empfehle getnada.com). Solche Konten können mit der Zeit gelöscht werden — aber für Tests ist es ausreichend.

Nach der Registrierung wird Ihnen angeboten, ein Training zu absolvieren (einige nicht allzu schwierige Aufgaben zu lösen). Die anfänglichen Limits sind sehr gering, aber für das Training oder einen Server sind sie ausreichend. Nach Abschluss des Trainings werden die Limits (zum Beispiel die maximale Anzahl an Indikatoren) erhöht.

Aus der Dokumentation — vor allem WIKI für den Serverteil und den Client (okerrupdate wiki). Aber wenn etwas unklar ist — schreiben Sie an support (at) okerr.com oder hinterlassen Sie ein Ticket — wir werden versuchen, alles schnell zu lösen.

Wenn Sie es ernsthaft verwenden und diese erhöhten Limits nicht ausreichen — schreiben Sie ebenfalls an den Support, wir werden erhöhen (kostenlos).

Möchten Sie okerr auf Ihrem eigenen Server installieren? Hier ist das Repository okerr-dev. Wir empfehlen, es auf einer sauberen virtuellen Maschine zu installieren, dann lässt sich das ganz einfach mit einem Installationsskript durchführen. Auf Ihrer eigenen virtuellen Maschine — keinerlei Einschränkungen :-). Und wieder — wenn etwas ist — wir werden immer versuchen zu helfen.

Wir möchten, dass dieses Projekt abhebt, damit die Welt durch uns sicherer wird. Dank kostenloser Software und Dienste ist die Welt freundlicher geworden und entwickelt sich dynamischer. Quellcodes können kostenlos auf github gespeichert werden, für E-Mails kann man kostenlos gmail nutzen. Wir nutzen kostenlos freshworks für den Support. Für all dies müssen keine Server bezahlt werden, es ist nicht nötig, herunterzuladen und einzurichten oder verschiedene Betriebsprobleme zu lösen. Jedes neue Projekt, jedes Team hat sofort E-Mail, Repositories und CRM. Und das alles ist von sehr guter Qualität, kostenlos und sofort verfügbar. Wir möchten, dass es für das Monitoring genauso ist – kleine Unternehmen und Projekte sollten okerr kostenlos nutzen können und sogar in der Phase der Gründung und des Wachstums die Zuverlässigkeit wie bei großen, seriösen Projekten haben.

Quelle: habr.com