Informe SRE diario - 2026-09-09

Informe diario de almasrv.thehomelesssherlock.com para las últimas 24 horas, generado el 9 de septiembre de 2026 a las 06:00 UTC. La comprobación de disponibilidad finalizó a las 06:01 UTC.

Estado general

CRITICAL: la autorización OAuth de OpenClaw para OpenAI Codex está caducada y el sistema no puede renovarla. Las tareas programadas del gateway recibieron errores HTTP 401 y agotaron las alternativas de modelo, por lo que existe un fallo operativo confirmado en las cargas que dependen de este proveedor.

Los 13 endpoints supervisados están disponibles y no hay contenedores en estado unhealthy o restarting. No se observa una indisponibilidad general de la plataforma.

Indicadores principales

Incidentes críticos

OAuth de OpenClaw caducado

La credencial OAuth de OpenAI Codex caducó el 4 de agosto de 2026. A las 06:00 UTC, OpenClaw registró fallos de renovación con HTTP 401. Los intentos con los modelos configurados finalizaron por error de autenticación y no quedó otro candidato disponible.

Impacto activo: las tareas programadas y sesiones de OpenClaw que requieren OpenAI Codex no pueden completarse mediante esa integración. La acción indicada por el propio sistema es codex-reauth.

Servicios degradados e impacto

• OpenClaw: degradación confirmada por fallo de autenticación y agotamiento del mecanismo de fallback.
• Memos, Vikunja y OTS: respondieron correctamente, pero necesitaron un segundo intento y registraron latencias observadas de aproximadamente 8,7 a 8,9 segundos. El resultado es compatible con activación bajo demanda o recuperación entre reintentos; no constituye una caída.
• Traefik y Authentik: se registraron cancelaciones transitorias en ForwardAuth. En la comprobación final, tanto Traefik como Authentik respondieron con HTTP 200, por lo que no hay impacto activo confirmado.
• CrowdSec: Traefik registró al menos un timeout al enviar métricas al servicio. No se ha confirmado pérdida de filtrado ni indisponibilidad actual.

Riesgos preventivos

• Swap completamente ocupada: los 4 GiB están usados. MySQL/MariaDB, procesos Python, Gunicorn, Celery y Ruby figuran entre los principales consumidores. Aunque quedan 7,3 GiB de memoria disponible y no hay evidencia aportada de OOM, esta situación puede aumentar la latencia y reducir el margen ante picos.
• Denegaciones SELinux recurrentes: Docker genera eventos repetidos relacionados con nnp_transition y, en un caso, nosuid_transition. Debe identificarse el contenedor o perfil que los provoca antes de modificar políticas; no se debe desactivar SELinux como mitigación genérica.
• Procesos Node con coredump: se registraron dos volcados de núcleo durante la ventana de 24 horas. Los datos no identifican con certeza el servicio afectado ni prueban impacto actual.
• Renovación ACME fallida: Traefik no pudo renovar el certificado de opencode.sherlockhomeless.net porque no encontró registros DNS A o AAAA válidos. No hay evidencia de una caída activa, pero la configuración debe corregirse o retirarse si el dominio ya no se utiliza.
• Capacidad del disco raíz: el uso se encuentra en 73%. No es crítico, pero conviene establecer seguimiento antes de alcanzar umbrales operativos más altos.
• Certificados próximos: los certificados de Nextcloud y OnlyOffice tienen 32 días restantes; Ruleta tiene 33 días y varios servicios 34 días. Todavía existe margen, pero debe verificarse que la renovación automática funciona.
• Configuración PAM/SSH: aparecen intentos contra usuarios inexistentes y avisos de segundo factor no configurado para algunos nombres de usuario. Fail2ban está activo, pero conviene validar que la política PAM se comporta como se espera y no genera rutas de autenticación ambiguas.

Acciones recomendadas

1. Restaurar OpenClaw de inmediato: ejecutar el procedimiento codex-reauth, confirmar la renovación OAuth y repetir manualmente una tarea representativa.
2. Investigar la swap: correlacionar consumo de memoria, actividad de swap y latencia por proceso; revisar especialmente las instancias de MySQL/MariaDB, Python, Gunicorn y Celery antes de reiniciar o vaciar swap.
3. Analizar los AVC de SELinux: obtener el detalle de los eventos indicados por sealert, identificar el contenedor responsable y aplicar una corrección específica de etiquetas, montaje o política.
4. Relacionar los coredumps de Node: identificar unidad, contenedor e imagen asociados a ambos procesos y revisar si coinciden con salidas recientes con código 137.
5. Corregir el dominio ACME: restaurar los registros DNS de opencode.sherlockhomeless.net si sigue activo o eliminar su router y solicitud de certificado si fue retirado.
6. Validar los servicios bajo demanda: comprobar el ciclo de arranque de Memos, Vikunja y OTS, y confirmar que sus tiempos de activación permanecen dentro del objetivo operativo.
7. Revisar autenticación SSH: comprobar la configuración de PAM, segundo factor y validación de claves, manteniendo Fail2ban activo y verificando que los usuarios no autorizados se rechazan correctamente.

Contexto operativo

Los 15 contenedores detenidos no equivalen por sí solos a 15 servicios caídos. Once están gestionados por Sablier y pueden permanecer apagados hasta recibir tráfico. Además, las comprobaciones finales de Memos, Vikunja y OTS fueron satisfactorias después de un reintento.

Los contenedores no gestionados por Sablier que permanecen detenidos son changedetection-browser, stirling-pdf, it-tools y memos-proxy. Debe verificarse su intención operativa, especialmente memos-proxy, que terminó recientemente con código 137, aunque el endpoint público de Memos estaba disponible al cierre del informe.

La mayoría del ruido del journal corresponde a denegaciones SELinux repetidas y a sondeos SSH. Los intentos SSH fallidos no indican que Fail2ban esté inactivo: el servicio está activo y mantiene seis bloqueos en el momento del informe.

El sistema utiliza el kernel 5.14.0-570.58.1.el9_6.x86_64. No se registran contenedores unhealthy o en reinicio continuo, y los servicios HTTP supervisados cerraron la ventana con disponibilidad completa.