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 etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
graylog etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Cuma, Nisan 17, 2015
Perşembe, Nisan 09, 2015
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.
# chkconfig iptables off
Java yüklemesi
TCP ve UDP 10514 syslog inputları oluşturulur.
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
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
# 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.
Perşembe, Nisan 02, 2015
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..
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.
Kaydol:
Kayıtlar (Atom)
