Vamos supor agora que você tem aquele cenário em que a sua aplicação não vai rodar no ambiente containerizado 100% você precisa de uma forma de coletar as métricas da aplicação e e aí como que você faz essa configuração então hoje aqui nesse vídeo nós vamos subir o serviço do Push Gateway e integrá-lo ao Prometheus e a aplicação de fato. Vamos começar primeiro revisitando as nossas configurações no Docker Compose. Vamos incluir o serviço do Push Gateway, basicamente referenciando a imagem prom barra push gateway, nome do container push gateway configuração de reinicialização o serviço expõe a porta 9091 para interação é a mesma porta que o Prometheus vai acessar e a aplicação também para enviar as métricas alguma configuração complementar também como label só um detalhe aqui só um ajuste de indentação, tá? Aqui teria que estar indentado para a direita segundo a configuração do Yemo. Eu já tenho configurado o serviço aqui, deixa eu mostrar, está aqui a configuração do PostGator, imagem, container, a mesma configuração e como comentei, identado aqui corretamente. Isso permite que eu suba o serviço do PostGator, mas eu preciso orientar o Prometheus agora onde ele precisa buscar essas métricas. Então nós vamos voltar aqui para a configuração e aqui eu tenho uma configuração adicional no prometheus.yml. Eu vou incluir mais um scrape que... e aí o job name vai ser... vou chamar de pushGateway e eu tenho que configurar também o intervalo para ele buscar as métricas e o target é o serviço do push gateway. Vou copiar essa configuração aqui, vou incluir no permitheus yaml, só revisar a identificação e pronto. Feita essa configuração será necessário reinicializar o serviço do Prometheus vou fazer um docker compose down para encerrar as aplicações aqui e vou fazer um docker composeapp para ter certeza de que ele vai pegar essa configuração. Agora preciso olhar do lado da aplicação, ajustar a aplicação e instrumentá-la para que ela envie os dados para o serviço do Push Gateway. Do lado da aplicação precisamos incluir essa dependência do do promissos inclusive que é o simple client push gateway e vamos no pão xml da aplicação o livro para manter aqui a coerência da configuração incluir e abaixo do promissometheus do micrômetro feito isso agora eu preciso configurar uma última configuração que é do lado do application.yml além dos endpoints que eu vou externalizar aqui, como eu vou utilizar o PushGateway, eu preciso dizer, configurar o Prometheus sobre onde ele precisa enviar essas métricas, para onde, né? Então a configuração ela fica dentro de Management, item Prometheus, métricas export, PushGateway, tem que ser essa estrutura e a configuração se ele está habilitado a URL para onde ele vai mandar as métricas e algumas configurações adicionais inclusive o job aqui eu estou mudando o nome estou chamando de Store API push vou subir convivendo com a configuração do Prometheus que nós já fizemos, então vai ter métricas chegando através do método pull e métricas chegando através do método push e vamos comparar essas informações no Prometheus. E o push rate é a taxa pela qual a aplicação irá enviar os dados de métricas para o push gateway e aqui eu quero reforçar que essa configuração precisa estar alinhada com a configuração do lado do Prometheus de pooling né de pool dessas métricas do lado do Prometheus em relação ao push gateway então resumindo a a aplicação vai enviar os dados de métricas para o PostGate a cada um segundo e o Prometheus virá buscar no PostGate a cada três. A configuração precisa ser, obviamente, revisitada, é calibrada, mas o ponto é que a configuração não esteja coerente. Vamos supor que eu configurasse para que o Prometheus fosse no PostGate a cada 1 segundo, porém na aplicação eu configurasse a cada 10 segundos essa postagem de métricas no PostGate, e aí não tem coerência, porque o Prometheus virá a cada 1 segundo, sendo que o dado só vai ser atualizado a cada 10. Ou seja, tem um desperdício de recurso computacional para buscar o mesmo dado que não vai mudar tão frequentemente. É importante sempre revisitar essa configuração para que ela tenha coerência. Eu vou copiar a configuração do Prometheus até o nome do job, a configuração anterior já tenho configurada no application yaml, vou acessar aqui a aplicação application yaml, vou quebrar aqui e vou incluir a configuração Prometheus nos bastidores o Prometheus ele utiliza um processo ali de threading mesmo na aplicação e a classe ou objeto que é inicializado ele é uma instância dessa classe Prometheus, PushGate e Manager. Por padrão, essa classe já vai ser inicializada a partir do momento que nós configuramos a dependência no POM XML e incluímos esses parâmetros, essa classe já vai ser inicializada. Mas, supondo que você quisesse sobrescrever a criação dessa classe, de repente você não quer utilizar essas propriedades, ou essas informações serão fornecidas de outra maneira, então você tem a oportunidade de sobrescrever essa configuração utilizando uma classe de configuration do Spring. Aqui por exemplo eu tenho o método, aqui o bin como primary, criando ele como primary. Um método que recebe alguns parâmetros adicionais. profissionais e aqui eu tô criando basicamente com os dados, com os mesmos dados que nós vimos anteriormente que é a URL que será aqui que o a aplicação irá enviar os dados que é do push gateway, a que mais a taxa de publicação desses dados o nome da aplicação e algumas configurações complementares como grouping key, etc. Então, você pode sobrescrever a criação desse bin da seguinte maneira aqui. Com isso feito, precisamos agora subir a aplicação. Então, vamos apenas rodar um clean install aqui, um clean compile, enfim, para garantir que as alterações tenham efeito. E na sequência vamos subir a aplicação. Eu vou pausar o vídeo até para não ficar longo. Eu vou pausar o vídeo até para não ficar longo. O build terminou, agora já inclusive inicializei a aplicação e precisamos agora testar se as métricas estão fluindo da aplicação proativamente para o Push Gateway e depois conferir se elas estão chegando no Prometheus. Vamos começar acessando a rota do PushGator através desse endereço. Observe que já apareceu aqui o job-story-pi-push. Se você tiver acessado antes, apenas dê um refresh aí ele vai aparecer e se eu expandir aqui já consigo visualizar algumas métricas lembrando que se você configurar um push rate muito maior, exemplo, a cada um minuto 30 segundos assim que você acessar a página, pode ser que demore para carregar as métricas, porque ele vai esperar completar um ciclo antes de carregar aqui então, no máximo, algumas poucas métricas, duas três alguma informação vai aparecer aqui nessa nessa listagem mas só depois de completar um ciclo completo que ele de fato vai trazer todas as métricas aqui então ele já está trazendo aqui bate aqui o horário é universal tá é como estamos gmt-3 vai ter essa diferença então conforme eu for atualizando aqui os dados vão atualizando também agora precisamos conferir se as métricas estão aparecendo no Prometheus vamos voltar aqui no serviço do Prometheus vou começar aqui do zero limpar aqui vamos verificar se tem métricas chegando aqui já tem algumas métricas inclusive do pushgator, go, memstat, aqui são métricas de monitoramento do serviço do pushgator e vamos fazer a mesma busca que fizemos vamos pegar http server request count count ops seconds count vou pegar o count e executar observe que eu tenho os dados aqui do Prometheus nas duas métricas batendo muito parecido aqui com o número de requisições, mas observe que a origem dos dados são diferentes. Essa métrica partiu do Store API Push, que é a solução do Push Gateway, e essa mais acima do modelo Pool. É claro que não é uma configuração ideal eu tenho duas configurações dois processos de coleta de métricas para a mesma aplicação aqui apenas para demonstração no momento ideal ali numa situação mais real você vai ter métricas obviamente partindo de diversas fontes porém obviamente monitorando aplicações distintas vou fazer requisições aqui aleatórias através do Insomnia e vou atualizar aqui as métricas e observe que outras métricas apareceram também e de novo você pode filtrar por exemplo remover métricas de um job específico por exemplo quero trazer métricas do job que comece com é que termine com, por exemplo, .mais, push. Tudo que é do push e tudo que é do pull. Então, ele vai trazer aqui também. Lembrando que essa configuração é muito interessante para cenários realmente limitados, em que você não tem como disponibilizar um endpoint da aplicação. A presença da figura do PostGateway, como a documentação oficial descreve, ela tem que ser feita realmente para esses casos, porque existe um risco relacionado a esse tipo de configuração. Então, a resiliência da aplicação do serviço do PostGateway, disponibilidade do serviço, enfim, é mais um componente que você precisa gerenciar e monitorar, inclusive. Então, use de fato quando fizer realmente sentido para um ambiente mais moderno que você tem toda a solução integrada, por exemplo, com Kubernetes, com Docker, com, enfim, ou soluções relacionadas, se você tiver a oportunidade de usar o Prometheus da forma que é recomendável, da forma que é recomendada pela documentação oficial, faça e evite o uso do PushGate. E aí deixe de fato para aquelas aplicações que realmente necessitam.