Splunk kullanım testleri (1)

Şeytan dürttü, Graylog ile aynı ortamda Splunk kurarak bir karşılaştırma yapayım dedim. Çerçevesini iyi belirlemek gereken bir karşılaştırma olduğunu farkındayım. Splunk gibi çok güçlü bir ürünle açık kaynak Graylog'u işlevsellik açısından yarıştırmak gibi bir hataya düşmeyeceğim. Amacım aynı gelen verinin her iki sistem üzerinde birbirine göre ne gibi farklılıklar oluşturduğunu, kaynak ve lisans kullanımını nasıl değiştirdiğini görmek gibi nesnel sınırlarda kalmak olacak.

Graylog'u 7 ESX 5.5 sunucusundan gelen logları izlemek üzere kurmuştum. Tüm ESX'lerde syslog yönlendirmesi bu CentOS sunucuya ve üzerindeki rsyslog'a yapılmıştı. Rsyslog da aynı sunucu üzerindeki Graylog'a 10514 (UDP) portuna syslog yönlendiriyordu.

Splunk'u ayrı bir CentOS sunucusu üzerine kurdum. Graylog'un rsyslog'undan da bu sefer 514 (UDP)'ye yönlendirme yaptım.

Ortaya çıkan sonuçlar bana göre ilginç oldu :

7 tane ESX sunucusundan asgari Info ve üstü seviyeden gelen loglar (Toplamda 100 VM var) Splunk'da gayet düşük yer kaplıyor. Bu anlamda disk kullanımının "makul" olduğunu söyleyebiliriz. Bakınız, üstteki görüntü.

7 tane ESX sunucusunun sysloglarını barındırdığımız CentOS sunucusu alışkanlık olduğu üzere mütevazi kaynaklara sahip. Altta orta-seviye bir disk depolama sisteminde çalışan 2 GB RAM ve 2 vCPU'su olan bir sunucu kullandım. Yukarıdaki görüntüden de anlaşılacağı üzere 4 milyon satır üzerinde kayıt birikmiş durumda ve indeksleme-arama sonuçları yine makul ve üstü düzeyde.

Gelelim konunun can alıcı kısmına. Yine hatırlatmak için söyleyeyim Splunk'un lisans kullanımını etkileyen şey dışarıdan gelen verinin Splunk'da depolanma durumu. Günlük 500 MB'a kadar sistem herhangi bir lisans ihlali üretmiyor.
Yukarıdaki grafik bu bağlamda incelendiğinde yine olumlu bir durum görmekteyiz. 100 VM'in koştuğu , 7 ESX sunucunun olduğu bir ortamda üretilen syslog verisi Splunk için günde 50 MB'ı aşmıyor. Bu, kendi ortamlarımızda ölçeğin hesaplanabilmesi için çok değerli bir bilgi sanırım.

Genelde lisans kullanımı %25'in üzerine çıkmamış.

Toplamda son 7 günde 250 bin kaydın depolandığı görülüyor. Bunun +/- %20 kadar sapması olabileceğini düşünüyorum. O konulara da ayrıca başka bir yazıda gireriz. :)

Graylog kullanım örnekleri (3)

Bu Graylog kağıt üzerinde kulağa hoş geliyor da, bunu gerçek hayatta nasıl kullanırız ? şeklinde sorular almaktayım. Tam da bu aralar sorular artmışken, yaşanmış bir olayda Graylog'u kullanma imkanı bulduk. Onu aktarmak isterim.

Müşteri, "kurduğunuz ESX 5.5 ortamında yavaşlama var, nedenini anlayamıyoruz..." şikayetiyle başvurdu. Tüm ESX sunucuları, storage kaynakları, SAN switchler vs.de yaptığımız incelemelerde performans grafikleri üzerinden hiç bir dalgalanma ve ani değişim göremedik. Güzel bir senaryo, şikayet var ama belirti yok :)

Neyse ki tüm ESX sunucularından logları Graylog'a yönlendirmiştik. Yaptığımız taramada [Warn] seviyesinde ESX sunucularının hakikaten şikayet etmeye başladığını gördük.

Sonra başka şeyleri kurcalamaya başladık. İş Qlogic HBA kartlarının firmware güncellemesine kadar gitti. Ancak diğer taraftan bir şekilde vCenter 5.5 sunucusunda SQL express ile kurulum yapılmış (biz değiliz :) ) ve SQL express 2008'in veritabanı maksimum büyüklüğüne erişilmiş olduğunu gördük. Eski veriyi silmeye başladık.

Sabah her şey yolundaydı. Yavaşlık bitmiş, müşteri mutlu. Ancak ESX sunuculardaki yavaşlık ile vCenter SQL DB'sinin dolmasını nasıl korele edersiniz ve bunu müşteriye anlatırsınız ? Normal şartlar altında algı sorunu SAN / Network tarafında aramaya meyilli olduğundan anlatmak da zor, ikna etmek de. Ancak dikkatli birisi, mesai sonrası saatlerde sistemi izliyor olacak ve SQL shrink bittiğinde de yavaşlığın kesildiğini gözlemleyecek. Her babayiğidin harcı değil. Ayrıca müşteriden bunu beklemek de haksızlık bir anlamda. Son olarak, bu iki başlığı birleştiren aramalarımda da net bir KB veya forum bilgisine rastlamadığımı ekleyeyim.

Aşağıdaki grafik her şeyi gösteriyor. Olaya konu olan hata mesajları bazında yapılan bir arama sonucu ve grafiğine göre, akşam 19.00 itibariyle shrink bittikten sonra ESX sunucularından gelen olaylar bıçakla kesilir gibi kesilmiş. Doğru kelime dizgileri ve basit mantıksal operatörlerle elde edilen ikna edici bir gösterge. Bunu sözle söylemek farklı, grafikle ispat etmek farklı.

Daha ne olsun :)

Graylog kullanım örnekleri (2)

Basit bir graylog sunucusunun nasıl kurulacağı hakkında İngilizce çok sayıda yazı görüyorum ancak Türkçe kaynak sayısı oldukça kısıtlı. Bu çorbada tuzum olmasını istedim ve denenmiş, kontrolleri yapılmış bir kurulum prosedürünü yayınlamak istedim.

Bu ortam 2 GB RAM ve 2 vCPU kullanan bir CentOS 6.6 üzerinde çalıştırılmıştır. Günde 2 milyon satıra yakın log toplayabileceği test edilmiş ve görülmüştür.

Genel

---

# chkconfig iptables off

# service iptables stop

# vi /etc/selinux/config

     SELINUX=disabled

Java yüklemesi

---

su -c "yum install java-1.7.0-openjdk"

Elasticsearch

---

# rpm --import https://packages.elasticsearch.org/GPG-KEY-elasticsearch

# vi /etc/yum.repos.d/elasticsearch.repo

     [elasticsearch]

     name=Elasticsearch repository for 1.5.x packages

     baseurl=http://packages.elasticsearch.org/elasticsearch/1.5/centos

     gpgcheck=1

     gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch

     enabled=1

# yum install elasticsearch

# chkconfig elasticsearch on

# vi /etc/elasticsearch/elasticsearch.yml

     cluster.name: graylog2

# service elasticsearch start

MongoDB

---

# vi /etc/yum.repos.d/mongodb.repo

     [mongodb]

     name=MongoDB Repository

     baseurl=http://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/x86_64/

     gpgcheck=0

     enabled=1

# sudo yum install -y mongodb-org

# chkconfig mongod on

# service mongod start

graylog

---

$ sudo rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-1.0-repository-el6_latest.rpm

# yum install graylog-server graylog-web

# chkconfig graylog-server on

# chkconfig graylog-web on

# echo -n AbraKadabra |sha256sum

     c57043562419912d3b15e1679665994d329a2f9a379b4b16a524456bdc396dec

# vi /etc/graylog/server/server.conf

     password_secret = AbraKadabra

     root_password_sha2 = c57043562419912d3b15e1679665994d329a2f9a379b4b16a524456bdc396dec

     root_timezone = Europe/# Email transport

     transport_email_enabled = true

     transport_email_hostname = mail.firma.com

     transport_email_port = 25

     transport_email_use_auth = false

     transport_email_use_tls = false

     transport_email_use_ssl = false

     #transport_email_auth_username = you@example.com

     #transport_email_auth_password = secret

     #transport_email_subject_prefix = [graylog2]

     transport_email_from_email = graylog2@firma.com

