Sem log você está no escuro: o que eu registro em toda aplicação

De onde eu falo

A importância de logs claros pra observabilidade numa aplicação. Parece grego, eu sei. Trocando em miúdos: log é vida.

Minha carteirada, pra você saber com quem está falando. Eu sou arquiteto de sistemas, de software e de infraestrutura. Cuido de uma série de coisas que a maioria das pessoas não faz ideia do que é: BGP, anúncio de prefixo, data center no Brasil e nos Estados Unidos.

Eu vinha me apresentando como engenheiro de infraestrutura. Alguém que tem CREA me xingou e falou que eu não podia usar, porque eu não tenho CREA. Não tenho mesmo. Então fica arquiteto, apesar de eu atuar com isso mais do que muita gente que tem.

A placa-mãe que foi pro beleléu

Eu gravei com uma placa-mãe de servidor dedicado na mão. É uma placa mais antiga, dual, de dois processadores octacore. Não lembro se ela tinha 256 GB de memória RAM. Essa placa foi pro beleléu.

E pra gente descobrir como uma placa-mãe vai pro beleléu, a gente precisa ter log da placa-mãe.

Quando eu compro um servidor que custa dezenas, às vezes centenas de milhares de reais, a gestão da placa é diferente da de um computador comum. A gente acessa o servidor remotamente com ele desligado. Pra quem não conhece, é bem interessante.

Ali dentro eu tenho vários monitoramentos da placa e do servidor:

• quanto de energia está passando pra placa-mãe;
• se tem alguma oscilação fora do que deveria ter;
• o firmware, e se está na hora de fazer update ou não;
• se ela começou a esquentar demais.

É com essas informações que eu sei se está na hora de trocar a placa ou se ela está prestes a morrer. Eu observo os dados da placa-mãe. Observabilidade.

Agora pensa comigo. Nesse hardware gastaram possivelmente milhões em pesquisa e desenvolvimento pra chegar nessas trilhas, nesse formato, nesse barramento de memória. E ele sai de fábrica registrando o que acontece com ele. Hardware eu também já queimei, e conto essa história em medo de subir em produção: como eu perdi o meu.

O vibe coder e o cafezinho

E o que acontece quando você, meu amigo vibe coder, está com o seu cafezinho, tranquilo, e fala: "tive uma ideia de um negócio, vou fazer um SaaS"?

Beleza, está tudo bem. O sol está aí pra todo mundo e nunca foi tão fácil empreender na vida. O que a gente precisa é não ficar no escuro.

Porque "na minha máquina funciona" é uma coisa. Botar em produção é outra. E quando você bota em produção, a aplicação já tem muitas pastas, muitos módulos, cada um com um tanto de arquivo, cada arquivo com um tanto de linha.

Agora me responde: quem está fazendo o quê? Onde? Quando?

Tá todo mundo ainda aprendendo a lidar com automação de IA pra valer, com skill, com agente. Isso ainda é um negócio obscuro. Tem muito CEO que não bota a mão na massa fazendo besteira com isso, às vezes supervalorizando, às vezes subvalorizando. Eu já falei do tipo de profissional que essa fase criou em sabor programador: cospe código e não sabe a receita. O log é o que te tira dessa turma.

Quem fez o quê, onde e quando, agora pro sistema

Se você conseguir responder essas quatro perguntas com log, você começa a ter um negócio que se chama vida.

Sabe aquele log de auditoria de usuário? "O usuário tal fez tal coisa." É mais ou menos isso. Só que a gente vai trazer a mesma regra pra dentro do sistema.

Quando é o date time completo. No dia da gravação o exemplo que eu dei foi: 2 de junho, 8h42 da manhã e 30 segundos. Desse jeito, até o segundo.

E o quê não é só "fez um insert". É o que tem dentro do insert: inseriu tal e tal coisa.

"Nossa, Josimar, mas vai ter mais log do que aplicação?" Sim, vai.

Por quê? Porque o amigo vibe coder não é sênior. Tem sênior fazendo vibe code, com certeza. Mas eu estou falando com a galera que ainda não entende muito bem o que está fazendo. Eu estou te dando uma trilha, pra te ajudar a evitar problema quando você botar em produção.

O checklist de inicialização: subiu, mas subiu pra quê?

Na hora que você sobe a aplicação, seja no terminal, seja no Docker, você tem que ver no log o checklist dela subindo:

