Monitoring und Alerting für große Device-Flotten — Von Ping bis Prometheus
75 Geräte im Dauerbetrieb. Nachts um 3 Uhr. Du schläfst. Irgendwo fliegt ein WiFi-Kanal raus, 8 Geräte sind offline, und du merkst es erst um 9 Uhr morgens, wenn du manuell durchscrollst. Genau so war mein erstes Jahr. Heute hab ich ein Monitoring, das mich weckt, bevor die Geräte länger als 3 Minuten offline sind.
Was du monitoren solltest (und was nicht)
Der Anfängerfehler: Alles monitoren. CPU, RAM, Disk-I/O, Netzwerk-Traffic, Akku-Temperatur... das sind 15 Metriken pro Gerät × 75 = 1125 Datenpunkte. Absoluter Overkill und du ertrinkst in Alerts. Meine Erfahrung: Nur monitoren, was handlungsrelevant ist.
Meine essentiellen Metriken (4 pro Gerät):
- Online/Offline — Ping oder ADB-Check. Die Base-Line für alles.
- Akku-Stand — Unter 30%? ACC funktioniert nicht richtig, Gerät lädt nicht.
- Akku-Temperatur — Über 38°C? Kühlungsproblem oder defekter Akku.
- ADB-Verbindung — Kann ich ADB-Commands ausführen oder ist die Session tot?
Level 1: Uptime Kuma (für 10-30 Geräte)
Für kleinere Setups oder als Einstieg ist Uptime Kuma perfekt. Einfacher Docker-Container, Web-UI, Ping-Monitoring mit Telegram/Discord-Notifications:
# docker-compose.yml für Uptime Kuma
services:
uptime-kuma:
image: louislam/uptime-kuma:latest
container_name: uptime-kuma
volumes:
- ./data:/app/data
ports:
- "3001:3001"
restart: unless-stopped
In Uptime Kuma legst du für jedes Gerät einen Ping-Monitor an (10.0.10.11, 10.0.10.12...). Das ist für 20-30 Geräte okay — für 75 wird die UI aber unübersichtlich. Dann steig auf Level 2 oder 3 um.
Level 2: Custom Python Monitor (30-75 Geräte)
Mein selbstgebauter Monitor — ein Python-Skript, das alle 60 Sekunden alle Geräte checkt:
#!/usr/bin/env python3
# phone-farm-monitor.py
import subprocess, time, json, requests
DEVICES = [f"10.0.10.{i}" for i in range(11, 86)] # 75 Geräte
TELEGRAM_BOT_TOKEN = "..."
TELEGRAM_CHAT_ID = "..."
def check_device(ip):
try:
# ADB-Check (besser als Ping — testet echte Konnektivität)
result = subprocess.run(
["adb", "-s", f"{ip}:5555", "shell", "echo OK"],
capture_output=True, timeout=5
)
if b"OK" in result.stdout:
return "online"
return "no_adb"
except:
return "offline"
def get_battery(ip):
try:
r = subprocess.run(
["adb", "-s", f"{ip}:5555", "shell", "dumpsys battery"],
capture_output=True, timeout=5, text=True
)
level = [l for l in r.stdout.split("\n") if "level:" in l]
temp = [l for l in r.stdout.split("\n") if "temperature:" in l]
return {
"level": int(level[0].split(":")[1].strip()) if level else -1,
"temp": int(temp[0].split(":")[1].strip()) / 10 if temp else -1
}
except:
return None
while True:
alerts = []
for ip in DEVICES:
status = check_device(ip)
if status != "online":
alerts.append(f"🔴 {ip} ist {status}")
continue
bat = get_battery(ip)
if bat:
if bat["level"] < 30:
alerts.append(f"⚠️ {ip} Akku bei {bat['level']}%")
if bat["temp"] > 38:
alerts.append(f"🔥 {ip} Temperatur {bat['temp']}°C")
if alerts:
msg = "Phone Farm Alert:\n" + "\n".join(alerts)
requests.post(
f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage",
json={"chat_id": TELEGRAM_CHAT_ID, "text": msg}
)
time.sleep(60)
Level 3: Prometheus + Grafana (75+ Geräte, professionell)
Für richtig große Setups oder wenn du historische Daten willst: Prometheus mit einem ADB-Exporter. Ich nutze einen selbstgebauten Exporter, der per ADB die Geräte abfragt und die Metriken als Prometheus-Endpoint bereitstellt.
Alerting-Kanäle: Was wann wohin?
- Telegram (Sofort-Alerts): Gerät offline > 3 Minuten, Akku-Temperatur > 40°C
- Email (Täglicher Report): Uptime-Statistiken, Akku-Durchschnitte, Geräte mit > 3 Offline-Events
- Dashboard (Grafana): Live-Übersicht aller Geräte, aber nur zum Reinschauen — keine Alerts
Der wichtigste Alert, den ich fast vergessen hätte
Als ich anfing, hab ich nur "Gerät offline" monitort. Eines Tages war ein Gerät online, ADB funktionierte — aber die App, für die ich das Gerät betrieben habe, war gecrasht. Das Gerät war aus Farm-Sicht tot, aber mein Monitoring sagte "alles gut".
Seitdem hab ich Application-Level-Checks: Ein Cronjob auf dem Gerät, der stündlich checkt, ob die Ziel-App läuft, und notfalls neustartet. Das hat meine "silent failures" auf null reduziert.
Fazit: Fang mit Uptime Kuma an. Wenn du über 30 Geräte gehst, bau dir einen Python-Monitor. Ab 75+ Geräten oder wenn du historische Daten brauchst: Prometheus. Aber monitore nur, was du auch wirklich nutzt — sonst ertrinkst du in Daten.