Couchbase 2.x İçin nagios-plugin-couchbase Güncellemesi

nagios-plugin-couchbase, iki yıl önce Necdet Yücel'in düzenlediği Yakından Eğitim ile ortaya çıktı. Bu projeyi Kaan'ın danışmanlığında geliştirdim. Daha önce kullanmadığım Nagios, Couchbase'i kullanmam ve NoSQL kavramlarını öğrenmem bakımından oldukça faideli bir proje olmuştu :).

Projeye ilk başladığımız zamanlar geliştirimi Couchbase 2.0 üzerinde yapıyordum. Şimdi Couchbase 2.x serisi kararlı halde ve 3.0'ın beta aşamasındalar. Ben de eklentiyi güncelledim ve artık Couchbase 2.x ile uyumlu diyebiliyorum :).

Eklentiye birkaç yama gönderilmişti onları aldım, bir de her güncellemede yeniden .cfg oluşturması uzun sürmesin diye örnek bir dosya ekledim. Bu arada proje aynı zamanda nagios-exchange'de de yer alıyor ^_^.

Bu projeyi geliştirmemi sağlayan Yakından Eğitim ekibine teşekkürler.

Yakından Eğitim Projem Nagios Exchange'de Yer Aldı

Nagios Exchange Nagios için yazılan belgeler, eklentiler, Nagios ile birlikte çalışan uygulamaların yer aldığı resmi sistesi. Kaan ile birlikte üzerinde çalıştığım Yakından Eğitim projesi olan nagios-couchbase-plugin'in Nagios Exchange'de yer alması için dün istekte bulundum ve bugün Nagios Exchange'den proje kabul edildi maili aldım :)

 Eklenti eğer resmi sayfada yer alırsa daha çok kullanılır ve daha yararlı olur diye düşündüm. Projenin linkine 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:

Yakından Eğitim Projemde Son Durum

Üzerinde çalıştığım Yakından Eğitim projesi olan Couchbase'i Nagios üzerinden izlemek için yaptığım eklentide geçen haftadan bu yana eksiklerin büyük kısmını kapattım. Sınav haftam nedeniyle danışmanımdan izin almıştım. Zaten final dönemi sıkıştırdığından 10 gün daha proje bitirme süresi uzatıldı.

Eklentiyi ilk şuan master dalında bulunan haliyle yayınlamıştım. Ordaki hali sorguyu sadece düğüm (node) seviyesinde yapıyordu ve Couchbase üzerindeki daha az özelliği kontrol ediyordu. Bu hafta githubda yapmam gereken bulabildiğim özellikleri ekledim. Ayrıca Rest Api kullanarak sorguları küme (cluster) seviyesinde yapılmasını da sağladım. Deb ve Rpm paketleri için bir alt yapı hazırlayıp, proje Readme'sini oldukça genişlettim. Eklenti web arayüzünden kullanılabildiği çıktılar konsolda ekranada dökülebildiği için "--help" ile çalıştırıldığında parametrelerinin açıklamasının görülmesini sağladım ve bir de uygulama için man sayfası hazırladım. En son dün kodu PEP 8 ile uyumlu hale getirdim.

Aslında projenin devel dalındaki hali bile şuan alınıp kullanılabilir durumda. Hatta bu hafta master ve devel dallarındaki halini alıp deneye bir kaç arkadaş projeye yönelik geri bildirimde bulundu.  Oldukça mutlu oldum bu duruma. Projeyi buradan alıp deneyebilirsiniz hata bildirimi, özellik ekleme gibi geri bildirimlerde bulunulursa da oldukça mutlu olurum :)

Rest Api ve cbstats kullanarak CouchBase'den Bilgi Çekme

