Hewlett Packard Enterprise HPE

HP ArcSight Logger Search Optimizasyonu

HP ArcSight Logger , her türlü data toplama, hızlı data analizi, long-term storage ve oldukça yüksek event throughput sağlayan Log Management çözümüdür.  Logger ,event’leri toplar ve saklar, bu event’ler içerisinde arama ve raporlama yapılmasını sağlar.

 

Logger’da, yüksek performanslı arama ve analiz, hızlı event akışı gibi aktiviteler aynı anda yapılmaya çalışıldığında “doğru optimizasyon yapılmadıysa” performans düşüşü gözlenebilir. Logger’ın performansı, sisteminizin performansına, network yapısına, logger üzerinde yapılan işlemlere, Logger tipine ve nasıl konfigure edildiğine bağlı olarak  değişir.

 

Logger’ın search hızını ve scan oranını birçok faktör etkiler. Bunlardan bazıları:

 

Ne kadar data search edilecek?

 

Query ne kadar kompleks?Search işlemi peer’lar arasında mı yapılıyor ve nasıl dağıtılmış?

 

Bu yazımda search optimizasyonu için nelere dikkat edilmesi gerektiğinden bahsedeceğim.

 

INDEXING

 

Search optimizasyonu deyince ilk akla gelen indexleme işlemi oluyor. Hızlı search için ,yazdığınız query’de kullandığınız field’ların indexlenmiş olduğuna dikkat edin. Fakat HP ArcSight’ın default olarak belirlemiş olduğu indexable field sayısını çok fazla aşmanız durumunda da beklenmeyen bir performans kaybı yaşayabilirsiniz. Bu nedenle sayıyı fazla aşmadan query içerisinde illa kullanmanız gereken ve default’ta indexlenmeyen field’lar indexlenmek üzere belirlenebilir ve indexable field’lar arasına eklenebilir. Bir field indexlenmek üzere eklendiğinde tekrar silemezsiniz.

 

Query içerisinde kullanmak istediğiniz field’ı indexlenmek üzere ekledikten sonra search işlemini başlatmak için biraz beklemelisiniz. Field’ın indexlenmesi için biraz zaman tanımalısınız. Indexlemenin bittiğinden emin olduktan sonra serch işlemini başlattığınızda hızlı sonuç geldiğini farkedeceksiniz.

 

IMPROVING SEARCH PERFORMANCE

 

Yukarıda da bahsettiğimiz gibi search hızını etkileyen birçok faktör vardır. Örneğin, search edilecek data’nın büyüklüğü, query’nin kompleks oluşu, search işleminin peer’lar arasında yapılması gibi. Search performansını optimize etmek için aşağıdaki maddeleri uygulayabilirsiniz:

 

Sistem Nasıl Kurulmalı?

 

Network bağlantısı hızı (Network’te QoS uygulanıyorsa!)

 

Peer logger ‘ların aynı subnet’te olması

 

