Primeiras aulas do curso Monitoramento: Prometheus, Grafana e Alertmanager

Monitoramento: Prometheus, Grafana e Alertmanager

Dashboards com Grafana - Apresentação

Oi, pessoal, tudo bem? Sejam bem-vindos. Esse é o vídeo de apresentação do curso Monitoramento: Prometheus, Grafana e Alertmanager. Eu sou o Kleber Costa, o construtor desse curso.

O conteúdo abordado será sobre a aplicabilidade do curso; quais são os requisitos para você fazer o curso; o que são os quatros sinais de ouro; o que são os métodos RED e USE; qual é o cenário do curso e quais são os benefícios de você fazer esse treinamento.

Vamos para a aplicabilidade. Esse curso se destina para pessoas desenvolvedoras; pessoas de operação de infraestrutura; pessoas de DevOps e pessoas de engenharia de confiabilidade de sites.

Seguindo, vamos entender quais são os requisitos para você fazer esse treinamento sem ter dificuldades. Você precisa ter feito o curso de Observabilidade: coletando métricas de uma aplicação com Prometheus. Por que você precisa ter feito esse curso? Nós estamos dando sequência nas implantações da stack que foi apresentada nesse primeiro curso.

E nesse primeiro curso nós fizemos a instrumentação de uma API Spring para que ela pudesse expor as métricas default da JVM e também expor métricas personalizadas.

Tudo isso foi feito utilizando o Actuator e, posteriormente, utilizando o Micrometer para fazer a interface dessas métricas e levá-las para um formato legível para o Prometheus.

Então, o Prometheus foi levantado nesse curso também e houve uma introdução à linguagem PromQL, trabalhando com sua sintaxe e os tipos de métricas que o Prometheus utiliza, além de lidarmos com questões que estão relacionadas à composição das métricas.

Então o pré-requisito é ter esse conhecimento. Se você já possui esse conhecimento, não é necessário fazer o curso. Porém, se você não entendeu algum dos termos que eu utilizei, faça o curso para você poder seguir nesse curso sem nenhum problema, dando continuidade a todas as tarefas que foram feitas no curso anterior sem ter nenhum débito técnico.

Quais são também os outros pré-requisitos? Caso você não tenha feito o curso, mas entenda tudo que eu falei até agora, você precisa ter o Docker e o Docker Compose instalados na sua máquina. Esses são os pré-requisitos.

Vamos falar um pouco sobre o que será abordado nesse treinamento. Falaremos sobre os Golden Signals, que são os quatro sinais de ouro.

Eles foram definidos pelo Google, e basicamente a premissa é a seguinte: se você só puder olhar para quatro componentes, quatro indicadores da sua aplicação, do seu sistema, foque em latência, tráfego, saturação e erros.

Entendendo que a latência está relacionada ao tempo de resposta da sua aplicação; o tráfego está relacionado ao número de requisições que a sua aplicação recebe; a saturação está relacionada ao uso excedente dos recursos que suportam a sua aplicação; e os erros falam por si só, é a quantidade de erros que você está tendo no decorrer da execução da sua aplicação, tanto em retorno para o usuário como em iteração com a infraestrutura que suporta o seu sistema.

Esses sinais de ouro estão como uma referência no livro SRE do Google. É importantíssimo você entender esse conceito, e ao olhar para um projeto, já planejar a camada de observabilidade e monitoramento de uma forma que esses quatro sinais sejam observados. Isso é de suma importância.

Como acabamos entrando num espectro muito abrangente quando falamos desses sinais, existem métodos que vão facilitar a observabilidade e o monitoramento em cima desses aspectos. Vamos falar dessas metodologias a seguir.

Existe a metodologia USE, que foca na utilização de recursos, na saturação e nos erros. Ela está muito voltada para uma questão de infraestrutura, então basicamente vamos olhar a utilização de disco, como está a questão de IO, como está basicamente a nossa parte de tráfego mesmo, em termos de pacote.