Bu hafta Nagios CouchBase eklentisinde eksik kalan kısımları tamamladım. Vbucket resources, disk queues gibi diğer alanlar eksikti. Ancak eklemem gereken yerlerin bir kısmını bulamadım. Couhcbase'den bu istatistikleri alabilmek için şuan "cbstats" komutunu kullanıyorum. En başta Rest api ile istatistikleri alırken daha sonra Rest Api ile bu istatistiklerin büyük bir kısmını bu şekilde alamayacağımı düşünüp "cbstats" kullanmaya başladım. Madem cbstats kullanıyorsam tüm bilgiyi onula çekeyim diye tüm kodu cbstats ile kullanılabilecek hale getirdim.

cbstats ile bilgi çekme şu şekilde:

./cbstats ip:11220 all -b bucket_name

"all" dediğimde bucket için olan tüm bilgiyi döndürüyor. İlgili alanı string üzerinde oynayarak elde ediyorum.

cbstats kullanmaya karar verdiğim akşam cbstats çıktısını nasıl anlamlandırıp hangi alan, web arayüzündeki değere karşılık geliyor diye nasıl bulacağımı düşünürken şunu fark ettim. cbstats komutunda değerler "vb_active_ops_update", "delete_hits" şeklindeki stringlere karşılık gelen değerler şeklinde dönüyor. Web arayüzünde de bilgisini çekmek istediğim alanın üzerine fare ile gelince ilgili alanın hangi değerler üzerinde işlem yapılarak hesaplandığı yazıyordu. Bunu bir kaç durum için kontrol edince cbstatsın değerleri byte olarak döndürdüğünü ve arayüzdeki belirtilen değerlerden bu sonuçların elde edildiğine emin oldum. Zaten "cache_miss_ratio" değerini kontrol etmeyi eklentiye ekleyecekken coucbase listesinde "cache_miss_ratio" nun hesaplanma şeklinin web arayüzünde fare ile üzerine gelince hesaplanan değerlerden oluştuğunu görünce emin oldum. Aslında hangi alanın cbstats'ın hangi çıktısına geldiği belgesinde de yazılı ancak hepsi yazılmış değil.

Bu haftaki eksikleri tamamlamak için baktığımda ise eksik kalan istatistikleri "cbstats" ile hesaplatamadığımı fark ettim. Aslında bir cevap dönüyor geriye ancak bu web arayüzünde gördüğümden farklı ve olması gerektiği değere nasıl dönüştüreceğimi bulamadım ve bu her istatistik için geçerli değil. Bazılarında durum bu şekilde. Listede Rest api kullanarak tüm istatistikleri bulabileceğimin önerilmesi ile birlikte Rest apide dönen değerler için bazı istatistik değerleri web arayüzündekinin aynısı. Ancak direkt arayüzdekinin aynısı bilgi döndüğü için, dönen değer gb mı, mb mı bilemiyorum. Bu iyi bir şey değil. Çünkü ben eklentiye birim bilgiside eklesem iyi olur :) Ve Rest api kullanarak da gene cbstats da olduğu gibi dönen değeri web arayüzdeki biçime dönüştüremiyorum. Çok bir şey değişmedi aslında bu durumda. Yani eklemem gereken istatistik bilgisi için bir cevap bulabiliyorum ancak webdeki ile aynı biçimde olmuyor. Bu durum cbstatsda da böyleydi. Muhtemelen yanlış bilgi dönmüyor ancak Rest apide elde ettiğim cevaplarda bir dizi içinde aynı değer 43 kere yazıyor gibi bir durum var. Ve webdeki bilgi ile aynı değil. Bu bilgiyi webdeki gibi anlamlı şekle nasıl dönüştürebilirim diye listede sordum. Ancak henüz cevap alamadım ve CouchBase belgesinde de bu yazılı değil, başka kaynak da bulamıyorum açıkçası.

Ben en başta Rest api ile bir çok bilgi eksik kalıyor zannettim dediğimde Rest apide dönen cevapta "streaming uri" gibi kısımlar var. Buradaki uri bilgisiyle bir kez daha http request isteğinde bulunduğumda ilgili alanları elde edebiliyorum. Bu istek için olan uri ise şu şekilde:

