Cloudflare lleva SQL a Logpush para filtrar logs

Cloudflare mete SQL dentro del pipeline de exportación de logs

Cloudflare anunció que Logpush ya está disponible en todos los planes self-serve y que Transformers pasó a disponibilidad general: un motor SQL embebido en el pipeline de exportación que permite filtrar, redactar y remodelar registros antes de que salgan hacia el destino. Para un founder, la traducción es directa: menos datos innecesarios viajando por la red y menos factura de ingesta en la plataforma del otro lado.

La escala del problema explica por qué esto no es un detalle menor. El pipeline de datos de Cloudflare ingiere más de mil millones de eventos por segundo, y su servicio de entrega —al que la compañía llama Bufstream— despacha más de 110 millones de registros Logpush por segundo hacia destinos de clientes, corriendo sobre cientos de pods de Kubernetes. Añadir procesamiento en ese camino sin romper la entrega es la verdadera dificultad de ingeniería.

¿Qué son los Transformers de Logpush?

Un Transformer es una consulta SQL escrita para un dataset específico de Logpush. La consulta referencia campos de ese dataset y define qué registros y qué campos se exportan: lo que no cumple la cláusula WHERE se descarta, y el resultado del SELECT se convierte en el registro exportado, en formato NDJSON.

Se crean, previsualizan y administran desde Transformer Studio en el dashboard, o de forma programática vía API. Cada cambio genera una versión nueva, y el Transformer se adjunta después a un job compatible que use el mismo dataset. Esto sustituye a la pieza que hoy resuelven muchos equipos con un servicio propio de procesamiento: desplegar, escalar, monitorear y mantener esa capa extra.

¿Qué casos de uso resuelven en la práctica?

• Normalizar logs de varios CDNs agregando un campo estático como provider antes de que lleguen a la plataforma de analítica.
• Redactar datos sensibles, como parte de una dirección IP, con una expresión regular dentro de la propia consulta.
• Eliminar ruido de health checks y tráfico interno antes de exportar, en lugar de pagar por transportarlo y descartarlo al llegar.
• Renombrar, anidar o quitar campos para alinear el esquema con los dashboards y las investigaciones del equipo.

El ejemplo que publica Cloudflare es elocuente. Un log de request HTTP se transforma con regexp_replace para convertir los dos últimos octetos de la IP en .XXX.XXX, se añade 'cloudflare' AS provider, se anidan host y path en un objeto request y se filtran internal.example.com, health.example.com y las rutas /healthz y /metrics. El resultado es un único registro NDJSON con el esquema que el equipo definió, listo para su destino.

¿Por qué eligieron Apache DataFusion y descartaron los Workers?

El primer prototipo ejecutaba Transformers definidos por el cliente en WebAssembly dentro de Cloudflare Workers. La idea era atractiva por el aislamiento y la distribución global, pero invocar un Worker inserta una llamada de red en el camino de exportación: eso habilita timeouts transitorios y reintentos, con menos throughput y más latencia de entrega. El equipo optó por ejecutar todo in-process.

La elección final fue Apache DataFusion, un motor de consultas escrito en Rust y construido sobre Apache Arrow, con planificador SQL y ejecución vectorizada por columnas. Ya era la base de Cloudflare Basin. En un benchmark interno, ejecutar un Transformer preparado sobre un lote sintético de 5.000 filas del dataset http_requests desde una sola goroutine de Go tomó unos 3 milisegundos, equivalentes a cerca de 1,6 millones de filas por segundo.

El detalle interesante para quien diseña sistemas es el puente entre Go y Rust: los lotes viajan como Arrow IPC a través de la interfaz entre lenguajes, con Go pasando un puntero solo durante la llamada y Rust devolviendo un buffer que Go copia y libera de forma explícita. Así el trabajo sigue siendo batch y no se parsea registro por registro. Además, el esquema de cada lote no se infiere de los datos, sino que se genera desde la especificación del dataset de Logpush, lo que permite validar la consulta contra campos y tipos reales antes de ejecutarla.

¿Qué pasa si una transformación falla?

