Cloudflare'ın Logpush Transformers özelliği SQL filtreleme ve maskeleme ile self-serve planlarda genel kullanıma açıldı

Cloudflare, Logpush Transformers özelliğini genel kullanıma sundu; böylece müşteriler log kayıtlarını platformdan çıkmadan önce SQL ile filtreleyebiliyor, yeniden şekillendirebiliyor ve maskeleyebiliyor. Cloudflare bloguna göre bu özellik, şirketin yakın zamanda düzenlediği Birthday Week kapsamında, Logpush'un kendisinin de tüm self-serve planlara yaygınlaştırılmasıyla birlikte geldi ve bu iki değişiklik, Cloudflare'ın gözlemlenebilirlik ürünlerine yapılan sekiz güncellemeden biri olarak sayılıyor.

Dışa aktarma hattının içinde bir SQL aşaması

Logpush, Cloudflare loglarını toplu hâle getirip güvenlik bilgi ve olay yönetimi sistemlerine, analitik platformlara ve nesne depolamaya iletiyor. Cloudflare blogu, ekiplerin bu logların hedefe varmadan önce genellikle temizlenmesi gerektiğine dikkat çekiyor: health-check trafiğinin atılması, hassas alanların gizlenmesi ya da kayıtların bir panoya veya şirket genelinde kullanılan bir şemaya uyacak şekilde yeniden yapılandırılması. Tarihsel olarak bu iş, bir ekibin dağıtması, ölçeklendirmesi, izlemesi ve bakımını yapması gereken ayrı bir işleme servisi gerektiriyordu; ayrıca varır varmaz atılacak kayıtları dışa aktarmak, almak ve depolamak için ödeme yapmak anlamına geliyordu.

Bir Transformer, belirli bir Logpush veri seti için yazılmış SQL sorgusudur. Logpush bu sorguyu dışa aktarmadan önce her toplu kayda uygular: WHERE koşulunu geçemeyen kayıtlar atılır, SELECT ifadesinin çıktısı ise dışa aktarılan kayıt olur. Dönüşümler alanları yeniden adlandırabilir, iç içe yerleştirebilir, birden fazla CDN arasında logları normalize eden ekipler için statik bir sağlayıcı tanımlayıcısı gibi hesaplanmış değerler ekleyebilir ya da bir istemci IP'sinin son oktetleri gibi verileri maskeleyebilir. Girdi ve çıktı NDJSON olarak kaldığından Transformers, kayıtları yeniden şekillendirir; serileştirme formatları arasında dönüştürme yapmaz.

Müşteriler Transformers'ları Cloudflare kontrol panelindeki Transformer Studio üzerinden veya API ile programatik olarak oluşturur, önizler ve yönetir, ardından bunları aynı veri setini kullanan uyumlu bir NDJSON Logpush işine bağlar. Bir Transformer'a yapılan her güncelleme yeni bir sürüm oluşturur; böylece müşteriler zaman içinde nasıl değiştiğini inceleyebilir.

Dönüşümü kritik yolun dışında tutmak

Cloudflare'ın ölçeği, şirketin SQL'in nerede çalışacağı konusunda bilinçli davranmasını açıklıyor. Blogda belirtildiğine göre şirketin veri hattı saniyede bir milyardan fazla olay alıyor ve teslimat servisi Bufstream, yüzlerce Kubernetes pod'u üzerinde müşteri hedeflerine saniyede 110 milyondan fazla Logpush kaydı iletiyor. İş hacmi Pareto benzeri bir dağılım izliyor: işlerin çoğu düşük hacimlerde çalışırken az sayıda iş saniyede milyonlarca kayıt işliyor.

Erken bir prototip, müşteri tanımlı WebAssembly Transformers'ları Cloudflare Workers içinde çalıştırıyordu; ancak bir Worker çağırmak, dışa aktarma yoluna bir ağ çağrısı sokarak veri iletimini düşüren ve gecikme ekleyen geçici zaman aşımları ve yeniden denemeler riski doğuracaktı. Bunun yerine Cloudflare, Cloudflare Basin'i zaten çalıştıran ve Apache Arrow üzerine kurulu Rust tabanlı bir sorgu motoru olan Apache DataFusion'ı Bufstream içinde süreç gömülü olarak çalıştırdı. Yazıda alıntılanan bir kıyaslamada, hazırlanmış bir Transformer'ı tek bir Go goroutine'i üzerinden sentetik 5.000 satırlık bir toplu kayda karşı çalıştırmak yaklaşık 3 ms sürdü; bu da kabaca saniyede 1,6 milyon satır demek. Yüksek hacimli işler, toplu kayıtların eşzamanlı olarak dönüştürülebilmesi için iş başına dönüşüm paralelliği elde ediyor; böylece ayrı bir dönüşüm katmanı eklemek yerine Bufstream'ın mevcut zamanlama, toplu işleme ve hedef kontrolleri yeniden kullanılıyor.

Go ile yazılmış Bufstream'ı Rust ile yazılmış bir motora bağlamak kalan zorluktu. Toplu kayıtlar, Cloudflare'ın kendi geliştirdiği dağıtık mesaj aracısı Buftee'den sıkıştırılmış Cap'n Proto kayıtları olarak gelir; Bufstream bunları açar, uygun logları ayrıştırır ve dönüşümü çalıştırmadan önce tipli Apache Arrow kayıt toplulukları oluşturur. Arrow IPC, bu toplulukları cgo üzerinden bir C ABI ile paylaşır. Sınır boyunca sahiplik açıktır: Go, girdi tamponuna işaretçisini yalnızca çağrı süresince Rust'a geçirir; Rust'ın çıktı tamponu ise Go tarafından yönetilen belleğe kopyalanır ve sonra serbest bırakılır. Cloudflare'a göre bu yaklaşım, çalışma zamanları arası bellek yönetimi hatalarını önler.

Neden önemli

Dışa aktarma öncesi dönüşüm büyük ölçüde bir maliyet ve hijyen çalışmasıdır. Teslim öncesi filtrelenen her kayıt, çıkış (egress), SIEM alımı ve depolama ücretlerinden kaçınmayı sağlar; maskelenen her alan da tam istemci IP'leri gibi hassas verilerin üçüncü bir tarafa gönderilme riskini azaltır. Birden fazla CDN sağlayıcısından gelen logları tek bir şemada normalize eden ekipler için bu işi dışa aktarma işinin içinde yapmak, altyapı faturasından özel yapım bir servisi çıkarır. Uygulama ayrıca analitik bir SQL motorunun operasyonel bir teslimat yoluna gömülmesinin dikkate değer bir örneği; Logpush artık her self-serve planda kullanılabilir olduğuna göre bu yetenek yalnızca kurumsal müşterilere ayrılmış değil.