"ip:8091/pools/default/buckets/test_bucket/stats/vb_active_num"

Aslında burada son kısımda belirtilen "vb_active_num" alanı bilgisine "cbstats" ile de ulaşabiliyorum. Bu uri ile "vb_active_num" bilgisine ulaşacağımı

ip:8091/pools/default/buckets/default/statsDirectory

urisini kullanarak elde ediyorum. En başta cbstats ile arayüzde hesaplanan değerleri elde edebileceğimi bilmeden de buraya ulaşamazdım aslında.

Son olarak web arayüzde belirtilen "summary" kısmını eksiksiz olarak eklentiye ekledikten sonra projeyi paketleme ve belge yazma kısmına geçmeme karar verdik.

Nagios'da Kullanıcı Oluşturma

Nagios'da web arayüzünden kimlik kanıtlaması yaparak sistem durumunu inceleyebiliriz. Bu durumda birden fazla farklı yetkilere sahip kullanıcılar oluşturumamız gerekebilir. Örneğin bir kullanıcı sadece web arayüzündeki bilgileri okusun ancak değiştiremesin (read-only) istiyorsak şu şekilde yapmalıyız. Öncelikle belirlediğimiz kullanıcı adı ve parolayı "htpaswd" komutuyla "/etc/nagios3/htpasswd.users" dosyasına yazdırmalıyız.  "htpasswd htpasswd.users testuser" diyerek "testuser" isimli bir kullanıcı adı ve parolası belirlemiş olduk. htpaswd komutunun bir miktar parametresi var. Şifrelenmesi gereken parolanın şifreleme algoritması türünü seçebiliriz, parolayı düz metin olarak tutabiliriz, oluşturduğumuz kulllanıcıları silebiliriz gibi.

Oluşturduğumuz bu kullanıcıya sadece webten okuma yetkisi vermek ise şu şekilde:
Öncelikle "/etc/nagios3/cgi.cfg" dosyasında muhtemelen yorum satırı halinde bulunan "authorized_for_read_only=" satırının başındaki "#" kaldırıp oluşturduğumuz kullanıcı adını ekliyoruz. Zaten cgi.cfg dosyasından oluşturulan kullanılacalara hangi yetkileri verebileceğimiz ile ilgili bilgiler var. Oradan istediğimiz özellikleri açabiliriz.

Oluşturduğumuz kullanıcıyı contact.cfg ( /etc/nagios3/conf.d/contacts_nagios2.cfg ) dosyasında da tanımlamalıyız.

define contact{
        contact_name                    testuser
        alias                           alias2
        service_notification_period     24x7
        host_notifications_enabled      1
        service_notifications_enabled   1
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        email                           mail_adresiniz
        }

   
define contactgroup{
  contactgroup_name       test
  alias                   alias_test
  members                 testuser
  }

 
Bu tanımlamalarıda ekledikten sonra, Nagios'da çalıştırdığımız komutların tanımlamalarını yaptığımız yerlere "testuser" kullanıcısını ait olduğu grup adını eklemeliyiz ki, izlenen servisler "testuser" kullanıcısı tarafından görülebilsin. O da şu şekilde olmalı:
 

define command{
  command_name        cb_disk_read
  command_line          $USER1$cb_disk_read  $ARG1$  $ARG2$ ...
  }
  
define service{
  use                  generic-service
  host_name            localhost
  service_description  Couchbase Disk Read
  check_command        cb_disk_read!10!0
  contact_groups       admins, test # testuser'in bulundugu grup
  }

Nagios Couchbase Eklentisinin Canlı Demosu Hazır

Bu dönem Kaan ile birlikte üzerinde çalıştığım Yakından Eğitim projesi olan Nagios Couchbase eklentisinin bu hafta büyük bir kısmını tamamladık, ve demosunu hazırladık. Uygulamanın çalışır halini web arayüzünden "testuser" kullanıcı adı ve "password"  parolası ile "http://54.234.80.73/nagios3/"  linkinden görebilirsiniz. Kullanıcı adı ve parolamızla sisteme girdikten sonra şöyle bir arayüzle karşılacağız:

Sol köşede "Current Status" kısmındaki "Services" bölümüne tıkladıktan sonra nagios kullanarak izlediğimiz servisleri görebiliriz.

Burada sistemin kendi üzerindeki kullanıcı sayısı, http servisi, ssh gibi çalışan süreçleri dışında benim CouchBase'den bilgi çekerek izlemimizi sağladığım özellikler de var. CouchBase, nagios ile aynı makine üzerine kurulu olduğundan localhost tanımlamasıyla nagios üzerinden izleme yaptım. Buradaki Couchbase'den aldığımız bilgilerin açıklaması ise şu şekilde:

CouchBase CAS: CAS aslında "check and set methods" kısaltması olarak kullanılıyor. Bu methodlarla var olan bilgiyi güncelleyebiliyoruz. 

CouchBase Create per second: Saniye başına disk üzerinde oluşturulan yeni verilerdir.

CouchBase Delete per second: Saniye başına disk üzerinde silinen verilerdir.

CouchBase Disk read: Belirtilen bucket için disk üzerinde yapılan okuma işlemleridir.

CouchBase Disk write queue: Belirtilen bir bucket üzerinde yazılmayı bekleyen kuyruktaki veriler.

CouchBase Memory usage: Kullanılmış olan bellek miktarı.

CouchBase Operation per second: Disk üzerinde saniye başına yapılan işlem sayısı.

CouchBase Disk update per second: Saniye başına disk üzerinde güncellenen veri miktarı.

CouchBase Disk set per second: Saniye başına disk üzerinde yapılan yazma işlemleri.

Nagios CouchBase Plugin diğer yaptığım projeler gibi bir özgür yazılım projesi ve GPL ile lisansladık. Uygulamanın kaynak koduna buradan bakabilir ve alıp kullanabilirsiniz. Gördüğünüz hataları, eksikleri, tavsiyelerinizi almaktan da oldukça memmun oluruz.

Bir kaç hafta içerisinde de CouchBase'den çekilmesi gereken diğer bilgilerle birlikte, daha fazla test etme, kod iyileştirme gibi kısımlarıda yaptıktan sonra projeyi bitirmiş olacağım.

Nagios Bildirimlerini Eposta Yoluyla Almak

Nagios'ta izlediğimiz hostların, servislerin durumlarından mail ya da sms ile haberdar olabiliriz. Bunun için ayar dosyalarında bir kaç tanımlama yapmak gerekli. Bu tanımlamalar ise şu şekilde:

1) /etc/nagios3/conf.d/contacts_nagios2.cfg dosyasında "contact" ve "contacgroup" tanımlamalarını ekliyoruz. Bu tanımlamalarda "contact" kısmındaki "contact_name", "contactgroup" daki "members"a referans verilmeli.

define contact{
        contact_name                    root
        alias                           Important Server Admin

        host_notifications_enabled      1
        service_notifications_enabled   1
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,r,c
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        email                           mail_adresiniz
}

define  contactgroup{
        contactgroup_name               admins
        alias                           Important Administrators
        members                         root
        }

Daha sonra çalıştırmak istediğimiz hostun ve servisin tanımlamasını yaptığımız yerde de "contact_groups" bilgisini eklemeliyiz. Şu şekilde:

define host{
        use                     generic-host            
        host_name               localhost
        alias                   localhost
        address                 127.0.0.1
        contact_groups          admins
        }

define service{
        use                             generic-service
        host_name                       localhost
        service_description             Couchbase Mem Usage
        check_command                   ...
        contact_groups                  admins
}

Nagios Makro Kullanımı

Makrolar Nagios'ta komut tanımlamaları, host tanımlamaları, servis tanımlamaları gibi kısımlarda değişkenlerde kullanılırlar.

