Aşağıda gerçekleştirilen
projeler, daha önceden başka ekipler tarafından yapılan projelerin
analizlerinde elde ettiğim tecrübelerimi paylaşmaya çalıştım. Aşağıda teknik
unsurlar özetlenmeye çalışılacak. Bununla birlikte bir projenin başarılı
olabilmesi için proje ekibinin çok önemli bir etken olduğu unutulmamalıdır.
Log yönetimi projelerinde
genelde karşılaşılan problemleri özetlemek gerekirse:
o
Sistemin ürettiği
verinin Log Yönetim yazılımı tarafından karşılanamaması
o
Log Yönetim
Sisteminin EPS değerlerinin yeterli olmaması ve kullanıcının bunun farkında
olmaması
o
Veri kaybı
o
Aranılan
verinin bulunamaması
o
Yedeklerden
geri dönememe
o
Arama
kriterlerinin beklenen seviyede olmaması
o
Raporlama
yeteneklerinin ileride çıkacak ihtiyaçlara göre planlanmamış olması
o
Logların
eksik alınması
o
Mail Server
o
WEB Server
o
FTP Server
o
DC ve diğer
Serverlar vb..
o
Logların kısa
süreli kaydedilmesi.
o Satın almaya kadar ortam ölçeklendirmesini
ertelemek (EPS değerleri)
o
Sadece
fiyatına bakıp seçim yapmak (En çok rastlana durumlardan biri)
o
Neleri
log'lamanız gerektiğini üretici firmanın size söylemesini beklemek
o
Hukuk ekibini
gözardı etmek
o
Arayüz çok
kullanışlı o yüzden desteğe ihtiyaç yok vb..
Son 5 madde ayrıca Anton Chuvakin'in Six MIstakes of Log Management
makalesinde de ifade edilmiştir.
Log Yakalama veya Log Kaçırmama Özelliği
Bir log yönetim
sisteminin en önemli özelliği gelen bütün logları yakalamak ve işlemektir.
Sistemin bu özelliği bir proje yapılırken neredeyse hiç göz önünde
bulundurulmamaktadır. Saniyede 100 lerce 1000 lerce log oluştuğu ve bu loglar
ekrandan çok hızlıca aktığı için gözle oluşan logların kontrolü mümkün
değildir. Dolayısı ile gözle kontrol çok
yanıltıcıdır.
SYSLOG Simulator
Sistemlerin gönderilen
bütün logları karşılayıp karşılayamadıklarını ölçmenin pek çok yöntemi
mevcuttur. En kolay yöntemi bir SYSLOG Simulator kullanıp saniyede belirlenen
adette log göndermek ve bunun sistem tarafından yakalanıp yakalanmadığına
bakmaktır. Bunu yaparken sistemin ortalamanın 2-3 katına belli tepe (
peak) zamanlarında çıkabileceğini de hesaba
katıp ona göre log göndermektir.
Sistemlerin gönderilen bütün logları karşılayıp
karşılayamadıklarını ölçmenin pek çok yöntemi mevcuttur. En kolay yöntemi bir
SYSLOG Simulator kullanıp saniyede belirlenen adette log göndermek ve bunun
sistem tarafından yakalanıp yakalanmadığına bakmaktır. Bunu yaparken sistemin
ortalamanın 2-3 katına belli tepe ( peak)
zamanlarında çıkabileceğini de hesaba katıp ona göre log göndermektir.
Örnek SYSLOG Simulatorler:
ayrıca profesyonel ürünün üreticilerinin tamamı bu
testleri hem kendi ürünleri hem de müşteri talebi ile herhangi bir ürün
üzerinde yapabilmektedir.
ANET yazılım olarak 100 K EPS değerlerine
erişmemizi sağlayacak bir altyapıyı test etmek için özel olarak geliştirdiğimiz
SYSLOG simülatörümüzü kullanmaktayız.
Bu aracın konfigürasyon dosyasında log üretme hızı vs..
ayarlanabilmektedir
logsize=10000
totallogs=50000000
sleeptime=1000
fast=true
logsize parametresi EPS değerini totlalogs ise
toplamda kaç log gönderileceğini belirtmektedir.
Ayrıca projelerde geliştirdiğimiz bu ve benzeri
araçlarda danışmanlık desteği de sunmaktayız.
Testler yapılırkan normal şartlar için değil Peak
EPS değerleri için test edilmelidir. Burada en önemli kriter
1.
Belirli bir
sayıdaki logu belirli sürede gönderebilmek
2.
Toplam log
sayısına değil de saniyede kaç adet gönderilebildiğini hesaba katmaktır.
Kiwi veya yukarıda linki verilen yazılımlar ile
30-40 EPS i aşmak mümkün değildir.
Ya da üçüncü bir parti yazılım kullanılmak
istenirse aşağıdaki linkteki ürün kullanılabilir
bu linkten Slogger-v0.6.zip dosyası indirilip
açıldıktan sonra aşağıdaki gibi bir dosya yapısı ile karşılaşılacaktır
Burada sadece run.bat dosyası kullanıcı tarafından
oluşturulmalıdır. Bu dosyanın içeriği ise
“java -cp .\bin;.\3rdParty\Syslog.jar org.slogger.Slogger” şeklindedir. Tabi sistemde java yüklü
olduğundan emin olun. Bunu için komut satırında aşağıdaki komut “java -version”
çalıştırılır
Yazılım çalıştıktan sonra aşağıdaki gibi bir sonuç
üretir.
Burada EPS değerini 977 olarak görürsünüz. Bu
parametreler ise slogger.properties dosyasından ayarlanmaktadır. Örneğin 1000 EPS hız ile 200 000 log
göndermek için aşağıdaki parametreleri kullanabilirsiniz.
|
## slogger Properties file
## configure slogger options.
## program options.
syslogProvider=org.slogger.provider.randomMessageProvider.RandomSyslogProvider
#syslogPublisher=org.slogger.publisher.FilePublisher
syslogPublisher=org.slogger.publisher.NetworkPublisher
## Control the rate at which messages are sent.
##Delay added between messages in millis. 0 means no delay.
## If maxEpsRate is specfied, this value is ignored.
#delayBetweenMessages=0
maxEpsRate=1000
promptForStart=FALSE
displayCounters=TRUE
displaySentMessages=TRUE
## FileTarget Options
FilePublisher.file=syslog.log
## Network publisher options
NetworkPublisher.host=localhost
NetworkPublisher.port=514
NetworkPublisher.sourceAddressEncapString=
NetworkPublisher.keepMessageCounters=FALSE
## RandomMessageProvider options.
## Global message options
## Message Count
rmp.messageCount=200000
rmp.useEmblem=true
rmp.sources=10.1.1.1,10.1.1.2,10.1.1.3
rmp.levels=3
rmp.facility=ASA
rmp.sourcePort=5555
rmp.targetHost=2.2.2.2
rmp.targetPort=targetPort
rmp.timeStamp=timeStamps
rmp.inputSyslogFile=input_syslogs.log
###Messages to be generated
rmp.message.1.multiplier=1
rmp.message.1.messageText=302013: Built <<inbound,outbound>>
TCP connection <<1-100000>> for
inside:<<1.1.0.0,1.1.255.255>>/<<10000-50000>>
(<<10.10.10.0,10.10.10.255>>/<<10000-50000>>) to
outside:<<128.1.1.1-200.1.1.2>>/<<1-1024>>
(<<21.1.1.1,21.1.1.255>>/<<1-1024>>)
rmp.message.2.multiplier=1
rmp.message.2.messageText=302014: Teardown TCP connection
<<1-100000>> for
<<inside,outside,dmz>>:<<1.1.0.0,1.1.255.255>>/<<10000-50000>>
to
<<inside,outside,dmz>>:<<128.1.1.1-200.1.1.2>>/<<1-1030>>
duration <<100,200,300>> bytes <<100,200,300>> Richa
(Ric)
rmp.message.3.multiplier=1
rmp.message.3.messageText=302015: Built <<inbound,outbound>>
UDP connection <<1-100000>> for inside:<<1.1.0.0,1.1.255.255>>/<<10000-50000>>
(<<10.10.10.0,10.10.10.255>>/<<10000-50000>>) to
outside:<<128.1.1.1-200.1.1.2>>/<<1-1024>>
(<<21.1.1.1,21.1.1.255>>/<<1-1024>>)
rmp.message.4.multiplier=1
rmp.message.4.messageText=302016: Teardown UDP connection
<<1-100000>> for
<<inside,outside,dmz>>:<<1.1.0.0,1.1.255.255>>/<<10000-50000>>
to
<<inside,outside,dmz>>:<<128.1.1.1-200.1.1.2>>/<<1-1030>>
duration <<100,200,300>> bytes <<100,200,300>>
rmp.message.5.multiplier=1
rmp.message.5.messageText=106100: access-list <<acl1,acl2,acl3>>
permitted <<TCP,UDP>>
outside/<<1.1.0.0,1.1.255.255>>(<<10000-50000>>)
->
inside/<<128.1.0.0,128.1.255.255>>(<<10000-50000>>)
hit-cnt 10 Something [0x1001, 0x1000]
rmp.message.6.multiplier=1
rmp.message.6.messageText=106023: Deny tcp src outside:<<1.1.0.0,1.1.255.255>>/<<10000-50000>>
dst
inside:<<192.168.131.10-192.168.135.10>>/<<5060-17000>>
by access-group "TRANSIT" [0x298f38e5, 0x0]
rmp.message.7.messageText=302020: Built outbound ICMP connection for
faddr <<10.20.14.141-10.20.255.255>>/<<0-7>> gaddr
<<192.168.5.21-192.168.6.255>>/512 laddr
<<192.168.5.21-192.168.6.255>>/512
|
Yukarıdaki programı kullanarak
1.
Belirli bir
sayıdaki logu belirli sürede gönderebilmeyi sağlayabiliriz. Burada 200 000 log
2.
Toplam log
sayısına değil de saniyede kaç adet gönderilebildiğini hesaba katmaktır. Bu da
mümkün yaklaşık 1000 EPS değeri (997) sağlanabilmektedir.
Ve tabi en önemlisi gönderilen toplam log sayısı
ve süresi gözükmektedir.
Log Yönetimi Sistemlerinin Log Yakalama (Toplama) Hızı
Bir log yönetim sisteminin en önemli özelliği
gelen bütün logları yakalamak ve işlemektir. Sistemin bu özelliği bir proje
yapılırken neredeyse hiç göz önünde bulundurulmamaktadır. Maalesef görsel
unsurlar bu özelliği perdelemektedir.
EPS Nedir?
Bazı sistemler kullanıcı ve bilgisayar sayısına
göre kurgulama ve fiyatlandırma yapmaktadır. Bu doğru bir yaklaşım olmadığı
gibi sektörce bilinen yazılımlar EPS değeri kullanmaktadır.
Yukarıdaki verilen örnekleri kullanarak bir
ölçekleme yaparsak:
100
Cihazlık bir ağ için
Ortalama EPS : 40
Peak EPS : 2500
Ortalama Peak EPS: 1500
250
Cihazlık bir ağ için
Ortalama EPS : 100
Peak EPS : 6000
Ortalama Peak EPS: 4000
500
Cihazlık bir ağ için
Ortalama EPS : 200
Peak EPS : 12500
Ortalama Peak EPS: 7500
1000
Cihazlık bir ağ için
Ortalama EPS : 400
Peak EPS : 25000
Ortalama Peak EPS: 15000
Önemli
olan sistemin Peak EPS değerlerini karşılayabilmesidir. Ortalama EPS ve
Ortalama Peak EPS sadece storage ihtiyacı için hesaplamada kullanılacak
parametrelerdir.
Arama Hızı
Diğer önemli bir husus da bu loğların ne hızla
raporlara yansıdığıdır. Aşağıda
pek çok raporda Big Data ve Veri arama (Search)
için önerilen ve milyonlarca dolar ciro yapan firmaların search hızları
ile ilgili bir fikir oluşturması açısından alınan örnekleri görebilirsiniz.
Herhangi biri daha hızlıdır diye bir görüş ortaya atmak bu çalışmanın konusu
değildir.
Ticari Ürünlerden Örnek Arama Senaryoları ve süreleri
Aşağıdaki örnekler sadece bir fikir oluşturması
açısından verilmiştir. Fikir oluşturması açısından
Bir fortinate firewalldan gelen SYSLOG paketleri
dosyaya yazılırsa ortalama :
1 000 000 (bir milyon) satır 1 GB lık bir text (ASCII) dosya
oluşturmaktadır.
Örnek Arama Hızları:
Örnek Bir Arama Kriteri:
EPS : 5000
Dakikada oluşan log: 5000 X60 =300 000 (Üçyüzbin)
Saatte oluşan log=300 000 X60=18 000 000 (Onsekiz milyon)
10 Saatte Oluşan log = 18 000 000 X10= 180 000 000
(Yüzseksen milyon)
Yukarıdaki değerlere bakarak 5000 EPS log akışına sahip
bir sistemde 10 saate 180 milyon log oluştuğu ve dolayısı ile herhangi bir 10
saatlik aramanın 180 milyon kayıt arasından olacağı unutulmamalı.
Dolayısı ile son 1 ayda en çok “social media “ da gezen
kullanıcıların listesi ve sıralaması istendiğinde
Eğer 5000 EPS lik bir ağda bu sorgu yapılacaksa
18 000 000 x 24 x 30=12 960 000 000 (yaklaşık 13 milyar) kayıt içerisinde
arama , sayma ve sıralama yapılmak zorunda olduğu unutulmamalı
Eğer seçilen sistem günlük birkaç milyon
log biriktirebiliyorsa (yukarıdaki rakamlarla kıyaslanırsa ne kadar küçük bir
rakam olduğu görülür) log arama handikapları gözle tespit edilemez. Sistemlerin
kapasiteleri milyarlarca log oluştuğunda ortaya çıkar
Kendi Geliştirdiğimiz Sistemlerdeki Durum Nedir?
Benzer arama hızı testlerini ANET yazılım tarafından
geliştirilen ürünlerle yapınca ortaya çıkan durum:
487 milyon kayıt oluşturuldu. Bu kayıtlar içerisinde KAYNAK IP si diğerlerindne farklı farklı olan logu ilk once ve de en sonra
göndererek (Zaman olarak) yaptığıız aşağıdaki fiziksel özelliklere sahip bir
sistemdeki testlerde
487 milyon kayıt içerisinde aranan o iki logu bulma
süresi 60 saniyedir. Bu arama system 6500 EPS log işlemeye devam ederken
yapılan bir testtir
ANET yazılım ürün detayları için
Örnek Bir Arama Kriteri:
EPS : 5000
Dakikada oluşan log: 5000 X60
=300 000 (Üçyüzbin)
Saatte oluşan log=300 000
X60=18 000 000 (Onsekiz milyon)
10 Saatte Oluşan log = 18 000
000 X10= 180 000 000 (Yüzseksen milyon)
Yukarıdaki değerlere bakarak
5000 EPS log akışına sahip bir sistemde 10 saate 180 milyon log oluştuğu ve
dolayısı ile herhangi bir 10 saatlik aramanın 180 milyon kayıt arasından
olacağı unutulmamalı.
Dolayısı ile son 1 ayda en çok
“social media “ da gezen kullanıcıların listesi ve sıralaması istendiğinde
Eğer 5000 EPS lik bir ağda bu
sorgu yapılacaksa
18 000 000 x 24 x 30=12 960 000 000 (yaklaşık
13 milyar) kayıt içerisinde arama , sayma ve sıralama yapılmak zorunda olduğu
unutulmamalı
Bilgilendirme için teşekkürler Ertuğrul Hocam. İletişim Bilgilerinizi paylaşırsanız Log yönetim projeleriyle ilgili görüşmek isterim. Saygılar.
YanıtlaSil