Infraestructura de Dashboards

1) Por qué es necesario

Una única imagen del estado: desde el clúster y las redes hasta las bases de datos y las colas.
RCAs rápidos y post-mortem: un conjunto de métricas ↔ registros ↔ pistas.
SLO por servicio y plataforma: control de disponibilidad y latencia.
FinOps transparencia: volumen/costo por servicios, tenant 'am y entornos.
Cumplimiento/seguridad: estado de parches/vulnerabilidades, accesos, anomalías.

Metodologías: Señales de oro (latency, traffic, errors, saturation), RED (Rate, Errors, Duration) para consultas, USE (Utilization, Saturation, Errors) para recursos.

2) Principios de buen dashboard

Validez (Actionable): cada panel responde a «qué hacer a continuación».
Jerarquía: revisión de → dominios → deep dive → raw.
Plantillas/variables: 'cluster', 'namespace', 'service', 'tenant', 'env'.
Unidades únicas: ms para latencia,%, RPS, operaciones/s, bytes.
Temporizador consistente: por defecto 1-6 horas, presets rápidos 5m/15m/24h.
Drilldown: desde el panel a los registros (Loki/ELK) y la pista (Tempo/Jaeger).
Posesión: en el dashboard se indica el propietario, SLO, runbook, contacto en la llamada on-call.

3) Estructura de carpetas y roles

00_Overview - Revisión de nivel superior de la plataforma.
10_Kubernetes - clusters, nodos, workloads, NRA/WPA, contenedores.
20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.
30_Storage_DB - PostgreSQL/MySQL, Redis, Kafka/RabbitMQ, almacenamiento de objetos.
40_CICD_Runner - paipelines, agentes, artefactos, registro.
50_Security_Compliance - vulnerabilidades, parches, RBAC, audit events.
60_FinOps_Cost - costo por servicio/tenant/cluster, eliminación.
99_Runbooks - enlaces a instrucciones y tarjetas SLO.

Roles: Platform-SRE (acceso completo), Service-Owner (sus espacios), Security/Compliance, Finance/FinOps, View-only.

4) Plataforma de dashboard de revisión (Landing)

Objetivo: en ≤30 segundos, ver si todo está bien.

• Plataforma SLO (disponibilidad de API edge): valor objetivo, real, era de errores, burn-rate.
• Latencia p50/p95/p99 en los puntos de entrada principales.
• Errores de 4xx/5xx y endpoints superiores con regresiones.
• Saturación de recursos (CPU, RAM, red, disco) - p95 por clústeres.
• Incidencias/alertas (activas) y lanzamientos recientes.
• Costo/hora (aproximado) y tendencia por semana.

Patrones de variables: 'env', 'region', 'cluster', 'tenant'.

5) Kubernetes: clústeres y worcload

1. Clúster/nodos

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

2. Vorkloady

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

3. Ruta de acceso de red dentro del clúster

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, grilla y DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast: distribución del tráfico por zonas, eventos falleros.
• DNS: latencia resolve, NXDOMAIN/SERVFAIL rate, hit-ratio kash.
• CDN/WAF: bloqueos por reglas, tráfico anormal (bots/scrapers).

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

7) Bases de datos y storage

PostgreSQL/MySQL: qps, latency, lock waits, replication lag, backups/falls.
Redis: hit ratio, evictions, memoria, comandos lentos.
Kafka/RabbitMQ: lag por grupos de consumo, rebalances, mensajes desactivados.
Almacenamiento de objetos: consultas, errores, egresos, 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 y artefactos

Pipeline overview: éxito/tiempo de ejecución, cola de ranners.
Salud deployment: versiones, estado canario/azul-verde, tiempo de calentamiento.
Registros de imágenes: tamaño, último inserto 'y, eliminación.

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

9) Seguridad y cumplimiento

Parches y vulnerabilidades: proporción de nodos/imágenes con CVEs críticos, promedio de «tiempo hasta el parche».
RBAC y secretos: intentos fallidos de acceso, de acceso a secretos.
Auditoría-eventos: entradas/cambios en componentes críticos, drift.
Edición WAF/DLP/PII: bloqueos de reglas, errores de enmascaramiento.

10) Registros y pistas: revisión de extremo a extremo

