31 KiB
31 KiB
Decision: Capa de observabilidad avanzada (punto 7)
Contexto
Las Capas 1-6 proporcionan toda la telemetría: métricas (VictoriaMetrics), logs (Loki), seguridad (Wazuh), inventario (Netbox), alertas (Alertmanager → Telegram). La Capa 7 trata de qué hacemos con esos datos más allá de reaccionar a alertas: visibilidad por cliente, medición de niveles de servicio, planificación de capacidad, informes y correlación.
No introduce herramientas nuevas. Todo se construye sobre Grafana + VictoriaMetrics + Loki + Netbox ya desplegados.
5 subcapas:
- 7.1 Dashboards por cliente
- 7.2 SLOs/SLIs (niveles de servicio)
- 7.3 Capacity planning (planificación de capacidad)
- 7.4 Status page e informes para clientes
- 7.5 Correlación avanzada (métricas + logs + seguridad)
7.1 Dashboards por cliente
El problema
Hoy para ver el estado de un cliente hay que:
- Entrar en Grafana → buscar métricas del PVE donde están sus VMs
- Entrar en PBS → buscar su datastore y ver si los backups están bien
- Entrar en Wazuh → filtrar eventos por sus hosts
- Entrar en Netbox → buscar qué tiene contratado
Para un técnico de soporte con un ticket abierto, esto son 4 herramientas y 5 minutos antes de saber qué pasa. Multiplicado por 50+ clientes.
DECISION 7.1 (confirmada)
Dashboard Grafana por cliente: una vista única que muestra todo lo relevante de un cliente.
Contenido del dashboard
┌─────────────────────────────────────────────────────────┐
│ CLIENTE: ACME Corp [Último refresh: 2m] │
├─────────────────────────────────────────────────────────┤
│ │
│ 📊 RESUMEN │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ VMs: 5/5 UP │ │ Backups: OK │ │ Storage: 234/600│ │
│ │ │ │ Último: 3h │ │ GB (39%) │ │
│ └─────────────┘ └─────────────┘ └─────────────────┘ │
│ │
│ 🖥️ VMs │
│ ┌──────────┬───────┬─────────┬──────────┬───────────┐ │
│ │ VM │ CPU │ RAM │ Disco │ Estado │ │
│ ├──────────┼───────┼─────────┼──────────┼───────────┤ │
│ │ web-01 │ 12% │ 2.1/4GB │ 18/50GB │ ✅ UP │ │
│ │ db-01 │ 45% │ 7.2/8GB │ 42/100GB │ ✅ UP │ │
│ │ mail-01 │ 3% │ 1.1/2GB │ 8/20GB │ ✅ UP │ │
│ │ app-01 │ 28% │ 3.5/4GB │ 22/50GB │ ✅ UP │ │
│ │ gw-01 │ 1% │ 0.3/1GB │ 2/10GB │ ✅ UP │ │
│ └──────────┴───────┴─────────┴──────────┴───────────┘ │
│ │
│ 💾 BACKUPS (PBS1) │
│ ┌──────────┬──────────────┬────────┬────────────────┐ │
│ │ VM │ Último backup│ Tamaño │ Verify │ │
│ ├──────────┼──────────────┼────────┼────────────────┤ │
│ │ web-01 │ Hoy 03:15 │ 12 GB │ ✅ OK (hace 5d)│ │
│ │ db-01 │ Hoy 03:22 │ 38 GB │ ✅ OK (hace 3d)│ │
│ │ mail-01 │ Hoy 03:18 │ 6 GB │ ✅ OK (hace 7d)│ │
│ │ app-01 │ Hoy 03:20 │ 15 GB │ ✅ OK (hace 2d)│ │
│ │ gw-01 │ Hoy 03:16 │ 1 GB │ ✅ OK (hace 6d)│ │
│ └──────────┴──────────────┴────────┴────────────────┘ │
│ │
│ 📈 STORAGE PBS │
│ [███████████████░░░░░░░░░░░░░░░░░░░░░░░] 39% (234/600) │
│ Tendencia: +2.1 GB/semana → lleno en ~174 semanas │
│ │
│ 🔄 SYNC PBS2 (archivo) │
│ Última sincronización: Hoy 06:00 ✅ │
│ Snapshots en PBS2: 16 (7d + 4w + 5m) │
│ │
│ 🔒 SEGURIDAD (últimas 24h) │
│ Eventos Wazuh: 23 (todos nivel bajo) │
│ Alertas activas: 0 │
│ │
│ 🌐 CONECTIVIDAD │
│ WG Hub: ✅ conectado (handshake hace 47s) │
│ DNS: ✅ resolviendo │
│ Servicios publicados: portal.acme.com ✅ (200 OK) │
│ │
└─────────────────────────────────────────────────────────┘
Implementación técnica
El dashboard usa variables de Grafana para filtrar por cliente:
Variable: $customer
Type: Query
Data source: VictoriaMetrics
Query: label_values(pbs_datastore_size_bytes, datastore)
O bien: API de Netbox (plugin Grafana-Netbox)
Cada panel filtra por el cliente seleccionado:
# VMs del cliente (PVE exporter, filtrado por tags de Netbox)
pve_guest_info{name=~"$customer.*"}
# Storage PBS
pbs_datastore_used_bytes{datastore="$customer"}
pbs_datastore_size_bytes{datastore="$customer"}
# Último backup
pbs_snapshot_timestamp{datastore="$customer"}
# Eventos Wazuh (via Loki)
count_over_time({job="wazuh"} |= "$customer" [24h])
La relación VM↔cliente viene de Netbox (custom field tenant). El plugin grafana-netbox-datasource permite usar Netbox como data source de variables.
Un dashboard, todos los clientes
No se crea un dashboard por cliente. Es un solo dashboard con variable dropdown. El técnico selecciona "ACME" y ve todo de ACME. Selecciona "BETA" y ve todo de BETA.
Para clientes con acceso a Grafana (futuro): Grafana Organizations + RBAC limita cada cliente a ver solo sus datos.
Prioridad
| Paso | Qué | Cuándo |
|---|---|---|
| Construir dashboard base con paneles de VMs y backups | Mes 1 | |
| Añadir storage PBS y tendencia | Mes 1 | |
| Añadir sync PBS2 y verify | Mes 2 | |
| Añadir seguridad (Wazuh) y conectividad (WG) | Mes 2-3 | |
| Integrar variable de Netbox (automático al añadir clientes) | Mes 2 |
7.2 SLOs/SLIs (niveles de servicio medibles)
El problema
Hoy se dice al cliente "tus backups se hacen diariamente" pero no se mide. Si un backup falla 3 días seguidos y nadie mira, no se sabe. Cuando el cliente pregunta "¿cuál ha sido mi uptime este mes?" la respuesta es "no sé, creo que bien".
Sin métricas de nivel de servicio:
- No puedes definir SLAs con datos reales
- No sabes si estás cumpliendo lo que prometes
- No puedes detectar degradación gradual (funciona, pero cada vez peor)
- No tienes datos para justificar precio o mejoras
DECISION 7.2 (confirmada)
Definir SLIs medibles y trackearlos en Grafana. No es necesario implementar un sistema de SLO formal (Google SRE style con error budgets). Es suficiente con métricas que respondan a las preguntas clave del negocio.
SLIs definidos
| SLI | Qué mide | Cómo se calcula | Objetivo |
|---|---|---|---|
| Backup freshness | ¿El backup es reciente? | Tiempo desde último backup exitoso | < 24h |
| Backup success rate | ¿Los backups funcionan? | Backups exitosos / backups programados (30 días) | > 99% |
| Verify pass rate | ¿Los backups son íntegros? | Verificaciones OK / verificaciones ejecutadas | > 99.5% |
| Sync freshness | ¿PBS2 está al día? | Tiempo desde última sincronización exitosa | < 48h |
| Storage headroom | ¿Queda espacio? | % libre del quota del cliente | > 15% |
| VM availability | ¿Las VMs están UP? | Tiempo UP / tiempo total (30 días) | > 99.5% |
| Restore time | ¿Cuánto tarda un restore? | Tiempo medio de restore (medido en ejercicios) | < 2h |
Implementación en Grafana
# SLI: Backup freshness (horas desde último backup)
(time() - pbs_snapshot_timestamp{datastore="$customer"}) / 3600
# SLI: Backup success rate (últimos 30 días)
# Requiere recording rule que cuente éxitos/intentos
pbs_backup_success_total{datastore="$customer"}
/ pbs_backup_attempts_total{datastore="$customer"}
# SLI: VM availability (30 días)
avg_over_time(up{job="pve", instance=~"$customer.*"}[30d])
# SLI: Storage headroom
1 - (pbs_datastore_used_bytes{datastore="$customer"}
/ pbs_datastore_size_bytes{datastore="$customer"})
Panel SLO en Grafana
┌──────────────────────────────────────────────────┐
│ SLOs - ACME Corp - Marzo 2026 │
├──────────────────────────────────────────────────┤
│ │
│ Backup Freshness ████████████████████ 100% │
│ Objetivo: < 24h Actual: 3h ✅ │
│ │
│ Backup Success ████████████████████ 100% │
│ Objetivo: > 99% Actual: 30/30 días ✅ │
│ │
│ Verify Pass Rate ███████████████████░ 99.7% │
│ Objetivo: > 99.5% Actual: 1 warn en 30d ✅ │
│ │
│ Sync PBS2 ████████████████████ 100% │
│ Objetivo: < 48h Actual: 6h ✅ │
│ │
│ Storage Headroom █████████████░░░░░░░ 61% │
│ Objetivo: > 15% Actual: 366 GB libre ✅ │
│ │
│ VM Availability ████████████████████ 99.97% │
│ Objetivo: > 99.5% Actual: 12min down ✅ │
│ │
│ Score global: 6/6 SLOs cumplidos ✅ │
│ │
└──────────────────────────────────────────────────┘
Alertas de SLO
| Alerta | Condición | Severidad |
|---|---|---|
| SLOBackupFreshnessBreach | Backup > 24h para cualquier VM | Critical |
| SLOBackupSuccessLow | Success rate < 99% en ventana 7d | Warning |
| SLOSyncFreshnessBreach | Sync PBS2 > 48h | Critical |
| SLOStorageHeadroomLow | Storage headroom < 15% | Warning |
| SLOVMAvailabilityLow | VM availability < 99.5% en ventana 7d | Warning |
Estas alertas son adicionales a las de infraestructura (Capa 1). Las de Capa 1 dicen "algo falla ahora". Las de SLO dicen "estamos incumpliendo lo que prometimos".
Prioridad
| Paso | Qué | Cuándo |
|---|---|---|
| Definir SLIs de backup (freshness + success) | Mes 1 | |
| Panel SLO básico en Grafana | Mes 2 | |
| Añadir SLIs de sync, verify, storage | Mes 2 | |
| Añadir SLI de VM availability | Mes 3 | |
| Recording rules para cálculos eficientes | Mes 3 |
7.3 Capacity planning (planificación de capacidad)
El problema
- Un cliente llena su quota de PBS un viernes a las 22h → no hay backups del fin de semana → ticket el lunes
- Un pool ZFS llega al 80% → rendimiento degrada → todos los clientes del pool sufren
- Se contratan 10 clientes nuevos y no se sabe si caben en el PBS actual o hay que provisionar otro
Hoy se reacciona cuando algo se llena. Con datos de tendencia se puede anticipar semanas antes.
DECISION 7.3 (confirmada)
Dashboards de tendencia en Grafana con funciones de predicción de VictoriaMetrics.
VictoriaMetrics tiene funciones nativas de predicción que Prometheus no tiene:
Predicción de llenado
# ¿Cuándo se llena el datastore de ACME?
# predict_linear: regresión lineal sobre los últimos 30 días
predict_linear(pbs_datastore_used_bytes{datastore="acme"}[30d], 86400*90)
# ¿Cuántos días quedan para llegar al 100% del quota?
(pbs_datastore_size_bytes{datastore="$customer"} - pbs_datastore_used_bytes{datastore="$customer"})
/ deriv(pbs_datastore_used_bytes{datastore="$customer"}[30d])
/ 86400
Panel de capacity planning
┌──────────────────────────────────────────────────────────┐
│ CAPACITY PLANNING - Todos los clientes │
├──────────────────────────────────────────────────────────┤
│ │
│ ⚠️ ATENCIÓN REQUERIDA (se llenan en < 60 días) │
│ ┌───────────┬──────────┬────────┬───────────────────┐ │
│ │ Cliente │ Usado │ Quota │ Días para llenarse│ │
│ ├───────────┼──────────┼────────┼───────────────────┤ │
│ │ DELTA │ 520/600 │ 87% │ ⚠️ 23 días │ │
│ │ GAMMA │ 380/500 │ 76% │ ⚠️ 45 días │ │
│ └───────────┴──────────┴────────┴───────────────────┘ │
│ │
│ ✅ SIN RIESGO (> 60 días) │
│ ┌───────────┬──────────┬────────┬───────────────────┐ │
│ │ ACME │ 234/600 │ 39% │ 174 días │ │
│ │ BETA │ 120/400 │ 30% │ 280 días │ │
│ │ ... (47 clientes más) │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ 📊 POOL ZFS GLOBAL │
│ pool9: 18.2 TB / 24 TB (76%) │
│ Tendencia: +120 GB/semana → lleno en ~48 semanas │
│ Recomendación: planificar ampliación antes del Q4 │
│ │
│ 📈 CRECIMIENTO POR CLIENTE (últimos 90 días) │
│ DELTA: +8.2 GB/semana (el que más crece) │
│ GAMMA: +5.1 GB/semana │
│ ACME: +2.1 GB/semana │
│ BETA: +1.3 GB/semana │
│ │
└──────────────────────────────────────────────────────────┘
Alertas de capacity
| Alerta | Condición | Severidad |
|---|---|---|
| CapacityDatastoreFull30d | Datastore se llena en < 30 días (predicción) | Warning |
| CapacityDatastoreFull7d | Datastore se llena en < 7 días (predicción) | Critical |
| CapacityPoolFull90d | Pool ZFS se llena en < 90 días (predicción) | Warning |
| CapacityPoolFull30d | Pool ZFS se llena en < 30 días (predicción) | Critical |
Estas alertas permiten actuar semanas antes: contactar al cliente para ampliar quota, provisionar disco adicional, o redistribuir clientes entre pools.
Prioridad
| Paso | Qué | Cuándo |
|---|---|---|
| Panel básico de uso por cliente con tendencia | Mes 1-2 | |
| Predicción de llenado (predict_linear) | Mes 2 | |
| Alertas de capacity (30d, 7d) | Mes 2 | |
| Panel de crecimiento por cliente | Mes 3 |
7.4 Status page e informes para clientes
El problema
- El cliente no tiene visibilidad de su servicio: no sabe si sus backups funcionan, si su storage está bien, cuánto espacio le queda
- Cuando hay una incidencia, el cliente se entera porque algo no funciona, no porque se le haya comunicado
- No hay informes periódicos: "este mes todo fue bien" no tiene datos detrás
DECISION 7.4 (confirmada)
Dos herramientas, dos públicos, dos momentos:
A) Status page per-client (tiempo real)
Cada cliente puede ver el estado actual de sus servicios. Dos opciones:
Opción simple (mes 2): Grafana con permisos
- Grafana Organizations: una org por cliente
- Dashboards de solo lectura con sus métricas
- SSO con Authentik (el cliente entra con su cuenta)
- Ve: VMs (UP/DOWN), backups (último, estado), storage (uso)
- No ve: métricas de otros clientes, infra interna
Opción dedicada (mes 3+): página de diagnóstico custom
Ya documentada en Capa 4.2: Flask/FastAPI ligero, SSO Authentik, detecta IP WG del cliente, muestra checks en tiempo real. Complementa el dashboard Grafana con tests activos (WG conectado, DNS resolviendo, certificado válido, PBS accesible).
B) Informes periódicos (mensuales)
Informe mensual generado automáticamente y enviado al cliente:
┌──────────────────────────────────────────────────┐
│ INFORME MENSUAL - ACME Corp - Marzo 2026 │
├──────────────────────────────────────────────────┤
│ │
│ RESUMEN EJECUTIVO │
│ ✅ Todos los SLOs cumplidos │
│ ✅ 0 incidencias de seguridad │
│ ✅ Storage en niveles saludables │
│ │
│ BACKUPS │
│ - Backups exitosos: 150/150 (100%) │
│ - Último verify: OK (12/03/2026) │
│ - Copia archivo (PBS2): sincronizada │
│ │
│ STORAGE │
│ - Uso actual: 234 GB / 600 GB (39%) │
│ - Crecimiento mes: +8.4 GB │
│ - Estimación llenado: 174 semanas │
│ │
│ DISPONIBILIDAD │
│ - Uptime VMs: 99.97% (12 min downtime) │
│ - Downtime planificado: 10 min (actualización) │
│ - Downtime no planificado: 2 min (reinicio red) │
│ │
│ SEGURIDAD │
│ - Eventos Wazuh: 687 (todos nivel informativo) │
│ - Alertas críticas: 0 │
│ - Vulnerabilidades parcheadas: 3 │
│ │
└──────────────────────────────────────────────────┘
Implementación:
Semaphore (cron mensual, día 1)
→ Playbook que consulta APIs:
- VictoriaMetrics (métricas del mes)
- Loki (eventos del mes)
- PBS API (backups, verify)
→ Genera PDF/HTML con template Jinja2
→ Envía por email o lo deja en Outline/Zammad
No es urgente. Es un diferenciador de servicio que se implementa cuando el stack está maduro.
Prioridad
| Paso | Qué | Cuándo |
|---|---|---|
| Grafana org por cliente (los que lo pidan) | Mes 3 | |
| Página de diagnóstico custom | Mes 3+ | |
| Template de informe mensual | Mes 4+ | |
| Automatización de generación y envío | Mes 4+ |
7.5 Correlación avanzada (métricas + logs + seguridad)
El problema
Las herramientas de las Capas 1-2 generan datos en silos:
- VictoriaMetrics tiene métricas (CPU, disco, red)
- Loki tiene logs (auth, syslog, PBS)
- Wazuh tiene eventos de seguridad (FIM, rootkits, vulnerabilidades)
Para investigar un incidente hay que saltar entre 3 herramientas y correlacionar mentalmente: "el disco subió a las 03:15, a ver qué hay en los logs a las 03:15, a ver si Wazuh detectó algo a las 03:15".
DECISION 7.5 (confirmada)
Grafana como panel de correlación único. Grafana ya soporta múltiples data sources en el mismo dashboard y la misma vista temporal.
Dashboard de investigación
Un dashboard dedicado a investigar incidentes, con todos los data sources sincronizados en el mismo rango temporal:
┌─────────────────────────────────────────────────────────┐
│ INVESTIGACIÓN - Servidor: ns31787946 │
│ Rango temporal: [13/03/2026 02:00 - 04:00] │
├─────────────────────────────────────────────────────────┤
│ │
│ 📊 MÉTRICAS (VictoriaMetrics) │
│ CPU: ─────────────────╱╲───────────── pico 92% 03:12 │
│ IO: ────────────────╱──╲──────────── pico 03:12-03:18│
│ Disco:────────────────────/──────────── subió 2GB 03:15│
│ Red: ─────────────────────────────── normal │
│ │
│ 📝 LOGS (Loki) │
│ 03:10 [syslog] proxmox-backup: starting GC datastore X │
│ 03:12 [syslog] proxmox-backup: GC phase1 marking... │
│ 03:15 [syslog] zfs: pool9: io error on sda │
│ 03:15 [auth] sshd: Accepted key for root from 83.50… │
│ 03:16 [syslog] proxmox-backup: GC failed: IO error │
│ 03:18 [syslog] zfs: pool9: scrub repaired 4K │
│ │
│ 🔒 SEGURIDAD (Wazuh via Loki o API) │
│ 03:15 [level 7] File integrity: /var/log changed │
│ 03:15 [level 3] SSH login from known IP (informativo) │
│ │
│ CORRELACIÓN AUTOMÁTICA: │
│ → GC empezó a las 03:10 │
│ → Error de IO en disco sda a las 03:15 │
│ → GC falló por el error de IO │
│ → ZFS reparó el error (scrub) │
│ → El login SSH fue del técnico investigando │
│ → Conclusión: problema de disco, no seguridad │
│ │
└─────────────────────────────────────────────────────────┘
Cómo funciona en Grafana
Grafana tiene la funcionalidad Explore que permite:
- Seleccionar un rango temporal en una gráfica de métricas
- Ver automáticamente los logs de Loki del mismo período
- Usar annotations para marcar eventos de Wazuh en las gráficas de métricas
- Split view: métricas a la izquierda, logs a la derecha, sincronizados
# Annotations automáticas en dashboards de métricas
# Marca eventos de Wazuh como líneas verticales en las gráficas
annotations:
- name: Wazuh Alerts
datasource: Loki
expr: '{job="wazuh"} |= "level" | json | level >= 10'
tagKeys: rule.description
textFormat: "{{rule.description}}"
Wazuh en Grafana
Dos opciones para tener datos de Wazuh en Grafana:
| Opción | Cómo | Pros | Contras |
|---|---|---|---|
| Wazuh logs → Loki | Alloy recoge logs de Wazuh Manager y los envía a Loki | Consultas LogQL en Grafana, mismo data source que otros logs | Requiere parsear formato Wazuh |
| Wazuh API → Grafana | Plugin Grafana o JSON datasource que consulta API de Wazuh | Datos estructurados, alertas con metadata | Plugin no oficial, mantenimiento |
Recomendación: Wazuh logs → Loki (opción A). Los alertas de Wazuh van al JSON log de /var/ossec/logs/alerts/alerts.json. Alloy los recoge y envía a Loki con labels (level, rule_id, agent_name). Consultas LogQL funcionan directamente.
Prioridad
| Paso | Qué | Cuándo |
|---|---|---|
| Wazuh alerts.json → Alloy → Loki | Mes 1 (junto con despliegue Alloy) | |
| Dashboard de investigación básico (métricas + logs) | Mes 2 | |
| Annotations de Wazuh en dashboards de métricas | Mes 2 | |
| Dashboard de investigación completo con correlación | Mes 3 |
Resumen Capa 7 completa (DECISIONES FINALES)
┌─────────────────────────────────────────────────────┐
│ CAPA 7: OBSERVABILIDAD AVANZADA │
├─────────────────────────────────────────────────────┤
│ │
│ 7.1 DASHBOARDS POR CLIENTE (confirmada) │
│ ┌───────────────────────────────────┐ │
│ │ Un dashboard Grafana con │ │
│ │ variable dropdown por cliente │ │
│ │ - VMs, backups, storage, sync │ │
│ │ - Seguridad, conectividad │ │
│ │ - Variables desde Netbox │ │
│ └───────────────────────────────────┘ │
│ │
│ 7.2 SLOs/SLIs (confirmada) │
│ ┌───────────────────────────────────┐ │
│ │ Métricas de nivel de servicio │ │
│ │ - Backup freshness < 24h │ │
│ │ - Backup success > 99% │ │
│ │ - VM availability > 99.5% │ │
│ │ - Storage headroom > 15% │ │
│ │ - Sync freshness < 48h │ │
│ │ Panel SLO en Grafana │ │
│ └───────────────────────────────────┘ │
│ │
│ 7.3 CAPACITY PLANNING (confirmada) │
│ ┌───────────────────────────────────┐ │
│ │ Predicción de llenado │ │
│ │ - predict_linear (VictoriaM.) │ │
│ │ - Alertas: lleno en <30d, <7d │ │
│ │ - Crecimiento por cliente │ │
│ │ - Panel pool ZFS global │ │
│ └───────────────────────────────────┘ │
│ │
│ 7.4 STATUS PAGE + INFORMES (confirmada) │
│ ┌───────────────────────────────────┐ │
│ │ Grafana org per-client (mes 3) │ │
│ │ Página diagnóstico custom (3+) │ │
│ │ Informes mensuales auto (mes 4+)│ │
│ │ - Template Jinja2 → PDF/HTML │ │
│ │ - Envío automático por email │ │
│ └───────────────────────────────────┘ │
│ │
│ 7.5 CORRELACIÓN AVANZADA (confirmada) │
│ ┌───────────────────────────────────┐ │
│ │ Grafana como panel único de │ │
│ │ investigación │ │
│ │ - Métricas + Logs + Wazuh │ │
│ │ - Mismo rango temporal │ │
│ │ - Annotations de seguridad │ │
│ │ - Wazuh alerts → Loki │ │
│ └───────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────┘
Recursos Capa 7:
- Herramientas nuevas: NINGUNA
- Todo se construye sobre Grafana + VictoriaMetrics +
Loki + Wazuh + Netbox (ya desplegados en Capas 1-2)
- Coste: 0 (dashboards, queries, recording rules)
- Esfuerzo: configuración progresiva meses 1-4