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):

  1. Online/Offline — Ping oder ADB-Check. Die Base-Line für alles.
  2. Akku-Stand — Unter 30%? ACC funktioniert nicht richtig, Gerät lädt nicht.
  3. Akku-Temperatur — Über 38°C? Kühlungsproblem oder defekter Akku.
  4. 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.

Mein aktuelles Setup: Python-Monitor (Level 2) + Uptime Kuma für die "rote Lampe" (wenn der Python-Monitor selbst ausfällt, kriege ich einen Uptime-Kuma-Alert). Zwei Ebenen, damit ich nicht blind bin, wenn das Monitoring selbst crasht.

Alerting-Kanäle: Was wann wohin?

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.