Sunucu izlemede hangi metrikler takip edilmeli?
Sunucu izleme planında yanıt süresi, trafik, hata, kaynak kullanımı ve kritik kullanıcı akışlarını birlikte değerlendirin; uyarılara sorumlu ve aksiyon ekleyin.
Sunucunun açık olması, uygulamanın doğru çalıştığı anlamına gelmez. Kullanıcının gördüğü sonucu ve sistem kaynaklarını birlikte izleyin; her acil uyarının ne yapılacağını anlatan kısa bir karşılığı olsun.
Bu rehberde neler var?
Önce kullanıcının tamamladığı işi tanımlayın
Bir tanıtım sitesi için iletişim formunun gönderilebilmesi, bir içerik sitesi için rehberlerin açılması kritik olabilir. İzleme planına yalnızca ana sayfanın yanıt vermesini yazarsanız çalışmayan bir formu fark etmeyebilirsiniz. Önce projenin en önemli birkaç kullanıcı akışını listeleyin.
Kontrolü uygulamanın içinden ve dışından düşünün. Dışarıdan yapılan sayfa isteği kullanıcının yaşadığı erişim sorununu gösterebilir; uygulama kayıtları ise nedenini araştırmaya yardım eder. Test işlemlerinin gerçek müşteri kaydı veya bildirim üretmesini önleyecek ayrı bir yöntem belirleyin.
Dört temel sinyalle bir başlangıç ekranı kurun
Google’ın SRE izleme rehberi, kullanıcıya hizmet veren sistemlerde gecikme, trafik, hatalar ve kaynakların ne kadar dolu olduğuna odaklanır. Bu çerçeveyi uygulamanızın temel işlemlerine uyarlayabilirsiniz.
| Sinyal | Başlangıç sorusu | Örnek inceleme |
|---|---|---|
| Yanıt süresi | İşlem ne kadar bekletiyor? | Rehber ve form isteklerini ayrı inceleyin |
| Trafik | Sisteme ne kadar talep geliyor? | İstek hacmindeki değişimi gözleyin |
| Hata | İşlemlerin hangileri başarısız? | HTTP hatalarıyla uygulama sonucunu karşılaştırın |
| Kaynak kullanımı | Hangi kaynak sınıra yaklaşıyor? | Bellek, disk alanı ve iş kuyruğunu değerlendirin |
Başarılı ve hatalı isteklerin sürelerini ayrı görmek yararlıdır. Çok hızlı dönen bir hata, toplam yanıt süresini iyi gösterirken kullanıcıya sunulan hizmet bozulmuş olabilir.
Her değişim için aynı seviyede alarm vermeyin
CPU kullanımının kısa süre yükselmesi ile formun uzun süre gönderilememesi aynı aciliyette olmayabilir. Uyarıyı iş etkisiyle birlikte tanımlayın. İncelenecek bir eğilim, çalışma saatinde ele alınabilir; kritik kullanıcı akışının durması daha hızlı müdahale gerektirebilir.
Her proje için evrensel bir eşik yazmak yerine olağan çalışma davranışınızı ölçün. Uyarının kaç gözlemde tekrarlandığını, hangi zaman aralığını kapsadığını ve hangi veriye dayandığını kaydedin. Bakım veya bilinen test sırasında oluşan bildirimlerin nasıl ele alınacağını da belirleyin.
Uyarıyı kısa bir müdahale notuna bağlayın
Bildirimde sistemin adı, etkilenen işlem, başlangıç zamanı ve ilgili kayıt bağlantısı yer alsın. Sorumlu kişinin ilk kontrolü ne olacak? Hangi değişiklik yakın zamanda yapıldı? Hizmet sağlayıcıya hangi bilgiyle başvurulacak? Bunları olay anında sıfırdan aramayın.
- Önce kullanıcıya yansıyan sorunu doğrulayın.
- Son yayın veya yapılandırma değişikliğini kontrol edin.
- İlgili hata kayıtlarını aynı zaman aralığında inceleyin.
- Yetki sınırını aşan müdahaleyi sorumlu kişiye aktarın.
- Yapılan işlemi ve sonucunu olay kaydına ekleyin.
Bir uyarı geldi diye hizmeti otomatik olarak yeniden başlatmayı genel çözüm kabul etmeyin. Geçici düzelme, asıl nedeni açıklamayabilir; kayıtların korunması inceleme için önemlidir.
İzleme sistemini de düzenli kontrol edin
Bildirim adresi değiştiğinde, ekipten biri ayrıldığında veya kritik bir sayfa taşındığında izleme kuralı güncelliğini kaybedebilir. Kontrollü bir testle uyarının doğru kişiye ulaştığını doğrulayın. İzleme panelinin güncel veri gösterdiğinden ve kaydın kesilmediğinden emin olun.
Aylık değerlendirmede işe yarayan uyarıları, gereksiz bildirimleri ve gözden kaçan sorunları inceleyin. Takibi bakım planına bağlayın; kapasite ihtiyacı ortaya çıkarsa sunucu seçeneklerini ölçtüğünüz iş yüküyle değerlendirin.
Sık sorulan sorular
Sadece uptime kontrolü yeterli mi?
Erişilebilirliği gösterir, ancak formun veya başka bir iş akışının doğru tamamlandığını tek başına kanıtlamaz. Kritik uygulama sonuçlarını da kontrol edin.
Uyarı eşiğini hazır bir listeden alabilir miyim?
Bir başlangıç hipotezi olarak kullanılabilir; ancak uygulamanın olağan davranışı ve iş etkisiyle doğrulanmalıdır. Aynı eşik her proje için uygun olmayabilir.
Kaynaklar ve doğrulama
Platforma özgü bilgileri işlem yapmadan önce resmi kaynaktan kontrol edin.
Örnek planlar ve hesaplamalar genel bilgilendirme amaçlıdır. Yayın ve kaynak yaklaşımımız.