log yÖnetİmİ ÇÖzÜmlerİnİn baŞari ve baŞarisizliĞinin nedenlerİ-1

17
LOG YÖNETİMİ ÇÖZÜMLERİNİN BAŞARI VE BAŞARISIZLIĞININ NEDENLERİ-1 Dr. Ertuğrul AKBAŞ

Upload: ertugrul-akbas

Post on 26-May-2015

333 views

Category:

Documents


10 download

DESCRIPTION

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.

TRANSCRIPT

LOG YÖNETİMİ ÇÖZÜMLERİNİN BAŞARI VE BAŞARISIZLIĞININ NEDENLERİ-1 Dr. Ertuğrul AKBAŞ

1

Log Yakalama ................................................................................................................................................. 2

SYSLOG Simulator ...................................................................................................................................... 2

Text Okuyucu ............................................................................................................................................. 2

EPS (Events Per Second) ............................................................................................................................ 2

Logların Kaydedilmesi (Storage) .................................................................................................................... 4

Log Sıkıştırma ............................................................................................................................................. 8

Log Kendini Eşitleme (Replication) ............................................................................................................ 8

Log Yedekleme .......................................................................................................................................... 9

Log Arama (Log Search) ................................................................................................................................. 9

Ticari Ürünlerden Örnek Arama Senaryoları ve süreleri ........................................................................... 9

Log Arama Alternatifleri .......................................................................................................................... 15

Proje Ekibi .................................................................................................................................................... 16

Keywords: Log Sıkıştırma, Log Arama (Log Search) ,Replikasyon (Replication), Log kaybı, Log Yedekleme,

Big Data, SYSLOG Simulator, Log Simulator, EPS, Events Per Second, Bilgi Güvenliği, ISO 27001,

Regulasyonlar, 5651 ,5651 Sayılı Yasa, Log Storage, Log Yönetimi projelerinde karşılaşılan problemler, Log

yönetiminde yapılan hatalar, Log Arşivleme,

Giriş

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

2

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

3

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

Diğer Örnekler:

4

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

5

6

7

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

8

http://www.informationdifference.com/

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

9

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

10

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

11

http://splunk-base.splunk.com/answers/54306/reasonable-search-performance

http://splunk-base.splunk.com/answers/12559/searches-taking-long

12

http://splunk-base.splunk.com/answers/13354/slow-search-for-squid-for-a-30-days-report

13

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

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

15

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

luciddb/

620 GB Data

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.

16

Ö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.