Informe SRE diario - 2026-08-14

Resumen operativo de almasrv.thehomelesssherlock.com para las últimas 24 horas, generado el 14 de agosto de 2026 a las 06:01 UTC. El servidor ejecuta el kernel 5.14.0-570.58.1.el9_6.x86_64.

Estado general

DEGRADED. Los 13 endpoints monitorizados están disponibles y no hay contenedores en estado unhealthy o reiniciándose. Sin embargo, existen dos fallos operativos confirmados: la autenticación OAuth de OpenClaw está vencida y provoca errores en tareas programadas, y el bouncer de firewall de CrowdSec ha fallado repetidamente. Además, la swap está completamente utilizada, lo que incrementa el riesgo de degradación de rendimiento.

Indicadores principales

Incidentes críticos

OAuth de OpenClaw vencido

La credencial OAuth de OpenClaw expiró el 4 de agosto de 2026. Los registros confirman respuestas de autenticación 401, fallos de renovación y agotamiento de las alternativas de modelo durante una tarea programada. El impacto activo está limitado a las operaciones de OpenClaw que dependen de OpenAI Codex; no afecta a la disponibilidad HTTP general del servidor.

Bouncer de firewall de CrowdSec inoperativo

El servicio crowdsec-firewall-bouncer terminó repetidamente con código de error durante la ventana analizada. Los registros muestran fallos al gestionar cadenas de iptables inexistentes. Esto confirma una degradación de esa capa de aplicación automática de bloqueos. Fail2ban continúa activo, pero no sustituye completamente la función del bouncer de CrowdSec.

Servicios degradados e impacto

• OpenClaw: las tareas que requieren OpenAI Codex no pueden autenticarse y finalizan con error. Se requiere reautenticación.
• CrowdSec firewall bouncer: no se puede confirmar la aplicación de decisiones de CrowdSec en el firewall mientras el servicio permanezca fallando.
• Servicios bajo demanda: Memos, Vikunja y One-Time Secret necesitaron un segundo intento y registraron latencias observadas de aproximadamente 8,7 a 9 segundos. Finalmente respondieron con HTTP 200, por lo que no se consideran caídos. El comportamiento es compatible con activación bajo demanda, aunque debe verificarse.

Riesgos preventivos

• Swap agotada: los 4 GiB están ocupados. Los principales consumidores observados incluyen procesos MySQL, Python, MariaDB, Node/Next.js, Chromium y Celery. Aunque quedan 6,8 GiB de memoria disponible, la swap llena puede prolongar latencias y evidencia presión de memoria previa o páginas inactivas no recuperadas.
• Volcado de núcleo de Node: un proceso Node produjo un coredump durante la ventana. No hay evidencia suficiente de impacto sostenido, pero debe asociarse con el contenedor o servicio responsable.
• Traefik y ACME: se registró un error aislado por ausencia de token al solicitar una operación ACME. Los certificados activos conservan entre 31 y 88 días de vigencia, por lo que no existe una expiración inmediata, pero debe comprobarse la siguiente renovación automática.
• Certificados próximos al umbral preventivo: www.thehomelesssherlock.com y thehomelesssherlock.com tienen 31 y 32 días restantes respectivamente.
• SELinux: se generó una ráfaga repetitiva de denegaciones para mandb sobre capacidades administrativas y de recursos. No se ha demostrado impacto sobre servicios productivos, pero el volumen introduce ruido y puede ocultar eventos relevantes.
• Intentos SSH automatizados: continúan los intentos con usuarios inexistentes, fallos PAM y conexiones interrumpidas. Fail2ban está activo, por lo que estos eventos constituyen principalmente actividad hostil bloqueada y ruido operativo, no evidencia de compromiso.
• Latencia de arranque bajo demanda: los segundos intentos exitosos de Memos, Vikunja y One-Time Secret podrían consumir una parte significativa del presupuesto de latencia si son servicios interactivos.

Acciones recomendadas

1. Reautenticar OpenClaw de inmediato mediante el procedimiento codex-reauth y ejecutar una tarea de validación para confirmar la renovación y el acceso al modelo.
2. Restaurar el bouncer de CrowdSec, revisando la compatibilidad y el estado de las reglas de iptables; confirmar después que el servicio permanece activo y que una decisión de prueba se aplica correctamente.
3. Investigar la presión de memoria correlacionando RSS, swap por proceso, actividad de paginación y límites de contenedores. No vaciar la swap de forma automática sin comprobar primero el margen real de RAM.
4. Identificar el proceso Node que generó el coredump, revisar sus registros previos al fallo y comprobar si coincide con algún contenedor detenido mediante señal de terminación forzada.
5. Validar la renovación ACME de Traefik antes de que los certificados más próximos alcancen el umbral de 30 días.
6. Revisar las denegaciones SELinux de mandb con los identificadores de alerta registrados y corregir la causa sin desactivar SELinux ni aplicar políticas permisivas generales.
7. Verificar los servicios bajo demanda con una prueba en frío y otra en caliente para confirmar que los segundos intentos y la latencia cercana a nueve segundos corresponden al funcionamiento esperado de Sablier.

Contexto operativo

Los contenedores detenidos administrados por Sablier no se consideran incidencias por sí mismos. Memos, Vikunja, Karakeep y One-Time Secret aparecen detenidos en el inventario, pero sus endpoints respondieron correctamente durante las comprobaciones; esto indica disponibilidad bajo demanda, aunque One-Time Secret y Vikunja registraron previamente salidas no limpias que conviene revisar.

El acceso no autorizado a un archivo de configuración de Nextcloud fue rechazado por la configuración del servidor web. Este evento representa un control de acceso funcionando correctamente, no una exposición confirmada. Las tareas observadas de Paperless finalizaron satisfactoriamente y no muestran degradación.

El almacenamiento mantiene margen operativo: la partición raíz está al 65 %, /opt al 37 % y las particiones de arranque no presentan presión. No se observaron contenedores unhealthy ni ciclos de reinicio en el momento de generación del informe.