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
- Dört temel sinyalle bir başlangıç ekranı kurun
- Karar tablosu: durumunuzu değerlendirin
- Her değişim için aynı seviyede alarm vermeyin
- Uyarıyı kısa bir müdahale notuna bağlayın
- Alarm var ama kullanıcı etkisi yoksa
- İzleme sistemini de düzenli kontrol edin
- Uygulama kontrolü ve dikkat edilecek nokta
- Sık sorulan sorular
Ö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.
Karar tablosu: durumunuzu değerlendirin
Dar ekranda tüm sütunları görmek için tabloyu yatay kaydırabilirsiniz.
| Durum | Nasıl yorumlanır? | Sonraki adım |
|---|---|---|
| Belirti | Kullanıcı işlemleri yavaşlıyor veya başarısız oluyor. | Önce etkiyi ve kapsamı doğrulayın; ilgili hizmetin müdahale planını açın. |
| Kaynak sinyali | CPU, bellek veya disk davranışı değişiyor. | Değişimi kullanıcı hatası ve iş yüküyle ilişkilendirin; tek metrikten neden sonucu çıkarmayın. |
| İzleme kaybı | Veri veya kontrol isteği artık gelmiyor. | Bunu sağlıklı durum saymayın; izleme hattını ve erişim sorununu ayrıca araştırın. |
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.
Alarm var ama kullanıcı etkisi yoksa
AÇIKLAMALI ÖRNEK · TEMSİLÎ SENARYO
Gece çalışan bir raporlama işi işlemci kullanımını yükseltiyor, fakat kullanıcı istekleri normal sürede tamamlanıyor olsun. Her işlemci artışını acil çağrıya dönüştürmek ekibi gereksiz yere kesintiye uğratabilir. Buna karşılık işlemci düşükken veritabanı bağlantı havuzu dolduğu için kullanıcı işlemleri başarısız olabilir. Altyapı sinyali ile kullanıcı etkisi birlikte okunmalıdır.
Örnek izleme planında başvuru formunun dışarıdan tamamlanması, hata oranı ve istek süresinin dağılımı takip edilir. Kaynak metrikleri sorunun nedenini araştırmaya yardımcı olur. Alarmın kime gideceği ve ilk kontrol adımı yazılıdır. Sürekli yok sayılan bir alarm varsa eşik kadar alarmın gerçekten eylem gerektirip gerektirmediği de gözden geçirilir.
İ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.
Uygulama kontrolü ve dikkat edilecek nokta
KENDİ ÇALIŞMANIZA UYGULAYIN
- Her acil alarm için sorumlu, ilk inceleme adımı ve kapatma koşulu yazın.
- Ortalamanın yanında yavaş istekleri gösteren dağılımı ve etkilenen istek sayısını izleyin.
- Deneme uyarısı göndererek bildirim kanalının ve nöbet devrinin gerçekten çalıştığını doğrulayın.
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.
Her metrik için alarm kurulmalı mı?
Hayır. Bazı metrikler araştırma ve kapasite planlaması içindir. Alarm, bir kişinin zamanında müdahale etmesini gerektiren durumu ifade etmelidir. Gürültüyü azaltmak gerçek sorunların fark edilmesini kolaylaştırır.
Kaynaklar ve doğrulama
Bu kaynaklar ilgili platform veya teknik konu için referanstır. Örnek senaryolar editoryal açıklamalardır; bağımsız ürün testi veya gerçek müşteri sonucu değildir. Değişebilen koşulları işlem öncesinde resmi kaynaktan doğrulayın.
Bu rehber Takipci.gen.tr tarafından hazırlanmıştır. Temsilî senaryolar ve hesaplamalar yöntemi açıklamak içindir; ölçülmüş müşteri sonucu veya başarı garantisi değildir. Yayın ve kaynak yaklaşımımız.