Olá, vamos iniciar agora o módulo de observabilidade. Bom, nesse módulo faremos um overview sobre o que é observabilidade, passaremos pela definição, conceito, a importância, falar um pouco do objetivo, algumas metodologias e ferramentas que a gente consegue utilizar nesse contexto, e também sobre os principais pilares, que são eles os logs, métricas e traces. Observabilidade. Observabilidade refere-se à capacidade de entender o comportamento interno de um sistema, principalmente através da análise de dados gerados por seus componentes. Isso inclui logs, métricas e traces, e outros tipos de informação que podem ser coletados e analisados para diagnosticar problemas, entender o desempenho e tomar decisões sobre como melhorar ou otimizar o sistema. A observabilidade é fundamental para garantir que o sistema seja robusto, resiliente e capaz de atender aos seus objetivos de disponibilidade e confiabilidade. Bom, e falando de arquitetura distribuída, temos diversos benefícios na utilização desse tipo de arquitetura, todavia, junto com esses benefícios também vem algumas complexidades, e uma delas é justamente a gente conseguir fazer a monitoração em cima de todos esses componentes. tinha ali um agente que ficava instalado no servidor, no sistema operacional, mesmo que fossem sistemas operacionais virtualizados, mas a gente tinha uma quantidade mais reduzida de servidores, tinha um agente, algum componente que era instalado dentro desses sistemas, e ele trazia ali toda a parte de telemetria para a gente. para a gente. Todavia, quando a gente fala de microserviço, quando a gente fala de cluster Kubernetes, a gente fala de ambientes que são distribuídos e tem um poder de escala muito maior, é impossível que a gente tenha esse mesmo mecanismo para conseguir ter essa telemetria para esse ambiente. Então, é aí que entra esse conceito de observabilidade, onde a gente vai explorar não só os logs, que eu acho que é um pouco mais comum quando a gente fala de ambientes, quando a gente tem que fazer algum tipo de troubleshooting ou entender o que está acontecendo no ambiente, mas explorar bastante também o pilar de métrica e o pilar de trace, porque quando a gente tem esses 3 pilares combinados de uma forma eficaz, a gente consegue proporcionar uma compreensão bem abrangente e detalhada do comportamento e desempenho de um sistema como um todo. Então, permitindo que engenheiros de SREs ou time de operação ou mesmo desenvolvedores, engenheiros de software, consigam entender e gerenciar o ambiente e também fazer a otimização da infraestrutura e dos microserviços de forma geral. Bom, então antes da gente se aprofundar nos pilares específicos da observabilidade, vamos pacificar alguns pontos que são super relevantes aqui também para o entendimento de todo mundo. O primeiro é a gente conseguir fazer a distinção entre sintoma e causa, certo? Onde, se a gente for falar aqui de observabilidade como um todo, monitoração, a gente visa responder principalmente duas questões, que seria o que está quebrado e por que está quebrado. Então, se a gente for na linha do que está quebrado, vai mais na linha de a gente identificar o sintoma, certo? E o por que iria mais na linha da causa pegando como base aqui uma tabela retirada de um dos livros do google a gente tem alguns exemplos do que seriam sintomas e do que seriam causas tá então aqui está pegando a primeira linha como referência, a gente conseguiu ter um sintoma de que a gente está servindo páginas com status code 500 e 404, com erro, e a causa é porque o banco de dados está recusando conexão dos servidores, certo? Então, um exemplo bem claro do que seria sintoma e do que seria a causa. Na segunda linha, a gente tá falando aqui de respostas com lentidão certo e tá sendo ocasionado aqui por overload de CPU por conta de um bogosorte que é um algoritmo ineficiente né de ordenação ou um cabo cabo Ethernet que não está bem conectado, fazendo com que a gente tenha perda parcial de pacote. Então, acaba aí a causa que leva justamente a esse tipo de sintoma de lentidão. tipo de sintoma de lentidão. A terceira linha seria usuários que não estão recebendo GIFs animados de gatos e isso está acontecendo por um problema que a gente está tendo na nossa camada de CDN, por conta de uma blacklist que está com alguns IPs que não estão liberados. E pegando o último exemplo, a gente tem aqui um conteúdo privado que está aberto. Então isso porque a gente está tendo algum problema de ACL, foi uma nova versão de software, ACL, certo? Foi uma nova versão de software e a gente acabou esquecendo ali de fazer as liberações devidas, né, de todas as requisições dentro da nossa ACL. Então, isso seria um exemplo, seriam exemplos de sintoma versus causa. Uma coisa que a gente precisa ficar atento é que dependendo da camada a gente pode ter percepções distintas do que é sintoma e do que é causa, principalmente quando a gente fala em arquiteturas que são multicamada. Então tomando um ambiente desse como exemplo, vamos supor que o sintoma de uma pessoa pode ser a causa para outra. Então, por exemplo, se o desempenho de um banco de dados está lento, essa lentidão no banco é um sintoma para um DBRE, por exemplo, que está fazendo essa detecção. No entanto, se a gente for pegar um SRE que esteja mais focado na camada de front-end e que está observando a lentidão na ponta do site, das requisições, a lentidão no banco de dados é a causa, certo? Então, é importante também ter isso em mente, porque aí a gente conecta um pouco com o nosso próximo assunto aqui, que é justamente a questão dos conceitos aqui de Blockbox e de Whitebox, tá? Bom, falando primeiro aqui sobre Blackbox, ele é mais focado em sintoma e problemas ativos, fazer a detecção quando o sistema não está em funcionamento corretamente no momento e útil para alertas, pois aciona a intervenção humana quando há um problema real em andamento. a um problema real em andamento. Já para o Whitebox, ele é mais indicado quando a gente está falando de inspeção no detalhe de sistemas internos, como logs e endpoints HTTP, identificação de problemas iminentes e falhas mascaradas por tentativas de repetição e essencial para depuração, troubleshooting, pois permite entender aqui a percepção de desempenho de diferentes componentes como essas camadas de arquitetura que eu comentei. Então as principais diferenças aí é que o black box é mais orientado por sintomas, enquanto o white box pode ser orientado tanto por sintoma quanto por causa, dependendo da informação que a gente tem disponível. E o black box é limitado para detectar problemas iminentes, enquanto o white box é mais abrangente e detalha para monitoramento e diagnóstico. Aqui a gente está falando, para tentar tangibilizar um pouco melhor, quando a gente fala de white box, e se a gente tivesse que focar mais em um ou mais em outro, eu diria que é mais importante a gente ter um white box mais bem alinhado, justamente porque esse cara é o cara que faz a detecção interna do nosso sistema. Então, é onde a gente vai ter o nosso código rodando e o código vai ter que ter todo o tratamento de exceção com a geração de logs para a gente conseguir entender o que está acontecendo quando a gente tiver que anal a gente conseguir entender o que está acontecendo, quando a gente tiver que analisar para entender o comportamento em produção, é o cara que vai ter ali a geração das métricas, para a gente conseguir entender se de repente a gente está tendo algum problema, seja ele de infraestrutura, seja ele na camada mais aplicacional, é onde a gente vai conseguir fazer a instrumentação dos nossos traces, para a gente conseguir ter todo o tracking também de como está descendo essa requisição e onde pode estar algum possível erro, alguma possível lentidão. Já a questão do black box, ela é um pouco mais externa, então seria, por exemplo, fazendo uma analogia para a infraestrutura, seria algo como assim, white box, a gente vai conseguir monitorar CPU, memória, disco e networking, enquanto uma black box, ela vai fazer, por exemplo, um SMTP de ficar pingando uma máquina para saber se ela está respondendo, de bater numa URL de health check para saber se a aplicação está respondendo. Então, ambas são importantes, porque se eu estou chamando uma URL de health check de uma aplicação e ela não está respondendo, eu tenho um problema. Mas, beleza, qual que é o tipo de problema? Aí a gente vai ter que se aprofundar, e quando a gente tiver que se aprofundar, passa a ser muito mais importante a gente ter ali toda a parte de instrumentação, vamos dizer assim, de log, metric e trace para o white box, tá bom?