Vamos olhar para a saturação, que é o uso excessivo de recursos. Temos um planejamento para a utilização de recursos.

Quando saímos um pouco disso, temos uma camada de saturação ocorrendo. Existe a saturação e os erros gerados com relação a toda essa comunicação de recursos em decorrência do consumo da sua aplicação pelos usuários e da forma como ela está interagindo com a infraestrutura que a suporta.

O método USE está mais focado nisso, ele não será o nosso foco nesse treinamento, porque é muito abrangente e deveríamos ter um curso específico só para USE, se fôssemos falar sobre ele.

Nós vamos focar no método RED, que foca na taxa de requisições, que é o rate; foca nos erros gerados por essas iterações; e foca também na duração dessas iterações, dessas requisições.

Nós não vamos simplesmente só mergulhar no método RED e focar só nesses três aspectos. É importante você entender que esses três aspectos geram muitos desdobramentos e que nós vamos, sim, olhar para alguma coisa do método USE que complemente a utilização do método RED na nossa sequência desse treinamento, entregando realmente uma camada de observabilidade e monitoramento completa.

O método RED, como se difere do USE, foca mais em iterações que estão relacionadas ao protocolo HTTP. Então o nosso objetivo é mensurar a experiência do usuário final.

Então o nosso foco será esse: entender de uma forma mais próxima possível como está a satisfação de quem consome a nossa API.

Vamos dar uma olhada agora para o cenário do curso para entender qual é a nossa missão daqui para frente.

Diagrama da jornada do usuário. À esquerda, temos um ícone de usuário que se conecta ao ícone da internet. Este último, por sua vez, está ligado ao *proxy* ("proxy-forum-api"), que tem acesso à API ("app-forum-api"), no centro do diagrama. A API está interligada com *cache* ("redis-forum-api"), com *database* ("mysql-forum-api") e com "monit", este na parte inferior do diagrama. "Monit" contém três elementos: "grafana-forum-api", "prometheus-forum-api" e "alertmanager-forum-api". Esses três ligam-se à internet (à direita do diagrama), que tem conexão com o Slack, que chega ao time de suporte. Este último tem uma ligação com "grafana-forum-api".

Nós já falamos sobre a jornada do nosso cliente, que é um cliente sintético basicamente.

É um container que possui um script que consome de uma forma não previsível a nossa API, gerando inclusive algumas interações com erros, o que é interessante em termos da nossa camada de observabilidade, para que ela realmente possa ser colocada à prova.

Nós já temos então um proxy reverso, temos a nossa API, temos um cache e nós temos um banco de dados, cada um em seu respectivo container, todos rodando em uma stack do Docker Compose.

E nós já temos o Prometheus configurado e sendo utilizado. O que nós faremos nesse curso é configurar o Grafana, configurar diversos painéis, tendo um dashboard bem abrangente com o Grafana, subir o Alertmanager e configurar a integração dele com o Slack.

Logicamente, teremos a comunicação do Prometheus também sendo configurada com o Alertmanager. Teremos a camada de visualização gráfica utilizando o Grafana. E teremos o Slack como o endpoint de alertas.

Basicamente, o nosso Alertmanager vai se comunicar com o Slack, passando para um canal específico todos os alertas que forem gerados através de eventos críticos no nosso ambiente.

Então todo incidente que ocorrer vai gerar um alerta que será enviado para o Slack e visualizado por um time de suporte e também pelos desenvolvedores dessa API.

Esse é o cenário do curso, e agora, para finalizar, vamos falar sobre os benefícios que você terá ao concluir esse treinamento em termos de conhecimento.

A prática que nós faremos serve para trabalharmos na redução do tempo médio de detecção de incidentes, o MTTD, que é o Mean Time To Detect.

Quando temos visibilidade sobre métricas e temos essa camada de observabilidade, nós conseguimos detectar algumas nuances dentro do nosso sistema. Então nós conseguimos pegar o início de degradações que, ao se desenvolverem, causam um incidente.

