Informe SRE diario - 2026-08-02

Resumen operativo de almasrv.thehomelesssherlock.com para las últimas 24 horas, generado el 2 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 y no se observan contenedores unhealthy o reiniciándose. Sin embargo, se confirmó un fallo operativo repetido de crowdsec-firewall-bouncer.service sin evidencia de recuperación en el resumen. El impacto actual se limita a una reducción de la defensa en profundidad; no se ha detectado indisponibilidad de aplicaciones.

Indicadores principales

Incidentes críticos

No se identificaron incidentes críticos con impacto activo. Todos los endpoints comprobados respondieron con HTTP 200, y Docker no reportó contenedores unhealthy ni ciclos de reinicio.

Los errores de autenticación SSH corresponden principalmente a usuarios inexistentes, códigos inválidos, incompatibilidades de protocolo y sondeos externos bloqueados. No hay evidencia en los datos de acceso exitoso o compromiso.

Servicios degradados e impacto

• CrowdSec firewall bouncer: registró 13 fallos con resultado exit-code durante la ventana. No consta una recuperación posterior. Impacto: posible pérdida parcial de la aplicación automática de decisiones de CrowdSec en el firewall. Fail2ban continúa activo, por lo que existe protección SSH adicional, pero la defensa en profundidad está reducida.
• Comprobaciones con reintento: Memos, Vikunja y One-Time Secret necesitaron dos intentos y completaron la comprobación aproximadamente en 8,9 segundos, incluyendo la espera entre reintentos. El intento satisfactorio fue rápido y devolvió HTTP 200. Impacto: no hay caída activa, aunque existe una señal de disponibilidad intermitente que conviene correlacionar.

Riesgos preventivos

• Swap agotada: se utilizan prácticamente los 4 GiB disponibles. Aunque quedan 7,5 GiB de memoria utilizable y no se observa impacto inmediato, esta condición puede aumentar la latencia y reducir el margen ante picos de carga. Entre los principales consumidores de swap aparecen procesos Python, MySQL/MariaDB, LiteLLM, Celery y Chromium.
• OAuth de OpenClaw Codex: la autorización vence el 4 de agosto de 2026 a las 10:06 UTC, con unas 52 horas restantes. Todavía no es un incidente, pero requiere renovación próxima.
• Patrón de panic sin atribución: el digest contabiliza 13 apariciones de panic: runtime error: index out of range. No se proporciona el servicio de origen ni existe correlación con endpoints caídos, por lo que debe tratarse como una anomalía pendiente de atribución.
• Configuración PAM/SSH: se registraron fallos del control de clave pública y avisos de Google Authenticator, incluidos intentos contra cuentas inexistentes y una cuenta sin secreto configurado. El tráfico parece compatible con sondeos, pero conviene verificar que la política PAM corresponde al diseño esperado.
• Contenedores detenidos: 11 de los 15 contenedores no ejecutándose están gestionados por Sablier y no deben considerarse caídos por ese hecho. Los cuatro restantes requieren reconciliación con su estado deseado, especialmente los terminados con códigos 137 o 143.
• Renovación TLS: los certificados más próximos vencen en 35 días. No existe riesgo inmediato, pero debe confirmarse que la renovación automática funciona para los 47 dominios activos supervisados.
• Errores de OpenClaw: el gateway registró lecturas fallidas por archivos ausentes y una operación rechazada por aislamiento del sandbox. No se ha observado impacto externo, pero puede afectar tareas internas que dependan de esos recursos.

Acciones recomendadas

1. Diagnosticar crowdsec-firewall-bouncer.service, validar su estado actual y restaurar la aplicación de decisiones de CrowdSec. Confirmar después que no se repiten los fallos.
2. Renovar la autorización OAuth de OpenClaw Codex antes del 4 de agosto de 2026 a las 10:06 UTC y comprobar el flujo dependiente tras la renovación.
3. Investigar la presión de swap con métricas temporales y consumo por proceso; revisar especialmente Python, MySQL/MariaDB, LiteLLM, Celery y Chromium antes de decidir entre reinicios controlados, ajuste de memoria o ampliación.
4. Atribuir el patrón de 13 errores panic: runtime error: index out of range a un servicio o contenedor concreto y comprobar si provoca reinicios, pérdida de trabajos o degradación silenciosa.
5. Correlacionar los primeros intentos fallidos de Memos, Vikunja y One-Time Secret con eventos de Sablier, arranque bajo demanda y logs de Traefik para confirmar si la latencia es esperada.
6. Revisar los cuatro contenedores detenidos fuera de la gestión de Sablier y documentar si su estado es intencional; investigar específicamente las terminaciones por códigos 137 y 143.
7. Validar la configuración PAM, el control de claves públicas y Google Authenticator, además de ejecutar una prueba de renovación TLS antes de que los certificados entren en una ventana inferior a 30 días.

Contexto operativo

El servidor utiliza el kernel 5.14.0-570.58.1.el9_6.x86_64. La capacidad de disco mantiene margen suficiente: la raíz está al 64%, /boot al 44% y /opt al 34%.

Traefik registró un intento aislado de inspeccionar un contenedor que ya no existía, compatible con una condición transitoria durante el ciclo de vida de Docker. Paperless completó correctamente su tarea de correo, y no se destacaron errores en n8n o Nextcloud.

Los contenedores detenidos bajo Sablier se consideran servicios bajo demanda, no incidencias, mientras no exista una comprobación funcional fallida. En esta ventana, Karakeep, Memos, Vikunja y One-Time Secret respondieron correctamente en sus endpoints supervisados.