ÇözümPark'a hoş geldiniz. Oturum Aç | Üye Ol
 
Ana Sayfa Makale Video Forum Resimler Dosyalar Etkinlik Hizmetlerimiz Biz Kimiz

HP - 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…

Tarih : 22 Eylül 2013 Pazar 23:38 Yayınlayan: selda aydogmusoglu

Yorumlar

 

Hakan UZUNER

Eline sağlık Selda.

Eylül 22, 2013 23:56
 

Evren Banger

Eline Sağlık.

Eylül 23, 2013 00:10
 

Bilgehan POYRAZ

Elinize sağlık. Çok güzel bir konu seçimi...

Eylül 23, 2013 00:25
 

selda aydogmusoglu

Teşekkürler Hakan,

Eylül 23, 2013 09:01
 

mertsever

Elinize sağlık güzel paylaşım.

Eylül 23, 2013 09:14
 

Rıza ŞAHAN

Elinize sağlık.

Eylül 23, 2013 10:59
 

selda aydogmusoglu

Herkse teşekkür ederim.

SIEM çözümü olarak HP ArcSight kullananlar için faydalı olabileceğini düşünüyorum.

Sorusu olanların sorularını yanıtlayabilirim.

Eylül 23, 2013 11:32
 

Ersin CAN

Elinize saglik.

Eylül 23, 2013 13:16
 

selda aydogmusoglu

Çok teşekkürler,

HP ArcSight ürünü kullananlar için umarım faydalı olmuştur.

Eylül 23, 2013 15:55
 

Mehmet PARLAKYİĞİT

Elinize sağlık.

Eylül 24, 2013 09:15
 

Ferit OSOYDAN

Elinize sağlık.

Eylül 26, 2013 10:38
 

Recep YÜKSEL

Selda hocam elinize sağlık.

Eylül 27, 2013 17:02
 

Ugur DEMIR

Elinize sağlık

Eylül 29, 2013 14:12
Kimliksiz yorumlar seçilemez kılınmış durumdadır.
 

Bu Kategori

Hızlı aktarma

Etiketler