Überwachung und Gesundheit der Geräteflotte
Leitfaden zur Geräteflottenüberwachung: was zu erfassen ist, Dashboards und Alerting, Heartbeats, automatisierte Wiederherstellung und Kapazitätsplanung für Handy-Farmen.
Geräteflottenüberwachung ist die Praxis, die Verfügbarkeit, den Zustand und den Session-Status jedes Geräts kontinuierlich zu verfolgen, sodass Probleme als Alerts auftauchen und häufige Ausfälle sich selbst heilen. Eine Flotte ohne Überwachung degradiert lautlos; diese Seite behandelt, was zu messen ist, wie zu alarmieren ist und wie die Wiederherstellung automatisiert wird.
- Heartbeats are the backbone — a device that stops reporting is a problem regardless of the underlying cause.
- Effective availability requires a healthy automation session, not just power and network connectivity.
- Build automated recovery (reconnect, restart app, reboot) before manual firefighting.
- Alert on trends, not just thresholds — a slow battery-health decline matters as much as a hard offline.
- Health data feeds capacity planning: know real available headroom before scheduling work.
Was zu überwachen ist
Behandeln Sie jedes Gerät als kleinen Host, der Telemetrie ausgibt. Die wesentlichen Signale:
Verfügbarkeit (online/offline)
Das grundlegendste Signal: Ist das Gerät vorhanden und erreichbar? Bei Android entspricht das dem ADB-Gerätestatus (device, offline, unauthorized oder nicht vorhanden). Bei iOS ist es die Verbindung des Host-Agenten zum Gerät. Verfolgen Sie Zustandsübergänge, nicht nur den aktuellen Zustand — Flackern zwischen online und offline deutet auf Kabel-, Strom- oder Hub-Probleme hin (siehe USB-Hubs und Laden im großen Maßstab).
Akku- und Wärmezustand
- Akku-% — für Duty-Cycling und um Geräte zu erfassen, die keine Ladung halten.
- Akkutemperatur — anhaltend hohe Temperatur signalisiert thermische oder Ladeprobleme.
- Akkuzustand/-kapazität — eine sich langsam verändernde Metrik, die das Lebensende vorhersagt.
- Ladezustand — lädt ein Gerät, das laden sollte, auch tatsächlich?
Setzen Sie einen harten Alert auf ungewöhnliche Akkutemperatur und jedes Gerät, das Laden meldet, aber nie an Ladung gewinnt. Das kann auf eine ausfallende oder aufblähende Zelle hindeuten — untersuchen Sie physisch und entfernen Sie das Gerät, wenn Sie Wölbung oder übermäßige Hitze feststellen.
Speicher
Automatisierung erzeugt im Laufe der Zeit Logs, Bildschirmaufnahmen und App-Daten, die Geräte füllen. Wenig freier Speicher verursacht Installationsfehler und instabile Sessions. Alarmieren Sie bei einer Speicher-Untergrenze und geben Sie Speicherplatz nach Möglichkeit automatisch frei.
Konnektivität
- Netzwerkerreichbarkeit — WLAN/Mobilfunk aktiv, kann die von Jobs benötigten Endpunkte erreichen.
- Durchsatz/Latenz, falls Ihr Workload netzwerksensibel ist.
- IP-/Konnektivitätszustand, relevant für Ihren Aufbau.
Session- und ADB-/Host-Status
Über "ist es online" hinaus verfolgen Sie, ob die Automatisierungs-Session gesund ist: Ist die ADB-Verbindung autorisiert, lebt die Appium/WebDriverAgent-Session, reagiert das Gerät auf Eingaben? Ein Gerät kann eingeschaltet und online sein und trotzdem eine feststeckende Session haben, die stillschweigend jeden Job scheitern lässt.
Bei Android ist dieser Session-Status direkt über adb devices sichtbar (device, unauthorized, offline). Bei iOS gibt es keine entsprechende Einzelbefehlsansicht — der Zustand ergibt sich daraus, ob der macOS-Host noch eine aktive Verbindung zum Gerät hält und ob der auf dem Gerät laufende WebDriverAgent-Prozess noch antwortet, weshalb sich iOS-Überwachung typischerweise eher auf die eigene Berichterstattung des Host-Agenten stützt als auf eine geräteseitige Abfrage.
App-Abstürze und Fehler
Erfassen Sie Absturzsignale (Android Logcat/ANRs, iOS-Absturzprotokolle) und Fehlerraten auf Job-Ebene. Ein Gerät, das plötzlich beginnt, bei einem bestimmten App-Ablauf zu scheitern, braucht Aufmerksamkeit, selbst wenn jede Hardware-Metrik grün aussieht.
Überwachungsmatrix
| Signal | Alert on | |
|---|---|---|
| Availability | ADB state / host agent connection | Offline, flapping |
| Battery % | dumpsys battery / iOS API | Below/above duty-cycle band |
| Battery temp | Battery telemetry | High temperature |
| Battery health | OEM/iOS capacity reading | Slow decline, low capacity |
| Storage | Filesystem stats | Below free-space floor |
| Session status | ADB auth, Appium session | Unauthorized, dead session |
| App crashes | logcat, crash logs | Crash/ANR spikes |
Heartbeats
Ein Heartbeat ist eine periodische "Ich lebe, und das ist mein Zustand"-Meldung jedes Geräts (oder seines Host-Agenten) an einen zentralen Collector. Designprinzipien:
- Pushen statt nur pollen, wo möglich — Geräte melden sich in einem Intervall, und fehlende Heartbeats sind selbst der Alert.
- Eine kompakte Zustands-Payload einbeziehen (Akku, Temperatur, Speicher, Session-Status), sodass eine Nachricht die meisten Signale abdeckt.
- Ein Intervall wählen, das Aktualität gegen Overhead abwägt — oft ein paar zehn Sekunden bis zu ein paar Minuten.
- N aufeinanderfolgende verpasste Heartbeats als offline behandeln, um Alerts bei einzelnen kurzen Aussetzern zu vermeiden.
Heartbeats verwandeln "wir haben nicht bemerkt, dass Gerät 43 vor drei Tagen ausgefallen ist" in ein sofortiges, umsetzbares Signal.
Dashboards und Alerting
Sammeln Sie Telemetrie in einem Zeitreihenspeicher und visualisieren Sie sie. Sie brauchen kein exotisches Tooling — ein Standard-Metrik-Stack (eine Zeitreihendatenbank plus eine Dashboard-Schicht) funktioniert gut.
Dashboards sollten auf einen Blick beantworten:
- Wie viele Geräte sind gerade online im Verhältnis zur Gesamtzahl?
- Welche Geräte sind ungesund, und warum?
- Flottenweite Trends: Verteilung des Akkuzustands, Absturzraten, Speicherdruck.
Alerting sollte nach Schweregrad unterscheiden:
- Alarmwürdig: viele Geräte gleichzeitig offline (wahrscheinlich Strom/Hub/Netzwerk), ungewöhnliche Akkutemperatur.
- Ticketwürdig: ein einzelnes feststeckendes Gerät, Speicher nahe der Untergrenze, steigende Absturzrate.
- Trend: allmählicher Rückgang des Akkuzustands, der Ersatzplanung anzeigt.
Alarmieren Sie bei Raten und Trends, nicht nur bei Momentanschwellenwerten — eine Flotte degradiert allmählich, und das frühe Signal ist meist eine Steigung, kein Abgrund.
Automatisierte Wiederherstellung
Das Ziel ist, die häufigen Ausfälle ohne Mensch zu lösen. Bauen Sie eine Eskalationsleiter und versuchen Sie zuerst den günstigsten Fix:
- Session neu verbinden — ADB/Appium bei Android oder die Host-zu-Gerät-Verbindung und WebDriverAgent bei iOS neu herstellen, bevor etwas Schwereres versucht wird.
- App neu starten — einen feststeckenden App-Zustand bereinigen.
- Gerät neu starten — löst viele feststeckende Zustände (offline ADB oder eine abgebrochene iOS-Host-Verbindung, Speicherdruck, instabile Sessions).
- Power-Cycling über Smart-PDU/USB-Schalter, wenn ein Soft-Reboot es nicht wiederherstellt.
- Isolieren und einen Menschen alarmieren — nachdem die Leiter fehlschlägt, das Gerät aus der Planung entfernen und ein Ticket öffnen.
Die iOS-Wiederherstellung hat eine zusätzliche Besonderheit: Der signierte Build von WebDriverAgent kann ablaufen oder neu installiert werden müssen, unabhängig davon, ob mit dem Telefon etwas nicht stimmt, sodass ein "tote Session"-Alert bei iOS gegen die Gültigkeit des Provisioning-Profils geprüft werden sollte, bevor ein Hardwareproblem angenommen wird.
Sichern Sie die automatisierte Wiederherstellung ab, damit sie echte Probleme nicht verdeckt: Wenn ein Gerät stündlich neu gestartet werden muss, ist das ein Signal zur Untersuchung, nicht zum stillen Weiter-Neustarten. Protokollieren Sie jede Wiederherstellungsaktion und alarmieren Sie bei der Wiederherstellungshäufigkeit.
Wiederherstellung ist eng mit der Planung verknüpft — ein sich selbst heilendes Gerät sollte automatisch wieder in den Arbeitspool eintreten, sobald es gesund ist. Siehe Planung und Orchestrierung dafür, wie der Überwachungszustand die Job-Zuweisung steuert.
Kapazitätsplanung
Überwachungsdaten zeigen Ihre tatsächliche Kapazität, die immer geringer ist als Ihre Geräteanzahl. Nutzen Sie sie, um:
- Effektive Verfügbarkeit zu berechnen — Geräte, die online, gesund und session-bereit sind, nicht nur eingeschaltet.
- Auslastung zu verfolgen, um zu wissen, wie viel Spielraum besteht, bevor mehr Geräte oder Hosts benötigt werden — bei einer iOS-Stufe schließt das die macOS-Host-Kapazität ein, da jeder Host nur so viele gleichzeitige WebDriverAgent-Sessions treiben kann, bevor er statt der Telefone selbst zum Engpass wird.
- Ausfallraten mit der Last zu korrelieren, um den Punkt zu finden, an dem Durchsatz die Zuverlässigkeit zu kosten beginnt.
- Ersatzplanung aus Akkuzustandstrends zu speisen, damit Sie vor Ausfällen kaufen.
Alles zusammenfügen
Ein gesunder Überwachungsaufbau sieht so aus: Jedes Gerät (oder sein Host-Agent) sendet Heartbeats mit einer kompakten Health-Payload; Telemetrie landet in einem Zeitreihenspeicher; Dashboards zeigen die Live-Online-Anzahl und die Zustandsverteilung; Alerts trennen flottenweite Vorfälle von Einzelgerät-Tickets; eine automatisierte Wiederherstellungsleiter behandelt die Routineausfälle und isoliert die hartnäckigen; und die Kapazitätsplanung läuft auf Basis der effektiven Verfügbarkeit, nicht der rohen Geräteanzahl.
All dies aufzubauen und zu pflegen ist selbst ein fortlaufendes Engineering-Engagement, keine einmalige Einrichtung — was ein großer Grund ist, warum Teams, die Bauen vs. Mieten abwägen, diese gesamte Schicht oft an einen gemanagten Anbieter auslagern, statt sie intern zu betreiben.