Buscar

Grafana: o que é e como montar painéis de monitoramento

Grafana explicado: o que é, de onde vêm os dados, como subir com Docker e quais painéis de servidor, site e banco valem a pena numa PME.

Gabriel Pedroso9 min de leitura
painel de monitoramento do grafana com gráficos de servidor

O disco do servidor de arquivos encheu numa sexta à tarde, e o sistema de notas fiscais parou junto. Na segunda, alguém da TI mostrou um gráfico: o espaço vinha caindo havia três semanas, numa linha quase reta.

O gráfico estava num painel do Grafana. Só que ninguém olhava para ele, e nenhum alerta tinha sido configurado.

O painel mostrou o problema com clareza. A coleta, o armazenamento do histórico e o aviso para a pessoa certa dependem de outras peças e de alguém que as configure.

O Grafana mostra o que outra ferramenta coletou. Sem uma boa fonte de dados por trás, o painel fica bonito e vazio.

1ColetaPrometheus, Zabbix ou agente no servidor
2Fonte de dadosonde a métrica fica guardada
3Consultao Grafana pergunta à fonte
4Painelgráficos montados sobre a consulta
5Alertaregra avisa quando passa do limite
O painel fica no meio do caminho: a coleta e a fonte de dados vêm antes dele, e o alerta só existe se alguém escrever a regra.

O que é o Grafana e o que ele não faz

A ferramenta é um visualizador. Você aponta para um lugar onde os dados já estão guardados, escreve uma consulta e escolhe como mostrar o resultado: gráfico de linha, medidor, tabela, mapa de calor. Um conjunto desses painéis forma um dashboard.

A documentação chama cada lugar de origem de fonte de dados (data source) e a define como uma conexão com um backend de armazenamento que guarda os seus dados. O painel faz a consulta na hora em que você abre a tela e não mantém uma cópia própria das métricas.

Por isso quem instala pela primeira vez sobe o contêiner, abre a tela e não vê nada: falta a peça que mede CPU, conta requisições ou registra log.

As fontes que já vêm embutidas cobrem quase tudo que uma PME usa:

  • Métricas: Prometheus, InfluxDB, Graphite, além do monitoramento nativo de AWS, Azure e Google Cloud
  • Logs: Loki e Elasticsearch
  • Rastreamento: Tempo, Jaeger e Zipkin
  • Bancos SQL: MySQL, PostgreSQL e Microsoft SQL Server

Outras fontes entram por plugin, e é assim que o Zabbix chega aos painéis.

Prometheus e o painel: quem faz o quê

O Prometheus é um kit de monitoramento e alerta open source que nasceu na SoundCloud. Ele guarda métricas como séries temporais: cada valor com um horário e um conjunto de rótulos, como nome do servidor ou ambiente.

A coleta funciona por puxada. Em intervalos fixos, o Prometheus faz uma requisição HTTP a cada alvo e lê os números expostos ali. Para um servidor Linux, o alvo costuma ser o node exporter, um programa pequeno que publica métricas de hardware e de kernel na porta 9100, todas com o prefixo node_.

A própria documentação do Prometheus cita esse visualizador, ao lado de outros consumidores da API, como opção para mostrar os dados coletados. A divisão de trabalho fica assim:

  • o node exporter mede a máquina;
  • o Prometheus busca os números, guarda o histórico e avalia regras;
  • o painel consulta o Prometheus e desenha.

Esse par aparece em tanto tutorial porque cada lado cobre a falta do outro. O Prometheus tem uma interface de consulta simples, feita para testar expressão. O visualizador não tem banco de métricas. Se os serviços rodam em contêineres Docker, o Prometheus também descobre os alvos sozinho em vários ambientes, e isso evita editar arquivo a cada máquina nova.

Zabbix, Netdata e Uptime Kuma

Muita empresa já tem o Zabbix rodando, com agentes nos servidores e anos de histórico. Para esse caso existe o plugin de Zabbix, que o catálogo oficial lista com a Grafana Labs como desenvolvedora. Ele traz as métricas do Zabbix para os dashboards, mostra os problemas ativos num painel de triggers e sobrepõe eventos nos gráficos como anotações. Você também pode misturar esses dados com outra fonte no mesmo painel.

Ninguém precisa trocar o Zabbix para ganhar painéis melhores. O Zabbix continua coletando e alertando, e o visualizador entra por cima.

Duas ferramentas aparecem na mesma conversa, com papéis diferentes:

  • Netdata: o agente coleta métricas de hosts, contêineres e aplicações, e já traz dashboards gerados sem escrever consulta. A interface tem código fechado, mas é gratuita.
  • Uptime Kuma: monitor self-hosted que testa se um endereço responde, por HTTP(s), TCP, ping ou DNS, e avisa por Telegram, Slack, e-mail e outros canais.

A comparação entre os três papéis principais:

GrafanaZabbixPrometheus
Papelvisualizar e consultarmonitorar a infraestrutura de ponta a pontacoletar e guardar métricas
Coletanão coleta; lê fontes de dadosagentes e checagens própriasbusca por HTTP nos alvos (exporters)
Armazena históriconãosim, em banco própriosim, como série temporal
Alertaregras sobre as consultastriggers e ações nativasregras avaliadas por ele, envio pelo Alertmanager

