Monitoring Nedir ve Neden Önemlidir?

Bir sunucunun diski dolduğunda bunu iki şekilde öğrenirsiniz: ya sistem size söyler, ya da müşteri arar. Aradaki fark teknik bir yetenek değil, bir tercihtir — o sunucuyu izliyor muydunuz, izlemiyor muydunuz?

Bu yazıda izlemenin ne olduğunu, hangi katmanlarda yapıldığını ve yaygın araçların hangi işe uygun olduğunu göreceğiz. Kurulumla devam etmek isterseniz Prometheus, Grafana ve Node Exporter kurulumu yazısı bu kavramların uygulamalı karşılığıdır.

İzleme Nedir: Toplama, Uyarı ve Analiz

Bir sistemin veya uygulamanın performansını, durumunu ve davranışını izleme işlemidir. Bu izleme, donanım, yazılım, ağ trafiği veya iş süreçleri gibi farklı bileşenlere odaklanabilir. Ayrıca, bu izleme süreci gerçek zamanlı veya geçmişe yönelik veri analizi şeklinde olabilir.

İzleme tek bir iş değildir, üç ayrı adımdır ve çoğu kurulum ikincisinde takılır:

1. Toplama: metrikler (CPU, disk, yanıt süresi), loglar ve olaylar bir yerde birikir.
2. Uyarı (alerting): toplanan veride bir eşik aşıldığında birine haber gider. Kimseye haber gitmiyorsa elinizde izleme değil, güzel bir grafik vardır.
3. Analiz: geçmiş veriye bakarak kapasite planlaması ve kök neden analizi yapılır.

Asıl Ölçü: Arızayı Kaç Dakikada Fark Ediyorsunuz?

İzlemenin değeri “sistemi görüyor olmak” değildir; arızanın başlaması ile sizin haberdar olmanız arasındaki süredir. Bu süreye MTTD (mean time to detect) denir ve izlemenin doğrudan kısalttığı tek sayı odur. Arızayı gidermek ne kadar sürerse sürsün, o sayacın başladığı anı izleme belirler.

Somutlaştıralım. Bir web sunucusunun diski gece 02:10’da dolmaya başlıyor:

Aradaki fark bir özellik değil, yedi saat. Aynı disk, aynı uygulama, aynı ekip. Bu yüzden izleme kurarken sorulacak ilk soru “hangi grafikleri göreceğim” değil şudur: bu sistem gece 03:00’te bozulursa kim, ne kadar sürede öğrenir?

Beş Katman: Neyi İzlersiniz

İzleme tek bir yerde yapılmaz; her katman başka bir arıza türünü yakalar.

• Ağ — bağlantı durumu, gecikme, arayüz hata sayaçları. Bir anahtar portu düştüğünde ya da paket kaybı başladığında uygulamanın logunda hiçbir şey görünmez; belirti yalnızca burada çıkar.
• Sunucu — CPU, bellek, disk doluluğu, IO beklemesi. Kapasite sorunları ve yavaşlamaların çoğu buradan okunur.
• Uygulama — yanıt süresi, hata oranı, kuyruk uzunluğu. Sunucu metrikleri tertemiz görünürken uygulama 500 dönüyor olabilir; donanım katmanı bunu göstermez.
• Güvenlik — başarısız kimlik doğrulamalar, yetki değişiklikleri, beklenmeyen dış bağlantılar. Bu katman arıza değil, niyet arar.
• Log — diğer dördünün “neden” sorusunun cevabı buradadır. Metrik bir şeyin bozulduğunu söyler, log neden bozulduğunu.

Metrik ile log birbirinin yerine geçmez: metrik ucuzdur ve uzun süre saklanır, log pahalıdır ve ayrıntı taşır. Yalnız log toplayan bir kurulum eğilimleri göremez, yalnız metrik toplayan kök nedeni bulamaz.

Araç Seçimi: Veriyi Kimin Topladığına Bakın

