Informe SRE diario - 2026-09-05

Resumen operativo de almasrv.thehomelesssherlock.com para las últimas 24 horas. El informe del servidor se generó el 5 de septiembre de 2026 a las 06:00:58 UTC y las comprobaciones de disponibilidad finalizaron a las 06:01:26 UTC.

Estado general

DEGRADED. Los 13 endpoints supervisados están disponibles y Docker no registra contenedores unhealthy ni en reinicio. Sin embargo, OpenClaw presenta un fallo operativo confirmado: la autorización OAuth de OpenAI Codex está caducada y las tareas programadas no pueden renovar el token ni completar el fallback de modelo.

Indicadores principales

Indicador Valor Evaluación
Disponibilidad HTTP 13 de 13 endpoints activos OK
Uptime 3 días, 13 horas y 44 minutos OK
Carga media 2.83 / 2.82 / 2.95 Requiere correlación con CPU y línea base
Memoria 14 GiB usados de 22 GiB; 8.2 GiB disponibles Con margen disponible
Swap 4.0 GiB usados de 4.0 GiB Riesgo preventivo
Disco raíz 144 GiB usados de 199 GiB, 73% Seguimiento recomendado
Volumen /opt 22 GiB usados de 50 GiB, 44% OK
Docker 86 activos, 0 unhealthy, 0 reiniciando, 14 detenidos Operación principal estable
Certificado más próximo llm.sherlockhomeless.net, 30 días restantes Advertencia preventiva
Protección SSH Fail2ban activo; 10 bloqueos actuales Protección operativa

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, OpenClaw recibió respuestas HTTP 401 al intentar renovarla. La tarea programada probó los candidatos configurados y terminó sin un modelo alternativo disponible.

Impacto activo: las ejecuciones de OpenClaw que dependen de OpenAI Codex no pueden completarse. El impacto está localizado en esa integración y no implica una caída general del servidor ni de los endpoints web supervisados.

Servicios degradados e impacto

  • OpenClaw: degradado por fallo de autenticación confirmado. Requiere reautorización.
  • Memos: respondió HTTP 200 en el segundo intento. La medición acumulada fue de 8.849 segundos, aunque la solicitud exitosa tardó aproximadamente 153 ms. Esto indica un fallo transitorio o activación bajo demanda, no una caída vigente.
  • OneTimeSecret: respondió HTTP 200 en el segundo intento, con 8.972 segundos acumulados y aproximadamente 522 ms en la solicitud exitosa. Al estar gestionado por Sablier, su estado detenido no se considera por sí mismo una incidencia.
  • Traefik y Authentik: se observaron dos cancelaciones puntuales de ForwardAuth, pero ambos endpoints respondieron correctamente durante la comprobación final. No hay evidencia de impacto sostenido.

Riesgos preventivos

  • Swap completamente utilizada: los 4 GiB están ocupados. Los mayores consumidores observados incluyen procesos de MySQL/MariaDB, Python, Gunicorn, Celery y Ruby. Hay memoria disponible, por lo que debe investigarse si se trata de páginas antiguas no recuperadas o de presión de memoria recurrente.
  • Eventos SELinux repetitivos: durante toda la ventana se registraron bloqueos de la transición nnp_transition solicitada por Docker. No existe evidencia suficiente para atribuirles una caída, pero su periodicidad justifica revisar la política y el contenedor que los provoca.
  • Renovación ACME con DNS inválido: Traefik no pudo renovar el certificado solicitado para opencode.sherlockhomeless.net porque no encontró registros A ni AAAA válidos. Puede tratarse de una configuración o router obsoleto y debe resolverse antes de que exista impacto.
  • Certificado próximo al umbral: llm.sherlockhomeless.net dispone de 30 días restantes. Los demás certificados activos informados tienen entre 32 y 86 días.
  • Contenedores detenidos: hay 14 contenedores no activos; 10 están identificados como gestionados por Sablier y no representan una caída sin evidencia adicional. Entre los cuatro restantes, memos-proxy terminó con código 137 y merece validación si debía permanecer activo.
  • Terminaciones forzadas: Docker registró varias ocasiones en las que un mismo contenedor no terminó dentro de los 10 segundos posteriores a SIGTERM. El resumen no proporciona su nombre, por lo que debe identificarse antes de evaluar el impacto.
  • Sondeos SSH: se observaron usuarios inexistentes, fallos PAM, incompatibilidad de protocolo y conexiones reiniciadas. Fail2ban permanece activo con 367 fallos acumulados, 28 bloqueos totales y 10 bloqueos actuales; estos eventos son compatibles con sondeos externos y no prueban una intrusión.

Acciones recomendadas

  1. Ejecutar la reautorización de OpenAI Codex en OpenClaw y confirmar posteriormente una ejecución satisfactoria de la tarea programada.
  2. Analizar la utilización de swap junto con la presión de memoria, el historial de OOM y el consumo de MySQL/MariaDB, Python, Gunicorn y Celery antes de liberar swap o reiniciar procesos.
  3. Examinar el evento SELinux asociado a Docker, identificar el contenedor y ajustar la política o configuración mínima necesaria sin desactivar SELinux globalmente.
  4. Revisar los cuatro contenedores detenidos que no están clasificados como gestionados por Sablier, especialmente memos-proxy, y determinar si sus paradas fueron intencionadas.
  5. Identificar el contenedor sometido repetidamente a terminación forzada y corregir su proceso de apagado, dependencia o tiempo de gracia si el comportamiento continúa.
  6. Corregir el DNS o eliminar la configuración obsoleta de opencode.sherlockhomeless.net; comprobar además la renovación automática de llm.sherlockhomeless.net.
  7. Repetir las comprobaciones de Memos y OneTimeSecret para confirmar si los primeros intentos fallidos corresponden al arranque bajo demanda esperado o a inestabilidad real.

Contexto operativo

El host ejecuta el kernel 5.14.0-570.58.1.el9_6.x86_64. No hay contenedores unhealthy ni en bucle de reinicio. Las tareas registradas de Paperless finalizaron correctamente y no se observaron errores relevantes en n8n, Nextcloud o el relay de correo.

Las comprobaciones HTTP confirman accesibilidad y respuesta HTTP 200, incluidas las redirecciones esperadas hacia páginas de autenticación o inicio de sesión. No constituyen una prueba transaccional completa de cada aplicación.

Los avisos de systemd sobre unidades marcadas como inaccesibles para usuarios no privilegiados indican explícitamente que no afectan a la lectura de la configuración mediante las API de systemd. Se consideran ruido operativo de baja prioridad, no una degradación activa.