Alertas: o painel que avisa sozinho

Painel só ajuda quem está olhando, e no caso do disco cheio ninguém estava. Para isso existe o módulo de alertas, que trabalha em cima das mesmas consultas dos painéis. Você escreve uma regra, por exemplo "uso de disco acima de 85% por 10 minutos", e define para onde vai o aviso. A documentação chama esses destinos de pontos de contato e lista, entre outros, e-mail, Slack, Microsoft Teams, Telegram, Discord, PagerDuty e webhook. Uma regra pode combinar consultas de mais de uma fonte.

Duas recomendações de quem já recebeu alerta demais:

  1. Comece com poucos alertas, ligados a algo que exige ação de alguém. Disco quase cheio exige. CPU em 90% por dois minutos quase nunca exige.
  2. Amarre o alerta a uma meta combinada com a área de negócio. É o raciocínio do SLO: você mede o que o usuário sente e define quanto de falha é aceitável.

Licença e versão em nuvem

Em abril de 2021, a Grafana Labs trocou a licença do visualizador, do Loki e do Tempo, de Apache 2.0 para AGPLv3. Plugins, agentes e algumas bibliotecas continuaram sob Apache. Para quem só instala e usa sem alterar o código, a troca tem pouco efeito. A AGPL pesa para quem modifica o código e oferece o resultado como serviço a terceiros.

Quem não quer manter servidor tem a versão hospedada, o Grafana Cloud. A página de preços mostra hoje um plano grátis sem cartão de crédito. Ele inclui 10 mil séries ativas de métricas por mês, 50 GB de logs e 50 GB de traces ingeridos por mês, até 3 usuários ativos por mês na visualização e retenção de 14 dias. Confira quantas séries o seu ambiente gera antes de contar com ele.

Como subir o painel com Docker

A documentação de instalação com Docker recomenda a edição Enterprise como padrão. Ela é gratuita e inclui todos os recursos da edição OSS. A mesma página avisa que, a partir da versão 12.4.0, o repositório da edição OSS no Docker Hub deixa de receber atualização. O comando da documentação é este:

docker run -d -p 3000:3000 --name=grafana grafana/grafana-enterprise

Depois, abra o endereço da máquina na porta 3000. O usuário e a senha iniciais são admin, e a tela pede uma senha nova no primeiro acesso. Troque na hora. Se Docker ainda é novidade, o tutorial de Docker para iniciantes explica imagem, contêiner e volume antes de você chegar aqui.

Para o primeiro painel de servidor, a sequência é esta:

  1. Instale o node exporter no servidor que você quer acompanhar. Ele publica as métricas em http://servidor:9100/metrics.
  2. Configure o Prometheus para buscar esse alvo. O exemplo do guia oficial do node exporter é este:
global:
  scrape_interval: 15s

scrape_configs:
- job_name: node
  static_configs:
  - targets: ['localhost:9100']
  1. Suba o visualizador com o comando acima.
  2. Adicione a fonte de dados. Em Connections, escolha Add new connection, procure Prometheus e informe o endereço, como http://localhost:9090. Se os dois rodam em contêineres separados, localhost aponta para o próprio contêiner do painel. Use o nome do serviço no Docker Compose ou http://host.docker.internal:9090 para um Prometheus na máquina hospedeira.
  3. Clique em salvar e testar. A mensagem de sucesso confirma que a consulta à API do Prometheus funcionou.
  4. Monte quatro painéis: CPU, memória, espaço livre em disco e tráfego de rede.
  5. Crie um alerta para disco, antes de qualquer outro.

Painéis que valem a pena numa PME

Uma empresa pequena não precisa de dezenas de dashboards. Três cobrem a maior parte dos sustos, e cada um depende de uma fonte diferente.

  • Servidor: o painel da lista acima. Ele mostra tendência, e tendência é o que avisa sobre o disco três semanas antes.
  • Site no ar: a disponibilidade vem de uma ferramenta que testa o endereço, como o Uptime Kuma ou uma checagem web do Zabbix. O painel junta esse histórico com o resto.
  • Banco de dados: com a fonte MySQL ou PostgreSQL, você consulta tabelas da aplicação e desenha pedidos por hora ou cadastros por dia. Crie um usuário só de leitura para isso e evite rodar consulta pesada no banco de produção.

Esses três respondem às perguntas que a diretoria faz quando algo para: o servidor aguentou, o site ficou fora e as vendas pararam. Esse é o tipo de visibilidade que sustenta os benefícios de uma boa estrutura de TI, porque transforma reclamação vaga em gráfico com horário.

O que fica

O painel é a parte que todo mundo vê e a mais fácil de montar. Antes dele vêm a escolha do que medir, a coleta e o histórico. Depois dele vem o alerta que chega a alguém.

Quem começa pelo servidor, com node exporter, Prometheus e o contêiner na porta 3000, tem o primeiro painel útil no mesmo dia. E o primeiro alerta que vale configurar é o de disco, porque o espaço livre encolhe devagar e dá semanas de aviso a quem acompanha.

Ferramentas citadas neste post

  • Uptime Kuma: Monitor de disponibilidade self-hosted que testa sites, portas, DNS e contêineres, avisa por Telegram, Slack ou e-mail e publica páginas de status.