Saltar a contenido

09 silencio

Principio

SmallCountry solo interrumpe la atención del administrador cuando un síntoma operativo exige una acción inmediata.
Las tareas rutinarias exitosas, los backups completados, los reinicios programados o los despliegues sin errores no generan notificaciones.

El sistema se organiza en tres niveles de señal:

  • 🟢 Bajo ruido (low‑noise): métricas y logs disponibles para depuración post‑mortem o consulta voluntaria en Grafana. La actividad normal no molesta.
  • 🟡 Consulta voluntaria (alert‑driven): dashboards pasivos que el administrador revisa cuando quiere conocer el estado del sistema.
  • 🔴 Crítico (critical): alertas push inmediatas por ntfy y Matrix que se disparan exclusivamente ante síntomas que requieren intervención humana urgente —pérdida de heartbeat de la bomba del sótano, ZFS (sistema de archivos con integridad de datos) DEGRADED, SLO (objetivo de nivel de servicio) en riesgo, backup no verificado durante más de 8 días—.

Este comportamiento sigue las prácticas de Google SRE: se alerta sobre síntomas (lo que le duele al sistema), no sobre causas (lo que el administrador ya puede investigar por su cuenta).
El silencio es la señal de normalidad; el ruido es la señal de acción.

Los tres niveles de señal en la práctica

🟢 Nivel 1 – Bajo ruido (low‑noise)

Qué incluye Dónde se consulta
Métricas de CPU, RAM, red y disco de cada LXC (contenedor ligero de Proxmox). Grafana, dashboards por servicio.
Logs estructurados de aplicaciones (peticiones HTTP, errores 404, reinicios de servicios no críticos). Loki, consultas LogQL (lenguaje de consulta de logs).
Métricas de la finca: humedad del suelo, generación solar, nivel de baterías Victron. Grafana, panel de finca.
Resultados de backups exitosos y snaps ZFS completados. No se notifican; solo se registra la métrica en Victoria Metrics.

🟡 Nivel 2 – Consulta voluntaria (alert‑driven)

Qué incluye Dónde se consulta
Dashboards de salud general del sistema. Grafana (Overview).
Estado de la despensa de datos (última actualización de cada fuente). Grafana, panel de despensa.
Progreso de simulacros de DR y resultados de tests de restauración. Grafana, panel de backups.
Tendencias de consumo energético y eficiencia por vatio. Grafana, panel de energía.

El administrador accede a ellos por interés profesional, no porque el sistema le haya interrumpido.
La IA de Ollama también consulta estos dashboards durante sus análisis nocturnos, pero no generan notificación.

🔴 Nivel 3 – Crítico (critical)

Solo los siguientes síntomas disparan una notificación push inmediata:

Síntoma Canal Motivo
Pérdida de heartbeat de la bomba del sótano (Shelly (actuador eléctrico WiFi)) o del ESP32 (microcontrolador WiFi para sensores) del Altherma. ntfy + Matrix Consecuencia física irreversible: inundación o falta de climatización.
ZFS pool DEGRADED o FAULTED. ntfy + Matrix Riesgo de pérdida de datos.
SLO en riesgo: backup sin verificar durante más de 8 días, RTO (tiempo objetivo de recuperación) del último simulacro superior a 15 minutos. ntfy + Matrix Degradación de la capacidad de recuperación.
Servicio Tier A caído (NetBird, Authentik, Forgejo, Node-RED crítico). ntfy + Matrix Afecta a la operación esencial del sistema.
Espacio en disco por debajo del 10% en el pool ZFS (agrupación de discos gestionada por ZFS) principal. ntfy + Matrix Riesgo de parada de servicios por falta de espacio.
Temperatura del servidor Ra (servidor principal de SmallCountry) por encima del umbral seguro. ntfy + Matrix Riesgo de daño físico del hardware.

Cualquier otra condición se investiga en los dashboards, pero no interrumpe.

Flujo de una alerta

  1. Detección
  2. Victoria Metrics evalúa las reglas definidas en Alertmanager.

  3. Uptime Kuma comprueba la disponibilidad de los servicios y expone métricas que Alertmanager puede consumir.

  4. Enrutamiento

  5. Si la alerta es crítica, Alertmanager la envía simultáneamente a ntfy (push al móvil) y a Matrix (sala de operaciones).

  6. Si la alerta es de warning, solo se registra en Grafana y queda visible en el panel de alertas, sin push.

  7. Respuesta

  8. El administrador recibe la notificación en el móvil o en el cliente Matrix.
  9. Accede a Grafana para ver el contexto de la alerta (métricas relacionadas, logs recientes en Loki).

  10. Si la IA de Ollama está disponible, puede solicitarle un diagnóstico preliminar basado en los logs indexados en Qdrant.

  11. Registro

  12. Todas las alertas, tanto las notificadas como las silenciosas, quedan registradas en Victoria Metrics con su duración y resolución.
  13. Los simulacros trimestrales incluyen la verificación de que las alertas críticas llegan correctamente a los canales configurados.

Stack necesario

  • Alertmanager – Evaluación de reglas de alerta, enrutamiento y deduplicación.
  • Victoria Metrics – Fuente de métricas para las reglas de alerta.
  • Loki – Fuente de logs para diagnóstico post‑mortem (no para alertas).
  • ntfy – Notificaciones push al móvil.
  • Matrix – Chat de operaciones con sala específica para alertas.
  • Grafana – Dashboards pasivos de consulta voluntaria.
  • Uptime Kuma – Healthchecks externos que alimentan métricas.

Relaciones con otros principios

Diagrama de silencio operativo y flujo de alertas

graph TD
    subgraph Monitoreo [Monitoreo continuo]
        direction TB
        VicMet[Victoria Metrics]
        Loki[Loki]
        Uptime[Uptime Kuma]
        Alloy[Grafana Alloy]
    end

    subgraph Evaluacion [Evaluación de alertas]
        direction TB
        AlertM[Alertmanager]
        Reglas[Reglas de alerta]
        AlertM --> Reglas
    end

    subgraph Canales [Canales de notificación]
        direction TB
        ntfy[ntfy - push móvil]
        Matrix[Matrix - sala de operaciones]
    end

    subgraph Consulta [Consulta voluntaria]
        direction TB
        Grafana[Grafana - dashboards]
        IA[Ollama - diagnóstico]
    end

    Alloy --> VicMet
    Alloy --> Loki
    Uptime --> VicMet
    VicMet --> AlertM
    AlertM -->|Crítico| ntfy
    AlertM -->|Crítico| Matrix
    AlertM -.->|Warning silencioso| Grafana
    VicMet --> Grafana
    Loki --> Grafana
    Grafana --> IA

    style Monitoreo fill:#a5d6a7,stroke:#2e7d32,color:#000
    style Evaluacion fill:#90caf9,stroke:#1565c0,color:#000
    style Canales fill:#ffcc80,stroke:#e65100,color:#000
    style Consulta fill:#e1bee7,stroke:#8e24aa,color:#000

← Principio 8: Observabilidad integral   |   Principio 10: Asistencia inteligente →

Secciones relacionadas