• a aplicação subiu, e subiu na porta tal;
• consultou o banco de dados;
• conectou no banco em memória, no Redis;
• conectou na API externa. Conseguiu ou não conseguiu?

Por que isso importa? Às vezes a aplicação precisa de um banco de dados, de um banco em memória e de uma API externa pra funcionar. É essencial. A API externa está indisponível, ou você não está conseguindo conectar nela, e a aplicação sobe do mesmo jeito.

Pra que a aplicação subiu, se a função principal dela não vai ser cumprida?

Então você coloca isso na inicialização, no log, de forma clara. Você tem que entender o que você está fazendo na aplicação, e tem que entender o que a aplicação está fazendo. É pra isso que a gente tem log.

O que eu mando registrar no dia a dia

Depois que subiu, é log em tudo que a aplicação faz:

• o usuário logou;
• o usuário navegou em tal página;
• o usuário fez tal ação;
• o insert no banco foi feito certinho, o select no banco foi feito certinho;
• eu criei o job pra tal coisa, e o job foi criado na outra aplicação;
• consultei o banco de dados em memória;
• consultei o Kafka da vida, ou qualquer coisa que você use pra fila e mensageria.

"O usuário navegou em tal página" parece exagero. Não é. Isso vai ser útil em outras camadas, lá na frente, que têm outros nomes e que eu não vou abrir aqui. Acredita: nada disso vai ser inútil.

Os níveis de log e a chavinha do debug

Pega um framework fantástico como o Laravel. Ele já vem com opção de log e de debug. (Lógico que, se o cara for muito ruim, ele consegue tirar as coisas boas do Laravel. Eu já vi. É história pra outro momento.)

Não é só o Laravel. Vários frameworks já vêm, nativamente, com uma chavinha: ativa e desativa o debug. E o que é o debug? É a leitura de log.

Em infraestrutura a gente usa isso demais. Todo mundo que mexe com desenvolvimento já mexeu com nginx. Ele está na frente do Laravel, de coisa em PHP, de quase tudo. E lá você escolhe o tipo de log que quer ativar:

• info: traz tudo;
• warning: traz só os alertas e ignora as informações de acesso;
• error: o log de erro;
• e o debug, que você liga quando precisa enxergar o que está acontecendo.

Tem outras classes além dessas. Eu fico nessas três e no debug porque é o que você precisa pra começar.

Fui conferir como a documentação descreve. No nginx, a diretiva error_log aceita oito níveis, em ordem crescente de gravidade: debug, info, notice, warn, error, crit, alert e emerg. Escolher um nível registra as mensagens dele e de todos os mais graves, e o padrão é error. O log de debug só funciona se o nginx tiver sido compilado com --with-debug.

No Laravel são os oito níveis da RFC 5424: emergency, alert, critical, error, warning, notice, info e debug. Cada canal de log tem um nível mínimo, que você ajusta. E a chavinha de debug é a variável APP_DEBUG: a documentação manda deixar ligada no desenvolvimento local e sempre desligada em produção, porque ligada ela pode expor configuração sensível pro usuário final.

Por que o log precisa desligar: ele arrebenta o seu IO

Por que ativar e desativar? Porque no futuro, quando Deus quiser, a sua aplicação vai subir, você vai ganhar dinheiro e vai ter centenas, milhares de usuários. E aí o log vai arrebentar com o seu IO, que é a escrita em disco.

Com um volume de log muito grande, a performance da aplicação cai. É fato, acontece. Se um sênior estiver lendo: eu estou sendo simplório de propósito. Dava pra entrar em quando isso acontece e quando não acontece. Fico no raso pra todo mundo entender.

Quando você sobe pra produção existe o que a gente chama de escovar bit, que é otimizar pra performance. E uma das coisas que a gente faz pra otimizar é desabilitar log.

Imagina o nginx recebendo milhares de usuários, com o log em info. Ele escreve dezenas de gigabytes. É uma quantidade absurda, e está gastando disco.

"Ah, mas disco eu tenho, eu alugo na AWS." Eu não estou falando de espaço. Estou falando de performance de escrita. Quando tem latência na escrita em disco, a aplicação inteira sente. O exemplo crítico é meter um banco de dados num disco mecânico comum em vez de um NVMe: arrebenta a performance do banco como um todo.

