UniFi überwachen: Möglichkeiten und Grenzen

inping überwacht bei UniFi zwei Dinge: per HTTP(S), ob die Oberfläche der Konsole oder des Controllers antwortet, und mit dem Agenten den Linux-Server, wenn Sie UniFi selbst betreiben. Access Points, Switches und Clients sieht inping nicht, und der Agent läuft nicht auf einer UniFi-OS-Konsole.

Welche Möglichkeiten gibt es?

Welche Variante Sie haben, entscheidet über den Weg. Ubiquiti nennt als Cloud Gateways unter anderem UCG-Ultra, UCG-Max, UDM-Pro, UDM-SE und UDR; auch ein Cloud Key ist eine Konsole. Auf eigener Hardware gibt es den UniFi OS Server und den von Ubiquiti als „Legacy“ geführten Network Server.

Weg 1: Erreichbarkeit der Oberfläche prüfen

Der Runner stellt pro Intervall eine GET- oder HEAD-Anfrage und vergleicht den Statuscode mit dem erwarteten Wert. Mehr prüft er nicht: Anmeldung, Adoption von Geräten und Funknetze bleiben außen vor.

Port 8080 (Inform) und die UDP-Ports für STUN und Discovery dienen den Geräten. Ob die Geräte ihren Controller erreichen, zeigt eine HTTP-Prüfung nicht. Sehen Sie vorher nach, welchen Statuscode die Adresse liefert, und stellen Sie ihn als erwarteten Wert ein, Standard ist 200.

# Welchen Statuscode liefert die Konsole? -k nur für diesen Test: Es überspringt die Zertifikatsprüfung
curl -skL -o /dev/null -w '%{http_code}\n' https://192.168.1.1/

Zwei Einschränkungen, die Sie kennen sollten

Zertifikat. Der Runner prüft Zertifikate immer, eine Ausnahme lässt sich nicht einstellen. UniFi-Oberflächen arbeiten ab Werk üblicherweise mit einem selbstsignierten Zertifikat, was im Runner als TLS-Fehler und damit als Ausfall zählt. Weiterleitungen von HTTP auf HTTPS desselben Hosts verfolgt er, das Ergebnis bleibt also gleich.

Private Adressen. Die Runner von inping erreichen keine privaten Adressen. Für eine Konsole im LAN brauchen Sie einen eigenen Runner dort. Eine öffentliche Adresse für die Konsole einzurichten, nur um sie zu überwachen, empfehlen wir nicht. Anders liegt der Fall bei einem Controller, der ohnehin auf einem öffentlich erreichbaren Server mit gültigem Zertifikat läuft, etwa hinter einem Reverse Proxy: Den prüfen die Runner von inping ohne weitere Einrichtung.

Eigener Runner im LAN

Der Runner läuft unter Linux mit amd64 oder arm64, als Dienst oder im Docker-Container, zum Beispiel auf einem Raspberry Pi. Der Free-Tarif enthält 1 eigenen Runner.

1. Legen Sie ihn als Team-Admin unter Runner → Runner hinzufügen oder im Projekt unter Runner → Runner hinzufügen an. Der Dialog zeigt den Befehl mit Token. Einzelheiten stehen in der Installationsanleitung.
2. Erlauben Sie private Netze und starten Sie den Runner neu. Im Docker-Betrieb setzen Sie stattdessen INPING_PRIVATE_NETWORKS=true in der .env. Loopback und Link-Local-Adressen bleiben immer gesperrt.
3. Tragen Sie die Adresse als private IP oder mit interner Endung ein (.lan, .local, .internal, .home.arpa oder ohne Punkt). Nur solche Adressen bekommen die Runner von inping gar nicht erst zugeteilt. Ein öffentlicher Name, der auf eine private IP zeigt, würde von ihnen als Fehler gemeldet, und die Mehrheit der Runner entscheidet über den Status.

# /etc/inping/runner.toml auf dem Gerät mit dem Runner
private_networks = true

Konsole mit Werkszertifikat prüfen

Interne Adressen und ein von inping anerkanntes Zertifikat passen selten zusammen. Für eine Konsole im LAN ist das Ziel daher eine kleine Zwischenstation auf einem Linux-Gerät, das der Runner per HTTP erreicht und das die Konsole selbst per HTTPS aufruft, zum Beispiel mit Caddy. Das ist ein allgemeiner Reverse-Proxy-Weg und nicht von uns auf dieser Hardware getestet. Die Zertifikatsprüfung findet dann auf der Strecke zur Konsole nicht statt, begrenzen Sie den Zugriff auf diesen Port deshalb auf Ihr Netz.

