Deu um problema na minha infraestrutura e eu peguei 30 GB de log de todo o CDN daquele momento — menos de uma hora de operação. Dividi em pacotinhos, despachei pra IA analisar e a gente achou. Só achou porque o log estava lá. Se não estivesse, nem eu nem a inteligência artificial teríamos o que fazer.
Resposta rápida: observabilidade é você conseguir observar o seu sistema — infraestrutura, back end, front end, banco e jobs — e responder quem fez o quê, onde e quando. O mínimo que eu não abro mão: (1) trate os erros de verdade, pare de devolver 500 pra tudo; (2) log em cada ação do back end, não só no que quebra; (3) monitore a máquina E a aplicação, pra cruzar infraestrutura com código; (4) ferramenta é escolha, não é a observabilidade — Grafana, Prometheus e Loki resolvem a maioria, Datadog costuma ser bala de canhão em formiga; (5) se você não sabe pra que serve aquele dado, nem coleta; (6) e agora tem um motivo novo: sem log, a IA não consegue debugar pra você.
Gravei quase 10 minutos sobre isso em 09/08/2026 no canal @josimarjmv. Assista e leia junto: aqui embaixo eu conto a mesma coisa por escrito, com mais calma e com as ferramentas conferidas na documentação oficial delas.
🎧 PREFERE OUVIR? · 10 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Meu nome é Josimar Machado, sou CEO de uma empresa de tecnologia e desenvolvo plataforma de vídeo. A gente entrega milhões de views, no Brasil e nos Estados Unidos. E eu sou hands-on: eu boto a mão na massa mesmo, eu cuido de infraestrutura pesada.
Dou a carteirada logo no começo por um motivo: eu não sou papagaio digital repetindo o que leu. O que vem abaixo é o que eu opero, com o problema que eu tive e a conta que eu paguei.
E já aviso onde este texto se encaixa: eu terminei o artigo sobre a arquitetura mínima pra criar software com IA e conseguir vender dizendo que observabilidade merecia um texto só dela e que eu ia escrever. É este aqui.
Eu brinquei com a palavra observar, mas é literalmente isso: observar o seu sistema. Tudo que acontece nele:
E não é assunto só de sistema grande. Isso serve pra site também, porque todo site que tem um formulário de contato tem um back end atrás dele. Pra sistema mais complexo é essencial, óbvio. Mas o site que perde lead em silêncio há três meses é o caso mais comum e mais barato de resolver que existe.
Onde isso ficou urgente foi na era do amigo vibe coder. Todo mundo desenvolvendo software local, todo mundo parando de assinar software desnecessário, todo mundo fazendo o seu próprio sistema in house. A minha leitura é que as gigantes — HubSpot, Salesforce e companhia — vão sentir isso no faturamento com o tempo; isso é aposta minha, não é número auditado. O que não é aposta é a consequência: cada um desses sistemas caseiros virou responsabilidade de quem fez. E quem fez, na maioria das vezes, não pôs log nenhum.
Deu um bug no sistema. Pá. Você foi lá e não tratou todos os erros. Pergunta sincera: você já pediu pra sua IA tratar todos os erros 200, 300, 400 e 500?
Provavelmente ela te respondeu algo como "hoje já foi um dia exaustivo, amanhã a gente continua". Aí agora está com essas besteiras. Daqui a pouco pede cartão pra bater ponto das 8 às 6, de segunda a sexta. Brincadeira à parte — o erro não tratado é o problema clássico do júnior, do estagiário e, agora, da IA sem revisão.
Erro 500 significa que você errou na sua aplicação e não deu a saída certa do erro. Rota errada? Devia ser um not found, e vem 500. Ação inesperada? 500. Uma coluna nova no banco que não aceita nulo? 500. Tudo 500.
Conferido por mim em 13/09/2026: a RFC 9110, seção 15.6.1 define o 500 como "o servidor encontrou uma condição inesperada que o impediu de atender à requisição". Leia de novo: inesperada. É a resposta pro que você não previu. Quando ela vira a resposta pra tudo, você transformou o seu catálogo de erros num apagão — o 500 passou a esconder a causa em vez de apontar pra ela. A mesma RFC organiza as respostas em cinco classes: 1xx informativa, 2xx sucesso, 3xx redirecionamento, 4xx erro do cliente e 5xx erro do servidor. Devolver 5xx pra erro do cliente é mentir sobre de quem é a culpa.
Então, antes de qualquer ferramenta: trate todos os erros da sua aplicação da forma correta — as respostas certas, o retry onde faz sentido. Sem isso, observabilidade não tem o que observar.
Quando a gente trata os erros direito, a gente começa a ter a maldade de colocar log nas ações — em tudo que o seu back end está fazendo, não só no que explode. Cada coisa que acontece deixa um registro. E aí você tem um sistema de monitoramento que captura esses log.
A partir daí, muda de figura o que você consegue enxergar. Principalmente quando você tem sistema com job. Você tem um sistema que executa um job de tanto em tanto tempo, ou um processamento que dispara depois que o cliente faz upload de um arquivo. Com observabilidade ativada, você consegue entender ponto a ponto todo o fluxo do que aconteceu. Sem ela, o job falhou em algum lugar entre a meia-noite e as seis e boa sorte.
Na minha operação, quem fez o quê, onde e quando é tudo registrado — em infraestrutura e em back end. A não ser que o desenvolvedor não tenha colocado log na aplicação. Aí nós dá um pedala Robinho nele, fala pra ele colocar, e resolve o problema.
E aqui vai uma honestidade que eu devo a quem está lendo: eu tenho mais de 300 sistemas e já passou muita gente aqui na empresa. Então eu tenho coisa legada que não está no padrão que a gente gostaria até hoje — padrão de código, digo. Conforme o tempo vai passando, a gente vai zerando os backlogs e deixando tudo padronizadinho. Não é uma casa perfeita. É uma casa que sabe onde está o buraco.
Recentemente a gente teve um problema na nossa infraestrutura, numa parte específica. Eu comentei com os meninos na hora e depois virou este texto.
O que eu fiz: peguei 30 GB de log de todo o CDN daquele momento — e "aquele momento" é menos de uma hora de operação. Trinta gigabytes. Eu tenho um repositório central que controla todos esses log, então estava tudo lá, à mão.
Só que eu não despachei os 30 GB de uma vez pra IA. Trinta giga é muita coisa: ia perder contexto, mesmo com 1 milhão de tokens de janela e a treta toda. Então eu tive que sair dividindo em pacotinhos, separar as partes importantes e fazer a mineração depois. É um processo um pouco chato, não vou romantizar.
Mas a gente conseguiu descobrir. Usando inteligência artificial pra debugar log dentro da observabilidade que eu já tinha instalada em todo o meu sistema. Repare na ordem das coisas: a IA não me deu observabilidade. Ela leu, rápido e sem reclamar, o que a observabilidade tinha guardado. Se o log não estivesse lá, não havia modelo no mundo que resolvesse.
É por isso que eu insisto tanto nesse ponto com quem está começando agora. Você, que não entende de código o suficiente pra fazer o debug na mão, vai ter que pedir pra IA fazer o debug. E aí a pergunta se resolve sozinha: como é que ela vai debugar se não tem log?
Depende muito de onde você hospeda a sua aplicação. Se é um site num terceiro, onde você não tem controle nenhum, não dá pra fazer muita coisa no nível da máquina: você vai ter que contratar ou criar uma ferramenta externa de observabilidade que conecte no seu sistema.
E aqui vem a armadilha que eu vejo direto: às vezes a integração dessa ferramenta fica mais cara e mais complexa do que o sistema em si. Tem isso também.
Exemplo: Datadog. É um sistema gigantesco de observabilidade, assim, maravilhoso, enorme — e extremamente complexo. Às vezes você está matando formiga com bala de canhão. Te falo por experiência própria: observabilidade às vezes gera um caminhão de informação que, se o cara não vai azeitar a performance, não faz nenhum sentido pra ele.
O que é muito usado hoje, e o que eu recomendaria pra quem está montando:
Conferido por mim em 13/09/2026, pra você não ter que acreditar em mim: a documentação do Prometheus o define como "um conjunto de ferramentas de monitoramento e alerta de código aberto" que "coleta e armazena suas métricas como dados de série temporal", e registra que ele entrou na CNCF em 2016 como o segundo projeto hospedado, depois do Kubernetes. A mesma página é honesta sobre o limite dele: "se você precisa de 100% de precisão, como para cobrança por requisição, o Prometheus não é uma boa escolha" — porque o dado coletado provavelmente não vai ser detalhado e completo o bastante. Ou seja: métrica não substitui log de negócio. São coisas diferentes e você vai precisar das duas.
Já a documentação do Loki explica por que ele ficou popular: "diferente de outros sistemas de logging, o Loki é construído em torno da ideia de indexar apenas os metadados sobre os labels dos seus logs", do mesmo jeito que os labels do Prometheus. Ele não indexa o texto inteiro — comprime o log em blocos e joga em object storage. É exatamente isso que derruba o custo e a complexidade contra um sistema de índice full-text. Pra quem tem volume e orçamento apertado, esse detalhe é a diferença entre ter observabilidade e não ter.
E tem o caminho do meio, que hoje é real: você pode criar com a IA algo menos denso que essas ferramentas grandes e complexas, que faça o rastreamento completo do que acontece no seu sistema. Não precisa ser bonito. Precisa responder quem, o quê, onde e quando.
Se você quiser um caminho que não te prenda a fornecedor nenhum, o padrão aberto pra instrumentar isso é o OpenTelemetry, que se apresenta como "100% open source e neutro em relação a fornecedores", é projeto graduado da CNCF e nasceu da fusão do OpenTracing com o OpenCensus. Ele organiza a coisa em sinais — traces, métricas, logs e baggage — e é a forma de você instrumentar uma vez e trocar de ferramenta depois sem refazer o sistema. Coerente com o meu jeito de trabalhar: eu não gosto de ficar preso.
Não adianta você querer montar um sistema de observabilidade e, sinceramente, subir aquilo, olhar um caminhão de informação e falar: "pra que que serve isso?". Já perdeu o intuito. Já perdeu o intuito.
Então a regra é curta: se você não sabe pra que usa, nem coloca.
Mas — e esse "mas" é grande — é extremamente importante você ter as informações essenciais. Quem fez o quê, onde e quando. No seu sistema, na sua infraestrutura, no seu banco de dados, no seu front, no mobile, em todos os endpoints. Pra que num momento de debug, num momento de melhoria, na hora de implementar uma feature ou de rodar uma migration pra alterar o banco, você consiga cruzar todas as informações.
E tem um uso que quase ninguém cita: a gente usa muita observabilidade pra escovar bit. A partir dela eu melhoro a performance de alguma coisa, escovando bit sempre, extraindo o máximo do hardware que eu tenho — porque a infraestrutura é minha. Esse é outro motivo, e é um motivo que paga a conta no fim do mês, não só na hora do incêndio. É a mesma lógica que me fez escrever aqui por que infraestrutura virou o novo superpoder na era da IA.
Cenário concreto, que é o que mais acontece hoje. "Ah, vou subir uma aplicação numa VM." Legal. Então:
Um lado sozinho não fecha a conta. A métrica da máquina te diz que a CPU foi a 100%; o log da aplicação te diz que naquele segundo entrou um upload de 4 GB e o job de transcodificação disparou três vezes. Separados, são dois mistérios. Juntos, é um diagnóstico. Desenhado, é assim:
E aí você tem observabilidade do que está acontecendo — até pra pedir pra um modelo, um Opus 5, um Fable 5.1 ou qualquer outro que você use, te ajudar a encontrar um bug e resolver um problema. Ter os log completos de tudo na mão da IA é essencial, inclusive pra você mesmo entender como aquilo funciona por dentro. O log é o material didático mais barato que existe sobre o seu próprio sistema.
Se o seu passo anterior é sair da nuvem e rodar isso em casa, eu já contei aqui como parar de pagar VM na nuvem e subir a sua no Proxmox. Observabilidade é o que faz essa mudança ser segura em vez de temerária — é o que tira o medo de subir em produção, porque você deixa de operar no escuro.
Vou terminar com a parte que não é técnica. Se não fosse eu ter ido pra on-premise, a minha empresa tinha quebrado. A nuvem ia me quebrar. Se eu tivesse mantido tudo lá, eu ia ter grandes problemas.
Ambiente próprio salvou a minha empresa. E ambiente próprio sem observabilidade seria trocar uma dependência cara por uma cegueira barata — eu não teria como escovar bit, não teria como achar o problema no CDN, não teria como provar pra mim mesmo que a conta fecha. Uma coisa sustenta a outra.
Se você quer entender como isso funciona na prática — como se faz o deploy disso, como você sobe, como integra, como usa pra aquilo que você precisa —, é exatamente o assunto da Imersão de Infraestrutura: três dias presenciais em São Paulo, montando rack, comprando servidor e configurando tudo pra você ter a sua nuvem privada. Ou pra você chegar ao consenso honesto de que on-premise não é pra você e que o seu lugar é na nuvem mesmo. Os dois desfechos são resultado.
Quer fazer isso comigo? A Imersão de Infraestrutura é o caminho de quem quer a própria nuvem. Tem também a Imersão de SaaS, que pega o seu produto do banco ao monitoramento, a Imersão de Sites e a de chatbot. Data, preço, formato e condição de cada uma estão em todas as imersões — é a página que vale, nunca o que eu falei num vídeo.
Nota de cronologia (importante). Esse relato é da gravação que eu publiquei em 09/08/2026, e você está lendo em setembro. Na gravação eu falo do número de inscritos da Imersão de Infraestrutura e do tamanho do local naquele dia — esses números são de agosto e já mudaram. Não use este texto nem a gravação pra saber data, preço, vaga ou condição: use todas as imersões, que é o que vale. A parte técnica — tratamento de erro, log, métrica, ferramenta e o caso dos 30 GB — continua valendo igual.
TODA SEGUNDA · MEIO-DIA · AO VIVO
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Baseado na gravação do canal @josimarjmv publicada em 09/08/2026 (9min37), com transcrição própria das legendas do próprio vídeo. O problema recente no CDN, os 30 GB de log de menos de uma hora divididos em pacotes pra análise por IA, o repositório central de log, os mais de 300 sistemas com legado fora do padrão, o uso de observabilidade pra escovar bit em hardware próprio e a decisão de on-premise que segurou a empresa são da minha vivência tocando a JMV Technology. Conferido por mim em 13/09/2026: a definição do status 500 e as cinco classes de resposta na RFC 9110; a descrição e o limite de precisão do Prometheus na documentação oficial; a indexação só de metadados de labels na documentação do Grafana Loki; e o status de projeto graduado da CNCF e os sinais do OpenTelemetry. Nenhuma dessas ferramentas tem relação comercial comigo. A leitura sobre o faturamento das gigantes de software é opinião minha, não é dado auditado. Data, preço, vaga e condição de cada imersão são os que estão em todas as imersões.