Was wird in dieser Anleitung eingerichtet?

In diesem Beitrag richten wir drei Bereiche ein:

1. Linux-/Proxmox-Host-Monitoring
CPU, Load, RAM, Swap, Speicherplatz, SMART, Temperatur, Updates, systemd-Services und mehr.

2. NAS-Monitoring per SNMP
Beispielhaft mit QNAP, aber das Script unterstützt auch Synology, Buffalo, TrueNAS, ASUSTOR und NETGEAR ReadyNAS.

3. FortiGate-Firewall-Monitoring per REST API
CPU, RAM, Sessions, Interfaces, IPsec VPN, HA und SD-WAN Health Checks.

Alle verwendeten Scripts sind öffentlich auf GitHub verfügbar und können direkt von dort heruntergeladen oder geklont werden:

Hinweis: Die Scripts ersetzen kein vollwertiges Monitoring-System wie Checkmk, Zabbix oder Prometheus. Sie sind aber eine sehr praktische Erweiterung für Uptime Kuma, besonders im Homelab, in kleinen Umgebungen oder als ergänzende Statusübersicht.

Grundprinzip: Pro Check ein Push-Monitor

In Uptime Kuma wird für jeden Wert ein eigener Monitor vom Typ Push erstellt.

Beispiele:

TEXT
Proxmox - CPU
Proxmox - RAM
Proxmox - Disk
Proxmox - SMART
QNAP - Health
QNAP - Storage
QNAP - RAID
FortiGate - CPU
FortiGate - Interfaces
FortiGate - IPsec

Danach kopierst du die jeweilige Push-URL aus Uptime Kuma in die passende Config-Datei des Scripts.

Wichtig: In die Config wird nur die Basis-URL eingetragen, also zum Beispiel:

BASH
PUSH_URL_CPU="http://10.10.13.58:3001/api/push/DEIN_TOKEN"

Nicht eintragen solltest du die komplette URL mit Parametern:

BASH
# Falsch in der Config:
PUSH_URL_CPU="http://10.10.13.58:3001/api/push/DEIN_TOKEN?status=up&msg=OK&ping=1"

Die Parameter status, msg und ping werden durch das Script selbst erzeugt.

Empfohlene Einstellung pro Push-Monitor:

TEXT
Heartbeat Interval: 120 Sekunden
Retries: 1 oder 2

Die Scripts können trotzdem jede Minute laufen. Das 120-Sekunden-Fenster verhindert Fehlalarme, wenn ein Check einmal etwas länger dauert.

1. Linux- und Proxmox-Host mit Uptime Kuma überwachen

Repository:

https://github.com/realarna/uptimekuma-linuxmonitoring

Das Linux-Paket ist für Debian-, Ubuntu- und Proxmox-Systeme gedacht. Es überwacht typische Systemwerte, die Uptime Kuma selbst nicht direkt als Metriken ausliest.

1.1 Was wird überwacht?

Je nach aktivierter Push-URL können unter anderem folgende Checks genutzt werden:

  • CPU-Auslastung
  • Load Average
  • RAM-Auslastung
  • Swap-Auslastung
  • freier Speicherplatz
  • freie Inodes
  • fehlgeschlagene systemd Units
  • Reboot Required
  • verfügbare Updates und Security Updates
  • frei definierbare systemd Services
  • Docker Container Status
  • SMART Festplattenzustand
  • Netzwerkfehler RX/TX
  • Temperatur mit Filterung und Entprellung

Gerade für Proxmox sind CPU, Load, RAM, Speicherplatz, SMART, Temperatur, Updates und die Proxmox-Dienste sehr interessant.

1.2 Voraussetzungen installieren

Auf dem Linux- oder Proxmox-Host als root oder mit sudo:

BASH
apt update
apt install -y curl coreutils gawk sed grep procps smartmontools lm-sensors

Optional, wenn Docker direkt auf dem Host überwacht werden soll:

BASH
apt install -y docker.io