# Caddyfile auf einem Linux-Gerät im LAN: HTTP nach innen, die Konsole dahinter per HTTPS
:8081 {
	reverse_proxy https://192.168.1.1 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

Im Projekt tragen Sie dann http://192.168.1.20:8081/ ein, mit dem Statuscode, den die Konsole dort liefert. Fällt die Zwischenstation aus, sieht das in inping wie ein Ausfall der Konsole aus.

Was ein Runner im LAN nicht meldet

Fällt der Internetzugang oder der Runner aus, kommen keine Ergebnisse bei inping an. Der Status bleibt dann auf dem letzten Stand, einen Alarm für einen stillen Runner gibt es derzeit nicht. Der Runner hebt Ergebnisse auf und sendet sie später nach. Gerade bei einem Gateway ist das wichtig: Fällt es aus, ist auch der Runner dahinter abgeschnitten. Deshalb gehört eine Sicht von außen dazu, siehe unten.

Weg 2: Agent auf dem selbst betriebenen Server

Betreiben Sie UniFi auf eigener Hardware, ist das aus Sicht von inping ein normaler Server, und der Agent gehört dorthin. Auch diese Kombination ist nicht von uns auf dieser Hardware getestet, sie folgt aber den Wegen, die wir für Linux und Docker beschreiben.

• UniFi OS Server. Laut Ubiquiti braucht er Ubuntu 24.04 oder neuer, Debian 13 oder neuer oder eine andere aktuelle Distribution mit systemd und Podman. Installieren Sie den Agenten wie auf jedem Linux-Server. Die Dienste in Podman meldet der Agent nicht als Services, sein Docker-Weg ist für die Docker-API gebaut und mit Podman nicht geprüft.
• Network Server aus dem APT-Paket. Dasselbe: Installation als Linux-Server. Das Paket unifi erscheint im Paketinventar. Schwachstellen gleicht inping für Host-Pakete mit den Hinweisen der Distribution ab, verlassen Sie sich für UniFi selbst also auf die Sicherheitshinweise von Ubiquiti.
• Network Application in Docker. Ein offizielles Image von Ubiquiti haben wir nicht gefunden, verbreitet ist etwa das von LinuxServer.io, das eine eigene MongoDB braucht. Den Agenten ergänzen Sie in derselben Compose-Datei wie unter Docker-Container überwachen beschrieben. Sie sehen dann pro Service CPU, Speicher, Netz, I/O und ob er läuft.

curl -fsSL https://www.inping.io/install.sh | INPING_TOKEN=<token> sudo --preserve-env=INPING_TOKEN sh -s --

Den Befehl mit echtem Token zeigt die App unter Agents → Agent hinzufügen. Sinnvoll sind auf einem solchen Server die Regeln für Platte und Arbeitsspeicher und der Offline-Alarm des Agenten.

Warum nicht der Agent auf der Konsole?

Wir unterstützen das nicht, und wir raten davon ab:

• Eine Konsole ist kein allgemeiner Server. Ubiquiti beschreibt selbst das Aktualisieren per SSH als nicht offiziell unterstützten Vorgang, einen vorgesehenen Weg für eigene Software haben wir in der Dokumentation von Ubiquiti nicht gefunden.
• Firmware-Updates entfernen solche Änderungen. Das Community-Projekt unifi-on-boot beschreibt, dass Updates das Root-Dateisystem neu aufbauen und installierte Pakete und Dienste verschwinden. Der Agent wäre also regelmäßig ohne Hinweis weg, und sein eigener Offline-Alarm wäre kein Zeichen für ein echtes Problem.
• Das Gerät trägt Ihr Netz. Fremdsoftware auf Router und Firewall vergrößert die Angriffsfläche genau dort, wo sie am wenigsten erwünscht ist.
• Auch inhaltlich wäre wenig gewonnen: Der Agent liest keine UniFi-Daten. Er würde CPU, Speicher und Platte der Konsole melden, keine Geräte und keine Clients.

Was ist mit Access Points, Switches und Clients?

Das kann inping nicht: Es gibt keine Werte pro Gerät, keine Clients, keine Funkkanäle und keine Portstatistik, weder über die UniFi-API noch über SNMP oder ICMP. Eine HTTP-Prüfung ist hierfür auch keine Lösung. Für diese Ebene gibt es passendere Werkzeuge:

• UniFi Alarm Manager: Alarme direkt aus UniFi, etwa für ausgefallene Geräte, per Push, E-Mail oder Webhook.
• SNMP in UniFi Network: Ubiquiti nennt Zabbix, PRTG und Nagios als Beispiele und weist darauf hin, dass USW-Flex- und Ultra-Switches kein SNMP unterstützen.

Beides ergänzt inping: UniFi und SNMP-Werkzeuge kennen das Netz, inping die Websites und Server dahinter.

Wie überwachen Sie ein UniFi-Netz sinnvoll?

1. Geräte und Funk im Alarm Manager von UniFi, denn dort liegen die Daten.
2. Sicht von außen. Haben Sie einen öffentlich erreichbaren Dienst hinter dem Gateway, prüfen ihn die Runner von inping aus anderen Standorten. Antwortet er nicht mehr, liegt es am Dienst, am Gateway oder am Internetzugang.
3. Sicht von innen. Ein Linux-Server im LAN mit Agent: Sein Offline-Alarm kommt von der Plattform, auch wenn im Netz nichts mehr sendet. Er sagt aber nur, dass keine Meldungen mehr ankommen, nicht weshalb.
4. Interne Dienste. Mit einem eigenen Runner im LAN prüfen Sie, was nur intern erreichbar ist, und sehen Antwortzeiten aus Sicht Ihres Netzes.

Was kostet das?

Der Free-Tarif reicht für den Einstieg: 2 Agenten, 1 eigener Runner und 10 URLs pro Projekt, höchstens alle 60 Sekunden geprüft. Die übrigen Tarife finden Sie unter Preise, die Installationswege unter Einbindung.

Häufige Fragen