Transformers está diseñado para fallar cerrado. Si una transformación no puede ejecutarse, Bufstream no avanza el offset de entrega del job ni envía el lote sin transformar: prefiere reintentar. La razón es puro sentido operativo, porque entregar datos crudos cuando el destino espera un esquema redactado y filtrado puede violar los supuestos de pipelines downstream.

Para que un job persistentemente roto no consuma capacidad de los que funcionan bien, Bufstream retrasa los reintentos de forma progresiva, reporta el error en el job y deshabilita automáticamente los que se mantienen fallando durante un período extendido. Todo esto se monitorea en la vista Transformer Health, dentro de la pestaña Health de Logpush, junto con el volumen de datos antes y después de la transformación y la duración de cada ejecución.

¿Cuánto cuesta hoy procesar y almacenar logs?

El ahorro es la promesa central, y el mercado viene empujando en la misma dirección. Cribl entró al mercado de SIEM con Detect, que según la compañía recorta costos hasta un 50% frente a herramientas existentes y se cobra por la infraestructura donde corre, no por cuánto se consulta: alrededor de 18.000 a 20.000 dólares por terabyte por mes a precio de lista, según declaraciones de su directora sénior de ingeniería y operaciones de seguridad recogidas por TechTarget. Axoflow, por su parte, lanzó AxoDetect en early access con el argumento de correr reglas de detección en el pipeline antes de que los datos lleguen al SIEM; de acuerdo con la compañía, una empresa industrial global redujo sus costos de SIEM un 50% y su tiempo medio de resolución un 85%, y una agencia de gobierno recortó 80% su volumen de datos.

Y el costo de no filtrar no es solo de almacenamiento. Un estudio de New Relic citado por InfoWorld encontró que algunas caídas de alto impacto pueden costar hasta 2 millones de dólares por hora, mientras que el equipo de soporte de Sourcegraph dedicaba entre 45 y 90 minutos por incidencia solo a revisar logs dispersos entre plataformas antes de empezar a usar IA. Filtrar y normalizar antes de exportar ataca las dos puntas: volumen de datos y velocidad de diagnóstico.

¿Qué significa esto para tu startup?

Tres movimientos concretos:

• Mide cuánto de lo que exportas no usas. Si una parte relevante de tus logs de acceso son health checks y tráfico interno, hoy pagas egreso, ingesta y almacenamiento por registros que descartas al llegar. Un Transformer con un WHERE bien puesto corta ese gasto antes de que salga de Cloudflare.
• Empieza por redacción de datos sensibles. Mover la limpieza de IPs, tokens o identificadores a la consulta SQL del pipeline reduce la superficie de exposición y, de paso, te ayuda con requisitos de privacidad. El ejemplo de regexp_replace que documenta Cloudflare es un punto de partida razonable.
• Instrumenta el fallo antes de confiar en el pipeline. Como Transformers no entrega datos sin transformar, una consulta rota detiene la entrega y puede terminar deshabilitando el job. Configura alertas sobre Transformer Health y versiona tus consultas para poder volver atrás sin perder trazabilidad.

Conclusión

Cloudflare movió una pieza que muchos equipos mantenían a mano —un servicio intermedio para filtrar y normalizar logs— dentro de su propio pipeline de exportación, y lo puso al alcance de los planes gratuitos y self-serve. Para startups con equipos de plataforma pequeños, la ganancia no es solo el ahorro en ingesta: es dejar de ser dueño de un componente más que hay que desplegar, escalar y monitorear. La contraparte es que ahora una consulta mal escrita puede frenar la entrega de logs, así que el versionado y las alertas dejan de ser opcionales.

Fuentes

• Filter, reshape, and redact logs before export with Transformers (fuente original)
• Cribl targets SIEM data costs with new Detect tool
• AI-powered data pipeline observability: Stop monitoring and start preventing
• Axoflow Launches AxoDetect, Bringing Detection Into the Pipeline and Making the SIEM Optional

Artículos relacionados:

Cloudflare OS: la plataforma open source que democratiza agentes de IA en empresas Entre empresas europeas con CDN, 9 de cada 10 usan Cloudflare Cloudflare integra a Cursor en sus Sandboxes de IA Cloudflare Traces: trazado OpenTelemetry para todo el stack Cloudflare: ve qué tráfico de tu dominio ya es post-quantum