Saltar a contenido

O3 Alerts Catalog

Catalogo operativo de alertas controladas al 2026-06-01.

Objetivo

Detectar problemas reales del VPS, Docker, servicios y Prometheus sin generar ruido innecesario.

Principios

  • usar umbrales conservadores
  • usar for: para evitar falsos positivos
  • usar solo severidades warning y critical
  • escribir mensajes claros para personas no tecnicas
  • no abrir puertos nuevos
  • no exponer Grafana
  • no enviar notificaciones externas todavia

Receiver actual

  • Alertmanager queda en modo local con receiver local-null
  • la plataforma agrupa por alert_group y severity
  • una alerta critical inhibe la warning equivalente cuando comparten contexto
  • hoy las alertas se revisan en Prometheus, Alertmanager y dashboards O2

Alertas de host

Alerta Severidad Intencion Umbral Duracion Que revisar primero
HostDiskUsageHighWarning warning avisar que el disco empieza a ponerse tenso / arriba de 80% 15m crecimiento de datos, backups y retencion
HostDiskUsageHighCritical critical avisar riesgo real de saturacion del VPS / arriba de 90% 15m directorio que crece y margen para backup / Prometheus
HostMemoryUsageHighWarning warning avisar RAM alta sostenida RAM usada arriba de 85% 15m contenedor o proceso que esta creciendo
HostMemoryUsageHighCritical critical avisar riesgo de degradacion por memoria RAM usada arriba de 92% 15m consumo de contenedores y estado de swap
HostCpuUsageHighWarning warning avisar CPU alta sostenida CPU arriba de 85% 15m top consumidores del host y Docker
HostCpuUsageHighCritical critical avisar riesgo real de lentitud por CPU CPU arriba de 95% 15m carga real y servicio que la produce
HostLoadHighWarning warning avisar cola de trabajo sostenida load15 mayor a 1.5 por CPU 15m CPU, RAM y disco en conjunto
HostLoadHighCritical critical avisar presion fuerte del host load15 mayor a 2 por CPU 15m cuello de botella real antes de intervenir

Alertas de Docker

Alerta Severidad Intencion Umbral Duracion Que revisar primero
DockerTrackedContainerDown critical detectar si cae un contenedor clave openclaw-openclaw-gateway-1, nginx-proxy-manager o portainer sin verse por mas de 4m, solo si cAdvisor sigue UP 2m adicionales docker ps, logs y reinicios recientes
CadvisorNoData warning avisar perdida de metricas de contenedores up{job="cadvisor"} == 0 5m contenedor obs-cadvisor y acceso a Docker
NodeExporterNoData warning avisar perdida de metricas del host up{job="node-exporter"} == 0 5m contenedor obs-node-exporter y mounts readonly

Nota operativa: si cae cAdvisor, la plataforma debe disparar CadvisorNoData y no inferir caida de openclaw-openclaw-gateway-1, nginx-proxy-manager ni portainer solo por perdida de la fuente container_last_seen.

Alertas de servicios

Alerta Severidad Intencion Umbral Duracion Que revisar primero
OpenClawHttpsDown critical detectar caida publica real de OpenClaw probe_success=0 sobre https://openclaw.alpuntodeventa.com.ar/ 3m Service Availability, upstream de NPM y contenedor OpenClaw
NpmLocalAdminDown warning detectar caida local de administracion NPM probe_success=0 sobre http://host.docker.internal:81/ 5m contenedor nginx-proxy-manager, logs y host
PortainerLocalDown warning detectar caida local de administracion Portainer probe_success=0 sobre https://host.docker.internal:9443/ 5m contenedor portainer, logs y escucha local
BlackboxProbeFailed warning marcar que un probe de disponibilidad falla probe_success=0 5m endpoint puntual, red o SSL del destino

Alertas de Prometheus

Alerta Severidad Intencion Umbral Duracion Que revisar primero
PrometheusTargetDown warning detectar targets internos caidos up=0 en targets sin alerta especifica propia 5m Targets de Prometheus y logs del servicio afectado
PrometheusTsdbGrowthWarning warning avisar crecimiento fuerte de TSDB proyeccion a 24h mayor a 70% del limite 30m dashboard Capacity Planning y cardinalidad
PrometheusTsdbGrowthCritical critical avisar riesgo real de presion sobre TSDB proyeccion a 24h mayor a 85% del limite 30m causa del crecimiento antes de tocar retencion

Que hacer si dispara

  • mirar primero el dashboard O2 que mejor corresponda
  • confirmar si el problema es real con una segunda evidencia simple
  • revisar solo el servicio o recurso afectado
  • guardar evidencia del disparo antes de corregir

Que no hacer

  • no reiniciar todo Docker por una sola alerta
  • no borrar volumenes, backups ni datos para ganar espacio rapido
  • no tocar OpenClaw internamente
  • no abrir puertos nuevos para diagnosticar
  • no habilitar notificaciones externas sin decision formal

Por que no hay notificaciones externas todavia

  • primero habia que probar que las reglas no generen ruido
  • el stack todavia esta en etapa de ajuste conservador
  • falta decidir canal, horarios, responsables y politica de silencios

Proximo paso futuro recomendado

  • O3.1 ya fue revalidado en verde con drills controlados y regla endurecida
  • definir un canal externo unico y simple, por ejemplo email o chat
  • habilitarlo solo cuando el equipo confirme que O3 no genera spam