Dashboards

Principios de diseño, métricas clave, dashboards operacionales vs de negocio y cómo construir vistas útiles.

¿Para qué sirven los dashboards?

Un dashboard es una vista consolidada de métricas que permite entender el estado de un sistema de un vistazo. Pero no todos los dashboards son iguales — un dashboard mal diseñado puede ser tan inútil como no tener ninguno.

El objetivo de un buen dashboard no es mostrar la mayor cantidad de datos posible, sino responder preguntas específicas de forma rápida y clara.

Principios de diseño

1. Definí la audiencia

Antes de crear un dashboard, preguntate: ¿quién lo va a usar y para qué?

• Ingeniero on-call: Necesita saber rápidamente si hay un problema y dónde está.
• Tech lead: Necesita entender tendencias de rendimiento y capacidad.
• Product manager: Necesita métricas de negocio y adopción.
• Ejecutivo: Necesita indicadores de alto nivel sobre salud y crecimiento.

Cada audiencia necesita un dashboard diferente.

2. Jerarquía visual

Organizá la información de más importante a menos importante, de arriba a abajo y de izquierda a derecha:

• Fila superior: Indicadores de estado general (semáforos, números grandes).
• Filas intermedias: Gráficos de tendencia de las métricas principales.
• Filas inferiores: Detalle y métricas secundarias.

3. Menos es más

Un dashboard con 30 paneles no es más útil que uno con 8 paneles bien elegidos. Cada panel debe justificar su presencia respondiendo una pregunta concreta.

Regla práctica: si un panel no cambió la decisión de nadie en los últimos 30 días, probablemente no necesita estar ahí.

4. Contexto temporal

Siempre incluí:

• Selector de rango temporal: Permitir cambiar entre últimas 6 horas, 24 horas, 7 días.
• Comparación temporal: Mostrar la misma métrica hace una semana para detectar anomalías.
• Marcadores de deploys: Líneas verticales que indican cuándo se hizo un deploy.

5. Colores con significado

Usá colores de forma consistente y con propósito:

• Verde: Todo normal, dentro de SLO.
• Amarillo/Naranja: Degradación, acercándose al umbral.
• Rojo: Problema activo, fuera de SLO.

Evitá usar muchos colores decorativos — distraen y diluyen las señales importantes.

Tipos de dashboards

Dashboard operacional

Diseñado para el equipo de ingeniería durante operaciones diarias y respuesta a incidentes.

Contenido típico:

• Métricas RED por servicio (rate, errors, duration).
• Estado de dependencias (bases de datos, colas, servicios externos).
• Recursos de infraestructura (CPU, memoria, disco).
• Alertas activas.
• Deploys recientes.

Características:

• Actualización en tiempo real (refresh cada 10-30 segundos).
• Foco en las últimas horas.
• Umbrales visibles con colores de semáforo.

Dashboard de servicio

Un dashboard dedicado a un microservicio específico. Cada equipo debería tener uno para cada servicio que mantiene.

Contenido típico:

• Métricas RED del servicio.
• Latencia por endpoint (p50, p95, p99).
• Tasa de errores por tipo de error.
• Métricas de dependencias downstream.
• Uso de recursos (CPU, memoria, conexiones a DB).
• Cola de mensajes (si aplica): tamaño, lag, throughput.

Dashboard de negocio

Diseñado para stakeholders no técnicos que necesitan entender el impacto en el negocio.

Contenido típico:

• Órdenes creadas por hora/día.
• Ingresos procesados.
• Tasa de conversión del checkout.
• Usuarios activos.
• Tiempo promedio de completar una operación clave.

Características:

• Actualización menos frecuente (cada 5-15 minutos).
• Foco en tendencias diarias/semanales.
• Lenguaje de negocio, no técnico.

Dashboard de SLO

Muestra el cumplimiento de los Service Level Objectives del equipo.

Contenido típico:

• SLO actual vs objetivo (ej: 99.92% vs 99.9%).
• Error budget restante (en minutos o porcentaje).
• Tendencia del error budget en los últimos 30 días.
• Incidentes que consumieron error budget.

Este dashboard es clave para tomar decisiones sobre priorización: si el error budget se está agotando, el equipo debería priorizar estabilidad sobre features.

Métricas clave por tipo de componente

Para un API Gateway

• Requests por segundo (total y por ruta).
• Latencia por ruta (p50, p95, p99).
• Tasa de errores 4xx y 5xx.
• Rate limiting activado.
• Conexiones activas.

Para una base de datos

• Queries por segundo.
• Latencia de queries (p50, p95, p99).
• Conexiones activas vs pool máximo.
• Replicación lag (si aplica).
• Uso de disco y crecimiento.

Para una cola de mensajes

• Mensajes publicados por segundo.
• Mensajes consumidos por segundo.
• Consumer lag (mensajes pendientes).
• Tamaño de la cola.
• Errores de procesamiento (dead letter queue).

Para un servicio HTTP

• Métricas RED (rate, errors, duration).
• Distribución de status codes.
• Latencia por endpoint.
• Errores por tipo (timeout, 500, 503).
• Saturación (requests en cola, threads activos).

Anti-patrones

Dashboard “wall of text”

Demasiados paneles pequeños con números que nadie puede leer. Priorizá pocos paneles grandes y claros.

Dashboard “vanity metrics”

Métricas que se ven bien pero no son accionables: “total de requests desde el inicio de los tiempos”. Mostrá tasas y tendencias, no acumulados.

Dashboard sin contexto

Gráficos sin umbrales, sin comparación temporal, sin indicación de qué es “normal”. Sin contexto, un gráfico es solo una línea bonita.

Dashboard desactualizado

Un dashboard que no refleja la arquitectura actual es peor que no tener dashboard — genera falsa confianza. Mantené los dashboards actualizados como parte del ciclo de desarrollo.

Un solo dashboard para todo

Intentar meter métricas operacionales, de negocio y de infraestructura en un solo dashboard. Cada audiencia necesita su propia vista.

Herramientas

Grafana

La herramienta más popular para dashboards de observabilidad:

• Soporta múltiples data sources (Prometheus, Elasticsearch, CloudWatch, etc.).
• Templates y variables para dashboards dinámicos.
• Alertas integradas.
• Comunidad activa con dashboards compartidos.

Datadog

Plataforma SaaS que integra métricas, logs, trazas y dashboards:

• Dashboards out-of-the-box para tecnologías populares.
• Correlación automática entre señales.
• Notebooks para investigación de incidentes.

Kibana

Parte del stack ELK, especializado en visualización de logs:

• Dashboards basados en datos de Elasticsearch.
• Ideal para análisis de logs y búsqueda.
• Lens para crear visualizaciones sin código.

Buenas prácticas

Dashboard como código

Definí dashboards en código (JSON, Terraform, Jsonnet) y versionálos en Git:

• Reproducibilidad: podés recrear dashboards en cualquier ambiente.
• Revisión: cambios en dashboards pasan por code review.
• Historial: sabés quién cambió qué y cuándo.

Onboarding con dashboards

Cuando un nuevo miembro se une al equipo, los dashboards deberían ser parte del onboarding:

• “Este es el dashboard principal del servicio X.”
• “Estos son los indicadores que miramos primero cuando hay un incidente.”
• “Este es el dashboard de SLO del equipo.”

Iteración continua

Los dashboards no son estáticos. Después de cada incidente, preguntate:

• ¿El dashboard me ayudó a diagnosticar el problema?
• ¿Faltó alguna métrica que hubiera sido útil?
• ¿Había paneles que no aportan valor?

Resumen

Los dashboards son la interfaz humana de la observabilidad. Un buen dashboard responde preguntas específicas para una audiencia definida, usa jerarquía visual para priorizar información y se mantiene actualizado con la arquitectura. Combinando dashboards operacionales, de servicio, de negocio y de SLO, el equipo tiene visibilidad completa sobre la salud del sistema desde múltiples perspectivas.