Sunucu İzleme (Monitoring) Nedir? Ping, Servis ve Kaynak İzleme Farkı

Sunucu izleme, bir sunucunun erişilebilirliğini, servislerinin çalışıp çalışmadığını ve kaynak kullanımını sürekli ölçüp sorun anında alarm üreten süreçtir. Ping (ICMP) izleme yalnızca sunucunun ağda yanıt verip vermediğini gösterir. Servis izleme web, veritabanı ve e-posta servislerini ayrı ayrı test eder. Kaynak izleme ise CPU, RAM ve disk doluluğunu takip ederek sorunu kesintiden önce yakalar.

Bu üç katman birbirinin yerini tutmaz; aşağıda farklarını bir arıza senaryosu üzerinden anlatıyoruz. Bulutzone'un ping ve servis izlemeli SLA paketleri de bu ayrım üzerine kuruludur.

Sunucu izleme nedir?

Sunucu izleme (monitoring), sistemden düzenli aralıklarla ölçüm toplayıp bu ölçümler belirlenen sınırları aştığında birilerini haberdar eden düzenektir. Amacı iki sorunun cevabını vermektir: şu anda bir şey bozuk mu, yakında bir şey bozulacak mı?

Google'ın site güvenilirliği mühendisliği (SRE) kitabı iki yaklaşımı ayırır. Kara kutu (black-box) izleme sistemi dışarıdan, kullanıcının gördüğü gibi test eder ve şu anda yaşanan sorunu yakalar. Beyaz kutu (white-box) izleme ise sistemin içinden gelen metriklere bakar ve yaklaşan sorunu önceden gösterir. Kitabın önerisi, beyaz kutu izlemeyi yoğun, kara kutu izlemeyi az ama kritik noktalarda kullanmaktır.

Aynı kaynak, kullanıcıya dönük her sistem için dört altın sinyal tanımlar:

• Gecikme (latency): Bir isteğe yanıt verme süresi. Başarılı ve hatalı isteklerin süresi ayrı ölçülmelidir; hızlı dönen bir hata sayfası ortalamayı yanıltıcı biçimde iyileştirir.
• Trafik (traffic): Sisteme gelen talep miktarı; bir web sitesi için saniyedeki HTTP isteği.
• Hatalar (errors): Başarısız isteklerin oranı. HTTP 500 gibi açık hataların yanında, 200 dönüp yanlış içerik gösteren sayfalar da bu gruba girer.
• Doygunluk (saturation): Sistemin ne kadar dolu olduğu; en kısıtlı kaynağın kullanım oranı.

İzleme katmanları

İzleme dört katmanda yapılır ve her katman bir öncekinin göremediğini görür. Aşağıdaki tablo her katmanın neyi yakalayıp neyi kaçırdığını özetliyor.

ICMP (ping) izleme

ICMP (Internet Control Message Protocol), ağ cihazlarının durum ve hata mesajlaşması için kullandığı protokoldür. Ping, bu protokolün echo isteğini gönderir ve echo yanıtını bekler. Yanıt geliyorsa işletim sistemi çalışıyor ve ağ bağlantısı var demektir. Ucuz, hızlı ve her sunucuya uygulanabilir olduğu için izlemenin ilk katmanıdır. Bazı sunucular güvenlik gerekçesiyle ICMP'yi engeller; bu durumda ping izleme sunucu çalışırken bile alarm verir.

Port ve servis izleme (HTTP, SQL, SMTP)

Servis izleme, her servisin kendi protokolüyle konuşup gerçekten iş yapıp yapmadığını test eder. En basit hali TCP port kontrolüdür: 3306 numaralı port bağlantı kabul ediyor mu? Daha güçlü hali protokol düzeyindeki kontroldür: web sayfası 200 kodu ve beklenen bir kelimeyi döndürüyor mu, veritabanı bir sorguya cevap veriyor mu, SMTP servisi selamlama mesajını gönderiyor mu? Anahtar kelime kontrolü, 200 kodu dönen ama boş ya da hata içeren sayfaları da yakalar.

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://ornek.com
mysqladmin ping

Kaynak izleme (CPU, RAM, disk, ağ)