Data’yı parçalara ayırma ( Bir defada tümünü search etmek yerine parçalara ayırıp search etmek sonucu hızlandırır.Yüksek Event GirişiEvent input çok yüksek ise, indexleme geride kalır, bitmemiş olabilir! Bu nedenle search beklenenden daha yavaş olur. Bu nedenle;

 

Search işlemi sırasında son 2 dk ‘yı almayın.

 

Problem sürekli devam ediyor ise yapınızın doğru bir şekilde dizayn edildiğinden emin olun.

 

Connector’ler üzerinde aggregation yapılandırın. Bu işlem, EPS rate’ini düşürür.

 

Search Analyzer tool kullanın. Data’nın tamamıyla indexlenip indexlenmediğini gözlemleyin.

 

Data’nın en son ne zaman indexlendiğini hızlıca görmek için Global Summary ekranını gözleyebilirsiniz.

 

Taranacak Event Sayısı

 

Search işlemini, storage group ya da peer’e göre kısıtlamak search edilecek alanı daraltır ve event sayısını da azaltır. Böylece daha hızlı sonuç elde edilir. Query yazarken aşağıdaki gibi başlanması uygun olacaktır;

 

_storageGroup IN [ Default Storage Group]

 

_peerLogger IN [ 10.11.11.70] gibi .

 

Query’de storage group ya da peer kullanmak, device group kullanmaktan daha etkilidir.

 

Search Timeframe

Search edilecek zaman aralığını çok uzun tutmak sonucu geciktirir!

 

Search ile Eşleşen Event Sayısı

 

Search işlemi, çok fazla sayıda event ile eşleşiyor ise sonucun gelmesi uzun sürer. Örneğin, 1 milyon event ile eşleşen query sonucu, 500000 event ile eşleşen query sonucuna göre daha yavaş ve geç gelir. Bu nedenle yazdığınız query’i modifiye edin. Örneğin,

 

Search kısmına sadece ;

 

Failure yazmak yerine;

 

_deviceGroup IN [ 10.11.12.13 [test1]] AND Authentication AND categoryOutcome = “/Failure”

yazmak daha hızlı sonuç sağlayacaktır.

 

Query ‘de BOOLEAN Operator Kullanma

Yazdığınız query “OR” ve ya  “AND” operatorleri içeriyor ise işlem uzun sürer. Özellikle OR operatörü , regular expression gerektirdiği için search işlemini yavaşlatır. Bu nedenle yapılabiliyor ise query’de OR ve ya AND opratorlerinin sayısını azaltın.

 

Kompleks Query

Mümkün olduğunca basit query yazın ve basit operatörler kullanın ( replace, rename gibi.). Rex, sort ve chart gibi operatorler kullanmaktan kaçının.

 

Query ‘de kullanılan Field’ların Indexable olması

Indexlenmiş field’ları query’de kullanmak search işlemini hızlandırır. Logger arayüzünde default olarak gelen indexable field’ları görebilirsiniz ( Configuration – Search – Default Fields).

 

Indexlenmemiş bir field kullanarak search işlemini hızlandırmak için, indexlenmiş bir field ile birleştirip bir query oluşturun. Örneğin, requestUrl field’ı indexable bir field değildir. Bu nedenle ;

 

requestUrl CONTAINS “ornek” kullanmak yerine;

 

name = “……….” | where requestUrl CONTAINS “ornek” şeklinde query kullanın.

 

Arşivlenmiş data içerisinde search işlemi yapıyor iseniz, online data içinde yaptığınız search işleminden daha geç sonuç verir. Çünkü arşivlenen data indexlenmiş değildir.

 

Bir field’i indexlenme için eklemiş iseniz, indexlenmesi için zaman tanıyın.

 

Aynı anda Search , Report, Forwarder

Search , report ve forwarder işlemleri için aynı search engine kullanılmaktadır. Sisteminizde ağır yük varsa, yüksek “incoming EPS” , forwarder işlemi ve filtreleme, birden fazla search ve raporlama operasyonları paralel gidiyor ise, işlemler çok zaman alacaktır. Search ,reports gibi işlemleri mümkün olduğunca off-peak saatlerde yapmaya çalışın.

 

Search İşlemini Etkileyen Logger Ayarları

“Discovered field” ve “Summary field” enable edilmiş ise , search sırasında sistem bu field’ları toparlamaya çalışacağı için sistem yavaşlar. Hızlı search için bu opsiyonların disable edilmesi gerekir. Ayrıca;

 

Secondary Delimiter Support – Disable

 

Source Type Support – Enable.

 

Spesifik source tipleri kullanın

 

Global Summary Persistence – Logger 5.3 SP1 upgrade sonrasında “table defragment” yapmalısınız. 

Diğer Faktörler:

Logger versiyonu

Appliance ve model

Sistemdeki event sayısı

Insertion Rate

 

Logger üzerinde search optimizasyonu için dikkat edilmesi gereken birkaç özellikten bahsettik.

 

 

Herkese mutlu haftalar…

İlgili Makaleler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu