Uptime Kuma

Uptime Kuma ist ein Monitoring-Tool, mit dem man auf recht einfache Weise Dienste im IP-Netzwerk prüfen kann und bei Ausfällen alarmiert wird.

Webseiten

Features

Konfiguration eines HTTPS Checks
Web UI für die Administration und das Einrichten der Checks
2FA per TOTP Authenticator (leider aber ohne Backup-Codes)
Öffentliche Status-Seiten
Grafische Auswertungen der Verfügbarkeit
Checks können gruppiert werden
Benachrichtigungen (Alarme) über viele verschiedene Integrationen (z.B. per E-Mail, Mattermost, Nextcloud Talk, Telegram, ...)
Dienste-Checks wie HTTPS (inkl. Validierung der Gültigkeit von TLS-Zertifikaten), DNS, TCP-Ports, Ping, SNMP, Datenbanken, Docker-Container, etc.
Ergebnis eines HTTPS Checks
Mit Tags kann man Checks markieren und bei der Suche eingrenzen

Was nicht damit geht

Kein System-Monitoring auf (Remote) Hosts, z.B. um Last zu prüfen oder laufende Prozesse zu prüfen.
Keine Plugins (wie z.B. bei Nagios/Icinga)

Installation

Am einfachsten lässt sich Uptime Kuma per Docker-Container bzw. Podman installieren. Eine separate Datenbank ist nicht nötig, siehe unten. Die Anbindung ans Internet kann mittels Reverse Proxy eingerichtet werden (entweder auf dem Docker-Host selbst - z.B. per Apache - oder über einen separaten Dienst wie Traefik als Container).

Uptime Kuma 2.x unterstützt MariaDB (neben SQlite), wobei keine separate MariaDB Instanz nötig, da das Image eine Embedded MariaDB Instanz enthält. Bei der Installation kann diese in der Web UI angegeben werden.

Starten des Containers

Beispiel mit Podman:

podman run -d --cap-add=NET_RAW --restart=always -p 3001:3001 -v /srv/uptime_kuma/data:/app/data -v /run/podman/podman.sock:/run/podman/podman.sock --name uptime-kuma louislam/uptime-kuma:2

Reverse Proxy

Apache-Konfig [1]:

<VirtualHost *:443>
  ServerName monitoring.kruedewagen.de
  DocumentRoot /srv/www/vhosts/letsencrypt
  SSLEngine On
  SSLProtocol -all +TLSv1.2 +TLSv1.3
  SSLHonorCipherOrder on
  SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !SHA1 !SHA256 !SHA384"
  SSLCertificateFile /etc/letsencrypt/live/monitoring.kruedewagen.de/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/monitoring.kruedewagen.de/privkey.pem

  # HSTS, https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

  ProxyPreserveHost on
  ProxyPass / http://localhost:3001/
  RewriteEngine on
  RewriteCond %{HTTP:Upgrade} =websocket
  RewriteRule /(.*) ws://localhost:3001/$1 [P,L]
  RewriteCond %{HTTP:Upgrade} !=websocket
  RewriteRule /(.*) http://localhost:3001/$1 [P,L]
</VirtualHost>

TLS

TLS-Zertifikat per Let's Encrypt und certbot.

/etc/letsencrypt/monitoring.kruedewagen.de.conf:

authenticator = webroot
webroot-path = /srv/www/vhosts/letsencrypt
domains = monitoring.kruedewagen.de
email = cert@example.org
rsa-key-size = 4096

Zertifikat erstellen:

/usr/bin/certbot certonly -c /etc/letsencrypt/monitoring.kruedewagen.de.conf

Known Issues

Für Pings (vor allem IPv6) sind - zumindest bei Verwendung von Podman - besondere Rechte beim Starten des Containers nötig [2]:

--cap-add=NET_RAW

Bei expliziten IPv6 HTTP Checks scheint es ein Problem mit der Namensauflösung zu geben (getaddrinfo ENOTFOUND)
Selbst-erstellte oder nicht per Public CA validierte TLS-Zertifikate (z.B. von CAcert) werden zwar akzeptiert, wenn man die TLS-Fehler abschaltet, aber die zeitliche Gültigkeit der Zertifikate kann dann nicht überwacht werden.
Das Durchreichen eines CAcert Root CA Zertifikats klappt nicht [3],[4]:

-v /etc/SSLPATH/cacert_class3.crt:/app/data/docker-tls

bzw.

NODE_EXTRA_CA_CERTS="/app/data/docker-tls/meine-zertifikatskette.crt"

Tipps und Tricks

Bei Verwendung von Podman muss man die Socket-Datei von Podman vom Host in den Container durchreichen und in den Admin-Settings anpassen.

-v /run/podman/podman.sock:/run/podman/podman.sock