Alarm bildirimini bulgu ve müdahale planıyla hazırlamak
Somut bir portal örneği hata oranını, sorumluyu ve ilk kontrolü bağlar. Alarm tek başına nedeni veya sorunun giderildiğini kanıtlamaz.
Yararlı bir alarm bildirimi, uygulamada neyin dikkat çektiğini ve ilk müdahale yolunun ne olduğunu gösterir. Bildirim, alıcının hizmeti bilinmeyen bir sunucu adından tahmin etmesini gerektirmeden anlaşılmalıdır.
Kullanıcı görevinden sinyale geçmek
Müşteri portalında proje listesini yüklemek gibi önemli bir görevle başlayın. Prometheus, etkileşimli hizmetler için kullanıcıya görünen hataları ve nedenleri araştırmaya uygun görünümleri önerir. Kaynak kullanım değeri bağlam sağlayabilir; proje listesinin çalışıp çalışmadığını kendiliğinden açıklamaz.
Ölçüme hangi istek ve yanıtların girdiğini belirleyin. Tekrarlanan çağrılar ek istektir; farklı kişilerin de etkilendiğini göstermez. Bu nedenle hata oranının paydası açık olmalıdır.
Somut bir alarm örneği
Aşağıdaki yazılım ekibi, ölçüm değerleri ve kurallar kurgusaldır. Örnek; gerçek bir ASES olayı, genel bir sınır değer veya destek vaadi değildir. Payda, burada belirtilen işlemin kaydedilen bütün istekleridir. Seçilen kural 5 dakikalık bir pencereyi değerlendirir; ayrıca bekleme süresi istemez.
Alan | Örnek değer |
|---|---|
Bildirim | Müşteri portalında proje listesi sunucu hatası döndürüyor. |
Kapsam |
|
Zaman penceresi | 09:10–09:15, Europe/Berlin |
Bulgu | 100 istekten 20’sinde sunucu hatası yanıtı |
Örneğin kuralı | En az 50 istekte, 5 dakikalık pencerede %10’dan fazla sunucu hatası. |
Sorumlu |
|
Başlangıç | Tam bu hizmet, işlem ve dönem için görünüm; “Proje listesi” runbook’u. |
Burada hem asgari istek sayısı hem hata sınırı aşılmıştır. %20, bu penceredeki istekleri anlatır. Aynı oranda kullanıcının etkilendiğini veya belirli bir nedeni kanıtlamaz.
İlk müdahaleyi hazırlamak
Runbook, planlanan teşhis yolu için kısa bir uygulama yönergesidir. Önce sorumlu kişi işi üstlendiğini onaylar ve sorunun sürüp sürmediğini inceler. Üstlenme onayı, hatanın giderildiği anlamına gelmez. Görünümdeki ön seçim aynı hizmet, işlem ve zaman bilgilerini kullanmalıdır.
Sonra etkilenen uygulama örnekleri, sürümler ve bağımlılıklar belirlenir. Örnekte 09:08’de yapılmış bir sürüm yayını, incelenecek olaydır; neden kanıtı değildir. Geri alma, uygun ve önceden kontrol edilmiş bir yol gerektirir; alarm bildirimi her yeniden başlatma veya değişiklik için izin sayılmaz.
Bildirim yolunu da kontrol etmek
Alertmanager benzer bildirimleri gruplayıp yapılandırılmış alıcılara yönlendirebilir. Etkilenen uygulama örnekleri görünür kalmalıdır. Bağımsız sorunlar yalnız adları benziyor diye birleştirilmemelidir.
Açıkça test olarak işaretlenmiş bir bildirimle almayı, üstlenmeyi ve yedek yolu da kontrol edin. Prometheus, izleme sisteminin kendisinin izlenmesini açıkça belirtir. Daha sonra normalleşen değerler alarm durumunu bitirebilir; kullanıcı görevini kontrol etmenin veya neden araştırmasının yerini tutmaz. Başarılı durum koduyla dönen ama iş sonucu yanlış olan yanıtlar veya yavaş yanıtlar, bu basit sunucu hatası kuralıyla tek başına yakalanmaz.
Kaynaklar
Devamını okuyun
Tüm yazılar
ASES ile Bulut ve işletim
Barındırma, yayına alma, bakım ve destek