Skip to main content


Introdução ao Prometheus​

Prometheus é uma ferramenta de monitoramento e alerta, de código aberto que coleta e armazena métricas como séries temporais, onde cada dado é associado a um momento específico e a rótulos descritivos. Ele usa um modelo de coleta baseado em pull, consulta os dados com PromQL (sua linguagem própria) e é autônomo, sem precisar de armazenamento distribuído. Prometheus é ideal para monitoramento de sistemas dinâmicos, como arquiteturas de microsserviços, e funciona bem em cenários de alta confiabilidade.



Arquitetura​

O Prometheus é quem vai coletar os dados e o Grafana vai exibir esses dados. Ele funciona com um modelo de coleta pull, onde os dados são extraídos de serviços monitorados.


Já o Grafana se conecta ao Prometheus como uma fonte de dados e transforma essas métricas em dashboards visuais, facilitando a visualização e análise das informações coletadas. Essa integração permite monitorar sistemas de forma eficiente e entender o comportamento dos dados em tempo real.



Métricas​

As Métricas são dados quantitativos que descrevem o comportamento ou o desempenho de um sistema, serviço ou componente ao longo do tempo. Elas são coletadas para monitorar aspectos específicos, como o uso de CPU, memória, tráfego de rede, ou o tempo de resposta de um aplicativo.


Em ferramentas como o Prometheus, as métricas são armazenadas como séries temporais, ou seja, pares de valor e carimbo de data/hora, permitindo que as equipes observem como essas medições evoluem ao longo do tempo e identifiquem tendências ou problemas.


As métricas são categorizadas em quatro tipos principais: Counter, Gauge, Histogram e Summary. Cada tipo de métrica é projetado para capturar e representar diferentes tipos de dados e comportamentos ao longo do tempo. Vejamos cada um deles.



Counter​

Um Counter é uma métrica que só aumenta ou é reinicializada para zero. Ele é usado para contar eventos cumulativos, como o número de requisições HTTP, o número de erros ou a quantidade de bytes enviados. Um contador não pode ser decrementado, exceto se for reinicializado, o que geralmente ocorre durante reinícios do processo de coleta.



Gauge​

Um Gauge é uma métrica que pode aumentar ou diminuir ao longo do tempo. Ele é usado para medir valores que podem flutuar, como a utilização de CPU, a quantidade de memória livre ou o número de usuários conectados em um sistema. Diferente do Counter, o Gauge pode aumentar ou diminuir conforme a métrica varia.



Histogram​

Um Histogram é usado para medir a distribuição de valores ao longo do tempo. Ele divide os dados em intervalos (chamados de buckets) e conta quantos valores caem em cada intervalo.


É útil, por exemplo, para medir a latência de requisições HTTP, porque você pode ver quantas requisições tiveram tempos de resposta em diferentes intervalos (por exemplo, entre 0,1s e 0,5s, entre 0,5s e 1s, etc.).


O Histogram armazena:

  • O número total de observações (quantas vezes a métrica foi registrada).
  • A soma de todos os valores observados (para calcular a média).
  • A contagem de valores dentro de cada intervalo (bucket).


Summary​

Um Summary também mede valores ao longo do tempo, mas a diferença é que ele calcula quantis (ou percentis) dinamicamente. Isso significa que o Summary te dá informações como "50% das requisições tiveram latência abaixo de X segundos" (50º percentil ou mediana) ou "90% das requisições ficaram abaixo de Y segundos" (90º percentil).


O Summary armazena:

  • O número total de observações.
  • A soma de todos os valores observados.
  • Os percentis, como o 50º, 90º e 99º percentil, que mostram a distribuição dos valores.


Diferenças entre Histogram e Summary​

O Histogram conta valores em intervalos predefinidos (buckets) e pode ser agregado entre diferentes servidores ou instâncias. Ele é ideal para medir a distribuição de um valor, como latência ou tamanho de arquivo, e te mostra quantas observações ficaram dentro de cada intervalo.


O Summary calcula percentis diretamente (como mediana ou 90º percentil) com base nos valores coletados, mas não pode ser agregado facilmente entre diferentes servidores. Ele é útil quando você precisa de precisão nos percentis de uma métrica.


