icerige gec

LOG YÖNETİMİ ÇÖZÜMLERİNİN BAŞARI VE BAŞARISIZLIĞININ NEDENLERİ-1

Mart 4, 2013 yazan ertugrul.akbas

LOG YÖNETİMİ ÇÖZÜMLERİNİN BAŞARI VE BAŞARISIZLIĞININ NEDENLERİ-1

Dr. Ertuğrul AKBAŞ

[email protected]

 

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.

http://www.slideshare.net/anton_chuvakin/csi-netsec-2007-six-mistakes-of-log-management-by-anton-chuvakin

Log Yakalama

 

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.

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.

Örnek SYSLOG Simulatorler:

http://www.theonesoftware.com/syslog_sender.php

http://sourceforge.net/projects/nxlog-ce/?source=directory

Ayrıca bu konuda danışmanlık hizmeti veren firmalar da mevcut

Text Okuyucu

Diğer Bir yöntem de büyükçe bir text dosyayı sisteme verip dosya satır sayısı ile log yazılımındaki kayıt sayısının eşit olduğu zamanı gözetleyip performansını ölçmek.

SNIFFER KULLANIMI

tTcpdump , snoop veya  wireshark benzeri bir yazılımla kontrol etmek

EPS (Events Per Second)

Saniyede işlenen olay demek olan bu parametre sektördeki yazılımların büyük bir kesimi tarafından kullanılan bir parametredir. Aşağıda birkaç hazır EPS hesaplama tablosu mevcuttur

http://www.netcerebral.com/log-management-planning-calculator/#more-125

Diğer Örnekler:

 

 

 Logların Kaydedilmesi (Storage)

 

Aşağıda pek çok raporda Big Data ve Search için önerilen ve milyonlarca dolar ciro yapan firmalarla ilgili bir fikir oluşturması açısından alınan örnekleri görebilirsiniz.

Companies, products, and technologies included in the Big Data Landscape:
- Splunk, Loggly, Sumo Logic
-
Predictive Policing, BloomReach, Atigeo, Myrrix 

- Media Science, Bluefin Labs, CollectiveI, Recorded Future, LuckySort, DataXu, RocketFuel, Turn
- Gnip,
Datasift, Space Curve, Factual, Windows Azure Marketplace, LexisNexis, Loqate, Kaggle, Knoema, Inrix
-  Oracle Hyperion,  
SAP BusinessObjects, Microsoft Business Intelligence, IBM Cognos, SAS, MicroStrategy, GoodData, Autonomy, QlikView, Chart.io, Domo, Bime, RJMetrics

-  Tableau Software, Palantir, MetaMarkets, Teradata Aster, Visual.ly, KarmaSphere, EMC Greenplum, Platfora, ClearStory Data, Dataspora, Centrifuge, Cirro, Ayata, Alteryx, Datameer, Panopticon, SAS, Tibco, Opera, Metalayer, Pentaho
- HortonWorks, Cloudera, MapR, Vertica, MapR, ParAccel, InfoBright, Kognitio, Calpont, Exasol, Datastax, Informatica
-
Couchbase, Teradata, 10gen, Hadapt, Terracotta, MarkLogic, VoltDB,
- Amazon Web Services Elastic MapReduce, Infochimps,
Microsoft Windows Azure, Google BigQuery
-
Oracle, Microsoft SQL Server, MySQL, PostgreSQL, memsql, Sybase, IBM DB2
-  Hadoop, MapReduce, Hbase, Cassandra, Mahout

 

http://www.forbes.com/sites/davefeinleib/2012/06/19/the-big-data-landscape

 

http://mattturck.com/2012/06/29/a-chart-of-the-big-data-ecosystem/

 

 


Log Sıkıştırma

 

Pek çok ihtiyaçtan dolayı logları sıkıştırmak gerekir. Mesela loglar yüksek trafiği olan sunucularda çok fazla yerde kaplar.

Burada 2 önemli özellik vardır.

o   Gerçek zamanlı log sıkıştırma. Yani arşivden yükleme işlemi yapmadan arama yapılabilecek logların sıkıştırılarak saklanması

o   Arşiv loglarının sıkıştırılması

Ürünlerin büyük bir kısmı arama yapılacak verileri sıkıştırmazken sadece arşivi sıkıştırmaktadır.

Log Kendini Eşitleme (Replication)

 

Sistem özellikle regülasyonlar ve/veya kanunlar için kullanılıyorsa replikasyon özelliği öne çıkar. Sistem gerçek zamanlı olarak logların bir kopyasını başka bir server, disk vs.. de tutabilirse eğer mevcut sistemden meydana gelen bir problemde log kaybı yaşanmamış olur

Log Yedekleme

 

Sistem replikasyon desteklemiyorsa bile en azından yedeklenebilmelidir. Burada da yedeklerin alınma süresi ve geri dönme süre ve başarısı önemlidir. Özellikle 100 lerce GB veri oluşunca yedeklerin nasıl alındığı (mesela incremental  ) ve nasıl geri dönüldüğü önemlidir.  Eğer seçilen ürün ona  göre tasarlanmadı ise 10 GB larla veri ile 100 GB lar veri arasında yedekleme başarısı açısından farklılık olma ihtimali yüksektir.

 Log Arama (Log Search)

 

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

 

 

http://splunk-base.splunk.com/answers/36166/from-forwarder-to-index-to-search-is-taking-too-long-roughly-10-to-15-minutes

 

 

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

 

 

http://www.slideshare.net/aungthurhahein/data-mining-column-stores

 

 

http://www.percona.com/docs/wiki/benchmark:ssb:start

 

 

http://www.mysqlperformanceblog.com/wp-content/uploads/2010/08/Infobright_Phase_1_-_Report.pdf

http://www.mysqlperformanceblog.com/2010/01/07/star-schema-bechmark-infobright-infinidb-and-luciddb/


 

Log Arama Alternatifleri

 

Pek çok arama alternatifi olan ürün bulunabilir. Bu alternatifler

·         Logların tamamı anlık arama için aktif veritabanında tutulan ürünler:

o   Burada eğer replikasyon ya da sık aralıklarla yedek alınmazsa verinin kaybı ihtimaline kaşı önlen alınmamış olur

o   Ayrıca arama dosyası büyüyeceği için arama hızları artabilir

·         Logların partionlar halinde canlı veritabanında tutulması:

o   Burada eğer replikasyon ya da sık aralıklarla yedek alınmazsa verinin kaybı ihtimaline kaşı önlen alınmamış olur

o   Partition yapısı hızlandırma sağlayabilir

·         Arşivden logları canlı veritabanına aktardıktan sonra arama

o   Canlı veritabanına yükleme süresi overhead olarak eklenecektir.

·         Yukarıdaki sistemlerin bir yada birkaçını aynı anda destekleyen sitemler.

Proje ihtiyaçlarına göre yukarıdaki alternatiflerin değerlendirilmesi gerekir.

 

Örnek Bir Arama Kriteri:

EPS : 5000

Dakika oluşan log: 5000 X60 =300 000 (Üçyüzbin)

Saatte oluşan log=300 000 X60=18 000 000 (Onsekiz milyon)

10 Satte 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ı

 

Proje Ekibi

 

Bir log Yönetimi projesinde %60 ürün etkiliyse %40 bu ürünü uygulayan ekip önemlidir.

 

Detayları için

http://www.scribd.com/doc/128270900/LOG-YONET%C4%B0M%C4%B0-COZUMLER%C4%B0N%C4%B0N-BA%C5%9EARI-VE-BA%C5%9EARISIZLI%C4%9EININ-NEDENLER%C4%B0-1