Watchdog İle Bildirim Alma

Bu yıl bitirme projemin bir kısmında watchdog kullandım. Watchdog ile makinemizde meydana gelen çeşitli değişiklikleri izleyebiliriz. Ben sadece dosyalar üzerindeki değişiklikleri izlemek için Pyhon modülünü kullandım.

Benim düşüncem Watchdog'un kullanıma hazır denilebilmesi için eksikleri var. Çünkü dosyalar üzerindeki değişiklikleri izleme işlemini Watchdog'u başka bir yazılım ile bütünleştirerek yapmak çok sağlıklı değil. Örneğin, eğer var olan bir dosyayı değiştiriyorsak o dosya için sırasıyla "Silindi, Oluşturuldu, Değiştirildi" bilgisini döndürüyor  (editörden bağımsız olarak) . Oysa tek döndürmesi gereken bilgi "Değiştirildi" olmalı. Aynı zamanda dosya taşıma işleminde, eğer izlemediğimiz bir yerden dosyayı izlediğimiz alana taşıyorsak "Oluşturuldu" ya da "Taşındı" bilgisini döndüremiyor. 

Burada Watchdog için istenen özellikler, hatalar listelenmiş. Belki dönem içerisinde bende kaynak kodu incelerim. Benim yukarıda bahsettiğim eksikliklerin bir kısmı için Github'a yama gönderilmiş. Ancak ben yamaları koda eklediğimde doğru çalışmadı.

Bu yılki projemde Watchdog'u kullanmam dışında, Necdet hoca "/etc"yi izleyip orada meydana gelen değişiklikleri e-posta gönderen bir betik yazmamı istedi. Bunun için yazdığım kodda oldukça kısa. Buradan ulaşabilirsiniz.

Nagios plugin to monitor Couchbase

I've created CouchBase plugin for Nagios. I used Python for plugin. I put plugin in Github. You can access here. Nagios Plugin Couchbase is available under the GPLv3. Your suggestions and feedbacks will be valued and highly appreciated.


Nagios plugin couchbase supply to monitor a lot of summary statistics:
Cache miss ratio, creates per second, disk read, high and low watermark, set per second, memory usage, operations per second..  etc.

You can monitor vbucket resources with option "--vbucket". You can see all option using "--help" parameter and you should read from Readme for more information about usage. And a screenshot:

Ruby Kodlama Biçimi Önerisi

Bir çok dilde kodlama yapılırken uyulan kurallar var. Aslında bu kurallar bir zorunluluk değil, kodun anlaşılırlığını kolaylaştırmak, kod yazımında bir ortaklık sağlamak için üzerinde anlaşılmış tavsiyeler. Python için bu konuda PEP 8 ile belirlenmiş kuralların bir kısmı. PEP 8 belgesi hakkındaki Türkçe yazıyı da bir üst dönemden Ahmet Can burada yazmış. Oldukça da güzel olmuş yazı.

Ruby ile kodlamayı daha çok sevdiğimden ve genelde Ruby kullandığımdan, Ruby için kodlama standartları nasıl diye biraz araştırdım. Resmi bir belge bulamadım. Ancak Github'da bir kaç belge buldum bu konuda. Bunlardan en çok yıldız alan, en çok kullanılana uymak daha doğru diye düşündüm. Bu belge baktıklarım arasında en çok kullanılan anladığım kadarıyla. Bu yüzden bu belgenin Türkçesini de Github'da tutmaya karar verdim. Ancak bire bir çeviri yapmadım. Yazdığım belgeye buradan ulaşabilirsiniz.

Belgede yazan girintiler 2 boşluk olmalı, fonksiyon yazımları, while kullanımı gibi bir kaç konuda daha Ruby'ciler ile aynı görüşte olduğumu öğrenince pek mutlu oldum :) Mesela bana sorarsanız Python'daki 4 boşluk fazla ama herkes böyle 4 boşluk kullandığından 2'ye düşürmüyorum Python'da, ya da özellikle betik dillerinde çok fazla farklı for yapısı oluyor. Bu durum Ruby'de de böyle. O zaman benim için bu durum kafa karıştırıcı oluyor. Dizi, hash yapısı gibi yerlerde .shift, .each gibi yapılar kullanıyorum. Herhangi bir for yapısını ise while ile sağlıyordum. Bu çevirdiğim belgede de bu durum böyle önerilmiş :)

