Monitorización y salud de la flota de dispositivos
Guía de monitorización de flotas de dispositivos: qué rastrear, paneles y alertas, latidos, recuperación automatizada y planificación de capacidad para granjas de teléfonos.
La monitorización de flotas de dispositivos es la práctica de rastrear continuamente la disponibilidad, salud y estado de sesión de cada dispositivo para que los problemas surjan como alertas y los fallos comunes se autorreparen. Una flota sin monitorización se degrada silenciosamente; esta página cubre qué medir, cómo alertar y cómo automatizar la recuperación.
- 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.
Qué monitorizar
Trata cada dispositivo como un pequeño host que emite telemetría. Las señales esenciales:
Disponibilidad (en línea/fuera de línea)
La señal más básica: ¿está el dispositivo presente y accesible? Para Android, esto se corresponde con el estado del dispositivo ADB (device, offline, unauthorized o ausente). Para iOS, es la conexión del host-agente al dispositivo. Rastrea las transiciones de estado, no solo el estado actual — la alternancia entre en línea y fuera de línea apunta a problemas de cable, energía o hub (ver hubs USB y carga a escala).
Salud de batería y térmica
- % de batería — para el ciclado de carga y para detectar dispositivos que no mantienen la carga.
- Temperatura de batería — una temperatura alta sostenida indica problemas térmicos o de carga.
- Salud/capacidad de la batería — una métrica de evolución lenta que predice el fin de vida útil.
- Estado de carga — ¿está cargando realmente un dispositivo que debería estar cargando?
Configura una alerta dura para temperatura de batería anómala y para cualquier dispositivo que reporte estar cargando pero nunca gane carga. Esto puede indicar una celda fallando o hinchándose — investiga físicamente y retira el dispositivo si encuentras hinchazón o calor excesivo.
Almacenamiento
La automatización genera registros, grabaciones de pantalla y datos de apps que llenan los dispositivos con el tiempo. El poco espacio libre causa fallos de instalación y sesiones inestables. Avisa ante un umbral mínimo de espacio libre y recupera espacio automáticamente cuando sea posible.
Conectividad
- Alcanzabilidad de red — Wi-Fi/datos móviles activos, capacidad de alcanzar los endpoints que los trabajos necesitan.
- Rendimiento/latencia si tu carga de trabajo es sensible a la red.
- Estado de IP/conectividad relevante para tu configuración.
Estado de sesión y ADB/host
Más allá de "está en línea", rastrea si la sesión de automatización está sana: ¿está autorizada la conexión ADB, está viva la sesión de Appium/WebDriverAgent, responde el dispositivo a la entrada? Un dispositivo puede estar encendido y en línea y aun así tener una sesión atascada que falla silenciosamente en cada trabajo.
En Android este estado de sesión es visible directamente desde adb devices (device, unauthorized, offline). En iOS no hay una vista equivalente con un solo comando — la salud proviene de si el host macOS todavía mantiene una conexión activa con el dispositivo y si el proceso WebDriverAgent que se ejecuta en el dispositivo sigue respondiendo, así que la monitorización de iOS normalmente se apoya más en el propio reporte del agente de host que en una consulta del lado del dispositivo.
Fallos y errores de apps
Captura señales de fallo (logcat/ANR de Android, registros de fallos de iOS) y tasas de error a nivel de trabajo. Un dispositivo que de repente empieza a fallar en un flujo de app específico necesita atención aunque todas las métricas de hardware se vean bien.
Matriz de monitorización
| 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 |
Latidos (heartbeats)
Un latido es un reporte periódico de "estoy vivo y este es mi estado" de cada dispositivo (o su agente de host) a un colector central. Principios de diseño:
- Empuja, no solo consultes cuando sea posible — los dispositivos reportan en un intervalo, y los latidos ausentes son en sí mismos la alerta.
- Incluye una carga útil de estado compacta (batería, temperatura, almacenamiento, estado de sesión) para que un solo mensaje cubra la mayoría de las señales.
- Elige un intervalo que equilibre la frescura frente a la sobrecarga — a menudo de decenas de segundos a un par de minutos.
- Trata N latidos consecutivos perdidos como fuera de línea para evitar alertar por fallos puntuales.
Los latidos convierten "no notamos que el dispositivo 43 murió hace tres días" en una señal inmediata y accionable.
Paneles y alertas
Reúne la telemetría en un almacén de series temporales y visualízala. No necesitas herramientas exóticas — una pila de métricas estándar (una base de datos de series temporales más una capa de paneles) funciona bien.
Los paneles deben responder de un vistazo:
- ¿Cuántos dispositivos están en línea ahora mismo frente al total?
- ¿Qué dispositivos no están sanos, y por qué?
- Tendencias de toda la flota: distribución de salud de batería, tasas de fallos, presión de almacenamiento.
Las alertas deben distinguir la gravedad:
- Dignas de aviso urgente: muchos dispositivos fuera de línea a la vez (probablemente energía/hub/red), temperatura de batería anómala.
- Dignas de ticket: un único dispositivo atascado, almacenamiento cerca del umbral, tasa de fallos en aumento.
- Tendencia: declive gradual de salud de batería que señala planificación de sustitución.
Avisa por tasas y tendencias, no solo por umbrales instantáneos — una flota se degrada gradualmente, y la señal temprana suele ser una pendiente, no un precipicio.
Recuperación automatizada
El objetivo es resolver los fallos comunes sin un humano. Construye una escalera de escalado y prueba primero la solución más barata:
- Reconectar la sesión — restablecer ADB/Appium en Android, o la conexión host-a-dispositivo y WebDriverAgent en iOS, antes de nada más pesado.
- Reiniciar la app — limpiar un estado de app atascado.
- Reiniciar el dispositivo — resuelve muchos estados atascados (ADB fuera de línea o una conexión de host iOS caída, presión de memoria, sesiones inestables).
- Ciclo de energía vía PDU inteligente o interruptor USB si un reinicio suave no lo recupera.
- Poner en cuarentena y avisar a un humano — después de que la escalera falle, retira el dispositivo de la programación y abre un ticket.
La recuperación en iOS tiene una arruga extra: la compilación firmada de WebDriverAgent puede caducar o necesitar reinstalación independientemente de que algo vaya mal con el teléfono, así que una alerta de "sesión muerta" en iOS merece comprobarse contra la validez del perfil de aprovisionamiento antes de asumir un problema de hardware.
Protege la recuperación automatizada para que no enmascare problemas reales: si un dispositivo necesita reiniciarse cada hora, esa es una señal para investigar, no para seguir reiniciando en silencio. Registra cada acción de recuperación y avisa por frecuencia de recuperación.
La recuperación se combina estrechamente con la programación — un dispositivo que se autorrepara debería reincorporarse automáticamente al grupo de trabajo una vez sano. Ver programación y orquestación para cómo el estado de monitorización condiciona la asignación de trabajos.
Planificación de capacidad
Los datos de monitorización te dicen tu capacidad real, que siempre es menor que tu recuento de dispositivos. Úsalos para:
- Calcular la disponibilidad efectiva — dispositivos que están en línea, sanos y listos para sesión, no simplemente encendidos.
- Rastrear la utilización para saber cuánto margen existe antes de necesitar más dispositivos u hosts — para un nivel iOS esto incluye la capacidad del host macOS, ya que cada host solo puede llevar tantas sesiones de WebDriverAgent concurrentes antes de convertirse en el cuello de botella en lugar de los teléfonos.
- Correlacionar las tasas de fallo con la carga para encontrar el punto en el que el rendimiento empieza a costar fiabilidad.
- Alimentar la planificación de sustituciones a partir de las tendencias de salud de batería, para comprar con antelación a los fallos.
Juntándolo todo
Una configuración de monitorización sana se ve así: cada dispositivo (o agente de host) emite latidos con una carga útil de salud compacta; la telemetría llega a un almacén de series temporales; los paneles muestran el recuento en línea en vivo y la distribución de salud; las alertas separan los incidentes de toda la flota de los tickets de un solo dispositivo; una escalera de recuperación automatizada gestiona los fallos rutinarios y pone en cuarentena a los tercos; y la planificación de capacidad se basa en la disponibilidad efectiva, no en el recuento bruto de dispositivos.
Construir y mantener todo esto es en sí mismo un compromiso de ingeniería continuo, no una configuración puntual — lo que explica en gran parte por qué los equipos que sopesan construir frente a alquilar a menudo trasladan toda esta capa a un proveedor gestionado en lugar de operarla internamente.