DEV Community: Francisco das Chagas

Um terço da conta era para medir

Francisco das Chagas — Thu, 22 Oct 2026 11:30:00 +0000

Fiz o rateio da conta de infraestrutura por domínio de negócio.

O segundo maior item não era produto. Era observabilidade: cerca de um terço da conta, quase empatado com o produto principal.

E o que esse terço comprava:

85,6% dos logs de produção não podiam ser atribuídos a nenhum serviço;
a ferramenta que media tudo não media a si mesma. Sem esse dado, o "um terço" podia ser 25% ou 44%, dependendo do tamanho real das máquinas dela.

No mesmo levantamento apareceu o outro lado:

as máquinas estavam a 18% de CPU, enquanto os containers passavam de 100% do próprio limite;
o autoscaling escalava por CPU um serviço que saturava por memória, então nunca acionou;
quase metade do ambiente de desenvolvimento ficava ociosa.

O gargalo não era falta de máquina. Era configuração, e corrigir configuração tem custo de licença zero.

A economia de maior retorno que encontrei não era trocar de ferramenta. Era corrigir o único ponto que gerava aqueles logs sem dono, com um alvo estimado de 30% a 40% do custo de observabilidade, sem perder nenhum sinal que alguém usa.

O que mudou a conversa com a gestão foi o custo por unidade de negócio. Todo negócio tem a sua: o pedido num e-commerce, a transação num banco, a consulta numa clínica, a entrega numa operação de logística, o aluno numa plataforma de ensino. "A infra custa X por mês" não leva a decisão nenhuma. "Cada unidade custa alguns centavos" leva. A pergunta "quanto custa atender mais um cliente?" passou a ter resposta.

Quanto a sua observabilidade custa em relação ao produto que ela observa?

O p99 foi para 60 s e nada ficou mais lento

Francisco das Chagas — Tue, 20 Oct 2026 11:30:00 +0000

Depois de um deploy, o p99 de um serviço virou uma linha reta em 60 segundos.

Pânico? Não. Ninguém tinha reclamado, e nenhum erro tinha aparecido.

O que aconteceu foi o seguinte: o deploy passou a instrumentar a espera da fila. O serviço fica escutando a fila por até 60 segundos e, se nada chega, volta a escutar.

99% dos spans de recebimento eram esperas vazias;
eram cerca de 136 mil spans por dia só de "nada aconteceu";
o processamento real continuava em 85 ms (p50) e 248 ms (p99).

A métrica não piorou. Ela passou a medir outra coisa.

O mesmo erro já tinha aparecido semanas antes, numa regra compartilhada: uma conexão ociosa de longa duração fixava o p99 em 60 segundos para todos os serviços.

A correção não exigiu deploy: bastou filtrar o span certo.

Duas lições de custo:

Mais instrumentação não é mais verdade. Cada span novo precisa responder a uma pergunta. Se não responde, é custo de ingestão sem retorno.
Antes de acionar o time por causa de um gráfico, pergunte: "o que mudou na forma de medir?". Nem sempre foi o sistema que mudou.

Você sabe quanto da sua telemetria é espera ociosa?

Cada funcionalidade é uma forma nova de errar

Francisco das Chagas — Thu, 15 Oct 2026 11:30:00 +0000

Um alerta notificou: "taxa de erro de 12,22%".

Fiz a conta à mão: 3 falhas em 19 execuções dão 15,8%.

O alerta não estava quebrado. Estava calculando outra coisa. A fórmula era avaliada minuto a minuto e depois tirava a média das razões. Com amostras pequenas, o número parece certo e é errado.

Depois disso comecei a colecionar esses casos. Todos são funcionalidades, e todos erram em silêncio:

Pedir 30 ou 60 dias de dados devolvia os mesmos 21 dias, sem nenhum aviso.
Uma consulta em lote devolveu resultados idênticos para filtros diferentes. O erro foi de 24 vezes.
Um alerta de "reinício em loop" só dispararia com 3 reinícios no mesmo minuto. Nunca disparou, com 19 reinícios em 7 dias.
Uma variável de dashboard sem valor padrão deixou 41 de 46 painéis em branco.

Nenhum desses casos mostrou erro na tela. Todos devolveram um número plausível.

Esse é o custo escondido das ferramentas cheias de recursos: cada recurso é mais uma forma de dar a resposta errada com cara de certa.

O que resolveu foi aritmética de padaria. Depois da correção, o alerta mostrou 13,04%, e a conta à mão deu 3 de 23. Bateu exato.

