Fala galera, beleza? Já estamos chegando aqui na parte final da nossa jornada. A gente tem mais algumas aulas pela frente, então força e fé aí que vai dar certo. Pessoal, a gente já aprendeu bastante coisa, o Jaques, o Diego e eu, a gente já falou bastante com vocês sobre vários conceitos. O Jaques já fez um monte de hands-on, a gente já entendeu na prática como a coisa funciona quando a gente está falando de observabilidade. E aqui eu queria passar com vocês um pouco mais de algumas teorias. Por quê? Porque no dia a dia você vai ouvir falar de alguns conceitos e é importante você ter essas teorias em mente. A gente já abordou tudo que eu vou falar aqui com vocês durante o treinamento. Ou falando de forma prática ou entre as conversas que a gente foi tendo. Mas estrategicamente eu deixei essa parte mais teórica para o final, porque eu sei que ela acaba sendo um pouco mais maçante. Então, assim, a gente já sabe tudo o que tem para saber, e aqui a gente só fecha com os conceitos que a gente precisa compreender para no dia a dia a gente estar falando na mesma linguagem de todo mundo, beleza? Então, quando a gente está falando de observabilidade, a gente tem um conceito que chama os quatro sinais de ouro. Vai parecer muito inglês para vocês também, mas eu coloquei aqui em português porque a gente está no Brasil, afinal, não? Então quando a gente está falando dos quatro sinais de ouro, ele vai falar sobre quatro pilares ou quatro grandes grupos que a gente sempre olha quando a gente está falando de monitoração e de observabilidade, tá bom? A gente vai falar um pouquinho de cada um deles, mas a gente já passou por eles durante o treinamento. Então eu vou falar de algumas coisas específicas deles para ficar na sua cabeça, específicas deles para ficar na sua cabeça, para você lembrar quais são esses quatro sinais de ouro. Então tá bom. Quando a gente está falando disso, vai ser super importante você sempre pensar nesses quatro, porque eles vão ser base da maior parte das coisas que você vai pegar para fazer monitoração. Sempre que você pegar um sistema, esses caras vão estar presentes. Você sempre vai notar que eles estão ali como se fossem os padrões que a gente sempre utiliza, eles sempre vão comparecer quando você estiver falando de monitoração, beleza? Então vamos falar aqui do primeiro, o primeiro dele é latência, a gente já falou um pouco sobre latência, então latência aqui vai ser aquele tempo de uma requisição ser feita, ou seja, um pedido, um cliente acessar alguma informação, como por exemplo um saldo de conta corrente, e essa resposta chegar para esse cliente. Então imagina que eu fui lá, acessei meu saldo de conta corrente e eu tive de volta a resposta lá, putz, está devendo 5 mil reais, vai trabalhar. Mais ou menos isso. Então, quando a gente está falando de uma latência, seria esse tempo de resposta de ponta a ponta. Normalmente, a gente olha muito para o tempo de latência de rede, porque esse cara acaba atrapalhando algumas funções. porque quando a gente está falando de testes de performance que os times de engenharia e desenvolvimento fazem, normalmente eles pegam muito aplicação, então ele olha a sua aplicação, como ela responde, banco de dados e assim por diante. Mas eu vou dar um caso, imagina que é um caso real, eu já trabalhei em um sistema que a gente tinha o nosso aplicativo aqui no Brasil, esse aplicativo ele batia em uma aplicação aqui em uma conta AWS AWS Brasil ainda e depois ele ia para uma conta Azure Estados Unidos lá em Nova Virgínia então quando ele ia para essa conta Azure Estados Unidos eu tinha um tempo de latência de rede porque trafegar esse dado entre países acaba sendo um pouco mais lento e eu não consegui usar nenhum tipo de CloudFront ou nenhuma estratégia de trazer essa informação para o Brasil porque ela era uma informação que ela acabava mudando muito, era muito difícil de ter isso aqui. Beleza. Então eu tinha essa latência para ir, a mesma latência para voltar. Quando voltava, o meu sistema processava e devolvia outra latência. Depois de lá, ele me devolvia outra resposta, mais uma latência. Então eu tenho latência de rede de ir, voltar e ir e voltar. Se aqui eu tiver qualquer tipo de problema na rede, eu gero impacto gigantesco na minha aplicação. Então, é super importante vocês pensarem nisso. A latência é algo que a gente tem que olhar. E quando a gente fala de latência de rede, na minha opinião, do que a gente já teve aqui de experiência e do que eu já passei na minha vida, é uma coisa que a gente acaba não olhando tanto, não prestando tanto atenção e pode derrubar as nossas aplicações. Então é super importante vocês olharem. Então vamos lá, quando a gente está falando de latência, eu vou separar em dois tipos de latência que eu vejo mais no dia a dia. Então uma latência de sucesso que eu tenho que monitorar. Então quando eu tenho tempo médio para a solicitação que foi concluída com sucesso. Dentro de uma solicitação que foi ou assim por diante. Então eu preciso compreender como está dividido esse tempo para entender se está tudo bem. Se a minha latência começar a aumentar, minha latência de rede, talvez eu tenha que aumentar a banda, talvez eu tenha que tomar alguma estratégia em rede. Se eu olhar só latência ponta a ponta, pode ser que eu force mais a barra na minha API ou no meu banco de dados para eles responderem mais rápido. E não é ele o problema. Então você está vendo que aqui eu tenho uma latência do que deu certo, do que deu sucesso. Então quando eu olhar, a requisição vai ter rodado com sucesso, mas talvez o tempo dela de resposta vai ser um pouco maior e você compreender onde está esse tempo de resposta vai ser super importante, a quebra dele. Beleza? Tem outro caso que é o caso que normalmente a gente acaba falhando mais, que é a latência no erro. Quando você tem um tempo ali de solicitação que elas deram erro, você precisa pensar em como você vai fazer a monitoração disso. Vou explicar por quê. Nesse caso que eu falei para vocês, imagina que eu tinha aqui um gateway, esse gateway, ele estava esperando tudo isso acontecer, beleza? A aplicação do meu parceiro que estava lá na Azure Estados Unidos, ela não recebia um erro e ela não me devolvia um erro, porque afinal a comunicação foi fechada. Eu fazia uma requisição, ela ia, ela voltava e dava tudo certo, mas no gateway eu tomava um timeout, eu caía. O meu parceiro ele ficava cego nisso, ele não conseguia enxergar o que estava acontecendo, porque para ele, ele respondeu ok, ele não estava tomando o erro 500, nem tomando nenhum tipo de problema ali. Quem estava tomando o erro era eu, eu dava erro para o meu usuário, e depois eu tinha que voltar para ele e falar, cara, está acontecendo alguma coisa, porque eu estou dando muito erro para o meu usuário. Então, na minha observabilidade, eu pegava, porque eu conseguia pegar o tempo completo de requisição. Na dele, ele não pegava. Então, você está vendo aqui como é importante que ele estivesse monitorando também os tempos de rede para ele conseguir compreender que ele estava começando a estourar o tempo e que o meu gateway ia capotar aqui. Se ele tivesse monitorado os tempos de rede e os tempos de resposta, ele entenderia que quando chegou, por exemplo, para o segundo da requisição, ele já estava batendo ali 16 segundos. E vamos lá, ninguém vai esperar 16 segundos. Já vai começar a ter problemas quando a gente está falando de experiência e mais ainda quando você está falando de configuração básica de gateway, você vai começar a estourar ali com uns 30 segundos da vida, já não vai conseguir mais processar nada. Então você está vendo como é importante você ter um tipo de observabilidade aqui que consiga te mostrar tudo isso em ambos os pontos. Eu coloquei aqui um caso prático que fica fácil de compreender. Então vamos ficar esperto nisso quando a gente está falando de latência, beleza? Primeiro pilar, então, foi latência. Espero que tenha ficado na cabeça de vocês. Vamos para o segundo pilar? Tráfego. Quando a gente está falando de tráfego, a gente está falando do que está sendo colocado no sistema e como que ela consegue responder para isso. É o TPS. Então, quantas transações por segundo eu consigo responder? Qual a quantidade de dados que eu consigo trafegar e eu consigo devolver para o meu requisitante. Então aqui é super importante você entender a capacidade de escala que você tem para atender esse tráfego que está acontecendo aqui, para você saber adequadamente quanto você precisa aumentar ou diminuir para conseguir dar throughput para quem está te chamando. Ou seja, se você tem uma aplicação que ela consegue dar X% de throughput, X TPS, você precisa saber quanto você precisa ter de aumento, de escalabilidade, para conseguir dar mais TPS, caso entre mais requisições. Então, é super importante, se você tiver um dashboard que ele é cruzado, ou seja, se você tem a visão do que está chegando de requisição, ou seja, quantas pessoas novas estão entrando no meu marketplace, quantas pessoas novas estão entrando na minha página de compra com esse número mais a sua visão de TPS, você consegue ter alertas que vão te falar se a sua aplicação vai continuar respondendo ou se uma hora ela vai capotar, tá bom? Então se você tem previsão de pico, você consegue monitorar também esse tráfego pra entender esse tipo de coisa que eu falei pra vocês, olha eu vou ter uma Black Friday, vai entrar muito mais coisa o meu TPS do jeito que está não funciona, talvez eu tenha que escalar, pensar em alguma outra, outro tipo de estratégia, porque do jeito que está, o número de pessoas que a gente está esperando que entre, vai capotar minha aplicação. Então aqui é super importante você pensar nesse tráfego que é o número de pessoas que está entrando, o número de requisições, entenda do jeito que você entender quiser, dependendo do case que pode ser pessoas. Quando você está falando, por exemplo, de requisições de contabilidade, pode ser requisições para bater conta a conta, abertura de conta, valor resultante, assim por diante. Pode ser vários cenários, tá bom? Então, aqui, basicamente, você tem que preparar a infraestrutura para suportar ou conseguir monitorar a entrada versus o seu throughput, que você já pode conseguir compreender com testes de performance, que vai facilitar sua vida para também ter os alertas alinhados e afinados no dia a dia beleza outro caso que é o mais simples é o que normalmente o primeiro que a gente pensa que são as taxas de erro o quanto que a gente tá com problemas ou com falhas nas nossas requisições então lembra aquele primeiro cenário que eu falei eu tinha uma latência de rede não estava dando uma falha não tava dando um erro 500 como eu falei pra vocês, então eu acabava não tendo uma taxa de erro elevada. Para o meu cliente eu acabava caindo por tempo de resposta, time out, isso gerava erro e ok. Para o meu fornecedor dessa requisição, o cara que estava lá nos Estados Unidos, ele não estava enxergando nada, então a taxa de erro dele estava super baixo, ele ele conseguiria pegar por latência. Agora, imagina o contrário, imagina que ele começou a tomar algum tipo de erro e começou a me responder o 500, ele precisa começar a ter lá algum tipo de avaliação para ele saber se isso está acontecendo, se está normal ou não. Sempre vai ter um erro ou outro, dificilmente você vai ter uma aplicação que não vai ter erro nenhum, nunca ouvi falar de uma aplicação que funcione 100%, é sempre 99,9%. Sempre tem uma falha ou outra, isso vai acontecer. O meu ponto é, quantos porcento eu estou disposto a ter de falhas? Quantos erros 500 são comuns? Quantos erros 400 são comuns? Depende da aplicação que você está tendo. Então, ter os erros explícitos aqui, ou seja, quando o sistema vai retornar para você uma resposta indicando uma falha direta. 500 lá,u problema, não conseguiu responder, acabou. Não tem muito o que conversar. Esse cara vai contar para você esse X%, você tem que gerar um alerta e ter algum tipo de ação. Então, esse aqui é um primeiro cenário de erro. E os erros implícitos é quando ele mostra uma resposta bem sucedida, mas o conteúdo está esquisito. Então, o conteúdo pode ter algum tipo de erro lógico ou de processamento ali que não está abatendo tanto e pode gerar algum tipo outro de camada de erro, dependendo do que você tiver, ou pode gerar um código de erro diferente, ou você pode ter batimentos que conseguem pegar isso. Isso é importante eu falar para vocês. A gente está muito acostumado com receber direto nos nossos alertas os códigos de erro de aplicação normais. Mas tem casos onde você tem que validar dados. Então imagina que você conseguiu processar tudo isso, só que os dados na ponta não saíram tão bem. Então você ter algum tipo de automação que consegue bater dados para ver se está tudo ok, às vezes também faz sentido. Então, por exemplo, imagina que você tem lá dados do cliente, o endereço do cliente, e você consegue bater se o endereço do cliente foi atualizado ou não e se ele continua sendo o mesmo do que ontem. Então, se o seu cliente não atualizou o dado e você recebeu de um outro lugar um dado diferente de endereço de cliente, você poderia alertar se isso começasse a bater mais do que x% de divergência de dados em um caso desse cenário. E com isso você consegue se preparar para atuar caso aconteça. Então, é outro tipo de estratégia que você consegue fazer de monitoração também beleza? e o último cara que eu queria falar com vocês é a saturação ele vai falar aqui então quão cheio o sistema está ou seja, a utilização dos recursos mais críticos como CPU, memória, largura de banda e assim por diante, ou seja, a gente está falando se o sistema está aguentando ou se ele vai arriar. Então aqui basicamente o que a gente está falando é a monitoração ali na minha infraestrutura mesmo, propriamente dita, que também sempre aparece, é bem comum. Vocês estão vendo que eu não estou falando nada de diferente, é o BAU, é o que acontece no dia a dia. Para quem não está acostumado, BAU é Business as Us visual, então a gente está falando do que é normal, é o comum do dia. Então, esse tipo de coisa que é bem comum no dia a dia acontece direto. Então, o que a gente precisa fazer é, quando eu tenho uma monitoração de saturação, eu tenho que me preparar para uma possível sobrecarga, ou seja, quando eu vejo que está tendo algum tipo de aumento, eu já preparar algum tipo de ação automática ou algum tipo de alerta que faça esse sistema retomar. E planejamento de capacidade. Quando você sabe qual é o seu nível de saturação máximo que você pode ter, você consegue planejar para aumentar a capacidade ou não, caso seja necessário. Então aqui a gente falou dos quatro casos, dos quatro sinais de ouro aqui para ficar na cabeça de vocês. Vamos voltar para ficar na cabeça. Então vai ser latência, tráfego, erros e saturação, beleza? Se vocês tiverem isso na cabeça e alguém falar para vocês os quatro sinais de ouro, vocês já sabem o que é, esse é o conceito, nada de inventar roda e diferente do que a gente já viu no treinamento, mas é importante vocês terem para vocês conversarem, para vocês entenderem quando chegar isso aí no dia a dia de vocês, beleza?