Bom pessoal, falando agora do próximo pilar, que é o pilar de métricas, eu queria que a gente, antes de entrar no pilar de métricas, a gente fizesse uma análise aqui sobre qual a importância das métricas. Pensa no seguinte, imagina que a gente coletou todos os logs que a gente falou anteriormente, tem um monte de informação, mas como que eu sei, olhando para um log, se eu tenho uma informação boa ou ruim? Ou seja, imagina que você tem a sua API e ela responde em 100 milissegundos. Se eu te perguntar, e isso é bom ou ruim? Você precisa gerar um alerta? Você precisa tomar alguma ação ou não? Ou, sei lá, ela está respondendo em um segundo. É ruim? Depende, vai depender de muita coisa. Vai depender de como essa API foi construída, de qual experiência para o usuário que você está dando, de qual que é o produto que você está fornecendo. Depende de muita coisa, de qual o momento. Então, você precisa ter uma base analítica para você conseguir olhar para aquilo e tomar uma decisão se é bom ou ruim, se você tem que fazer algo ou se não, está tudo bem. Então, aqui é muito importante a gente olhar para métricas para a gente conseguir entender que o dado puro não vai chegar em lugar nenhum. Putz, a gente falou aqui sobre tempo de resposta de API. Normalmente, isso está mais na nossa mão. A gente consegue tomar essa decisão mais fácil, a gente consegue enxergar isso mais fácil. Mas tem outras tantas métricas que vão depender de uma análise de negócio junto com a análise de tecnologia, junto com a análise de tecnologia, junto com outras áreas que precisam estar juntas para compreender se aquilo vai fazer sentido ou não, para a gente conseguir definir os alertas em conjunto. Lembra que eu falei para vocês que, querendo ou não, a observabilidade traz ali uma intersecção entre as especialidades, como negócios, operações, sustentação e a nossa parte de codificação, porque ela precisa que essas partes, pelo menos essas partes, sentem juntas para definir como isso vai ser observado, como que a gente vai definir ações para isso e assim por diante. Então, basicamente, quando a gente vai falar de métrica, é para a gente conseguir chegar nessa solução, tá bom? Então, vamos dar uma passada aqui, mais ou menos, pelo que significa métrica, tá? As métricas, elas vão fornecer aqui uma visão quantificável do desempenho da saúde do sistema e vão permitir que a gente consiga detectar anomalias e avaliação de tendência ao longo do tempo. Quando eu falo de avaliação de tendência e anomalia, de novo, para você saber se é uma anomalia ou não, você precisa ter uma base. Se você não tem o que é normal, você não sabe o que é anormal. Então, é importante que você saiba o que é o normal. E tendência ao longo do tempo depende de base histórica. Para você saber a tendência, você precisa ter conseguido identificar como que foi isso para trás, como foi isso antes de chegar naquele momento, para você poder traçar uma tendência com base no que você tem de conhecimento. Então, tudo isso vai ser super importante para você traçar métrica. Elas vão te ajudar a identificar um problema, ou seja, eu consigo traçar uma tendência e ver que tudo que sai daquela tendência, tudo que sai daquela média, tudo que for anômalo, eu vou ter que gerar algum tipo de ação. E daí, com isso, eu consigo identificar e atuar antes de gerar qualquer tipo de impacto para o usuário final. Então, qual é o principal das coisas que a gente tem que pensar aqui? Tem que ter uma visão quantificável, ou seja, ela precisa oferecer ali dados objetivos que podem ser usados para tomada de decisão, ou seja, não pode ser um dado que ele não é objetivo, que ele é subjetivo, não pode ser um dado que fica no limiar entre faz sentido ou não faz sentido, pode ser um talvez, tem que ser sim ou não. Então você precisa ter um dado objetivo para tomada de decisão e para você conseguir tomar alguma ação, desde que seja acionar as áreas responsáveis até fazer alguma automatização e otimização de sistema. Outra coisa também que a gente tem que ter é a detecção de anomalias. Elas vão permitir que a gente consiga detectar essas anomalias que eu falei, que podem ser um possível problema no futuro. E avaliação de tendência, ou seja, com base nas métricas que eu tenho, eu consigo prever com as minhas regras de negócio e com as métricas já geradas, o que pode ocorrer no futuro. Então você consegue padronizar o futuro e conseguir mais ou menos mapear como vai ser aquilo no longo prazo. Eu comentei com vocês aqui sobre um caso, por exemplo, você pega Black Friday desse ano, imagina que você tem ali um e-commerce, você pega Black Friday desse ano, vê que você aumentou em 50% os seus acessos na Black Friday em relação aos meses anteriores. Quando você for para Black Friday do ano que vem, você já consegue se preparar, por exemplo, para durante aquele momento você escalar seu sistema para ele estar preparado para 50% a mais de acessos com base no que você já teve desse ano e coisas nesse sentido. Então, basicamente, vai trazer para vocês essa visão. Outra coisa que a gente tem que pensar aqui são os tipos de métrica que a gente pode gerar e eu elenquei aqui alguns que são interessantes. Tem mais, mas aqui eu elenquei os principais que a gente tem que olhar no dia a dia, tá? Então as métricas de desempenho, elas vão medir ali a eficiência do sistema. Uso de CPU, memória, tempo de resposta e taxa de transferência. Essas tem que ter, não tem como não ter. Essas você já tem que ter set O time de tecnologia consegue fazer isso sozinho. Você precisa saber quanto está tendo o percentual de uso da sua CPU e o que você vai fazer caso comece a estourar. O percentual de uso de memória, o tempo de resposta e a taxa de transferência. Aqui eu já vou aproveitar para dar uma dica que não tem a ver com observabilidade, mas com resposta a problemas. Quando a gente coloca esse tipo de métrica em algumas equipes que não tem tanto conhecimento e tanta implementação de sistemas mais robustos, a gente acaba colocando algumas estratégias de redis, por exemplo, algumas estratégias de cache, ou seja, de utilização de banco de dados em cache, a gente pode dizer desse jeito, informações cacheadas ali, e quando as pessoas colocam isso, eu já peguei muitas vezes, então fica aqui uma dica para vocês, uma dica até boba para algumas pessoas, mas quando vocês fizerem isso, não coloquem na mesma máquina que vocês estão colocando a aplicação de vocês, porque você vai consumir toda a sua memória, porque você está usando memória, para conseguir fazer esse tipo de utilização de cache, então você vai usar toda a memória daquela máquina e vai matar a memória que você precisaria para a sua aplicação. Então, aqui fica uma dica. Mas, no fim das contas, a gente está falando de métrica e métricas de desempenho. Vamos lá, CPU, memória, tempo de resposta, taxa de transferência, você tem que ter. Métrica de disponibilidade. Aqui é muito importante para você entender se está tendo um problema que está sendo específico com o problema generalizado. Então, quanto que está sendo a disponibilidade do seu sistema? Aqui é para responder aquela pergunta que sempre fica. Ah, o seu chefe vira e fala, putz, o sistema está fora. Você pergunta, tá, mas quantas pessoas pegaram esse sistema fora? Ah, só eu. Então, ele pegou um erro. Tá bom, pode ter sido só um erro, mas pode ter sido um monte. Então, quando você coloca aqui as métricas de disponibilidade, você vai conseguir entender se está sendo só um problema com você, com o seu chefe, com um usuário, ou com 500, ou com todos os usuários e assim por diante. E daí você vai conseguir ver quanto você está tendo de uptime e de downtime. E daí com isso você toma as decisões também. Métricas de erros também são extremamente importantes. Você conseguir separar isso no tipo de erro que você está tendo vai ser muito bom para depois você tomar a decisão mais rápido. Então, se você está tendo muito erro 500, você vai tomar um tipo de ação. Se está tendo muito 404, você já pode tomar outro tipo de ação e assim por diante. Tem as métricas de capacidade, que elas vão monitorar ali a utilização dos recursos de sistema, como espaço e disco e uso de rede também, que também é super importante e não pode nascer sem, tá bom, gente? Quando a gente está falando de métricas, então, vamos colocar aqui um cenário para a gente pensar junto. Imagina um cenário ali de uma aplicação web que ela está começando a apresentar lentidão durante o pico de uso. E quando a gente começou a mostrar essa lentidão, qual o propósito que a gente pode ter para conseguir enxergar isso, monitorar isso de forma boa, de forma rápida. Então, vamos monitorar ali as métricas de uso do CPU e memória. E com isso a gente já vai saber que está tendo lentidão, porque se você tiver uma CPU com alto consumo, uma memória com alto consumo, vai ficar mais lento, meio óbvio. Qual ferramenta você pode usar para pegar isso? Prometheus e Grafana, eu acho elas ótimas para fazer esse tipo de coisa. Tem outras também, mas Prometheus e o Grafana é um conjuntinho bacana para pegar esse tipo de problema. O Prometheus vai pegar ali as métricas de uso do CPU e memória dos servidores e o Grafana consegue criar os dashboards para você olhar se está tendo algum pico e com isso já sabe que você está gerando lentidão. Aí se você depois olhar o seu tempo de resposta de aplicação, que daí já é um log de aplicação, você consegue ver que está refletindo lá. Então o resultado aqui que a gente conseguiu com esse caso de uso é a identificação que o CPU está batendo, sei lá, 100% durante alguns picos de tráfego, ou seja, muita gente acessando e assim por diante, está consumindo muito. Isso vai indicar a necessidade de uma escalabilidade horizontal para você conseguir responder a isso, beleza? Agora vamos mudar um pouco, vamos falar de traces. Quando a gente está falando de traces, vamos voltar um pouco para os nossos logs. Imagina que o log ali, eles são as pegadas, tá? Então, eu até coloquei aqui um desenho das pegadas. Imagina que cada log é uma pegadinha dessa aqui, tá? É uma pegada, pegada, pegada. Esses são os logs. Na minha opinião, a forma mais fácil de você entender trace é você falar que você está tendo os logs organizados em cadeia para saber qual é a trilha que aquelas pegadas estão seguindo. Então, você consegue olhar o end-to-end para entender o fluxo que foi feito pelos logs e conseguir fazer um trace do que está acontecendo, uma relação dentro do sistema, beleza? Então, basicamente, você vai capturar todas as solicitações de todos os serviços e componentes do sistema, beleza? Então basicamente você vai capturar todas as solicitações ali de todos os serviços e componentes do sistema distribuído e você vai conseguir entender a relação e o fluxo entre essas partes e como elas estão gerando seus logs e gerando a sua conversa entre si. Beleza? Os traces ali eles são, como eu expliquei agora há pouco, eles são fundamentais para você conseguir seguir o caminho de uma solicitação de ponta a ponta. Então, ele é end-to-end. Você consegue identificar ali gargalos de desempenho, falhas nas interações entre os serviços e assim por diante. Você não tem mais aquela visão unificada, você tem a visão toda, a visão do sistema todo, da função inteira de ponta a ponta. Você não tem mais só o log da aplicação que consome o banco de dados. Você tem o trace de como que o cliente acessou para conseguir, por exemplo, fazer um pagamento, como a gente falou no exemplo anterior. Puts, eu fiz uma compra e eu preciso fazer um pagamento. Se eu tenho só os logs separados e não consigo fazer o trace da coisa toda, eu não sei se esse cliente começou e até onde ele foi para conseguir fazer essa coisa acontecer, tá bom? Então aqui você vai ter uma visão end-to-end, ele vai começar a oferecer para você uma visão completa do fluxo de solicitação em todos os serviços que estão envolvidos, tá? Então, ele é uma visão mais organizada do todo e vai te ajudar muito no diagnóstico de problema. Na verdade, para mim, se você não tiver como fazer um tracing quando você tiver algum problema, dificilmente você vai entender onde estão sendo os grandes problemas ali. E você consegue fazer otimização de performance porque quando você está fazendo o tracing do seu sistema, você consegue ver aonde que está gargalando mais. Pensa que quando a gente constrói um sistema mais complexo, maior, às vezes a gente fala de quanto que cada microserviço está tendo de tempo de resposta, cada microserviço está conseguindo ser eficiente. Mas se você não olha no todo, você pode ter um cara que é muito bom, outro que é muito ruim, e no todo, pouco importa se você é muito bom, porque todo o resto está atrapalhando o fluxo completo. Então é importante você estar usando o todo para ver onde gargala e onde não gargala, beleza? Agora falando de Trace ainda, quais são os componentes que a gente tem no Trace? A gente tem os Spans, que são ali as unidades básicas de um Trace, que são as operações individuais. Cada Span tem a informação de timestamp, duração e logs de evento. Então você consegue agrupar isso por cada passo da coisa, tá? São as unidades menores ali. Os três, eles são os conjuntos de spans que representam a jornada completa de uma solicitação através do sistema distribuído. Então você vai pegar todos esses spans que você tem ali pra conseguir juntar a história toda. Eu chamo de log o span, ele tá aqui um conjunto, tá? Ele pode ser alguns logs de eventos com o timestamp e a duração daquilo. Mas eu chamei de log anteriormente porque no fim das contas aqui você só está agregando um pouco mais de informação, mas o que você está querendo dizer é uma unidade, como a gente não tinha falado ainda de spans, eu achei melhor fazer o paralelo com o log das pegadas, mas imagina que a pegada aqui, quando a gente está falando dos Trace, são os Spans, porque você pode agrupar logs de eventos em determinados pontos, e pode ter timestamp e duração agregados a essa informação também, para ficar mais fácil de você fazer essa rastrabilidade, tá bom? O contexto ali do Trace é uma coisa muito importante também, que é a informação que você vai passar entre serviços, que vai falar como você correlaciona os spans individuais em um único trace. Ou seja, como cada coisa se fala para você conseguir fechar uma cadeia, uma corrente de comunicação, beleza? Isso é extremamente importante, gente. Outra coisa aqui que eu coloquei para a gente pensar um pouquinho, vamos colocar um case para a gente analisar. Então aqui, vamos lá. Uma identificação de gargalos de latência. O cenário é o seguinte. O serviço de streaming de vídeo está enfrentando muita reclamação que os vídeos demoram para carregar. Beleza? E daí quando você vai usar o Tracing para identificar onde está acontecendo a latência, você pode fazer o seguinte processo. Você vai implementar em Spans em todos os microserviços envolvidos na entrega dos vídeos. Então você vai ter todos aqueles agrupamentos de informação. O Jager, que é uma ferramenta que eu acho bem interessante para fazer isso também, ele vai coletar a visualização dos traces e vai destacar a duração de cada spam. E daí com isso você consegue ter um mapa de o que está demorando mais. Quando você tem esse mapa, o Splunk é bom para fazer isso também, eu gosto muito do Splunk. O Splunk, ele consegue te mostrar como que está a correlação entre as aplicações e entre os spans aqui no nosso caso, e com isso você consegue ver quem está demorando mais, e quem está demorando mais você ataca para resolver o problema. Então, nesse tipo de problema aqui, a gente pode ter identificado que o serviço de transcodificação, ou seja, um dos serviços ali, ele estava colocando uma latência maior por algum problema e a gente tem que analisar aquele serviço para entender. Pode ser vários problemas. Mas, basicamente, o que a gente está mostrando aqui é que a gente tem os spans, que são as suas unidades, conversando entre si. E quando você tem um mapa disso, fica muito fácil de você enxergar e resolver