Uma vez que conseguimos ver o início dessa degradação, nós conseguimos já iniciar uma busca pela causa raiz do incidente e resolver o problema antes que uma grande fatia de usuários seja impactada. Então também teremos uma redução do MTTR, que é o tempo médio de reparo, ou Mean Time To Repair.

Nesses dois pontos você vai realmente ganhar esse conhecimento, terá essa agregação de conteúdo para levar para o mundo real.

Além disso, vamos dar uma pincelada sobre um assunto que está dentro do escopo SRE, mas que tem tudo a ver com métricas. Na verdade é um assunto que é derivado de métricas também, que é o acordo de nível de serviço, SLA.

É um documento que faz parte de uma norma ISO e que serve como uma base para que tenhamos um objetivo de nível de serviço. Basicamente, o foco será em manter a qualidade e a estabilidade do nosso serviço acima desse SLA.

Então temos um acordo de nível de serviço, que normalmente gera algum tipo de punição caso ele não seja cumprido. O que nós faremos para manter esse SLA? Nós teremos um objetivo de nível de serviço que está acima desse SLA.

E como entendemos que estamos dentro desse objetivo de nível de serviço? Temos que ter indicadores, e esses indicadores são considerados como o SLI, os nossos indicadores de nível de serviço, que basicamente serão compostos através de métricas.

Dentro desse escopo daremos uma pincelada no Error Budget, que é o orçamento de erro, a margem de erro que nós temos para falhar sem culpa.

Mas nós não vamos mergulhar de cabeça nesse assunto, porque o escopo dele é SRE, e falaremos de uma prática da engenharia em confiabilidade de sites, que é a medição, o trabalho com a observabilidade, com o monitoramento através de métricas. Mas esse não é um curso de SRE.

Além disso, quais são os benefícios que você agregará em nível de conhecimento depois de entender esses conceitos e trabalhar com métricas? Você entenderá o que é a composição de uma baseline comportamental. Afinal de contas, uma série temporal pode te entregar isso.

Você entenderá que as ações de escalabilidade automática e preditiva são derivadas também do uso de métricas. Daí a importância de se trabalhar com métricas.

Também ações reativas e proativas. Ação reativa é quando existe uma reação como um evento disparado com base em algo que foi monitorado, observado. E dentro desse escopo entram os acionamentos, o call, e alertas automatizados.

Lembrando que estamos falando de ação reativa. Um alerta, uma ação automatizada é uma reação. Quando falamos de escalabilidade preditiva, temos ações proativas. Tudo isso é gerado através do uso de métricas.

E o ponto mais forte do curso, que é a medição da experiência do usuário. Se você não tem clientes, não tem usuários satisfeitos com a sua aplicação, ela não serve de nada. Por isso que o nosso objetivo é justamente medir a experiência do usuário o mais próximo possível. Então esse é o nosso objetivo final, e com ele nós vamos rumo à confiabilidade.

Esse é o conteúdo que você verá nesse curso, eu espero que tenha te agradado. E espero poder agregar um pouco de conhecimento no seu caminho. Te vejo na próxima aula.

Dashboards com Grafana - Subindo o Grafana

Vamos dar sequência ao nosso curso. Na aula de hoje vamos subir o Grafana. Esse processo é bem simples, já vai ter um pacote para você na plataforma com todo o conteúdo feito de subida do Grafana.

Vamos fazer algumas configurações após a subida do contêiner e essa você realmente vai precisar executar. Eu aconselho que você utilize o que já está feito para não perder tempo em erros de digitação com relação à sintaxe do YML no Docker Compose.

Mas se você quiser digitar e fazer tudo na mão, é muito legal também, pode seguir que vai dar tudo certo.

O primeiro ponto, estou no meu workdir, estou no path em que está o meu Docker Compose. Vou criar um diretório chamado grafana. Esse diretório, essa pasta vai servir como um volume para o contêiner, e vai ser onde o Grafana armazena suas informações.

Após criar esse diretório, vou aplicar um chmod para mudar as permissões dele para 777, então chmod 777 grafana, acabei digitando sem colocar o Grafana.

