Falando um pouquinho mais aqui sobre as métricas, né? Métricas são medidas quantitativas que descrevem o comportamento de um sistema em determinado momento. Elas podem incluir informações como uso de CPU, utilização de memória, taxa de transferência de rede, número de solicitações por segundo e muito mais. Métricas são fundamentais para monitorar o desempenho do sistema, identificar tendências ao longo do tempo, definir alertas e tomar decisões com base em dados objetivos. Elas ajudam a entender o estado atual e a saúde do sistema. Então, existem diversas ferramentas aí que podem nos auxiliar também nesse pilar de métrica, tá? Elas vão ter ali basicamente uma arquitetura ou pool-based ou push-based. Eu vou me basear aqui no Promifius, que eu acho que é uma ferramenta bastante adotada no mercado, de forma geral, e é uma ferramenta do tipo pool-based. E aí como que funciona esse mundo das métricas? A aplicação vai ter ali as métricas instrumentadas, então a gente vai ter alguns tipos de métrica que a gente consegue trabalhar, eu vou passar um pouquinho mais no detalhe mais para frente, mas basicamente essas métricas estando prontas, a gente precisa fazer a exposição delas através de algum endpoint HTTP, tá? Por padrão, a gente fala ali de fazer a exposição num barra metrics da vida, e aí pode ser, de repente, se tiver no Kubernetes ali, um service, né, pra isso, mas a gente precisa fazer a exposição via HTTP, tá? Dessas informações, e vai ter um padrãozinho ali, que vai estar exposto. A gente vai ter um componente dentro da nossa infraestrutura que vai ser responsável por fazer o que a gente chama de scrape das métricas. Então, ele tem um service discovery ali onde ele consegue identificar todos os serviços que estão expostos dentro do ambiente. Ele vai identificar esse serviço, vai ter uma configuração específica para ele, que a gente chama de Service Monitor, para indicar quais são os services que ele tem que bater. Ele vai bater na sua aplicação que está expondo expondo lá um barra metrics da vida, vai conseguir shippar essas métricas e vai escrever em algum TSDB, que seria algum Time Series Database, certo? Se a gente estiver utilizando o próprio Promifius, ele consegue fazer essa atividade de ir lá na aplicação, fazer o scrape e escrever numa própria base de dados interna dele. Mas, em muitos casos, a gente acaba, até por uma questão de a gente centralizar essas métricas, a gente conseguir ter uma governança um pouco maior, a gente acaba pegando, não descentralizando essas bases de dados. Então, muitas vezes a gente faz esse processo de buscar essas métricas, a gente pode até deixar para algum tipo de retenção menor, tipo uma hora, duas horas localmente ali, mas geralmente a gente já faz a escrita remota já faz um remote write para algum outro componente centralizado pode ser de repente um próprio promífios, pode ser uma ferramenta como o Thanos que consegue ter alguns níveis de inteligência adicional para trabalhar com dados em um volume maior mas geralmente a gente centraliza adicional para trabalhar com dados em um volume maior, mas geralmente a gente centraliza, e aí a gente faz esse processo de escrita remota. E aí a gente vai na nossa ferramenta de visualização, então até aqui a gente está falando, já consegui fazer o scrape, já consegui ter um enriquecimento nesse processo de scrape, já consegui ter um de repente um enriquecimento nesse processo de scrape e aí escrevi numa base de dados, agora eu preciso visualizar essas métricas de alguma forma e a ferramenta que a gente pode utilizar para isso pode ser muito bem um grafana esse grafana a gente cadastra ali alguns data sources, e o data source que a gente vai cadastrar nesse caso vai ser um data source do tipo Promifios, por exemplo, e a partir daí a gente consegue já fazer consultas ali, o que a gente chama de PromQL, fazer algumas queries para buscar as informações que a gente deseja. E aí no próprio Promifios a gente também consegue cadastrar alguns alertas, e aí nesses alertas a gente vai se preocupar com coisas como severidade, de repente colocar um texto básico descritivo do que é aquele alerta, se ele vai ter um pooling ou não, então bati ali na métrica vi que deveria alarmar beleza, eu já gero uma alerta de fato, ou eu espero, sei lá, 5, 10 minutos para bater de novo, e só aí que eu realmente gero esse alerta então dá para a gente fazer esse esse alerta. Então dá para gente fazer esse tipo de configuração. Dá para colocar algum tipo de sumário também para gente ir na linha já tipo, putz, se der um problema tal, já coloca ali para direcionar o time de operação para olhar um humbook XPTO. Então é possível a gente fazer esse tipo de integração. E, uma vez que a gente tem esse alerta configurado, a gente consegue também fazer integração com ferramentas. O alerta no Promifios, a gente só vai conseguir enxergar no Promifios. Para a gente conseguir, por exemplo, receber esse alerta, ser notificado em uma ferramenta como o Slack, o Teams ou alguma ferramenta que a gente tem ali uma geração de incidentes, a gente precisa de um outro componente que seria o alert manager, e aí o alert manager é o cara que vai ser responsável por receber uma notificação do Promifius e falar assim, opa, tem um alerta aqui que entrou em firing pega esse alerta aqui que entrou em firing, né? Pega esse alerta, dá para a gente fazer um enriquecimento nele também se for necessário, e fala assim, cara, agora eu tenho minhas integrações aqui conectadas no Alert Manager e eu saio fazendo todas essas notificações, tá? Bom, e como que é a anatomia de uma métrica? Então, ela basicamente vai ter um nome, e aí esse nome, existem algumas boas práticas para a gente trabalhar, então, se a gente estiver falando de uma métrica onde a gente consiga ter, por exemplo, a quantidade total de requisições na nossa aplicação, que seja uma aplicação http poderia ser uma métrica aí com o nome por exemplo http__request__total pensando em cpu alguma métrica ali com o nome de cpu usage percentage ou de repente memory usage bytes então existe um padrãozinho para a gente convencionar aqui mas toda métrica vai ter um nome e é importante a gente seguir esse padrão para a gente conseguir para a gente não se perder em produção vai ter muita métrica então a gente não pode perder muito tempo tentando identificar qual é a métrica que a gente quer consultar, né, para investigar ali algum tipo de coisa que pode estar acontecendo. Essa métrica, ela também vai ter um valor, né, então uma medida quantitativa. Então, sei lá, pensando aí no exemplo do HTTP Request Stotal, a gente pode, vai ser uma métrica do tipo counter, né? Vou comentar um pouquinho mais para frente também. Mas, basicamente, ela vai incrementando. Cada vez que você receber uma requisição, ela vai incrementando, né? 1, 2, 3, 4. Ela só incrementa, nunca tem um decréscimo desse valor. Para esse tipo de métrica, por exemplo, se forem outros tipos de métrica, como alguma métrica, sei lá, de repente 0 ou 1, se a gente bater num health check, se tiver ok é 0, se não tiver ok é 1, já seria uma métrica do tipo gauge, por exemplo, mas o valor dela ali, toda métrica vai necessariamente também ter um valor. Aí a gente vai ter um timestamp, então, para que a gente consiga ter aí uma análise temporal, isso é super importante, e quando a gente está falando de trabalhar ali com ambientes que soluções que são time series databases, né? Então, é uma informação que é super relevante também. A gente vai ter algumas labels, tá? Que adicionam contexto para filtragem e agregação. Então, aqui a gente pode estar falando, por exemplo, pensando em uma API, né? HTTP. Qual que é o path? O path, né? Poderia ser uma label. qual que é o path, o path poderia ser uma label, qual que é o método, qual que é a região que eu estou fazendo aquela requisição. Então, todas as informações que são relevantes para que eu consiga ter algum tipo de diferenciação na minha aplicação é importante que a gente tenha uma label, mas também é super importante tomar muito cuidado com o que a gente coloca porque a gente nunca pode utilizar, por exemplo um valor que tem uma altíssima probabilidade de alteração como por exemplo, um valor que tem uma altíssima probabilidade de alteração, como, por exemplo, um ID. Um ID é único, a gente sempre vai ter ali ID 1, 2, 3, então se a gente colocar um ID como uma label, a gente vai acabar tendo um problema de cardinalidade porque é quase como se cada métrica, dependendo das labels ali, quando tem algum tipo de alteração, ele meio que cria uma time series dedicada para esse cara. Então, se a gente toda hora estiver trocando esses valores, o que vai acontecer é que a gente acaba não tendo meio que uma continuidade, a gente vai ter um crescimento exponencial, vai consumir muito mais storage, vai acabar deixando o nosso ambiente com uma degradação de performance, então tem que ter um pouco de cuidado aqui na definição dessas labels. E pode ser comum que vocês escutem esse nome label também como dimensão. Basicamente é a mesma coisa, dependendo da solução que vocês trabalharem, tem essas duas nomenclaturas. E por fim, o tipo, que foi o que eu comentei com vocês. Então, a gente tem alguns tipos de métrica, cada um indicada para o melhor contexto. Então, a gente tem métricas do tipo counter, que é uma métrica que só aumenta. Ideal quando a gente quer fazer algum tipo de contagem de evento, como requisição, por exemplo. A gente tem métricas do tipo gauge, que a gente pode estar utilizando mais de repente para consumo de CPU, memória, algo que sobe e desce, e cada vez que você olha ali pode estar com um valor um pouco diferente. A gente está falando aí também de, a gente também tem os tipos de métrica que são histogramas, que são métricas que medem a distribuição de valores. Então, geralmente a gente utiliza esse cara para a gente conseguir entender como está a latência das nossas requisições. Então, a gente fornece vários intervalos de observação. Então, a gente fornece vários intervalos de observação. Quando a gente vai medir nossos SLOs, por exemplo, de latência, a gente utiliza métricas do tipo histograma. E aí a gente pode falar assim, define intervalos como, por exemplo, 500 milissegundos, 1 segundo, 1 segundo e meio, 2. E a gente vai conseguindo ter um match, ele meio que vai dando um count ali, vamos dizer assim para cada vez que você tiver uma requisição que se enquadra dentro daquele time range então se você tem uma requisição e essa requisição respondeu em 900 milissegundos aí você vai ter um contador ali no no bucket value de 500 milissegundos, aí você vai ter um contador ali no bucket value de 500 milissegundos e no de 1 segundo. E aí o de 1,5, por exemplo, 2, que já seria uma outra entrada, você já não vai ter um incremento desse cara, porque essa resposta foi abaixo desse tempo tá e a gente tem por fim também aqui os as métricas do tipo Samarim que são métricas que a gente também consegue ter uma similaridade Mas em vez de fornecer os valores de bucket, os valores dos tempos de resposta, a gente fornece os percentis, os percentis médios. Então é uma forma um pouquinho diferente de trabalhar. E falando especificamente aqui de uma métrica, como que seria aí tipo um da vida, por exemplo, a gente teria aqui então no comecinho o nosso a gente tem o nome da nossa métrica que seria uma métrica que se chama request total, certo? Essa é uma métrica do tipo count, tá? Aqui não está especificado, mas é uma métrica que a gente está incrementando, né? Cada vez que a gente tem algum tipo de chamada no nosso ambiente. E a gente está fazendo algumas filtragens, passando algumas labels, né? Passando algumas dimensões. passando alguns algumas leigos né passando algumas dimensões então eu quero todas as request que deem net com o status 200 que o pef seja ap ver um resource e que a região seja é esse a estima certo então isso seria um exemplo de uma umaomia aqui, de uma métrica, de uma forma bem simplista. tem o Promithio Server, né, a gente tem o TSDB, que seria a base de dados efetivamente conectado aqui com nodes, né, e discos, tá bom? A gente tem aqui essa parte de retrieval, deixa eu ver se eu consigo marcar com a caneta, então, o TSDB aqui na parte central, a gente tem aqui a camada de retrieval e aí o que eu comentei com vocês né, essa é uma ferramenta que ela utiliza aqui o modelo de pool, então a gente vai ter aqui alguns jobs e alguns exporters, então quando a gente trabalha, por exemplo, com instâncias EC2, a gente vai ter ali Node Exporter, a gente tem exporter para banco de dados, a gente tem exporter para SMTP, então existem alguns tipos de exporter que a gente consegue trabalhar, são caras meio que já estão prontos ali, já coletam uma série de métricas, a gente não precisa se preocupar em fazer nenhum tipo de instrumentação, tá bom? E os jobs aqui a gente pode entender como, por exemplo, micro-serviços, tá? Então, os micro-serviços podem ser os nossos jobs, não é exatamente um job do Kubernetes. E a gente tem, a gente bate nesse cara, faz o scrape das métricas, registra aqui no nosso banco de dados, certo? Para a gente conseguir chegar nesse cara, a gente pode fazer o discovery aqui utilizando o service discovery do Kubernetes. Então, a gente pode ter uma configuração fixa ou a gente pode ter uma configuração dinâmica. Existem algumas formas formas a gente trabalhar tá é uma coisa que é importante tem um componente aqui também não vale tanto se aprofundar aqui que quando a gente trabalha no kubernetes por exemplo a gente tem a possibilidade de utilizar alguns Chrome Jobs né e o que que é um Chrome Job é basicamente um pode que vai nascer vai executar algum tipo de ação e aí assim que ele terminar ele vai morrer e aí vamos analisar friamente assim se esse cara ele não é long running ele não fica lá paradinho ele não consegue expor um path, um endpoint barra metrics pra gente ir lá, consultar buscar essa informação e trazer de volta muitas vezes ele nasce e morre muito rápido ali, não faz tanto sentido, mas pode ser que seja importante a gente gerar métrica desse tipo de atividade, pode ser algum batch, alguma coisa que é importante a gente ter visibilidade, então como que a gente pode fazer? A gente consegue configurar uma SDK do Push Gateway, e aí, basicamente, a gente executa o que tiver para executar dentro desse CronJob, e no final, a gente gera uma métrica e faz push para esse componente aqui do push gateway. E esse componente aqui, ele faz o armazenamento dessa métrica e faz a exposição através de um barra metrics, certo? E aí, a gente tendo agora essa métrica dentro de um path, a gente consegue bater aqui, fazer o pull, buscar essa informação e ter essa informação disponível para consulta. E aí, como eu comentei, a gente tem aqui também a camada de visualização. Então, todos esses dados são expostos também via HTTP e também a gente consegue utilizar aqui o Proncwell para poder fazer as consultas, a gente vai ter o cadastro de um DataSource aqui, e a gente vai conseguir montar os nossos dashboards para a gente poder fazer acompanhamento do nosso ambiente. E para a parte de geração de alerta, a gente tem aqui também uma integração com o Alert Manager, e o Alert Manager fazendo toda a parte de notificação com diferentes componentes. Então, nesse caso aqui, o pager.duty, um e-mail, poderia ser o slack, né? Ou qualquer outra ferramenta aqui que ele dê suporte, tá bom?