Informe SRE diario - 2026-09-11

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

Estado general

DEGRADED. Los 13 endpoints monitorizados están disponibles y no hay contenedores marcados como no saludables o reiniciándose. Sin embargo, existe un fallo operativo confirmado en OpenClaw: la autenticación OAuth de OpenAI Codex está expirada y las tareas programadas no pueden utilizar ni el modelo solicitado ni su alternativa.

Indicadores principales

Indicador Resultado Evaluación
Disponibilidad HTTP 13 de 13 endpoints disponibles OK
Uptime 1 semana, 2 días, 13 horas y 44 minutos Estable
Carga 3,44 / 3,55 / 3,43 Sin referencia de CPU para determinar saturación
Memoria 15 GiB usados de 22 GiB; 6,9 GiB disponibles Con margen disponible
Swap 4,0 GiB usados de 4,0 GiB Riesgo elevado
Disco raíz 143 GiB de 199 GiB; 72 % utilizado Vigilancia preventiva
Docker 85 en ejecución, 0 no saludables, 0 reiniciándose y 15 detenidos Operación principal estable
TLS 50 dominios activos; vencimiento mínimo en 30 días Renovación próxima
Protección SSH Fail2ban activo; 6 bloqueos actuales y 69 históricos Protección operativa

Incidentes criticos

OAuth de OpenClaw Codex expirado

La credencial OAuth figura como expirada desde el 4 de agosto de 2026. A las 06:00 UTC se registraron respuestas HTTP 401 al intentar renovarla. Las tareas programadas fallaron primero con openai-codex/gpt-5.4 y después con la alternativa openai-codex/gpt-5.1, que también quedó sin una opción posterior de respaldo.

Impacto activo: las ejecuciones de OpenClaw que dependen del proveedor OpenAI Codex no pueden completarse. No hay evidencia de que este incidente haya afectado a los 13 servicios web comprobados.

Servicios degradados e impacto

  • OpenClaw: degradado por fallo confirmado de autenticación. El impacto está limitado a las tareas que necesitan OpenAI Codex.
  • Vikunja: respondió correctamente en el segundo intento. La medición acumulada fue de 8,746 segundos, aunque la solicitud exitosa empleó aproximadamente 102 ms. Esto indica una indisponibilidad o demora transitoria durante el primer intento, no una caída sostenida.
  • One-Time Secret: también necesitó dos intentos. La medición acumulada fue de 8,886 segundos y la solicitud exitosa empleó aproximadamente 449 ms.
  • Traefik y ACME: se registró un fallo de renovación para opencode.sherlockhomeless.net porque el dominio no tenía registros A o AAAA válidos. No se observó impacto sobre el resto del enrutamiento ni sobre los certificados activos comprobados.

Nextcloud, OnlyOffice, Paperless, n8n, Memos, Karakeep, Authentik, Traefik, RSS, Dozzle y Beszel devolvieron HTTP 200. Algunas comprobaciones terminaron en páginas de autenticación o inicio de sesión, por lo que confirman accesibilidad HTTP, pero no validan flujos funcionales completos.

Riesgos preventivos

  • Swap agotada: los 4 GiB están ocupados. Los principales consumidores incluyen procesos MySQL, Python, Gunicorn, MariaDB, Celery y Ruby. No se acredita una degradación directa, pero aumenta el riesgo de latencia y presión de memoria.
  • Eventos SELinux recurrentes: SELinux bloqueó repetidamente a Docker en operaciones nnp_transition, aproximadamente con periodicidad horaria. También hubo una ráfaga de denegaciones de capacidades para mandb. Los servicios siguen disponibles, pero la recurrencia requiere análisis antes de ajustar políticas.
  • Certificados próximos a renovación: Nextcloud y OnlyOffice tienen 30 días restantes; otros dominios se encuentran entre 31 y 36 días. No están vencidos, pero debe verificarse que la renovación automática funcione.
  • Capacidad de disco: la raíz está al 72 %. Quedan 57 GiB, por lo que no existe presión inmediata, aunque el crecimiento de imágenes, volúmenes y registros debe vigilarse.
  • Contenedores detenidos: 11 de los 15 contenedores no ejecutándose están gestionados por Sablier y no deben considerarse caídos sin evidencia adicional. Entre los cuatro restantes aparecen salidas recientes, incluido memos-proxy con código 137, que requieren correlación operativa.
  • Actividad SSH hostil: se observaron usuarios inexistentes, fallos PAM, desconexiones durante el intercambio de claves y protocolos incompatibles. Fail2ban permanece activo, por lo que estos registros representan principalmente intentos bloqueados y ruido de Internet, no una intrusión confirmada.

Acciones recomendadas

  1. Reautenticar OpenClaw Codex de inmediato mediante la acción operativa codex-reauth y ejecutar una tarea controlada para confirmar tanto la renovación como el acceso al modelo.
  2. Investigar la presión de memoria y swap, correlacionando consumo residente, actividad de paginación y latencia de MySQL, MariaDB, Python y Gunicorn antes de reiniciar procesos o liberar swap.
  3. Analizar las denegaciones SELinux relacionadas con Docker y mandb. Validar contexto, política y proceso originador; no desactivar SELinux ni crear excepciones amplias sin confirmar la necesidad.
  4. Revisar el DNS de opencode.sherlockhomeless.net. Restaurar sus registros A o AAAA si el servicio continúa activo, o retirar la configuración ACME obsoleta si el nombre fue dado de baja.
  5. Auditar las salidas recientes de contenedores, especialmente los códigos 137 y el código 2 de Vikunja, diferenciando activaciones bajo demanda, paradas planificadas y terminaciones forzadas.
  6. Verificar la renovación automática de TLS para Nextcloud y OnlyOffice antes de que entren en una ventana inferior a 14 días.
  7. Crear alertas de tendencia para swap, disco raíz y endpoints que necesiten reintentos, con atención específica a Vikunja y One-Time Secret.

Contexto operativo

El servidor utiliza el kernel 5.14.0-570.58.1.el9_6.x86_64. El volumen raíz XFS está al 72 %, /opt al 45 % y /boot al 44 %. No se detectaron contenedores no saludables ni ciclos de reinicio.

El resumen de Docker se tomó inmediatamente antes de la comprobación HTTP. Por ello, algunos servicios gestionados bajo demanda pueden figurar como detenidos en la instantánea y responder después al ser activados por la propia solicitud. Los estados históricos de contenedores detenidos desde hace semanas tampoco representan por sí solos incidentes actuales.

Los registros de Paperless muestran tareas de correo y entrenamiento completadas correctamente. El principal volumen de errores del journal corresponde a eventos SELinux repetidos y a intentos SSH externos, no a una indisponibilidad general del servidor.