# vi /etc/graylog/web/web.conf

     graylog2-server.uris="http://127.0.0.1:12900/"

     application.secret="AbraKadabra"

     timezone="Europe/Istanbul"

# service graylog-server graylog-web start

Web arayüzü

---

TCP ve UDP 10514 syslog inputları oluşturulur.

Graylog kullanımı örnekleri (1)

Splunk’un aşırı yüksek lisans ve EPS maliyetleri nedeniyle uzun zamandır ihtiyaçlarımı görecek bir log yönetim yazılımı arıyordum. Aradığım yazılım yüksek hızda indeksleme yapabilmeli, performansı Splunk’ı aratmamalı, yani aslında Splunk’ın ücretsiz hali gibi bir şey olmalıydı. Çıtayı Splunk seviyesinden koyarak doğru mu belirliyoruz bu seviyeyi emim değilim ama net olan şu, Splunk  malesef fazla pahalı. Splunk Light ile $75 / ay fiyatlı daha düşük kapasiteli bir ürün ile bu dezavantajı kapatmaya çalışıyorlar ancak fiyat / EPS / depolama kapasitesinin yaratacağı sıkıntılar nedeniyle ben Türkiye pazarında Splunk Light’ın tutunacağına inanmıyorum. O nedenle bu seçenek de benim için ihtimal dışı.

Diğer yandan da kabul etmek lazım ki, Splunk iyi bir ürün. Belki de endüstri standartı oldu. VMware’in de ürünü kendisine entegre etmesi bunun bir göstergesi. Vazgeçmemek adına ücretsiz halini kullanmak istesek bile, olaylarda eposta gönderimi yapma özelliğinin kapalı olması büyük handikap. Bu imkanı göz ardı ederek yine de Splunk kullanırım ! diyenlere ancak hitap ediyor bu haliyle. Ben ise malesef ihtiyaçlarımı listelediğimde olaylar karşısında eposta ile uyarı iletme özelliğinden vazgeçemiyorum.

Elasticsearch tabanlı Logstash/ Kibana ve Graylog ikilisini bu anlamda bir süredir takip ediyor ve deniyorum. Bugün bunlardan Graylog hakkındaki düşüncelerimi yazmaya çalışacağım. Graylog’u 0.80 sürümünden bu yana takip ediyorum. O dönemlerde kurulumu da daha zordu, kullanımı da. Oysa ki 1.0.x sürümleriyle birlikte gerçekten olgunlaştı. Küçük sanal Linux sunucuları üzerinde bile çalıştırır ve yönetebilir hale geldim. Şu an bir müşterimdeki tüm VMware ESX sunucuları, VMware Horizon View sunucuları ve Hitachi HUS storageları bu yazılım üzerinden izliyorum..

Günde yaklaşık 1 milyon satır log topluyorum. 8 GB RAM / 50 GB diski olan bir Centos 6.x sunucuda takır takır çalışıyor.

Syslog deyince tabi irkilenler olabilir. Malum üreticilerin çoğu RFC 'lere uygun syslog üretmiyorlar. Bu nedenle de Graylog gibi yazılımların bunu anlaması zor olabiliyor. Nitekim ESX 5.x sunucularından gelen syslog'u Graylog anlamakta ve yerleştirmekte sorun yaşadı. Biraz araştırmak zorunda kaldım ama doğru Rsyslog şablonunu yazınca bu sorun da çözüldü.

Yaşanan başka bir sorun da (aşılması güç değil) Mongo DB ile oluyor. Cache loglarının diski doldurmasını engellemek için küçük log ayarına dönmek yeterli oluyor.

En rahat çalıştığım loglardan biri de VMware Horizon View logları oldu. Doğru şablonla çalışınca bu loglar da sisteme rahatça alındı ve yapılandırıldı.

Şimdilik memnunum. Uzun zamandir kullanıyorum ancak bu kadar olgunlaşmasını beklemek iyi oldu bu konu hakkında yazmaya başlamak için sanırım. Doğru zamanlama. İzlenimlerimi paylaşmaya devam edeceğim.