Sunucuda Neyi İzlemeli? Disk, Bellek, İşlemci ve Ötesi

Sunucu arızalarının çoğu ani değil. Disk günlerce dolmaya devam ediyor, bellek haftalarca artıyor, yedekleme işi sessizce hata veriyor — ve bir sabah sistem duruyor.

İzleme, bu sinyalleri iş durmadan önce görmek demek. Ama yanlış kurulmuş bir izleme, gelen uyarıların hepsinin göz ardı edilmesiyle sonuçlanıyor. Bu yazı neyin izlenmesi gerektiğini ve gürültüden nasıl kaçınılacağını anlatıyor.

1. Disk alanı — en yaygın arıza sebebi

Disk dolduğunda sunucu genelde çökmüyor, daha kötüsünü yapıyor: yazamamaya başlıyor. Veritabanı hata veriyor, günlükler tutulamıyor, geçici dosyalar oluşturulamıyor ve uygulamalar açıklanamayan biçimde bozuluyor.

İzlenmesi gerekenler:

• Her bölümün (partition) doluluk oranı — sistem bölümü ayrı izlenmeli
• Doluluk artış hızı: haftada yüzde bir mi, günde yüzde beş mi?
• Büyüyen klasörler: günlük dosyaları, geçici dosyalar, yedek çıktıları, e-posta kuyrukları

Yaygın eşikler yüzde 80 bilgi, yüzde 90 uyarı, yüzde 95 acil biçiminde kuruluyor. Ama asıl değerli olan artış hızı: yüzde 70'te olup her gün artan bir disk, yüzde 85'te olup sabit duran diskten daha acil.

En sık disk dolduran sebep, temizlenmeyen günlük dosyaları ve eski yedeklerin birikmesi. İkisi de otomatik temizlemeyle çözülüyor.

2. Bellek

Bellek dolduğunda sistem takas alanına (swap) yazmaya başlıyor ve performans ciddi biçimde düşüyor. Kullanıcı tarafında bu, sistemin çok yavaşlaması olarak görünüyor.

Dikkat edilecek bir ayrım var: Linux'ta yüksek bellek kullanımı tek başına sorun değil — boş bellek önbellek olarak kullanılıyor ve gerektiğinde bırakılıyor. Asıl bakılması gereken takas kullanımı ve sürekli artış eğilimi.

Sürekli artan ve hiç düşmeyen bellek kullanımı bellek sızıntısına işaret ediyor. Bu, yeniden başlatmayla geçici olarak çözülüyor ama sebebi bulunmadan tekrar ediyor.

3. İşlemci

Anlık yüksek işlemci kullanımı normal — bir rapor çalışıyor olabilir. Anlamlı olan sürekli yüksek kalması.

• Ortalama kullanım: uzun süre çok yüksek kalıyorsa kapasite yetersiz
• Yük ortalaması (load average): çekirdek sayısına göre değerlendirilmeli
• Bekleme süresi (iowait): yüksekse sorun işlemcide değil, diskte

Son madde önemli bir ayrım: iowait yüksekken işlemci yükseltmek para kaybı — sorun disk hızında.

4. Servisler ve süreçler

Kaynak göstergeleri normal olsa da bir servis durmuş olabiliyor. Web sunucusu, veritabanı, e-posta servisi ve uygulama servisleri ayrı ayrı izlenmeli.

Servisin çalışıyor görünmesi cevap verdiği anlamına gelmiyor. Gerçek kontrol, servise bir istek gönderip cevabı doğrulamak.

5. Sessizce başarısız olan işler

Bu kategori en tehlikelisi çünkü hiçbir gösterge değişmiyor:

• Yedekleme işleri: çalıştı mı, ne kadar sürdü, boyutu makul mü?
• Zamanlanmış görevler: hata mı verdi, hiç mi çalışmadı?
• Sertifika bitiş tarihleri: SSL sertifikası bittiğinde site erişilemez oluyor
• Alan adı yenileme tarihleri
• Disk sağlığı (SMART): arıza öncesi uyarı verebiliyor

Yedekleme işinin çalışmadığını izlemek, çalıştığını izlemekten daha önemli. Beklenen saatte bir başarı kaydı gelmemişse uyarı üretilmeli — sessizlik, başarı demek değil.

Yedek boyutu da izlenmeli: normalde 40 GB olan yedeğin 2 GB gelmesi, işin başarılı görünüp aslında eksik çalıştığı anlamına geliyor.

6. Güvenlik göstergeleri

• Başarısız giriş denemeleri — ani artış saldırı işareti
• Yeni açılan kullanıcı hesapları
• Yönetici yetkisi verilen hesaplardaki değişiklikler
• Beklenmeyen dinleyen portlar
• Sistem dosyalarındaki değişiklikler

Uyarı gürültüsü: izlemenin en büyük düşmanı

Günde otuz uyarı gelen bir sistemde kimse uyarıları okumuyor. Gerçek arıza da o otuz uyarının içinde kayboluyor.

Gürültüyü azaltmanın yolları:

1. 01Eşikleri gerçekçi belirleyin. Normalde yüksek yükte çalışan bir sunucuda düşük eşik anlamsız.
2. 02Anlık sıçramalarda değil, süre koşuluyla uyarın: on dakikadan uzun süre eşiğin üzerinde kalmak gibi.
3. 03Tekrarlayan uyarıları gruplayın. Aynı sorun için saat başı e-posta göndermeyin.
4. 04Aciliyet seviyesi ayırın: bazıları gece uyandırmalı, bazıları sabah okunmalı.
5. 05Uyarıya karşılık gelen bir eylem yoksa o uyarıyı kaldırın. Yapılacak bir şey yoksa uyarı değil, gürültüdür.

Beşinci madde en çok göz ardı edileni ve en etkilisi.

Uyarılar nereye gitmeli?

E-postaya gönderilen uyarılar, e-posta sunucusu sorun yaşadığında gelmiyor — ve genelde sorun yaşandığı an tam da o an oluyor.

Kritik uyarılar için ikinci bir kanal gerekiyor: farklı bir e-posta sağlayıcısı, mesajlaşma uygulaması ya da SMS. Ayrıca sunucunun tamamen erişilemez olduğunu anlayan dışarıdan bir kontrol de olmalı — sunucunun kendi izleme yazılımı, sunucu kapalıyken haber veremiyor.

Ölçmeden önce: normal neye benziyor?

İzlemenin en çok atlanan adımı, eşik belirlemeden önce normali ölçmek. Bir sunucunun mesai saatlerinde yüzde 60 işlemci kullanması normal olabilir; başka bir sunucuda aynı değer sorun işaretidir.

Bunun için birkaç hafta veri toplayıp günün ve haftanın hangi saatlerinde ne olduğunu görmek gerekiyor. Ay sonu raporlaması, bordro dönemi ya da yedekleme penceresi gibi düzenli yük tepeleri bu dönemde ortaya çıkıyor ve eşikler buna göre kuruluyor.

Normali bilmeden konulan eşikler ya sürekli alarm üretiyor ya da gerçek sorunu kaçırıyor.

Uygulama tarafını da izleyin

Sunucu göstergeleri sağlıklı görünürken kullanıcı tarafında her şey yavaş olabiliyor. Aradaki farkı görmek için uygulama düzeyinde ölçüm gerekiyor:

• Sayfa ya da ekran açılma süresi
• Veritabanı sorgu süreleri ve yavaş sorgu kayıtları
• Hata oranı — uygulamanın ürettiği hata sayısındaki artış
• Eşzamanlı kullanıcı ve oturum sayısı
• Kuyruğa giren iş sayısı; artıyorsa sistem yetişemiyor demek

İkinci madde çoğu yavaşlığın gerçek kaynağı. Donanım yükseltmeden önce yavaş sorgulara bakmak, sık sık donanım gerekmediğini gösteriyor.

Kayıtları ne kadar saklamalı?

İzleme verisi iki farklı amaca hizmet ediyor ve saklama süresi buna göre belirleniyor. Anlık uyarı için birkaç gün yeterli; eğilim analizi ve kapasite planlaması içinse aylara ihtiyaç var.

Güvenlik kayıtları ayrı bir başlık: bir olayın ne zaman başladığını anlamak için geriye dönük giriş kayıtlarına ihtiyaç duyuluyor ve olaylar genelde haftalar sonra fark ediliyor. Bu kayıtların daha uzun ve tercihen sunucunun DIŞINDA saklanması gerekiyor — sunucuya sızan biri ilk iş olarak yerel kayıtları siliyor.

İzleme kurmanın makul sırası

1. 01Diskin dolmasını ve yedekleme işlerinin durmasını izleyin — en çok soruna yol açan iki başlık.
2. 02Servislerin gerçekten cevap verip vermediğini kontrol edin.
3. 03Sertifika ve alan adı bitiş tarihlerini takvime bağlayın.
4. 04Bellek ve işlemci eğilimlerini toplamaya başlayın; normali öğrenin.
5. 05Eşikleri normal değerlere göre belirleyin ve uyarıları açın.
6. 06Güvenlik kayıtlarını sunucu dışına aktarın.
7. 07Uygulama düzeyinde ölçüm ekleyin.

İlk üç madde tek başına, arızaların büyük kısmını önceden yakalıyor ve kurulumu birkaç saat sürüyor. İzleme kurmaya buradan başlamak, en hızlı geri dönüşü veren yol.

Özet

Disk doluluğunu ve artış hızını, bellek eğilimini, sürekli işlemci yükünü, servislerin gerçekten cevap verip vermediğini, sessizce duran işleri ve sertifika tarihlerini izleyin. Eşikleri gerçekçi kurun ve karşılığında yapılacak bir şey olmayan her uyarıyı kaldırın.

Sunucunuzda izleme yoksa ya da gelen uyarılar okunmayacak kadar çoksa, hangi göstergelerin sizin yapınızda anlamlı olduğunu birlikte belirleyebiliriz.