Primeiras aulas do curso
Olá! Meu nome é Lara Xavier, e irei ajudar a construir esta trilha em observabilidade. Sou especialista em observabilidade, com formação em tecnologia DevOps. Minha trajetória começou na Engenharia Elétrica, e agora estou aqui para compartilhar conhecimentos sobre este tema.
Possuo duas especializações: Arquiteturas em Cloud (nuvem) e Machine Learning (aprendizado de máquina). Além disso, no ano passado, obtive o título de primeira mulher Grafana Champion no Brasil, tornando-me embaixadora da Grafana Labs no país. Meu lema é promover a observabilidade de forma agnóstica. Espero que apreciem.
Finalmente, chegamos a entender a diferença entre monitoramento e observabilidade. Embora sejam conceitos distintos, eles se complementam para proporcionar uma visão clara da operação e da experiência do usuário.
Quando falamos de monitoramento, referimo-nos ao acompanhamento de sistemas nos quais já conhecemos os problemas e as métricas que desejamos coletar. Por exemplo, queremos identificar falhas, aprender com elas e começar a respondê-las. Isso pode incluir um servidor que reinicia frequentemente, um disco que enche rapidamente ou uma CPU que trava com frequência. São problemas cujos sintomas já sentimos e que queremos observar ao longo do tempo para resolvê-los e minimizar os impactos no sistema. Por exemplo, se sabemos que 95% de uso de memória impactará o sistema, queremos ser alertados com antecedência para aumentar a memória ou identificar o processo causador do problema.
O monitoramento, a curto prazo, ajuda a solucionar problemas conhecidos. Quando observamos um dashboard, podemos ver que a CPU está em bom estado, a memória está abaixo de 80% e os discos têm consumo considerável, mas ainda assim, o cliente pode reclamar de lentidão no sistema. Isso indica que, além dos problemas conhecidos, há uma "caixa preta" de problemas desconhecidos que não foram correlacionados.
A correlação pode ser feita por ferramentas que fornecem insights ou pelo próprio operador. No entanto, em grandes equipes e empresas, é difícil que a pessoa responsável tenha o contexto necessário para entender todas as dependências além das métricas de CPU, disco e memória. É por isso que buscamos a observabilidade.
A observabilidade complementa o monitoramento, abrangendo não apenas os problemas conhecidos, mas também as dependências, problemas de rede, latência e tráfego. Ela se aproxima mais do usuário, evidenciando os impactos sofridos pelo sistema. Em eventos imprevisíveis, como picos de acesso em dias de pagamento, Black Friday ou pandemias, o sistema é testado até seus limites, revelando falhas imprevisíveis que podem ser planejadas em cerca de 80% dos casos com o uso de Chaos Engineering.
Essas falhas imprevisíveis podem ser derivadas de deploys feitos semanas antes, e tudo isso se encaixa na lei de Murphy, onde as coisas tendem a dar errado no pior momento possível. Com a velocidade de produção atual, é comum que sistemas enfrentem alterações e mudanças frequentes em busca de escalabilidade e inovação.
Podemos observar abordagens reativas e preditivas. O monitoramento tradicional é reativo, pois tomamos ações diante de problemas já existentes. Já a observabilidade traz uma abordagem preditiva, baseada em tendências conhecidas. Por exemplo, ao acompanhar picos de memória por três meses, podemos receber alertas preditivos sobre possíveis colapsos do sistema.
Na abordagem preditiva, temos uma visão unificada de métricas, logs e traces, facilitando a identificação rápida de problemas e o entendimento de causa e efeito. Isso pode ser feito manualmente ou com o auxílio de IA.
O ciclo de observabilidade deve ser bem estruturado, não apenas para identificar erros, mas para receber alertas e analisar traces distribuídos. Se um alerta indicar que o tempo de resposta excedeu 500 milissegundos, queremos ver o trace desse período para entender o caminho percorrido pela requisição e os serviços ou microserviços envolvidos, além de obter métricas de rede e atributos relevantes.
Atributos são informações sobre o nosso sistema, como onde ocorreu um evento e qual evento foi disparado. Queremos identificar qual serviço estava lento e acabou impactando para que uma requisição extrapolasse mais de 500 milissegundos. Analisando a latência, começamos a determinar a causa que impactou o usuário. Assim, já temos o problema, o caminho percorrido, os microserviços relacionados e os limites que foram extrapolados, permitindo que comecemos a implementar uma solução.
Essa é a forma adequada de chamar um time para uma sala de crise: quando já temos dados e entregamos informações úteis para que as pessoas possam ajustar seus serviços, esteiras e aplicações. No final, temos uma resolução. Um limite extrapolado de mais de 500 milissegundos é um problema, então, a partir de 400 ou 450 milissegundos, talvez já seja um gatilho adequado para ser alertado.
Podemos trabalhar com nomes de eventos usando Regex (expressões regulares) para buscar nos logs e nos traces, trazendo uma contagem de quantos eventos temos. Se é uma métrica desconhecida, devemos começar a monitorar, colocando uma contagem para analisar em dias normais e em dias de pico quantos problemas ocorrem. Se a solução implementada já resolveu boa parte disso, ótimo. Mas devemos deixar a métrica para validar que as próximas implementações não passem despercebidas. Isso porque, ao sentir que já resolvemos, podemos remover o monitoramento e não perceber que a próxima implementação pode ter o mesmo problema ou um problema ainda mais grave.
O ciclo do threshold (limite) envolve criar, observar, passar um tempo e validar novamente se faz sentido continuar com aquela métrica. Se em algum ponto acharmos que só ela não é suficiente, podemos trazer outra métrica para complementar e agrupar. Esses são insights para pensarmos no dia a dia e nos inspirarmos quando nos depararmos com um problema em uma sala de crise de observabilidade ou em qualquer outro problema, pois tudo envolve observabilidade. Se temos observabilidade, é um problema se não conseguimos encontrar um erro com ela; se não a temos, é um problema ainda maior, indicando que não temos visibilidade sobre nada, o que representa um grande risco.
Chegamos ao exemplo de monitoramento de painel e observabilidade como scanner (escâner), trazendo uma analogia automotiva. No painel do motorista, temos informações em tempo real, uma informação estática que acompanhamos com o olhar, mas não conseguimos guardar bem um histórico. Observamos que estamos a 60 quilômetros por hora e que o limite é 80, então nos controlamos. Já com um scanner, temos dados mais detalhados e técnicos, que é o que a observabilidade também nos entrega.
Os pilares da observabilidade são traces (rastreamentos), métricas e logs. A união desses três elementos forma os pilares mais importantes da observabilidade. Apenas ter traces, logs ou métricas isoladamente não constitui observabilidade. Podemos ter monitoramento, mas a observabilidade só funciona quando temos o rastreamento de ponta a ponta das requisições e os três métodos integrados. Quando conseguimos visualizar as coletas de métricas, traces e logs, temos observabilidade. No entanto, ainda não temos maturidade. Apenas coletar não significa que teremos tudo.
O monitoramento começa na base, padronizando o monitoramento e tendo o parque de máquinas monitorado. Se já temos alertas, ótimo. Na observabilidade, instrumentamos todas as aplicações, temos métricas, traces e logs em abundância. Isso é muito bom, mas sem método e processo, podemos nos perder em informações e continuar sem visibilidade. Devemos ter cuidado com isso.
Os traces são uma forma de monitorar todas as requisições que a aplicação recebe e faz, desde o primeiro clique no aplicativo até a finalização de uma compra. Observamos quantas vezes o banco de dados foi acessado, quantos selects e updates foram feitos, entre outros. É um rastreamento minucioso da requisição, incluindo tempo de resposta e latência. Os traces são poderosos porque podem ser correlacionados com os logs. Além de ver a requisição de ponta a ponta, conseguimos ver todos os logs gerados por ela e as métricas de sistema e infraestrutura. Por exemplo, podemos perceber que no meio de uma requisição a rede caiu.
Os logs são registros de sistema e infraestrutura escritos em um arquivo de texto, que podem ser enviados para a stack de observabilidade e anexados aos traces.
A partir de tudo isso, podemos tomar decisões, que são o ponto-chave para acertar. Decisões precisam ser baseadas em dados. Em questões de FNOPs, por exemplo, se queremos diminuir custos, precisamos de visibilidade. A partir da tomada de decisões, vem a otimização de processos. Temos insights a partir dos dados, tomamos decisões e otimizamos processos, que são alinhados com as regras de negócio e monitorados com observabilidade.
A observabilidade abraça o monitoramento e, estando fora, fica mais próxima do usuário. A tomada de decisão interna impacta diretamente quem está na ponta, observado pela observabilidade. Dessa forma, a explicação fica mais clara.
Quando falamos de critérios, foco principal de monitoramento e observabilidade, escopo e objetivo, chegamos a um ponto importante. O foco principal do monitoramento é a saúde e o desempenho do sistema com métricas pré-definidas e conhecidas, como o tempo de atividade do servidor, funcionamento de agentes, ping e processos que não podem parar. A observabilidade, por sua vez, investiga hipóteses desconhecidas a partir das saídas de dados, métricas, logs e traces.
O escopo do monitoramento envolve componentes individuais e infraestrutura tradicional, enquanto a observabilidade trabalha com sistemas distribuídos, microserviços, ambientes e nuvens, que são infraestruturas de aplicações modernas. O objetivo do monitoramento é informar que algo não está funcionando, enquanto a observabilidade busca entender a causa e efeito de um componente ou falha.
Se houver dúvidas ou interesse, estamos disponíveis para conversar.
Agora, vamos discutir os três pilares clássicos de observabilidade: métricas, logs e traces (rastreamentos). Vamos começar com um exemplo prático. Suponha que recebemos um alerta de um microserviço de check-out que está com alta latência. Normalmente, temos um dashboard que mostra a latência ao longo do tempo, evidenciando a resposta do microserviço. No entanto, as métricas podem não fornecer contexto suficiente. Por exemplo, a latência pode estar alta, mas o ping do servidor está normal, assim como a memória e a CPU. Isso não nos mostra exatamente o que está acontecendo. Se houver um problema de CPU, pode nos levar a investigar outro aspecto da latência.
Os logs, por sua vez, oferecem um contexto muito rico, mas podem ser volumosos, especialmente em casos de problemas. Logs de erros são gerados frequentemente a cada tentativa, resultando em um grande volume de dados, dificultando a identificação do problema exato. Filtrar por erro ou warning pode trazer várias informações, incluindo problemas atuais ou anteriores que não foram observados. Se os logs forem instrumentados de forma inadequada, como categorizados como debug, torna-se ainda mais difícil encontrar problemas apenas lendo os logs. Portanto, é essencial ter métricas de qualidade e logs bem categorizados.
Os traces normalmente mostram o percurso de uma requisição, indicando com quais microserviços interagiu, se houve falhas de rede ou de banco de dados. Cada requisição, como um clique em um aplicativo como Spotify ou iFood, é registrada, resultando em um grande volume de dados por microserviço. Isso torna difícil identificar onde a requisição enfrenta problemas. O alinhamento com as regras de negócio é crucial.
Para depurar a latência e entender melhor o que ocorreu, utilizamos métricas que ajudam a evidenciar problemas em grandes volumes de dados, como o P95. Se alguém sem conhecimento profundo em métricas perguntar sobre um P95 alto na API, um SRE explicaria que isso indica um aumento no tempo de resposta da API no percentil 95, evidenciando desempenho. Para entender e depurar o problema, abrimos um trace, analisamos os spans lentos no microserviço, como o payment service, e verificamos os logs de timeout externo. Primeiramente, analisamos o trace para identificar quais foram os mais lentos, considerando que 500 milissegundos pode ser lento ou não, dependendo da aplicação. É importante entender o que é uma anomalia para a aplicação, como ela sempre respondeu e como está se comportando agora. A partir daí, buscamos os traces mais lentos e identificamos o microserviço em comum, destrinchando o problema.
Por exemplo, em um catálogo de uma loja de comércio eletrônico, temos métricas, traces e produtos catalogados. O monitoramento tradicional pode mostrar ping OK, disco OK, e processos em execução, mas isso não revela o problema que o usuário está enfrentando. Por isso, a observabilidade é importante. Correlacionar traces, métricas e logs pode evidenciar problemas, como um serviço Aurora em um cluster que está com 80 milissegundos de latência, mas agora está OK.
Em algum momento, o sistema apresentou um aumento, chegando a 99,76%. No trace, conseguimos identificar, por exemplo, que o Aurora chamou outro microserviço. Podemos identificar e ler o log, além de visualizar os SpamTributes e os Resources. Os SpamTributes fornecem informações sobre os microserviços, enquanto os Resources mostram onde o serviço está alocado e mais detalhes de infraestrutura. Assim, obtemos uma visão mais clara. Se o serviço interagisse com outros serviços externos instrumentados, essas interações também seriam visíveis. Provavelmente, houve algum problema externo que afetou o comportamento.
A questão do alerta vermelho não está relacionada a um tempo excessivo, mas sim a uma anomalia detectada pela nossa stack de observabilidade. Isso chamou atenção e evidenciou uma possível anomalia. Cabe a nós determinar se isso faz sentido para a nossa regra de negócio ou se pode ser ignorado. Para isso, analisamos os microserviços chamados e seus atributos para verificar se eles contam a história correta.
Ao retornar ao nosso slide, começamos a identificar a métrica de alerta. Quando o problema ocorreu, foi em cerca de 600 milissegundos, o que é problemático. Assim, estabelecemos um limite para observação. A partir de 500 milissegundos, podemos configurar um alerta para monitorar e verificar se realmente faz sentido. Vamos abrir o trace para investigar o problema e consultar os logs anexados aos traces. Tudo isso depende de como instrumentamos para obter informações adicionais sobre o processo.
Falamos sobre a análise e observação de dados em massa, utilizando os golden signals, ou seja, os quatro sinais de ouro divulgados pela Google e utilizados em seus processos de SRE. Utilizamos a latência, que é o tempo que leva para um pedido ser processado. Podemos observar a latência dos microserviços e a latência final. O tráfego refere-se à quantidade de dados que passam pelo sistema. Em um sistema bancário, por exemplo, podemos ter 2 transações na madrugada e até 1 milhão em um dia de pagamento. Queremos saber até onde chegou para entender o desempenho da aplicação com aquele tráfego. Se o tráfego duplicar, a aplicação continua funcionando? Podemos usar ferramentas de estresse para descobrir e planejar resiliência para a duplicação.
Monitorar erros é sempre importante. Devemos contar erros em logs e categorizá-los bem. Contar erros em traces, como erros 500 e 400 nos HTTPs, e analisar esses erros. Se os erros forem do cliente, como preenchimento incorreto de cadastro ou tentativas de acesso a algo inexistente, podemos excluí-los. Podemos colocar exceções nesses erros para focar nos problemas reais do sistema. É importante entender se um ou dois erros são normais, mas se o número de erros aumenta de 8 para 16 mil, isso é uma métrica interessante para acompanhar e ajustar um limite. Podemos definir um gatilho para quando os problemas começarem a aparecer nos traces e logs. Isso tem uma rotina? Ocorre sempre no mesmo horário? É sobre o mesmo problema? Isso gera relatórios importantes.
Por fim, a saturação indica o quão cheios estão os recursos do sistema. A Google também sugere o read e o use. O read (rate, erros e duration) foca na saúde dos serviços. Podemos olhar essas três métricas de cada microserviço e escalar quais têm mais erros, maior rate ou maior duração para responder, analisando os traces e tratando os problemas. O use (utilização, saturação e erro) é voltado para a infraestrutura. Observamos a utilização de recursos, a saturação e os erros na infraestrutura. Essas métricas permitem resolver problemas rapidamente e dar continuidade aos processos.
Na próxima aula, continuaremos discutindo observabilidade e veremos mais exemplos do nosso dia a dia.
O curso Observabilidade: integrar métricas, logs e traces com OpenTelemetry e Grafana possui 95 minutos de vídeos, em um total de 52 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:
