Monitorização e Saúde da Frota de Dispositivos

A monitorização da frota de dispositivos é a prática de acompanhar continuamente a disponibilidade, a saúde e o estado de sessão de cada dispositivo, de modo a que os problemas surjam como alertas e as falhas comuns se autocorrijam. Uma frota sem monitorização degrada-se silenciosamente; esta página aborda o que medir, como alertar e como automatizar a recuperação.

O que monitorizar

Trate cada dispositivo como uma pequena máquina anfitriã que emite telemetria. Os sinais essenciais:

Disponibilidade (online/offline)

O sinal mais básico: o dispositivo está presente e acessível? No Android, isto corresponde ao estado do dispositivo no ADB (device, offline, unauthorized, ou ausente). No iOS, é a ligação do agente anfitrião ao dispositivo. Acompanhe as transições de estado, não apenas o estado atual — oscilar entre online e offline aponta para problemas de cabo, energia ou hub (ver hubs USB e carregamento em escala).

Saúde da bateria e térmica

• Percentagem de bateria — para ciclos de utilização e para detetar dispositivos que não retêm carga.
• Temperatura da bateria — temperatura elevada sustentada indica problemas térmicos ou de carregamento.
• Saúde/capacidade da bateria — uma métrica de evolução lenta que prevê o fim de vida útil.
• Estado de carregamento — um dispositivo que devia estar a carregar está mesmo a carregar?

Armazenamento

A automação gera registos, gravações de ecrã e dados de aplicações que enchem os dispositivos ao longo do tempo. Pouco espaço livre causa falhas de instalação e sessões instáveis. Configure um alerta para um limiar mínimo de espaço livre e recupere espaço automaticamente sempre que possível.

Conectividade

• Alcançabilidade de rede — Wi-Fi/dados móveis ativos, capacidade de alcançar os endpoints de que as tarefas precisam.
• Débito/latência, se a sua carga de trabalho for sensível à rede.
• Estado de IP/conectividade relevante para a sua configuração.

Estado de sessão e ADB/anfitrião

Além de "está online", acompanhe se a sessão de automação está saudável: a ligação ADB está autorizada, a sessão Appium/WebDriverAgent está ativa, o dispositivo responde a comandos? Um dispositivo pode estar ligado e online mas ter uma sessão bloqueada que falha silenciosamente todas as tarefas.

No Android, este estado de sessão é visível diretamente a partir de adb devices (device, unauthorized, offline). No iOS não há uma visão equivalente por comando único — a saúde vem de saber se o anfitrião macOS ainda mantém uma ligação ativa ao dispositivo e se o processo WebDriverAgent em execução no dispositivo continua a responder, pelo que a monitorização em iOS tende a apoiar-se mais nos relatórios do próprio agente anfitrião do que numa consulta ao dispositivo.

Falhas e erros de aplicações

Capture sinais de falhas (logcat/ANRs no Android, registos de falhas no iOS) e taxas de erro ao nível das tarefas. Um dispositivo que começa subitamente a falhar num fluxo específico de uma aplicação precisa de atenção, mesmo que todas as métricas de hardware pareçam normais.

Matriz de monitorização

Heartbeats

Um heartbeat é um relatório periódico de "estou vivo e este é o meu estado" enviado por cada dispositivo (ou pelo seu agente anfitrião) para um coletor central. Princípios de conceção:

• Envie, não se limite a consultar, sempre que possível — os dispositivos reportam a um intervalo regular, e a ausência de heartbeats é, por si só, o alerta.
• Inclua um payload de estado compacto (bateria, temperatura, armazenamento, estado de sessão), para que uma única mensagem cubra a maioria dos sinais.
• Escolha um intervalo que equilibre atualidade com sobrecarga — normalmente entre dezenas de segundos e um par de minutos.
• Trate N heartbeats consecutivos em falta como offline, para evitar alertas causados por picos isolados.

Os heartbeats transformam "não reparámos que o dispositivo 43 morreu há três dias" num sinal imediato e acionável.

Painéis e alertas

Reúna a telemetria numa base de dados de séries temporais e visualize-a. Não precisa de ferramentas exóticas — uma pilha de métricas padrão (uma base de dados de séries temporais mais uma camada de painéis) funciona bem.

Os painéis devem responder, à primeira vista:

