Sunucu İzleme: Metrikler, Uyarı Eşikleri ve Harici İzleme

Gece saat iki ve site açılmıyor. SSH bağlanıyorsunuz ama yanıt alamıyorsunuz. Hatırladığınız son şey dün her şeyin normal olduğu ve hiçbir uyarı almadığınız. İşte tam bu noktada sunucu izlemeniz olmadığı ya da vardı ama olması gereken şeye uyarı vermediği ortaya çıkıyor. Bu makale sıfırdan izleme kurulumu hakkında: neyi ölçmeliyiz, eşiği nasıl belirlemeliyiz ve neden yalnızca sunucunun kendisinde çalışan izleme işin yarısıdır.

Herhangi bir araçtan önce şu dört metriği ölçün

İzleme araçları onlarca metrik verir ve bu yüzden insanlar hepsini açıp sonra hiçbirine bakmaz. Başlamak için dört metrik yeterlidir. Bu dördü sağlıklıysa, geri kalanı genellikle onlara bağlıdır.

• Çekirdek sayısına göre load average. uptime komutu üç sayı verir: 1, 5 ve 15 dakikalık ortalama. Ham sayı anlamsızdır; çekirdek sayısına bölünmelidir. 4 çekirdekli bir sunucuda load 4 tam doygunluk demektir. Load 8, bekleme kuyruğunun işlem kapasitesinin iki katı olduğu anlamına gelir. Load yükseliyor ama CPU boştaysa, sorun işlemcide değil disk I/O'dadır; yüksek sunucu yükünün nedenini teşhis etme rehberi tam da bu durumu adım adım açıklıyor.
• Bellek ve swap kullanımı. free -m ile bakın, free sütununa değil available sütununa. available sayısı gerçekte yeni süreçlere verebileceğiniz miktardır. Swap sürekli kullanılıyorsa, sunucu canlıdır ama yavaştır; bu durum tam çökmeden daha kötüdür çünkü kimse fark etmez.
• Disk alanı ve inode. df -h blok alanını gösterir ve df -i inode sayısını. İkincisini ciddiye alın. %20 alanı olan ama inode'u tükenmiş bir sunucu hiçbir dosya oluşturamaz ve df boş alan gösterirken No space left on device hatası verir. Genellikle suçlu PHP session'ları veya sayısız küçük cache dosyasıdır.
• Hizmetin yanıt süresi, sadece canlı olması değil. nginx'in 200 koduyla yanıt vermesi yeterli değildir. Yanıt 8 saniye sürüyorsa, kullanıcı açısından site down'dır.

Gece sizi uyandırmayacak uyarı eşiği nasıl belirlenir

Sunucu izlemede en büyük hata, eşiği tahmine göre seçmektir. Biri "CPU %80'in üzerine çıkarsa uyarı ver" der ve sonra her gün saat 3'te bir e-posta alır çünkü gece yedeklemesi o saatte çalışıyor. İki hafta sonra o e-postayı filtreler ve artık hiçbir uyarı görmez. İşte tam da bu, izlemeniz olup yine de hazırlıksız yakalanmanıza neden olan şeydir.

Doğru yöntem şudur: önce bir hafta uyarı olmadan sadece veri toplayın. Sonra normal kalıbın ne olduğuna bakın. Eşiği normalde asla dokunulmayan bir şeye koyun, her gün dokunulan bir şeye değil.

"Süre koşulu" sütunu eşik sütunundan daha önemlidir. İki saniyelik CPU'nun %95'e anlık sıçraması kötü haber değildir; bir sunucunun yapması gereken tam da budur. Uyarı zirveye değil sürekliliğe dayanmalıdır. Prometheus'ta bunu rule bloğunda for: 10m ile yazarsınız:

- alert: HighLoad
  expr: node_load1 > (count(node_cpu_seconds_total{mode="idle"}) * 1.5)
  for: 10m
  labels:
    severity: warning

for: 10m satırı yanlış alarmları engelleyen şeydir. O olmadan, her ağır cron çalıştığında telefonunuz çalar.

Dahili izleme yeterli değil; dışarıdan da bakın

İşte birçok kişinin hata yaptığı yer burası. Netdata veya node_exporter'ı sunucuya kurarlar, güzel bir dashboard yaparlar ve içleri rahattır. Ama sunucunun kendisi erişilemez hale geldiğinde, o araç da erişilemez hale gelir. Sunucu yeniden başlarsa, ağ kartı ölürse, veri merkezinde elektrik sorunu olursa, güvenlik duvarı yanlışlıkla kapanırsa, hiçbir uyarı almazsınız çünkü uyarıcı ölen makinenin kendisindeydi.

Harici izleme, sunucunuzun dışında bağımsız bir noktanın her 60 saniyede bir HTTP isteği veya ping göndermesi ve yanıt gelmezse size haber vermesi demektir. Bu hizmet başka bir yerdeki ucuz bir VPS veya uptime monitoring hizmetlerinden biri olabilir. Önemli olan nokta, uyarı yolunun arıza yolundan ayrı olmasıdır.

Maliyetini de söyleyeyim: harici izleme sunucunun neden öldüğünü söyleyemez. Sadece öldüğünü söyler. Nedeni teşhis etmek için hâlâ dahili metriklere ve loglara ihtiyacınız var. Yani bu ikisi birbirinin yerini tutmaz; birbirini tamamlar. Sadece birini kurabiliyorsanız, harici izlemeyi seçin, çünkü geç uyarı tam sessizlikten iyidir.