Quando fazemos isso, damos esse chmod, nós estamos atribuindo permissões muito abertas, muito inseguras para esse diretório. Porém, estamos falando somente do diretório grafana.

Se eu olhar dentro do diretório grafana, ele está vazio, não tem nada. Se eu olhar para o diretório em si, vocês vão ver que qualquer um pode executar, escrever e ler o diretório.

Por que eu tenho que fazer isso? Quando o contêiner do Grafana subir, ele vai ter um usuário próprio que vai ter que usar esse diretório porque ele vai ser montado como volume dentro do contêiner e, se ele não tiver permissões para entrar nesse diretório e escrever, o contêiner não vai subir.

É apenas isso. Tendo feito isso, vamos abrir o nosso docker.compose.yml. Abrindo-o, o que acontece? Nós temos essa configuração, essa é a configuração atual que você tem.

Você tem o contêiner do prometheus e você tem o contêiner do client que depende do proxy – o prometheus depende do proxy e o client depende do prometheus. Temos essa dependência intercalada de contêineres.

Vamos respeitar isso para o Grafana. Vou pegar a cola que eu já fiz para não gastar tempo digitando tudo isso. Vou pegar esse conteúdo e vou colar entre o conteúdo do prometheus e do client. O bloco de código vai entrar aqui.

Para facilitar, vou colocar a numeração aqui. Esse bloco de código eu coloquei da linha 97 até a linha 108. O que ele diz? Que vamos ter um service, que no caso um contêiner chamado grafana-forum-api; ele vai trabalhar com a imagem corrente mais atual do Grafana; o nome do contêiner vai ser grafana-forum-api; ele vai ter como volume esse diretório grafana que eu criei e apliquei aquela permissão; e ele vai ser montado dentro do contêiner /var/lib/grafana.

O esquema de restart é igual ao dos outros contêineres. Se derrubarmos esse contêiner, ele não sobe sozinho, isso é proposital. Se tivermos uma falha, não vamos entrar em loop e ficar tentando subir o serviço, e também, em casos em que derrubemos um contêiner para forçar uma situação de erro, ele não vai subir no automático.

Aqui está a porta, o Grafana roda na porta 3000 TCP e vai fazer bind de porta para o seu docker host, para a sua máquina. Então, em “localhost:3000”, você vai acessar o Grafana.

Ele está na network: monit, que é a mesma do Prometheus, e ele depende do prometheus-forum-api. Essa é a configuração do Docker Compose para subir essa stack.

A alteração a mais que eu vou fazer é na dependência do client. O client vai subir após o grafana agora. É bom porque dá um tempo para o client enviar as requisições para a API.

O client fala com a API através do proxy, ele envia requisições, só que ele sobe antes que o MySQL esteja devidamente configurado. O que acontece?

No esquema de dependências, se olharmos aqui, você vai ver que temos o redis subindo primeiro; o mysql sobe depois do redis e depende do redis para subir; o app depende do mysql, por sua vez, para subir – aqui está a dependência dele, mysql-forum-api.

O proxy depende do app para subir, da API; e o prometheus depende do proxy. Agora, o grafana depende do prometheus e o client depende do grafana.

Sem essa configuração, do jeito que estava antes, apesar do contêiner do mysql subir, ele ainda não estava com a base configurada e o client já enviava requisições, o que resultava em alguns erros 500 que vocês podem observar nas métricas anteriores que nós verificamos.

Inclusive, você vai conseguir verificar nas suas métricas que isso vai acontecer. Aqui, nós coibimos um pouco dessa falha porque o contêiner do client só vai começar a disparar suas requisições depois que o grafana tiver subido e isso dá um tempo a mais para o MySQL se organizar e estar bem das pernas nessa hora.

Vou salvar o conteúdo e vou rodar o comando docker-compose up -d para ele subir em modo daemon. Ele vai baixar a imagem do Grafana, vai fazer todo esse processo conhecido, você já viu isso sobre contêineres.