Kaynak izleme, sunucunun içindeki bir ajan yardımıyla CPU, bellek, disk doluluğu, disk gecikmesi ve ağ trafiği gibi metrikleri zaman serisi olarak toplar. Değeri anlık ölçümde değil eğilimdedir: her gün yüzde 1 dolan bir disk, kesintiden haftalar önce görünür. Yavaşlamanın hangi kaynaktan geldiğini bulmak için darboğaz tespiti yazımıza bakabilirsiniz.

Log ve güvenlik izleme

Loglar, metriklerin söyleyemediği "neden" sorusunu cevaplar. Aynı hatanın saatte yüzlerce kez tekrarlanması, beklenmedik bir kullanıcı girişi ya da bir IP'den gelen yoğun başarısız deneme ancak loglarda görünür. Log izlemenin sonucu da bir alarm olmalıdır; yalnızca saklanan loglar, olaydan sonra incelemeye yarar.

Ping izleme neden yetmez?

Çünkü en yaygın arızalarda sunucu açık kalır, bozulan şey üzerinde çalışan servistir. Ping bu durumda yeşil görünmeye devam eder.

Somut bir senaryo: bir e-ticaret sitesi gece saatlerinde yoğun bir kampanya trafiği alıyor. Bellek dolunca Linux çekirdeğinin OOM killer mekanizması, yani bellek tükendiğinde sistemi ayakta tutmak için süreç sonlandıran bileşeni, en çok bellek kullanan süreci, MySQL'i kapatıyor. Sunucu, işletim sistemi ve web sunucusu çalışmaya devam ediyor. Site her istekte veritabanı bağlantı hatası sayfası döndürüyor.

Bu tabloda saatler örnektir; asıl fark, sorunun kimin tarafından ve ne zaman fark edildiğidir. Ping izlemede kesinti altı saatten uzun sürüyor ve müşteriler tarafından bildiriliyor. Servis izlemede aynı arıza, kontrol aralığı ve müdahale süresi kadar sürüyor.

Bulutzone paketlerinde bu ayrım şöyle karşılık bulur: SLA-2'de sunucu izleme ping ile yapılır. SLA-3 buna web, SQL ve mail servislerinin izlenmesini ekler; yukarıdaki senaryoyu yakalayan da bu servis bazlı kontroldür. SLA-2'de ayrıca "servis kontrolü" kalemi bulunur; bunun SLA-3'teki servis izlemeden kapsam olarak nasıl ayrıldığını, yani hangi servislerin, hangi sıklıkla ve hangi alarm kanalıyla izlendiğini paket seçmeden önce sorun.

Hangi metrik için hangi eşik?

Eşikleri sunucunun normal davranışına göre ayarlayın; aşağıdaki değerler yalnızca başlangıç noktasıdır. İki hafta veri topladıktan sonra, gereksiz alarm üreten eşikleri gevşetip kaçırılanları sıkılaştırın.

Load average, çalışmak için sırada bekleyen ve disk gibi kaynaklarda bekleyen süreçlerin ortalama sayısıdır; nasıl yorumlanacağını load average nedir yazısında ayrıntılı anlattık.

Alarm yorgunluğunu önlemek

Her alarm bir insan müdahalesi gerektirmelidir; gerektirmeyen alarm, gerçek alarmın da görmezden gelinmesine yol açar.

Alarm yorgunluğu, çok sayıda gereksiz bildirim alan ekiplerin zamanla bildirimleri okumayı bırakmasıdır. SRE kitabı bunu açıkça söyler: çağrı (page) üreten her alarm eyleme dönüştürülebilir olmalı ve kullanıcıların gerçekten etkilendiğini göstermelidir. Uygulamada şunlar işe yarar:

• Uyarı ile kritik seviyeyi ayırın. Uyarılar mesai saatinde e-postaya, kritik alarmlar gece telefona gitsin.
• Tek bir başarısız kontrolde alarm üretmeyin; arka arkaya iki ya da üç başarısızlık bekleyin.
• Dış kontrolleri birden fazla lokasyondan yapın; tek bir izleme noktasının ağ sorunu yanlış alarm üretir.
• Bağımlılıkları tanımlayın. Sunucu kapalıysa, üzerindeki on servis için ayrı ayrı alarm göndermeyin.
• Planlı bakımlar için bakım penceresi tanımlayın.
• Ayda bir, hiçbir işlem yapılmadan kapanan alarmları gözden geçirip eşiği ya da kuralı düzeltin.

