Dashboards de infraestrutura

1) Por que é necessário

Um único quadro de estado, desde cluster e redes até bancos de dados e filas.
RCA e pós-mortem rápidos, ligando métricas de ↔ ↔ trilhos.
SLO de serviços e plataforma: controle de acessibilidade e latência.
Transparência FinOps: volume/custo por serviço, tenant's e ambientes.
Complaens/segurança: status de patches/vulnerabilidades, acessibilidade, anomalias.

Metodologias: Golden Signals (latency, traffic, errors, saturation), RED (Rate, Errors, Duration) para solicitações, USE (Usilization, Saturation, Errors) para recursos.

2) Princípios do bom dashbord

Actividade (Actionable): Cada painel responde a «o que fazer».
Hierarquia: visão geral de domínios → → deep dive → raw.
Modelos/variáveis: «cluster», «namespace», «service», «tenant», «eng».
Unidades unificadas: ms para latência,%, RPS, operações/s, bytes.
Timpicker de consistência: padrão de 1 a 6 horas, prantos rápidos de 5m/15m/24h.
Drilldown: do painel para o logi (Loki/ELK) e pista (Tempo/Jaeger).
Propriedade: O dashbord indica o dono, SLO, runbook, contato on-call.

3) Estrutura de pastas e papéis

00 _ Overview - visão superior da plataforma.
10 _ Kubernetes - clusters, noodles, workloads, NRA/VPA, contêineres.
20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.
30 _ Armazenamento _ DB - PostgreSQL/MySQL, Redis, Kafka/RabbitMQ, armazenamento de objetos.
40 _ CICD _ Runner - Pipinas, agentes, artefatos, registry.
50 _ Security _ Compliance - vulnerabilidades, patches, RBAC, auditoria de eventos.
60_FinOps_Cost - custo por serviço/tenant/cluster, reciclagem.
99 _ Runbooks - links para instruções e cartões SLO.

Desempenhos: Plataforma-SRE (acesso completo), Service-Owner (seus espaços), Security/Compliance, Finance/FinOps, View-only.

4) Plataforma de dashboard de visão (Landing)

O objetivo é ver se está tudo bem em ≤30 segundos.

• Plataforma SLO (disponibilidade de API edge): destino, real, era de erros, burn-rate.
• Latitude p50/p95/p99 nos principais pontos de entrada.
• Erros 4xx/5xx e top endpoint com regressão.
• Saturação de recursos (CPU, RAM, rede, disco) - p95 em clusters.
• Incidentes/alertas (ativos) e lançamentos recentes.
• Custo/hora (próximo) e tendência por semana.

Modelos de variáveis: «eng», «region», «cluster», «tenant».

5) Kubernetes: clusters e vorcloadas

1. Cluster/nodes

Reciclagem CPU/Memory, pressure (memory/cpu), disco IO, inode.
Subsistemas: kube-api, etcd, controladores; kubelet health.

2. Vorcloadas

RPS/RPM, latency p95, error rate, restarts, throttling, OOMKills.
HPA meta vs métricas reais.

3. Caminho de rede dentro do cluster

eBPF/Netflow: top talkers, drops, retransmits.

4. Eventos K8s

Rate по Warning/FailedScheduling/BackOff.

promql
API (5xx) errors by sum by (service) (rate (http_requests_total{status=~"5"..}[5m]))

Latency p95 histogram_quantile (0. 95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))

Throttling CPU контейнеров sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m]))

6) Edge, grade e DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast: distribuição de tráfego por zonas, eventos failover.
• DNS: latência do resoluto, NXDOMAIN/SERVFAIL rate, hit-ratio cajá.
• CDN/WAF: bloqueios de regras, tráfego anormal (bots/screeps).

promql sum(rate(nginx_http_requests_total[5m])) by (status)

7) Bancos de dados e estorco

PostgreSQL/MySQL: qps, latency, lock wits, replicação de lag, bacapes/falhas.
Redis: hit ratio, evicções, memória, comandos lentos.
Kafka/RabbitMQ: lag por grupo consumer, rebalances, mensagens unacked.
Armazenamento de objeto: consultas, erros, egress, lat p95.

promql
Replication lag in seconds max by (replica) (pg_replication_lag_seconds)

Slow Queries> 1s rate (pg_stat_activity_longqueries_total[5m])

promql
Lag by group max by (topic, group) (kafka_consumergroup_lag)

8) CI/CD e artefatos

Pipeline overview: sucesso/tempo de execução, fila de runners.
Deployment health: versões, canary/blue-green, tempo de aquecimento.
Registro de imagens: tamanho, último push 'e, reciclagem.

promql
Rate (ci_pipeline_success_total[1h] )/rate (ci_pipeline_total[1h]) success rate

9) Segurança e Complacência