Ele vai subir toda a stack naquela ordem de dependências que está no Docker Compose e, por último, ele vai subir o Grafana. É só aguardar um pouco, ele já está na fase de criação, já baixou as layers do Grafana bem rapidamente e agora está subindo a stack.

Para validar isso, vou abrir o browser. Enquanto isso, ele está subindo a stack, está criando o prometheus normalmente e agora está indo para o grafana.

Meu browser vai aparecer a qualquer momento aqui. Pronto, já está subindo o client, o grafana já está certo e agora ele está criando o client. Vamos esperar acabar para podermos acessar a nossa aplicação e verificar como está a questão da observabilidade.

Em primeiro ponto, vou no “localhost/metrics” para que possamos verificar – não subiu, deixa eu dar uma olhada em como está a situação. Vou atualizar, subiu. Deu aquele “Bad Getway” porque estava processando.

Agora está certo, era só o contêiner subindo. Aqui, o erro 500 que eu falei que conseguíamos observá-lo. Por que continuamos observando o erro 500? Estamos usando um volume no Prometheus e o TSDB está sendo armazenado, então temos essa referência histórica.

Se eu procurar por requisições 200, eu tenho o /actuator/prometheus e agora o meu client já começa a atingir o /auth, /topicos e /topicos/{id} está em algum lugar também – não estou enxergando, deixa eu atualizar mais uma vez porque ele também vai bater em /topicos/{id} daqui a pouco.

Já estamos consumindo a aplicação, isso já está sendo refletido nas métricas. Se eu acessar o “localhost:9090”, eu vou cair na interface do Prometheus lá no "Graph”. Aqui, é o Expression Browser, é o navegador de expressão. Vamos agora para o Grafana. O Grafana vai estar em “localhost:3000”, como falei anteriormente.

No primeiro acesso ao Grafana, o login é “admin” e senha “admin”, ele vem default com essa configuração. Autentica e, assim que você autenticar, ele vai pedir para você criar um novo password, uma nova senha. Vou colocar “Alura”.

Vou salvar e pronto, autenticamos no Grafana. Essa é a interface do Grafana. A primeira coisa que vamos fazer agora que o Grafana subiu é configurar um data source.

Isso é rápido, vamos no painel à esquerda, no símbolo da engrenagem, em “Configuration > Data sources”. O que é um data source? É uma origem de dados do Grafana. Ele pode ter diversos data sources, pode ser o Splunk, pode ser o CloudWatch, pode ser o Prometheus etc.

Vamos adicionar no “Data sources”, o primeiro da lista já é o Prometheus. Vou selecioná-lo, o “Name” está “Prometheus”, vou colocar que ele está em “http://prometheus-forum-api:9090” TCP.

Esse é o endereço porque ele vai falar com o contêiner. Se você colocar “localhost”, o Grafana vai achar que ele é o próprio endpoint de métricas do Prometheus, e não é.

Aqui você não mexe em mais nenhuma opção, vem e roda um “Save & test”. Se estiver certo, se você conseguir falar com esse endpoint, ele vai ter um resultado igual ao meu e vai estar configurado.

Está certo aqui. Se eu procurar em “Data sources”, vou ver que já tenho o Prometheus configurado. A outra configuração rápida que vamos fazer é, no painel à esquerda, no símbolo do “+”. Vamos entrar em “Folder”.

Vamos criar uma pasta e toda a nossa configuração de dashboard vai ficar nessa pasta. O nome da pasta vai ser “forum-api”, vou criar a pasta e posso criar o meu dashboard dentro dessa pasta.

Vou em “Create dashboard > Dashboard settings” e no nome do dashboard vou colocar “dash-forum-api”. Não vou colocar descrição, nada disso. Vou dar um “save”, vou salvar com as tags e pronto, está feito.

Essa é a subida do Grafana e a configuração mais básica, que é a seleção de um data source e a criação de uma pasta em que o nosso dash será configurado.