Use Histogram para ter uma visão geral da distribuição de valores, dividida em intervalos.


Use Summary quando você precisar de percentis exatos de um valor (por exemplo, "90% das requisições demoraram menos de X segundos").



Time Series Database - TSDB​

O Prometheus utiliza um TSDB (Time Series Database) como banco de dados otimizado para armazenar métricas coletadas como séries temporais, ou seja, dados associados a pontos no tempo. Esse tipo de banco de dados é projetado para lidar eficientemente com grandes volumes de dados que variam ao longo do tempo, como métricas de desempenho de servidores, leituras de sensores IoT, preços de ações e registros de logs.


No Prometheus, cada série temporal é identificada por uma combinação de um nome de métrica, como http_requests_total, e um conjunto de etiquetas (labels), como job="api_server" ou method="GET", que ajudam a diferenciar várias instâncias da mesma métrica. Cada ponto de dados em uma série temporal inclui um timestamp, que indica o momento exato em que a métrica foi registrada, e um valor, que é o dado medido, como o número de requisições ou o uso de CPU.



Retrieval​

O Retrieval é o processo de recuperar dados de métricas armazenadas no banco de séries temporais para responder a consultas. As métricas são armazenadas como séries temporais com timestamps, e o retrieval envolve a leitura desses dados em função das consultas feitas pelos usuários, geralmente por meio da linguagem de consulta PromQL.


O Prometheus realiza o processo de coleta de métricas por meio de jobs ou exporters, dependendo da fonte das métricas.



Job​

Um job no Prometheus refere-se a uma tarefa de coleta de métricas. Os jobs são configurados no arquivo de configuração do Prometheus (prometheus.yml), onde você define quais endpoints o Prometheus deve "scrapar" (coletar) para obter métricas. Cada job representa uma entidade ou serviço do qual o Prometheus busca métricas periodicamente.


Por exemplo, você pode configurar um job para coletar métricas de um servidor web, banco de dados, ou aplicação.


Aqui está um exemplo de configuração de um job no Prometheus:

scrape_configs:
  - job_name: 'api_server'
    static_configs:
      - targets: ['localhost:9100']

Nesse caso, o Prometheus coleta métricas do endpoint localhost:9100 a partir do job chamado api_server.



Exporter​

Um exporter é um componente que coleta e expõe métricas de um sistema ou aplicação que não fornece dados no formato esperado pelo Prometheus. O exporter atua como uma ponte, transformando as métricas específicas do sistema em um formato compreensível pelo Prometheus (geralmente exposto em um endpoint HTTP).


Existem muitos exporters prontos, como o node_exporter (para métricas de sistemas operacionais), blackbox_exporter (para testes de disponibilidade), mysql_exporter (para banco de dados MySQL), entre outros.


Quando o Prometheus realiza um job para coletar dados de um sistema, ele muitas vezes "scrapa" um exporter. Por exemplo, o Node Exporter é um dos mais comuns para coletar métricas de sistemas Linux e outros servidores.



Pushgateway​

O Pushgateway é um componente que permite que métricas sejam enviadas diretamente para o Prometheus, sem a necessidade de seguir o modelo tradicional de scraping, onde o Prometheus coleta periodicamente dados de um endpoint.


Ele é especialmente útil em situações em que jobs de curta duração (como cron jobs) ou processos transitórios não podem ser scrapados diretamente, já que esses processos podem terminar antes que o Prometheus tenha a chance de coletar suas métricas.


Assim que esses processos são executados, eles enviam suas métricas para o Pushgateway, garantindo que as informações sejam armazenadas temporariamente até que o Prometheus possa coletá-las. Em vez de o Prometheus buscar as métricas diretamente de um endpoint como de costume, o Pushgateway recebe as métricas via push, de jobs ou processos efêmeros.


Posteriormente, o Prometheus coleta (scrapa) as métricas do Pushgateway durante sua rotina de coleta normal. Isso possibilita que métricas de processos rápidos ou executados de forma esporádica, como scripts, tarefas de CI/CD ou jobs em batch, ainda sejam capturadas, pois são enviadas para o Pushgateway imediatamente após a conclusão da execução.



HTTP Server​

