Informe SRE diario - 2026-09-03

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

Estado general

DEGRADED. El servidor y los 13 endpoints supervisados están disponibles, pero existe un fallo operativo confirmado en OpenClaw: la credencial OAuth de OpenAI Codex está caducada y los intentos de renovación devuelven HTTP 401. La tarea programada afectada agotó también su alternativa de modelo, por lo que no pudo completarse.

No se observa una caída general de infraestructura: Docker mantiene 86 contenedores en ejecución, sin contenedores marcados como no saludables o reiniciándose, y todas las comprobaciones HTTP terminaron correctamente.

Indicadores principales

Incidentes críticos

OAuth de OpenClaw caducado

La supervisión de OpenClaw registra estado CRITICAL para la integración OpenAI Codex. La credencial expiró el 4 de agosto de 2026 a las 10:06 UTC. A las 06:00 UTC del periodo actual, la renovación falló con HTTP 401.

El fallo afectó una tarea programada de OpenClaw: el modelo solicitado no pudo autenticarse y el modelo alternativo falló por el mismo motivo, quedando sin otra opción de ejecución. El impacto confirmado está limitado a los trabajos que dependan de esta autenticación; no hay evidencia de indisponibilidad general del host ni de los servicios web supervisados.

Servicios degradados e impacto

• OpenClaw: degradación activa. Las tareas que requieren OpenAI Codex pueden fallar hasta completar la reautenticación.
• OneTimeSecret: el endpoint respondió HTTP 200, pero necesitó dos intentos y la comprobación acumuló 8.845 segundos. Se considera un episodio transitorio, no una caída activa.
• Traefik y Authentik: se registraron dos cancelaciones puntuales en llamadas de autenticación delegada. Las comprobaciones posteriores de Traefik y Authentik finalizaron correctamente, por lo que no se confirma impacto activo.
• Nextcloud: permaneció disponible. Los rechazos de solicitudes dirigidas a archivos de configuración y recursos administrativos corresponden a controles de acceso funcionando frente a sondeos externos, no a fallos del servicio.

Los contenedores detenidos administrados por Sablier no se consideran caídos sin evidencia adicional. Además, los endpoints de Memos y Karakeep respondieron correctamente pese a figurar como detenidos en la instantánea, comportamiento compatible con activación bajo demanda.

Riesgos preventivos

• Swap completamente ocupada: quedan solo 16 MiB libres. Aunque el sistema conserva 9 GiB de memoria disponible y no se documenta presión activa, esta situación reduce el margen ante picos de consumo. Los mayores consumidores de swap incluyen procesos de LiteLLM, MySQL/MariaDB, Python, Gunicorn y Celery.
• Uso del disco raíz: el 74 % está ocupado. No requiere intervención de emergencia, pero conviene revisar el crecimiento antes de alcanzar umbrales operativos.
• Denegaciones SELinux recurrentes: Docker genera de forma aproximadamente horaria denegaciones relacionadas con nnp_transition. También se observaron denegaciones de capacidades para mandb. No se ha demostrado impacto funcional, pero la recurrencia merece análisis.
• Renovación ACME inconsistente: Traefik intentó renovar un certificado para opencode.sherlockhomeless.net, pero el dominio no tenía registros A ni AAAA válidos. Puede tratarse de una configuración o un router obsoleto.
• Certificados próximos a la ventana de renovación: llm.sherlockhomeless.net vence en 32 días; Grafana, Wiki, Pastebin, OpenGist y OneTimeSecret tienen 34 días restantes. No hay certificados vencidos entre los 50 dominios activos analizados.
• Contenedores no administrados por Sablier: cuatro aparecen detenidos. memos-proxy terminó con código 137 aproximadamente una hora antes del informe; los otros tres llevan varias semanas detenidos. No se confirma impacto actual, pero debe validarse si su estado es intencionado.
• Exposición SSH: continúan los intentos automatizados contra usuarios inexistentes o privilegiados. Fail2ban está activo y aplicando bloqueos, aunque los registros también muestran intentos que alcanzan la cadena PAM antes de ser rechazados.

Acciones recomendadas

1. Restaurar OpenClaw: ejecutar el procedimiento codex-reauth, validar la renovación OAuth y repetir la tarea programada que falló.
2. Investigar la ocupación de swap: correlacionar los principales consumidores con su memoria residente, revisar si la swap contiene páginas antiguas tras picos previos y evitar liberarla de forma agresiva sin confirmar margen suficiente.
3. Analizar las denegaciones SELinux: revisar los eventos completos asociados a Docker y mandb, identificar el proceso o contenedor que dispara el patrón horario y corregir etiquetas o políticas sin desactivar SELinux globalmente.
4. Corregir la configuración ACME: confirmar si opencode.sherlockhomeless.net debe existir; restaurar sus registros DNS o eliminar del proxy la referencia obsoleta.
5. Revisar contenedores detenidos fuera de Sablier: priorizar memos-proxy por su salida 137 y confirmar si Changedetection Browser, Stirling PDF e IT-Tools deben permanecer apagados.
6. Verificar renovaciones TLS: comprobar la automatización para los certificados con 32–34 días restantes y configurar alerta antes de entrar en una ventana crítica.
7. Auditar la cadena SSH/PAM: confirmar que el comportamiento para usuarios privilegiados es el previsto, mantener Fail2ban activo y revisar que no existan accesos legítimos afectados por la configuración del segundo factor.

Contexto operativo

• Kernel en ejecución: 5.14.0-570.58.1.el9_6.x86_64.
• Los 13 endpoints supervisados respondieron con HTTP 200.
• Las respuestas más rápidas fueron Beszel, Vikunja y n8n, con 62 ms, 64 ms y 87 ms respectivamente.
• La mayor latencia normal en el primer intento fue Memos, con 693 ms. OneTimeSecret requirió un segundo intento.
• Paperless procesó correctamente sus tareas de correo y entrenamiento del clasificador.
• Los avisos de Traefik sobre contenedores inexistentes son compatibles con cambios rápidos del ciclo de vida de Docker y no demuestran por sí solos una interrupción.
• Se registró una advertencia aislada del reloj del kernel por un intervalo de lectura prolongado, sin repetición ni impacto confirmado.