Host adres makrosu: 
Aşağıdaki komut tanımlamasındaki "$HOSTADDRESS$" ile ifade edilen kısım host tanımlamasındaki ip adresiyle aynı değerdir.

define host{
	host_name       linux
	address	        192.168.1.2
	check_command	check_ping
	...
	}
define command{
	command_name check_http
	command_line $USER1$/check_ping -H $HOSTADDRESS$ -w ..
	}

Komut Argüman Makrosu: 

define service{
	host_name		linuxbox
	service_description	PING
	check_command	check_ping!200.0,80%!400.0,40%
	...
	}

/path/check_ping -H 192.168.1.2 -w 200.0,80% -c 400.0,40%

Yukarıdaki servis tanımlamasında ise "!" işaretleriyle ayrılan her bir kısım komutta tanımlamanan "-w", "-c" gibi parametrelerin aldıkları değere karşılık gelir.

 Makroların kullanım şekillerinde bunun gibi bir kaç durum daha mevcut. Ancak temel olarak bilinmesi gerekenler bu kadar olduğu için ben de şimdilik bu kadar bahsettim.

Nagios Couchbase Eklentileri

Yapacağım Nagios Couchbase eklentisinde veri tabanlarından çektiğimiz her bilgiyi hem Couchbase'deki  kümeden (cluster), hem de belirli bir sunucu üzerinden çekmem gerekiyordu. Github'ta yapılmasını istediğimiz eklentilerden bir kaçını cluster ve sunucular için bu hafta yapıp, nagios için olan ayar dosyalarını githuba koydum. Gene optparse kullanarak parametre aldırdım. Kullanıcı adı ve parolasıyla kimlik kanıtlaması kısımını geçirdikten sonra sıra veri çekmedeydi. İlk yazdığım eklenti saniye başına yapılan işlem bilgisi çekmeydi. Bunun için girilecek parametre "--OPS" (operation per second) diye belirledim. Ancak burda şöyle bir şey gerekli, kullanıcı --OPS parametresini, parametreye bir değer atamadan giriyor. Kullanıcının parametreye bir değer ataması gerekse bu parametreye bir değer atanıp atanmadığını kontrol edebilirdim. Hiç değer girilmeyen bir parametrenin komut satırından yazılıp yazılmadığını kontrol etmek için tekrar optparse belgesini okudum ama orada buna benzer bir şey göremedim. Okuduğum bloglar ve örnek nagios eklentilerinden yola çıkarak şu şekilde yapmaya karar verdim:

parser.add_option('--OPS', action='callback', callback=option_none, dest='operations_per_second')

Yukarıda parametre tanımlaması yaparken 'action' kısmında bu parametre kullanılırsa bir fonksiyona gitmesi gerektiği için 'callback' ve fonksiyon ismi tanımlaması yaptım. Bu şekilde kullanıcı --OPS parametresini girdiği anda callback kısmında tanımlanan fonksiyon çalıştırılacak. Tanımladığımız fonksiyonda ise komut satırında --OPS seçeneğinden sonra girilen değerlere bakarak --OPS değer girilme durumunu kontrol ettim. O da bu şekilde:

def option_none(option, opt, value, parser):
    if parser.rargs and not parser.rargs[0].startswith('-'):
        print "Option arg error"
        ...
        ....
    setattr(parser.values, option.dest, True)

Eğer --OPS seçeneğinden sonra değer ataması olacak bir şey girilmediyse --OPS değerini True yapıp, bu değere bakarak sonrasındaki işlemleri devam ettirdim. optparse belgesinde parser.rargs ile ilgili bir şey yazmıyordu bana lazım olan kısım burasıydı. Buna bakarken artık optparse'dan ziyade argParse'ın kullanılsa daha iyi gibi bir şeyler okudum. argParse'da parametrelerle ilgili daha gelişmiş özellikler var. Ama incelediğim bir çok nagios eklentisinde herkes hala optparse kullanıyor. Bu konuyu Kaan'a danışacaktım ama unuttum :) Daha sonra kimlik kanıtlaması yapıp dönen veriyi hangi tipe çevirip veri tabanından bilgi çekmek daha kolay oluyorsa o tip üzerinde oynayarak istediğimiz bilgiyi elde ediyoruz.

