Informe SRE diario - 2026-09-04

Resumen operativo de almasrv.thehomelesssherlock.com para las 24 horas comprendidas entre el 3 de septiembre de 2026 a las 06:00 UTC y el 4 de septiembre de 2026 a las 06:00 UTC. Informe generado el 4 de septiembre de 2026 a las 06:01 UTC.

Estado general

DEGRADED. Los 13 endpoints supervisados están disponibles y no hay contenedores reiniciándose o marcados como no saludables. Sin embargo, existe un fallo operativo confirmado en OpenClaw: la credencial OAuth de OpenAI Codex está vencida y los trabajos programados no pueden autenticarse ni completar el fallback configurado. Adicionalmente, la swap está completamente utilizada, lo que aumenta el riesgo de latencia y terminaciones por presión de memoria.

Indicadores principales

Incidentes críticos

OAuth de OpenClaw vencido

La integración openai-codex presenta un fallo activo de autenticación. A las 06:00 UTC se registraron respuestas 401 al intentar renovar la credencial, seguidas de errores en la ejecución programada. Los candidatos de modelo configurados fallaron por autenticación y el proceso terminó sin una alternativa disponible.

• Impacto confirmado: los trabajos de OpenClaw que dependen de OpenAI Codex no pueden ejecutarse correctamente.
• Alcance observado: afecta al flujo programado de OpenClaw; no se observa caída de los 13 endpoints HTTP supervisados.
• Acción requerida: renovar la autorización mediante el procedimiento codex-reauth.

Servicios degradados e impacto

Servicios bajo demanda

memos, vikunja y onetimesecret figuraban detenidos bajo gestión de Sablier. Sus endpoints respondieron correctamente después de un segundo intento, con tiempos globales de comprobación cercanos a 8.7–9.0 segundos. Esto es compatible con activación bajo demanda y no constituye una caída confirmada, aunque sí representa latencia de arranque perceptible.

Traefik y Authentik

Traefik registró errores transitorios context canceled al consultar el servicio de autenticación. En la comprobación final, tanto Traefik como Authentik devolvieron HTTP 200 y completaron el flujo de redirección esperado. No hay impacto activo confirmado, pero conviene correlacionar los eventos con reinicios, despliegues o periodos de presión de recursos.

Contenedores no gestionados por Sablier

memos-proxy terminó con código 137 aproximadamente 22 minutos antes del informe. El endpoint de Memos quedó disponible después de un reintento, por lo que no se declara una indisponibilidad actual. it-tools, stirling-pdf y changedetection-browser también aparecen detenidos, pero los datos disponibles no demuestran impacto activo sobre servicios supervisados.

Riesgos preventivos

• Swap agotada: los 4 GiB están ocupados. Los mayores consumidores identificados incluyen procesos de LiteLLM, MySQL/MariaDB, Python, Gunicorn y Celery. Aunque quedan 8.4 GiB de memoria disponible, la ocupación completa de swap puede mantener páginas frías en disco y elevar la latencia.
• Eventos SELinux recurrentes: durante toda la ventana se repitió aproximadamente cada hora una denegación de nnp_transition para Docker. No hay evidencia suficiente para atribuirle una caída, pero la recurrencia indica una incompatibilidad persistente que debe analizarse.
• CrowdSec: el resumen de patrones contiene 17 fallos de crowdsec-firewall-bouncer.service y 17 eventos de pánico por acceso fuera de rango. El estado actual del servicio no está incluido, por lo que debe verificarse antes de asumir que la protección está operativa.
• Renovación ACME: Traefik no pudo renovar el certificado de opencode.sherlockhomeless.net porque no encontró registros A o AAAA válidos. Este nombre no aparece entre los dominios TLS activos informados, pero la configuración residual seguirá generando fallos hasta corregirse o retirarse.
• Capacidad del disco raíz: el 73% de / está ocupado. No es una emergencia, pero debe vigilarse el crecimiento para conservar margen operativo.
• Certificados: los certificados activos tienen entre 31 y 87 días restantes. No hay vencimientos inmediatos; el primero a observar es llm.sherlockhomeless.net.
• Intentos de acceso: se observaron pruebas SSH contra usuarios inexistentes, fallos PAM y conexiones con versiones de protocolo incompatibles. Fail2ban está activo, pero la configuración de PAM para root intenta consultar un segundo factor no configurado y genera ruido operativo.

Acciones recomendadas

1. Restaurar OpenClaw: ejecutar codex-reauth y validar posteriormente una ejecución programada completa, incluida la selección de modelo y el fallback.
2. Analizar la presión de memoria: revisar RSS, swap real por proceso, actividad de paginación y eventos OOM. Priorizar LiteLLM, MySQL/MariaDB, Python, Gunicorn y Celery antes de considerar reinicios o ajustes de límites.
3. Diagnosticar SELinux: inspeccionar el evento indicado por sealert, identificar el contenedor o tarea que solicita nnp_transition y corregir la política o configuración sin desactivar SELinux globalmente.
4. Verificar CrowdSec: comprobar el estado del bouncer, revisar la traza de los pánicos y confirmar que las reglas de firewall se siguen aplicando.
5. Revisar los arranques bajo demanda: correlacionar los primeros intentos fallidos de Memos, Vikunja y OneTimeSecret con los eventos de Sablier, y comprobar específicamente la terminación 137 de memos-proxy.
6. Corregir la configuración ACME: restaurar los registros DNS de opencode.sherlockhomeless.net si el servicio sigue vigente o retirar su router y solicitud de certificado si fue dado de baja.
7. Endurecer y limpiar la autenticación remota: revisar las reglas PAM para usuarios sin segundo factor, confirmar el bloqueo de acceso directo de root y validar la exposición necesaria de SSH y XRDP.

Contexto operativo

El servidor utiliza el kernel 5.14.0-570.58.1.el9_6.x86_64. Los errores XRDP observados se concentran en sesiones y negociaciones de conexión durante un periodo limitado; no hay una comprobación de salud de XRDP que confirme una caída actual. Los intentos contra archivos de configuración de Nextcloud fueron rechazados por el servidor web, lo que indica que los controles de acceso funcionaron según lo esperado.

Los 15 contenedores detenidos no deben interpretarse conjuntamente como 15 incidencias: 11 están identificados como gestionados por Sablier y varios llevan semanas parados. La disponibilidad final confirma que los servicios HTTP supervisados están accesibles, mientras que los contenedores históricos o bajo demanda requieren evaluación individual antes de clasificarlos como fallos.