• Quantos dispositivos estão online agora, face ao total?
• Que dispositivos estão com problemas de saúde, e porquê?
• Tendências a nível da frota: distribuição da saúde da bateria, taxas de falhas, pressão de armazenamento.

Os alertas devem distinguir gravidade:

• Dignos de aviso urgente: muitos dispositivos offline em simultâneo (provavelmente energia/hub/rede), temperatura de bateria anormal.
• Dignos de ticket: um único dispositivo bloqueado, armazenamento a aproximar-se do limite, taxa de falhas a subir.
• Tendência: declínio gradual da saúde da bateria, sinalizando planeamento de substituição.

Alerte com base em taxas e tendências, não apenas em limiares instantâneos — uma frota degrada-se gradualmente, e o sinal precoce é normalmente uma inclinação, não um precipício.

Recuperação automatizada

O objetivo é resolver as falhas comuns sem intervenção humana. Construa uma escada de escalonamento e tente primeiro a correção mais barata:

1. Reconectar a sessão — restabelecer ADB/Appium no Android, ou a ligação anfitrião-dispositivo e o WebDriverAgent no iOS, antes de qualquer coisa mais pesada.
2. Reiniciar a aplicação — limpar um estado de aplicação bloqueado.
3. Reiniciar o dispositivo — resolve muitos estados bloqueados (ADB offline ou uma ligação de anfitrião iOS perdida, pressão de memória, sessões instáveis).
4. Cortar e restabelecer a energia através de um PDU inteligente ou comutador USB, se uma reinicialização suave não o recuperar.
5. Colocar em quarentena e avisar uma pessoa — depois de a escada falhar, remova o dispositivo do agendamento e abra um ticket.

A recuperação em iOS tem uma particularidade extra: a compilação assinada do WebDriverAgent pode expirar ou precisar de ser reinstalada independentemente de haver algo errado com o telemóvel, pelo que um alerta de "sessão morta" em iOS vale a pena verificar contra a validade do perfil de aprovisionamento antes de assumir um problema de hardware.

Proteja a recuperação automatizada para que não mascare problemas reais: se um dispositivo precisa de ser reiniciado de hora a hora, isso é um sinal para investigar, não para continuar a reiniciar silenciosamente. Registe todas as ações de recuperação e alerte sobre a frequência de recuperação.

A recuperação está intimamente ligada ao agendamento — um dispositivo que se autorrecupera deve reentrar automaticamente no conjunto de trabalho assim que estiver saudável. Ver agendamento e orquestração para saber como o estado de monitorização condiciona a atribuição de tarefas.

Planeamento de capacidade

Os dados de monitorização indicam a sua capacidade real, que é sempre inferior ao número de dispositivos que possui. Use-os para:

• Calcular a disponibilidade efetiva — dispositivos que estão online, saudáveis e prontos para sessão, não apenas ligados.
• Acompanhar a utilização, para saber quanta margem existe antes de precisar de mais dispositivos ou máquinas anfitriãs — para um nível iOS isto inclui a capacidade das máquinas macOS, já que cada anfitrião só consegue suportar um determinado número de sessões WebDriverAgent simultâneas antes de se tornar o gargalo, em vez dos telemóveis.
• Correlacionar taxas de falha com a carga para encontrar o ponto em que o débito começa a custar fiabilidade.
• Alimentar o planeamento de substituições a partir das tendências de saúde da bateria, para comprar com antecedência às falhas.

A juntar tudo

Uma configuração de monitorização saudável tem este aspeto: cada dispositivo (ou agente anfitrião) emite heartbeats com um payload de saúde compacto; a telemetria chega a uma base de dados de séries temporais; os painéis mostram a contagem de dispositivos online em tempo real e a distribuição de saúde; os alertas separam incidentes a nível da frota de tickets de dispositivo único; uma escada de recuperação automatizada trata das falhas rotineiras e coloca em quarentena as mais persistentes; e o planeamento de capacidade assenta na disponibilidade efetiva, não na contagem bruta de dispositivos.

Construir e manter tudo isto é, por si só, um compromisso de engenharia contínuo, não uma configuração pontual — o que explica em boa parte por que razão as equipas que ponderam construir vs. alugar transferem muitas vezes esta camada inteira para um fornecedor gerido, em vez de a operarem internamente.