Na próxima aula, vamos trabalhar com as variáveis que vamos utilizar no Grafana. É isso, te vejo na próxima aula.

Dashboards com Grafana - Variáveis e métricas Uptime e Start Time

Vamos dar sequência no nosso curso. Agora que já temos uma pasta e já temos o nosso dash criado, vamos começar a criação dos painéis. Antes disso, vamos iniciar o uso de um recurso bem interessante do Grafana, que são as variáveis.

Por que usar variáveis no Grafana? Vamos imaginar que a sua API foi "deployada" em um ambiente distribuído. Você teria que ter uma métrica para cada instância em que sua API fosse "deployada". Isso não seria nada interessante.

Com uma variável, você pode simplesmente alimentar essa variável com valores que estão relacionados às instâncias que estão suportando a sua API.

Além disso, podemos conter uma métrica que possa atender mais de uma aplicação. Então, quando utilizamos variáveis, nós tornamos as nossas métricas dinâmicas, o que fica mais interessante.

Para configurar a variável, é bem simples. No Grafana, no canto superior direito, vamos em “Dashboard settings > Variables” e vamos adicionar a nossa primeira variável. Tem o nome da variável, vou chamá-la de “application”. O type da variável é como ela é configurada.

Essa variável vai ser configurada como uma “Query”, uma consulta. Vamos fazer uma consulta no endpoint e a configuração dessa variável vai ser herdada de uma configuração já estabelecida lá no endpoint de métricas.

Existem outros tipos também, poderíamos fazer “Customizada”, “Constante” etc. Nesse momento, vamos trabalhar com o tipo “Query”. O label é o rótulo da variável, vai ficar como “application” também.

Aqui, nas opções de query, o data source é o “Prometheus”, vamos buscar lá no endpoint que está configurado nesse data source e a query que vamos fazer é bem simples.

O primeiro ponto para entender é que vamos trabalhar com um label_value. Então, entre parênteses, dizemos qual é a configuração de label que vai ser encontrada no endpoint de métricas e que vai alimentar a nossa variável application.

Nesse caso, é o valor (application). Então fica label_value(application) Quando estávamos mexendo no application properties, nós definimos uma property chamada application que tem como valor app-forum-api. É essa.

Fazendo isso, automaticamente o Grafana já exibe para nós um preview “app-forum-api”. Simples assim, está feito, vou clicar em “Update” no final da página e temos aqui a primeira variável configurada.

À direita da variável, com um símbolo de atenção, fica um aviso de que essa variável não foi referenciada por nenhuma outra variável ou dashboard. É questão de tempo, vamos criar outra variável que vai referenciar essa variável e esse aviso vai sumir. Ele não é um erro, é normal.

Vamos criar uma próxima variável que vai se chamar “instance”. Também vai ser um tipo “Query” e vai ter o label “instance” também. Ela vai usar como “data source” o “Prometheus”.

A query que vamos fazer vai ser label_values() e aqui, dentro dos parênteses de label_values(), vamos pegar uma métrica que é o jvm – deu um erro porque eu tirei o cursor daqui –, vamos trabalhar com essa métrica, (jvm_classes_loaded_classes).

Dentro dessa métrica é que vamos configurar a variável “instance”. Ela trabalha buscando por application. Dentro de application, vamos ter application. Por fim, fora dessa configuração de métrica, nós declaramos o instance, que vai ser alimentado. Então a query fica label_values(jvm_classes_loaded_classes{application="$application"}, instance).

Automaticamente, o preview já traz para nós “app-forum-api:8080”. 8080 é a porta TCP que a aplicação está rodando e ela está rodando na instância de nome “app-forum-api” – lembrando que esse é o nome do contêiner.

Tendo feito isso, vou clicar em “Update”. Já temos agora a variável “application” e a “instance” configuradas. Vou criar mais uma variável. O nome dessa variável vai ser “pool”, ela vai ter como label “pool” também.

O tipo é consulta (Query) e aqui é a métrica que vamos usar para buscar essa variável. A métrica que vamos usar – deixa eu configurar o label_values(hikaricp_connections{instance="$instance", application="$application"}, pool), essa é a métrica, com os labels instance e application.