Bir de belgeyi okurken Ruby ve programlamada bilmediğim kavramları öğrendim.  Duck-typing, factory method pattern gibi kavramları daha önceden duymamıştım açıkçası. Mesela Ruby'de "%" karakterinin dizge (string) yazımında bilmediğim özellikleri varmış, Ruby'de sembol kavramını da daha önce kullanmamıştım. Bu gibi bilmediğim kavramları öğrenmek de bana faydalı oldu. 

Python Uygulamalarına Debian ve Rpm Paketi Yapmak

Yazdığımız uygulamaları paketlemek kullanım açısından oldukça kolaylık sağlar. Eğer yaptığımız projeyi Python kullanarak kodladıysak bir setup.py dosyası oluşturarak hem paket oluşturmak hem de paket oluşturmadan kullanmak için de bir kolaylık sağlamış oluruz. setup.py dosyasında hangi dosyanın sistemde hangi dizin altına kopyalanacağı, proje lisansı, geliştiricisi, web adresi gibi bilgileri tanımlarız. Sadece setup.py'yi kullanarak "sudo python setup.py install" diyerek sistemimize uygulamayı kurabiliriz.

Debian Paketi Hazırlamak:

Debian tabanlı sistemler için paket oluştururken öncelikle bir uygulama içerisinde "debian" dizini oluşturmalıyız. Bu dizin içerisinde mutlaka olması gereken dosyalar ise şu şekilde:

ebru@debian:~/nagios-plugin-couchbase$ ls -ll debian/
toplam 20
-rw-rw-r-- 1 ebru ebru 153 Haz  5 22:00 changelog
-rw-rw-r-- 1 ebru ebru   2 Haz  5 22:00 compat
-rw-rw-r-- 1 ebru ebru 374 Haz  5 22:00 control
-rw-rw-r-- 1 ebru ebru 660 Haz  5 22:00 copyright
-rwxrwxr-x 1 ebru ebru 175 Haz  5 22:00 rules

Bu dosyaların her birini kendimiz elle tek tek oluşturabileceğimiz gibi "debianize" distutils komutunu da kullanabiliriz. Ben ilk önce tüm dosyaları kendim oluşturuyordum ancak bu şekilde biraz zahmetli. Çünkü ürettiğimiz control, changelog dosyalarının basitte olsa kendilerine özel herkes tarafından ortak kullanılan biçimi var. Örneğin changelog dosyasında yıldızdan sonra bir boşluk bırak değişiklikleri yaz, "--" ifadesinden sonra geliştirici adını yaz gibi. Bu tanımlamaları kendim yaparken biraz buradan ve Debian'ın kendi sayfasından yararlanıyordum. Daha sonra burada paketleme işinin daha basit yöntemini gördüm.

$ python setup.py --command-packages=stdeb.command debianize

Yukarıdaki gibi setup.py'yi kullanarak debian dizinimizi ve içerisinde olması gereken dosyaları üretebiliriz. Bu dosyaları ürettikten sonra geriye kalan sadece küçük kontroller oluyor. Zaten bunun sonucunda yukarıda belirttiğim (debian dizini altında) dosyaları oluşturuyor. Eğer setup.py'yi işimizi görecek şekilde doğru bir şekilde yazmışsak her şey debian dizini altında eksiksiz geliyor. Örneğin ben setup.py içinde uygulama adını kelimeler arasında boşluk bırakarak yazdığım için deb paketi üretirken uygulama adını parse edemiyorum gibi bir hata verdi. Bu gibi durumlar oluşmazsa hatasız debian dizini altındaki dosyalarımız oluşacaktır. debian dizini altındaki dosyalarımızın içeriği nasıl diye bakacak olursak:

