Server Monitoring mit apybot: Unterschied zwischen den Versionen

Aus revampedia
Zeile 68: Zeile 68:
  
 
* 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 ==

Version vom 17. September 2018, 11:44 Uhr

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:

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.

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