1. Retomando: dados prontos, falta visualizar
A stack unificada do artigo anterior já coleta métricas das duas mini apps, recebe seus logs e processa seus traces. Mas até aqui, toda consulta foi feita manualmente — uma expressão PromQL de cada vez no Prometheus, uma query LogQL de cada vez no Explore do Grafana. Este artigo constrói um dashboard real, com vários painéis lado a lado, para acompanhar as duas mini apps sem precisar reabrir consultas soltas toda vez.
2. Criando o dashboard e o primeiro painel
No Grafana, em Dashboards → New → New Dashboard → Add visualization, escolhendo o datasource Prometheus, o primeiro painel é a taxa de requisições da mini app Python:
rate(app_requests_total{job="python-app"}[1m])
Configurações relevantes desse painel:
- Visualization: Time series (o padrão, adequado para qualquer métrica ao longo do tempo).
- Title: "Taxa de Requisições — Python App".
- Unit (na aba Standard options): "requests/sec", para o eixo Y ficar legível sem precisar interpretar o número bruto.
3. Painel de latência com histogram_quantile
Um segundo painel, usando o histogram de duração criado no artigo 3 para a mini app PHP:
histogram_quantile(0.50, rate(orders_duration_seconds_bucket{job="php-app"}[5m]))
histogram_quantile(0.95, rate(orders_duration_seconds_bucket{job="php-app"}[5m]))
histogram_quantile(0.99, rate(orders_duration_seconds_bucket{job="php-app"}[5m]))
Adicionando as três expressões como três queries (A, B, C) no mesmo painel de Time series, cada uma vira uma linha — p50, p95 e p99 sobrepostas no mesmo gráfico é o padrão mais comum para visualizar latência, porque a distância entre as três linhas já mostra visualmente o quão "cauda longa" (long tail) a latência está: linhas próximas indicam latência consistente, p99 muito acima do p50 indica que uma fração pequena de requisições está bem mais lenta que a maioria.
4. Painel de taxa de erro (gauge)
Um painel do tipo Gauge (ponteiro/velocímetro) para o tamanho atual da fila de pedidos da mini app PHP — útil por mostrar o valor instantâneo de forma proeminente, sem exigir interpretar um gráfico de linha:
orders_queue_size{job="php-app"}
Na aba Thresholds desse painel, vale configurar faixas de cor — verde até 5, amarelo até 15, vermelho acima disso — para o painel comunicar "tudo bem" ou "atenção" de relance, sem precisar ler o número.
5. Painel de logs com LogQL
Adicionando um novo painel, agora com o datasource Loki, tipo Logs:
{app=~"python-app|php-app"}
A expressão =~ faz correspondência por regex no valor do label — nesse caso, trazendo logs das duas aplicações no mesmo painel, empilhados por tempo. Um segundo painel de logs, filtrado só para eventos de erro (útil para manter visível mesmo quando o volume geral de log é alto):
{app=~"python-app|php-app", level="error"}
6. Painel de volume de logs ao longo do tempo
O LogQL também permite agregações numéricas sobre logs, não só listagem de linhas — útil para correlacionar visualmente um pico de volume de log de erro com um painel de métricas ao lado:
sum(count_over_time({app=~"python-app|php-app", level="error"}[1m]))
Esse painel, como Time series (mesmo vindo de uma query LogQL), mostra quantas linhas de log de erro por minuto cada aplicação produziu — o equivalente, em logs, ao que rate() faz para um counter do Prometheus.
7. Organizando o dashboard
Com os cinco painéis criados — taxa de requisições, latência p50/p95/p99, tamanho da fila, logs recentes e volume de erro — a organização recomendada segue uma convenção comum em dashboards de observabilidade: do geral para o específico, de cima para baixo.
┌─────────────────────────┬─────────────────────────┐
│ Taxa de Requisições │ Latência p50/p95/p99 │
├─────────────────────────┼─────────────────────────┤
│ Tamanho da Fila (gauge) │ Volume de Erros / min │
├─────────────────────────┴─────────────────────────┤
│ Logs Recentes (filtrados por app e nível) │
└─────────────────────────────────────────────────────┘
Painéis de métrica agregada (o "o quê") ficam no topo, e o painel de logs detalhado (o "por quê") fica embaixo — assim, o fluxo natural de investigação (ver o problema no topo, entender a causa embaixo) segue a ordem visual do próprio dashboard. Salvando o dashboard com um nome como "Mini Apps — Visão Geral" e uma tag observabilidade, ele fica disponível na lista principal de dashboards do Grafana.
8. Variável de template para alternar entre apps
Para não duplicar o dashboard inteiro entre Python e PHP, o Grafana permite criar uma variável que filtra os painéis dinamicamente. Em Dashboard settings → Variables → Add variable:
-
Name:
app - Type: Query
- Data source: Prometheus
-
Query:
label_values(app_requests_total, job)(ou, mais genérico,label_values(job)para listar todos os jobs configurados noprometheus.yml)
Com a variável criada, cada query dos painéis passa a usar $app no lugar do valor fixo:
rate(app_requests_total{job="$app"}[1m])
Um seletor aparece no topo do dashboard, permitindo trocar entre python-app e php-app sem editar nenhum painel manualmente — o mesmo dashboard serve para as duas mini apps, e para qualquer aplicação nova que a stack venha a ganhar no futuro.
9. Conclusão e próximos passos
Construímos um dashboard real combinando métricas via PromQL (taxa de requisições, latência por percentil, tamanho de fila) e logs via LogQL (eventos recentes, volume de erro), organizados do geral para o específico e parametrizados com uma variável de template para reutilização entre aplicações. No último artigo desta série, esse dashboard vira ferramenta de investigação de verdade: vamos simular um incidente real nas mini apps e usar métricas, logs e traces juntos para encontrar a causa raiz.
Imagem de capa: Logo oficial do Prometheus — repositório prometheus/prometheus, licença Apache 2.0 (convertido para PNG via wsrv.nl)
Referências:
