Informe SRE diario - 2026-08-20

Resumen operativo de almasrv.thehomelesssherlock.com para las últimas 24 horas, con ventana iniciada el 19 de agosto de 2026 a las 06:00 UTC. El informe del servidor se generó el 20 de agosto de 2026 a las 06:00:58 UTC y las comprobaciones de disponibilidad finalizaron a las 06:01:28 UTC.

Estado general

DEGRADED. Los 13 endpoints supervisados están disponibles y no se detectan contenedores no saludables o reiniciándose. Sin embargo, OpenClaw tiene un fallo operativo confirmado: la autorización OAuth de OpenAI Codex está caducada y los intentos de renovación devuelven 401, impidiendo ejecutar las tareas que dependen de esos modelos. Además, Traefik registra fallos repetidos al obtener el token del proveedor ACME, aunque los certificados actuales siguen vigentes.

Indicadores principales

Incidentes críticos

OAuth de OpenClaw Codex caducado

La autorización de OpenAI Codex caducó el 4 de agosto de 2026. A las 06:00 UTC se confirmaron nuevos fallos de renovación con respuesta 401. OpenClaw intentó utilizar los modelos configurados como principal y alternativa, pero ambos candidatos fallaron por autenticación y el proceso terminó sin otra opción de respaldo.

Impacto activo: las tareas programadas y sesiones de OpenClaw que requieren OpenAI Codex no pueden completarse. El impacto está limitado a esa integración y no representa una caída general del servidor ni de los endpoints web supervisados.

Servicios degradados e impacto

Traefik y automatización ACME

Traefik registró repetidamente el error Unable to get token: missing token para el proveedor ACME. También apareció un fallo aislado y cancelado en la comunicación con el servicio de autenticación y varias advertencias al intentar inspeccionar contenedores que ya no existían.

Impacto actual: no se observa interrupción de tráfico. Traefik y el servicio de autenticación respondieron con HTTP 200, y los certificados permanecen vigentes. El fallo afecta a la capacidad de obtener o renovar certificados y puede convertirse en una incidencia futura si no se corrige.

Servicios bajo demanda

Memos y Vikunja necesitaron un segundo intento y respondieron en aproximadamente 8,9 y 8,8 segundos, respectivamente. Ambos terminaron con HTTP 200. Karakeep también estaba disponible.

Estos servicios figuran entre los contenedores administrados por Sablier, por lo que su estado detenido no constituye por sí solo una caída. La latencia observada es compatible con una activación bajo demanda, aunque debe verificarse para descartar reinicios anómalos. Vikunja presentaba previamente un código de salida 2, mientras que Memos y Karakeep habían terminado con código 0.

n8n

El endpoint de salud de n8n respondió con HTTP 200 en 266 ms. Los registros contienen solicitudes bloqueadas dirigidas a recursos internos o archivos de registro, además de errores de parámetros NaN y conexiones WebSocket ausentes.

Impacto actual: no se ha confirmado una degradación del servicio. El bloqueo de las solicitudes potencialmente peligrosas indica que los controles de acceso funcionaron según lo esperado.

Riesgos preventivos

• Swap agotada: los 4 GiB están ocupados. Aunque todavía hay 6 GiB de memoria disponible, la situación puede aumentar la latencia y hacer que futuros picos de memoria terminen en terminaciones por falta de recursos.
• Procesos con uso relevante de swap: las mayores asignaciones corresponden a procesos MySQL, Python, MariaDB, Next.js, Celery y Chromium. Los dos procesos MySQL principales consumen aproximadamente 334 y 332 MiB de swap cada uno.
• Terminaciones recientes con código 137: memos-proxy terminó recientemente con código 137. No hay evidencia suficiente para atribuirlo a falta de memoria, pero debe correlacionarse con la presión de recursos y con la gestión de Sablier.
• Renovación TLS: el certificado más próximo vence en 34 días. No existe una expiración inmediata, pero los errores ACME reducen el margen operativo disponible.
• Eventos SELinux repetitivos: SELinux bloqueó a mandb al solicitar capacidades administrativas y de gestión de recursos. Los mensajes están duplicados y dominan el resumen del journal, lo que puede ocultar señales más relevantes.
• Exposición SSH: continúan las sondas automatizadas, intentos contra usuarios inexistentes y fallos previos a la autenticación. Fail2ban está activo, por lo que estos eventos representan principalmente ruido hostil esperado y no evidencia de acceso exitoso.
• Capacidad de disco: el volumen raíz está al 66 %. No requiere intervención inmediata, pero conviene mantener seguimiento debido al número de contenedores y al crecimiento potencial de imágenes y registros.

Acciones recomendadas

1. Reautorizar OpenClaw Codex de inmediato mediante el procedimiento codex-reauth y ejecutar una prueba controlada de la tarea programada y de la cadena de fallback.
2. Restaurar la autenticación del proveedor ACME en Traefik, comprobar que la credencial requerida esté disponible para el proceso y validar una renovación de prueba sin esperar al vencimiento de los certificados.
3. Investigar la saturación de swap correlacionando consumo por proceso, presión de memoria y actividad de contenedores. Evitar liberar toda la swap de forma indiscriminada; aplicar reinicios escalonados únicamente si están justificados.
4. Revisar las terminaciones recientes de memos-proxy y Vikunja, confirmando si fueron provocadas por Sablier, un despliegue o una condición de recursos.
5. Medir el tiempo de activación bajo demanda de Memos y Vikunja y ajustar los umbrales de salud si los 8–9 segundos son esperados; en caso contrario, revisar dependencias y secuencia de arranque.
6. Analizar las denegaciones SELinux de mandb y corregir el contexto o la configuración que las origina. No desactivar SELinux ni generar una política permisiva sin validar primero la necesidad de esas capacidades.
7. Mantener la vigilancia de SSH y n8n, verificando que los bloqueos continúen funcionando y que las solicitudes rechazadas no hayan producido ejecuciones, accesos internos ni cambios de configuración.

Contexto operativo

• El servidor utiliza el kernel 5.14.0-570.58.1.el9_6.x86_64.
• No hay contenedores marcados como no saludables ni en ciclo de reinicio.
• Diez de los catorce contenedores detenidos están administrados por Sablier. Su estado no debe interpretarse como indisponibilidad sin una prueba de endpoint o evidencia adicional.
• Paperless procesó correctamente sus tareas programadas y de clasificación durante la ventana analizada.
• Nextcloud y OnlyOffice superaron sus comprobaciones con HTTP 200.
• Las advertencias de Traefik sobre contenedores inexistentes son compatibles con cambios rápidos del inventario Docker y no muestran por sí mismas impacto en el enrutamiento.
• Los mensajes SSH de usuarios inexistentes, conexiones reiniciadas y tiempos de espera corresponden a actividad externa no autenticada. No se observan datos que confirmen una intrusión.