Quando ninguém está usando, é uma beleza, funciona na minha máquina. Quando começa a botar carga, o trem agacha, não aguenta.

Na documentação do nginx dá pra ver os dois botões que existem pra isso no log de acesso: o parâmetro buffer, que junta as linhas em memória antes de escrever no disco (64 KB por padrão quando ligado), e o access_log off, que desliga o log naquele nível da configuração.

Por isso a regra é ter a opção. Liga pra entender o problema. Desliga pra otimizar. Quem não tem a chave fica com as duas piores coisas: ou está no escuro, ou está com o disco apanhando.

Uma skill e um agente só pra cuidar de log

Você pode, e deve, criar no seu Claude Code, no Codex, no Cursor, no que você estiver usando:

1. um agente de revisão que cuide exclusivamente da parte de log e cheque se ele está lá;
2. uma skill que esse agente usa, que sabe ativar e desativar os níveis.

E você pode colocar isso no seu CI, no deploy. Aí, toda vez que a aplicação sobe, você vê o checklist: subiu na porta tal, consultou o banco, conectou no que precisava.

Isso está nos contratos que a gente faz na hora de desenvolver uma aplicação, nas regras que a gente coloca pra IA seguir. Eu mostro como o meu pipeline cerca os agentes em GitHub vai virar gargalo: meu CI com agentes de IA.

O erro clássico: a coluna que a IA criou na mão

Quando você for debugar a sua aplicação, é disso que você precisa: o modo debug ativado, e ela escrevendo tudo.

Deu erro. Deu erro por quê? Porque alguém enfiou uma coluna a mais no banco. A IA enfiou uma coluna lá que agora é obrigatória pra inserir registro, e no código ela não está obrigatória. Ela criou na mão, direto no banco. Não usou o model, não fez a migration.

Clássico. Clássico de acontecer.

E tem milhares de outras possibilidades. O payload que saiu de um lado está diferente de quando a API foi feita. Os dados não batem: um lado aceita nulo, o outro não aceita.

Em comunicação de API, o log tem que mostrar o que foi e o que chegou. A rota tal mandou os dados: nome, CPF e por aí vai. A rota tal recebeu. Só que a rota de lá não tinha data de nascimento. Ela vai quebrar? Vai responder? Vai aceitar ou não vai?

Você só descobre quando tem o log completo de toda informação que transaciona na aplicação. Sem ele, você não vê por que quebrou.

Por que eu insisto tanto nisso

São coisas que eu sofri na pele há muitos anos. Eu tenho mais de 300 aplicações rodando hoje. Tive muita gente capacitada trabalhando comigo, e tive muita gente que ignorou os contratos e os padrões que a gente definiu e causou muito problema.

Eu perdi mais de R$ 300 mil com SaaS meu, feito errado, na onda do hype do microsserviço. E eu aviso por um motivo: a IA às vezes vai te sugerir criar um microsserviço e fatiar um negócio que não deve ser fatiado.

O que tem de aplicação legada que a gente pega e que não tem log direito é um absurdo. Você olha o log e não entende o que a aplicação está fazendo.

Eu, como infraestrutura, quando vou debugar alguma coisa, quero conectar o meu shell, meter o log na cara e entender o que está acontecendo na aplicação agora. Já precisei ler muito log pra achar um problema só, e conto em observabilidade: os 30 GB de log que eu tive que ler.

E tem um ganho que pouca gente percebe. Quando você abre o contêiner do seu Docker, um pod, ou o terminal direto no Linux ou no seu Mac, e vê no log o que a aplicação está fazendo, você fica com mais segurança do que está fazendo. Aí você consegue mexer mais. O vibe coder vai elevando o nível de conhecimento conforme vai vendo o que acontece: "ah, essa função aqui fez isso".

Nota de cronologia. Eu gravei no começo de junho de 2026 e deixei a parte de performance, de como identificar gargalo no sistema, pra outro vídeo. O que existe hoje de aula sobre isso está na página das imersões. A de SaaS em Produção é a que trata deste assunto.

Eu acredito, na prática, que uma coisa fundamental pra gente ter aplicações melhores é você saber o que está fazendo. Você só vai saber o que você está fazendo na hora que vir o log. E só vai saber o que a IA está fazendo pra você na hora que tiver log. Sem log você fica no escuro, e no escuro ninguém faz absolutamente nada.

Perguntas frequentes