ADR-0014 — Logs: backend de objeto para la agregación¶

Estado: propuesto

Esta decisión documenta el destino y su justificación para una fase futura de observabilidad en la nube. Todavía no está implementada: hoy la agregación de logs almacena en el disco local del clúster.

Contexto¶

El agregador de logs corre en modo de proceso único con almacenamiento local en disco, dentro del clúster. Ese diseño encaja mal con el objetivo de nube (coherente con las fases anteriores) por tres motivos:

Durabilidad ligada al disco del contenedor. Los datos viven en el disco del clúster. Con el modelo de encendido bajo demanda (que escala a cero nodos en reposo), los logs quedan atrapados en un disco que solo es útil con el clúster encendido, exactamente el problema que ya se resolvió para los datos analíticos al introducir la capa fría.
No escala ni separa lectura de escritura. El almacenamiento de objetos es requisito para el modo distribuido del agregador; el disco local lo impide.
Coste y retención. Ampliar la retención en disco significa agrandar el volumen; el almacenamiento de objetos, con sus clases más frías y baratas, es mucho más económico para el histórico.

La fase analítica ya introdujo el almacenamiento de objetos como capa fría con ciclo de vida hacia clases más baratas. Reutilizar ese mismo patrón para los logs es coherente.

Decisión¶

Migrar el backend del agregador de logs de disco local a almacenamiento de objetos. El índice se apoya también en el objeto. Se conserva la configuración anterior para el histórico ya escrito (el esquema se versiona por rango de fechas, así que la migración es sin corte). La autenticación es sin claves, mediante identidad de carga de trabajo, el mismo patrón que la exportación analítica. El bucket es dedicado y con ciclo de vida hacia clases de almacenamiento más frías, definido como código.

Consecuencias¶

Positivas:

Logs duraderos e independientes del disco del clúster: sobreviven al apagado y a los desalojos de nodos interrumpibles.
Retención larga y barata mediante las clases de almacenamiento del objeto, sin agrandar volúmenes.
Desbloquea el modo distribuido del agregador (caminos de lectura y escritura separados) si algún día hace falta.
Consistencia con la capa fría analítica: un único patrón de objeto y de autenticación sin claves.

Negativas o deuda asumida:

No implementado todavía: requiere aplicar el cambio de configuración, crear el bucket y los permisos como código, y probarlo en la nube. Hasta entonces sigue en disco local.
Introduce dependencia del proveedor de nube para los logs (antes eran portables a cualquier disco). Aceptable dado que el objetivo de estas fases es la nube; en local se puede seguir con disco mediante una configuración alterna.
Latencia y coste por petición de objeto frente a disco local; despreciable para el volumen de un laboratorio.

Alternativas descartadas¶

Seguir en disco local: es el estado actual; no cumple durabilidad con el clúster apagado ni retención barata. Se mantiene solo para desarrollo local.
Almacén de objetos autohospedado dentro del clúster: portable, pero es otra pieza con estado que mantener (copias, alta disponibilidad) y no resuelve el "consultable con el clúster apagado".
Almacén de objetos de otro proveedor de nube: introduciría una nube extra solo por los logs, sin motivo, cuando la plataforma ya está en un proveedor concreto.
Enviar los logs al almacén de datos analítico: no es un motor de búsqueda de logs (consultas por patrón, correlación por identificador de traza); la herramienta correcta es el agregador sobre objeto.