Ir para o conteúdo principal
Voltar aos artigos

Logpush: o filtro de privacidade precisa falhar sem vazar o lote bruto

Transformers da Cloudflare aplicam SQL antes da exportação de logs. A decisão central é equilibrar minimização de dados e visibilidade de falhas.

·3 min de leitura·2 visualizações

A Cloudflare detalhou os Transformers no Logpush, recurso disponível de forma geral que aplica SQL a lotes de logs antes de exportá-los.[10] É possível filtrar registros, mascarar ou remover campos, renomear dados e criar estruturas aninhadas, mantendo a saída em NDJSON.[10] Para mim, o detalhe decisivo não é a flexibilidade da consulta: é o que acontece quando ela falha.

O que muda para quem desenvolve

Se a transformação falha, o sistema não exporta o lote bruto nem avança o offset; ele tenta novamente e pode desativar jobs persistentemente problemáticos.[10] Essa é uma escolha coerente com um filtro de dados sensíveis, mas exige tratar interrupção de entrega como uma condição operacional visível.

Minha análise é que a política de privacidade não pode virar opcional justamente no caminho de erro. Ao mesmo tempo, um job parado não deve parecer uma queda espontânea do tráfego. Eu distinguiria “nenhum evento produzido” de “eventos aguardando transformação”.

A implementação final executa Apache DataFusion, em Rust, dentro do serviço de entrega escrito em Go, em vez de acrescentar uma chamada de rede a Workers.[10] Os lotes atravessam essa fronteira em Arrow IPC, com propriedade da memória explícita: a saída é copiada para Go e a alocação Rust é liberada.[10] A lição de arquitetura que eu aproveitaria é documentar o ciclo de vida dos dados tão cuidadosamente quanto o plano de consulta.

Como aplicar

Escolha um dataset e defina uma lista explícita dos campos necessários no destino. Para cada campo descartado, registre o motivo; para cada dado mantido, registre a finalidade. Comece com amostras sem informação pessoal real.

O Transformer Studio e a API permitem criar, testar e administrar consultas com histórico de versões, e o Transformer deve usar o mesmo dataset do job compatível.[10] Teste não só o exemplo feliz, mas registros com campo ausente, valor nulo, formato inesperado e estrutura nova. Confira também se o mascaramento continua permitindo a investigação que motivou a coleta.

Depois, compare volumes antes e depois e valide a leitura do NDJSON no destino. A visão de saúde expõe sucessos, falhas, duração e volumes.[10] Minha sugestão é criar um alerta para interrupção da entrega e um procedimento de correção que não reative exportação bruta como atalho.

Em um pipeline próprio, replique o princípio com um teste controlado: force erro no transformador e verifique que nenhum registro original chega ao coletor de teste. Estabeleça também um limite de retenção dos lotes pendentes e um responsável por resolver o bloqueio.

Cuidados e limites

O benchmark sintético apresentado processou 5 mil linhas em aproximadamente 3 ms com consulta preparada; isso não é uma garantia de vazão de todo job.[10] O recurso aparece nos planos Free, Pro, Business e Enterprise, mas a publicação não torna gratuito todo uso do Logpush.[10]

Eu não removeria campos de segurança apenas para reduzir a fatura. Minimização precisa preservar o propósito da observabilidade. O objetivo é exportar menos dados desnecessários sem perder a capacidade de explicar uma falha ou um incidente.

Fonte

[10] Fonte: Cloudflare Blog

Continue lendo