Pazartesi, Mayıs 04, 2015

Splunk App for Active Directory kurulumu

Splunk'u giderek seviyorum ama hakkını vermek lazım, beni çok uğraştırıyor. Bence dokümantasyonu dolgun ve yeterli gibi görünse de kafa karıştırıcı. İşleri sıralı bir prosedür ve birbirini takip eden konular halinde anlatamıyor sanırım. Ya da ben anlamakta zorlanıyorum, bu da ihtimal dahilinde elbet. :)

"Splunk app for Active Directory" konusunda da önceki postalarımdakinin aynısı oldu. Prosedürü aynen uyguladım. Çalışmadı, beklediğim sonucu vermedi. Uğraştım, forumlara yazdım, prosedürleri üçüncü, beşinci kez okudum. Yine olmadı. En sonunda da bilimselliğe aykırı olarak "kendiliğinden" düzeldi.

Bu "kendiliğinden" oldu veya "zamanla düzeldi" beni sahiden de illet eden bir açıklama türü ama mantıklı açıklamasını bulamadığım zamanlarda başvuracak başka bir yol kalmıyor malesef.

Neyse, biz ne yaptık da ne oldu kısmına geçelim lafı uzatmadan.

1- Splunk içinden "Active Directory app" yüklenir.


2- Splunk içinden "Universal forwarder" tarafından gönderilecek veriyi dinleyecek bir alıcı (receiver) oluşturulur.


3- Universal Forwarder DC'ye kurulurken , ben bir deployment server kullanmadığım için bu adımı boş geçtim.

4- Splunk serverı işaret edilecek. Port, daha önce oluşturduğumuz alıcı ile aynı port. Dikkat !


5- SSL sertifikasını boş bıraktım.

6- splunk adında bir AD hesabı oluşturdum ve minimum Account operator yetkisi verdim. Daha fazlası veya azından kurulum belgelerinde bahsedilmiyor, tedbiren :) DC'ye kurduğumuz için re

7- Hiç bir girdi türünü seçmedim. Normal olarak kurulumun bu adımdan sonra başarıyla tamamlanması ve servisin çalışması gerekiyor.




Perşembe, Nisan 30, 2015

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. :)


Cuma, Nisan 17, 2015

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 :)


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.

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

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


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.



Çarşamba, Mart 18, 2015

VMware / Troubleshooting Network Teaming Problems with IP Hash

Bir süredir ihmal ediyorum buraları. Tekrar dönmeye karar verdim.

Bugün bir müşterimizde konusu geçti. IP hash / EtherChannel kullanımında maksimum bant kullanımını nasıl sağlarım ? diye sordu. Dilim döndüğünce anlattım tabi. Ancak güzel bir makale ile desteklemek istedim. Ektekini buldum.

http://blogs.vmware.com/kb/2013/03/troubleshooting-network-teaming-problems-with-ip-hash.html

Troubleshooting Network Teaming Problems with IP Hash