Bu rehber neyi çözer?
İyi monitoring yalnız CPU grafiği değildir; kapasite, hata, gecikme, servis sağlığı ve kullanıcı etkisini birlikte gösteren alarm modeli gerekir.
Host metrikleri
CPU utilization yanında load average, steal time, context switch ve run queue önemlidir.
RAM’de free değeri kadar cache, swap, OOM ve application working set izlenmelidir.
Disk ve filesystem
Latency, IOPS, throughput, queue depth, doluluk ve inode birlikte izlenmelidir.
Sadece %100 alarmı değil büyüme trendi ve tahmini tükenme süresi kullanılmalıdır.
Network ve servis
Error/drop, latency, bağlantı sayısı ve retransmit uygulama problemlerini açıklayabilir.
systemd servis, HTTP health, database connection ve kritik port kontrolleri eklenmelidir.
Prometheus vs Zabbix
Prometheus label tabanlı time-series ve cloud-native ekosistemde güçlüdür.
Zabbix agent/SNMP/template tabanlı bütünleşik izleme için klasik altyapılarda güçlüdür; seçim operasyon modeline göre yapılmalıdır.
Sık Sorulan Sorular
Load average yüksekse CPU yetersiz mi?
Her zaman değil. I/O beklemesi ve runnable process sayısı da değeri yükseltebilir.
Disk alarmı yüzde kaç olmalı?
Sabit eşik yanında büyüme trendi ve tahmini kapasite bitiş süresi kullanılmalıdır.
Monitoring ayrı sunucuda mı olmalı?
Üretimde bağımsız konumlandırmak arıza anında görünürlüğü korumaya yardımcı olur.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
Monitoring kaynağın kullanımını ve hizmetin kullanıcıya etkisini birlikte izlemelidir. Prometheus scraping/metric yaklaşımı, Zabbix ajan, SNMP ve diğer kontrol yollarıyla farklı işletim seçenekleri sunar. Kullanıcı kimliği gibi yüksek cardinality label değerleri veri hacmini büyütebilir. Alarm eşiği kadar toplama kesintisi ve hatalı etiketleme de yönetilmelidir.
- 1Metrik/log kaynakları
- 2Toplama ve etiketleme
- 3Zaman serisi/alarm
- 4Hizmet müdahalesi
Tasarım parametreleri
- Cardinality ve seri
- Kullanıcı veya request ID gibi sınırsız label değerleri seri sayısını büyütür; label bütçesi tanımlayın.
- Scrape ve servis sağlığı
- Exporter erişimi uygulama başarısını kanıtlamaz; metrik, sentetik işlem ve logları birlikte izleyin.
- Servis ve kullanıcı
- Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
- Depolama ve kalıcılık
- Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
- Ağ ve güvenlik katmanı
- Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
- Paket ve işletim yöntemi
- Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.
Hesap ve uygulama örneği
Örnek uygulama için latency, hata oranı, iş hacmi ve doygunluğu izleyin. Process ayakta olsa da HTTP sağlık kontrolü başarısız olabilir. Bir exporter kapatılarak veri yokluğu alarmı sınanır. Aynı olay için gereksiz alarm tekrarı yerine hizmet sahibi ve müdahale yolu tanımlanır.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Metrikler geliyor ama kesinti görülmüyor | Sadece host sağlığı izleniyor veya alarm koşulu yanlış olabilir. | Kontrollü uygulama arızasıyla alarm oluşumu ve bildirim yolunu test edin. |
| Servis aktif ama yanıt vermiyor | Process sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir. | Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin. |
| Dosya yazılamıyor | İzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir. | Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın. |
| Reboot sonrası yapılandırma kayboldu | Geçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir. | Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın. |
Kabul ve doğrulama kontrolleri
- Veri yokluğu alarmını ve kullanıcı etkili alarmı ayrı test edin.
- Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
- Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
- Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
- Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
- Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.
İlgili kavramlar
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Kuyruk ve eşzamanlılık
Kuyruk, bir kaynağın işleyebildiğinden daha hızlı gelen işleri tutar. Eşzamanlılığı artırmak belirli bir noktaya kadar kapasite kullanımını yükseltir; sonra bekleme süresini büyütür. Durağan durumda Little yasası L = λ × W ilişkisidir: ortalama sistemdeki iş sayısı, tamamlanan iş hızı ile ortalama toplam sürenin çarpımıdır. Birimler tutarlı olmalıdır. 2.000 işlem/s ve 5 ms toplam süre yaklaşık 10 eşzamanlı iş demektir. Bu ilişki tasarım tahminidir; kuyruk sınırları, ani yük ve çok değişken servis süreleri ayrıca ölçülmelidir.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.