Yaptığım eklentide mail atma ve bir kaç test betiği yazdıktan sonra ilk sürümü bitirmiş olmayı planlıyoruz. Mail atma ve test etme kısımlarını tamamlamak için hafta sonu bir de Couchbase SDK'sına baktım. Kendi bilgisayarımdan Couchbase'in kurulu olduğu makine için sorgular falan yapıp, kalan kısımları tamamlayacaktım. Ama Couchbase'e bağlandıktan sonraki kısım timeout hatası verdi. Ben önce uzun döngülere girdirecek yanlış bir fonksiyon yazdım ondan kaynaklı sandım. Bir süre daha fazla beklediğimde timeout hatası aldım. Couchbase'in timeout değerleriyle oynasam bile işlemler çok uzun sürecekti bu şekilde. Sonra Couchbase'in kurulu olduğu makineye bağlanıp aynı sorguları çalıştırdığımda hata vermedi. Bu yüzden diğer makine üzerinde devam etmeye karar verdik. Eklentiler bittiğinde Couchbase'de tutulan neredeyse bir çok durumun çekildiği eklentiler tamamlanmış olacak.

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

Couchbase Nagios Plugin

Yakından Eğitim projelerinden Couchbase Nagios Plugin'e başvuru yaptım. Başvuru sürecinde yapmamız gerekenler burada belirtilmişti. Ben de cv'mi ve gereken soruları yanıtlayıp başvuru mailimi gönderdim. Bir zaman sonra başvuru sonuçları açıklandı. Kabul edildiğimi öğrendim.

Projeye başvuru nedenim aslında Necdet hoca önermişti Nagios Plugin'e başvurmamı. Eğer severek yapmayacağın bir iş olacaksa başvurma dedi. Twitterdaki tweetleri gözümde canlandırabiliyorum demişti :) Kaan'la çalışmak benle çalışmaktan daha eğlencelidir diye de belirtmişti (aslında Necdet hocayla çalışmak da çok eğlenceli bence). Ben birkaç akşam proje nasılmış, bu süreçte neler öğrenmem gerekecek diye bir kaç belge baktım. Çünkü NoSql'in sadece adını duymuştum daha önce kullanmadım. Sonrasında aklıma yatınca başvurmaya karar verdim. Aslında genelde bir işe başlarken seçme nedenlerim içinde bilmediğim şeyler olsun ve sıkılarak yapmayayım oluyor. Başvuru sorularını yanıtlarken de belirtmiştim bilmediğim işler ufkumu açıyor, bu şekilde ne üzerinde çalışmak isteyeceğim hakkında görüş alanımı genişletmeye çalışıyorum diye.

Projelerde çabuk sıkılma gibi bir eksi yanımda vardı eskiden ama artık daha geç sıkılıyorum bir iş uzarsa. Zaten yazılımda da yaptım bitti şeklinde değilde hep geliştirme ve bakım isteyen işler oluyor. Nagios Plugin'de de bu şekilde. Başvuru yapmadan önce okuduğum yazıda da proje bittikten sonra projenin gelişimine devam edilmesi gerektiği belirtilmişti. Başvuru yaptıktan sonra kimin seçileceği henüz belli değilken danışmanıma mail attım nelere bakmam faydalı olur konusunda. Kabul edilmek için danışmanlar genelde başvuru sürecinde başvuranlardan projeyle ilgili bir şeyler yapmasını istiyorlar. Danışmanım Nagios'u kur, çalıştır bak demişti. Bunun için belge önerdi bunları okuyabilirsin diye, ben de ek bir kaç yerden daha okumuştum, sonra kurup çalıştırdım. Kurulumla ilgili blog yazmamı istemişti. Bir kaç gün sonrasında zaten başvuru sonuçları açıklandı. Kabul edilmesem bile Nagios'un nasıl kurulup çalıştırıldığı hakkında bilgi edinmiş olacaktım.

