Monitoring et santé d'une flotte d'appareils
Guide de monitoring d'une flotte d'appareils : que suivre, tableaux de bord et alertes, heartbeats, récupération automatisée, et planification de capacité pour les fermes de téléphones.
Le monitoring d'une flotte d'appareils est la pratique consistant à suivre en continu la disponibilité, la santé et l'état de session de chaque appareil afin que les problèmes se manifestent sous forme d'alertes et que les pannes courantes s'auto-réparent. Une flotte sans monitoring se dégrade silencieusement ; cette page couvre ce qu'il faut mesurer, comment alerter, et comment automatiser la récupération.
- 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.
Que surveiller
Traitez chaque appareil comme un petit hôte émettant de la télémétrie. Les signaux essentiels :
Disponibilité (en ligne/hors ligne)
Le signal le plus basique : l'appareil est-il présent et joignable ? Pour Android, cela correspond à l'état de l'appareil ADB (device, offline, unauthorized, ou absent). Pour iOS, c'est la connexion de l'agent hôte à l'appareil. Suivez les transitions d'état, pas seulement l'état actuel — un basculement répété entre en ligne et hors ligne indique un problème de câble, d'alimentation ou de hub (voir hubs USB et charge à grande échelle).
Santé de la batterie et thermique
- % de batterie — pour le cyclage d'usage et pour repérer les appareils qui ne tiennent plus la charge.
- Température de la batterie — une température élevée soutenue signale des problèmes thermiques ou de charge.
- Santé/capacité de la batterie — une métrique à évolution lente qui prédit la fin de vie.
- État de charge — un appareil censé être en charge l'est-il réellement ?
Mettez en place une alerte stricte sur une température de batterie anormale et tout appareil qui signale être en charge sans jamais gagner de charge. Cela peut indiquer une cellule défaillante ou en train de gonfler — investiguez physiquement et retirez l'appareil si vous constatez un gonflement ou une chaleur excessive.
Stockage
L'automatisation génère des journaux, des enregistrements d'écran et des données d'application qui remplissent les appareils au fil du temps. Un espace libre faible provoque des échecs d'installation et des sessions instables. Alertez sur un seuil plancher d'espace libre et récupérez de l'espace automatiquement lorsque possible.
Connectivité
- Joignabilité réseau — Wi-Fi/cellulaire actif, capacité à atteindre les points de terminaison dont les tâches ont besoin.
- Débit/latence si votre workload est sensible au réseau.
- État IP/connectivité pertinent pour votre installation.
État de session et ADB/hôte
Au-delà de « est-ce en ligne », suivez si la session d'automatisation est saine : la connexion ADB est-elle autorisée, la session Appium/WebDriverAgent est-elle active, l'appareil répond-il aux entrées ? Un appareil peut être alimenté et en ligne tout en ayant une session bloquée qui échoue silencieusement à chaque tâche.
Sur Android, cet état de session est directement visible via adb devices (device, unauthorized, offline). Sur iOS, il n'existe pas d'équivalent en une seule commande — la santé provient du fait que l'hôte macOS détient toujours une connexion active à l'appareil et que le processus WebDriverAgent exécuté sur l'appareil répond toujours, si bien que le monitoring iOS s'appuie généralement davantage sur le rapport propre de l'agent hôte que sur une requête côté appareil.
Plantages d'application et erreurs
Capturez les signaux de plantage (logcat/ANR Android, journaux de plantage iOS) et les taux d'erreur au niveau des tâches. Un appareil qui commence soudainement à échouer sur un flux d'application spécifique nécessite de l'attention même si chaque métrique matérielle semble au vert.
Matrice de monitoring
| 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
Un heartbeat est un rapport périodique « je suis vivant et voici mon état » envoyé par chaque appareil (ou son agent hôte) à un collecteur central. Principes de conception :
- Poussez, ne vous contentez pas d'interroger lorsque possible — les appareils signalent leur présence à intervalle régulier, et les heartbeats manquants constituent eux-mêmes l'alerte.
- Incluez une charge utile d'état compacte (batterie, température, stockage, état de session) afin qu'un seul message couvre la plupart des signaux.
- Choisissez un intervalle qui équilibre fraîcheur et surcharge — souvent de quelques dizaines de secondes à quelques minutes.
- Considérez N heartbeats manqués consécutifs comme un état hors ligne pour éviter d'alerter sur de simples anomalies ponctuelles.
Les heartbeats transforment un « nous n'avons pas remarqué que l'appareil 43 était mort il y a trois jours » en un signal immédiat et actionnable.
Tableaux de bord et alertes
Collectez la télémétrie dans un entrepôt de séries temporelles et visualisez-la. Aucun outillage exotique n'est nécessaire — une pile de métriques standard (une base de données de séries temporelles plus une couche de tableaux de bord) fonctionne bien.
Les tableaux de bord doivent répondre en un coup d'œil à :
- Combien d'appareils sont en ligne actuellement par rapport au total ?
- Quels appareils sont en mauvaise santé, et pourquoi ?
- Tendances à l'échelle de la flotte : répartition de la santé des batteries, taux de plantage, pression sur le stockage.
Les alertes doivent distinguer la gravité :
- Dignes d'un appel d'urgence : de nombreux appareils hors ligne simultanément (probablement alimentation/hub/réseau), température de batterie anormale.
- Dignes d'un ticket : un seul appareil bloqué, stockage approchant du plancher, taux de plantage en hausse.
- Tendance : déclin progressif de la santé des batteries signalant une planification de remplacement.
Alertez sur les taux et tendances, pas seulement sur des seuils instantanés — une flotte se dégrade progressivement, et le signal précoce est généralement une pente, pas une falaise.
Récupération automatisée
L'objectif est de résoudre les pannes courantes sans intervention humaine. Construisez une échelle d'escalade et essayez d'abord le correctif le moins coûteux :
- Reconnecter la session — rétablir ADB/Appium sur Android, ou la connexion hôte-appareil et WebDriverAgent sur iOS, avant toute chose plus lourde.
- Redémarrer l'application — effacer un état d'application bloqué.
- Redémarrer l'appareil — résout de nombreux états bloqués (ADB hors ligne ou connexion hôte iOS interrompue, pression mémoire, sessions instables).
- Cycler l'alimentation via un PDU intelligent ou un commutateur USB si un redémarrage logiciel ne le rétablit pas.
- Mettre en quarantaine et alerter un humain — une fois l'échelle épuisée, retirer l'appareil de la planification et ouvrir un ticket.
La récupération iOS comporte une particularité supplémentaire : le build signé de WebDriverAgent peut expirer ou nécessiter une réinstallation indépendamment de tout problème sur le téléphone, donc une alerte de « session morte » sur iOS mérite d'être vérifiée par rapport à la validité du profil de provisionnement avant de présumer un problème matériel.
Encadrez la récupération automatisée pour qu'elle ne masque pas de vrais problèmes : si un appareil nécessite un redémarrage toutes les heures, c'est un signal à investiguer, pas à continuer de redémarrer silencieusement. Journalisez chaque action de récupération et alertez sur la fréquence de récupération.
La récupération s'articule étroitement avec la planification — un appareil auto-réparé devrait réintégrer automatiquement le pool de travail une fois sain. Voir planification et orchestration pour savoir comment l'état de monitoring conditionne l'attribution des tâches.
Planification de capacité
Les données de monitoring indiquent votre capacité réelle, toujours inférieure à votre nombre d'appareils. Utilisez-les pour :
- Calculer la disponibilité effective — les appareils qui sont en ligne, sains et prêts en session, pas simplement alimentés.
- Suivre l'utilisation pour savoir combien de marge existe avant d'avoir besoin de plus d'appareils ou d'hôtes — pour un palier iOS, cela inclut la capacité des hôtes macOS, puisque chaque hôte ne peut piloter qu'un nombre limité de sessions WebDriverAgent concurrentes avant de devenir le goulot d'étranglement plutôt que les téléphones.
- Corréler les taux de panne avec la charge pour trouver le point où le débit commence à coûter de la fiabilité.
- Alimenter la planification des remplacements à partir des tendances de santé des batteries afin d'acheter en avance des pannes.
Assembler le tout
Une installation de monitoring saine ressemble à ceci : chaque appareil (ou agent hôte) émet des heartbeats avec une charge utile de santé compacte ; la télémétrie atterrit dans un entrepôt de séries temporelles ; les tableaux de bord affichent le décompte en ligne en direct et la répartition de la santé ; les alertes séparent les incidents à l'échelle de la flotte des tickets d'appareil unique ; une échelle de récupération automatisée gère les pannes routinières et met en quarantaine les cas récalcitrants ; et la planification de capacité fonctionne à partir de la disponibilité effective, pas du nombre brut d'appareils.
Construire et maintenir tout cela est en soi un engagement d'ingénierie continu, pas une mise en place ponctuelle — ce qui explique en grande partie pourquoi les équipes qui pèsent construire vs louer déplacent souvent toute cette couche vers un fournisseur géré plutôt que de la faire tourner en interne.