Informe SRE diario - 2026-09-06

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

Estado general

CRITICAL. Los 13 endpoints supervisados están disponibles y no hay contenedores unhealthy o reiniciándose, pero la integración OpenClaw con OpenAI Codex presenta un fallo operativo confirmado: la autorización OAuth está caducada y los intentos de renovación reciben HTTP 401. Las tareas programadas afectadas agotaron también el fallback configurado, por lo que no pudieron ejecutarse con los modelos solicitados.

Indicadores principales

Incidentes críticos

Autorización OAuth de OpenClaw caducada

La credencial OAuth de OpenAI Codex caducó el 4 de agosto de 2026. A las 06:00 UTC se registraron respuestas HTTP 401 durante la renovación, seguidas de errores en las tareas programadas de OpenClaw. El intento con el modelo principal falló por autenticación, el fallback alternativo presentó el mismo problema y no quedó otro candidato disponible.

Impacto activo: las automatizaciones de OpenClaw que dependen de OpenAI Codex no pueden completar su ejecución. La acción indicada por el sistema es renovar la autorización mediante codex-reauth y verificar después una ejecución real.

Servicios degradados e impacto

• OpenClaw: degradación confirmada de las tareas que requieren Codex. El gateway está generando errores de autenticación y agotando el fallback.
• Vikunja: respondió con HTTP 200, pero necesitó dos intentos y la comprobación acumuló 8,81 segundos. No hay caída activa confirmada.
• One-Time Secret: respondió con HTTP 200 tras dos intentos y 8,89 segundos acumulados. El contenedor está gestionado por Sablier, por lo que su estado detenido no constituye por sí solo una incidencia.
• Traefik y Authentik: se registró una cancelación puntual en una llamada de ForwardAuth. Las comprobaciones posteriores de Traefik y Authentik devolvieron HTTP 200, sin evidencia de impacto sostenido.
• Proceso Node.js: se produjo un volcado de memoria a las 19:44 UTC. Los datos no identifican el servicio asociado y ningún endpoint supervisado aparece caído, por lo que el impacto permanece sin confirmar.

Riesgos preventivos

• Swap agotada: los 4 GiB están ocupados. Aunque quedan 7,8 GiB de memoria disponible y no se documenta una caída por memoria, esta condición reduce el margen ante picos de carga y puede aumentar la latencia. MySQL/MariaDB, procesos Python, Gunicorn, Celery y Ruby figuran entre los consumidores de swap.
• Disco raíz al 73%: quedan 56 GiB disponibles. No existe agotamiento inmediato, pero conviene revisar la tendencia y el crecimiento de imágenes, logs y datos persistentes.
• Denegaciones SELinux recurrentes: Docker genera eventos repetidos relacionados con transiciones de proceso. No se ha confirmado una interrupción, pero la periodicidad indica que debe identificarse el contenedor o la política involucrada.
• Ruido y presión sobre SSH: se observan intentos con usuarios inexistentes, errores de intercambio de claves y fallos PAM. Fail2ban está activo y aplicando bloqueos; estos registros no implican por sí solos una intrusión.
• Configuración PAM/MFA: aparecen intentos de autenticación para root sin un secreto MFA configurado, además de fallos del comprobador de claves públicas. Debe confirmarse que el flujo resultante coincide con la política de acceso prevista.
• Certificados próximos al umbral de renovación: los certificados de Grafana, Wiki, Pastebin, OpenGist y One-Time Secret tienen 31 días restantes. No están caducados, pero ya requieren seguimiento de la renovación automática.
• Contenedores detenidos fuera de Sablier: changedetection-browser, stirling-pdf e it-tools figuran detenidos. No hay evidencia de impacto en los endpoints supervisados, pero debe verificarse que su estado sea intencionado.

Acciones recomendadas

1. Ejecutar codex-reauth, confirmar que la renovación OAuth deja de devolver HTTP 401 y lanzar una tarea controlada de OpenClaw para validar tanto el modelo principal como el fallback.
2. Investigar la ocupación completa de swap, correlacionándola con MySQL/MariaDB, Python, Gunicorn, Celery y Ruby. Revisar tendencia de memoria, fallos de asignación y latencia antes de realizar reinicios o liberar swap.
3. Analizar las denegaciones SELinux mediante los identificadores de alerta registrados, localizar el contenedor que solicita las transiciones y corregir contexto o política sin desactivar SELinux globalmente.
4. Inspeccionar el volcado del proceso Node.js y asociarlo con su contenedor o servicio para determinar si fue un fallo aislado, una terminación por recursos o un defecto reproducible.
5. Auditar la cadena SSH/PAM: política para root, validación de claves públicas y comportamiento del módulo MFA ante usuarios inexistentes. Mantener Fail2ban activo y verificar sus umbrales.
6. Confirmar que los tres contenedores detenidos fuera de Sablier están fuera de servicio de forma intencionada; revisar por separado los estados de salida 1, 2, 137 y 143 de los servicios bajo demanda sin clasificarlos automáticamente como caídas.
7. Configurar seguimiento para la latencia con reintentos de Vikunja y One-Time Secret, el uso del disco raíz y la renovación de los certificados que alcanzan el umbral de 31 días.

Contexto operativo

El servidor utiliza el kernel 5.14.0-570.58.1.el9_6.x86_64. La infraestructura web supervisada permanece accesible: todos los endpoints devolvieron HTTP 200, incluidos Nextcloud, Paperless, OnlyOffice, n8n, Memos, Karakeep, Beszel, Traefik y Authentik. Las redirecciones hacia el flujo de autenticación son coherentes con servicios protegidos y no se consideran fallos.

Los 13 contenedores detenidos no deben interpretarse en conjunto como una interrupción. Diez aparecen gestionados por Sablier y pueden permanecer apagados hasta recibir demanda. Los estados históricos de hace semanas tampoco representan impacto activo sin una comprobación funcional fallida. Paperless completó correctamente sus tareas periódicas de correo y no encontró documentos nuevos.