Önümüzdeki 2 aylık süreçte projeyi geliştiriyor olacağım. Ayrıca her hafta freenode #yakından eğitim kanalında projelerin durumu hakkında konuşuyoruz. Ben de proje üzerinde bir şeyler yaptıkça, danışmanımın yönlendirmesi ile bu konuda yazmaya devam edeceğim.

Nagios Kurulumu ve Kullanımı

Nagios kullanarak bir makinenin üzerindeki bellek, işlemci gibi yerel kaynakları ya da vermiş olduğu smtp, mysql gibi servisleri izleyebiliriz. Ayrıca bu servislerin durumlarıyla ilgili kullanıcıya mail, sms gibi yollarla uyarıyı verebiliriz. Nagios ağ üzerinden servis ya da kaynak dinleme işlemini çeşitli eklentileri (plugin) kullanarak yapar. Nrpe'de bu sistem kaynaklarını dinlemek için kullanılan bir eklentidir. Nrpe kaynakları izlenecek olan makineye kurulur.

Kurulum

Kurulum için nagiosu ana makineye nrpe'yi ise kaynakları izlenecek olan makineye kurmamız gerekir. Nagios kurulumunu aşağıdaki gibi her iki makinede yapalım.

# apt-get install nagios3 nagios-nrpe-server  nagios-nrpe-plugin

Kurulumdan sonra web arayüzünden izleme yapabilmek için aşağıdaki gibi kullanıcı oluşturmalıyız

sudo htpasswd -c /etc/nagios3/htpasswd.users nagiosadmin

Şimdi nrpe ile başka bir makinanın yerel kaynak durumlarını izleyelim. Bunun için /etc/nagios3 dizini altında ubuntu_remote.cfg adında bir dosya oluşturalım. Bunun içine yapmamız gereken tanımlamalar şu şekilde:

# host tanimlamasi
define host{
use generic-host  # tum host tanimlamalarinda olmasi zorunlu
host_name Ubuntu2
alias Ubuntu2Alias
address ip_adres # dinleyecegimiz makine ip
}

# nrpeyi tanimliyoruz
define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

# izlemek istedigimiz kaynak
define service{
use generic-service # tum servis tanimlamalarinda olmasi zorunlu
host_name Ubuntu2
service_description Current Users
check_command check_nrpe!check_users
}

/etc/nagios3/conf.d/ dizini altındaki hostgroups_nagios2.cfg dosyasında aşağıdaki gibi tanımladığımız host ismini referans vermeliyiz.

define hostgroup {
hostgroup_name ubuntu-servers
alias Ubuntu GNU/Linux Servers
members localhost, Ubuntu2
}

/etc/nagios.cfg dosyasında da tanımladığımız ubuntu_remote.cfg dosyasının yolunu "cfg_file=/etc/nagios3/ubuntu_remote.cfg" şeklinde belirtmeliyiz. Aynı zamanda kaynaklarını dinleyeceğimiz makinede /etc/nagios/ dizini altındaki nrpe.cfg dosyasında sunucu makinenin ip adresini "allowed_host=nagios_server_ip" olarak belirtmeliyiz. Daha sonra nagios ve nagios-nrpe-server süreçlerini yeniden başlatalım.

/etc/init.d/nagios3 restart
/etc/init.d/nagios-npre-server restart

Tarayıcıda localhost/nagios3 adresiyle yerelimizde karşıdaki makinenin durumlarını kontrol edebiliriz.

Ayrıca nagiosta çalıştırabileceğimiz komutların listesi /usr/lib/nagios/plugin dizini altındadır. Oradaki komutların alabilecekleri parametreleri aşağıdaki gibi --help parametresiyle görüntüleyebilirsiniz.

/usr/lib/nagios/plugin/check_disk --help