Primeiras aulas do curso
Olá, pessoal. Meu nome é Camilla Martins e este é o nosso curso 3, no qual vamos abordar observabilidade inteligente.
Ao longo das aulas, vamos estudar observabilidade moderna e análise operacional; tendências e comportamento operacional; alertas inteligentes e redução de ruído; investigação operacional e análise inteligente de logs; e operações orientadas por observabilidade inteligente. Também realizaremos um laboratório prático de ponta a ponta com Docker Compose, trabalhando com as principais ferramentas de código aberto do mercado, para colocarmos em prática estes cinco conteúdos que veremos ao longo deste curso 3.
Vamos trabalhar com Prometheus, Grafana, OpenTelemetry e também com IEG.
Nós veremos em profundidade a questão do ruído, estratégias para aperfeiçoar alertas, práticas de Post Mortem (análise pós-incidente) e de Blameless Culture (cultura sem atribuição de culpa), além de como eliminar ruídos, trabalhar com limiar estático, baseline (linha de base) dinâmica e outros tópicos relacionados.
A ideia é que possamos trabalhar com os principais atores do mercado, entender consultas para aperfeiçoar o monitoramento e também contribuir com o monitoramento da empresa, desenvolvendo uma compreensão completa de como funciona a observabilidade.
Qual é a grande diferença entre observabilidade e monitoramento? Monitoramento é a prática operacional: observar um painel, acompanhar uma métrica, corrigir um problema a partir de um log. Observabilidade, por sua vez, envolve as práticas profundas que orientam a construção desses monitoramentos — a inteligência por trás do que medimos, como correlacionamos sinais e como projetamos indicadores e alertas efetivos.
Nós vamos explorar tudo isso ao longo deste curso 3.
Eu aguardo você. Agradeço!
Olá, pessoal.
Chegamos ao Curso 3, que tratará de observabilidade inteligente. Teremos mais 5 aulas especiais, nas quais não apenas aprofundaremos diversos temas que são base do mercado de trabalho, como também desenvolveremos um projeto para vocês, ainda que em ambiente local, para entender melhor como tudo o que veremos sobre observabilidade, ao longo deste Curso 3, se encaixa. Vamos trabalhar com Prometheus, Grafana e Docker, tudo em um ambiente local, que depois poderá ser testado na nuvem que desejarem, no sistema da empresa e em produção, entre outros contextos.
Hoje, na nossa primeira aula, abordaremos observabilidade moderna. Neste vídeo curto, veremos a evolução da observabilidade em ambientes modernos. Falaremos de conceitos-chave, como o monitoramento em black box (caixa-preta), que consiste em verificações externas, como PING (eco de rede) e estados HTTP (códigos de estado, como 200 — tudo certo; 300 — redirecionamento; 400 — geralmente erro do cliente ou problema de permissões; 500 — o conhecido internal server error), sem visibilidade interna. Em seguida, trataremos de observabilidade distribuída e instrumentação interna, que expõe o estado de cada componente. Além disso, discutiremos o contexto corporativo e metadados de negócio agregados à telemetria técnica, e retomaremos os pilares — já vistos em outro curso aqui na Alura — que são métricas, logs (registros) e traces (rastreamentos) como verticais complementares.
Nesta primeira parte do curso — e este código também estará disponível para vocês — vamos explorar essas informações apresentadas. O que faremos? Vamos abrir o terminal e executar um script em Python. Lembrando que os pré-requisitos do curso serão enviados. É importante ter Docker instalado, Python instalado e Git, para que seja possível manejar a biblioteca e trabalhar da mesma forma que estamos demonstrando aqui.
Para colocar isso em prática, no terminal, executamos o script Python responsável por gerar os primeiros insights que discutiremos ao longo da aula:
python3 curso3-aula-01-observabilidade-moderna/video-1.1-evolucao-observabilidade/observability_evolution.py
Esse comando executa o script observability_evolution.py em ambiente local, permitindo observar, na prática, aspectos de monitoramento black box versus observabilidade moderna que iremos analisar em seguida.
Ao executarmos esse código em Python, já obteremos alguns dos insights que estamos discutindo hoje e com os quais trabalharemos ao longo do curso. Vamos falar sobre monitoramento em black box (caixa-preta) versus observabilidade moderna. No monitoramento em black box, que é externo, a equipe de operações realiza verificações HTTP externas. Geralmente fazemos um método GET (obter). O GET é utilizado quando lemos algum recurso em um back-end (camada de retaguarda), geralmente de APIs específicas, e essas APIs costumam expor uma rota para verificar a saúde da aplicação.
Essas rotas de verificação de saúde, como a rota /health, por exemplo, se a API tiver conexão com a base de dados, também devem se conectar a essa base. Não adianta enviar um PING a uma página estática, vazia, sem conexão com a base, quando a aplicação de fato depende dela. Em um cenário no qual o RDS (banco relacional) cai, pode parecer que a aplicação está funcionando porque a rota /health continua respondendo 200, mas, na realidade, trata-se de uma falsa sensação de 200 OK. Isso não reflete o estado verdadeiro da aplicação. Portanto, é uma boa prática fundamental que a página /health, que mostra de forma simplificada o estado da aplicação, verifique todas as dependências reais com as quais a aplicação trabalha — seja um RDS (banco de dados relacional), um banco de dados não relacional, um cache como o ElastiCache ou o Redis, entre outros — para sabermos se a aplicação está, de fato, saudável.
Nesse contexto, podemos observar vários componentes saudáveis: todos retornando healthy, o API Gateway saudável, o serviço de usuários também com health 200. Sabemos que está tudo saudável porque 200 é o código padrão que indica sucesso. Ao lermos sobre os códigos de estado HTTP, entendemos que, em geral, 2xx significa que a solicitação foi recebida, aceita e processada com sucesso (200 OK). Códigos 3xx indicam redirecionamento: o cliente precisa realizar ações adicionais para completar a solicitação. Códigos 4xx representam erros do cliente — alguma sintaxe incorreta (por exemplo, 404 para rota inexistente) ou problemas de permissão, como 403 (forbidden). Já os códigos 5xx indicam falhas internas do servidor, como o conhecido 500 internal server error.
Retomando o exemplo mencionado da rota /health ou da base de dados indisponível: esse cenário provavelmente resultará em um 500 internal server error. Em algumas situações, quando acessamos a página de index (página inicial), podemos ver um 504 bad gateway. Isso geralmente ocorre quando o index tenta acessar algo que falha com um erro 500. Ao tentar completar a solicitação e retornar 200, não consegue, pois ocorre um erro no meio do caminho, e o resultado final é 504 (bad gateway).
Voltando à nossa aplicação: durante um incidente, além do 504 bad gateway, também notamos aumento no tempo das solicitações. Quando tudo funciona, o tempo em milissegundos é muito menor. No incidente, provavelmente ocorre timeout (expiração). Observamos tempos próximos de 29 mil milissegundos (quase 30 mil) e 15 mil milissegundos, indicando que a solicitação ficou muito tempo tentando acessar algo que não estava funcionando. Possíveis causas incluem problemas na base de dados, falha no cache, alguma dependência relacionada a um serviço como o S3 (por exemplo, um bucket (repositório de objetos) com problema), ou ainda recursos estáticos, como CSS ou JavaScript, que não carregam. Nessas situações, a requisição atinge timeout e o sistema retorna como down (fora do ar).
Identificamos que o serviço de pagamento caiu. Em alguns momentos, o sistema de pagamentos fica fora do ar; o gateway de pagamento utilizado também apresentou indisponibilidade. O diagnóstico, no modelo de black box (caixa preta), indica serviços com problema: API Gateway, Card Service e Payment Service, todos sinalizados como indisponíveis, pois o tempo da solicitação ficou muito alto e provavelmente ocorreu um estouro de timeout (tempo limite).
O que é timeout (tempo limite), para quem não sabe? É o período máximo em que a solicitação permanecerá consultando o /health (ou qualquer outra rota que programarmos) para entender se o serviço está “on” ou “off”. Definimos um limite para evitar esperas indefinidas. Existem timeouts mais longos, pois, às vezes, é normal a aplicação demorar para iniciar. Há aplicações que ficam prontas em 15 segundos, mas outras aguardam que outra API inicie, esperam uma base de dados, um cache, JavaScript, entre outros, para que tudo esteja pronto. Em alguns casos, isso leva um minuto, um minuto e meio. Nesses cenários, o timeout da aplicação deve ser, por exemplo, de dois minutos. Se definirmos apenas um minuto, não é que a aplicação esteja com problema; ela estará “off” apenas porque não terminou de iniciar. É inadequado aplicar um timeout de um minuto quando a aplicação fica pronta em um minuto e meio. É mais adequado deixar uma margem e configurar dois minutos, por exemplo, para que a aplicação inicie confortavelmente. Além do tempo médio de um minuto e meio, adicionamos margem para variações e, ao mesmo tempo, não esperamos em excesso para confirmar se a aplicação está, de fato, falhando.
Neste momento, a causa é desconhecida. A base de dados parece saudável, pois realizamos uma consulta específica ao endpoint da base (por exemplo, RDS, Aurora, Postgres). O User Service e o Product Service também parecem saudáveis. Portanto, precisamos investigar manualmente cada serviço.
Vamos aplicar observabilidade distribuída. Precisamos coletar os logs e entender o que está acontecendo, porque apenas consultar um endpoint e verificar “on” ou “off” não é suficiente para realizar troubleshooting (diagnóstico de incidentes).
O que as sinais correlacionadas revelam? Realizamos um deploy (implantação) de um serviço. O connection pool (pool de conexões) já está em 95% na base de dados, e as conexões ativas chegam a 97% de 100%. Provavelmente estamos no limite de conexões, o que torna a base mais lenta e a aplicação também mais lenta. Precisamos agir: limpar conexões ociosas e entender por que a base está sendo tão demandada.
O User Service, em um GET, ainda está ok, retornando 200. Em seguida, realizamos um POST, enviando informações para o checkout. Como contexto, em e-commerce, o checkout (finalização de compra) é a etapa de pagamento. Nesse ponto, a parte do fluxo de pagamento foi abortada; algo durante a transação de pagamento falhou. No API Gateway, observamos uma taxa de erros elevada, com error rate (taxa de erro) de 0,68. A latency (latência) está muito alta, muito acima do SLO (objetivo de nível de serviço), que é inferior a 500 milissegundos; estamos em 30.000 milissegundos.
Qual foi o diagnóstico pela observabilidade? A causa raiz foi o deploy realizado: logo no primeiro serviço do fluxo, o User Service foi atualizado da versão 2.4.1 para 2.4.2. O autor, David Chin, introduziu uma consulta sem índice. Isso tornou as consultas mais lentas, saturou o connection pool e o time deixou de conseguir processar pagamentos e transações do checkout. Precisamos fazer rollback (retorno de versão) e adicionar o índice no próximo deploy. Com ferramentas automatizadas, levamos aproximadamente dois minutos para chegar a esse diagnóstico. Analisar logs manualmente costuma demorar muito mais.
Agora, vamos comparar o aspecto entre black box (caixa preta) e observabilidade distribuída:
Conclusão: o monitoramento black box (caixa preta) responde apenas se o serviço está “up” ou “down” (200, 404, 500 etc.). A observabilidade moderna responde por que o serviço está se comportando assim. Obtemos essas respostas por meio de pequenas histórias, conectando métricas, logs e traces.
Na Aula 1.2, exploraremos como correlacionar métricas, logs e traces (rastros) de forma integrada para acelerar ainda mais o troubleshooting (diagnóstico de incidentes). Nos vemos na Aula 1.2 do nosso curso 3 de observabilidade inteligente.
Olá, pessoal. Agora vamos entrar na parte de métricas, logs e traces na resolução de problemas moderna.
Qual é a nossa ideia? Vamos trabalhar correlacionando três métricas clássicas da telemetria de forma integrada para acelerar a localização de falhas que acabamos de ver na Aula 1. Qual é o problema? A perda de tempo por termos de alternar entre ferramentas isoladas. E qual é a solução? A navegação integrada de logs para traces.
Conceitos-chave importantes para aprendermos:
Logs: registros textuais detalhados de eventos discretos. Por exemplo, isto é um log; o que vimos antes também é log. Há níveis de log: error (erro), warning (aviso) e info (informação). Existem logs apenas de erro, como “Não foi possível… faltou a biblioteca tal; na hora de compilar, Python não está com a biblioteca tal instalada”. Isso é um erro. Um warning (aviso) seria “Esta biblioteca está obsoleta; em breve não poderá ser usada”. É apenas um aviso, pois não impede o uso da ferramenta ou biblioteca; indica que não é a melhor forma, mas funciona. Já info (informação) pode ser “Python está na versão 3.17”. É apenas uma informação. Podemos calibrar os logs para exibirem apenas erro, ou erro e informação, ou aviso, ou tudo, conforme o tipo de informação que for mais importante.
Traces: registros altamente detalhados que capturam informações de baixo nível e o fluxo de uma requisição através de múltiplos serviços. Obtemos informações de baixo nível — por exemplo, algo que roda por baixo em C/C++.
Um exemplo prático: estamos no Google. Vamos abrir o famoso F12 (Inspecionar), ir até a aba Network (Rede) e pressionar F5. Aparecem diversos itens. Em uma rota específica, que tipo de informação temos? Queremos obter informação de que algo chega de um lugar a outro. Aqui, vemos o response header (cabeçalho de resposta). Podemos observar vários recursos que, em conjunto, são carregados para construir a página. Alguns são visíveis, como uma imagem; outros são invisíveis, como um arquivo de CSS (folhas de estilo em cascata) que nem imaginávamos que seria carregado. Vemos que uma coisa leva a outra. Um tracing (rastreio) é algo semelhante, mas um pouco diferente: entramos em um site (Google). A partir do Google, como chegamos a uma imagem de um gauge (indicador) do Grafana? Precisamos digitar “grafana gauge”, clicar em Imagens e, então, clicar em uma imagem específica. Isso é um tracing (rastreio).
Também em logs existe essa ideia de encadeamento. Como fazemos para chegar até o endpoint (ponto final da API) de checkout (finalização de compra)? Precisamos acessar o endpoint “/”. De lá, acessar “/e-commerce” (comércio eletrônico). De “/e-commerce”, ir para “/item” (o item que queremos). Em seguida, “/select” (selecionamos o item). Depois, “/buy” e, então, “/checkout”. Existe uma história que nos leva até o ponto final.
Fazendo uma analogia para quem é do Rio de Janeiro — em seguida daremos um exemplo para São Paulo. Como fazemos para ir do Centro até a Barra? É longe. Suponhamos que moramos na Lapa. Teremos de ir caminhando, provavelmente, até a estação Cinelândia.
Partindo da Cinelândia, vamos pegar o metrô em direção a Jardim Oceânico. A partir de Jardim Oceânico, dependendo do destino, precisaremos pegar um ônibus até o local desejado, como o local do Rock in Rio ou o Via Parque. Portanto, há três etapas. Estamos criando uma narrativa que chega a esse lugar.
Em São Paulo, como fazemos para ir do nosso bairro na Zona Leste, São Mateus, até o centro? Provavelmente precisaremos pegar um ônibus até o Terminal Mercado e, então, caminhar. Ou podemos pegar um ônibus até Vila Prudente, descer em Vila Prudente, fazer transbordo para a Linha Azul e, a partir dela, descer na Sé. Depende do destino final. Basicamente, trata-se de construir rotas que cheguem ao destino final.
Por isso, o tracing (rastreio) ajuda muito mais rapidamente do que logs (registros) isolados, como dissemos na primeira aula. Ao construir essa narrativa, conseguimos responder com mais facilidade por que a aplicação está se comportando de determinada forma quando não deveria. Em seguida, fazemos correlações por meio do uso de um Trace ID (ID de rastreio) e de um Span ID (ID de operação) para unificar essas três verticais e chegar mais rapidamente ao resultado desejado.
Vamos executar outro exemplo em Python para deixar isso claro. Aqui, temos uma vista isolada. Há um painel de métricas no qual visualizamos, por exemplo, uma base de dados com duração de consulta de 7,5 segundos. Há 98 conexões ativas nessa base de dados. O API Gateway (gateway de API) apresenta uma duração de 8,5 segundos para processar a requisição; está alta e poderia ser mais rápida.
Nesse cenário, recebemos um POST (requisição POST) no checkout (finalização de compra) de uma pessoa cliente. Chegou um POST de uma pessoa cliente; estamos processando o checkout número 789, com três itens, e o total dessa compra será de R$ 300. O cache falhou para essa pessoa usuária que está fazendo a compra, identificada como usuário 42. Essa requisição falhou para essa mesma base de dados, pois a consulta está lenta. Observando acima, a consulta está lenta, em 7,5 segundos. Isso impacta a nossa API, que está levando 8,5 segundos para fazer o request (requisição) e devolver a resposta para a pessoa cliente.
Há erro no checkout por timeout (estouro de tempo). O User Service (serviço de usuário) está muito lento. Em seguida, como a compra não pode ser concluída, o Payment Service (serviço de pagamento) também apresenta erro, pois não consegue processar o pagamento devido à lentidão.
Qual é o problema aqui? Precisamos abrir três ferramentas: a de logs (registros), o painel de métricas — tanto o Grafana quanto, possivelmente, dependendo da situação, o Prometheus também. Para quem já acompanhou algo do curso, o Grafana é uma ferramenta visual. Já o Prometheus é a ferramenta de coleta dessas métricas, que depois são exibidas visualmente no Grafana. O painel de logs pode ser um Elasticsearch com visualização via Kibana, pode ser o Loki; também podemos visualizar logs diretamente no Grafana. Podemos coletar logs com Logstash, entre outras possibilidades.
Para quem não conhece muito o Grafana, trata-se da ferramenta visual que já vimos antes. O Prometheus é a ferramenta que utilizamos para coletar métricas. Coletamos as métricas com o Prometheus para, então, decidir o que fazer com elas: visualizar, converter em alerta, etc. Isso dependerá da ferramenta associada ao Prometheus. Neste caso, usamos o Grafana, mas poderíamos usá-lo para disparar alertas por meio de um pager (serviço de alerta), um VictorOps, entre outros, para recebermos chamadas quando algo cair, por exemplo.
O problema é que, nesse fluxo tradicional, precisamos copiar manualmente três IDs entre os dashboards (painéis) e correlacionar mentalmente os timestamps (carimbos de tempo). Isso é ruim e, às vezes, leva muito tempo — meia hora, quarenta minutos, uma hora.
Com a vista correlacionada, passamos a correlacionar os eventos em um formato de waterfall (cascata). Nesse exemplo, o POST no checkout apresentou problema. O Cart Service (serviço de carrinho) também falhou, o que correlacionamos aqui. A operação de get user profile (buscar perfil de usuário) também está com tempo alto, mas teve sucesso. O database select (seleção na base de dados) está alto, porém teve sucesso. No momento do Payment Service (serviço de pagamento), a operação não funcionou porque já estava muito lenta.
Vemos sinais correlacionados a esse tracing (rastreio): relacionamos os logs (registros) com os tracings (rastreios) acima que estão muito elevados. No diagnóstico automático, o tracing (rastreio) revela que 88% do tempo total gasto ocorreu no select (seleção) da base de dados. Ou seja, quase todo o tempo foi consumido nessa seleção. A informação foi obtida, mas demorou demais e, quando seria devolvida, já estava lenta em excesso e a operação não foi concluída. A métrica associada mostra que o connection pool (pool de conexões) está muito alto.
A cadeia de impacto é a seguinte: a base de dados afeta o User Service (serviço de usuário), que afeta o carrinho, que afeta o pagamento, e daí impacta o gateway. O tempo de diagnóstico foi muito menor porque conseguimos, diretamente, unir correlações relacionando os problemas dos logs (registros) com as métricas e com os tracings (rastreios).
Conclusão: a correlação via Trace ID (ID de rastreio) vai unificar três fontes de dados separadas em uma narrativa única de cada requisição. Em vez de investigar métricas, logs (registros) e tracings (rastreios) de forma separada, navegaremos por um fluxo contínuo que conta a história completa da falha.
E, nesta Aula 1.3, veremos como o contexto operacional de implantações e configurações vai enriquecer ainda mais essa correlação. Nos encontramos na próxima aula. Agradecemos!
O curso Observabilidade inteligente: integrando métricas, logs e traces com OpenTelemetry possui 218 minutos de vídeos, em um total de 53 atividades. Gostou? Conheça nossos outros cursos de Confiabilidade & SRE em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Todos os cursos, trilhas e certificados para evoluir.
7 dias para cancelar com reembolso
Aprenda mais rápido com IA, idiomas e imersões.
7 dias para cancelar com reembolso
TUDO DO PLUS, MAIS:
Aceleração de carreira: mentoria, vagas e prática guiada.
7 dias para cancelar com reembolso
TUDO DO PRO, MAIS: