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.

İlişkisel Olmayan Veri Tabanı: NoSQL

NoSql Facebook, Twitter, LinkedIn, Google gibi bir çok şirket tarafından kullanılır. NoSql ilişkisel veri tabanı olmamakla birlikte ona rakip de değildir. İlişkisel veri tabanına alternatif olarak ortaya çıkmıştır. 

Düşündüğümüzde internet ortamında gün geçtikçe saklanan veri miktarı artmakta ve verilerin işlenmesi de zorlaşmaktadır. Artan veri miktarıyla birlikte verilerin birbirleriyle olan bağlantısı artıp karmaşıklaşmıştır. NoSql ile bu verileri işlemek kolaylaşmıştır. 

Google, Twitter gibi büyük şirketlerin NoSql'i kullanma sebepleri arasında tuttukları verinin çok büyük olması yanında aynı veri bloğuna sürekli başka bilgiler eklenip güncellenmesidir. NoSql ile veri güncelleme işlemleri daha hızlı yapılır. Çünkü ilişkisel veri tabanındaki gibi bir tablodaki tüm verilerin sütun sayısı aynı olmak zorunda değildir. Verilerin tutulma şekli Sql'den daha basittir.

NoSql çeşitlerini veri tutma biçimlerine göre 4 temel kategoride inceleyebiliriz:

Anahtar-Değer Şeklinde Depolama Yapanlar: Bu sistemlerde anahtara karşılık gelen değerler tutulur. Bu şekilde veri depolanmasında genelde önbellekleme işlemleri çok büyük performans harcar. Örnek olarak Amazon tarafından oluşturulmuş olan Dynomo.

Sütunlar Şeklinde Tutulanlar: Bu yapı genelde bir çok farklı makine üzerine dağıtılmış oldukça büyük veriler için kullanılır. Örnek olarak Google tarafından üretilip kullanılan Big Table.

Döküman Tabanlı Depolama Yapanlar: Veriler döküman şeklinde tutulur. Bu dökümanlar ise json biçminde saklanır. MongoDB, CouchDB gibi.

Graf Tabanlılar: Düğümlerden oluşur. Düğümler arasındaki ilişki saklanır.

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