Server Monitoring mit apybot: Unterschied zwischen den Versionen
(5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
+ | '''Wird nicht mehr verwendet, Monitoring siehe: [[Server_Monitoring]]''' | ||
+ | |||
== Motivation == | == Motivation == | ||
Zeile 68: | Zeile 70: | ||
* IRC Bot in ''bash'', von Robin: [[IRC_Bot_in_bash]] | * IRC Bot in ''bash'', von Robin: [[IRC_Bot_in_bash]] | ||
+ | |||
+ | === ToDo === | ||
+ | |||
+ | * evtl. feature Mails prüfen einbauen / Überarbeiten | ||
== Verwendung in der Revamp-it == | == Verwendung in der Revamp-it == | ||
− | Zur Zeit läuft der apybot noch auf unserem Development Server in meinem home. | + | Zur Zeit läuft der apybot noch auf unserem Development Server (delfin-web) in meinem home. |
Damit dieser automatisch gestartet wird habe ich das folgende systemd service file geschrieben: | Damit dieser automatisch gestartet wird habe ich das folgende systemd service file geschrieben: | ||
Zeile 88: | Zeile 94: | ||
# Restart (!) | # Restart (!) | ||
Restart=always | Restart=always | ||
+ | # timeout | ||
+ | RestartSec=10 | ||
[Install] | [Install] | ||
Zeile 100: | Zeile 108: | ||
* Gelegentlich stürzt der Bot ab und wird '''nicht''' neu gestartet. Wobei nicht ganz klar ist warum dies geschieht... | * Gelegentlich stürzt der Bot ab und wird '''nicht''' neu gestartet. Wobei nicht ganz klar ist warum dies geschieht... | ||
+ | ** Nach einfügen eines Timeout im systemd service files (siehe oben) kommt dies weniger häufig vor. | ||
Für die Zukunft wäre allenfalls eine Alternative zu suchen. | Für die Zukunft wäre allenfalls eine Alternative zu suchen. | ||
Allenfalls könnte man die Überwachung auch aufteilen: | Allenfalls könnte man die Überwachung auch aufteilen: | ||
Z.B. könnte ich mir gut vorstellen ''kanla'' für Webseiten einzusetzen. Für die server an sich könnte man eine der anderen lösungen verwenden. | Z.B. könnte ich mir gut vorstellen ''kanla'' für Webseiten einzusetzen. Für die server an sich könnte man eine der anderen lösungen verwenden. | ||
+ | Siehe auch: [[Server Monitoring]] (insb. Abschnitt zabbix) | ||
== Vergleich C++ vs. Python == | == Vergleich C++ vs. Python == |
Aktuelle Version vom 25. Oktober 2023, 15:57 Uhr
Wird nicht mehr verwendet, Monitoring siehe: Server_Monitoring
Motivation
Nach einem unbemerkten Ausfall eines unserer Server, gab es den Wunsch nach einer einfachen Überwachung/Benachrichtigung im Falle eines Ausfalls.
Diese soll auf unserem LTSP Server laufen, da wir diesen praktisch ständig benutzen und so einen Ausfall sofort bemerken.
Ich habe mich entschlossen dies mittels einem Python Script umzusetzen. So entstand der apybot.
Zuerst hatte ich die Idee im Falle eines Ausfalls Mails zu verschicken. Falls nun aber der Mailserver ausfällt funktioniert dies nicht. Nicht nur können dann keine Mails verschickt werden. Es können auch keine empfangen werden. Da wir auf freenode.net den IRC Channel #revamp haben, und dort auch present sind, entstand die Idee, statt der Mails, einen IRC Bot zu verwenden.
Über apybot
apybot ist ein einfacher IRC Bot, geschrieben in Python 3. Grundsätzlich kann dieser verschiedene Aufgaben übernehmen. Nicht zuletzt kann er als einfaches Beispiel für asynchrone Programmierung in Python 3 dienen.
Siehe dazu auch die Python Referenz (englisch): https://docs.python.org/3/library/asyncio.html
Weiterführende Dokumente zur asynchronen Programmierung:
- http://cs.brown.edu/courses/cs168/f12/handouts/async.pdf Allgemeine Einführung (englisch)
- http://www.dabeaz.com/coroutines/ Verwandte Konzepte: Coroutinen, in Python (englisch)
Der source code des apybot ist in meinem git repository: https://github.com/rebootl/apybot
Features/Vorteile
- Asynchrones IO (asyncio) / Ressourcenschonend
- Reaktion auf private messages im IRC
- Periodische Ausführung von Funktionen
- Einfachste Konfiguration
- Einfach erweiterbar/anpassbar
- Saubere moderne Programmierung
- keine weiteren Abhängkeiten (für die Grundfunktion)
Konfiguration
IRC Netzwerk, Channel und gewünschter Nick werden direkt in der Python Datei angepasst.
Zusätzlich kann eine Liste zu prüfender hosts angeben werden. Es können hostnamen sowie IP Adressen angegeben werden. Beispiel:
# Hosts/Servers to check HOSTLIST = [ "localhost", "www.google.ch", "amd64box", "gugus" ]
Anwendung
Befehle können dem apybot im IRC als private Nachricht geschickt werden:
\msg <nick_vom_apybot> <befehl>
Zur Zeit versteht der apybot die folgenden Befehle:
quote Schickt ein Zitat zurück (Verwendet fortune, fortune muss auf dem System auf dem der Bot läuft, installiert sein.) status Gibt eine kurze Statusmeldung aus check Prüft hosts gemäss Konfiguration help Gibt eine kurze Hilfe aus
Bei anderen Messages gibt er einfach "I don't know..." aus.
Alternativen
- kanla "kanla: the simple, well-documented alerting software."
Geschrieben vom Entwickler des i3 Windowmanager Michael Stapelberg (leider in perl ;). Siehe: http://kanla.zekjur.net/
- nagios Umfangreiches Monitoring System. Meiner Meinung nach nicht empfehlenswert. Zu kompliziert und umständlich.
- IRC Bot in bash, von Robin: IRC_Bot_in_bash
ToDo
- evtl. feature Mails prüfen einbauen / Überarbeiten
Verwendung in der Revamp-it
Zur Zeit läuft der apybot noch auf unserem Development Server (delfin-web) in meinem home.
Damit dieser automatisch gestartet wird habe ich das folgende systemd service file geschrieben: /etc/systemd/system/apybot-revamp.service:
[Unit] Description=Simple host/server alerting IRC bot Documentation=http://wiki.revamp-it.ch/index.php?title=Server_Monitoring_mit_apybot After=network.target Requires=network.target [Service] User=revamp ExecStart=/home/caydin/Scripts/apybot-revamp/apybot-revamp.py # Restart (!) Restart=always # timeout RestartSec=10 [Install] WantedBy=multi-user.target
Steuerung mittels systemctl. Mehr Informationen zu Systemd, siehe z.B.: https://wiki.debian.org/systemd Oder auch: https://wiki.archlinux.org/index.php/Systemd
Probleme / Bugs
Nach einiger Zeit lässt sich sagen, dass es doch zum Teil Probleme gibt.
- Gelegentlich stürzt der Bot ab und wird nicht neu gestartet. Wobei nicht ganz klar ist warum dies geschieht...
- Nach einfügen eines Timeout im systemd service files (siehe oben) kommt dies weniger häufig vor.
Für die Zukunft wäre allenfalls eine Alternative zu suchen. Allenfalls könnte man die Überwachung auch aufteilen: Z.B. könnte ich mir gut vorstellen kanla für Webseiten einzusetzen. Für die server an sich könnte man eine der anderen lösungen verwenden. Siehe auch: Server Monitoring (insb. Abschnitt zabbix)
Vergleich C++ vs. Python
Interessehalber wollte ich wissen wie Python in einem Vergleich zu einer anderen Sprache abschneidet. So habe ich den IRC Parser zusätzlich in C++ implementiert. Da dies jedoch nichts mit dem Server Monitoring zu tun hat dokumentiere ich es in einem separaten Artikel: Vergleich C++ vs. Python