Auf einem klassischen Proxmox-Host ist Docker normalerweise nicht installiert. Der Docker-Check ist deshalb optional.

1.3 Script installieren

BASH
cd /tmp
git clone https://github.com/realarna/uptimekuma-linuxmonitoring.git
cd uptimekuma-linuxmonitoring
chmod +x install.sh scripts/*.sh tools/*.sh
./install.sh

Die Dateien werden installiert nach:

TEXT
/opt/linux-kuma-push
/etc/linux-kuma-push/config.env

Die bestehende Config wird bei späteren Updates nicht überschrieben.

1.4 Uptime-Kuma-Push-Monitore anlegen

Lege in Uptime Kuma zum Beispiel diese Push-Monitore an:

TEXT
Proxmox - CPU
Proxmox - Load
Proxmox - RAM
Proxmox - Swap
Proxmox - Disk
Proxmox - Inodes
Proxmox - Systemd
Proxmox - Reboot
Proxmox - Updates
Proxmox - Services
Proxmox - SMART
Proxmox - Netzwerk
Proxmox - Temperatur

Anschließend die Push-URLs kopieren.

1.5 Config bearbeiten

BASH
nano /etc/linux-kuma-push/config.env

Beispiel für einen Proxmox-Host:

BASH
HOST_DISPLAY_NAME="auto"

CURL_MAX_TIME=10
CMD_TIMEOUT=15
CACHE_DIR="/var/tmp/linux-kuma-push"

PUSH_URL_CPU="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_CPU"
PUSH_URL_LOAD="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_LOAD"
PUSH_URL_MEMORY="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_MEMORY"
PUSH_URL_SWAP="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_SWAP"
PUSH_URL_DISK="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_DISK"
PUSH_URL_INODES="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_INODES"
PUSH_URL_SYSTEMD_FAILED="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_SYSTEMD"
PUSH_URL_REBOOT_REQUIRED="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_REBOOT"
PUSH_URL_UPDATES="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_UPDATES"
PUSH_URL_SERVICES="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_SERVICES"
PUSH_URL_SMART="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_SMART"
PUSH_URL_NETWORK="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_NETWORK"
PUSH_URL_TEMPERATURE="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_TEMPERATURE"

# Optional, auf Proxmox meist leer lassen
PUSH_URL_DOCKER=""

MAX_CPU_PERCENT=90
MAX_LOAD_PER_CORE=2.0
MAX_MEMORY_USED_PERCENT=90
MAX_SWAP_USED_PERCENT=50
ALLOW_NO_SWAP="true"

DISK_PATHS="/ /var/lib/vz"
MIN_DISK_FREE_PERCENT=10
INODE_PATHS="/ /var/lib/vz"
MIN_INODE_FREE_PERCENT=10

SERVICES_TO_CHECK="pveproxy pvedaemon pvestatd pve-cluster"

CHECK_SECURITY_UPDATES="true"
MAX_AVAILABLE_UPDATES=100
MAX_SECURITY_UPDATES=0

SMART_DEVICES=""
SMARTCTL_BIN="auto"
SMART_ALLOW_NOT_INSTALLED="true"
SMART_ALLOW_NO_DEVICES="true"
SMART_CMD_TIMEOUT=20

NETWORK_INTERFACES=""
MAX_NETWORK_ERROR_DELTA=10

MAX_TEMP_C=85
MIN_VALID_TEMP_C=0
MAX_VALID_TEMP_C=120
ALLOW_MISSING_TEMPERATURE="true"
TEMP_REQUIRE_CONSECUTIVE_FAILURES=2
TEMP_CMD_TIMEOUT=8
TEMP_CACHE_FILE="/var/tmp/linux-kuma-push/temperature.cache"

1.6 Checks testen

Alle Checks ausführen:

BASH
CONFIG_FILE=/etc/linux-kuma-push/config.env /opt/linux-kuma-push/scripts/run-all.sh

Einzelne Checks testen:

BASH
CONFIG_FILE=/etc/linux-kuma-push/config.env /opt/linux-kuma-push/scripts/linux-cpu.sh
CONFIG_FILE=/etc/linux-kuma-push/config.env /opt/linux-kuma-push/scripts/linux-temperature.sh
CONFIG_FILE=/etc/linux-kuma-push/config.env /opt/linux-kuma-push/scripts/linux-smart.sh

Lokale Diagnose:

BASH
CONFIG_FILE=/etc/linux-kuma-push/config.env /opt/linux-kuma-push/tools/test-local.sh

1.7 Automatische Ausführung per Cron

Die aktuelle Version bringt bereits ein Cron-Beispiel mit. Dieses kann direkt nach /etc/cron.d/ kopiert werden:

BASH
cp /opt/linux-kuma-push/cron.example /etc/cron.d/linux-kuma-push

Der Inhalt sieht so aus:

CRON
* * * * * root CONFIG_FILE=/etc/linux-kuma-push/config.env /opt/linux-kuma-push/scripts/run-all.sh >/dev/null 2>&1

Damit werden alle aktivierten Linux-Checks jede Minute ausgeführt.

Prüfen:

BASH
cat /etc/cron.d/linux-kuma-push

Optional mit Logdatei:

CRON
* * * * * root CONFIG_FILE=/etc/linux-kuma-push/config.env /opt/linux-kuma-push/scripts/run-all.sh >> /var/log/linux-kuma-push.log 2>&1

2. NAS mit Uptime Kuma per SNMP überwachen

Repository:

https://github.com/realarna/NAS-Uptime-Kuma-Push-Monitor

Das NAS-Paket ist herstellerübergreifend aufgebaut. Es nutzt SNMP, liest je nach Hersteller und Modell verschiedene OIDs aus und sendet die Ergebnisse an Uptime Kuma.

2.1 Unterstützte Hersteller

Die aktuelle Version ist für folgende NAS-Systeme vorbereitet:

| Hersteller | Vendor-Wert |
|---|---|
| Synology DSM | synology |
| QNAP QTS / QuTS hero | qnap |
| Buffalo TeraStation / LinkStation | buffalo |
| TrueNAS / FreeNAS | truenas |
| ASUSTOR ADM | asustor |
| NETGEAR ReadyNAS | readynas |

UGREEN NAS / UGOS ist bewusst nicht enthalten, weil aktuell keine ausreichend stabile öffentlich dokumentierte Vendor-MIB in das Paket aufgenommen wurde.

2.2 Was wird überwacht?

Je nach Hersteller und verfügbaren SNMP-Werten:

  • SNMP-Erreichbarkeit / Health
  • CPU-Auslastung
  • RAM-Auslastung
  • freier Speicherplatz
  • Disk-/SMART-/Health-Status
  • RAID-/Pool-/Volume-/ZFS-Status
  • System-/CPU-/Disk-Temperaturen
  • Netzwerkfehler RX/TX

Nicht jedes NAS liefert jeden Wert per SNMP. Fehlende Checks können in der Config erlaubt oder durch leere Push-URLs deaktiviert werden.

2.3 SNMP auf der NAS aktivieren

Beispiel QNAP:

TEXT
Systemsteuerung
→ Netzwerk & Dateidienste
→ SNMP
→ SNMP-Dienst aktivieren
→ SNMP v2c aktivieren
→ Community setzen, z. B. monitoring

Wichtig: Der Monitoring-Host muss die NAS per SNMP erreichen können.

Test vom Monitoring-Host:

BASH
snmpget -v2c -c monitoring 10.10.7.20 1.3.6.1.2.1.1.1.0

2.4 Voraussetzungen installieren

Auf dem Linux-/Proxmox-Host, auf dem die Scripts laufen:

BASH
apt update
apt install -y snmp curl jq

Optional für ReadyNAS-SSH-Fallback:

BASH
apt install -y openssh-client

2.5 Script installieren

BASH
cd /tmp
git clone https://github.com/realarna/NAS-Uptime-Kuma-Push-Monitor.git
cd NAS-Uptime-Kuma-Push-Monitor
chmod +x install.sh scripts/*.sh tools/*.sh
./install.sh

Installationspfad:

TEXT
/opt/nas-kuma-push
/etc/nas-kuma-push/conf.d/

Die aktuelle Version ist für den Multi-NAS-Modus vorbereitet. Auch wenn nur eine NAS überwacht wird, ist eine eigene Config-Datei unter /etc/nas-kuma-push/conf.d/ empfohlen.

2.6 QNAP-Config erstellen

Mit dem Helper-Script:

BASH
/opt/nas-kuma-push/tools/new-config.sh qnap qnap-backup
nano /etc/nas-kuma-push/conf.d/qnap-backup.env

Alternativ manuell kopieren:

BASH
cp /opt/nas-kuma-push/examples/conf.d/nas-qnap.example.env /etc/nas-kuma-push/conf.d/qnap-backup.env
nano /etc/nas-kuma-push/conf.d/qnap-backup.env

2.7 Beispiel-Config für QNAP

BASH
NAS_VENDOR="qnap"
NAS_HOST="10.10.7.20"
NAS_DISPLAY_NAME="auto"

SNMP_VERSION="2c"
SNMP_COMMUNITY="monitoring"
SNMP_TIMEOUT=2
SNMP_RETRIES=0
SNMP_CMD_TIMEOUT=8
CURL_MAX_TIME=10
CACHE_DIR="/var/tmp/nas-kuma-push"

PUSH_URL_HEALTH="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_HEALTH"
PUSH_URL_CPU="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_CPU"
PUSH_URL_MEMORY="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_MEMORY"
PUSH_URL_STORAGE="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_STORAGE"
PUSH_URL_DISKS="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_DISKS"
PUSH_URL_RAID="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_RAID"
PUSH_URL_TEMPERATURE="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_TEMP"
PUSH_URL_NETWORK="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_QNAP_NET"

MAX_CPU_PERCENT=90
MAX_MEMORY_PERCENT=90

# Wichtig für QNAP/Linux:
# Cache und Buffers werden als verfügbar gezählt.
MEMORY_MODE="available"

MIN_STORAGE_FREE_PERCENT=15
MAX_SYSTEM_TEMP_C=75
MAX_DISK_TEMP_C=55
MAX_NETWORK_ERRORS=0

ALLOW_MISSING_DISK_STATUS="true"
ALLOW_MISSING_RAID_STATUS="true"
ALLOW_MISSING_TEMPERATURE="true"
STORAGE_LOCK_ENABLE="true"
STORAGE_FORCE_METHOD="auto"

2.8 QNAP testen

SNMP-Basistest:

BASH
CONFIG_FILE=/etc/nas-kuma-push/conf.d/qnap-backup.env /opt/nas-kuma-push/tools/test-snmp.sh

Discovery der verfügbaren Werte:

BASH
CONFIG_FILE=/etc/nas-kuma-push/conf.d/qnap-backup.env /opt/nas-kuma-push/tools/discover-values.sh

Alle Checks für diese eine NAS:

BASH
CONFIG_FILE=/etc/nas-kuma-push/conf.d/qnap-backup.env /opt/nas-kuma-push/scripts/run-all.sh

Alle Configs im Multi-NAS-Modus:

BASH
CONFIG_GLOB="/etc/nas-kuma-push/conf.d/*.env" /opt/nas-kuma-push/scripts/run-multi.sh

2.9 Automatische Ausführung per Cron

Die aktuelle Version bringt eine Cron-Datei für den Multi-NAS-Modus mit:

BASH
cp /opt/nas-kuma-push/cron.multi.example /etc/cron.d/nas-kuma-push-multi

Der Inhalt:

CRON
* * * * * root CONFIG_GLOB=/etc/nas-kuma-push/conf.d/*.env /opt/nas-kuma-push/scripts/run-multi.sh >/dev/null 2>&1

Damit werden alle NAS-Configs unter /etc/nas-kuma-push/conf.d/ jede Minute geprüft.

3. FortiGate Firewall mit Uptime Kuma überwachen

Repository:

https://github.com/realarna/FortiGate-Uptime-Kuma-Push-Monitor

Das FortiGate-Paket nutzt die FortiOS REST API. Es ist dafür gedacht, wichtige Firewall-Werte an Uptime Kuma zu senden.

3.1 Was wird überwacht?

Aktuell sind folgende Checks vorgesehen:

| Check | Beschreibung |
|---|---|
| API Health | API-Erreichbarkeit und Token |
| CPU | CPU-Auslastung in Prozent |
| Memory | RAM-/Memory-Auslastung in Prozent |
| Sessions | Session-Anzahl oder Bewertung gegen Grenzwert |
| Interfaces | definierte Interfaces auf Up/Link prüfen |
| IPsec VPN | definierte IPsec-Tunnel oder Phase2-Status prüfen |
| HA | HA-/Cluster-Status, soweit API-Felder vorhanden |
| SD-WAN | definierte SD-WAN Health Checks prüfen |

Hinweis: FortiOS-Versionen und Modelle können unterschiedliche API-Strukturen liefern. Die Scripts enthalten deshalb Endpoint-Overrides und Diagnose-Tools.

3.2 FortiGate vorbereiten

Auf der FortiGate sollte ein eigener API-User nur für das Monitoring erstellt werden.

Empfehlung:

TEXT
API User: uptime-kuma-api
Rechte: read-only / monitor-only
Trusted Host: IP des Monitoring-Servers
VDOM: root oder gewünschter VDOM
Auth: REST API Token

Wichtig:

  • API-Token niemals in GitHub veröffentlichen
  • Token nicht in Screenshots oder Videos zeigen
  • Trusted Host auf den Monitoring-Server einschränken
  • API nicht öffentlich ins Internet freigeben
  • Wenn möglich gültiges Zertifikat verwenden

3.3 Voraussetzungen installieren

Auf dem Monitoring-Host:

BASH
apt update
apt install -y curl python3 unzip

3.4 Script installieren

BASH
cd /tmp
git clone https://github.com/realarna/FortiGate-Uptime-Kuma-Push-Monitor.git
cd FortiGate-Uptime-Kuma-Push-Monitor
chmod +x install.sh scripts/*.sh tools/*.sh scripts/*.py
./install.sh

Installationspfade:

TEXT
/opt/fortigate-kuma-push
/etc/fortigate-kuma-push/config.env

3.5 Uptime-Kuma-Push-Monitore anlegen

Beispiele:

TEXT
FortiGate - API
FortiGate - CPU
FortiGate - Memory
FortiGate - Sessions
FortiGate - Interfaces
FortiGate - IPsec
FortiGate - HA
FortiGate - SD-WAN

Empfohlen:

TEXT
Heartbeat Interval: 120 Sekunden
Retries: 1 oder 2

3.6 Config bearbeiten

BASH
nano /etc/fortigate-kuma-push/config.env

Minimalbeispiel:

BASH
FORTIGATE_URL="https://10.10.10.1"
FORTIGATE_TOKEN="DEIN_API_TOKEN"
FORTIGATE_VDOM="root"
FORTIGATE_DISPLAY_NAME="auto"
FORTIGATE_NAME=""

# Bei selbstsigniertem Zertifikat true setzen.
INSECURE_SSL="true"

CURL_CONNECT_TIMEOUT=5
CURL_MAX_TIME=15

PUSH_URL_API="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_API"
PUSH_URL_CPU="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_CPU"
PUSH_URL_MEMORY="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_MEMORY"
PUSH_URL_SESSIONS="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_SESSIONS"
PUSH_URL_INTERFACES="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_INTERFACES"
PUSH_URL_IPSEC="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_IPSEC"
PUSH_URL_HA="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_HA"
PUSH_URL_SDWAN="http://DEIN-UPTIME-KUMA:3001/api/push/TOKEN_FGT_SDWAN"

MAX_CPU_PERCENT=85
MAX_MEMORY_PERCENT=82

# 0 = Sessions nur melden, nicht kritisch bewerten
MAX_SESSION_COUNT=0

# Beispiele: "wan1 wan2 internal" oder "port1,port2"
MONITOR_INTERFACES="wan1"

# Beispiele: "HQ-to-Branch Branch2-VPN"
MONITOR_IPSEC_TUNNELS=""

# Falls FortiOS einen Tunnel findet, aber kein klares Statusfeld liefert.
# Nur als Existenzcheck nutzen.
IPSEC_NO_STATUS_OK="false"

HA_EXPECTED_MODE="auto"
HA_STANDALONE_OK="true"

MONITOR_SDWAN_CHECKS=""

ENDPOINT_SYSTEM_STATUS="/api/v2/monitor/system/status"
ENDPOINT_RESOURCE_PRIMARY="/api/v2/monitor/system/resource/usage"
ENDPOINT_RESOURCE_FALLBACK="/api/v2/monitor/system/resource"
ENDPOINT_SESSION="/api/v2/monitor/firewall/session?summary=true&count=1"
ENDPOINT_INTERFACE="/api/v2/monitor/system/interface/select?include_vlan=true"
ENDPOINT_IPSEC="/api/v2/monitor/vpn/ipsec"
ENDPOINT_HA="/api/v2/monitor/system/ha/status"
ENDPOINT_SDWAN="/api/v2/monitor/virtual-wan/health-check"

DEBUG=0

Nicht benötigte Checks einfach leer lassen:

BASH
PUSH_URL_SDWAN=""

3.7 FortiGate API testen

API Health prüfen:

BASH
CONFIG_FILE=/etc/fortigate-kuma-push/config.env /opt/fortigate-kuma-push/tools/test-api.sh

Interfaces, IPsec, HA und SD-WAN Werte entdecken:

BASH
CONFIG_FILE=/etc/fortigate-kuma-push/config.env /opt/fortigate-kuma-push/tools/discover-values.sh

Rohdaten eines Endpoints anzeigen:

BASH
CONFIG_FILE=/etc/fortigate-kuma-push/config.env /opt/fortigate-kuma-push/tools/dump-endpoint.sh ipsec

Mögliche Parameter:

TEXT
system
resource
session
interface
ipsec
ha
sdwan

Alle aktivierten Checks starten:

BASH
CONFIG_FILE=/etc/fortigate-kuma-push/config.env /opt/fortigate-kuma-push/scripts/run-all.sh

3.8 Automatische Ausführung per Cron

Die aktuelle Version enthält eine passende Cron-Beispieldatei:

BASH
cp /opt/fortigate-kuma-push/cron.example /etc/cron.d/fortigate-kuma-push

Der Inhalt:

CRON
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

* * * * * root CONFIG_FILE=/etc/fortigate-kuma-push/config.env /opt/fortigate-kuma-push/scripts/run-all.sh >/dev/null 2>&1

4. Troubleshooting

Push-URL timeoutet

Wenn das Script Meldungen wie diese ausgibt:

TEXT
curl: (28) Connection timed out after 10001 milliseconds

prüfe zuerst, ob der Monitoring-Host Uptime Kuma erreichen kann:

BASH
nc -vz DEIN-UPTIME-KUMA 3001
curl -v --max-time 10 http://DEIN-UPTIME-KUMA:3001

Eine Push-URL direkt testen:

BASH
curl -v --max-time 10 "http://DEIN-UPTIME-KUMA:3001/api/push/DEIN_TOKEN?status=up&msg=test&ping=1"

Wenn Uptime Kuma hinter einem Reverse Proxy läuft, ist für interne Scripts oft die direkte interne Adresse stabiler:

BASH
http://10.10.13.58:3001/api/push/TOKEN

statt:

BASH
https://deine-domain.example/api/push/TOKEN

Uptime Kuma zeigt im Diagramm „Ping“ an

Uptime Kuma nennt den numerischen Wert bei Push-Monitoren intern weiterhin ping. Das ist normal. Die Scripts senden dort je nach Check zum Beispiel Prozentwerte, Temperaturen oder Zählerwerte.

Deshalb sollten die Monitore eindeutig benannt werden:

TEXT
Proxmox - CPU %
Proxmox - Temperatur °C
QNAP - Speicher frei %
FortiGate - Sessions

NAS liefert nicht alle Werte

Nicht jedes NAS liefert alle Werte per SNMP. Manche Geräte liefern keine Temperatur, keinen vollständigen RAID-Status oder keine SMART-Werte.

Dann entweder die Push-URL leer lassen:

BASH
PUSH_URL_TEMPERATURE=""

oder Missing-Werte erlauben:

BASH
ALLOW_MISSING_TEMPERATURE="true"
ALLOW_MISSING_RAID_STATUS="true"
ALLOW_MISSING_DISK_STATUS="true"

FortiGate IPsec wird nicht sauber erkannt

Rohdaten prüfen:

BASH
CONFIG_FILE=/etc/fortigate-kuma-push/config.env /opt/fortigate-kuma-push/tools/dump-endpoint.sh ipsec

Bei FortiOS 7.4.x ist oft proxyid[].status das entscheidende Feld. Wenn keine eindeutigen Statusfelder vorhanden sind, kann testweise gesetzt werden:

BASH
IPSEC_NO_STATUS_OK="true"

Das ist aber nur ein Existenzcheck und kein echter Up/Down-Tunnelcheck.

5. Sicherheitshinweise

Für alle drei Script-Pakete gilt:

  • Push-URLs niemals veröffentlichen
  • API-Tokens niemals in GitHub committen
  • SNMP-Community nicht öffentlich zeigen
  • FortiGate API-User nur mit Read-only-/Monitor-Rechten verwenden
  • Trusted Host auf den Monitoring-Server beschränken
  • .env-Dateien nicht veröffentlichen
  • Logs und Debug-Ausgaben vor GitHub-Issues anonymisieren

Eine .gitignore sollte echte Config-Dateien immer ausschließen.

Fazit

Uptime Kuma ist von Haus aus ein sehr gutes Tool für einfache Erreichbarkeitsprüfungen. Mit Push Scripts kann man es aber deutlich erweitern und auch Werte überwachen, die sonst eher klassischen Monitoring-Systemen vorbehalten sind.

Für ein Homelab, kleinere IT-Umgebungen oder ergänzende Statuschecks ist diese Kombination sehr praktisch:

  • Uptime Kuma bleibt übersichtlich und einfach.
  • Die Scripts liefern tiefere Informationen.
  • Jeder Check ist einzeln sichtbar.
  • Die Einrichtung bleibt nachvollziehbar.

Wer ein vollwertiges Enterprise-Monitoring benötigt, sollte weiterhin Lösungen wie Checkmk, Zabbix, LibreNMS oder Prometheus prüfen. Wer aber schnell und flexibel mehr aus Uptime Kuma herausholen möchte, bekommt mit diesen Push Scripts eine starke Erweiterung.

GitHub Repositorys

Die im Beitrag verwendeten Script-Pakete findest du in diesen öffentlichen GitHub-Repositorys:

- Linux / Proxmox Monitoring:
https://github.com/realarna/uptimekuma-linuxmonitoring

- NAS Monitoring für QNAP, Synology, Buffalo, TrueNAS, ASUSTOR und NETGEAR ReadyNAS:
https://github.com/realarna/NAS-Uptime-Kuma-Push-Monitor

- FortiGate Firewall Monitoring per REST API:
https://github.com/realarna/FortiGate-Uptime-Kuma-Push-Monitor