Informe SRE diario - 2026-09-01

Resumen operativo de almasrv.thehomelesssherlock.com para las últimas 24 horas, generado el 1 de septiembre de 2026 a las 06:00 UTC. Las comprobaciones externas finalizaron a las 06:01 UTC.

Estado general

DEGRADED. Los 13 endpoints supervisados están disponibles y no hay contenedores marcados como no saludables o reiniciándose. Sin embargo, OpenClaw presenta un fallo operativo confirmado: la credencial OAuth de OpenAI Codex está caducada, la renovación devuelve HTTP 401 y las ejecuciones programadas registradas agotaron sus alternativas de modelo. Además, la swap está completamente ocupada y se produjeron varios volcados de memoria de procesos Gunicorn, aunque no se ha confirmado impacto externo asociado.

Indicadores principales

Indicador Valor Evaluación
Disponibilidad externa 13 de 13 endpoints disponibles OK
Contenedores Docker 84 activos, 0 no saludables, 0 reiniciándose, 15 detenidos OK con revisión pendiente
Uptime 1 semana, 16 horas y 15 minutos OK
Carga 3.76 / 3.29 / 3.06 Sin umbral de CPU disponible
Memoria 15 GiB usados de 22 GiB; 7.1 GiB disponibles Vigilancia
Swap 4.0 GiB usados de 4.0 GiB Riesgo alto
Disco raíz 144 GiB de 199 GiB; 73% utilizado Vigilancia
Volumen /opt 21 GiB de 50 GiB; 42% utilizado OK
Certificado más próximo ocode.sherlockhomeless.net: 30 días Advertencia
Protección SSH Fail2ban activo; 7 bloqueos actuales OK

Incidentes críticos

OAuth de OpenClaw/OpenAI Codex caducado

La credencial OAuth figura como caducada desde el 4 de agosto de 2026. A las 06:00 UTC se registraron respuestas HTTP 401 durante la renovación, fallos en una tarea programada y agotamiento de las alternativas configuradas entre los modelos de Codex.

Impacto activo: las ejecuciones de OpenClaw que dependen de OpenAI Codex no pueden autenticarse y pueden finalizar sin respuesta. No existe evidencia de que este incidente afecte a los otros 13 servicios comprobados.

Servicios degradados e impacto

  • OpenClaw: degradación activa y confirmada por fallo de autenticación OAuth.
  • Memos, Vikunja y One-Time Secret: respondieron con HTTP 200, pero necesitaron un segundo intento y registraron tiempos totales aproximados de 8.7 a 8.8 segundos. Esto indica arranque bajo demanda o disponibilidad intermitente durante la primera comprobación, no una caída actual.
  • n8n: registró varios timeouts de conexión a la base de datos y errores Driver not Connected. Su endpoint de salud respondió posteriormente con HTTP 200 en 112 ms, por lo que el episodio parece recuperado en el momento del muestreo.
  • Gunicorn: tres workers generaron volcados de memoria simultáneos a las 23:10 UTC. No se ha identificado en los datos el servicio afectado ni un fallo visible en las comprobaciones externas.
  • Traefik y Authentik: hubo errores temporales por ausencia del middleware de autenticación y cancelaciones de ForwardAuth. Las comprobaciones posteriores de Traefik y Authentik devolvieron HTTP 200, por lo que no se considera una interrupción activa.

Riesgos preventivos

  • Swap agotada: los 4 GiB están ocupados. MySQL/MariaDB, Ruby, Python, Gunicorn y procesos de conversión aparecen entre los principales consumidores. Aunque quedan 7.1 GiB de memoria disponible, esta situación puede aumentar la latencia y agravar reinicios bajo picos de carga.
  • Renovación TLS: ocode.sherlockhomeless.net vence en 30 días. Además, Traefik no pudo renovar el certificado de opencode.sherlockhomeless.net porque no encontró registros DNS A o AAAA válidos.
  • Capacidad del disco raíz: el 73% está utilizado. No es crítico, pero requiere seguimiento para evitar crecimiento sin control de imágenes, registros y volcados de memoria.
  • Estabilidad de procesos: además de los workers Gunicorn, un proceso adb generó un volcado de memoria. El analizador también encontró archivos de core incompletos o no analizables.
  • SELinux y Docker: SELinux bloqueó transiciones solicitadas por Docker. El impacto no está confirmado, pero debe validarse antes de aplicar excepciones.
  • Exposición SSH: continúan los intentos automatizados contra usuarios inexistentes y las conexiones incompatibles. Fail2ban está activo, con 2.061 fallos acumulados y 159 bloqueos totales.

Acciones recomendadas

  1. Prioridad inmediata: renovar la autenticación de OpenClaw mediante el procedimiento codex-reauth y ejecutar una prueba controlada de la tarea programada afectada.
  2. Investigar la ocupación completa de swap, correlacionando consumo residente y swap por proceso; revisar especialmente las instancias de MySQL/MariaDB, Gunicorn y los procesos de conversión antes de liberar memoria.
  3. Identificar el servicio y la versión asociados a los tres workers Gunicorn que volcaron memoria, revisar sus reinicios y conservar un core válido para análisis si el problema se repite.
  4. Revisar la conectividad y los límites de conexiones de la base de datos de n8n, confirmando que los timeouts no continúan fuera de la ventana observada.
  5. Corregir o retirar la configuración DNS de opencode.sherlockhomeless.net y verificar manualmente la renovación ACME; comprobar también la renovación de ocode.sherlockhomeless.net.
  6. Validar la estabilidad de Authentik y la disponibilidad persistente del middleware referenciado por Traefik, especialmente durante recreaciones de contenedores.
  7. Revisar el evento de SELinux con la política efectiva y mantener la protección SSH; no crear excepciones amplias ni relajar controles sin confirmar primero el flujo bloqueado.

Contexto operativo

El servidor ejecuta el kernel 5.14.0-570.58.1.el9_6.x86_64. Los 15 contenedores detenidos no constituyen por sí solos una incidencia: 11 están gestionados por Sablier y pueden permanecer apagados hasta recibir tráfico. Algunos de esos servicios respondieron correctamente durante las comprobaciones, lo que es compatible con un arranque bajo demanda.

Entre los cuatro contenedores detenidos no gestionados por Sablier se encuentra memos-proxy, finalizado con código 137 dos horas antes. Como Memos respondió finalmente con HTTP 200, corresponde investigarlo como señal de presión de recursos o terminación forzada, no declararlo como caída activa.

Los intentos de acceso a archivos protegidos de Nextcloud fueron rechazados por la configuración del servidor, comportamiento esperado ante exploraciones automatizadas. Los registros informativos de Paperless muestran tareas completadas correctamente. Los errores del portal gráfico, los intentos SSH rechazados y varios avisos sobre contenedores ya eliminados se consideran ruido operativo o histórico mientras no exista impacto correlacionado.