Chef Server'ın Oluştuğu Bileşenler

Chef Server'da cookbookları depolayabiliriz demiştik, her  cookbook'un kendi içeriğindeki dosyalara göre de sunucuları yapılandırabiliriz. Chef istemcileri de Chef sunucusundan nasıl davranması gerektiği bilgisini alır ve ona göre sunucuyu yapılandırır. Chef Server Erlang kullanılarak yazılmıştır ve Chef Server'ın sağladığı hizmetler aşağıdaki bileşenlerle sağlanır:

Bookshelf: Bookshelf ile cookbook dosyalarının depolanması ve workstationdaki cookbookların Chef sunucusuna gönderilmesi sağlanır. Eğer farklı cookbooklar aynı dosyayı içeriyorsa ya da aynı cookbookun farklı sürümlerinde aynı dosyalar varsa Bookshelf bu dosyaları sadece bir kez depolar.

WebUI: Ruby on Rails ile kodlanmış, Chef Server için bir arayüzdür.

Erchef (Erlang API Server): Chef Server için bir API'dir. Bu API hala orjinal Ruby tabanlı Chef Server için uyumludur.

Mesaj Kuyruğu: Mesajlar search indexlerine gönderilirler. RabbitMQ Chef Server'da mesaj kuyruğu olarak için kullanılır.

Nginx: Chef Server için yük dengeleyici (front end load balancer) olarak kullanılan bir sunucudur. Chef Server Api'sine gelen tüm istekler Nginx sayesinde yönlendirilirler.

PostgreSQL: Verileri tutmak için kullanılan depodur.

Chef Server'da Knife Kullanımı

Geçen hafta Chef Server kullanımı, cookbook kavramı, cookbookların içerdikleri dosyalar, cookbook kullanma gereksinimi gibi kavramlara baktım. Stajın 4. gününden sonra baya bir hastalandım. Bu sefer midem değil ama ofis biraz serindi sanırım ondan kusma, ateşlenme meydana geldi. Bir kaç gün izin aldım Kaanlardan.

Bu haftada knife ile Chef istemcisi oluşturma, data bag, roller gibi kavramlara baktım. Burada Chef sunucusunu knife eklentisi kullanarak yönetmeden bahsetmiş. İlk önce kendi makinem üzerinde vagrant ile bir sanal makine açıp onun Amazon'daki Chef sunucumuz için bir istemci olmasını sağladık.

Oluşturduğumuz istemci üzerinde bir kaç cookbook çalıştırmak için workstation üzerinde roller tanımladım. Kullanmak istediğimiz cookbook'u "knife cookbook site install cookbook_name" şeklinde workstationdaki Chef deposuna (chef dizini) indirebiliriz. Daha sonra chef/roles içine çalıştırmak istediğimiz cookbooklar içindeki recipe'leri run_list'e ekliyoruz. Bu şekilde istediğimiz kadar istemciye istediğimiz şeyleri tek seferde yaptırabiliriz. İndirdiğimiz cookbookları aynı zamanda Chef sunucumuza "knife cookbook upload --all" şeklinde göndermeliyiz. Yoksa istemci üzerinde cookbookları çalıştıramayız. Eklediğimiz rolü de yüklemeliyiz. Bunu da "knife role from file roles/role.rb" şeklinde yapabiliriz.

Data Bag

Data bag kavramı Chef istemcilerinde kullanıcı oluşturmak için kullanılan, json şeklinde depolanan dosyalardır. users cookbook'u eğer kullanıcılar data bag'de varsa, o kullanıcıları istediğimiz özelliklerde istediğimiz makineye eklememizi sağlar. Burada data bag'e kullanıcı ekleme işleminin nasıl yapılacağından ve json dosyasının nasıl yazılması gerektiğinden bahsetmiş. Workstation'daki chef/databags/users dizini altında istediğimiz kullanıcıları tanımlayıp, "knife data bag from file kaan.json" şeklinde kullanıcıyı data bag'e ekleyebiliriz.

Environment

Her Chef organizasyonunun varsayılan ortamı (environment)  _default'tur. Environment kavramı ortamları ayırmak için kullanılır. Workstationdaki chef/environments dizini altına tanımladığımız ortamın özelliklerini (cookbook sürümleri gibi) environment_name.json şeklinde kaydedip gene knife kullanarak istediğimiz istemci için bu ortamı kullanabiliriz.

LWRPs

