Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Log yonetimi tecrubeleri

1,101 views

Published on

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.

  • Be the first to comment

  • Be the first to like this

Log yonetimi tecrubeleri

  1. 1. Log Yönetimi Tecrübeleri eakbas@gmail.com 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 o o Sistemin ürettiği verinin Log Yönetim yazılımı tarafından karşılanamaması 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.. 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. http://www.slideshare.net/anton_chuvakin/csi-netsec-2007-six-mistakes-of-log-management-byanton-chuvakin
  2. 2. 1 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. Log Yönetimi projelerinin demo aşamalarında en önemli parametrenin atlandığı ve bundan dolayı aslında amaca hizmet etmeyen ya da lazım olduğunda işe yaramayan, aranan verinin bulunamadığı bir kurulum ortaya çıkmış olur. Bu parametre kurulan sistemlerin vaat edilen EPS değerlerini sağlayabilmeleridir. 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: http://www.theonesoftware.com/syslog_sender.php http://sourceforge.net/projects/nxlog-ce/?source=directory http://sourceforge.net/projects/syslog-slogger/ 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.
  3. 3. 2 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. Bunun için ANET yazılımdan destek alınabilir info@anetyazilim.com.tr Ya da üçüncü bir parti yazılım kullanılmak istenirse aşağıdaki linkteki ürün kullanılabilir
  4. 4. 3 http://sourceforge.net/projects/syslog-slogger/ 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;.3rdPartySyslog.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.
  5. 5. 4 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
  6. 6. 5 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>>/<<11024>> (<<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>>/<<11024>> (<<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>>(<<1000050000>>) -> 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.10192.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.
  7. 7. 6 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
  8. 8. 7 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.
  9. 9. 8 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ı: http://splunk-base.splunk.com/answers/5987/is-there-any-way-to-speed-up-searches http://splunk-base.splunk.com/answers/50503/reducing-time-taken-for-search-in-splunk-query
  10. 10. 9 http://splunk-base.splunk.com/answers/36166/from-forwarder-to-index-to-search-is-taking-too-longroughly-10-to-15-minutes
  11. 11. 10 http://splunk-base.splunk.com/answers/54306/reasonable-search-performance http://splunk-base.splunk.com/answers/12559/searches-taking-long http://splunk-base.splunk.com/answers/13354/slow-search-for-squid-for-a-30-days-report
  12. 12. 11 Ö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
  13. 13. 12 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 http://www.anetyazilim.com.tr/Downloads/doc/tr/log_management_compare/ANE T_Log_Compare.pdf
  14. 14. 13 Ö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ı

×