Wie ich mein Monitoring geschrieben habe

Ich habe beschlossen, meine Geschichte zu teilen. Vielleicht kann jemand von dieser budgetfreundlichen Lösung bei einem weit verbreiteten Problem profitieren.

Als ich jung und voller Energie war und nicht wusste, wohin ich meine Ressourcen lenken sollte, beschloss ich, ein bisschen freiberuflich zu arbeiten. Ich konnte schnell meine Bewertung steigern und fand ein paar feste Kunden, die mich baten, ihre Server ständig zu betreuen.

Das erste, was mir in den Sinn kam, war die Notwendigkeit einer Überwachung. Ich beschloss, es wie die schlauen Leute zu machen, nicht das Rad neu zu erfinden, sondern fertige Lösungen wie Munin oder Zabbix anzusehen. Doch es stellte sich schnell heraus, dass die Web-Version eine gute Internetverbindung erfordert, insbesondere wenn man sie zum ersten Mal mit dem Handy öffnet. Wenn man jedoch auf dem Land abseits der Stadt entspannt, ist es schwierig, eine stabile Verbindung zu erhalten. Daher fiel die Wahl auf eine Konsolenüberwachung.

Für die Konsolenüberwachung halfen mir atop und das Programm zum Lesen der atop-Logs – atopsar. Diese wurden bereits auf habr erwähnt, atop wurde sogar auseinander genommen,, aber über atopsar wurde fast nichts gesagt.

Installation

Die Installation ist sehr einfach, nur drei Befehle.

#Centos

yum install atop

#Debian/Ubuntu

apt-get install atop

Danach kann man die Überwachungsarbeit anpassen oder die Standardeinstellungen verwenden.

#Debian/Ubuntu/Centos

/etc/default/atop 

Die Standarddatei:

 #cat /etc/default/atop
INTERVAL=60                    #Время, через которое создаётся снимок нагрузки в секундах, по умолчанию каждые 10 минут
LOGPATH="/var/log/atop"        #Путь до папки хранения логов
OUTFILE="$LOGPATH/daily.log"   #Название файла логов за сегодняшний день

Hinzufügen zum Autostart
#Debian/Ubuntu/Centos

systemctl enable atop 

Starte atop als Daemon
#Debian/Ubuntu/Centos

systemctl start atop  

Für die Faulen habe ich alles in einen Befehl zusammengefasst
#Centos

yum install atop && systemctl enable atop && systemctl start atop

#Debian/Ubuntu

apt-get install atop && systemctl enable atop && systemctl start atop

Atopsar

Mit atop wird auch atopsar installiert, ein praktischer Konsolenanalysator für die binären Logs, die der atop-Daemon führt. Natürlich kann man die Logs auch mit atop selbst lesen, aber das ist nicht so bequem, wenn man einen längeren Zeitraum erfassen muss.

Eine kleine Einführung in die Arbeit mit atopsar.

Beim Starten von atopsar ohne Optionen öffnet sich das Log für den heutigen Tag und zeigt die Last auf jedem Kern getrennt an sowie die idl-Zeile über alle Kerne.

Die Optionen, die ich verwende:

-A = zeigt alle Informationen im Log an
-c = zeigt Informationen zur Last auf den Prozessorkernen, Standardoption
registry-garbage-collect = Last auf dem Arbeitsspeicher und Swap
-d = Festplattenaktivität
-O = die Top-3 Prozesse mit der höchsten CPU-Last
-G = die Top-3 Prozesse mit der höchsten RAM-Last
-D = die Top-3 Prozesse mit der höchsten Festplattenlast
-N = die Top-3 Prozesse mit der höchsten Netzwerkbelastung
-r = den Pfad zum Log angeben, das Sie lesen möchten, wenn Sie die Last der vergangenen Tage überprüfen möchten
-b = die Zeit, ab der mit der Ausgabe begonnen werden soll
-e = die Zeit, zu der die Ausgabe beendet werden muss
-M = erstellt eine zusätzliche Spalte am Ende, in der die Kritikalität der Zeile markiert ist (+ es gibt eine Last, * — kritische Last)

Dank des Monitorings können wir die Ursache für das fehlerhafte Verhalten des Servers jederzeit verstehen.

Benachrichtigungen

Das Monitoring der Last ist vorhanden, bietet jedoch keine Möglichkeit, Probleme schnell zu finden und zu beheben. Wir benötigen Benachrichtigungen über auftretende Probleme.

