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. Es lässt sich komplett in einer Web UI konfigurieren.

Webseiten

Ergebnis eines HTTPS Checks

• https://uptime.kuma.pet/
• Quellen und Doku auf GitHub
• Demo: https://demo.kuma.pet/start-demo
• c't 26/21 S.164, ct:y96q
• Monitoring-Software Uptime Kuma erreicht Version 2.0 - Neu: MariaDB statt SQlite möglich

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, Push, Webhooks, ...)
• Dienste-Checks wie HTTPS (inkl. Validierung der Gültigkeit von TLS-Zertifikaten, mit Pattern bzw. Status Codes - auch invers), DNS, TCP-Ports, Ping, SNMP, Datenbanken, Docker-Container, etc.
• 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)
  

Status Page

Mit einer Status-Page kann man der Außenwelt den Status der Dienste im Netzwerk anzeigen. Die Status Page ist öffentlich einsehbar, siehe z.B. https://status.kuma.pet/ . Welche Gruppen und Dienste auf einer Status Page angezeigt werden, kann eingestellt werden. Es sind mehrere Status Pages möglich.

Kommerzielle Pendant dazu wäre z.B. Atlassians Status Page oder auch status.io.

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

Docker/Podman Socket Konfiguration

• 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

• Änderung der im Container genutzten DNS-Server: Standardmäßig wird Quad9 verwendet (/etc/resolv.conf), welches in meinem Testzeitraum aber erhebliche Schwierigkeiten hatte (Timeouts bei DNS und HTTP-Checks). Man kann beim Starten des Containers andere DNS-Server durchreichen, z.B.:

podman run -d --dns="1.1.1.1" --dns="8.8.8.8"