Patchi e vulnerabilidade: proporção de nodes/imagens com CVE crítico, tempo médio até o patch.
RBAC e segredos: tentativas incompletas de acesso, acesso a segredos.
Auditoria de eventos: entradas/alterações em componentes críticos, draft.
Edição WAF/DLP/PII: bloqueios de regras, erros de disfarce.

10) Logs e pistas: visão de passagem

Resumo de erros de logs (Loki/ELK): top exceptions, novas assinaturas.
Botão Ir para logs com filtros (LogQL/ES query).
Pistas: top slow spans, percentual de consultas sem contexto trace.

{app="api", level="error"}     = "NullReference"
{app="nginx"}      json      status="5.."      count_over_time([5m])

11) FinOps: custo e reciclagem

Custo por serviços/tenantes/clusters (de acordo com os dados do Billing/Exportadores).
Nódulos quentes/frios: idle recursos, recomendações de rightsizing (CPU/Mem).
Data egress, L7 solicitações e seu custo.
Dinâmica semana/mês, previsão.

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• O fator de eficiência é 'RPS/$' ou 'SLO-minuto/$'.

12) SLO, erros e burn-rate

Cartão SLO em cada domínio dashboard: alvo, período, erros (budget).
Alertas burn-rate (duas velocidades: rápida/lenta).

promql
Bad budget: 5xx as a fraction of sum (rate (http_requests_total{status=~"5"..}[5m])) traffic
/
sum(rate(http_requests_total[5m]))

Burn-rate (fast channel ~ 1h)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

13) Padrões de visualização

Painéis de taips: time-series para filas, stat para KPI, tabela para top-N, heatmap para latência.
Lendas e units: obrigatórios; editoras reduzidas, formato SI.
Áreas de cor: verde/amarelo/vermelho em SLO/threshold (uniforme).
Descrição do painel: o que medimos, origem, link runbook, proprietário.

14) Modelos de painel (início rápido)

(A) API Overview

KPI: `RPS`, `p95`, `5xx%`, `error_budget_remaining`.
Top endpoints by error/latency.
Drilldown no logi 'trace _ id = $ trace'.

(B) Node Health

CPU/Memory/Disk/Network - p95 por nodes, lista «quentes».
Pressure, throttling, drop pacotes.

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.
Estado de Bacap/último sucesso.

(D) Kafka Lag

Por grupos, velocidade de consumo vs produção, rebalances.

(E) Cost & Util

Costa/hour por serviços, idle%, rightsizing hants, previsão.

15) Variáveis e marcas (conjunto recomendado)

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

`component` (edge/db/cache/queue)

`version` (release/git_sha)

16) Integração com alerting e gestão de incidentes

Regras no Alertmanager/Grafan Alerts com referências ao dashboard desejado e variáveis já encobertas.
P1/P2 com critérios SLO, auto-assign para on-call.
Anotações de lançamentos/incidentes em grafias.

17) Qualidade dos dashboards: folha de cheque

• Dono e contato.
• SLO/thresholds foram documentados.
• As variáveis funcionam e limitam o volume de solicitações.
• Todos os painéis com units e lenda.
• Drilldown no logi/pista.
• Os painéis são colocados em 2-3 «ecrãs» (sem scroll por quilômetro).
• O tempo de resposta das solicitações ≤2 -3 c (dinheiro, downsample).
• Não há painéis «mortos» nem métricas deprecatadas.

18) Desempenho e custo dos próprios dashboards

Downsampling/recording rulas para agregações pesadas.
O cachê (query-frontend/repiter) e os limites de range/step.
Hangar de testes: carga de trabalho de TSDB/clusters para solicitações típicas de dashboard.
Saneamento de editoras (baixa cardealidade), renúncia de wildcards.

19) Plano de implementação (iterações)

1. Semana 1: Landing + K8s/Edge revisões, SLO básico, proprietários.
2. Semana 2: DB/Queues, integração de logs e trilhos (drilldown), burn-rate alerts.
3. Semana 3: FinOps-dashboards, recomendações de rightsizing, relatório de custo.
4. Semana 4 +: Segurança/Compliance, geração automática de cartões SLO, testes de regressão de dashboards.

20) Mini-FAQ

Quantos dashboards precisas?
Pelo menos 1 visão + por domínio (K8s, Edge, DB, Queues, CI/CD, Security, Cost). O resto é por maturidade.

O que é mais importante, métricas ou logs?
Métricas para sintomas e SLO, logs para causas. A ligação através de 'trace _ id' e as editoras consistentes.

Como não se afogam nos painéis?
Hierarquia, proprietários explícitos, higiene de métricas, revezamento regular e remoção de painéis «mortos».

Resultado

Os dashboards de infraestrutura não são «gráficos bonitos», mas uma ferramenta de gestão: controle SLO, RCA rápido e FinOps consciente. Normalize variáveis, modelos visuais e proprietários; forneça drilldown a logs/pistas e automatize burn-rate alerts. Isso dará previsibilidade, velocidade de resposta e transparência de custo ao nível de toda a plataforma.