Resumen de errores de los registros (Loki/ELK): top exceptions, nuevas firmas.
Botón «Ir a los logs con filtros» (LogQL/ES query).
Tracks: top slow spans, porcentaje de consultas sin contexto trace.

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

11) FinOps: costo y eliminación

Valor por servicios/tenantes/clústeres (según facturación/exportadores).
Nodos fríos/calientes: recursos idle, recomendaciones rightsizing (CPU/Nat).
Data egress, L7 solicitudes y su costo.
Dinámica: semana/mes, pronóstico.

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• factor de eficiencia: 'RPS/$' o'SLO-minutos/$ '.

12) SLO, errores y burn-rate

Tarjeta SLO en cada tablero de dominio: objetivo, período, errores (budget).
alertas Burn-rate (dos 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) Estándares de visualización

Tapas de panel: series de tiempo para series, stat para KPI, table para top-N, heatmap para latencia.
Leyendas y unidades: obligatorias; etiquetas acortadas, formato SI.
Zonas de color: verde/amarillo/rojo por SLO/threshold (uniforme).
Descripción del panel: lo que medimos, fuente, enlace runbook, propietario.

14) Plantillas de panel (inicio rápido)

(A) API Overview

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

(B) Node Health

CPU/Memory/Disk/Network - p95 por nodos, lista «caliente».
Pressure, throttling, drops de paquetes.

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.
Estado de respaldo/último éxito.

(D) Kafka Lag

Lag por grupos, velocidad de consumo vs producción, rebalances.

(E) Cost & Util

Costo/hora por servicios, idle%, rightsizing hints, pronóstico.

15) Variables y etiquetas (conjunto recomendado)

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

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

`version` (release/git_sha)

16) Integración con alerting y gestión de incidentes

Reglas en alertas de Alertmanager/Grafana con referencias al dashboard deseado y variables ya enmarcadas.
P1/P2 según criterios SLO, auto-assign on-call.
Anotaciones de lanzamientos/incidentes en gráficos.

17) Calidad de los dashboards: lista de cheques

• Propietario y contacto.
• SLO/thresholds están documentados.
• Las variables funcionan y limitan el alcance de las solicitudes.
• Todos los paneles con unidades y leyenda.
• Drilldown en los registros/pistas.
• Los paneles se colocan en 2-3 «pantalla» (sin deslizamiento por kilómetro).
• Tiempo de respuesta de consultas ≤2 -3 c (caché, downsample).
• No hay paneles «muertos» y métricas depositadas.

18) Rendimiento y costo de los propios dashboards

Downsampling/recording rules para agregaciones pesadas.
Almacenamiento en caché (query-frontend/repetidor) y límites en range/step.
Pruebas de hangar: carga de TSDB/clústeres en consultas de dashboard estándar.
El saneamiento de las etiquetas (baja cardinalidad), el rechazo a los comodines.

19) Plan de implementación (iteración)

1. Semana 1: Landing + reseñas K8s/Edge, SLO básicos, propietarios.
2. Semana 2: DB/Queues, integración de registros y pistas (drilldown), alertas burn-rate.
3. Semana 3: FinOps-dashboards, recomendaciones rightsizing, informe de costos.
4. Semana 4 +: Seguridad/Cumplimiento, autogeneración de tarjetas SLO, pruebas de regresión de dashboards.

20) Mini preguntas frecuentes

¿Cuántos dashboards necesitas?
Mínimo de 1 revisión + una por dominio (K8s, Edge, DB, Queues, CI/CD, Security, Cost). El resto es de madurez.

¿Qué es más importante: métricas o registros?
Métricas para síntomas y SLO, registros para causas. Un conjunto a través de 'trace _ id' y etiquetas consistentes.

¿Cómo no «ahogarse» en los paneles?
Jerarquía, propietarios explícitos, higiene de métricas, rugidos regulares y eliminación de paneles «muertos».

Resultado

Los dashboards de infraestructura no son «gráficos hermosos», sino una herramienta de gestión: control SLO, RCA rápido y FinOps consciente. Estandarizar variables, patrones visuales y propietarios; proporcione el drilldown a los logotipos/las pistas y automatice el burn-rate de la alerta. Esto dará previsibilidad, velocidad de reacción y transparencia del coste a nivel de toda la plataforma.