debian/changelog    # projemizde sürümden sürüme meydana gelen değişiklileri belirttiğimiz dosya.

debian/compat    # Tek satırdan oluşan, debhelper paketinin sürümünü belirtir. debhelper deb paketlerini inşa etmek için kullanılır.

debian/control    # Bu dosyada projenin sürümü, bağımlılık bilgisi, geliştiricisi, lisansı, uygun olduğu mimari bilgisi bulunur.

debian/copyright    # Projeyi kimin hangi lisans ile lisansladığı bilgisi yer alır.

debian/rules    # deb paketini üretmek için bir debian Makefile'dır.

Daha sonra aşağıdaki gibi deb paketimizi oluşturabiliriz:

$ dpkg-buildpackage -rfakeroot -uc -us

RPM Paketi Hazırlamak:

Rpm paketlerinide Fedora tabanlı sistemler için gene setup.py yardımı ile hazırlayabiliriz. Eğer setup.py'mizde bir eksiklik yoksa sorunsuz bir şekilde spec dosyamızı oluşturabiliriz. Ben rpm paketi üretirken ilk başta hata aldığımdan önce sadece bir .spec dosyası üretmeyi denedim. .spec dosyası rpm paketi üretilirken bağımlılık, lisans, geliştirici bilgisi, hangi dosyanın nasıl kopyalanmasının gerçekleştirileceği gibi standartların bulundğu bir dosya. deb paketleri için olan debian dizinin toplanmış hali gibi düşünebiliriz. Direkt rpm paketini "python setup.py bdist_rpm" şeklinde üretebiliriz. Eğer önce benim gibi .spec üretip içeriğine bakmak istersenizde "python setup.py bdist_rpm --spec-only" şeklinde yapabilirsiniz.

Nagios CouchBase Kimlik Doğrulama Eklentisi

Geçen cuma biten sınav haftam ardından hafta sonu NoSql, CouchBase gibi kavramlara baktım. Daha öncesinde çok az bilgim olan bu konulara hakkında yazılmış bloglar okudum. Sonrasında Couchbase kurulumu yaptım. Aslında Couchbase'i kendi yerelimde kurup deneyecektim. Ama benim makinem kaldırmadı. 4 gb ram gerekli, şu gerekli, bu gerekli dediği için kurulumu kesmek zorunda kaldım. Sonrasında daha yeterli başka bir makine üzerinde kurulum yapıp kendi bilgisayarımdan uzaktaki makineye bağlandım.

Couchbase kullanımını öğrenmek için Couchbase'in kendi sitesinden faydalandım. Orada bir çok şey anlatılıyor zaten. Hafta sonu Kaan webten kullanımı nasıl ve Rest Api nasıl gibi kavramlara baksan yeterli olur demişti. Burada anlatılanlar oldukça uzun çünkü hepsini 1 günde kavramam zor olabilirdi :)

Okuduğum kavramlar arasında temel olanlar cluster ve buckettı. Belgede cluster diyerek bahsettiği üzerinde Couchbase'in çalıştığı her bir makine, bucket ise bu makineler üzerinde oluşturulmuş olan veri tabanı. Couchbase'de veriler json belgeler olarak veri tabanında saklanır ve her json belgesi diğer belgeleri değiştirmeye ihtiyaç duymadan içeriği değiştirilebilir. Zaten Couchbase'i hızlı kılan özelliklerden biri bu.

Hafta sonu Couchbase'de kimlik kanıtlaması yapan bir nagios eklentisi yazdım. Nagios eklentisi yazarken Python ile yazıyorsak optparse adında bir kütüphane ile parametre alarak çalışan kodlar yazabileceğimizi bu yazımda belirtmiştim.

Kimlik kanıtlamasını kısmını ise rest api ile http isteği göndererek yapıyoruz. Bu isteklere karşılık dönen durum kodlarının ne anlama geldiği ise burada belirtilmiş. Ben de bu eklentiyi yazarken "import requests" diyerek http isteklerini gönderebilmem için olan kütüphaneyi import ettim. Sonrasında