Araçlar: Zabbix, Prometheus + Grafana, Uptime Kuma, Netdata

Tek bir site için Uptime Kuma, birkaç sunucu için Netdata ya da Zabbix, çok sayıda servis ve konteyner için Prometheus ve Grafana iyi bir başlangıçtır. Dördü de açık kaynaklıdır.

Dış kontrol yapan aracı, izlediğiniz sunucunun üzerine kurmayın; sunucu kapandığında alarmı gönderecek olan da onunla birlikte kapanır. Ayrı küçük bir sunucuda Uptime Kuma'yı Docker ile şöyle çalıştırabilirsiniz:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

Panel 3001 numaralı portta açılır. Bu portu internete açık bırakmadan önce güvenlik duvarıyla sınırlayın ya da önüne HTTPS'li bir ters vekil koyun.

Durum sayfası (status page) nedir?

Durum sayfası, bir hizmetin bileşenlerinin anlık durumunu, yaşanan olayları ve planlı bakımları kullanıcılara gösteren herkese açık sayfadır. Kesinti anında destek hattına gelen "sorun sizde mi, bizde mi?" sorusunu azaltır. Uptime Kuma gibi araçlar, izleme sonuçlarından otomatik durum sayfası üretebilir.

Sağlayıcınızın durum sayfası ile kendi durum sayfanızı karıştırmayın. Bulutzone'un durum sayfası status.bulutzone.com adresindedir. Sağlayıcı durum sayfaları altyapının ve hizmet bileşenlerinin genel durumunu gösterir; sizin sunucunuzda MySQL'in çökmesi orada görünmez, kendi servisleriniz için kendi izlemeniz ya da servis izlemesi içeren bir yönetim paketi gerekir.

Kendin kur mu, hizmet al mı?

İzleme aracını kurmak bir öğleden sonra sürer; zor olan, alarm geldiğinde gece üçte müdahale edecek birinin olmasıdır. Karar da buna göre verilmelidir.

Ekibinizde alarmlara 7/24 yanıt verebilecek biri varsa ve eşikleri düzenli ayarlayabiliyorsanız, yukarıdaki açık kaynak araçlar yeterlidir. Alarm geldiğinde bakacak kimse yoksa, en özenli yapılandırılmış izleme sistemi bile yalnızca kesintinin saatini kaydeder. Bu durumda izlemeyi ve ilk müdahaleyi birlikte devretmek daha anlamlıdır. Hangi işlerin sağlayıcıya geçtiğini managed server yazısındaki matriste, izlemeyle birlikte yapılması gereken periyodik işleri de sunucu bakım kontrol listesi içinde bulabilirsiniz.

Sık sorulan sorular

Ücretsiz izleme aracı var mı?

Evet. Zabbix, Prometheus, Grafana, Uptime Kuma ve Netdata'nın açık kaynak sürümleri ücretsiz kullanılabilir. Maliyet yazılımdan değil, kurulum, bakım ve alarmlara yanıt verecek insan zamanından gelir. İzleme sunucusunun kendisi de izlenmesi ve güncellenmesi gereken bir sistemdir.

İzleme sunucusu nerede durmalı?

Dış kontroller, izlenen sunucudan farklı bir sunucuda ve mümkünse farklı bir ağda çalışmalıdır. Kaynak metrikleri ise sunucunun içindeki ajandan toplanır. İki parçanın birbirinden bağımsız olması, bir arızanın alarmı da susturmasını önler.

Hangi metrikler mutlaka izlenmeli?

Her sunucu için erişilebilirlik, disk ve inode doluluğu, kullanılabilir bellek ve load average; her web sitesi için HTTP durum kodu, yanıt süresi ve SSL süresi asgari settir. Veritabanı ve e-posta servisi çalışıyorsa bunların protokol düzeyindeki kontrolleri de listeye eklenmelidir.

Sunucunuzun yalnızca açık olup olmadığını değil, web, SQL ve mail servislerinin gerçekten çalışıp çalışmadığını da izletmek istiyorsanız, servis izleme içeren SLA-3 paketini inceleyin.

Kaynaklar

• Google SRE Book: Monitoring Distributed Systems
• RFC 792: Internet Control Message Protocol
• Zabbix Manual
• Prometheus: Overview
• Uptime Kuma (GitHub)
• Netdata documentation