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.

Kubuntu 10.10 > 11.04 > 11.10 güncelleme, logon problemi

Sony vaio laptopumda uzun süredir Kubuntu 10.10 kullanıyordum ve oldukça memnundum. Sonra şeytan dürttü ve diğer kurulum olan Ubuntu'yu 11.10'a güncelleyip güzel bir performans elde edince Kubuntu'yu da güncelleyeyim dedim.

Halbuki Kubuntu'yu dikkatli kullandığım için onun başına kolay kolay bir şey gelmesine izin vermiyorum. Neyse, dediğim gibi şeytan dürttü.

Grafik oturumdan 11.04'e güncellemeyi tamamlayınca, ilk logon hayal kırıklığı oldu. Kullanıcı adımı ve şifremi girdikten sonra gelen splash screen'deki ikonlardan sonuncusu olan KDE çarkını bir türlü ekrana getiremiyor ve masaüstünü açamıyordum. Uğraştım, ettim ama beceremedim.

Sonra CTRL+ALT+F1 ile komut satırını açtım ve oradan 11.10'a güncellemeyi tamamladım. Bu sefer herhalde olur diye düşünüyordum.

Ama yine olmadı.

Bu arada okuduğum makalelerdeki soruna neden olabileceği söylenen kablosuz bağlantıyı hem 11.04'de hem de 11.10'da defalarca pasif hale getirip denedim ama hiç birinde giriş yapamadım.

Neyse, 11.10 kurulumu bitince tam da umutsuzluğa kapılmak üzeeyken logon ekranında KDE failsafe ile açmak geldi aklıma. Bingo ! Bu sefer girdim. İlk iş olarak da NVIDIA sürücüsünü mevcut 96 sürümünden 17x (pre-release vs. birşey) haline güncelledim.

Kapattım, açtım. Çalıştı :)

Ardından da kablosuz bağlantıyı aktif hale getirdim. Yine çalıştı.

Rahatladım yahu... :)

connection reset by peer : sshfs

Bir linux sunucusundan başka bir linux sunucunun loglarını okumak üzere Apache log dizinini mount etmek istediğimizde aşağıdaki hata mesajını aldık.

Mevcut şartlar :

-Makine tanıdık bir arkadaşın (şüpheli bir şey olma ihtimali var yani)

- public key kopyalandı.

- ssh ile bağlantı sağlanabiliyor ama sshfs çalışmıyor.

$ /usr/bin/sshfs -o sshfs_debug zurafa@1.2.2.2:/var/log/httpd /tmp​

SSHFS version 2.2

zurafa@1.2.2.2.'s password: 

read: Connection reset by peer​

​Hasta etti beni, açık söyleyeyim. İnsan 1s15dk salak bir makineye sshfs bağlanmak için zaman kaybeder mi ? Ettik tabi ki.

Neyse ki aşağıdaki sayfadaki kontrol listesi bize yardım etti. Olay şu ; bağlantı yapılacak sunucudaki sftp-server servisinin aktif olması lazım. Bu makineyi kim kurmuşsa (muhtemelen eski arkadaşlardır) servisi kapatmış.

Bu linkte ilgili makale var. 

http://www.masaokitamura.com/2008/11/how-to-fix-sshfs-connection-reset-by-peer/

Bu makale de olayla ilgili daha güzel bilgiler veriyor.

http://linux.dsplabs.com.au/sshfs-read-connection-reset-by-peer-p73/​

Installing VRTSralus 12.5.2213 on xxxx Unable to copy

Backup Exec 12.5 Linux agent’ını CentOS sunucularına yüklerken aşağıdaki gibi bir hata mesajı alıyordum.

Installing VRTSralus 12.5.2213 on xxxx Unable to copy, /home/tomcat/gecici/Backup\ Exec Linux/RALUS64/pkgs/Linux/VRTSralus.tar.gz, on xxxx to, /var/tmp/vxif/RALUS/VRTSralus, on xxxx

…………………………………………………… failed to install

BE agent’ın olduğu tar dosyasını “Backup Exec Install” adında bir klasöre açmışım. Farkedilebileceği üzere arada boşluk karakterleri var. Bu boşluk karakterlerini kaldırınca yükleme sorunsuz gerçekleşti.