r = requests.get("http://ip_adress/pools", auth=("username", "password"))
print r.status_code

şeklinde kullanıcı adı ve parola göndererek sistemde kimlik kanıtlaması yapıldığında 200, yapılmazsa 401 kodu döndüren bir eklenti yazmış oldum.

Nagios Plugin Yazma

Nagios ile servisleri izlemek için çeşitli pluginler (eklentiler) kullanır. Bu eklentiler betiklerden oluşur. Ben de geçen hafta python kullanılarak yazılmış bir kaç örnek betik inceledim. Genelde betiklerde izlenen yöntem şu şekildeydi: konsoldan parametreler alıp o parametrelere değer girilme ya da girilmeme durumuna göre cevaplar döndüren betiklerdi. Yazılan kodun konsoldan parametre alarak çalışması için genelde optparse kütüphanesi kullanmışlar.

optparse kullanırken temelde yapılan işlem: sisteme verilebilecek parametreleri tanımlama. Küçük bir örnek ile bakacak olursak:

from optparse import OptionParser
#standart kullanım tanımlaması
parser = OptionParser(usage='%prog [options <arg1> <args2>') 
#parametre tanimlamalari
parser.add_option('-H', dest='hostname')
parser.add_option('-u', dest='username')
parser.add_option('-p', dest='password')
#program calisirken verilen parametreleri optionsa atar
options, args = parser.parse_args()
#bu sekilde istenen durumlar tanimlanir
for option in ('hostname', 'username', 'password'):
    .....
    .....
    .......

Bu şekilde parametre vererek çalıştırabileceğimiz bir betik yazmış olduk. Ben mysql_check eklentisi yazmıştım. Bunun için yukarıdaki koda ek olarak mysql'e bağlanma kısımlarını eklemiştim. Yazdığımız betiği nagios ile birlikte çalıştırabilmek ise şu şekilde:

#linux_remote.cfg dosyasi
define host{
use generic-host
host_name Ubuntu2
alias Ubuntu2Alias
address ip_adres
}

define command{
command_name mysql_check
#betik dosyasinin tam yolunun yazilmasi
command_line $USER1$/mysql_check.py -H host -u username -p paswd
}

define service{
use generic-service
host_name Ubuntu2
service_description MYSQL CONNECT
check_command mysql_check
}

Yukarıdaki $USER1$ makrosu "/etc/nagios3/resource.cfg" dosyası içinde "$USER1$=/usr/lib/nagios/plugins" şeklinde tanımlı olduğu için kullanabiliyorum. Bunu kullanmayıp kendimiz /dosya_tam_yolu/ şeklinde tanımlasak da olurdu. Ayrıca bu kendi yazmış olduğumuz betikten hariç .cfg dosyasını da /etc/nagios3/nagios.cfg dosyası içerisinde tam yolunu aşağıdaki gibi belirtmeliyiz:

cfg_file=/etc/nagios3/linux_remote.cfg

Bir de bu optparse kullanırken şöyle bir hataya düştüm. Ben kendi tanımladığım "-H" parametresini "-h" olarak tanımladım zannedip o şekilde parametre verip çalıştırıp sürekli "usage" kısmının döndürülmesine neden oluyordum. Ben başka bir yerde hata yaptım diye sürekli başka şeyleri kontrol ettim durdum.

Normalde "-h" ya da "--help" seçeneği varsayılan olarak mevcut olan, tanımlanan yardım kısmını geri döndürmek için olan parametreler. --help'in "usage" kısmını döndürdüğü biliyordum, ancak "-H"ı "-h" niyetine kullandığıma dikkat etmemişim. Akşam analiz ödevini yaptıktan sonra gece eklenti yazmaya bakayım derken uzunca bir süre "-h" dediğim için "usage"i döndürdü. Sonra optparse nasıl belgesine tekrar bakayım derken -h'ın --help ile aynı şeyi yaptığını öğrenince  bir an kendimi camdan atmak istedim :)