O Prometheus possui um servidor HTTP integrado, que é essencial para sua operação como ferramenta de monitoramento. Esse servidor é responsável por acessar os alvos (targets) e coletar métricas via requisições HTTP, em um processo chamado scraping. Durante esse processo, o Prometheus faz requisições periódicas (com intervalos configurados) aos endpoints /metrics dos targets, obtendo os dados expostos por eles.


Quando precisamos monitorar métricas que não são diretamente acessíveis via HTTP, como o uso de CPU, memória, ou outras informações do sistema operacional, utilizamos exporters. Os exporters atuam como "intermediários", coletando essas informações do sistema ou serviço monitorado e as transformando em um formato que o Prometheus consegue acessar — ou seja, expõem essas métricas através de um servidor HTTP próprio.


Cada exporter roda seu próprio servidor HTTP independente, que é responsável por expor as métricas em um endpoint HTTP para o HTTP Server do Prometheus. Ele então, faz o scraping desses exporters como se estivesse acessando qualquer outro endpoint HTTP. Dessa forma, cada exporter funciona como um serviço separado e utiliza uma porta dedicada para expor suas métricas, garantindo isolamento e flexibilidade na coleta de dados.


O servidor HTTP do Prometheus também serve como uma API que permite consultas às métricas armazenadas. Isso pode ser feito diretamente via HTTP, utilizando a linguagem de consultas do Prometheus, a PromQL. A API é acessível através de endpoints como /api/v1/query e /api/v1/query_range, que são usados para consultar séries temporais específicas.


A interface web do Prometheus, acessível geralmente no endereço http://<host>:9090, permite aos usuários explorar métricas e realizar consultas diretamente no navegador. A interface é bem simples, mas funcional, facilitando a verificação de dados de maneira rápida.



AlertManager​

O Alertmanager é um componente fundamental, sendo responsável pelo gerenciamento de alertas gerados com base nas regras definidas. Ele recebe os alertas, os processa e executa ações de notificação, como enviar alertas para canais específicos (e-mail, Slack, PagerDuty, etc.), gerenciar a agregação de alertas, e definir a supressão ou silenciamento de notificações.



Modelo Pull e Push​

No contexto de monitoramento, pull e push referem-se a diferentes formas de coletar dados:


  • Pull: O sistema de monitoramento (como o Prometheus) busca ativamente os dados de outros sistemas ou serviços. Ele "puxa" as métricas, consultando periodicamente os alvos configurados.
  • Push: Ao contrário, os sistemas ou serviços enviam suas métricas diretamente para o monitoramento. Isso é útil quando os serviços não podem ser consultados diretamente, como dispositivos em redes protegidas.

Uma ferramenta de monitoramento que pode operar no modelo pull e push é o Nagios. Ele normalmente opera no modelo pull, onde o servidor executa verificações (via scripts ou plugins) para consultar os clientes e obter métricas sobre o status de serviços e dispositivos.


No entanto, o Nagios também pode ser configurado para o modelo push, utilizando agentes (como o NRPE ou NSClient++) nos clientes para enviar ativamente métricas ao servidor. Embora o push seja possível, o Nagios é tradicionalmente mais focado no modelo pull, onde o servidor faz as verificações diretamente.



Instalando o Prometheus​

Podemos baixar o Prometheus pelo link oficial ou podemos subir um container com ele. Em todos os testes irei demonstrar com o uso do Docker.



Primeiro crie o arquivo do compose:


docker-compose.yaml
version: '3'

services:
  prometheus:
    image: prom/prometheus
    volumes:
      - "./prometheus.yml:/etc/prometheus/prometheus.yml"
    networks:
      - localprom
    ports:
      - 9090:9090

networks:
  localprom:
    driver: bridge

Depois crie o arquivo de configuração do Prometheus, vou usar um arquivo de condifugração padrão (o mesmo que já vem no container):


prometheus.yml
# my global config
global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: "prometheus"

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ["localhost:9090"]

Agora, estando no mesmo diretório, basta executar o comando abaixo:

Terminal
sudo docker compose up -d

No docker-compose.yaml podemos adicionar algumas opções interessantes, como:

services:
  prometheus:
    image: prom/prometheus
    command:
      - --config.file=/prometheus.yaml
      - --web.external-url=/prometheus/
      - --storage.tsdb.retention=5y
      - --web.enable-admin-api

    configs:
      - source: prometheus_config
        target: /prometheus.yaml

    logging:
      driver: $LOGGING_DRIVER
      options:
        tag: '{{.Name}}'

    volumes:
      - prometheus-data:/prometheus

prometheus_config:
  prometheus_config:
    content: |
      global:
        scrape_interval: 10s
        scrape_timeout: 5s
      scrape_configs:
        - &scrape_config
          scheme: http
          metrics_path: /metrics
          metric_relabel_configs:
            # drop exporter internal metrics
            - source_labels: [ "__name__" ]
              regex: '(go|python|process)_.+'
              action: drop
          job_name: postgresql_exporter
          static_configs: [{targets: ["postgresql-exporter:9187"]}]
        - <<: *scrape_config
          job_name: redis_exporter
          static_configs: [{targets: ["redis-exporter:9121"]}]
        - <<: *scrape_config
          job_name: rabbitmq_exporter
          static_configs: [{targets: ["rabbitmq:15692"]}]

volumes:
  prometheus-data: {}

A seção command envia argumentos adicionais para o binário principal do Prometheus, já que ele trabalha junto com o ENTRYPOINT. Abaixo segue as opções usadas:

  • --config.file=/prometheus.yaml
    Especifica o arquivo de configuração que o Prometheus usará.

  • --web.external-url=/prometheus/ Define o caminho base para acessar o Prometheus via uma URL externa. Isso é útil em setups com proxies reversos.

  • --storage.tsdb.retention=5y Configura o período de retenção de dados no armazenamento TSDB (Time Series Database) para 5 anos.

  • --web.enable-admin-api Habilita a API administrativa, permitindo operações como a exclusão de séries de dados. Essa configuração pode representar um risco de segurança se exposta diretamente.


A seção configs é usada para configurar arquivos que o container precisa.

  • source: prometheus_config
    Refere-se a uma configuração previamente definida no arquivo docker-compose.yml ou no Docker Swarm.

  • target: /prometheus.yaml
    Define o caminho dentro do container onde essa configuração será montada.


A seção logging define o driver de log para o container.

  • $LOGGING_DRIVER
    É uma variável de ambiente que determina qual driver será usado (por exemplo, json-file, syslog, ou outro).

  • tag: '{{.Name}}'
    Personaliza a tag do log para incluir o nome do container.


A seção volumes monta volumes no container para persistência de dados, o pulo do gato aqui é:

  • prometheus-data:/prometheus
    Cria um volume chamado prometheus-data e o monta no diretório /prometheus dentro do container. Isso garante que os dados de séries temporais coletados pelo Prometheus sejam persistentes, mesmo se o container for reiniciado ou destruído.



Monitorando um container Docker​

Vamos configurar o Prometheus para monitorar container Docker. Isso é feito através do cAdvisor (abreviação de container Advisor), ele analisa e expõe dados de uso de recursos e desempenho de contêineres em execução. Ele fornece métricas no formato Prometheus de forma nativa.


Para fazer isso, vamos precisar:

  1. Criar uma instalação local com vários contêineres usando Docker Compose, incluindo Prometheus, cAdvisor e um servidor Redis.
  2. Examinar métricas dos contêineres Redis, coletadas pelo cAdvisor e capturadas pelo Prometheus.

Primeiro, vamos criar o arquivo de configuração do Prometheus para extrair métricas do cAdvisor.

prometheus.yml
scrape_configs:
- job_name: cadvisor
  scrape_interval: 5s
  static_configs:
  - targets:
    - cadvisor:8080

Agora vamos criar um Docker Compose para iniciar o container com o Prometheus e com o cAdvisor. É importante ter outros containers em execução para podermos observar melhor. No mesmo diretório onde está o arquivo prometheus.yml, crie o docker-compose.yml abaixo:

docker-compose.yml
version: '3.2'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
    - 9090:9090
    command:
    - --config.file=/etc/prometheus/prometheus.yml
    volumes:
    - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    depends_on:
    - cadvisor

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    ports:
    - 8080:8080
    volumes:
    - /:/rootfs:ro
    - /var/run:/var/run:rw
    - /sys:/sys:ro
    - /var/lib/docker/:/var/lib/docker:ro