Minha regra hoje: número novo só vale depois de conferido por soma, com uma conta que dá para fazer no papel.

Qual foi a última vez que você conferiu à mão um número que um dashboard te deu?

85% dos logs não diziam se eram erro

Francisco das Chagas — Tue, 13 Oct 2026 11:30:00 +0000

Fiz a primeira linha de base completa da plataforma. O número que mais me incomodou:

85% dos logs de produção chegavam sem severidade.

São dezenas de milhões de linhas por dia sem dizer se eram informação, aviso ou erro. Qualquer alerta do tipo "me avise quando houver erro" enxergava só 15% da operação.

Três achados do mesmo dia:

o ambiente de desenvolvimento consumia 47% de toda a ingestão de logs e não tinha nenhum alerta;
cada consulta de 24 horas varria cerca de 13 GB;
dois serviços respondiam por mais da metade do volume de produção.

A causa não era a ferramenta. Era uma linha de configuração: o log da aplicação saía no console, sem formato estruturado. Essa única causa gerava três sintomas: sem severidade, volume inflado (uma consulta SQL virava de 10 a 20 linhas) e nenhuma ligação com o trace.

Eu pagava para guardar, pagava para consultar e não conseguia responder à pergunta mais básica.

Mais volume não é mais visibilidade. Na maioria das vezes, é só mais custo.

E aqui entra a IA. Ela lê log muito bem, mas não lê o que nunca foi registrado. Nenhum modelo recupera a severidade que a aplicação não escreveu.

A correção certa não é filtrar volume. É consertar o que é emitido na origem.

Que percentual dos seus logs chega com severidade preenchida? Alguém já mediu?

Poucos alertas, um trace, zero impacto

Francisco das Chagas — Thu, 08 Oct 2026 11:30:00 +0000

Uma semana depois do incidente de 8h40, os alertas novos começaram a tocar, sempre por volta das 21:30.

O pool de conexões do banco subiu noite após noite: 90%, 89%, 94,8%. Na terceira noite, 36 conexões recusadas.

Era a mesma falha daquele incidente, em formação. Só que desta vez sabíamos três noites antes.

O diagnóstico não veio de uma ferramenta cara. Veio de duas coisas simples:

um alerta de conexões que tocou antes do impacto;
um trace, na janela do alerta, que ligou um job noturno de um serviço à saturação do banco de outro.

O job fazia uma consulta por ponto de medição. A leitura no banco chegava a 12 vezes o normal, com a escrita parada. Era o padrão N+1, conhecido de qualquer livro.

Do primeiro erro ao diagnóstico, levou menos de um dia útil. O impacto em cliente foi zero.

No mesmo dia, corrigi dois alertas que davam falso positivo. Menos ruído é o que faz o time acreditar no próximo alerta.

A lição para quem gere risco: detectar cedo é barato. Poucos alertas certos e uma forma de ligar a causa ao sintoma valem mais que cem painéis.

Spoiler: a correção do job ainda não saiu. Detectar não é corrigir, e isso é assunto de outro post.

No seu time, o último incidente foi detectado pelo alerta ou pelo cliente?

Antes de criar, eu apaguei

Francisco das Chagas — Tue, 06 Oct 2026 11:30:00 +0000

Depois do incidente de 8h40, a tentação era criar dezenas de alertas e painéis.

Fiz o contrário. Comecei pelo inventário:

10 dashboards, 8 deles templates importados no mesmo dia, e nenhum sobre os nossos serviços;
15 "visões salvas" que ninguém abria;
4 alertas.

A meta que escrevi foi cortar: 5 dashboards, 4 visões de investigação, uns 11 alertas.

Três regras saíram desse dia e valem para qualquer time:

Uma regra bem agrupada cobre tudo. Um único alerta de taxa de erro, agrupado por serviço, cobre os 24 serviços. Não são necessários 24 alertas.
Nunca suba o limite global para acomodar um serviço doente. Trate o doente.
Alerta que disparou sem ninguém agir é ajustado ou apagado na mesma semana. Alerta ignorado duas vezes é apagado.

Antes de ligar qualquer coisa, testei com dado real. Se medisse por span, e não por requisição, 6 serviços teriam disparado no primeiro dia. Seria ruído desde a estreia.

E o registro honesto: um mês depois, 6 dos templates "consolidados" ainda estavam lá, duplicados. O custo de ter demais é esse: ninguém apaga.

