Yönetilen bulutta izleme, ekrana çok sayıda grafik koymakla kurulmaz. Her alarmın bir sahibi, bir eylemi ve geriye dönük bir değişiklik kaydı olduğunda kurulur. Metrik toplamak kolaydır. Zor olan, gece gelen bir bildirimin kime gideceğini, o kişinin ne yapacağını ve alarmın bir bakım işinden mi yoksa gerçek bir bozulmadan mı doğduğunu hızla ayırabilmektir. Bu yazı, yönetilen bulut servisleri ve operasyon hizmeti sayfasının izleme tarafını destekler. Eşik değeri, yanıt süresi ya da kapsam taahhüdü içermez.
Hızlı Özet
İzleme üç soruya cevap vermelidir. Sistem çalışıyor mu, yavaşlıyor mu ve kapasitesi tükeniyor mu. Bu soruların her biri farklı metrik ve farklı alarm ister. Alarm, bir insanın yapabileceği somut bir işe bağlanmazsa gürültüye dönüşür. Değişiklik kaydı alarm zaman çizgisine eklenmezse aynı olay iki kez incelenir. Leon-X bulut altyapısının sahibi değildir. İzleme kapsamını sorumluluk matrisiyle birlikte netleştirir ve sağlayıcı dokümantasyonuyla doğrular.
İçindekiler
- İzleme Hangi Soruları Cevaplar
- Hangi Metrikler Toplanır
- Alarm Nasıl Tasarlanır
- Değişiklik Yönetimi ile Bağlantı
- Sorumluluk Nerede Ayrılır
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Wikimedia Commons, Batelco Network Operations Centre (NOC). Fotoğraf Masdestructive tarafından çekilmiş olup CC BY-SA 3.0 lisansıyla yayımlanmıştır.
İzleme Hangi Soruları Cevaplar
Bir izleme düzeni kurmadan önce hangi kararı desteklemesi gerektiğini yazın. Üç soru çoğu ortam için yeterli bir başlangıç verir.
- Sistem çalışıyor mu. Servis yanıt veriyor mu, sanal makine ayakta mı, bağlantı kuruluyor mu.
- Sistem yavaşlıyor mu. Yanıt süresi uzuyor mu, kuyruklar birikiyor mu, hata oranı artıyor mu.
- Kapasite tükeniyor mu. Disk, bellek, işlemci ya da bağlantı sayısı sınıra yaklaşıyor mu.
Bu üç soru farklı hızlarda cevap ister. İlkine saniyeler içinde, ikincisine dakikalar içinde, üçüncüsüne günler öncesinden cevap vermek gerekir. Hepsini tek bir alarm tipiyle çözmeye çalışırsanız ya acil bir olayı geç duyarsınız ya da kapasite uyarısıyla gece uyanırsınız.
Hangi Metrikler Toplanır
Metrikleri katmanlara göre düşünmek, hangisinin neden toplandığını açıklar.
Platform katmanında sanal makinenin işlemci, bellek, disk ve ağ kullanımı bulunur. İşletim sistemi katmanında servis durumları, disk doluluğu ve olay kayıtları yer alır. Uygulama katmanında yanıt süresi, hata sayısı ve kuyruk uzunluğu izlenir. Kullanıcı deneyimi katmanında ise dışarıdan yapılan bir erişim denemesi, sistemin gerçekten kullanılabilir olup olmadığını gösterir.
Hangi uygulama metriğinin seçileceği konusunda iyi bilinen bir çerçeve vardır. Google SRE kitabı bir servisi gecikme, trafik, hata ve doygunluk olmak üzere dört sinyalle izlemeyi önerir. Bu dört sinyal, her katmanda aynı soruları sormanıza yardım eder. Bir metrik toplanıyorsa hangi karara yaradığı da yazılı olmalıdır. Kararı olmayan bir metrik depolama maliyeti üretir ama bilgi üretmez.
Alarm Nasıl Tasarlanır
Alarm, bir insanın yapabileceği bir işe bağlandığında değer taşır. Şu özellikleri taşıyan alarm kalıcı olarak kullanılabilir.
- Alarmın bir sahibi vardır ve bildirim doğrudan o kişiye ya da nöbet grubuna gider.
- Alarmın yanında kısa bir çalışma notu bulunur. Not, ilk bakılacak yeri ve olası eylemi söyler.
- Önem derecesi, iş etkisine göre belirlenir. Bir metriğin sınırı aşılması tek başına acil durum anlamına gelmez.
- Alarm tekrar eden bir durumu bildiriyorsa gruplanır, aynı mesaj art arda gönderilmez.
Eşik değerleri uygulamaya göre değişir ve hiçbir genel değer her ortam için geçerli değildir. Değeri belirlerken önce normal davranışı bir süre gözleyin, sonra sınırı bu davranışın dışına koyun. Eşiği sağlayıcının varsayılanında bırakmak, ilk haftada yanlış alarmları çoğaltır ve gerçek uyarıyı bastırır. Eşik ayarının kimde olduğu da sorumluluk matrisinde yazmalıdır.
Değişiklik Yönetimi ile Bağlantı
İzleme ile değişiklik yönetimi ayrı süreçler gibi görünür ama aynı zaman çizgisini paylaşırlar. Bir alarm geldiğinde ilk sorulacak şey, o anda bir değişiklik yapılıp yapılmadığıdır.
Bunun için iki pratik yeterlidir. Birincisi, her planlı değişiklik bir kayıt numarası taşır ve bu numara izleme panosunda zaman çizgisine eklenir. İkincisi, bakım penceresi sırasında beklenen alarmlar bastırılır ama bastırma bir bitiş süresiyle tanımlanır. Süresiz bastırma, pencere bittikten sonra da gerçek sorunları gizler.
Değişiklikten sonra bir doğrulama ölçümü de kayda eklenir. Değişiklik bitti diye iş kapanmaz. Uygulamanın yanıt süresinin ve hata sayısının eski düzeyine döndüğü görülmelidir. Bu kayıt, bir olay sonradan incelendiğinde hangi işin neye yol açtığını gösterir. Kayıt tutma ve erişim denetimi tarafı için ISO 27001 ve bulut bilişim yazısı ek bir çerçeve verir.
Sorumluluk Nerede Ayrılır
İzleme tek bir sahibe ait değildir. Platformun kendi sağlığını bulut sağlayıcı izler. Kurumun uygulaması ve verisi için ise izleme çoğu zaman kurumda ya da yönetilen hizmet kapsamındadır. Yönetilen bulut ve operasyon devri yazısındaki sorumluluk matrisi bu ayrımı satır satır yazmak için kullanılır. Bulut sunucunun operasyon modeli ve IaaS sorumluluk paylaşımı yazıları ise sağlayıcı ile kurum arasındaki çizginin nereden geçtiğini anlatır.
Matriste izleme için en az şu satırlar bulunmalıdır. Hangi metrikleri kim topluyor, eşikleri kim belirliyor, alarmı kim karşılıyor ve alarm gözden geçirme toplantısını kim yapıyor.
Yaygın Hatalar
Her metrik için alarm kurmak, ilk haftada bildirimlerin göz ardı edilmesine yol açar. Alarm sayısını artırmak yerine, her birinin bir eylemi olduğunu doğrulayın.
Sahibi olmayan alarm kimseye ait değildir. Bildirim bir ortak kutuya düşüyorsa kimse üstlenmez.
Bakım penceresi için alarmları kapatıp açmayı unutmak, pencere sonrasında gerçek bir sorunun görünmemesine neden olur.
İzlemeyi yalnızca altyapı metrikleriyle sınırlamak da yaygındır. Sanal makine ayakta olsa bile uygulama hata veriyor olabilir. Dışarıdan yapılan bir erişim denemesi bu boşluğu kapatır.
Son olarak alarm eşiklerini hiç gözden geçirmemek eşiklerin eskimesine yol açar. Uygulama değişir, normal davranış da değişir.
Kontrol Listesi
- İzleme hangi üç soruya cevap veriyor, yazılı mı
- Her metriğin hangi karara yaradığı belli mi
- Her alarmın sahibi, çalışma notu ve önem derecesi var mı
- Eşik değerlerini kim belirliyor ve ne zaman gözden geçiriyor
- Planlı değişiklikler kayıt numarasıyla izleme zaman çizgisine ekleniyor mu
- Bakım penceresi bastırmalarının bitiş süresi tanımlı mı
- Değişiklik sonrası doğrulama ölçümü kayda ekleniyor mu
- Dışarıdan yapılan bir erişim denemesi izlemede yer alıyor mu
Leon-X ile Sonraki Adım
Leon-X mevcut bulut ortamınızdaki izleme düzenini, alarm sahipliğini ve değişiklik kaydı bağlantısını birlikte inceler. Hangi metriklerin toplandığını, hangi alarmların eyleme dönüştüğünü ve hangi satırların sorumluluk matrisinde eksik kaldığını listeler. Kapsam ve izleme düzeni ortamınıza göre netleşir. Sağlayıcıya ait ayrıntılar resmi dokümantasyonla doğrulanır. Ayrıntılar yönetilen bulut servisleri ve operasyon hizmeti sayfasında yer alır. Keşif için iletişime geçin.
Sık Sorulan Sorular
İzleme ile alarm aynı şey mi?
Hayır. İzleme, metriklerin toplanması ve görünür kılınmasıdır. Alarm ise belirli bir koşulda bir kişiyi harekete geçiren bildirimdir. Her metrik alarm gerektirmez.
Yönetilen bulutta izlemeyi kim kurar?
Bu sözleşmede ve sorumluluk matrisinde yazılır. Platform metrikleri sağlayıcıdan gelir. Uygulama metriklerini ve eşikleri kimin belirleyeceği kapsama göre değişir.
Bakım sırasında alarmları kapatmak güvenli mi?
Süreyle sınırlandırıldığında güvenlidir. Bitiş zamanı olmayan bastırma, pencere sonrasında gerçek sorunları gizler.
Kaç alarm yeterlidir?
Sabit bir sayı yoktur. Ölçüt, her alarmın bir sahibi ve bir eylemi olmasıdır. Eylemi olmayan alarm azaltılır.
Sonuç
Yönetilen bulutta izleme, metrik sayısından çok alarmın bir insana ve bir eyleme bağlanmasıyla değer kazanır. Üç soruyu cevaplayan katmanlı bir metrik seti, sahibi belli alarmlar ve değişiklik kaydıyla bağlı bir zaman çizgisi çoğu operasyon sorusunu hızlandırır. Kapsam için yönetilen bulut servisleri ve operasyon hizmeti sayfasına bakabilirsiniz.
Kaynaklar
- Google, Site Reliability Engineering kitabı, Monitoring Distributed Systems bölümü
- NIST SP 800-145, bulut bilişimin tanımı ve hizmet modelleri
- Leon-X, yönetilen bulut servisleri ve operasyon hizmeti