Ela vai pegar o valor do pool de conexões, esse é o pool da JDBC, é o hikari pool cp. Automaticamente, já aparece aqui “HikariPool-1”. Então, estão configuradas as nossas variáveis, vou dar um “Update”.

Ela não é referenciada por outra variável, é por isso que esse aviso fica feito aqui. Vou salvar o dashboard com essa mudança e vou colocar “variáveis”.

Está salvo, vamos voltar. Já temos aqui “application”, “instance” e “pool” de conexões que vamos utilizar. Agora, vamos ao canto direito superior, clicar em "Add Panel" e adicionar uma nova linha, uma “New row”.

Clicarei em "Row Title". Vou chamar a linha de “API BASIC”. É dentro dessa row que vamos criar os painéis desse capítulo 3. Vamos começar já criando um painel bem simples que, basicamente, vai ser uma métrica que traz para nós o uptime da nossa API.

Na verdade, ela traz o uptime do processo. No painel inferior, em "metrics browser", vou rodar process_uptime_seconds. Se olharmos aqui, ele vai trazer um dado para nós que não parece muito interessante, mas vamos formatar isso.

Eu vou trabalhar com o label application. Quem é o application? Eu posso preencher direto aqui, mas é legal trabalharmos com as nossas variáveis.

Porque, se em algum momento eu tiver outro application que essa métrica possa ser utilizada, a variável vai ter mais de um valor, é só fazer um ajuste nela e conseguimos trabalhar com ela como se ela fosse um vetor, conseguimos pegar diversos índices.

Vai ter o application e o instance. Poderia colocar outro label que é muito importante, que é o job. Esse eu acabei não criando variável, app-forum-api, esse é o job. Fica process_uptime_seconds{application="$application",instance="$instance",job="app-forum-api"}.

Já temos essa métrica. Na legenda, não tem o que colocar, vamos entender. Sob "Panel Title", tenho o painel em que a métrica vai ser exibida para mim. No painel abaixo, eu tenho o data source e as opções de query – inclusive, posso inspecionar a minha query.

Ainda no painel inferior, tenho o browser de métricas que eu coloco a minha métrica e ela vai gerar o painel aqui, a informação que vai ser exibida no painel. Mais abaixo, posso colocar uma legenda, o formato que estou utilizando, e tenho outras opções, como o “Min step”, “Resolution”, enfim, não vamos lidar com essas configurações agora.

O que importa para nós é configurar, do lado direito superior, qual é o tipo de visualização. Temos diversos tipos de visualizações. Para essa, vamos utilizar o “Stat”. Ele já trouxe um número interessante para nós. Vou chamar, no campo para título que apareceu à direita, de “UPTIME” e vou colocar como descrição “API uptime”.

Essa é a descrição. Quando coloco uma descrição, quando alguém colocar o mouse sobre o painel, ele vai ver a descrição. Agora, vamos trabalhar aqui.

Descendo em “Opções de valores”, temos a forma de cálculo do valor que vai ser exibido. Vamos pegar o último valor não nulo, é esse “Last” e o tipo de campo é “Numérico”.

Aqui, temos o modo de coloração. Se eu colocar em “None”, ele vai ficar sem cor; em “Value”, ele colore o valor; e em “Background”, é o fundo. Vou manter em “Value”.

“Graph mode” é essa colação de métrica que fica aqui, eu não vou utilizar, eu quero só o número. Em "Text Size", tamanho de texto, eu não vou mexer para não alterar essa configuração.

Nas opções padrões, nas “Standard options”, temos o tipo de unidade. A unidade para esse valor é “Time” e, nesse caso, uma medida de uptime que eu acho interessante que se parece muito quando você está olhando o uptime, por exemplo, de um sistema operacional, é a duração em hora, minuto e segundo.

Está aqui, a aplicação está de pé há 4 horas, 46 minutos e 15 segundos. Descendo, temos o “Threshold” que não vai ser utilizado, vou colocar essa métrica em cor azul.

