E entrando um pouquinho mais nas metodologias de observabilidade, eu vou passar por algumas delas aqui. A principal talvez seja a For Golden Signals. Então, quando a gente fala de For Golden Signals aqui, a gente está falando de latência. Então, o tempo que leva para atender uma solicitação. para atender uma solicitação. Então, é importante distinguir entre a latência de solicitações bem-sucedidas e as que a gente teve falha. Então, a gente está falando aí, por exemplo, de um erro 500, que pode ter respondido de forma rápida, mas é uma request com falha. Então, é crucial que quando a gente estiver fazendo os nossos dashboards relacionados à latência, a gente consiga ter esse tipo de distinção. Tráfego, que é a medida da demanda do sistema, expressa em uma métrica específica para um serviço web pode ser o número de requisições HTTP por segundo, por exemplo. Então, se a gente estiver falando, sei lá, de uma aplicação, de um sistema que faça streaming de áudio, a gente pode, de repente, o tráfego, a gente já vai estar falando de I.O., de tráfego de rede ou de sessões abertas simultaneamente, ou para um sistema que seja de chave-valor, a gente pode estar utilizando o tráfego mais no sentido de transações e recuperações por segundo. no sentido de transações e recuperações por segundo, certo? Erros, então a taxa de solicitações que falham, seja explicitamente, como erros 500, ou implicitamente, como respostas HTTP com conteúdo errado, né? Ou por política, como respostas que excedem um tempo limite. Então aqui a gente já está falando um pouco de erros numa linha de SLO, certo? Então monitorar erros pode envolver diferentes tipos de método, como capturar erros 500 em um balanceador, um load balancer, né? Ou utilizar algum tipo de teste, end-to-end, para a gente conseguir fazer a detecção de se a gente tiver algum tipo de conteúdo errado, nesse caso de estar servindo ali com status code errado, e aí seria um erro mais funcional, vamos dizer assim. E saturação, que mede a fração de utilização do sistema, destacando os recursos mais utilizados, como CPU, memória, network, disco, storage. Então, pensando aqui em uma API, é super importante que a gente também consiga ter esse tipo de visibilidade, se a gente está tendo algum tipo de degradação no nosso microserviço, porque naturalmente, se isso estiver acontecendo, vai começar a impactar ali em outras coisas, né, a gente pode começar a responder, afetar erro, né, porque a gente vai começar a responder, de repente, com o erro 500, ou a gente pode ter um afetar ali a questão de latência, né, porque a gente vai estar muito mais lento e a gente vai passar a exceder os tempos que a gente estabeleceu. Então, falando de metodologia, sempre que a gente for começar a montar a observabilidade de alguma peça, de algum componente do zero, o Fargo Designals é uma boa linha de raciocínio que a gente pode seguir, tá? Porque eu acho que a gente consegue ter uma abrangência, uma completude bem legal, assim, né? Pegando cada um desses pilares, olhando cada um deles, falando assim, ó, deixa eu ver se eu tô conseguindo cobrir, se eu não tô conseguindo cobrir, se eu tô conseguindo passar pelos quatro pilares. E pegando como exemplo aqui um dashboard de um componente que é o API Server, que é o cérebro ali, vamos dizer assim, do control plane de um Kubernetes, a gente tem um exemplo do que seria uma visão, uma visão simplista, dá para deixar isso aqui explorar outros pontos né ainda nessa linha do Golden Signals mas percebam né a gente consegue aqui já tem uma visibilidade de request por minuto poderia ser request por segundo, tá? A gente tem aqui a visão Tanto do total Quanto um timeline Então a gente consegue saber se Puta, tá maior, tá menor agora A gente consegue ter visibilidade da latência Né? Então na mesma linha Tipo, quanto que tá a latência agora Quanto que se ela subiu, desceu Como que tá o comportamento dela Ao longo do tempo Certo? Se a gente está tendo erro, então aqui com certeza a gente está pegando erros do tipo 500, por exemplo, que pode estar significando algum erro para a gente, a gente poderia separar, de repente criar até mais divisões, como eu comentei, ter um dashboard só para requests com sucesso, outro para, de repente, requests com status code 400, outros com requests 200 com sucesso, outros com 400, outros com 500, que já falha do nosso lado mesmo, do lado do server. A gente tem dashboards aqui de CPU, memória, que pode estar mais relacionada ali já com a questão de saturação, e também de networking, para a gente conseguir mensurar qual que está sendo o tráfego na mesma linha, a gente conseguindo pegar o de agora, pegar o timeline, e aqui também dá para, com base nisso, explorar muito, muita coisa. Mas, fora o For Golden Signals a gente também tem aqui algumas outras metodologias uma delas é o Use, o Use a gente está falando basicamente de utilização então a porcentagem do tempo que esse recurso, determinado recurso estava ocupado, estava sendo utilizado. A gente pode estar falando também de saturação e erros, certo? Seria uma contagem da quantidade de eventos com falha e a saturação ali, se a gente está tendo algum problema de autoconsumo de algum tipo de recurso computacional. A gente tem a metodologia READ, onde a gente está falando basicamente de rate, então, número de requests por segundo, por exemplo. Mesma coisa, erro, quantos requests estão falhando, quantos não estão, e a duração, que a gente também poderia estar falando de latência. Basicamente, quanto tempo a gente leva para responder as nossas requisições. Então, ambas essas metodologias, dependendo do que a gente estiver monitorando, pode ser uma boa linha de raciocínio também. Não necessariamente a gente ficar preso só ao Golden Signals especificamente. ficar preso só ao Golden Signals especificamente. E quando a gente fala ali até de metodologias para a gente conseguir ter um bom norte, vamos dizer assim, para a gente traçar SLOs, a gente também pode estar comentando aqui do wallet. Então, o V seria de volume, qual que é o tráfego né então é quanto de volume está passando ali no meu serviço quanto o serviço consegue suportar é disponibilidade então se nosso serviço ativo né quando é necessário latência é se a gente está conseguindo responder dentro do que a gente espera, erros, certo? Então, se a gente está gerando algum tipo de erro quando as requisições estão subindo, se a gente está incrementando o erro, não está, quais são os tipos de erro e também os tickets. Então se de repente a gente está tendo muito ticket aberto para fazer intervenção manual, na linha de definição de SLOs, eu acho que o Valet consegue contribuir também com uma boa linha de raciocínio para a gente conseguir fazer as nossas definições.