Olá, vamos falar um pouquinho de métricas? Você deve lembrar que métricas te ajudam a detectar ou identificar se o problema está com algum comportamento anômalo, algum comportamento inesperado. Exemplo, taxa de erros nos últimos minutos aumentou, ou existe algum tipo de saturação de processamento, de storage, enfim, de algum recurso computacional. Obviamente que sozinho métricas não vai te ajudar 100%, você precisa também dos logs para, de fato, uma vez detectado o problema, você atuar na causa raiz, identificar a causa raiz. E como que você implementa a captura de métricas da aplicação? Você precisa de um meio para externalizar as métricas de CPU, de memória, enfim, aqueles elementos dos quatro Golden Signals, saturação, throughput, latência, etc. Você precisa de uma forma de capturar esses elementos e externalizar para um serviço de observabilidade. E é importante você fazer de uma forma que você não impacte o funcionamento da aplicação ou traga complexidade desnecessária para a aplicação em tempo que você busca algum tipo de reuso. Para isso, existe uma biblioteca no Java muito conhecida que é o Actuator. que é o actuator. O actuator abstrai um pouco da complexidade que você teria para externalizar essas métricas em paths, ali em endpoints da sua aplicação, e ele já faz esse trabalho para você. O trabalho sujo ali de disponibilizar esses recursos, essas informações, esses dados externamente. Ele tem um uso muito maior, é claro. Por exemplo, ele disponibiliza também rota de health check uma vez, por exemplo, que sua aplicação estiver rodando atrás de um balanceador eventualmente o balanceador vai acessar sua aplicação para consultar se ela está saudável e você precisaria disponibilizar um endpoint uma path http ou tcp para que o balanceador conseguisse fazer carry a cada x tempo, saber se a aplicação está de pé e o actuator disponibiliza disponibiliza isso nessas rotas comuns rota de informação se aplicação quais são os dados da aplicação enfim vamos começar a fazer então aqui um rendição vamos incluir essa biblioteca na aplicação. Vamos acessar aqui o POM XML da aplicação que estamos utilizando. Por enquanto eu vou deixar o Prometheus de lado, vamos incluir depois, eu vou falar mais dele adiante. E no passo 2 precisamos agora externalizar esses pathsciso dizer, oh Spring, além das rotas da minha aplicação que eu tenho aqui, externalize também esses endpoints, esses paths. Então, vamos copiar ou incluir o comentário também. E não vou incluir o Prometheus, vou incluir só até métricas. Vamos incluir no application.yaml. Ou application properties, enfim, que você estiver utilizando. Uma vez feito isso, será disponibilizado, vou demonstrar já já, mas será disponibilizado um path chamado actuator. Como que você acessa, por exemplo, a rota de métricas? Localhost ou endpoint da sua aplicação, a porta, dois pontos né, a porta, barra actuator, barra metrics, barra actuator, barra health, se você quiser acessar a rota de health, check. você consegue sobrescrever esse parâmetro management ponto web base path e você poderia colocar sei lá admin, management, enfim. Eu não vou sobrescrever, vou colocar apenas os paths aqui em include, mas saiba que você pode sobrescrever essa configuração até inclusive deixar na raiz aqui, ou ou seja em vez de ter um actuator barra health actuator barra metric você poderia colocar na raiz feita essa configuração vamos iniciar a aplicação e vou pausar vamos acessar localhost 8080 e acessar barra actuator, que já está aqui no autocomplete do browser. Quando você acessa actuator, você consegue visualizar quais paths estão habilitados na aplicação. Então, actuatorator, como está aqui, Actuator barra Health, opcionalmente algum atributo de path que o endpoint de Health esteja externalizando, exemplo, eu quero detalhes do... Eu quero que o Health externalize, por exemplo, informação do disco, se a saturação do disco está ok, se não existe alguma saturação, se a conexão banco está saudável também. Aqui estou utilizando o Health mais básico mesmo, que é a aplicação saudável ou não, mas a rota de Health permite parâmetros aqui também. A rota de Info e a rota de Métricas que vai ser o assunto aqui deste vídeo. A rota de Métricas também permite algum parâmetro aqui adicional, eu vou falar dele já já. Vamos acessar então agora a rota de métricas. E aqui você tem os nomes das métricas que o actuator está externalizando e disponibilizando para a consulta. Aí você talvez se pergunte, ué, mas onde está o valor dessas métricas? como comentei, no path de métricas você tem o parâmetro que você aceita que ele aceita que é o nome da métrica então, precisamos pegar uma métrica, vamos pegar por exemplo consumo de memória aqui, jvm.memory.usage vamos pegar essa que está aqui embaixo pegar essa rota de memory vamos buscar aqui ops, é interrogação não, barra pronto, então actuator barra metrics barra o nome da métrica que você quer consultar. Aqui ele vai trazer algumas informações gerais, nome, descrição, mas você tem a unidade base daquela métrica e o valor daquela métrica ou potencialmente os valores que retornar. Aqui, por exemplo, eu tenho essa quantidade de bytes de memória que a aplicação está consumindo. E aqui embaixo você tem tags que você pode filtrar para especializar esse valor. Vou mostrar já já para vocês, para você que está assistindo. Vamos voltar aqui, vamos pegar uma outra métrica. Quero pegar HTTP Server Requests. Vamos filtrar essa métrica aqui. Vou colocar barra nome da métrica e observe que eu tenho quatro requisições foram feitas. A unidade base é segundos, mas eu tenho quatro quantidades de requisições feitas e em segundos eu tenho esse tempo aqui de baixo, o tempo total e o máximo, o meu máximo que eu vou aqui. Como eu só fiz requisição de rotas administrativas através do Actuator, eu só vou mostrar essas rotas aqui. Vamos acessar aqui a aplicação e vou aleatoriamente fazer algumas requisições, criar alguns pedidos, consultar, quero também solicitar um aconselhamento aleatoriamente sem me preocupar com o resultado de cada uma dessas rotas. Vamos atualizar aqui e observe que agora já começaram a aparecer algumas outras rodas, alguns outros paths. Foram feitas um total de 20 requisições, tempo total 1 segundo, máximo 0.4 segundos. E aqui embaixo eu consigo especializar através das tags tive aqui por exemplo algumas rotas de delete algumas rotas de post, pouted e get algumas requisições nenhuma deu erro algumas requisições aqui foram feitas para path de orders, a rota administrativa aqui do actuator, orders complete, cancel e etc. E aqui embaixo tem o resultado daquelas requisições. Tem uma rota que retornou 404, 405, não necessariamente as requisições que eu fiz agora, mas algumas rotas retornaram 404, 405, 200 e 201. E agora, como que eu faço aqui para especializar esse número de 20 requisições? Como que eu sei quais requisições, por exemplo, foram resultados de uma requisição de put, por exemplo, ou de get. Vamos filtrar aqui. Como que eu faço esse filtro? Você faz esse filtro via carryString. Você adiciona a interrogação e você vai incluir o parâmetro tag, igual, e aqui você precisa informar chave e valor. Chave, dois pontos, valor. Queremos buscar por método, então method, como está aqui em tag, é a chave que vamos informar. Então, tag method, dois pontos, e o valor que queremos filtrar, vamos filtrar o método put que já está no autocomplete observe que eu tive cinco requisições agora vou voltar aqui para comparar cinco requisições de 20 das quais tiver tivemos algumas requisições que retornaram 405 e algumas que tornaram 200 e agora como que a gente faz para saber quais das requisições do método put retornaram 405, status 405, quais retornaram 200? Ou melhor, quantas retornaram 405, quantas retornaram 200? Você pode incluir e-comercial e fazer um novo filtro. Vamos supor que eu queira filtrar por status 200, tag igual chave status, campo que está aqui, dois pontos o valor, 200. Agora eu tive apenas uma requisição de cinco requisições que retornou 200 sucessos. Então, obviamente, por diferença, se eu filtrar aqui quatro requisições retornaram 405 e isso aqui é muito útil por exemplo quando você quer saber taxa de sucesso da sua aplicação se você tem se você quer saber por exemplo se você tem um SLA por, de disponibilidade, enfim, de sucesso, de bom funcionamento da sua aplicação, aqui seria um bom exemplo. É que aqui o erro 400, ele remete a um parâmetro incorreto que o cliente informou. Mas poderia ser um erro 500, 503, enfim, de timeout, por exemplo, que representaria o mau funcionamento da aplicação. E aqui, no caso, por exemplo, que representaria o mal funcionamento da aplicação. E aqui, no caso, no exemplo, eu tive quatro requisições que retornaram em sucesso e uma com sucesso. Então, saber essa métrica seria muito útil. Uma outra métrica que quero explorar, vamos voltar aqui para a barra metrics. Vamos, ops, esqueci a barra. aqui para barra metrics vamos... Ops, esqueci a barra. Vamos explorar de novo jvm.memoryused que está ali embaixo aqui, eu busquei para facilitar. Barra o nome da métrica e de novo aqui eu tenho esse consumo em bytes de memória. E se eu quiser especializar quantos dessa quantidade de memória está sendo consumido nas áreas heap e non-heap? De novo, interrogação, tag igual area, dois pontos, heap, chave valor. Agora eu sei que existe um sumo em conjunto né uma partição da memória que está sendo consumido especificamente pela área hip e se eu quiser agora pegar quais estão sendo consumidos pela idemizado aqui o tamanho em bytes de memória que está sendo consumido aqui pela g1 e de space então muito útil aqui por exemplo uma terceira métrica que quer explorar a quantidade de conexões supondo que você queira monitorar conexões por exemplo com connection pool que através aqui do Hikari para saber se sua aplicação está consumindo mais, muitas conexões com banco e se você precisaria fazer algum tipo de fine turning. E aí você tem aqui de novo só tem uma tag, então não adiantaria muito fazer filtro. Talvez agora você esteja se perguntando, muito útil essa funcionalidade, essa possibilidade de filtro, mas eu não vou ter acesso direto à aplicação no ambiente produtivo, como que eu vou poder coletar essas métricas da aplicação, de repente se a aplicação roda no ambiente que eu não consigo alcançar, um ambiente Docker, Kubernetes, ou até mesmo que fosse uma máquina virtual, mas tem uma burocracia para acessar, enfim, não vou conseguir ficar fazendo essas carries o tempo todo. Eu preciso de uma forma de pegar essas métricas em lote, todas elas, a cada X tempo, e colocar num serviço que é apropriado para esse tipo de consulta. Um serviço que eu tenho, inclusive, uma tela administrativa, uma user-friendly que eu consiga acessar e interagir, e até, de repente, guardar como histórico, fazer cruzamentos, criar alarmes proativos. Observe que a roda de métricas, nesse caso, ficou um pouquinho limitada para o exemplo que eu trouxe, e eu quero agora trazer o exemplo do Prometheus, explicar como ele pode ajudar a gente a resolver esse problema.