Está feito, está aqui o “UPTIME”, vou arrastá-lo para dentro da “API BASIC”. Já temos o primeiro painel com o uptime da aplicação, vamos criar outro.

Esse agora que vamos criar ele vai utilizar a métrica process_start_time_seconds. Vamos pegar o momento que o processo foi "startado". Temos o uptime da nossa API, mas temos o start time de processo que pode mudar se "restartarmos" a nossa aplicação.

Isso não vai influenciar no uptime, são dois valores distintos. Vamos trabalhar com os labels process start_time_seconds{application=”$application”, instance=”$instance”, job=”app-forum-api”}.

Depois, nós configuramos uma variável como job para não termos que ficar fazendo isso todas as vezes, para simplesmente colocarmos job=job para caso tenhamos mais de um job e possamos utilizar a variável como um recurso válido.

Tendo colocado essa métrica, temos um valor que não fica interessante em forma de gráfico. Vamos mudar a nossa visualização também para um formato “Stat”. Temos um Unix timestamp, temos uma numeração que é difícil de entender, vamos ter que fazer uma conversão rápida nela.

Vou por como título desse painel “START TIME”. Na descrição, vou colocar “Hora da inicialização da API”. Agora, no “Cálculo”, vamos usar o último valor; no campo numérico não vamos mudar nada; o que vou fazer é que o “Graph mode” eu vou retirar para ele não ficar com aquela linha.

Na “Unidade”, vamos ter uma diferença. Nós trabalhamos com “Time” na unidade anterior, aqui, vou trabalhar com “Date & Time” e vou colocar “Datetime local”.

Ele apareceu com um formato que tem o mês, dia, ano e hora. Não é muito interessante. Deixa eu procurar outro que não tenha toda essa informação. O "Datetime ISO", nenhum deles está vindo da forma que eu gostaria.

Quando escolhemos “Datetime ISO (No date if today)”, ele não traz para nós o ano, o mês e o dia, mas aqui está com um bug que ele está trazendo, então para vocês é possível que não apareça dessa forma que está aqui.

Vou acabar colocando o default, o “Datetime ISO”. Aqui, em “Threshold”, vou retirar, vou colocar uma cor azul. Ele está aqui “1970-01-19” porque é o Unix timestamp. Vou multiplicar por 1000 (* 1000) e acabo com esse problema.

Inclusive, sumiu tudo. Fazendo essa conversão, está aqui, só não está no fuso adequado. Vou tirar do “ISO”, vou colocar o “Datetime local”, e ainda está incorreto, não era para ele estar trazendo esse horário, tem alguma coisa de questão de horário do meu contêiner que está incorreta.

Não vou me preocupar com isso agora, depois isso vai ser corrigido quando eu subir a stack novamente. Não vou investigar isso agora para não perdermos tempo, o que importa é que o “Start time” está aqui, também vou arrastar para "API BASIC".

Na verdade, está certo o “Start time”, está completamente certo, foi a hora que eu subi a minha API, eu subi às 05:48 da tarde mesmo, não tem nada errado, está correto.

Aqui, já temos dois painéis configurados, estamos trabalhando com variáveis e abrimos caminho para a próxima aula que vamos estar trabalhando com uma métrica de usuários autenticados e erros de autenticação.

Te vejo na próxima aula.

Sobre o curso Monitoramento: Prometheus, Grafana e Alertmanager

O curso Monitoramento: Prometheus, Grafana e Alertmanager possui 222 minutos de vídeos, em um total de 30 atividades. Gostou? Conheça nossos outros cursos de Builds em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Builds acessando integralmente esse e outros cursos, comece hoje!

Plus

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$85
à vista R$1.020
Matricule-se

Pro

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$120
à vista R$1.440
Matricule-se
Conheça os Planos para Empresas

Acesso completo
durante 1 ano

Estude 24h/dia
onde e quando quiser

Novos cursos
todas as semanas