Neyi bilerek izlemeyin

Eklediğiniz her metriğin depolama maliyeti ve dikkat maliyeti vardır. Birkaç şeyi bilinçli olarak bir kenara bırakın:

• Kendini yeniden başlatan hizmetler için süreç düzeyi metrikler. systemd hizmeti 5 saniye içinde ayağa kaldırıyorsa, bunun için uyarı vermek sadece gürültüdür.
• 404 hata oranı. Bu sayı genel sitelerde her zaman yüksektir ve neredeyse hiçbir zaman arıza belirtisi değildir.
• Sanal sunucularda CPU sıcaklığı. Sensör yoktur ve gördüğünüz sayı sahtedir.

Yarım saatte pratik kurulum

Bugün başlamak istiyorsanız, şu sırayı izleyelim:

1. Sunucuya node_exporter kurun ve systemd ile etkinleştirin. Varsayılan portu 9100'dür ve yalnızca izleme sunucusunun IP'sinden erişilebilir olmalıdır, internetten değil. Açık olmaması gereken portların listesini Yaygın hizmet portları referansı sayfasında görebilirsiniz.
2. Ayrı bir makinede Prometheus ayağa kaldırın ve prometheus.yml dosyasına hedefi ekleyin. Ayrı makineniz yoksa, bunun için küçük bir bulut sunucusu yeterlidir.
3. Yukarıdaki tablonun dört uyarısını yazın. Alertmanager'ı gerçek bir kanala bağlayın; telefonda bildirim vermeyen e-posta, uyarı değildir.
4. Sitenizin ana sayfasına 10 saniye timeout ile harici bir HTTP kontrolü ayarlayın.
5. Bir hafta çalışmasına izin verin ve sonra eşikleri gerçek verilere göre ayarlayın.

Sunucuyu yeni teslim aldıysanız ve henüz dağıtım ile hizmetleri seçmediyseniz, izlemeden önce sunucu Linux dağıtımı seçimi ve SSH yapılandırması işlemlerini yapın; sonradan değiştirmek zahmetlidir. Donanım üzerinde tam kontrol istediğiniz fiziksel sunucular için tahsis edilmiş sunucu daha yaygın bir seçenektir, ancak çoğu site için yönetilen bir Linux hosting yeterlidir ve bu izlemenin büyük bir kısmını omuzlarınızdan alır.

Burada hata yapıyorlar

Gördüğüm en yaygın hata şudur: biri Alertmanager'ı yapılandırır, ama uyarı gönderme yolu aynı sunucudan geçer. Yani uyarı yerel SMTP ile gönderilir. Sunucunun diski dolar, postfix kuyruğu yazamaz ve dışarı hiçbir e-posta çıkmaz. Belirtisi de şudur: dashboard'da uyarının tetiklendiğini görürsünüz ama inbox'ta hiçbir şey yoktur. Uyarı göndermek için her zaman harici bir relay kullanın.

İkinci hata, "hizmet ayakta" yerine "hizmet doğru çalışıyor" üzerine uyarı vermektir. nginx 502 koduyla da ayaktadır. Sağlık kontrolü, yalnızca 80 portunun açık olup olmadığına bakmak yerine veritabanına da dokunan gerçek bir endpoint'i çağırmalıdır.

Sık sorulan sorular

Linux sunucu izleme için hangi araç daha uygundur?

Hızlı başlangıç için Netdata en az zahmetlidir ve birkaç dakika içinde canlı dashboard verir. Hassas uyarılar ve uzun vadeli geçmiş istiyorsanız, Prometheus ile node_exporter ve Alertmanager kombinasyonu daha iyi bir seçimdir, karşılığında birkaç YAML dosyası yazmanız gerekir. Tek bir sunucu için Netdata yeterlidir; üç sunucudan itibaren Prometheus zamanına değer.

CPU uyarı eşiğini kaça koymalıyım?

Sabit bir sayı yoktur. Eşiği genel bir sayıya göre değil, çekirdek sayınıza ve kendi yük kalıbınıza göre belirleyin. Bir hafta veri toplayın, normal zirvelerin nerede olduğuna bakın ve eşiği bunun üzerine koyun. Sayıdan daha önemlisi süre koşuludur: uyarı anlık bir sıçramada değil, birkaç dakika sürdükten sonra etkinleşmelidir.

İzlemem olduğu halde arızayı neden geç fark ettim?

Neredeyse her zaman iki nedenden biridir: ya uyarı yanlış metriğe ayarlanmıştı, ya da uyarı gönderme yolu arızalanan sunucunun kendisinden geçiyordu. Üçüncü neden de az değildir: yanlış uyarılar o kadar çoktu ki kullanıcı onları filtrelemişti. Uyarılarınızı görmezden geliyorsanız, sorun izlemede değil, eşik ayarındadır.

Harici ve dahili izlemeye aynı anda ihtiyacım var mı?

Evet, nedeni de basittir: dahili izleme ne olduğunu söyler, harici izleme kullanıcının ne gördüğünü söyler. Birincisi sunucu öldüğünde susar; ikincisi sunucu öldüğünde tam o anda haber verir. Sadece bir seçeneğiniz varsa, harici olanı alın ve sonra dahili olanı ekleyin.

Bugün sitenizin ana sayfasına harici bir kontrol ayarlayın. Her 60 saniyede bir HTTP isteği, 10 saniye timeout ve telefonunuza ulaşan bir uyarı. Bu yarım saatlik iş, en güzel dashboard'dan daha değerlidir.