Ich überwache die Server alleine, daher müssen die Benachrichtigungen dorthin gesendet werden, wo ich sie immer sehen und darauf reagieren kann.

Anfangs gab es SMS – schnell, zuverlässig, kostenlos. Aber dann haben die Mobilfunkanbieter den kostenlosen SMS-Versand über ihre Gateways eingestellt.
E-Mail ist langsam, es können Zustellprobleme auftreten.
Messenger – müssen auf dem Telefon installiert werden, es müssen Bots erstellt werden.

Als Ergebnis der Suche wurde der Messenger Telegram aufgrund seiner Einfachheit und der benutzerfreundlichen App für Smartphone und Desktop ausgewählt.

Ich habe meinen Bot mit Hilfe von botfather.
Nachdem ich mehrere Skripte auf den Server gelegt habe, die die Serverlast überwachen (IDL, smartct usw.), sowie das Vorhandensein von Fehlern vom Typ „oom killer“, Fehler beim Erstellen eines Backups und andere Operationen, die überwacht werden müssen.

Die Skripte sind relativ einfach, in Bash geschrieben, zum Beispiel die Überprüfung der LA und die Benachrichtigung über das Überschreiten des Load Average in Bezug auf die Kernanzahl Server.

if [ ${LA[0]} -gt 2000 ] || [ ${LA[1]} -gt 3000 ] || [ ${LA[2]} -gt 4000 ]
    then
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=Auf dem Server $ip LA $LAd"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=`top -b -n 1 | grep Cpu`"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=Top 5 Prozesse `top -b -n 1 | grep -A 5 'PID USER' | tail -5`"
    fi

Die Einfachheit der Syntax bietet viele Möglichkeiten zur Nutzung (und kann von jedem, der sich ein wenig mit Programmiersprachen auskennt, geschrieben oder ergänzt werden).

Der einzige Hinweis – wenn sich der Server in Russland befindet (und Sie kein IPv6 auf dem Server haben), müssen Sie einen Proxy verwenden. Dazu muss zu Beginn des Skripts die Verbindungszeile zum Proxy angegeben werden:

export https_proxy=http://login:passwort@IP.adresse:port

Das ist nicht das Ende

Du gehst ganz entspannt mit einem Rucksack über die Berge, erholst dich von der Zivilisation, und plötzlich, zufällig auf einer Verbindung, bekommst du eine Mitteilung über ein Problem auf deinem Server. Was tun? Die gelassene Stimmung ist wie weggeblasen. Soll ich meine Frau anrufen und ihr Befehle diktieren? Ha-ha!

Ich musste schnell einen Weg finden, um die aufgetretenen Probleme schnell und ohne gute Internetverbindung zu lösen. Hier half mir wieder einmal der Messenger (#telegramlebtdurch). Ich habe meinen Bot so programmiert, dass er nur mit mir kommuniziert und alle anderen ignoriert. Jetzt bekomme ich mit der Problemmeldung etwas mehr Informationen, die mir helfen, die Quelle des Problems zu identifizieren und es aus der Ferne zu lösen. Es genügt, einfach eine Nachricht an den Bot zu schicken, das Handy ein wenig höher zu halten, damit die Nachricht gesendet wird, und voilà – der Bot macht deine Arbeit. So kann ich zum Beispiel einen unerwünschten Prozess beenden, den Daemon neu starten, eine IP sperren und mehr.

In diesem Zusammenhang habe ich auch zukünftige benötigte Anfragen von Kunden verschoben, zum Beispiel die sofortige Rücksetzung von Benutzerpasswörtern (denn „Aaaah, wir können nicht auf den Server zugreifen, wir verlieren Millionen!“), die Suche nach einem Benutzer, der Zugriff auf den benötigten Ordner hat, das Ein- und Ausschalten der Website und weiteres. Natürlich arbeite ich ständig an der Funktionalität des Bots, da die Fantasie der Kunden manchmal unerwartete und von mir nicht vorhergesehene Anfragen bringt. Aber die Hauptanliegen sind zufriedenstellend.

Es gibt auch eine Version für VK, aber die hat sich irgendwie nicht durchgesetzt.

Jetzt reise ich entspannt und lerne diese Welt kennen, ohne Angst, dass etwas kaputtgeht, und ich davon nichts erfahre oder es nicht beheben kann.

Quelle: habr.com