Essas configurações de volumes no container cadvisor são fundamentais para o funcionamento do cAdvisor. Abaixo podemos consultar o objetivo de montar cada volume:

  • /:/rootfs:ro
    Monta o sistema de arquivos raiz (/) do host no contêiner, em modo somente leitura (ro). Isso permite que o cAdvisor analise a estrutura do sistema de arquivos do host.

  • /var/run:/var/run:rw
    Monta o diretório /var/run do host no contêiner, com permissão de leitura e escrita (rw). Isso é necessário para acessar sockets e processos ativos do host.

  • /sys:/sys:ro
    Monta o sistema de arquivos do kernel (/sys) do host no contêiner, em modo somente leitura (ro). Isso permite que o cAdvisor colete informações do sistema, como uso de CPU, memória e informações de dispositivos.

  • /var/lib/docker/:/var/lib/docker:ro
    Monta o diretório de dados do Docker (/var/lib/docker) do host no contêiner, em modo somente leitura (ro). Isso é necessário para que o cAdvisor identifique e monitore os contêineres gerenciados pelo Docker.


Agora basta rodar o comando docker compose up. Depois dos containers iniciarem com sucesso, podemos acessar a interface web do cAdvisor em http://localhost:8080. É possível explorar estatísticas e gráficos de contêineres Docker específicos em nossa instalação em http://localhost:8080/docker/<container>. Por exemplo:

  • As métricas do Prometheus estão disponíveis em http://localhost:8080/docker/prometheus, e assim por diante.

Como explicado, o cadvisor vai ter um /metrics para que o prometheus possa coletar os dados das variáveis, podemos acessar em http://localhost:8080/metrics.



Explorando métricas no navegador de expressões​

A interface web do cAdvisor é útil para visualizar o que ele monitora, mas não fornece uma interface para explorar métricas detalhadas dos contêineres. Para isso, utilizaremos o navegador de expressões do Prometheus, acessível em http://localhost:9090/graph. Nessa URL, podemos inserir expressões Prometheus na barra de expressão.


Vamos começar explorando a métrica container_start_time_seconds, que registra o horário de início dos contêineres (em segundos). Podemos filtrar por contêineres específicos pelo nome usando a expressão name="<nome_do_container>".


O nome do contêiner corresponde ao parâmetro container_name na configuração do Docker Compose. Por exemplo, a expressão container_start_time_seconds{name="prometheus"} exibe o horário de início do contêiner prometheus.



Configurando o Prometheus para obter dados de aplicações​

Para configurar o Prometheus para obter dados de qualquer site que tenha sido construído para trabalhar com ele, basta informar as configurações abaixo no Prometheus.

scrape_configs:
- job_name: <name>
  scrape_interval: 5s
  static_configs:
  - targets:
    - <IP-or-DNS>:<port>


Monitorando um host Linux​

Vamos configurar o Node Exporter para obter dados do host Linux e expor esses dados para o servidor Prometheus. O Prometheus Node Exporter é um binário estático que pode ser instalado via tarball. Faça o download na página do Prometheus.


Terminal
# Baixe o arquivo node exporter:
sudo wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz

# Extraia o binário:
sudo tar xvfz node_exporter-*.*-amd64.tar.gz

# Entre no diretório recém extraido:
cd node_exporter-*.*-amd64

# Execute o binário:
./node_exporter

Você verá uma saída indicando que o Node Exporter está em execução e expondo métricas na porta 9100:

INFO[0000] Starting node_exporter (version=0.16.0, branch=HEAD, revision=d42bd70f4363dced6b77d8fc311ea57b63387e4f) source="node_exporter.go:82"
INFO[0000] Build context (go=go1.9.6, user=root@a67a9bc13a69, date=20180515-15:53:28) source="node_exporter.go:83"
INFO[0000] Enabled collectors: source="node_exporter.go:90"
INFO[0000] - boottime source="node_exporter.go:97"
...
INFO[0000] Listening on :9100 source="node_exporter.go:111"


Node Exporter em container​

Uma forma de obter o mesmo resultado acima é usando um container docker rodando o Node Exporter para obter os dados do host hospedeiro e passar para o Prometheus, abaixou vou deixar um exemplo:

docker-compose.yml
version: '3.2'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - 9090:9090
    command:
    - --config.file=/etc/prometheus/prometheus.yml
    volumes:
    - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro

  # https://github.com/prometheus/node_exporter#docker
  node-exporter:
    image: quay.io/prometheus/node-exporter
    container_name: node-exporter
    ports:
      - 9100:9100
    command:
      - --path.rootfs=/host
      - --collector.systemd
      # disable metrics about the exporter itself
      - --web.disable-exporter-metrics
      # ignore docker container interfaces
      - --collector.netdev.device-exclude=veth
      # ignore docker container interfaces
      - --collector.netclass.ignored-devices=veth
      - --collector.textfile
      - --collector.textfile.directory=/prometheus-textfile-directory
    restart: unless-stopped
    pid: host
    volumes:
      - /:/host:ro
      - /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket

prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
- job_name: my_linux_with_node_exporter
  static_configs:
  - targets: ['node-exporter:9100']


Métricas do Node Exporter​

Depois de instalado e em execução, podemos verificar se as métricas estão sendo exportadas acessando o endpoint /metrics:


Terminal
curl http://localhost:9100/metrics

Quando o Node Exporter está expondo métricas que o Prometheus pode coletar, incluindo várias métricas do sistema, ela são prefixadas com node_. Para visualizá-las:

Terminal
curl http://localhost:9100/metrics | grep "node_"


Configurando o Prometheus​

Para que o Prometheus acesse as métricas do Node Exporter, é necessário configurá-lo adequadamente. Abaixo temos um exemplo do arquivo de configuração prometheus.yml.

prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
- job_name: my_linux_with_node_exporter
  static_configs:
  - targets: ['localhost:9100']

Agora vamos usar o mesmo docker compose que vimos mais acima.

docker-compose.yaml
version: '3.2'
services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    network_mode: host
    command:
    - --config.file=/etc/prometheus/prometheus.yml
    volumes:
    - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro

Agora é só executar:

Terminal
docker compose up -d

Para acessar, basta ir no navegador e digitar: http://localhost:9090.


Como o node_exporter está sendo executado na minha máquina e o Prometheus é um container na mesma máquina, temos que subir o container do Prometheus com network_mode: host, para que o container tenha acesso ao /metrics.


Para calcular o uso médio de CPU (%) durante um período de 5 minutos, podemos usar a expressão do Prometheus abaixo:

100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m]))*100)

  • node_cpu_seconds_total{mode="idle"}
    Esta métrica rastreia o tempo total (em segundos) que as CPUs do sistema passaram no estado "idle" (inativo). O filtro {mode="idle"} seleciona apenas os dados referentes ao estado inativo.

  • irate(node_cpu_seconds_total{mode="idle"}[5m])
    O irate (instant rate) é usado para calcular a taxa de variação instantânea da métrica nos últimos 5 minutos. Essencialmente, isto mostra a proporção de tempo que as CPUs permaneceram no estado "idle" durante esse período.

  • avg(...) * 100
    Calcula a média da taxa de variação entre todas as CPUs monitoradas no sistema e depois converte a proporção de tempo "idle" para uma porcentagem (* 100).

  • 100 - (...)
    Subtrai a porcentagem de tempo "idle" de 100%, resultando no uso efetivo da CPU (percentual de tempo que a CPU não estava inativa).


Para o tráfego de rede podemos usar:

# Download em Mb:
rate(node_network_receive_bytes_total{device="<interface>"}[1m]) / 1048576

# Download em Gb:
rate(node_network_receive_bytes_total{device="<interface>"}[1m]) / 1073741824

# Upload em Mb:
rate(node_network_transmit_bytes_total{device="<interface>"}[1m]) / 1048576

# Upload em Gb:
rate(node_network_transmit_bytes_total{device="<interface>"}[1m]) / 1073741824

# Converte Upload e Download para Mb:
(rate(node_network_receive_bytes_total{device="enp6s0"}[1m]) + rate(node_network_transmit_bytes_total{device="enp6s0"}[1m])) / 1048576



Fontes​

https://prometheus.io/docs/introduction/overview/

https://prometheus.io/docs/prometheus/latest/getting_started/

https://prometheus.io/docs/guides/cadvisor/

https://prometheus.io/docs/guides/node-exporter/