QRadar’da Persistent Queue ve Spillover Queue Farkı Nedir ?
QRadar ile uğraşan herkesin er ya da geç karşılaştığı bir konu: event’ler bir yerlerde birikiyor ama neden birikiyor, hangi kuyruk hangi soruna işaret ediyor? Bu ikisini birbirine karıştırmak yanlış tuning’e, yanlış tuning de boşa zaman kaybına yol açıyor. Kısaca netleştirelim.
Event Pipeline’da İki Aşama
QRadar’da event’ler şu sırayla ilerliyor:
- ecs-ec-ingress → log source’lardan gelen ham event’ler burada toplanır
- ecs-ec → parsing, normalization, coalescing işlemleri burada yapılır
- ecs-ep → parse edilmiş event’ler Custom Rules Engine’e (CRE) buradan gider
Her aşama arasında bir persistent queue (kalıcı kuyruk) var, çünkü bir sonraki aşama yetişemezse event’lerin kaybolmaması gerekiyor.
Persistent Queue: Performans Meselesi
ecs-ec-ingress.ecs-ec-ingress ve ecs-ec.ecs-ec kuyrukları tamamen performans/kapasite ile ilgilidir, lisansla ilgisi yoktur.
- ecs-ec-ingress şişiyorsa → ecs-ec (parsing) yetişemiyor demektir. Sebep DSM/parsing tuning veya auto-discovery yüküdür.
- ecs-ec.ecs-ec şişiyorsa → ecs-ep (CRE) yetişemiyor demektir. Sebep genelde custom rule sayısı/karmaşıklığı veya CPU/RAM darboğazıdır.
Bu kuyrukların sabit bir GB limiti yoktur. Disk doldukça büyümeye devam ederler; gerçek IBM support vakalarında ecs-ec-ingress kuyruğunun 325GB’a kadar şiştiği görülmüştür. Sınır, appliance’ın /store partition kapasitesidir, bu partition %95 doluluğa ulaştığında QRadar kritik servisleri (ecs-ec, ecs-ep) otomatik olarak mevcut diski korumak adına durdurur.
Performans Sorununu Teşhis Etmek: İki Script
ecs-ec-ingress veya ecs-ec.ecs-ec kuyruğu şişiyorsa, “neden yetişemiyor” sorusuna cevap bulmak için IBM’in resmi destek script’leri devreye giriyor.
findExpensiveCustomProperties.sh
Custom Event Property’lerin (CEP) regex performansını ölçer. ecs-ec-ingress tarafında parsing yavaşlığından şüpheleniyorsan ilk bakılacak yer burası.
- Konum: /opt/qradar/support/findExpensiveCustomProperties.sh
- Varsayılan ölçüm penceresi: 120 saniye, sonuna -i <saniye> parametresi eklenerek uzatılabilir. Trafiği yoğun ortamlarda temsili veri için IBM 300–600 saniye öneriyor.
- Sonuç eşikleri:
- >500.000 ns (0,5 ms) → acil, öncelikli müdahale gerekir
- 200.000–500.000 ns → expensive, tuning yapılmalı
- <200.000 ns → sorun değil, olması gerektiği gibi
findExpensiveCustomRules.sh
Custom rule’ların CRE (Custom Rules Engine) üzerindeki yükünü ölçer. ecs-ec.ecs-ec kuyruğu şişiyorsa asıl bakılması gereken script budur.
- Konum: /opt/qradar/support/findExpensiveCustomRules.sh
- Kullanım: ./findExpensiveCustomRules.sh -d /root (-d ile çıktı dizini belirtilir)
- Script çalıştıktan sonra sonucu bir CustomRule-xxxx-xx-xx-yyyyyyy.tar.gz dosyasına yazar; bunu tar -zxvf ile açıp içeriğini inceleyebilirsin.
İlişkili sistem bildirimi: qradar.error log dosyasında şu tarz bir uyarı görürsen “Custom Rule Engine has sent a total of X event(s) directly to storage” tuning yapılmamış custom rule’ların performans sorununa yol açtığının işaretidir.
Get Berkay Köseoğlu’s stories in your inbox
Join Medium for free to get updates from this writer.
Bu mesaj, CRE’nin yetişemediği için event’leri korelasyondan geçirmeden doğrudan depolamaya gönderdiğini, yani rule tuning’in gecikmeden yapılması gerektiğini gösterir.
Spillover Queue: Lisans Sebebiyle ( Burst Handling )
Spillover (taşma) kuyruğu ise bambaşka bir mekanizma: EPS, host’un lisans limitini aştığında devreye giriyor. Lisansı aşan event’ler bu kuyrukta geçici olarak bekletiliyor, gelen EPS lisans eşiğinin altına düşünce buradan işlenmeye devam ediyor.
Bu kuyruğun sabit bir boyutu var: 5GB. Bu 5GB’lık alan yaklaşık 1.5 milyon event tutabiliyor (EPS’e göre değişir).
Önemli: Bu 5GB artırılabilir bir değer değil. IBM support’un resmi tutumu net:
“Support does not increase buffer sizing for end users.”
Buffer’ı büyütmek asıl sorunu çözmüyor, sadece erteliyor. Spillover sürekli doluyorsa gerçek çözüm iki yoldan biri:
- EPS lisansını artırmak
- Routing rule ile düşük güvenlik değerli event’leri drop ederek lisans aralığına geri dönmek ( license giveback fonksiyonu bulunmaktadır, coalescing de lisans giveback bulunmaz! )
Burst Handling Nasıl Çalışır?
Spillover mekanizmasının resmi adı aslında burst handling: QRadar, lisanslı EPS/FPM limitini aşan bir spike geldiğinde veri kaybı yaşanmasın diye fazlalığı geçici bir kuyruğa alıyor ve trafik yavaşlayınca işliyor. Bu tetiklendiğinde appliance’ın lisans limitini aştığına dair bir sistem bildirimi de üretiliyor.
Birkaç önemli detay:
- Sıralama FIFO’dur: Kuyruktaki en eski event/flow, en yeni olandan önce işlenir.
- Kuyruğun boşalma/dolma hızı spike’ın büyüklüğüne ve süresine, appliance’ın kapasitesine ve payload boyutuna bağlıdır.
- Donanım appliance’lar genelde kendi lisanslı EPS/FPM kapasitesinin en az %50 üzerinde burst’ü kaldırabilir ve bu geçici kuyrukta 5GB’a kadar veri tutabilir. Gerçek burst kapasitesi sistem yüküne göre değişir.
- VM appliance’lar da benzer sonuca ulaşabilir, ancak VM’in yeterince büyük boyutlandırılmış ve performans gereksinimlerini karşılıyor olması şartıyla.
Örnek: Sabah Yoğunluğu (Burst) Senaryosu
IBM’in resmi dokümantasyonundaki örnek durumu somutlaştırıyor:
Bir şirkette her sabah 08:00–09:00 arası çalışanlar sisteme giriş yapıp ağ kaynaklarını kullanmaya başlayınca trafikte spike oluşuyor. Ortamda 5.000 EPS / 100.000 FPM lisanslı bir appliance var, ortalama kullanım ise 4.000 EPS / 70.000 FPM.
Spike sırasında (saat 09:00 civarı zirve yaparak) appliance 6.000 EPS / 120.000 FPM’e kadar veri alıyor. QRadar, lisansı aşan kısmı (1.000 EPS ve 20.000 FPM) otomatik olarak burst handling queue’ya (spillover) yönlendiriyor ve appliance’ın lisanslı kapasiteyi aştığına dair bir sistem bildirimi üretiyor.
Trafik normale döndüğünde recovery rate (lisanslı kapasite ile o anki gelen veri arasındaki fark) devreye giriyor ve kuyrukta bekleyen event/flow’lar bu hızla boşaltılıyor:
5.000 lisanslı event — 4.000 gelen event = 1.000 EPS recovery rate
100.000 lisanslı flow — 70.000 gelen flow = 30.000 FPM recovery rate
Kritik nokta: Offense’lar, event appliance tarafından işlenene kadar oluşmuyor. Yani spillover’da bekleyen event’ler için korelasyon/offense üretimi gecikiyor demektir. Bu yüzden appliance’a spike’ları hızlı toparlayabilecek kadar EPS/FPM tahsis etmek önemli — aksi halde sürekli “recovery” moduna giremeyen bir sistemle uğraşırsın ve tespit gecikir.
ÖZET TABLO
Referanslar
https://www.ibm.com/support/pages/qradar-how-interpret-script-findexpensivecustompropertiessh
https://www.ibm.com/docs/en/qsip/7.4.0?topic=management-burst-handling
