Informe SRE diario - 2026-08-15

Resumen operativo de almasrv.thehomelesssherlock.com para las últimas 24 horas, generado el 15 de agosto de 2026 a las 06:00 UTC. La comprobación de disponibilidad finalizó a las 06:01 UTC.

Estado general

DEGRADED. La infraestructura web permanece disponible y los 13 de 13 endpoints comprobados responden correctamente, pero OpenClaw presenta un fallo operativo confirmado: la autorización OAuth de OpenAI Codex está caducada, la renovación devuelve HTTP 401 y las tareas programadas afectadas agotan sus alternativas de modelo.

No se observa una caída general, contenedores reiniciándose ni servicios Docker marcados como no saludables.

Indicadores principales

Indicador Valor Evaluación
Disponibilidad HTTP 13/13 endpoints activos OK
Uptime 5 semanas, 2 días, 5 horas Estable
Carga media 3.40 / 2.94 / 2.73 Sin impacto confirmado
Memoria 15 GiB usados de 22 GiB; 6.8 GiB disponibles Vigilar
Swap 4.0 GiB usados de 4.0 GiB Riesgo alto
Disco raíz 128 GiB de 199 GiB, 65% OK
Disco /opt 19 GiB de 50 GiB, 37% OK
Docker 75 activos, 0 no saludables, 0 reiniciándose, 15 detenidos Operativo
TLS más próximo www.thehomelesssherlock.com, 30 días Advertencia preventiva
Fail2ban SSH Activo; 9 bloqueos actuales y 729 históricos Protección activa

Incidentes criticos

Autorización OAuth de OpenClaw caducada

La credencial OAuth de OpenAI Codex caducó el 4 de agosto de 2026. A las 06:00 UTC se confirmaron respuestas HTTP 401 durante la renovación, errores en tareas programadas y agotamiento de la cadena de fallback entre los modelos configurados.

Impacto activo: las automatizaciones de OpenClaw que dependen de OpenAI Codex pueden fallar y no completar su trabajo. El incidente no afecta a la disponibilidad de los 13 endpoints web verificados.

Servicios degradados e impacto

  • OpenClaw: degradado por fallo de autenticación confirmado. Las tareas programadas afectadas terminan con error después de que fallen tanto el modelo solicitado como su alternativa.
  • Servicios bajo demanda: Memos, Vikunja y OneTimeSecret necesitaron un segundo intento y registraron latencias totales cercanas a 8.8 segundos. Finalmente respondieron con HTTP 200, por lo que no se consideran caídos. El comportamiento es compatible con activación bajo demanda, aunque debe verificarse.
  • Traefik y Authentik: Traefik registró una ráfaga de cancelaciones al consultar el servicio de autenticación a las 10:54 UTC del día anterior. La comprobación posterior confirmó HTTP 200 tanto para Traefik como para Authentik, por lo que no hay evidencia de impacto activo al cierre del informe.

Riesgos preventivos

  • Swap agotada: los 4 GiB están ocupados. Los mayores consumidores observados incluyen procesos MySQL, Python, OpenCode, MariaDB, Next.js, Chromium y Celery. Aunque todavía existen 6.8 GiB de memoria disponible, la swap completa reduce el margen frente a nuevos picos y puede introducir latencia.
  • Certificado próximo al umbral: www.thehomelesssherlock.com vence en 30 días. El dominio raíz vence en 31 días. No hay expiración activa, pero debe confirmarse la renovación automática.
  • Estados Docker no limpios: hay 15 contenedores detenidos. Once aparecen administrados por Sablier y no deben interpretarse automáticamente como caídas. No obstante, vikunja terminó con código 2 y onetimesecret con código 1, por lo que conviene revisar su último ciclo de ejecución.
  • Finalizaciones forzadas: el daemon de Docker registró varias ocasiones en las que un contenedor no terminó dentro de los 10 segundos posteriores a SIGTERM, además de errores aislados sobre flujos cerrados y una comprobación de salud cancelada.
  • Ruido de SELinux: se repitieron denegaciones para /usr/bin/mandb sobre las capacidades sys_admin y sys_resource. No se ha demostrado impacto en servicios, pero el volumen de eventos puede ocultar señales más importantes.
  • Presión SSH externa: se observaron intentos contra usuarios inexistentes, fallos PAM, desconexiones durante el intercambio de claves y tiempos de espera previos a la autenticación. Fail2ban permanece activo; estos registros no indican por sí solos una evasión del control.

Acciones recomendadas

  1. Restaurar OpenClaw: ejecutar la reautenticación de Codex y validar después una renovación de credenciales y una tarea programada completa.
  2. Analizar la swap antes de intervenir: comprobar presión de memoria, actividad de intercambio y persistencia de los procesos consumidores. Evitar vaciar la swap de forma indiscriminada sin confirmar margen suficiente en RAM.
  3. Revisar los contenedores bajo demanda: validar el arranque de Memos, Vikunja y OneTimeSecret, sus códigos de salida y la causa de los segundos intentos observados.
  4. Correlacionar el evento Traefik–Authentik: revisar la ventana de las 10:54 UTC para determinar si hubo reinicio, despliegue, saturación o pérdida temporal de conectividad interna.
  5. Verificar la renovación TLS: confirmar que la automatización renovará www.thehomelesssherlock.com y el dominio raíz antes de alcanzar un margen operativo insuficiente.
  6. Investigar las denegaciones de SELinux: analizar los dos eventos de mandb con las referencias de sealert y corregir contexto, paquete o política según corresponda, sin desactivar SELinux.
  7. Revisar higiene operativa: identificar el contenedor que requiere SIGKILL, ajustar su apagado si procede y normalizar los permisos de las unidades systemd que generan advertencias de archivos inaccesibles para otros usuarios.

Contexto operativo

  • Host ejecutando kernel 5.14.0-570.58.1.el9_6.x86_64.
  • La partición raíz conserva 71 GiB libres y /opt conserva 32 GiB; no existe presión inmediata de almacenamiento.
  • Paperless completó correctamente sus tareas de revisión de correo y no encontró documentos nuevos.
  • Nextcloud registró una solicitud aislada a /error.php con respuesta 404, sin evidencia de indisponibilidad.
  • Las advertencias de systemd sobre unidades no accesibles para otros usuarios indican explícitamente que no afectan al funcionamiento, ya que la configuración sigue disponible mediante las API del sistema.
  • Los contenedores detenidos por Sablier representan capacidad bajo demanda y se clasifican como contexto operativo, no como incidentes, mientras sus endpoints puedan activarse y responder.