1. Zabbix: Açık kaynaklı ve çok yönlü bir monitoring çözümüdür. Sunucu, ağ ve uygulama izlemeyi destekler. Özelleştirilebilir uyarılar ve raporlama yetenekleri sunar.
2. Nagios: Uzun bir geçmişe sahip olan Nagios, ağ ve sunucu izlemesi için popüler bir tercihtir. Büyük topluluk desteğine sahiptir ve geniş bir eklenti ekosistemi sunar.
3. Prometheus: Özellikle bulut tabanlı uygulamalar ve mikro servisler için uygun olan Prometheus, veri toplama ve sorgulama yeteneklerine odaklanır. Grafana gibi görselleştirme araçlarıyla entegre edilebilir.
4. Grafana: Farklı kaynaklardan gelen verileri görsel olarak sunmak için kullanılan açık kaynaklı bir platformdur. Monitoring araçlarıyla entegre edilebilir ve özelleştirilebilir görselleştirmeler sunar.
5. Cacti: Ağ cihazları ve sunucuların performansını izlemek için kullanılan bir açık kaynaklı yazılımdır. SNMP (Simple Network Management Protocol) tabanlı cihazları izlemek ve verileri grafiklerle görselleştirmek için kullanılır.

Seçim yaparken belirleyici olan şey araçların özellik listesi değil, veriyi nasıl topladıklarıdır. Zabbix ve Nagios hedefe gidip sorar (pull ya da agent), Prometheus ise uygulamanın kendi açtığı bir uç noktadan metrik çeker. İkincisi konteyner ve mikroservis ortamlarında yaygınlaştı, çünkü sürekli gelip giden sunucuları elle tanımlamak mümkün değil; Prometheus onları servis keşfiyle kendisi bulur.

Uyarı Yorgunluğu: İzlemenin Sessizce Bozulduğu Yer

İzleme kurulumları çökerek değil, gürültüye boğularak işe yaramaz hâle gelir. En sık görülen üç hata:

• Her metriğe uyarı koymak. Günde 200 bildirim alan bir ekip üç hafta içinde hepsini filtreye atar; 201’inci gerçek arıza da o filtrenin içinde kalır. Bir uyarı kuralının ölçüsü şudur: bu bildirim geldiğinde birinin yapacağı somut bir iş var mı? Yoksa o bir uyarı değil, gösterge panelinde durması gereken bir grafiktir.
• Eşiği anlık değere bakarak koymak. CPU’nun bir anlığına %95’e çıkması normaldir. Kural bir süre içermelidir — “beş dakika boyunca %90’ın üstünde” gibi — yoksa her gece yedekleme işi alarm çaldırır ve ekip alarmı susturmayı öğrenir.
• İzleme sisteminin kendisini izlememek. Prometheus durduğunda size bildirim gelmez, çünkü bildirimi gönderecek olan odur. Bu yüzden izleme sunucusunun ayakta olduğunu dışarıdan kontrol eden ayrı ve basit bir mekanizma gerekir; bu düzeneğin adı dead man’s switch’tir.

Sonuç

İzlemeye başlarken akılda tutulacak üç şey:

• Uyarısız izleme, izleme değildir. Kimsenin bakmadığı bir gösterge paneli arızayı yine müşteriye buldurur. İlk kurduğunuz şey grafik değil, eşik ve bildirim kanalı olsun.
• Aracı ortamınız seçer. Sabit sunucu envanteri olan bir kurumda Zabbix/Nagios, sürekli değişen konteyner ortamında servis keşfi yapan Prometheus daha az bakım ister.
• İzlenmeyen şey çalışmıyor sayılır. Yedekleme işi, sertifika süresi ve disk doluluğu — üçü de sessizce bozulur ve üçü de ancak izlendiklerinde arıza olmadan yakalanır.

Uygulamaya geçmek için: Adım Adım Prometheus, Grafana ve Node Exporter Kurulumu. Zabbix tarafını video olarak izlemek isterseniz Samet Tunçbilek‘in YouTube kanalındaki ‘Zabbix Server’ serisi iyi bir başlangıçtır.