Informe SRE diario - 2026-08-29

Resumen operativo de almasrv.thehomelesssherlock.com para las 24 horas anteriores al 29 de agosto de 2026 a las 06:00 UTC. Comprobaciones de salud completadas a las 06:01 UTC.

Estado general

DEGRADED: los 13 endpoints supervisados están disponibles y no hay contenedores en estado unhealthy o reiniciándose. Sin embargo, OpenClaw presenta un fallo operativo confirmado: la autenticación OAuth de OpenAI Codex está caducada, la renovación devuelve HTTP 401 y una tarea programada agotó sus alternativas de modelo.

Indicadores principales

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, OpenClaw recibió respuestas HTTP 401 al intentar renovarla. La tarea programada falló primero con el modelo solicitado, intentó una alternativa y terminó sin más candidatos disponibles.

Impacto activo: las tareas de OpenClaw que dependen de OpenAI Codex no pueden ejecutarse correctamente. No se observa impacto sobre los 13 servicios web incluidos en las comprobaciones de disponibilidad.

Servicios degradados e impacto

• OpenClaw: degradado por fallo de autenticación confirmado. Las tareas programadas dependientes de Codex están afectadas.
• Memos: respondió correctamente en el segundo intento, con una latencia agregada de 8,8 segundos. El endpoint quedó disponible con HTTP 200.
• Vikunja: respondió correctamente en el segundo intento, con una latencia agregada de 8,8 segundos. El endpoint quedó disponible con HTTP 200.
• OneTimeSecret: respondió correctamente en el segundo intento, con una latencia agregada de 9,0 segundos. El endpoint quedó disponible con HTTP 200.

Las respuestas lentas de Memos, Vikunja y OneTimeSecret son compatibles con una activación bajo demanda, pero los datos disponibles no permiten confirmar la causa. No se consideran caídas porque las comprobaciones finalizaron satisfactoriamente.

Riesgos preventivos

• Swap agotada: los 4 GiB están ocupados. Los principales consumidores observados incluyen procesos MySQL/MariaDB, Ruby, Gunicorn y Python. Aunque permanecen 7,6 GiB de memoria disponible y no hay impacto confirmado, esta situación aumenta el riesgo de latencia y presión de memoria.
• Renovación ACME de opencode.sherlockhomeless.net: Traefik no pudo renovar el certificado porque DNS no devolvió registros A ni AAAA válidos. No se ha demostrado una interrupción activa, pero la configuración debe corregirse o retirarse si el dominio ya no está en uso.
• Certificados próximos al umbral de seguimiento: remote.sherlockhomeless.net tiene 31 días restantes, ocode.sherlockhomeless.net 33 días y llm.sherlockhomeless.net 37 días. Ninguno está caducado.
• Capacidad del volumen raíz: el 73% está utilizado. Quedan aproximadamente 55 GiB, por lo que no existe agotamiento inmediato, pero conviene mantener seguimiento de tendencia.
• Errores DNS transitorios: se registraron varios fallos al consultar un resolvedor externo. No se observa indisponibilidad sostenida en las comprobaciones HTTP.
• Autenticación SSH: se observaron intentos fallidos, reinicios de conexión y configuraciones MFA ausentes para intentos sobre usuarios concretos. Fail2ban permanece activo, pero la configuración PAM debe revisarse para evitar rutas de autenticación incoherentes.

Acciones recomendadas

1. Ejecutar codex-reauth para renovar la autenticación de OpenClaw y validar después una tarea programada de extremo a extremo.
2. Revisar la presión de memoria y el uso de swap por proceso; confirmar si los procesos de bases de datos y aplicaciones mantienen páginas inactivas o presentan crecimiento sostenido.
3. Corregir los registros DNS de opencode.sherlockhomeless.net o eliminar su configuración ACME si el nombre ya no debe publicarse.
4. Verificar la renovación automática de los certificados con menos de 40 días restantes, especialmente los de remote, ocode y llm.
5. Revisar los tiempos de activación de Memos, Vikunja y OneTimeSecret para confirmar si las latencias de aproximadamente nueve segundos son esperadas bajo Sablier.
6. Analizar las denegaciones SELinux de mandb con los identificadores de sealert; corregir el contexto o la política únicamente si la operación es legítima.
7. Auditar la cadena PAM de SSH y la disponibilidad de MFA para las cuentas permitidas, manteniendo Fail2ban y el control de claves públicas activos.

Contexto operativo

• El host ejecuta el kernel 5.14.0-570.58.1.el9_6.x86_64.
• Los 13 endpoints comprobados devolvieron HTTP 200. N8n, Nextcloud, Paperless, OnlyOffice, Authentik, Traefik, RSS, Dozzle, Beszel, Memos, Vikunja, Karakeep y OneTimeSecret quedaron accesibles.
• Los contenedores detenidos administrados por Sablier no se consideran incidentes por sí solos. Varias aplicaciones detenidas durante el inventario respondieron posteriormente a las comprobaciones HTTP.
• Los registros de Paperless muestran tareas programadas completadas correctamente y no evidencian un fallo del servicio.
• Las alertas repetidas de SELinux corresponden a dos denegaciones de capacidades para mandb. Constituyen ruido operativo relevante para revisión, pero no hay evidencia de impacto sobre los servicios publicados.
• Los avisos de systemd sobre unidades marcadas como inaccesibles para otros usuarios no impidieron que systemd leyera su configuración mediante sus APIs.
• Los reinicios de conexión y fallos de intercambio SSH son consistentes con sondeos o autenticaciones fallidas. Por sí solos no indican que Fail2ban esté inactivo.