Informe SRE diario - 2026-09-02
Resumen operativo de almasrv.thehomelesssherlock.com para las 24 horas finalizadas el 2 de septiembre de 2026 a las 06:00:55 UTC. El resumen del servidor se generó a las 06:00:58 UTC y la comprobación final de endpoints a las 06:01:28 UTC.
Estado general
DEGRADED. Los 13 endpoints supervisados están disponibles y responden con HTTP 200, sin contenedores marcados como no saludables o en reinicio. Sin embargo, existe un fallo operativo confirmado en OpenClaw: la credencial OAuth de OpenAI Codex está caducada, su renovación devuelve HTTP 401 y las tareas programadas no disponen de un modelo alternativo funcional. También se registraron fallos repetidos en los servicios de alertas operativas y del bouncer de CrowdSec.
Indicadores principales
| Indicador | Valor | Evaluación |
|---|---|---|
| Disponibilidad HTTP | 13 de 13 endpoints disponibles | OK |
| Uptime | 13 horas y 44 minutos | Reinicio reciente; sin caída observada |
| Carga | 3.00 / 3.19 / 3.35 |
Sin evidencia de saturación con los datos disponibles |
| Memoria | 13 GiB usados de 22 GiB; 9,1 GiB disponibles | OK |
| Swap | 3,5 GiB usados de 4 GiB | Riesgo preventivo |
| Disco raíz | 146 GiB usados de 199 GiB; 74% | Vigilar crecimiento |
Volumen /opt |
21 GiB usados de 50 GiB; 43% | OK |
| Docker | 85 activos, 0 no saludables, 0 reiniciando, 15 detenidos | Operación principal estable |
| Fail2ban SSH | Activo; 22 bloqueos actuales y 25 acumulados | Protección activa |
| TLS más próximo | llm.sherlockhomeless.net, 33 días restantes |
Renovación preventiva |
Incidentes críticos
OAuth de OpenClaw/OpenAI Codex caducado
La credencial OAuth figura como caducada desde el 4 de agosto de 2026. A las 06:00 UTC, los intentos de renovación devolvieron HTTP 401 y fallaron tanto el modelo solicitado como el candidato de respaldo. El impacto activo confirmado es la interrupción de las tareas programadas de OpenClaw que dependen de OpenAI Codex. La acción requerida es una nueva autenticación mediante codex-reauth.
Servicios degradados e impacto
- Alertas operativas:
recarga-alert-check.servicefalló seis veces. Esto reduce la confianza en la detección automática de incidencias de Recarga, aunque no demuestra por sí mismo que el servicio de negocio esté caído. - CrowdSec:
crowdsec-firewall-bouncer.serviceregistró cinco fallos. Fail2ban continúa activo, pero una capa adicional de aplicación de bloqueos puede estar degradada. - Correo de Authentik: el relay rechazó repetidamente mensajes dirigidos a dos destinatarios configurados con
554 5.7.1 Access denied. También falta la configuración del complemento SASL XOAUTH2. El impacto probable se limita a notificaciones o correos de autenticación afectados por esas rutas. - Latencia intermitente: Vikunja y One-Time Secret necesitaron dos intentos y completaron la comprobación en aproximadamente 8,7 y 9 segundos, respectivamente. Ambos terminaron disponibles con HTTP 200, por lo que no se consideran caídos.
Los errores de Traefik sobre la ausencia temporal del middleware ths-authentik@docker afectaron a varios routers durante la ventana de logs. No hay evidencia de impacto activo al cierre: las comprobaciones de Traefik, Authentik y los servicios protegidos finalizaron correctamente, incluidas las redirecciones hacia el flujo de autenticación.
Riesgos preventivos
- Presión de swap: se utilizan 3,5 GiB de los 4 GiB disponibles. La memoria disponible sigue siendo de 9,1 GiB, por lo que no se confirma agotamiento actual, pero el uso elevado de swap puede introducir latencia. Los principales consumidores incluyen LiteLLM, procesos MySQL/MariaDB, Gunicorn, Document Server, Celery y Python.
- SELinux: se repiten denegaciones de
nnp_transitionpara Docker con una periodicidad aproximada de una hora. También aparecen denegaciones de capacidades paramandb. Debe determinarse si bloquean alguna operación real antes de modificar políticas. - Capacidad del disco raíz: el sistema de archivos principal está al 74%. Quedan 54 GiB, por lo que no existe una emergencia inmediata, pero conviene establecer alertas y revisar la tendencia.
- Certificados TLS: todos los certificados listados siguen vigentes. El vencimiento más próximo está a 33 días, seguido por varios certificados a 35 y 39 días; debe confirmarse que la renovación automática funciona.
- Sondeos SSH: hubo numerosos intentos contra usuarios inexistentes, principalmente
rootyadmin. Fail2ban está activo y aplicando bloqueos; estos registros no indican por sí solos una intrusión. - n8n: se observó un fallo temporal de resolución DNS hacia su base de datos y una advertencia por ausencia de Python 3 para el task runner interno. El endpoint
/healthzresponde correctamente, por lo que no hay impacto activo confirmado.
Acciones recomendadas
- Ejecutar
codex-reauth, validar la renovación OAuth y repetir manualmente una tarea programada de OpenClaw para confirmar la recuperación completa. - Revisar los logs y el estado de
recarga-alert-check.serviceycrowdsec-firewall-bouncer.service; restaurarlos y comprobar que permanecen activos tras varios ciclos. - Corregir los destinatarios o permisos rechazados por el relay de correo y confirmar si SASL XOAUTH2 debe estar habilitado; si es necesario, proporcionar su configuración y realizar una prueba de entrega.
- Analizar las denegaciones SELinux identificadas para Docker y
mandbcon las herramientas de diagnóstico del sistema. No deshabilitar SELinux ni generar reglas permisivas sin validar primero la operación bloqueada. - Investigar el uso elevado de swap mediante métricas de memoria, fallos de página y presión por proceso; revisar especialmente LiteLLM, las bases de datos y los workers antes de reiniciar o ajustar límites.
- Comprobar que las paradas de contenedores gestionados por Sablier son intencionadas y revisar por separado las salidas recientes de
memos-proxy,vikunjay otros contenedores con códigos distintos de cero. - Verificar la renovación automática de TLS antes de que el certificado más próximo alcance 21 días y configurar alertas de capacidad para el disco raíz y de latencia para endpoints que requieran reintentos.
Contexto operativo
El host utiliza el kernel 5.14.0-570.58.1.el9_6.x86_64. Los 15 contenedores detenidos no deben interpretarse colectivamente como una caída: 11 están gestionados por Sablier y varios endpoints asociados, como Memos, Vikunja, Karakeep y One-Time Secret, respondieron correctamente durante la verificación final.
Los accesos no autorizados contra Nextcloud fueron rechazados o devolvieron HTTP 404, sin evidencia de compromiso. Los fallos iniciales de espera de base de datos en Paperless fueron transitorios; sus tareas posteriores finalizaron correctamente y el servicio respondió con HTTP 200. Las advertencias de Traefik al inspeccionar contenedores ya eliminados son compatibles con cambios dinámicos del ciclo de vida de Docker y no prueban una indisponibilidad actual.
Comments ()