Informe SRE diario - 2026-08-09

Resumen operativo de almasrv.thehomelesssherlock.com para las últimas 24 horas, generado el 9 de agosto de 2026 a las 06:00 UTC. Las comprobaciones de disponibilidad finalizaron a las 06:01 UTC.

Estado general

DEGRADED. Los 13 endpoints supervisados están disponibles, pero la integración OAuth de OpenClaw con OpenAI Codex está expirada y los intentos de renovación reciben respuestas 401. Esto provoca fallos confirmados en tareas programadas que requieren esos modelos. No se observa una caída general de la plataforma.

Indicadores principales

Incidentes críticos

OAuth de OpenClaw para OpenAI Codex expirado

La credencial OAuth expiró el 4 de agosto de 2026. A las 06:00 UTC se confirmaron errores 401 durante su renovación. La tarea programada intentó usar los modelos configurados de forma sucesiva, pero ambos candidatos fallaron por autenticación y no quedó otro fallback disponible.

Impacto activo: las ejecuciones de OpenClaw que dependen de OpenAI Codex pueden fallar. Los datos no muestran impacto sobre los demás servicios web ni sobre la disponibilidad general del host.

Servicios degradados e impacto

• Memos: respondió con HTTP 200 en el segundo intento, con una latencia observada de 8.663 ms incluyendo el ciclo de reintento.
• Vikunja: respondió con HTTP 200 en el segundo intento, con una latencia observada de 8.692 ms incluyendo el ciclo de reintento.
• One-Time Secret: respondió con HTTP 200 en el segundo intento, con una latencia observada de 9.066 ms incluyendo el ciclo de reintento.

Estas comprobaciones indican disponibilidad recuperada o activación bajo demanda, no una caída vigente. Memos, Vikunja y One-Time Secret figuran además entre los servicios administrados por Sablier; por tanto, su estado detenido en la instantánea de Docker no constituye por sí solo un incidente.

Traefik registró una advertencia aislada al intentar inspeccionar un contenedor que ya no existía. El endpoint de Traefik respondió con HTTP 200 y no se ha confirmado impacto operativo.

Riesgos preventivos

• Swap agotada: los 4 GiB están ocupados. Aunque quedan 7,6 GiB de memoria disponible y no se ha confirmado presión activa, esta condición puede incrementar la latencia si reaparecen páginas intercambiadas o aumenta la demanda.
• Consumo de swap distribuido: los principales consumidores incluyen procesos MySQL, Python, MariaDB, Celery, Chromium y aplicaciones Node.js. Debe determinarse si corresponde a procesos longevos, carga histórica o presión sostenida.
• Renovación TLS: el certificado con menor margen tiene 31 días restantes. No existe expiración inmediata, pero conviene verificar que la renovación automática funcione antes de entrar en una ventana más estrecha.
• Contenedores no activos: hay 15 contenedores detenidos. La mayoría están administrados bajo demanda o terminaron correctamente, pero existen salidas con códigos 1, 2, 137 y 143 que deben correlacionarse con despliegues, suspensión intencional y límites de recursos.
• Paradas forzadas: un contenedor no completó varias detenciones dentro del plazo de 10 segundos y Docker tuvo que forzar su salida. No hay reinicios activos, pero el patrón puede señalar un cierre deficiente.
• Ruido SSH: continúan los sondeos automatizados, reinicios de negociación y accesos contra usuarios inválidos. Fail2ban está activo y ha aplicado 657 bloqueos acumulados; no hay evidencia aportada de acceso exitoso.

Acciones recomendadas

1. Ejecutar la reautenticación de OpenClaw mediante codex-reauth y validar después una tarea programada completa.
2. Confirmar que el fallback de modelos no dependa exclusivamente de credenciales del mismo proveedor o del mismo flujo OAuth.
3. Revisar presión de memoria, actividad de swap y antigüedad de los procesos con mayor consumo antes de decidir si reciclar servicios o limpiar swap de forma controlada.
4. Correlacionar los segundos intentos de Memos, Vikunja y One-Time Secret con eventos de activación de Sablier; ajustar tiempos de espera si la latencia corresponde al arranque esperado.
5. Identificar el contenedor con detenciones forzadas repetidas y revisar su manejo de SIGTERM y su tiempo de gracia.
6. Verificar la renovación automática de los certificados que vencen en 31 y 32 días, sin esperar a la ventana crítica.
7. Revisar la configuración SSH y MFA para asegurar que los mensajes asociados a usuarios inválidos sean ruido esperado y no oculten errores en cuentas administrativas legítimas.

Contexto operativo

El servidor ejecuta el kernel 5.14.0-570.58.1.el9_6.x86_64 y mantiene más de cuatro semanas de uptime. No hay contenedores marcados como unhealthy ni en reinicio. Los servicios principales comprobados —Traefik, autenticación, n8n, Nextcloud, Paperless, OnlyOffice, Karakeep, RSS, Dozzle y Beszel— respondieron correctamente en el primer intento.

Los errores predominantes del journal corresponden a conexiones SSH interrumpidas antes de completar la autenticación y a intentos contra usuarios inválidos. También apareció una advertencia aislada del extractor de metadatos y un fallo puntual de consulta DNS externa. Con los datos disponibles, estos eventos se clasifican como ruido operativo o señales para seguimiento, no como interrupciones activas.