LWRPs (Lightweight resources and recipes) Chef'te paket yükleme, servis başlatma gibi işlemler için kullanılır. Benim de sunucular üzerinde işlem yaptırırken kendim bu gibi işlemleri tanımlamam gerekecek. 

Vagrant, Chef Solo, Chef Server ile Sunucu Yönetimi

Bu yaz stajı 2 sistem yöneticisinin yanında yapıyorum. Öğreneceğim teknolojiler de gene sunucu bakımı, yönetimi üzerine olacak. Şuan çok fazla bilmediğim kavram olduğu için bir süreyi kavramları öğrenmeye, temel bir kaç deneme yapmaya ayırdık. Kullanmam gereken şeyler arasında tek bildiğim şey Ruby, kullanacağım diğer her şeyi ben de daha önce kullanmadım. Zaten on tane makine açayım onları yapılandıran betikler yazayım gibi bir düşüncesi olmuyor insanın durup dururken :)

Dün Kaan kendi kullandıkları teknolojilerden bahsetti. Yeni duyduğum, öğrendiğim şeyler karşısında verdiğim standart tepki olarak "insanlar biliyorlar, insanlar yapıyorlar" oldu :)

Çalışmaya önce Vagrant ile başladım. Vagrant sanal makine açarken istediğimiz özellikleri daha rahat verebildiğimiz bir araç. Örneğin ram ayarlarını bir Vagrantfile içerisinden makineyi ilk oluştururken yapabiliyoruz. Komut satırından yönetim yaptığımız için hızlı.

 Chef solo kullanımı ilk Vagrantfile içerisinden yaptım. Vagrantfile içerisinden çalıştırılması gereken cookbookları tanımlayabiliyoruz. Bu şekilde Chef sunucusu, Chef istemcisi gibi konulara bakmadan temel bir cookbook çalışmasını ve dosyalarını inceleyebiliriz. Cookbooklar ise Chef'teki makinelerin nasıl çalışacağının adımları tanımlayan dosyalardan oluşuyor. Biraz Couchbase cookbookunun kodunu incelemiştim. Burada temel bir cookbook yapmışlar. Çalıştırıp denemedim henüz ama belgesinde Couchbase kurulumu ve yapılandırması sağladığı yazıyor, ama Couchbase'de yapılan diğer işlere destek vermiyor. Cookbooklar da temel olarak aşağıdaki işlemler sağlanabiliyor:

1) Düğüm (node) üzerindeki temel ayarlar
2) Dosya dağılımları
3) Versiyon kısıtlamaları, desteklediği platformlar
4) Recipes dizini içerisindeki dosyaların hangi tarife göre çalıştırılacağı

Cookbooklarda karşımıza çıkan kavramlardan kaynaklar (resources) ve sağlayıcı (provider) ise şu şekilde: Kaynaklar, Chef farklı görevler için çalışırken (paket yükleme, dosya sistemine erişme, servis çalışabilir durumda mı, hangi kullanıcı, hangi grup için, dosyaların nereye kopyalanacağı gibi) hangi sağlayıcının kullanılacağını söyler. Çünkü her kaynak bir sağlayıcı ile ilişkilendirilmiştir. Sağlayıcı ise bu çalışma işlemlerini sağlar. Yani sağlayıcı, kaynaktaki adımları tanımlar. Örneğin paket yüklemesinde "apt_package" kaynağı apt kullanan sistemler için yükleme yapar, bu kaynağın yapabileceği işlemler ise install, remove, upgrade gibi "action" kavramı olarak tanımlı. Bu temel örnekteki gibi cookbooklar içerisinde istediğimiz işlemleri sırayla işletebiliriz.

Chef ise sunucuları yerleştirmeyi yönetmeyi sağlayan bir alt yapıdır ve bu yönetim cookbooklar ile sağlanır. Her makinenin kendi platformuna uygun ve isteniyorsa aynı özelliklere sahip olması sağlanır. Chef'te kullanılan kavramlar ise sunucu, çalışma alanı, ve düğümler.

Çalışma alanı denilen kavram cookbookların konumudur. Ve her düğüm ihtiyaçlarına göre bir Chef istemcisi içerir.

Son olarak knifedan da bahsedeyim. Knife, Chef üzerinde işlem yapmak için kullanılan bir araç. Chef sunucusu kurulumunu ve kullanımını kolaylaştırıyor. Ben ilk olarak Chef'i depodan indirip yapılandırmak istedim, ancak İşbaran karşı çıktı, ben biraz direndim, derken knife ile kurulum sağladık. Çünkü knife ile kurulum gerçekten daha kolay oluyormuş. Bize kurulum sırasında çeşitli seçenekler sunuyor, ve dosyaları gerekli yerlere kendisi kopyalıyor.

UNIX Manual Page Editor: RManEdit

RManEdit is a editor to prepare man page. I used Ruby & Gtk for RManEdit. RManEdit has many features like other editors. You can get more information from  here.

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:

Unix Man Sayfası Hazırlama Editörü: RManEdit 2.0.2

Ruby ve Gtk kullanarak kodladığım RManEdit 1.0.1 sürümünde tek sayfa açılabiliyordu. Şimdi 2.0.2 sürümünde ise çoklu sekme yapısı, bul değiştir, sihirbaz özellikleri ekledim. RManEdit diğer metin editörlerinin sahip olduğu bir çok özelliğe sahip. Projenin kurulum ve kullanım bilgilerine buradan ulaşabilirsiniz. Projeden bir kaç ekran görüntüsü:

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. 

3. Sınıf Biter Sonrası Staj

Bu yıl 3. sınıfı bitirip artık 4 oldum. Biraz tuhaf bir yıl oldu benim için. Hem biraz hastaydım, biraz küsmüş derken yılı sonlandırdım. İlk dönem fazlasıyla rahatsızdım midemden. Zaten zayıf bir insan olarak hepten zayıfladım :) Ama gene de boş geçirmedim tabiki yılı. Tabi Necdet hoca boş geçirmemem için dürtükleyip duruyordu o ayrı :)

Bu dönem aslında hiç istediğim gibi çalışamadım. Okul sınavlarımı çok boşladım bu yıl, aslında pek boşlamazdım sene sonunda genelde iyi sonuçlar elde ederdim. Sanırım bu yıl sınavlara sallamadan nasıl oluyor bir deniyim mi istedim ne istedim ben de bilemedim :) İlk dönem olan derslerden Java vardı ama ben Java'yı sevmiyorum. Yazımı gereksiz uzun bence. C++ daha çok seviyorum açıkçası. Bir de 2. sınıftayken okuldaki derslere çok hevesli başlardım. Ancak okuldaki hocalarda aynı tepkiyi alamadım. O yüzden artık okuldaki derslerde pek heveslenmiyorum "vay be bunu öğreneceğim" şeklinde. Zaten 3. sınıf olduğumuz için aldığımız son programlama dersi olarak Java vardı. Bundan sonraki dersler hep işletim sisteminin çalışması, programlama dilleri ve kavramları, mikro işlemciler gibi dersler. 3'ün ilk döneminde veri tabanı dersi de aldık, ben bu yıl pek çalışmadığımdan onu pek verimli geçiremedim, açıkçası buna da üzüldüm biraz. Veri tabanı iyi öğrenmek isterdim. Aslında arka planda tamamen veri tabanı tasarımına dayanan uygulamalar yazmayı sevmem, ama sevmemem boşlamamı pek gerektirmezdi. Belirli bir seviyeye kadar varlıklar arasında ilişki kurmayı ben de yapıyorum tabi. Ama daha karmaşık şeyler üzerinde çalışmadım.

Bu dönem bana sorarsanız dersler bakımından ağır değildi. Konular 2. sınıfı geçirdikten sonra daha rahat anlaşılırdı benim için. Bir de okul dışında uygulama yapınca kavraması daha basit oluyor. Ezberleyip geçmekten farklı bir hal alıyor. 2. sınıftan daha fazla okul dışında işlere bakmak için vakit vardı bence. Ancak ben zaman yönetimini pek yapamadım.

Bu yıl Linux dağıtımlarına yönelik 2. sınıfa oranla oldukça şey öğrendim. Lpi 101 sınavına çalışmıştık bir grup olarak okulda, ona giren her arkadaşımla birlilkte başarıyla sonuçlandırdık Lpi 101 sınavını. 1. dönem fazla rahatsız olduğumdan ara tatilde RManEdit'i yaptık. Ve gene ilk dönem Gnome'un Outreach for Women etkinlğine katılarak projelere katkı vermeye başladım. Aslında katkı verdiğim uygulamayı da zor şartlar altında çalıştırıp yamayı göndermiştim. Benim makinemde problem olduğundan okuldan bir makine kullanmak zorunda kalıyordum. O zamanda sabahtan akşama kadar okulda durduğumdan dışarıda yemek yemek (yiyememek) midemi daha fena getiriyordu. Ara tatilde uzun bir süre ev yemekleri yediğimden midem biraz daha düzeldi. Derken 2. dönem ortasından sonra mide ilaçları kullanmadan devam edecek kadar iyileşebildim :)

