Sunucu izleme: neyi, hangi eşikle izlemeli?

İzleme sisteminin başarısı topladığı metrik sayısıyla değil, gerçekten önemli bir şey olduğunda sizi zamanında haberdar etmesiyle ölçülür. Yüz grafiği olan ama gece üçte disk dolduğunda susan bir kurulum, işe yaramaz.

Önce dışarıdan bakın

En değerli kontrol en basit olanıdır: sunucunun dışından, düzenli aralıklarla siteye HTTP isteği atmak. Sunucunun içinde çalışan bir ajan, sunucu tamamen düştüğünde size haber veremez. Dış kontrolde bakılacaklar:

• HTTP durum kodu 200 mü?
• Yanıt süresi eşiğin altında mı?
• Sayfada beklenen bir metin geçiyor mu? (Sunucu 200 dönüp boş sayfa da verebilir.)
• SSL sertifikasının bitmesine kaç gün kaldı?

Kontrol sıklığı bir dakika, uyarı için iki ardışık başarısızlık şartı iyi bir başlangıçtır. Tek seferlik ağ dalgalanmasında gece yarısı uyanmazsınız.

Dış kontrolü kendiniz kurmak

Hazır bir izleme servisi kullanmıyorsanız, başka bir makinede dakikada bir çalışan tek satır bile işi görür:

curl -fsS --max-time 10 https://ornek.com/ | grep -q "Sepetim" || bildirim-gonder

Üç parçanın da görevi var: -f sunucu 5xx döndüğünde çıkış kodunu bozar, --max-time asılı kalan bağlantıyı keser, grep ise sayfanın boş değil gerçekten dolu geldiğini doğrular. Sertifika için ayrı bir satır yeter:

echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null | openssl x509 -noout -enddate

Bu kontrolü izlediğiniz sunucunun üzerinde çalıştırmayın. Aynı makinede duran bir kontrol, makine düştüğünde sizinle birlikte susar. Bir VDS'iniz varsa ikinci bir küçük sunucu ya da bir bulut örneği bu iş için fazlasıyla yeterlidir.

İzlenecek yedi metrik ve eşikleri

Disk için mutlak eşik yerine eğilim izlemek daha iyidir: "mevcut hızla 48 saat içinde dolacak" uyarısı, %80 eşiğinden daha erken ve daha anlamlıdır.

Inode'u unutmayın

Disk yüzdesi %40 görünürken "no space left on device" hatası alan sunucular çoğunlukla inode tükenmesi yaşar. Sebebi genellikle milyonlarca küçük dosyadır: oturum dosyaları, önbellek klasörü, temizlenmeyen kuyruk dizinleri. df -i komutu bu tabloyu gösterir ve izleme listesinde disk yüzdesinin hemen yanında olmalıdır.

Inode tükendiğinde suçluyu bulmak için dizinleri dosya sayısına göre sıralayın:

for d in /var/*; do echo "$(find "$d" -xdev -type f 2>/dev/null | wc -l) $d"; done | sort -rn | head

Sonuç çoğunlukla /var/lib/php/sessions, /var/spool ya da bir uygulamanın önbellek dizinini gösterir. Çözüm dosyaları elle silmek değil, oturum ömrünü ve önbellek temizleme işini düzeltmektir; elle silinen dizin iki hafta sonra geri gelir.

Elle bakarken kullanılacak komutlar

Bir uyarı geldiğinde sunucuya bağlanıp ilk beş dakikada bakılacaklar hep aynıdır. Bu listeyi ezberlemek, panik anında zaman kazandırır:

free -m çıktısında used değil available sütununa bakın; Linux boş belleği disk önbelleği olarak kullanır ve bu tamamen normaldir. Gerçek darlık işareti, takas alanının aktif olarak yazılıp okunmasıdır — vmstat 2 çıktısındaki si ve so sütunları sıfırdan farklıysa sistem gerçekten sıkışmıştır.

Uygulama seviyesinde iki metrik

• Hata oranı. Toplam isteklerin yüzde kaçı 5xx dönüyor? Normal seviyeyi bilmeden eşik koyamazsınız; bir hafta ölçüp temel çizgiyi çıkarın.
• Yanıt süresi yüzdelikleri. Ortalama yanıt süresi yanıltıcıdır. p95 ve p99 değerlerine bakın: kullanıcıların en yavaş yüzde beşi ne yaşıyor? Ortalama iyi görünürken p99'un beş saniye olması yaygındır.

Alarm yorgunluğu gerçek bir risktir

Gereksiz uyarı, uyarı yokluğundan daha tehlikelidir; çünkü ekip bir süre sonra hepsini görmezden gelmeye başlar. Üç kural:

1. Her uyarı bir eylem gerektirmeli. Karşılığında yapılacak bir şey yoksa o bir uyarı değil, bir grafiktir.
2. Kendiliğinden düzelen durumlar uyarı üretmemeli. Gecikme (örneğin beş dakika sürmesi şartı) ekleyin.
3. Uyarıları önceliklendirin. Gece uyandıracak olanlar ile sabah bakılacaklar ayrı kanallardan gelsin.

İzleme sisteminin kendisini kim izliyor?

Sessiz kalan bir izleme kurulumu, "her şey yolunda" ile "izleme çalışmıyor" arasındaki farkı size söyleyemez. Çözüm ters mantıkla çalışan bir kontroldür: yedek işi, cron görevleri ve ajanlar başarıyla bittiklerinde dışarıdaki bir uca ben yaşıyorum sinyali gönderir; sinyal beklenen sürede gelmezse uyarı üretilir. Yedeklemede bu düzeneğin kritik olma sebebi, başarısızlığın çoğunlukla gürültüsüz olmasıdır — ayrıntısı yedekleme yazısında.

Ayrıca uyarı kanalının kendisini ayda bir sınayın. Bilerek eşiği düşürüp bir uyarı tetikleyin ve mesajın gerçekten telefonunuza düştüğünü görün. Süresi dolmuş bir web kancası ya da spam klasörüne düşen bir e-posta, kesinti anında fark edilecek en kötü sürprizdir.

Sık yapılan üç hata

• Eşikleri temel çizgi ölçmeden koymak. Belirtisi: kurulumun ilk günü onlarca uyarı gelmesi. Bir hafta yalnız veri toplayın, eşiği gerçek dağılıma göre belirleyin.
• Yalnız sunucuyu izleyip işi izlememek. CPU, disk ve bellek yeşilken ödeme sağlayıcısına giden çağrılar başarısız olabilir. Saatlik sipariş ya da kayıt sayısı gibi bir iş metriğini de eşiğe bağlayın.
• Uyarıyı susturup unutmak. Belirtisi: aylardır "bakım modunda" duran kurallar. Susturmaya her zaman bir bitiş tarihi verin; süre dolduğunda kural kendiliğinden geri açılsın.

Bu yaklaşım ne zaman yanlış olur

Yukarıdaki eşik tablosu tek sunucu üzerinde çalışan klasik bir web yığını içindir. Şu durumlarda tabloyu olduğu gibi uygulamayın:

• Toplu iş sunucularında yükün çekirdek sayısını aşması normaldir; orada anlamlı eşik yük değil, işin bitiş süresidir.
• Konteyner ve otomatik ölçeklenen kurulumlarda tek bir örneğin ölmesi olay değildir. Uyarıyı örneğe değil, sağlıklı örnek sayısına ve toplam hata oranına bağlayın.
• Paylaşımlı barındırmada sunucu metriklerine erişiminiz yoktur; izlenecek şey dış erişim, yanıt süresi ve disk kotasıdır.

Günlükleri metriklerin yanına koyun

Metrik "bir şey oldu" der, günlük "ne oldu" der. Bir uyarı geldiğinde ilgili zaman aralığındaki günlüklere hızlıca bakabiliyor olmanız gerekir. En azından web sunucusu erişim ve hata günlükleri, uygulama günlüğü ve sistem günlüğü tek bir yerden aranabilir olsun. logrotate ayarlarını kontrol edin; sınırsız büyüyen bir günlük dosyası, izlemek istediğiniz diski dolduran sebebin ta kendisi olabilir.

İzleme sistemi kurmadan önce: tek dosyalık eşik kontrolü

Tam bir izleme yığını kurmak zaman ister; ama disk dolmasını ya da inode tükenmesini haber almak için o yığına gerek yoktur. Aşağıdaki küçük betik, yukarıdaki tablodaki en sık dört eşiği beş dakikada bir denetler ve aşıldığında sistem günlüğüne uyarı yazar. İsterseniz bir sohbet ya da bildirim servisine de gönderir. Bir deneme sunucusunda kurup diski bilerek doldurarak sınadık.

#!/bin/bash
# /usr/local/bin/esik-kontrol
uyar() { logger -t esik-kontrol -p user.warning "$1"
  [ -n "${WEBHOOK:-}" ] && curl -fsS --max-time 10 -d "text=$(hostname): $1" "$WEBHOOK" >/dev/null; }
df -P -x tmpfs -x devtmpfs | awk 'NR>1 {sub("%","",$5); if ($5+0 >= 85) print $6, $5}' |
  while read -r yol yuzde; do uyar "disk $yol %$yuzde"; done
df -P -i -x tmpfs -x devtmpfs | awk 'NR>1 && $5!="-" {sub("%","",$5); if ($5+0 >= 85) print $6, $5}' |
  while read -r yol yuzde; do uyar "inode $yol %$yuzde"; done
read -r yuk _ < /proc/loadavg; cekirdek=$(nproc)
awk -v y="$yuk" -v c="$cekirdek" 'BEGIN{exit !(y > c*1.5)}' && uyar "yük $yuk (çekirdek $cekirdek)"
kullanilabilir=$(awk '/MemAvailable/ {print int($2/1024)}' /proc/meminfo)
[ "$kullanilabilir" -lt 200 ] && uyar "kullanılabilir bellek ${kullanilabilir} MB"
exit 0

Cron yerine systemd zamanlayıcısı kullanmanın iki faydası vardır: her çalışmanın çıktısı ve çıkış kodu günlükte durur, ve systemctl list-timers bir sonraki çalışmayı gösterir. İki küçük birim dosyası yeter:

# /etc/systemd/system/esik-kontrol.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/esik-kontrol

# /etc/systemd/system/esik-kontrol.timer
[Timer]
OnBootSec=2min
OnUnitActiveSec=5min
[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now esik-kontrol.timer

Denemede 24 GB'lık diske 18 GB'lık bir dosya yazıp doluluğu %90'a çıkardık; servisi elle tetiklediğimizde journalctl -t esik-kontrol çıktısında disk / %90 satırı belirdi. Dosyayı silince uyarı da kesildi. Siz de kurulumdan sonra bu provayı bir kez yapın: hiç uyarı üretmemiş bir kontrolün çalıştığını bilemezsiniz.

Bu betik dış kontrolün yerini tutmaz. Sunucu tamamen kapandığında kendi kendine haber veremez; dışarıdan HTTP kontrolü ve sertifika bitiş kontrolü (SSL sertifika kontrolü aracıyla elle de bakabilirsiniz) yine gereklidir. Betik, o dış kontrolün göremediği iç tükenmeleri erken yakalamak içindir.

Olay sonrası inceleme

Her kesintiden sonra üç soruyu yazılı cevaplayın: Ne oldu? Neden fark etmemiz bu kadar sürdü? Bir dahakine daha erken fark etmek için hangi kontrolü ekliyoruz? Üçüncü sorunun cevabı bir izleme kuralına dönüşmüyorsa inceleme yarım kalmıştır.

Bu düzeneği kurmak zaman ister; yönetim yükünü üstlenmek istemiyorsanız paylaşımlı barındırma veya yönetilen altyapı tarafında izleme sağlayıcıdadır. Kendi sunucunuzu işletiyorsanız, izlemeyi ilk gün listesinin bir maddesi olarak görün.

Sık sorulan sorular