Bom, e falando um pouquinho mais sobre os traces, os traces são uma forma de monitoramento que captura e rastreia as chamadas entre diferentes serviços de um sistema distribuído. Eles fornecem uma visão detalhada do fluxo de uma solicitação desde o início até o fim, incluindo todas as interações entre os serviços ao longo do caminho. serviços ao longo do caminho. Cada parte do trace é chamado de SPAM e representa uma unidade de trabalho como uma chamada de função, uma requisição HTTP ou uma solicitação aqui a um banco de dados. Bom, e aí entrando um pouco mais no detalhe aqui dos traces distribuídos de forma geral, a gente tem então o trace ID, que é um identificador único para uma solicitação ou uma transação que vai percorrer por vários serviços. Então lembra que aqui a gente está falando de um ambiente que é distribuído também. um ambiente que é distribuído também. Os SPAMs, de fato, que são as unidades individuais de trabalho dentro desse trace. Então, cada SPAM tem o seu próprio identificador, que é um SPAM ID, além de detalhes como o início e término, a duração e também alguns metadados. Os metadados em si, que incluem informações como nome do serviço, nome da operação, status e qualquer outro dado que seja relevante. E o contexto de correlacionamento, isso daqui é de suma importância, porque essa é a informação que é passada entre os serviços para que a gente consiga manter o contexto do trace, geralmente incluído nos headers das requisições. Então, aqui a gente, basicamente, se a gente estiver pensando em um ambiente onde tem diversas camadas, como um BFF, a gente tem um front-end, a gente tem um BFF, a gente tem API, a gente tem um banco de dados, a gente tem integração com diferentes tipos de serviço, como um Secrets Manager para consultar ali, de repente, uma credencial do banco, ou a gente tem algum processo assíncrono e bate em um SQS, em uma fila. tem algum processo assíncrono e bate num SQS, numa fila. Quando a gente tiver com um problema no ambiente e a gente precisar fazer qualquer tipo de troubleshooting, pensa nisso para milhares de serviços rodando ao mesmo tempo em diversos clusters diferentes, para a gente conseguir chegar exatamente, que a gente de repente está para um microserviço em específico, tendo uma lentidão que é um pouco maior, quando a gente vai fazer a requisição para o banco de dados. Chegar nesse tipo de conclusão, de uma forma rápida, é super complexo, se a gente não tiver com os traces, com os traces bem definidos, com os alertas anteriormente que a gente comentou também. Para que a gente consiga saber exatamente tudo o que está acontecendo em uma requisição, a gente precisa fazer com que essa requisição desde o ponto inicial desde o ponto de contato do cliente até ao processamento dessa requisição no último componente ali a gente precisa fazer com que eles se correlacionem tá então isso é feito basicamente através de um parent span id, que é o cara que a partir dele vai ser gerado os outros spans, e fazer com que a gente passe o contexto de correlacionamento, para que quando a próxima peça for chamada, ele entender que essa é a mesma requisição, vai colocar aquele mesmo cara ali também, quando a gente fizer o próximo componente é a mesma coisa, é a mesma coisa, e aí fica bem bacana porque a gente consegue depois ter um service map, e aí com esse service map a gente consegue ser muito mais assertivo em onde pode estar o problema. Bom, então imagina um sistema de e-commerce, por exemplo, onde o cliente faz um pedido e a solicitação passa por diversos serviços. Suponha que a gente tenha aí então o front-end, que recebe a requisição do cliente, uma camada de autenticação, a parte de processamento do pedido, verificação da disponibilidade do produto, o processamento do pagamento e a notificação de que o pedido foi feito com sucesso, enviar uma confirmação por e-mail. Foi um pouco do que eu comentei, a gente precisa fazer com que essa requisição seja correlacionada. E aí a gente trabalhando da forma correta, tendo esse contexto de correlação, utilizando o header para poder fazer a propagação desse contexto e propagando o spam de bonitinho, a gente vai ter uma visão muito parecida com essa então a gente tem um cliente chamando um ponto de contato que nesse nosso caso seria o front-end service e aí tipo vai chamar o out-service que vai chamar o order-service então perceba a gente consegue ter o tracking de toda a requisição, e se a gente tiver qualquer tipo de componente que esteja com problema, se a gente tiver um componente que está respondendo com um tempo de resposta maior, batendo o olho nesse Service Map, vai ficar extremamente fácil da gente conseguir falar assim, opa, já tem uma luz, já sei onde eu vou buscar. E aí a gente vai olhar os nossos logs, vai olhar nossas métricas, vai entender se a gente teve algum alerta nesse meio tempo, se pode estar sendo algum problema de saturação. E aí começa a correlacionar, percebam, começa a correlacionar os princípios que eu comentei com vocês ali nas primeiras aulas desse módulo. Então, quando a gente consegue unir essas três coisas, a gente tem muito mais condição de ser assertivo e onde pode estar o problema, fazer o troubleshoot de uma forma muito mais rápida, melhorar nosso MTTR, conseguir ter uma observabilidade até prévia, né? troubleshooting de uma forma muito mais rápido, melhorar nosso MTTR, conseguir ter uma observabilidade até prévia, né? Então, se a gente estiver conseguindo ter métrica pra tudo, a gente consegue até ter alertas ali que com o threshold um pouco mais baixo e a gente ter algum tipo de atuação mais proativa e mais preventiva também. Então, assim, esses três pilares aqui são extremamente poderosos falando um pouquinho mais ainda dos três algumas ferramentas que tem um pouco mais de familiaridade eu vejo o pessoal utilizando com bastante frequência seria o Jaeger que é uma ferramenta open source que foi desenvolvida pela Uber, tem o Zipkin também que também é uma ferramenta open source desenvolvida pelo Twitter e como eu comentei para vocês também tem o OpenTelemetry que o pessoal tem adotado aí com bastante frequência que é um conjunto ali de SDKs vamos dizer assim, tipo open source, para coleta de telemetria. Para algumas linguagens a gente já consegue utilizar o OpenTelemetry para tracing, métrica e log. E o interessante é que ele dá um poder ali de deixar a nossa instrumentação, vamos dizer assim, um pouco mais agnóstica. Então a gente basicamente vai desenvolver tudo no padrão do OpenTelemetry, e o OpenTelemetry vai fazer a integração ali do Collector, vai fazer a integração ali com diferentes exporters e aí a gente pode ter poderia ter o Jager poderia ter o Zipkin poderia ter um X-Ray poderia ter uma ferramenta de um motoclub provider e a gente não precisaria mexer no nosso código para a gente conseguir ter esse mesmo tipo de visibilidade tá