2. dönem RManEdit'in eksik yerlerinin bir kısmını tamamladım. Bir de Yakından Eğitim projesi olan Nagios Couchbase Plugin'e başvurdum. Nagios eklentisi projesini de başarı ile neticelendirebildim. Bir de gene Necdet hocanın Gnome projelerine katkı ver sıkıştırmaları nedeniyle jhbuildi kurmak ile olan yakından ilişkim bilgisayara her format attığımda yeniden başladı. Aslında bana sorarsanız projelere katkı vermek için en güzeli dağıtımların kararlı olmayan hallerini kullanmak. Gündelik ihtiyaçlar için iyi diyemem, ama katkı vermek için iyi. 2. dönem bir de Muğla'da ilk sunumumu yaptım. 4. sınıflardan Ahmet ve Serhat ile birlikte Özgür Yazılım projelerine nasıl katkı verilirden bahsetmiştik. Muğla'da yoldan, heyecandan, midem fena olursa yemek yiyemediğimden halsiz kalırım ve kötü olur diye korkmuştum aslında. Ancak öyle olmadı :)

Reflü kötü bir şey :( İlk zamanlar kötü aslında bir süre ilaç kullandıktan sonra midenizi pek zorlamazsanız çok sorun olmuyor.

Şimdi ise bu hafta çalışmam gereken bir sınavım kaldı. Sonrasında staja başlamadan önce okumam gerekli olan belgeler var. Stajımı sistem yönetimi üzerine yapacağım. Kaan ve İşbaran sistem yönetimi üzerine bir kaç şeyden bahsetti staj görüşmemde. Artık sistem yöneticilerinin sunucu bakımını tek tek elle yapmadığını, çalışan makine sayısının da sürekli değiştiğini, bunun için sistem yöneticilerinin sunucu yönetimi sağlayan betikler yazdğından bahsetti. Aslında sistem yöneticisi olmak istemiyorum ama sistem yöneticilerinin kullandıkları teknolojilere karşı merakım var :) Bu yüzden stajda bu tür şeyler öğrenmenin beni sıkacağını sanmıyorum.

Son olarak bu dönem de bittiği için artık ben de 4. sınıfım :)

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

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.

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
}

Muğla Özgür Yazılım Semineri

Geçen hafta cuma günü Muğla'ya özgür yazılım semineri için gittik. Seminerin ana konusunu "Özgür yazılım projelerine nasıl katılabilir ve nasıl kendinizi yetiştirebilirsiniz?" olarak belirlemiştik. Seminerde Necdet hoca özgür yazılım felsefesinden bahsetti. Ahmet, Serhat ve ben de projelere nasıl katkı verilebileceğinden, özgür yazılımda hangi imkanların sunulduğundan bahsettik. Projelere katkı verme konusunda kendi deneyimlerimizden bahsedeceğimiz için anlatması biraz daha rahat oldu benim için. Konuşma yaptığım ilk seminer olduğu için oldukça heyecanlıydım. Genelde yüksek sesle konuşan biri olmadığımdan konuşma sırasında insanlar ne dediğimi duymazlar, anlatmak istediğimi anlatamam gibi olası durumlardan korkmadım değil :) Ama neyseki hiç böyle olmadı, anlatırken insanlara baygınlık geçirtmeden anlatabildim :) En çok korktuğum şeylerden biri sıkıcı bir şekilde anlatmaktı çünkü. Ahmet ve Serhat sunum konusunda geçen yıldan tecrübeli olduklarından onlar benden daha sakinlerdi.

Muğla'da Enis hoca ve Esra'nın misafiri olduk :)  Enis hoca bizi çok güzel bir şekilde ağırladı. Seminerden sonraki gün Muğla'da bir kaç yer gezdik. Kahvaltı için gittiğimiz yerlerdeki her şey çok doğaldı, bu yüzden midem (reflüden dolayı) fazla zorlanmadı :) Eski Muğla dedikleri bir semti de gezdik en çok orayı beğendim. Kurtuluş savaşı dönemine çok ilgiliyim, Eski Muğla'daki evler aynı öyleydi. O yüzden Eski Muğla'yı çok beğendim.

Muğla'daki seminer bu biraz yorucu ve bolca heyecanlı bir şekilde sonlandı benim için. Umarım herkes için faydalı olmuştur :)