Ferramenta rica em funcionalidade é convite para acumular. Gestão é dizer não.

Quantos dashboards o seu time tem, e quantos alguém abriu nos últimos 30 dias?

8h40 com todos os dados e nenhum aviso

Francisco das Chagas — Fri, 02 Oct 2026 11:30:00 +0000

00:34. Uma manutenção automática do provedor de nuvem reciclou os dois servidores do banco de produção, com 6 minutos de intervalo entre eles.

O failover funcionou em 4 segundos. A segunda reciclagem derrubou o novo primário no meio da ressincronização, e a réplica travou.

Ficamos 8h40 operando sem cópia de segurança do banco. Ninguém soube.

Quem avisou foi o negócio, pelo impacto, horas depois.

A parte mais incômoda veio depois: reconstruímos o incidente inteiro, minuto a minuto. Os logs estavam lá. As métricas estavam lá.

E a métrica de saúde da réplica marcou "saudável" durante as 8h40.

Três lições que eu levo desse dia:

Telemetria sem alerta é arqueologia. O MTTR não veio de falta de dado, veio de falta de detecção.
Métrica de status mente. O que mostrou o problema foi a diferença entre o que o primário escreveu e o que a réplica aplicou, uma conta simples.
Um aviso num card do chat não acorda ninguém às 00:34.

Em gestão de risco, a pergunta certa não é "temos o dado?". É "quanto tempo levamos para saber?". Naquele dia, a resposta foi 8 horas.

Esse incidente virou o caso de negócio de tudo o que veio depois.

Se o seu banco perdesse a réplica agora, em quanto tempo você saberia?

Migrar para o Envoy Gateway não é trocar YAML

Francisco das Chagas — Thu, 01 Oct 2026 22:48:32 +0000

O ingress-nginx não recebe patch de segurança desde março de 2026.
Ele continua funcionando, e é por isso que o risco passa despercebido.

A saída recomendada pelo próprio Kubernetes é a Gateway API, e o Envoy Gateway é uma das implementações dela. A tentação é tratar a migração como tradução: pegar cada anotação e reescrever no formato novo. Só que a migração não se resume a trocar YAML.

No nginx, cada app levava a própria regra de IP numa anotação. No Envoy, a regra sobe para uma SecurityPolicy no Gateway compartilhado. Ela muda de dono: sai do time da app e vai para a plataforma. Um erro, que antes afetava uma app, agora afeta todas as rotas.

Ela também muda de camada. A allowlist por IP é uma decisão de L3 tomada em L7. O proxy filtra o IP que ele acredita ser o do cliente. Se houver SNAT no caminho, todo mundo vira o IP do node. Se o X-Forwarded-For for aceito sem critério, qualquer um escreve o próprio IP.

Abaixo, os pontos que a documentação confirma e que eu teria errado se só traduzisse as anotações: SNAT, precedência por substituição, CIDR largo copiado e o API gateway que vira o único cliente.

Qual regra de acesso sumiu, ou abriu demais, numa migração que parecia só de ferramenta no seu ambiente?

Referências

Três ferramentas, nenhuma resposta

Francisco das Chagas — Thu, 01 Oct 2026 22:48:29 +0000

Hoje toda conversa de operação termina em "qual IA a gente coloca aqui?".

Vou começar esta série por outra pergunta: quantas das suas ferramentas você consegue provar que funcionam?

Nós tínhamos três. Logs numa, métricas em outra, APM numa terceira.

Quando alguma coisa quebrava, a resposta não estava em nenhuma delas.

Não faltava ferramenta. Faltava garantia:

a aplicação parava de mandar log para o cluster e ninguém percebia;
quando o log chegava, não trazia a informação necessária;
a retenção dependia de uma rotina de limpeza configurada à mão, e nem sempre funcionava: guardávamos meses de dados quando o combinado eram semanas.

Eram três lugares para procurar e nenhum dono. Em gestão de risco, isso tem nome: controle que só existe no papel. A auditoria marca "temos monitoramento", mas no dia do incidente ninguém confia nele.

A saída não foi comprar uma quarta ferramenta. Foi juntar logs, métricas e traces num lugar só (open source, com OpenTelemetry) e usar menos coisa, não mais.

Nos próximos posts, vou contar o que isso revelou, com números: o que funcionou, o que custou, onde a IA ajudou e onde errou.

Comece pela pergunta do início: das ferramentas de observabilidade que você paga hoje, quantas você já testou num incidente real?