Informe SRE diario - 2026-08-08

Resumen operativo privado de almasrv.thehomelesssherlock.com para las últimas 24 horas, desde el 7 de agosto de 2026 a las 06:00 UTC hasta el 8 de agosto de 2026 a las 06:00 UTC. Datos consolidados el 8 de agosto de 2026 a las 06:01 UTC.

Estado general

DEGRADED. Los 13 endpoints supervisados están disponibles y no hay contenedores en estado unhealthy o reiniciándose. Sin embargo, OpenClaw presenta un fallo operativo confirmado: la autorización OAuth de OpenAI Codex expiró y los intentos de renovación devuelven HTTP 401, dejando sin candidato funcional las tareas programadas que dependen de ese proveedor.

Indicadores principales

Indicador Valor Evaluación
Disponibilidad HTTP 13 de 13 endpoints disponibles OK
Uptime 4 semanas, 2 días, 5 horas y 28 minutos Estable
Carga media 2.55 / 2.73 / 2.65 Sin impacto confirmado
Memoria 15 GiB usados de 22 GiB; 7.5 GiB disponibles Con margen disponible
Swap 4.0 GiB usados de 4.0 GiB Riesgo alto
Disco raíz 128 GiB de 199 GiB; 65% OK
Disco de aplicaciones 18 GiB de 50 GiB; 35% OK
Docker 75 activos, 0 unhealthy, 0 reiniciándose, 15 detenidos Operativo
Certificado más próximo spintools.pro y www.spintools.pro: 29 días Advertencia preventiva
Protección SSH Fail2ban activo; 21 bloqueos actuales y 644 acumulados Operativa

Incidentes críticos

OAuth de OpenClaw/OpenAI Codex expirado

La credencial OAuth expiró el 4 de agosto de 2026. A las 06:00 UTC se confirmaron respuestas HTTP 401 durante la renovación, seguidas por el fallo del modelo principal y del candidato alternativo.

  • Impacto activo: las tareas programadas de OpenClaw que requieren OpenAI Codex no pueden completarse mediante los modelos configurados.
  • Alcance: limitado a esa integración; no hay evidencia de indisponibilidad general del host ni de los 13 servicios web comprobados.
  • Recuperación requerida: nueva autenticación de Codex y validación posterior de las ejecuciones programadas.

Servicios degradados e impacto

  • OpenClaw: degradado por fallo de autenticación confirmado. El mecanismo de fallback agotó sus candidatos sin completar la tarea.
  • Memos: respondió correctamente en el segundo intento, con una latencia total observada de 8.876 segundos.
  • Vikunja: respondió correctamente en el segundo intento, con una latencia total observada de 8.618 segundos.
  • One-Time Secret: respondió correctamente en el segundo intento, con una latencia total observada de 8.835 segundos.

Las latencias elevadas anteriores son compatibles con activación bajo demanda y con el retardo configurado entre reintentos. Se consideran degradación de tiempo de arranque, no una caída, porque las comprobaciones terminaron con HTTP 200. Del mismo modo, los contenedores detenidos administrados por Sablier no se clasifican como incidentes sin evidencia adicional de fallo.

Riesgos preventivos

  • Swap saturada: solo quedan aproximadamente 4 MiB libres. Aunque todavía existen 7.5 GiB de memoria disponible, la ocupación completa puede aumentar la latencia y dificultar la respuesta ante nuevos picos. Los principales consumidores observados incluyen procesos MySQL, Python, MariaDB, Celery y Chromium.
  • Renovación TLS próxima: los certificados de spintools.pro y www.spintools.pro vencen en 29 días. El resto de los dominios activos revisados dispone de al menos 32 días.
  • Ruido de SELinux: se registraron denegaciones repetidas relacionadas con mandb y las capacidades sys_admin y sys_resource. No se ha confirmado impacto sobre servicios, pero la repetición reduce la señal útil del diario.
  • Exposición SSH: se mantienen sondeos automatizados, intentos con usuarios inexistentes, paquetes de clave incompletos y conexiones interrumpidas antes de autenticarse. Fail2ban está activo, por lo que estos eventos no demuestran una brecha ni una inactividad del control.
  • Configuración PAM/MFA: aparecen intentos contra cuentas inexistentes y avisos por ausencia de configuración MFA para root. Debe verificarse la política prevista para esa cuenta, sin asumir que los intentos externos hayan sido exitosos.
  • Contenedores terminados de forma forzada: algunos servicios registran códigos 137 o 143 y Docker informó de procesos que no terminaron dentro del plazo de diez segundos. No existe impacto actual confirmado, pero conviene comprobar si las terminaciones corresponden al ciclo normal de Sablier.
  • Permisos de unidades systemd: varias unidades se encuentran marcadas como inaccesibles globalmente. Systemd indica expresamente que esto no afecta al acceso de configuración mediante sus API, por lo que se clasifica como advertencia de higiene y no como fallo.

Acciones recomendadas

  1. Restaurar OpenClaw: ejecutar la nueva autenticación de Codex, confirmar que la renovación deja de devolver HTTP 401 y lanzar una tarea programada de prueba.
  2. Investigar la swap: revisar la antigüedad y el consumo de los procesos MySQL, MariaDB, Python, Celery y Chromium; liberar memoria o reiniciar componentes únicamente dentro de una ventana controlada.
  3. Validar los arranques bajo demanda: medir por separado el tiempo de activación de Memos, Vikunja y One-Time Secret, y ajustar Sablier o los umbrales de comprobación si el retraso no cumple el objetivo operativo.
  4. Renovar o verificar la autorrenovación TLS: priorizar spintools.pro y www.spintools.pro antes de alcanzar una ventana inferior a 14 días.
  5. Analizar las denegaciones SELinux: revisar los dos eventos de mandb con sealert y corregir la causa sin desactivar SELinux de forma global.
  6. Revisar SSH y MFA: confirmar la política de acceso de root, la configuración PAM y el funcionamiento del verificador de claves públicas, manteniendo Fail2ban activo.
  7. Correlacionar terminaciones Docker: identificar el contenedor que excede repetidamente el periodo de parada y confirmar si los códigos 137 y 143 son esperados durante la suspensión bajo demanda.

Contexto operativo

  • Kernel activo: 5.14.0-570.58.1.el9_6.x86_64.
  • No se detectaron contenedores unhealthy ni ciclos de reinicio.
  • De los 15 contenedores detenidos, 11 figuran como administrados por Sablier y cuatro pertenecen a otros grupos. Su estado detenido no implica por sí solo indisponibilidad.
  • Nextcloud bloqueó correctamente solicitudes externas dirigidas a archivos de configuración y al estado interno del servidor. Son intentos denegados, no errores de disponibilidad.
  • Paperless completó correctamente las tareas de correo y workflows incluidas en el digest; las entradas destacadas son informativas.
  • El sistema de archivos raíz conserva 72 GiB libres y el volumen de aplicaciones conserva 33 GiB, sin presión inmediata de capacidad.
  • Las desconexiones SSH, los usuarios inexistentes y los errores de preautenticación se consideran principalmente ruido de Internet mientras no exista evidencia de autenticación exitosa o evasión de controles.