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.

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.
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:
| Grafana | Zabbix | Prometheus | |
|---|---|---|---|
| Papel | visualizar e consultar | monitorar a infraestrutura de ponta a ponta | coletar e guardar métricas |
| Coleta | não coleta; lê fontes de dados | agentes e checagens próprias | busca por HTTP nos alvos (exporters) |
| Armazena histórico | não | sim, em banco próprio | sim, como série temporal |
| Alerta | regras sobre as consultas | triggers e ações nativas | regras 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:
- 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.
- 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-enterpriseDepois, 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:
- Instale o node exporter no servidor que você quer acompanhar. Ele publica as métricas em
http://servidor:9100/metrics. - 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']- Suba o visualizador com o comando acima.
- 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,localhostaponta para o próprio contêiner do painel. Use o nome do serviço no Docker Compose ouhttp://host.docker.internal:9090para um Prometheus na máquina hospedeira. - Clique em salvar e testar. A mensagem de sucesso confirma que a consulta à API do Prometheus funcionou.
- Monte quatro painéis: CPU, memória, espaço livre em disco e tráfego de rede.
- 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.


