İzleme ve tanılama kılavuzu

Bulutta çalıştırılan dağıtılmış uygulamalar ve hizmetler, doğaları gereği birçok hareketli parçadan oluşan karmaşık yazılımlardır. Üretim ortamında, kullanıcıların sisteminizi nasıl kullandığını izleyebilmek, kaynak kullanımını izlemek ve sisteminizin sistem durumunu ve performansını genel olarak izlemek önemlidir. Bu bilgileri, sorunları algılar ve düzeltirken tanılama yardımcısı olarak kullanabilirsiniz ve ayrıca bu bilgiler olası sorunların saptanmasına ve sorun ortaya çıkmadan önlenmesine yardımcı olabilir.

İzleme ve tanılama senaryoları

İzlemeyi kullanarak sistemin ne kadar iyi çalıştığı konusunda öngörüler elde edebilirsiniz. İzleme, hizmet kalitesi hedeflerini tutturmanın önemli bir parçasıdır. İzleme verileri toplamaya yönelik yaygın senaryolar şunlardır:

• Sistemin iyi durumda çalışmayı sürdürdüğünden emin olma.
• Sistemin ve bileşen öğelerinin kullanılabilirliğini izleme.
• İş hacmi arttığında sistemin aktarım hızının beklenmedik bir düşüş göstermediğinden emin olmak için performansı koruma.
• Sistemin müşterilerle yapılan tüm hizmet düzeyi sözleşmelerine (SLA) uyduğunu garanti etme.
• Sistemin, kullanıcıların ve verilerinin gizliliğini ve güvenliğini koruma.
• Denetim ve yasal düzenleme amacıyla gerçekleştirilen işlemleri izleme.
• Sistemin gündelik kullanımını izleme ve ilgilenilmediği takdirde sorunlara yol açabilecek eğilimleri belirleme.
• Ortaya çıkan sorunları ilk rapordan başlayıp olası nedenlerin analizi, düzeltme, izleyen yazılım güncelleştirmeleri ve dağıtım boyunca izleme.
• İşlemleri izleme ve yazılım sürümlerinde hataları ayıklama.

Aşağıdaki bölümlerde bu senaryolar daha ayrıntılı olarak açıklanır. Her senaryoyla ilgili bilgiler şu biçim kullanılarak ele alınmıştır:

1. Senaryoya kısa bir genel bakış.
2. Bu senaryonun tipik gereksinimleri.
3. Senaryoyu ve bu bilgilerin olası kaynaklarını desteklemek için gereken ham izleme verileri.
4. Anlamlı tanılama bilgileri oluşturmak için bu ham verilerin nasıl analiz edilebileceği ve birleştirilebileceği.

Sistem durumunu izleme

Sistem çalışıyorsa ve istekleri işleyebiliyorsa iyi durumda demektir. Sistem durumunu izlemenin amacı, sistemin geçerli durumunun bir anlık görüntüsünü oluşturarak tüm sistem bileşenlerinin beklendiği gibi çalıştığını doğrulayabilmenizdir.

Sistem durumunu izleme gereksinimleri

Sistemin herhangi bir bölümü iyi durum değil gibi görünüyorsa, operatör hemen (saniyeler içinde) uyarılmalıdır. Operatör sistemin hangi bölümlerinin normal çalıştığını ve hangi bölümlerinde sorun yaşandığını tespit edebilmelidir. Sistem durumu bir trafik ışığı sistemiyle vurgulanabilir:

• Kırmızı, iyi durumda değil (sistem durduruldu)
• Sarı, kısmen iyi durumda (sistem sınırlı işlevsellikte çalıştırılıyor)
• Yeşil, tamamen iyi durumda

Kapsamlı bir sistem durumu izleme sistemi, operatörün sistem genelinde detaya giderek alt sistemlerin ve bileşenlerin durumunu görüntüleyebilmesine olanak tanır. Örneğin, sistemin bir bütün olarak kısmen iyi durumda belirtiliyorsa, operatörün sisteme yakından bakabilmesi ve şu anda hangi işlevselliğin kullanılamadığını saptayabilmesi gerekir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Sistem durumu izleme işlemini destekleyecek ham veriler, şu işlemler sonucu oluşturulabilir:

• Kullanıcı isteklerinin yürütülmesini izleme. Bu bilgiler hangi isteklerin başarılı, hangilerinin başarısız olduğunu ve her isteğin ne kadar zaman aldığını saptamak için kullanılabilir.
• Yapay kullanıcı izleme. Bu işlemde, kullanıcı tarafından gerçekleştirilen adımların benzetimi yapılır ve önceden tanımlanmış bir dizi adım uygulanır. Her adımın sonuçları yakalanmalıdır.
• Özel durumları, hataları ve uyarıları günlüğe kaydetme. Bu bilgiler hem uygulama koduna eklenmiş izleme deyimlerinin sonucu olarak hem de sistemin başvurduğu tüm hizmetlerin olay günlüklerinden bilgi alarak yakalanabilir.
• Sistemin kullandığın tüm üçüncü taraf hizmetlerin durumunu izleme. Bu izleme için söz konusu hizmetlerin sağladığı durum verilerini almak ve ayrıştırmak gerekebilir. Bu bilgiler çeşitli biçimlerde olabilir.
• Uç nokta izleme. Bu mekanizma "Kullanılabilirliği izleme" bölümünde daha ayrıntılı açıklanmıştır.
• Arka plan CPU kullanımı veya G/Ç (ağ dahil) etkinliği gibi çevresel performans bilgilerini toplama.

Sistem durumu verilerinin analizi

Sistem durumu izlemenin birincil odak noktası, sistemin çalışıp çalışmadığını hızla göstermektir. Anlık verilerin hızlı analizi, kritik bir bileşenin iyi durumda olmadığı algılandığında bir uyarıyı tetikleyebilir. (Örneğin, ardışık bir ping dizisine yanıt veremiyor.) İşleç daha sonra uygun düzeltici eylemi gerçekleştirebilir.

Daha gelişmiş bir sistem, geçmiş ve geçerli iş yükleri üzerinde gecikmeli analiz gerçekleştiren tahmine dayalı bir bölüm içerebilir. Gecikmeli analiz eğilimleri ortaya koyabilir ve sistemin iyi durumda kalıp kalamayacağını ve ek kaynaklara ihtiyacı olup olmayacağını saptayabilir. Tahmine dayalı bu bölüm, aşağıdakiler gibi kritik performans ölçümlerine dayanmalıdır:

• Her hizmete veya alt sisteme yönlendirilen isteklerin oranı.
• Bu isteklerin yanıt süreleri.
• Her hizmette içeri ve dışarı veri akışının hacmi.

Ölçümlerden herhangi birinin değeri tanımlı eşiği aşarsa, sistemin durumunu korumak üzere operatörün veya otomatik ölçeklendirmenin (varsa) gerekli önleyici eylemleri gerçekleştirebilmesi için sistem uyarı verebilir. Bunlar kaynak ekleme, hatalı durumdaki bir veya birden çok hizmeti yeniden başlatma veya düşük öncelik isteklerin sayısını azaltma gibi eylemler olabilir.

Kullanılabilirliği izleme

Gerçekten iyi durumda bir sistem için, sistemi oluşturan bileşenlerin ve alt sistemlerin kullanılabilir olması gerekir. Kullanılabilirliği izleme, sistem durumunu izlemeyle yakından ilgilidir. Ama sistem durumunu izleme işleminde sistemin geçerli durumunun anlık görüntüsü sağlanırken, kullanılabilirliği izleme sistemin çalışma süresi hakkındaki istatistikleri oluşturmak üzere sistemin ve bileşenlerinin kullanılabilirliğini izlemeyle ilgilenir.

Birçok sistemde, ciddi bir hata veya bağlantı kaybı söz konusu olduğunda yükü hızla devredebilmek için bazı bileşenler (örneğin, veritabanı) yerleşik yedekli çalışma özelliğiyle yapılandırılır. İdeal olan, kullanıcıların böyle bir hatanın oluştuğunu fark etmemesidir. Ama kullanılabilirliği izleme açısından bakıldığında, bu tür hatalarda nedeni saptamak ve yeniden oluşmasını önleyecek düzeltici eylemleri gerçekleştirmek için mümkün olduğu kadar çok bilgi toplamak gerekir.

Kullanılabilirliği izlemek için gereken veriler, alt düzey faktörlerin sayısına bağlı olabilir. Bu faktörlerin birçoğu uygulamaya, sisteme ve ortama özgü olabilir. Etkili bir izleme sistemi bu alt düzey faktörlere karşılık gelen kullanılabilirlik verilerini yakalar ve ardından bunları bir araya getirerek sistemin genel bir görüntüsünü çıkarır. Örneğin, bir e-ticaret sisteminde müşterinin sipariş vermesine olanak sağlayan işlevsellik, sipariş ayrıntılarının saklandığı depoya ve bu siparişlerin ödenmesine yönelik parasal işlemleri işleyen ödeme sistemine bağlı olabilir. Dolayısıyla sistemin sipariş verme bölümünün kullanılabilirliği deponun ve ödeme alt sisteminin kullanılabilirliğinin bir fonksiyonudur.

Kullanılabilirliği izleme gereksinimleri

Operatörün her sisteme ve alt sisteme ilişkin geçmiş kullanılabilirlik bilgilerini de görüntüleyebilmesi ve bu bilgileri kullanarak bir veya birden çok alt sistemin düzenli aralıklarla başarısız olmasına neden olabilecek eğilimleri saptayabilmesi gerekir. (Hizmetler günün yoğun işlem saatlerine denk gelen belirli bir zamanında mı başarısız olmaya başlıyor?)

Bir izleme çözümü, her alt sistemin kullanılabilir veya kullanılamaz olduğu durumların anlık ve geçmiş görünümünü sağlamalıdır. Ayrıca bir veya birden çok hizmet başarısız olduğunda veya kullanıcılar hizmetlere bağlanamadığında operatörü hızla uyarabilme özelliğine de sahip olmalıdır. Söz konusu olan yalnızca her hizmeti izlemek değildir; aynı zamanda kullanıcıların gerçekleştirdiği eylemleri, bu eylemlerin hizmetle iletişim kuramamaları durumunda incelemek de gerekir. Bağlantının başarısız olması bir noktaya kadar normaldir ve geçici hatalardan kaynaklanıyor olabilir. Ama sistemin, belirli bir süre boyunca belirli bir alt sisteme başarısız bağlanma denemelerinin sayısına ilişkin uyarı vermesini sağlamak da yararlı olabilir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Sistem durumu izlemesinde olduğu gibi, kullanılabilirliğin izlenmesinde de bu izlemeyi desteklemek için gereken ham veriler yapay kullanıcı izlemesi yoluyla ve oluşabilecek özel durumları, hataları ve uyarıları günlüğe kaydederek oluşturulabilir. Buna ek olarak, kullanılabilirlik verileri uç nokta izlemesi gerçekleştirerek de elde edilebilir. Uygulama bir veya birden çok sistem durumu uç noktasını ortaya çıkarır ve her biri sistemdeki işlevsel bir alana erişimi test eder. İzleme sistemi tanımlı bir zamanlamaya uygun olarak her uç noktaya ping yapabilir ve sonuçları (başarı veya başarısızlık) toplayabilir.

Tüm zaman aşımları, ağ bağlantısı hataları ve bağlantı yeniden deneme girişimleri kaydedilmelidir. Tüm veriler zaman damgasına alınmalıdır.

Kullanılabilirlik verilerinin analizi

Ölçümlü izleme verileri bir araya toplanmalı ve şu türlerdeki analizleri destekleyecek şekilde ilişkilendirilmelidir:

• Sistemlerin ve alt sistemlerin anlık kullanılabilirliği.
• Sistemlerin ve alt sistemlerin kullanılabilirliğinde hata oranları. İdeal olan, operatörün hataları belirli etkinliklerle ilişkilendirilebilmesidir: Sistem başarısızlığa uğradığında ne oluyordu?
• Belirli bir süre içinde sistemin veya alt sistemlerin hata oranlarının geçmiş görünümü ve sistemin hata oluştuğu sıradaki yükü (örneğin, kullanıcı isteklerinin sayısı).
• Sistemin veya alt sistemlerin kullanılabilir olmamasının nedenleri. Örneğin, nedenler hizmetin çalışmaması, bağlantı kaybı, bağlanmış ama zaman aşıma uğramış olma durumu ve bağlanmış ama hata döndürüyor olma durumu olabilir.

Belirli bir süre içinde hizmetin kullanılabilirlik yüzdesini hesaplamak için şu formülü kullanabilirsiniz:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Bu, SLA amaçları açısından yararlıdır. (SLA izleme, bu kılavuzun ilerleyen bölümlerinde daha ayrıntılı olarak açıklanmıştır.) Kapalı kalma süresinin tanımı hizmete bağlıdır. Örneğin, Visual Studio Team Services Derleme Hizmeti kapalı kalma süresini Derleme Hizmeti'nin kullanılamaz durumda olduğu süre (toplam dakika sayısı) olarak tanımlar. Müşteri tarafından başlatılan işlemleri gerçekleştirmek üzere Derleme Hizmeti’ne yapılan tüm sürekli HTTP isteklerinin bir dakika boyunca hata kodu ile sonuçlandığı veya bir yanıt döndürmediği durumlarda o dakikanın kullanılamaz olduğu kabul edilir.

Performansı izleme

Sistem giderek daha çok baskı altına alındıkça (kullanıcı hacmi artırılarak), bu kullanıcıların eriştiği veri kümelerin boyutu büyür ve bir veya birden çok bileşende hata oluşma olasılığı artar. Bileşen hatasından önce sıklıkla performans düşüşü yaşanır. Böyle bir düşüşü algılayabilirseniz, durumu düzeltmek için proaktif adımlar atabilirsiniz.

Sistem performansı bir dizi faktöre bağlıdır. Her faktör normal olarak, bir saniyede yapılan veritabanı işlemlerinin sayısı veya belirtilen zaman çerçevesinde başarıyla hizmet verilen ağ isteklerinin hacmi gibi ana performans göstergeleriyle (KPI) ölçülür. Bu KPI'lerden bazıları belirli performans ölçüleri olarak sağlanabilirken, diğerleri ölçümlerin bir bileşiminden türetilebilir.

Performans izleme gereksinimleri

Sistem performansını incelemek için, operatörün normalde şu bilgileri görmesi gerekir:

• Kullanıcı istekleri için yanıt hızları.
• Eş zamanlı kullanıcı isteklerinin sayısı.
• Ağ trafiğinin hacmi.
• Kurumsal işlemlerin tamamlanma hızları.
• İstekler için ortalama işlem süresi.

Operatöre ilişkileri saptamasına yardımcı olacak araçlar sağlamak da yararlı olabilir, örneğin:

• Eş zamanlı kullanıcı sayısıyla istek gecikme sürelerinin karşılaştırması (kullanıcı bir istek gönderdikten sonra isteğin işlenmeye başlaması ne kadar sürüyor).
• Eş zamanlı kullanıcı sayısıyla ortalama yanıt süresini karşılaştırma (bir isteğin işlenmeye başladıktan sonra tamamlanması ne kadar sürüyor).
• İstek hacmiyle işleme hatalarının sayısını karşılaştırma.

Bu üst düzey işlevsel bilgilerin yanı sıra, operatörün sistemdeki her bileşenle ilgili ayrıntılı performans görünümünü de alabilmesi gerekir. Bu veriler normalde aşağıdakiler gibi bilgileri izleyen alt düzey performans sayaçları aracılığıyla sağlanır:

• Bellek kullanımı.
• İş parçacığı sayısı.
• CPU işleme süresi.
• İstek kuyruğu uzunluğu.
• Disk veya ağ G/Ç oranları ve hataları.
• Yazılan veya okunan bayt sayısı.
• Kuyruk uzunluğu gibi ara yazılım göstergeleri.

Tüm görselleştirmelerde operatöre bir zaman aralığı belirtme olanağı tanınmalıdır. Görüntülenen veriler geçerli durumun anlık görüntüsü veya performansın geçmiş görünümü olabilir.

Operatörün belirli bir süre boyunca belirli bir değer için yapılan herhangi bir performans ölçümü temelinde uyarı oluşturabilmesi gerekir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Kullanıcıların sisteme ulaşan ve sistemden geçen isteklerinin ilerleme durumunu izleyerek üst düzey performans verileri (aktarım hızı, eş zamanlı kullanıcı sayısı, kurumsal işlem sayısı, hata oranları, vb.) toplayabilirsiniz. Bu işlem, uygulama kodundaki önemli noktalarda yer alan izleme deyimlerinin zamanlama bilgileriyle birlikte bir araya getirilmesini içerir. Tüm hatalar, özel durumlar ve uyarıların bunlara neden olan isteklerle ilişkilendirilebilmesi için, bunların yeterli veriyle yakalanması gerekir. Internet Information Services (IIS) günlüğü bir diğer yararlı kaynaktır.

Mümkünse, uygulamanın kullandığı tüm dış sistemler için de performans verilerini yakalamalısınız. Bu dış sistemler, kendi performans sayaçlarını veya performans verileri istemeye yönelik başka özellikler sağlıyor olabilir. Bu mümkün değilse, dış sisteme yapılan her isteğin başlangıç saati ve bitiş saati gibi bilgileri, ayrıca işlemin durumunu (başarı, başarısızlık veya uyarı) kaydedin. Örneğin, isteklerin zamanını belirlemek için kronometre yaklaşımı kullanabilirsiniz: İstek başlatıldığında süreölçeri başlatın ve istek sona erdiğinde süreölçeri durdurun.

Sistemdeki tek tek bileşenlerin alt düzey performans verileri, Windows performans sayaçları ve Azure Tanılama gibi özellikler ve hizmetler aracılığıyla sağlanabilir.

Performans verilerinin analizi

Analiz çalışmalarının çoğu, performans verilerinin kullanıcı isteği türüne veya her isteğin gönderildiği alt sisteme veya hizmete göre toplandığından oluşur. Bir e-ticaret sisteminde alışveriş sepetine öğe eklemek veya alışverişi bitirme işlemi yapmak birer kullanıcı isteği örneğidir.

Bir diğer yaygın gereksinim, performans verilerini seçilen yüzdelik dilimlerde özetlemektir. Örneğin, operatör isteklerin yüzde 99'u için, isteklerin yüzde 95'i için ve isteklerin yüzde 70'i için yanıt sürelerini saptayabilir. Her yüzdebirlik dilime ilişkin SLA hedefleri veya başka hedefler ayarlanmış olabilir. Anlık sorunları algılamaya yardımcı olmak için, devam eden sonuçlar neredeyse gerçek zamanlı olarak raporlanmalıdır. İstatistikleri tutmak amacıyla daha uzun bir sürenin sonuçları da toplanmalıdır.

Performansı etkileyen gecikme sorunlarıyla karşılaşıldığında, operatörün her istekte gerçekleştirilen her adımı inceleyerek performans sorununun nedenini hızla belirleyebilmesi gerekir. Dolayısıyla performans verileri, her adımın performans ölçümlerini ilişkilendirip bunları belirli bir isteğe bağlamak için bir yol sağlamalıdır.

Görselleştirme gereksinimlerine bağlı olarak, ham verilerin görünümlerini içeren bir veri küpü oluşturmak ve depolamak yararlı olabilir. Bu veri küpü performans verilerinin geçici olarak yapılacak karmaşık sorgulama ve analizine olanak tanıyabilir.

Güvenlik izleme

Hassas verilerin bulunduğu tüm ticari sistemlerin bir güvenlik yapısına sahip olması gerekir. Güvenlik mekanizmasının karmaşıklık düzeyi çoğunlukla verilerin hassaslık düzeyine göre belirlenir. Kullanıcıların kimlik doğrulaması yapmasını gerektiren bir sistemde şunların kaydını tutmalısınız:

• Tüm oturum açma girişimleri, bunların başarılı olup olmadığı.
• Kimliği doğrulanmış bir kullanıcı tarafından gerçekleştirilen tüm işlemler ve erişilen tüm kaynakların ayrıntıları.
• Kullanıcının ne zaman oturumu sona erdirdiği ve kapattığı.

İzleme, sisteme yapılan saldırıları algılamaya yardımcı olabilir. Örneğin, çok fazla sayıda oturum açma girişimi bir deneme yanılma saldırısına işaret ediyor olabilir. İsteklerdeki beklenmedik bir artış, bir dağıtılmış hizmet engelleme (DDoS) saldırısının sonucu olabilir. Nereden başlatılmış olursa olsun tüm kaynaklara yönelik istekleri izlemeye hazırlıklı olmalısınız. Oturum açma işleminde güvenlik açığı olan bir sistem kullanıcının gerçekten oturum açmasına gerek kalmadan kaynakları yanlışlıkla dış dünyanın kullanımına açabilir.

Güvenliği izleme gereksinimleri

Güvenlik izlemesinin en kritik yönleri operatörün şunları hızla yapabilmesini sağlamalıdır:

• Kimliği doğrulanmamış bir varlığın yetkisiz erişim denemelerini algılama.
• Varlıkların, kendilerine erişim verilmemiş veriler üzerinde işlem gerçekleştirme denemelerini belirleme.
• Sistemin veya bazı sistem bölümlerinin dışarıdan veya içeriden saldırı altında olup olmadığını saptama. (Örneğin, kimliği doğrulanmamış kötü niyetli bir kullanıcı sistemi kapatmaya çalışıyor olabilir.)

Bu gereksinimleri desteklemek için aşağıdaki durumlarda operatöre bildirim verilmelidir:

• Bir hesap, belirtilen süre içinde yinelenen başarısız oturum açma girişimleri yapar.
• Kimliği doğrulanmış bir hesap, belirtilen süre boyunca yasaklanmış bir kaynağa tekrar tekrar erişmeye çalışır.
• Belirtilen süre boyunca çok sayıda kimliği doğrulanmamış veya yetkisiz istek gerçekleşir.

Operatöre sağlanan bilgiler her isteğin kaynağının ana bilgisayar adresini içermelidir. Düzenli olarak belirli bir adres aralığından güvenlik ihlalleri yapılıyorsa, bu ana bilgisayarlar engellenebilir.

Normal düzenden sapmayı gösteren eylemlerin hızla algılanabilmesi, sistemin güvenliğini korumakta önemli bir rol oynar. Olağan dışı bir zamanda etkinlikte ani bir artış olup olmadığını algılamaya yardımcı olmak için başarısız veya başarılı oturum açma isteklerinin sayısı gibi bilgiler görsel olarak görüntülenebilir. (Bu etkinliğe örnek olarak, iş günü sabah 9:00'da başlayan kullanıcıların 3:00'da oturum açması ve çok fazla sayıda işlem gerçekleştirmesi verilebilir.) Bu bilgiler, zamana dayalı otomatik ölçeklendirmeyi yapılandırmaya yardımcı olmak için de kullanılabilir. Örneğin, operatör günün belirli bir saatinde çok fazla sayıda kullanıcının düzenli olarak oturum açtığını gözlemlerse, iş hacmini üstlenecek ek kimlik doğrulama hizmetlerinin başlatılmasını düzenleyebilir ve yoğunluk geçtikten sonra bu ek hizmetleri kapatabilir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Dağıtılmış sistemlerin çoğunda güvenlik sistemin her yönünü kapsar. Sistemin her yanındaki çeşitli noktalarda güvenlikle ilgili veriler oluşturulur. Uygulama, ağ donanımı, sunucu, güvenlik duvarı, virüsten koruma yazılımı ve diğer yetkisiz erişimi önleme öğeleri tarafından oluşturulan olaylardan elde edilen güvenlikle ilgili bilgileri toplamak için bir Güvenlik Bilgileri ve Olay Yönetimi (SIEM) yaklaşımı benimsemeyi göz önünde bulundurabilirsiniz.

Güvenlik izlemesi uygulamanızın parçası olmayan araçlardan gelen verileri bir araya getirebilir. Bu araçlar, kimlik doğrulaması yapmadan uygulamanıza ve verilerinize erişme denemelerini algılayan ağ filtrelerinin veya dış aracıların bağlantı noktası tarama etkinliklerini belirleyen hizmet programları içerebilir.

Her durumda, yönetici toplanan verilerden yararlanarak herhangi bir saldırının doğasını saptayabilmeli ve uygun önlemleri alabilmelidir.

Güvenlik verilerinin analizi

Güvenlik izlemesinin bir özelliği, verilerin alındığı kaynakların çeşitliliğidir. Farklı biçimler ve ayrıntı düzeyleri söz konusu olduğundan, yakalanan verilerin mantıklı bir bilgi dizisi halinde bir araya getirilmesi için çoğunlukla karmaşık bir analiz gerekir. En basit durumlar (çok fazla sayıda başarısız oturum açma denemesini veya kritik kaynaklara yetkisiz erişim kazanmaya yönelik yinelenen girişimleri algılama gibi) bir yana bırakılırsa, güvenlik verileri üzerinde karmaşık otomatik işlemler gerçekleştirmek mümkün olmayabilir. Bunun yerine, uzman el ile analize olanak sağlamak için bu verileri zaman damgalı ancak aksi halde özgün biçiminde güvenli bir depoya yazmak tercih edilebilir.

SLA izleme

Ücretli müşterileri destekleyen birçok ticari sistem, sistemin performansı hakkında SLA biçiminde garantiler verir. Temel olarak, SLA'lar sistemin üzerinde anlaşmaya varılmış bir zaman çerçevesinde ve kritik verilerde kayba neden olmadan tanımlı bir iş hacmini işleyebileceğini belirtir. SLA izleme, sistemin ölçülebilir SLA'lara uyum gösterip gösteremediğiyle ilgilidir.

SLA'ların tanımında genellikle şunlar kullanılır:

• Genel sistem kullanılabilirliği. Örneğin, bir kuruluş sistemin zamanın yüzde 99,9'unda kullanılabilir olacağını garanti edebilir. Bu garanti sistemin kapalı kalma süresinin yılda 9 saati veya haftada yaklaşık 10 dakikayı aşmaması anlamına gelir.
• İşlem aktarım hızı. Garantinin bu yönü genellikle bir veya birden çok üst sınır işaretiyle gösterilir. Örneğin, sistemin en çok 100.000 eş zamanlı kullanıcı isteğini destekleyeceği veya 10.000 eş zamanlı işlemi işleyeceği garanti edilebilir.
• İşlem yanıt süresi. Sistem kurumsal isteklerin işlenme hızıyla ilgili garantiler de verebilir. Örneğin, tüm kurumsal işlemlerin yüzde 99'unun 2 saniye içinde biteceği ve tek tek hiçbir işlemin 10 saniyeden uzun sürmeyeceği belirtilebilir.

SLA izleme gereksinimleri

En üst düzeyde, operatör sistemin üzerinde anlaşmaya varılan SLA'lara uyup uymadığını bir bakışta saptayabilmelidir. Uymuyorsa, operatör detaya gidebilmeli ve temel faktörleri inceleyerek standardın altına düşen performansın nedenlerini saptayabilmelidir.

Görsel olarak ortaya konabilecek tipik üst düzey göstergeler şunlardır:

• Hizmetin çalışır süresi yüzdesi.
• Uygulama aktarım hızı (başarılı işlemler veya saniye başına işlemler açısından ölçülür).
• Başarılı/başarısız uygulama isteklerinin sayısı.
• Uygulama ve sistem hataları, özel durumları ve uyarılarının sayısı.

Bu göstergelerin hepsi belirli bir zaman aralığına göre filtrelenebilmelidir.

Bir bulut uygulaması büyük olasılıkla bir dizi alt sistemden ve bileşenden oluşur. Operatör üst düzey göstergelerden birini seçip bunun nasıl temel öğelerin durumundan oluştuğunu görebilmelidir. Örneğin genel olarak sistemin çalışma süresi kabul edilebilir bir değerin altına düşerse, operatör duruma yakından bakabilmeli ve bu hataya katkıda bulunan öğeleri saptayabilmelidir.

Üst düzey göstergelerden herhangi biri belirlenen eşiği aşarsa, uyarı amacıyla sistem bir olay oluşturabilmelidir. Üst düzey göstergeyi oluşturan çeşitli faktörlerin daha alt düzey ayrıntıları, uyarı sistemine bağlamsal veriler olarak sağlanmalıdır.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

SLA izlemesini desteklemek için gereken ham veriler, performans izlemesi için gereken ham verilere, ayrıca bazı açılardan sistem durumu ve kullanılabilirlik izlemesine de benzer. (Daha fazla ayrıntı için bu bölümlere bakın.) Bu verileri şu şekilde yakalayabilirsiniz:

• Uç nokta izlemesi gerçekleştirerek.
• Özel durumları, hataları ve uyarıları günlüğe kaydetme.
• Kullanıcı isteklerinin yürütülmesini izleyerek.
• Sistemin kullandığın tüm üçüncü taraf hizmetlerinin durumunu izleyerek.
• Performans ölçümlerini ve sayaçlarını kullanarak.

Tüm verilerin zamanlanması ve zaman damgasının alınması gerekir.

SLA verilerinin analizi

Sistemin genel performansının görünümünü oluşturmak için izleme verileri bir araya toplanmalıdır. Temel alt sistemlerin performansının incelenebilmesi için toplanan verilerin detaya gitmeyi de desteklemesi gerekir. Örneğin, şunları yapabilmelisiniz:

• Belirli bir süre boyunca gelen kullanıcı isteklerinin toplam sayısını hesaplama ve bu isteklerde başarı ile başarısızlık oranını saptama.
• Kullanıcı isteklerinin yanıt sürelerini bir araya getirerek sistem yanıt sürelerinin genel görünümünü oluşturma.
• Kullanıcı isteklerinin ilerleme durumunu analiz ederek isteğin genel yanıt süresini bu istek dahilindeki tek tek çalışma öğelerinin yanıt sürelerine bölme.
• Belirli bir zaman aralığındaki çalışma süresinin yüzdesi olarak sistemin genel kullanılabilirliğini saptama.
• Sistemdeki tek tek bileşenlerin ve hizmetlerin kullanılabilirlik süresi yüzdesini analiz etme. Bu analiz üçüncü taraf hizmetlerinin oluşturduğu günlükleri ayrıştırmayı içerebilir.

Birçok ticari sistemin belirli bir süreye (normalde bir ay) ait, üzerinde anlaşmaya varılmış SLA'lara karşılık gelen gerçek performans rakamlarını bildirmesi gerekir. Bu süre boyunca SLA'lara uyulmamışsa, kredileri veya müşterilere yapılacak başka biçimlerdeki geri ödemeleri hesaplamak için bu bilgiler kullanılabilir. Hizmetin kullanılabilirliğini hesaplamak için, Kullanılabilirlik verilerinin analizi bölümünde açıklanan tekniği kullanabilirsiniz.

Bir kuruluş, dahili nedenlerle hizmetlerin başarısız olmasına neden olan olayların sayısını ve doğasını da izleyebilir. Bu sorunların nasıl hızla çözülebileceğini veya tamamen ortadan kaldırılabileceğini öğrenmek, kapalı kalma sürelerini azaltmaya ve SLA'lara uymaya yardımcı olacaktır.

Denetim

Uygulamanın doğasına bağlı olarak, kullanıcı işlemlerini denetleme ve tüm veri erişiminin kaydını tutma gereksinimlerini belirleyen yasal düzenlemeler olabilir. Denetim, müşterileri belirli isteklere bağlayan kanıtı sağlayabilir. İnkar edilmemesi, bir müşteri ile uygulama veya hizmet sorumlusu olan kuruluş arasında güvenin korunmasına yardımcı olmak için birçok e-iş sisteminde önemli bir faktördür.

Denetim gereksinimleri

Analistin kullanıcıların eylemlerini yeniden oluşturabilmesi için gerçekleştirdikleri işle ilgili işlemlerin sırasını izleyebilmesi gerekir. Bu yalnızca kayıtlar için gerekli olabileceği gibi, adli bir soruşturma için de gerekebilir.

Denetim bilgileri son derece hassastır. Büyük olasılıkla, gerçekleştirdikleri görevlerle birlikte sistemin kullanıcılarını da tanımlayan veriler içerir. Bu nedenle, denetim bilgileri büyük olasılıkla grafik işlemlerde detaya gitmeyi destekleyen etkileşimli bir sistem değil yalnızca güvenilen analistlerin kullanabileceği raporlar biçiminde olacaktır. Analistin bir dizi rapor oluşturabilmesi gerekir. Örneğin, raporlarda belirli bir zaman çerçevesinde gerçekleşen tüm kullanıcı etkinlikleri listelenebilir, tek tek kullanıcıların etkinlik kronolojisinin ayrıntıları yer alabilir ya da bir veya birden çok kaynak üzerinde gerçekleştirilen işlemlerin sırası listelenebilir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Denetim için birincil bilgi kaynakları şunlardan oluşabilir:

• Kullanıcı kimlik doğrulamasını yöneten güvenlik sistemi.
• Kullanıcı etkinliğini kaydeden izleme günlükleri.
• Tüm tanımlanabilen ve tanımlanamayan ağ isteklerinin izlendiği güvenlik günlükleri.

Denetim verilerinin biçimini ve bunların depolanma yöntemini, yasal düzenleme gereksinimleri yönlendirebilir. Örneğin, verileri herhangi bir şekilde temizlemek mümkün olmayabilir. (Özgün biçiminde kaydedilmelidir.) Üzerinde oynanmasını önlemek için deponun tutulduğu depoya erişim korunmalıdır.

Denetim verilerinin analizi

Analist ham verilerin tamamına, özgün biçimlerinde erişebilmelidir. Ortak denetim raporları oluşturma gereksiniminin dışında, bu verilerin analizinde kullanılan araçlar büyük olasılıkla özelleştirilmiştir ve sistemin dışında tutulur.

Kullanımı izleme

Kullanımı izleme işleminde uygulama özelliklerinin ve bileşenlerinin nasıl kullanıldığı izlenir. Operatör toplanan verileri kullanarak şunları yapabilir:

• Hangi özelliklerin yoğun kullanıldığını ve sistemdeki olası etkin noktaları saptayabilir. Yoğun trafiği olan öğeler işlevsel bölümlemeden veya işi daha eşit yaymak için çoğaltmadan bile yararlanabilir. Operatör bu bilgileri kullanarak hangi özelliklerin sık kullanılmadığından ve sistemin gelecek sürümlerinden birinde kullanım dışı bırakılmaya veya değiştirilmeye aday olduğundan emin olabilir.

• Sistemin normal kullanım koşullarında işletimsel olaylar hakkında bilgi alabilir. Örneğin, bir e-ticaret sitesinde işlem sayısı ve bunlardan sorumlu olan müşterilerin hacmiyle ilgili istatistiksel bilgileri kaydedebilirsiniz. Bu bilgiler, müşteri sayısı arttıkça kapasite planlaması yapmak için kullanılabilir.

• Sistemin performansı ve işlevselliğiyle ilgili müşteri memnuniyetini (büyük olasılıkla dolaylı olarak) saptayabilir. Örneğin, bir e-ticaret sisteminde çok sayıda müşteri düzenli olarak alışveriş sepetini bırakıyorsa, bu durum alışverişi sonuçlandırma işlevindeki bir sorundan kaynaklanıyor olabilir.

• Fatura bilgilerini oluşturabilir. Ticari bir uygulama veya çok kiracılı bir hizmet müşterilerini kullandıkları kaynaklara göre ücretlendiriyor olabilir.

• Kotaları zorunlu kılabilir. Çok kiracılı bir sistemde kullanıcı belirli bir süre içinde ücretli işlem süresi veya kaynak kullanımı kotasını aşarsa, erişimi sınırlandırılabilir veya işlem kısıtlanabilir.

Kullanım izleme gereksinimleri

Sistem kullanımını incelemek için, operatörün normalde şu bilgileri görmesi gerekir:

• Her alt sistem tarafından işlenen ve her kaynağa yönlendirilen isteklerin sayısı.
• Her kullanıcının gerçekleştirdiği çalışma.
• Her kullanıcının kapladığı veri depolama alanı.
• Her kullanıcının eriştiği kaynaklar.

Operatör graflar da oluşturabilmelidir. Örneğin, bir grafta en çok kaynak isteyen kullanıcılar ya da en sık erişilen kaynaklar veya sistem özellikleri gösterilebilir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Kullanım izlemesi görece yüksek bir düzeyde gerçekleştirilir. Her isteğin başlangıç ve bitiş zamanlarını ve isteğin doğasını (söz konusu kaynağa bağlı olarak okuma, yazma, vb.) kaydedebilir. Bu bilgileri şu şekilde elde edebilirsiniz:

• Kullanıcı etkinliğini izleyerek.
• Her kaynağın kullanımını ölçen performans sayaçlarını yakalayarak.
• Her kullanıcının kaynak tüketimini izleyerek.

Ölçüm amacıyla, hangi kullanıcıların hangi işlemleri gerçekleştirmekle sorumlu olduğunu ve bu işlemlerin kullandığı kaynakları da tanımlayabilmeniz gerekir. Doğru faturalama için, toplanan bilgiler yeterince ayrıntılı olmalıdır.

Sorun izleme

Sistemde beklenmedik olaylar veya davranışlarla karşılaşan müşteriler veya diğer kullanıcılar sorun bildirebilir. Sorun izleme işlemi bu sorunları yönetmekle, bunları sistemdeki temel sorun çözümü çalışmalarıyla ilişkilendirmekle ve olası çözümler konusunda müşterileri bilgilendirmekle ilgilidir.

Sorun izleme gereksinimleri

Operatörler sorun izlemesi gerçekleştirmek için genellikle kullanıcıların bildirdiği sorunların ayrıntılarını kaydetmelerine ve raporlamalarına olanak tanıyan ayrı bir sistem kullanır. Bu ayrıntılar kullanıcının gerçekleştirmeye çalıştığı görevlerden, sorunun belirtilerinden, olayların sırasından ve gönderilen hata veya uyarı iletilerinden oluşabilir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Sorun izleme verileri için ilk veri kaynağı, en başta sorunu bildiren kullanıcıdır. Kullanıcı aşağıdakiler gibi ek veriler sağlayabilir:

• Kilitlenme bilgi dökümü (uygulama kullanıcının masaüstünde çalıştırılan bir bileşen içeriyorsa).
• Ekran anlık görüntüsü.
• Hatanın oluştuğu tarih ve saat, ayrıca kullanıcının konumu gibi ortamla ilgili diğer bilgiler.

Bu bilgiler hata ayıklama çalışmalarına ve yazılımın gelecek sürümleri için kapsam oluşturmaya yardımcı olmak için kullanılabilir.

Sorun izleme verilerinin analizi

Farklı kullanıcılar aynı sorunu bildirebilir. Sorun izleme sistemi ortak raporları birbiriyle ilişkilendirmelidir.

Her sorun raporunda hata ayıklama çalışmasının ilerleme durumu kaydedilmelidir. Sorun çözüldüğünde, müşteri çözüm konusunda bilgilendirilebilir.

Kullanıcının bildirdiği sorunun sorun izleme sisteminde bilinen bir çözümü varsa, operatör kullanıcıyı çözüm hakkında hemen bilgilendirebilmelidir.

İşlemleri izleme ve yazılım sürümlerinde hataları ayıklama

Bir kullanıcı bir sorun bildirdiğinde, kullanıcı genellikle yalnızca işlemleri üzerindeki hemen etkisinin farkında olur. Kullanıcı, sistemin bakımından sorumlu olan operatöre sadece kendi deneyiminin sonuçlarını bildirebilir. Bu deneyimler ise çoğunlukla bir veya birden çok temel sorunun yalnızca görünür belirtileridir. Birçok durumda, sorunun kök nedenini belirlemek için analistin temeldeki işlemlerin kronolojisini sorgulaması gerekecektir. Bu işlem kök neden analizi olarak adlandırılır.

İzleme ve hata ayıklama gereksinimleri

Beklenmedik olayları ve diğer sorunları izlemek için, izleme verilerinin analistin bu sorunların kökenine dönmesine ve gerçekleşen olayların sırasını yeniden oluşturmasına olarak tanıyacak kadar bilgi sağlayabilmesi yaşamsal önem taşır. Bu bilgiler bir analistin tüm sorunların kök nedenini tanımlaması için yeterli olmalıdır. Bundan sonra bir geliştirici bu sorunların yeniden ortaya çıkmasını önlemek için gerekli değişiklikleri yapabilir.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleri

Sorun giderme, müşteri belirli bir istekte bulunduğunda sistemdeki mantıksal akışı çizen bir ağaç oluşturmak için işlemin parçası olarak çağrılan tüm yöntemlerin (ve parametrelerinin) izlenmesini içerebilir. Bu akışın sonucu olarak sistemin oluşturduğu özel durumlar ve uyarılar yakalanmalı ve günlüğe kaydedilmelidir.

Hata ayıklamayı desteklemek için sistem operatörün sistemin kritik noktalarında durumu yakalamasına olanak tanıyan kancalar sağlayabilir. Öte yandan, seçili işlemlerde devam ederken sistem adım adım ayrıntılı bilgiler de verebilir. Verilerin bu ayrıntı düzeyinde yakalanması sisteme ek yük getirebilir ve geçici bir işlem olmalıdır. Operatör, asıl olarak son derece alışılmamış ve yinelenmesi güç bir dizi olay gerçekleştiğinde veya sistemde yeni kullanıma sunulan bir veya birden çok öğenin dikkatle izlenip bunların beklendiği gibi çalıştığından emin olmak gerektiğinde bu işlemi kullanır.

İzleme ve tanılama işlem hattı

Büyük ölçekli bir dağıtılmış sistemin izlenmesi son derece zor olabilir. Önceki bölümde açıklanan senaryolardan her birinin yalıtılmış olarak ele alınması gerekmez. Büyük olasılıkla her durumda gereken izleme ve tanılama verilerinde ciddi bir çakışma olur; ama bu verilerin farklı yollarla işlenmesi ve sunulması gerekebilir. Bu nedenlerle, izleme ve tanılamaya bütüncül bir yaklaşım benimsemelisiniz.

İzleme ve tanılama işleminin tamamını Şekil 1'de gösterilen aşamalardan oluşmuş bir işlem hattı olarak gözünüzde canlandırabilirsiniz.

Şekil 1 - İzleme ve tanılama işlem hattındaki aşamalar.

Şekil 1'de izleme ve tanılamaya yönelik verilerin nasıl çeşitli veri kaynaklarından gelebildiği vurgulanmaktadır. Ölçümlü izleme ve toplama aşamaları verilerin hangi kaynaklardan yakalanması gerektiğini belirlemek, hangi verilerin yakalanacağını, nasıl yakalanacağını ve kolayca incelenebilmesi için bu verilerin nasıl biçimlendirileceğini saptamakla ilgilidir. Analiz/tanılama aşaması ham verileri alır ve bunları kullanarak bir operatörün sistemin durumunu saptamak için yararlanabileceği anlamlı bilgiler oluşturur. Operatör bu bilgileri gerçekleştirilecek olası eylemler hakkında karar vermek için kullanabilir ve ardından sonuçları yeniden ölçümlü izleme ve toplama aşamalarına sağlar. Görselleştirme/uyarı verme aşaması sistem durumunun kullanılabilir bir görünümünü sunar. Bir dizi panoyu kullanarak neredeyse gerçek zamanlı bilgiler görüntüleyebilir. Ayrıca verilerin, uzun vadeli eğilimleri belirlemeye yardımcı olabilecek bir geçmiş görünümünü sağlamak için raporlar, graflar ve grafikler oluşturabilir. Bilgiler bir KPI'nin kabul edilebilir sınırları aşma eğiliminde olduğunu gösterirse, bu aşama operatöre bir uyarı da tetikleyebilir. Bazı durumlarda, otomatik ölçeklendirme gibi düzeltici eylemler gerçekleştirmeyi deneyen otomatik bir süreci tetiklemek için de uyarı kullanılabilir.

Bu adımların sürekli akan bir süreç oluşturduğuna ve aşamaların paralel yürütüldüğüne dikkat edin. İdeal olan tüm aşamaların dinamik olarak yapılandırılabilir olmasıdır. Bazı noktalarda, özellikle de sistemin yeni dağıtıldığı ve sorunlarla karşılaştığı durumlarda, daha sık olarak daha kapsamlı veriler toplamak gerekebilir. Bunun dışındaki zamanlarda, sistemin düzgün çalıştığını doğrulamak için temel düzeyde gerekli verileri yakalama uygulamasına dönmek mümkündür.

Ayrıca, izleme işleminin tamamı canlı, devam eden ve geri bildirimlere bağlı olarak ince ayarlamalar ve geliştirmeler yapılan bir çözüm olarak değerlendirilmelidir. Örneğin, sistem durumunu saptamak için birçok faktörün ölçümünü almakla işe başlayabilirsiniz. Zaman içinde siz konuyla ilgili olmayan ölçümleri attıkça analizde kapsam daraltılabilir ve arka plan gürültüsünü en aza indirip ihtiyacınız olan verilere daha net odaklanmanıza olanak tanınabilir.

İzleme ve tanılama verilerinin kaynakları

İzleme işleminin kullandığı bilgiler Şekil 1'de gösterildiği gibi çeşitli kaynaklardan gelebilir. Uygulama düzeyinde, bilgiler sistem kodunun içine eklenmiş izleme günlüklerinden gelir. Geliştiriciler kodlarında denetim akışını izlerken standart bir yaklaşım benimsemelidir. Örneğin bir yönteme yapılacak giriş, yöntemin adını, geçerli zamanı, her parametrenin değerini ve diğer ilgili bilgileri belirten bir izleme iletisi gönderebilir. Giriş ve çıkış zamanlarının kaydedilmesi de yararlı olabilir.

Tüm özel durumları ve uyarıları günlüğe kaydetmeli ve iç içe yerleştirilmiş özel durumların ve uyarıların tümünün tam izlemesini tuttuğunuzdan emin olmalısınız. İdeal olan, kodu çalıştıran kullanıcıyı tanımlayan bilgileri, etkinlik ilişkilendirme bilgileriyle birlikte (istekleri sistemden geçerken izlemek için) yakalamanızdır. Ayrıca, ileti kuyrukları, veritabanları, dosyalar ve diğer bağımlı hizmetler gibi tüm kaynaklara erişim girişimlerini de günlüğe kaydetmelisiniz. Bu bilgiler ölçüm ve denetim amaçlarıyla kullanılabilir.

Birçok uygulama, veri deposuna erişme veya ağ üzerinden iletişim kurma gibi yaygın görevleri gerçekleştirmek için kitaplıkları ve çerçeveleri kullanır. Bu çerçeveler kendi izleme iletilerini ve ham tanılama bilgilerini (örneğin işlem hızları ve başarılı/başarısız veri iletimleri) sağlayacak şekilde yapılandırılabilme özelliğine sahip olabilir.

Uygulamanın çalıştırıldığı işletim sistemi I/O hızları, bellek kullanımı ve CPU kullanımını gösteren performans sayaçları gibi sistem geneline ilişkin alt düzey bilgilerin alındığı bir kaynak olabilir. İşletim sistemi hataları (örneğin bir dosyanın düzgün açılamaması) da raporlanabilir.

Ayrıca sisteminizin üzerinde çalıştığı temel altyapıyı ve bileşenleri de dikkate almalısınız. Sanal makineler, sanal ağlar ve depolama hizmetlerinin hepsi altyapı düzeyinde önemli performans sayaçları ve diğer tanılama verilerinin kaynağı olabilir.

Uygulamanızda web sunucusu veya veritabanı yönetim sistemi gibi başka dış hizmetler kullanılıyorsa, bu hizmetler kendi izleme bilgilerini, günlüklerini ve performans sayaçlarını yayımlıyor olabilir. SQL Server veritabanında gerçekleştirilen izleme işlemleri için SQL Server Dinamik Yönetim Görünümleri ve web sunucusuna yönelik istekleri kaydetmek için ISS izleme günlükleri buna örnek verilebilir.

Sistemin bileşenleri değiştikçe ve yeni sürümler dağıtıldıkça, sorunların, olayların ve ölçümlerin hangi sürümle bağlantılı olduğunu belirlemek önemlidir. Bir bileşenin belirli bir sürümüyle ilişkili sorunların hızla izlenmesi ve düzeltilmesi için, bu bilgilerin geriye, yayın işlem hattında bağlanması gerekir.

Güvenlik sorunları sistemin herhangi bir noktasında oluşabilir. Örneğin, bir kullanıcı geçersiz kullanıcı kimliği veya parolayla oturum açmaya çalışabilir. Kimliği doğrulanmış bir kullanıcı bir kaynağa yetkisiz erişim elde etmeyi deneyebilir. Bir kullanıcı şifrelenmiş bilgilere erişmek için geçersiz veya eski bir anahtar sağlayabilir. Başarılı ve başarısız isteklerin güvenlikle ilgili bilgileri her zaman günlüğe kaydedilmelidir.

Uygulamada ölçümlü izleme yapma bölümü yakalamanız gereken bilgilerle ilgili daha fazla rehberlik sağlar. Ama bu bilgileri toplamak için çeşitli stratejiler kullanabilirsiniz:

• Uygulama/sistem izleme. Bu stratejide uygulamanın, uygulama çerçevelerinin, işletim sisteminin ve altyapının içinde bulunan dahili kaynaklar kullanılır. İstemci isteğinin yaşam döngüsü boyunca dikkate değer noktalarda uygulama kodu kendi izleme verilerini oluşturabilir. Uygulama, koşulların gerektirdiği şekilde seçmeli olarak etkinleştirilebilen veya devre dışı bırakılabilen izleme deyimleri içerebilir. Ayrıca bir tanılama çerçevesi kullanıp tanılamayı dinamik olarak eklemek de mümkün olabilir. Bu çerçeveler normalde kodunuzdaki çeşitli ölçümlü izleme noktalarına ekleyebildiği ve bu noktalarda izleme verilerini yakalayan eklentiler sağlar.

  Ayrıca kodunuz veya temel alınan altyapı kritik noktalarda olaylar oluşturabilir. Bu olayları dinleyecek şekilde yapılandırılan izleme aracıları olay bilgilerini kaydedebilir.

• Gerçek kullanıcı izleme. Bu yaklaşım kullanıcıyla uygulama arasındaki etkileşimleri kaydeder ve her istekle yanıtın akışını gözlemler. Bu bilgilerin iki amacı olabilir: her kullanıcı tarafından ölçüm kullanımına yönelik olarak kullanılabilir ve kullanıcıların uygun kalitede hizmet (örneğin, hızlı yanıt süresi, düşük gecikme süresi ve minimum hata) alıp almadıklarını saptamak için kullanılabilir. Yakalanan verileri kullanarak en sık hata oluşan sorunlu alanları tanımlayabilirsiniz. Ayrıca, uygulamadaki etkin noktalardan veya başka herhangi bir performans sorunundan dolayı sistemin yavaşladığı öğeleri tanımlamak için de verileri kullanabilirsiniz. Bu yaklaşımı özenle uygularsanız, hata ayıklama ve test amacıyla uygulama içinde kullanıcı akışlarını yeniden oluşturmanız mümkün olabilir.

  Önemli

  Gerçek kullanıcıların izlenmesiyle yakalanan verilerin son derece hassas olduğunu çünkü gizli malzemeler içerebileceğini dikkate almalısınız. Yakalanan verileri kaydederseniz, güvenli bir şekilde saklayın. Verileri performans izleme veya hata ayıklama amacıyla kullanmak istiyorsanız, önce tüm kişisel verileri çıkarın.

• Yapay kullanıcı izleme. Bu yaklaşımda, bir kullanıcının benzetimini yaparak kendi test istemcinizi yazar ve yapılandırılabilir ama tipik bir işlem serisi gerçekleştirirsiniz. Sistemin durumunu saptamak için test istemcisinin performansını izleyebilirsiniz. Ayrıca, sistemin baskı altında nasıl yanıt verdiğini ve bu koşullarda ne tür bir izleme çıkışı oluşturulduğunu belirlemek için yapılan bir yük testi işlemi kapsamında test istemcisinin birden çok örneğini de kullanabilirsiniz.

  Not

  Yöntem çağrılarının ve uygulamanın diğer kritik parçalarının yürütülmesini izleyen ve zamanını belirleyen kodu ekleyerek gerçek veya yapay kullanıcı izlemesi gerçekleştirebilirsiniz.

• Profil oluşturma. Bu yaklaşımın birincil hedefi uygulama performansını izlemek ve geliştirmektir. Gerçek ve yapay kullanıcı izlemenin işlevsel düzeyinde çalışmak yerine, uygulamanın çalıştırılması sırasında alt düzey bilgileri yakalar. Uygulamanın yürütme durumdan düzenli aralıklarla yapılan örneklemeyi kullanarak (belirli bir anda uygulamanın hangi kod parçasını çalıştırdığını saptayarak) profil oluşturabilirsiniz. Ayrıca önemli kavşaklarda (bir yöntem çağrısının başlangıcı ve bitişi gibi) koda yoklamalar ekleyen ölçümlü izlemeyi de kullanabilir ve hangi yöntemin ne zaman çağrıldığını, her çağrının ne kadar sürdüğünü kaydedebilirsiniz. Ardından bu verileri analiz ederek uygulamanın hangi parçalarının performans sorunlarına yol açabileceğini saptayabilirsiniz.

• Uç nokta izleme. Bu teknikte uygulamanın özellikle izleme için açığa çıkardığı bir veya birden çok tanılama uç noktası kullanılır. Uç nokta uygulama kodunda bir yol sağlar ve sistemin durumu hakkındaki bilgileri döndürebilir. Farklı uç noktalar işlevin farklı yönlerine odaklanabilir. Bu uç noktalara düzenli aralıklarla istekler gönderen ve yanıtları toparlayan kendi tanılama istemcinizi yazabilirsiniz. Daha fazla bilgi için bkz . Sistem Durumu Uç Noktası İzleme düzeni.

En geniş kapsamı elde etmek için, bu tekniklerin bir bileşimini kullanmalısınız.

Uygulamada ölçümlü izleme yapma

İzleme işleminin kritik parçalarından biri de ölçümlü izlemedir. Sistemin performansı ve durumu hakkında anlamlı kararlar verebilmek için, önce bu kararları vermenizi sağlayacak verileri yakalamalısınız. Ölçümlü izleme kullanarak topladığınız bilgiler, el ile izleme (ve hata ayıklama) yapmak için uzak bir üretim sunucusunda oturum açmanıza gerek kalmadan performansı değerlendirmeniz, sorunları tanılamanız ve kararlar vermeniz için yeterli olmalıdır. Ölçümlü izleme verileri normalde izleme günlüklerine yazılan ölçümler ve bilgilerden oluşur.

İzleme günlüğünün içeriği, uygulama tarafından yazılan metin verilerinin veya uygulama Windows için Olay İzleme (ETW) kullanıyorsa izleme olayının sonucu olarak oluşturulan ikili verilerin sonucu olabilir. Bunlar altyapının parçalarından, örneğin bir web sunucusundan ortaya çıkan olayların kaydedildiği sistem günlüklerinden de üretilebilir. Metin biçimindeki günlük iletileri çoğunlukla insanlar tarafından okunabilecek şekilde tasarlanır, ama bunların aynı zamanda otomatik bir sistemin kolayca ayrıştırabileceği biçimde yazılmış olması gerekir.

Günlükleri kategorilere ayırmalısınız. Tüm izleme verilerini tek bir günlüğe yazmayın; sistemin farklı işletim alanlarından gelen izleme çıkışını kaydetmek için ayrı günlükler kullanın. Bundan sonra tek bir büyük dosyayı işlemek zorunda kalmadan uygun günlükten okuyarak günlük iletilerini hızla filtreleyebilirsiniz. Farklı güvenlik gereksinimleri olan bilgileri (denetim bilgileri ile hata ayıklama verileri gibi) hiçbir zaman aynı günlüğe yazmayın.

Ölçümler genellikle belirli bir zamanda sistemdeki bir alanın veya kaynağın ölçüsü veya sayısı olacak, bir veya birden çok ilişkili etiket veya boyut (bazen örnek olarak adlandırılır) içerecektir. Çoğunlukla ölçümün tek bir örneği yalıtılmış olarak yararlı olmaz. Zaman içinde değişen ölçümlerin yakalanması gerekir. Dikkate alınması gereken en önemli konu hangi ölçümleri ne sıklıkta kaydetmeniz gerektiğidir. Ölçümleri için veri oluşturmak büyük çoğunlukla sisteme önemli bir ek yük getirebilirken, ölçümlerin fazla seyrek yakalanması da önemli bir olaya yol açan koşulları kaçırmanıza neden olabilir. Dikkate alınacak noktalar her ölçümde değişiklik gösterir. Örneğin, sunucudaki CPU kullanımı bir saniyeden diğerine ciddi ölçüde değişiklik gösterebilir, ama yüksek kullanım birkaç dakika boyunca durmadan sürüyorsa bir sorun haline gelir.

Verileri ilişkilendirmek için gereken bilgiler

Tek tek sistem düzeyi performans sayaçlarını kolayca izleyebilir, kaynakların ölçümlerini yakalayabilir ve çeşitli günlük dosyalarından uygulama izleme bilgilerini alabilirsiniz. Ama bazı izleme biçimlerinde, çeşitli kaynaklardan alınan verileri ilişkilendirmek için izleme işlem hattında analiz ve tanılama aşaması gereklidir. Bu veriler ham verilerde çeşitli biçimlerde olabilir ve bu farklı biçimlerin eşlenebilmesi için analiz işlemine yeterli ölçümlü izleme verisi sağlanmalıdır. Örneğin uygulama çerçevesi düzeyinde, bir görev iş parçacığı kimliğiyle tanımlanabilir. Uygulamanın içinde, aynı çalışma bu görevi gerçekleştiren kullanıcının kullanıcı kimliğiyle ilişkilendirilmiş olabilir.

Aynı zamanda, iş parçacıklarıyla kullanıcı istekleri arasında bire bir eşleme olma olasılığı pek yüksek değildir, çünkü zaman uyumsuz işlemler birden çok kullanıcı adına işlem gerçekleştirirken aynı iş parçacıklarını yeniden kullanabilir. İşleri daha da karmaşık hale getirmek için, tek bir istek sistemdeki yürütme akışları şeklinde birden çok iş parçacığı tarafından işleniyor da olabilir. Mümkünse, her isteği istek bağlamının bir parçası olarak sistem geneline yayılan benzersiz bir etkinlik kimliğiyle ilişkilendirin. (Etkinlik kimliklerini oluşturma ve izleme bilgilerine ekleme tekniği, izleme verilerini yakalarken kullanılan teknolojiye bağlıdır.)

Tüm izleme verileri aynı şekilde zaman damgasına alınmalıdır. Tutarlılık sağlamak için, tüm tarihleri ve saatleri Eşgüdümlü Evrensel Saat kullanarak kaydedin. Bu, olayların sırasına daha kolay izlemenize yardımcı olacaktır.

Ölçümlü izleme verilerine dahil edilecek bilgiler

Hangi ölçümlü izleme verilerini toplamanız gerektiğine karar verirken aşağıdaki noktaları dikkate alın:

• İzleme olayları tarafından yakalanan bilgilerin makine ve insan tarafından okunabilir olduğundan emin olun. Sistemler arasında günlük verilerinin otomatik olarak işlenmesini kolaylaştırmak ve günlükleri okuyan operasyon ve mühendislik personeline tutarlılık sağlamak için, bu bilgilerde iyi tanımlanmış şemalar benimseyin. Dağıtım ortamı, işlemin üzerinde çalıştırıldığı makine, işlem ayrıntıları ve çağrı yığını gibi ortam bilgilerini de ekleyin.

• Profil oluşturma sisteme ciddi bir ek yük getirebileceğinden profil oluşturmayı yalnızca gerektiğinde etkinleştirin. Ölçümlü izleme verilerini kullanarak profil oluşturma bir olayı (örneğin bir yöntem çağrısını) her gerçekleştiğinde kaydederken, örnekleme yalnızca seçili olayları kaydeder. Seçim zaman tabanlı (n saniyede bir) veya sıklık tabanlı (her n istekte bir kez) olabilir. Olaylar çok sık gerçekleşiyorsa, ölçümlü izlemeyle profil oluşturma çok fazla yüke neden olabilir ve genel olarak performansı bu işlemin kendisi etkileyebilir. Böyle bir durumda, örnekleme yaklaşımı tercih edilebilir. Öte yandan, olayların sıklığı düşükse örneklemeyle bu olaylar kaçırılabilir. Böyle bir durumda, ölçümlü izleme daha iyi bir yaklaşım olabilir.

• Geliştiricinin veya yöneticinin her isteğin kaynağını saptayabilmesi için yeterli bağlam sağlayın. İsteğin belirli bir örneğini tanımlayan bir tür etkinlik kimliği ekleyebilirsiniz. Bu etkinliği gerçekleştirilen hesaplama çalışması ve kullanılan kaynaklarla ilişkilendirmek için kullanılabilecek bilgiler de eklenebilir. Bu çalışmanın birden çok işlem ve makineye yayılabileceğini aklınızda bulundurun. Ölçüm amacıyla, bağlam (doğrudan veya ilişkilendirilmiş bilgiler yoluyla dolaylı olarak) isteğin yapılmasına neden olan müşteriye de bir başvuru içermelidir. Bu bağlam, izleme verilerinin yakalandığı sırada uygulamanın durumu hakkında değerli bilgiler sağlar.

• Tüm istekleri ve bu isteklerin yapıldığı konumları ve bölgeleri kaydedin. Bu bilgiler konuma özgü etkin noktalar olup olmadığını saptamaya yardımcı olabilir. Bu bilgiler uygulamanın veya onun kullandığı verilerin yeniden bölümlenip bölümlenmeyeceğini saptama açısından da yararlı olabilir.

• Özel durumların ayrıntılarını dikkatle kaydedin ve yakalayın. Özel durumların kötü işlenmesinin sonucu olarak sıklıkla kritik hata ayıklama bilgileri kaybolur. Uygulamanın oluşturduğu özel durumların tüm ayrıntılarını, tüm iç özel durumlar ve diğer bağlam bilgileriyle birlikte yakalayın. Mümkünse çağrı yığınını da ekleyin.

• Uygulamanızın farklı öğelerinin yakaladığı verilerde tutarlılığı koruyun, çünkü olayları incelerken ve bunları kullanıcı istekleriyle ilişkilendirirken yararlı olabilir. Sistemin farklı parçalarını oluştururken geliştiricilerin aynı yaklaşımı benimsemesine bağımlı kalmak yerine, bilgi toplamak için kapsamlı ve yapılandırılabilir bir günlük paketi kullanmayı göz önünde bulundurun. Gerçekleştirilen G/Ç hacmi, ağ kullanımı, istek sayısı, bellek kullanımı ve CPU kullanımı gibi ana performans sayaçlarından veri toplayın. Bazı altyapı hizmetleri veritabanına yönelik bağlantıların sayısı, işlemlerin gerçekleştirilme hızı ve başarılı veya başarısız olan işlem sayısı gibi kendi özel performans sayaçlarını sağlayabilir. Uygulamalar da kendi özel performans sayaçlarını tanımlayabilir.

• Veritabanı sistemleri, web hizmetleri veya altyapının parçası olan diğer sistem düzeyi hizmetler gibi dış hizmetlere yapılan tüm çağrıları günlüğe kaydedin. Her çağrıyı gerçekleştirmenin ne kadar sürdüğü ve çağrının başarısı veya başarısızlığı hakkındaki bilgileri kaydedin. Mümkünse, oluşan geçici hatalar için tüm yeniden deneme girişimleri ve başarısızlıklar hakkındaki bilgileri yakalayın.

Telemetri sistemleriyle uyumluluğu sağlama

Birçok durumda, ölçümlü izlemenin ürettiği bilgiler bir dizi olay olarak oluşturulur, sonra da işleme ve analiz için ayrı bir telemetri sistemine geçirilir. Normalde telemetri sistemi belirli herhangi bir uygulama veya teknolojiden bağımsızdır ama bilgilerin çoğunlukla bir şema tarafından tanımlanan belirli bir biçime uymasını bekler. Şema etkili bir şekilde, telemetri sisteminin alabileceği veri alanlarıyla türlerini tanımlayan bir anlaşma belirtir. Bir dizi platform ve cihazdan veri gelmesine izin vermek için şema genelleştirilmelidir.

Yaygın bir şema tüm ölçümlü izleme olaylarında ortak olan olay adı, olay saati, gönderenin IP adresi ve diğer olaylarla ilişkilendirmek için gereken ayrıntılar (örneğin kullanıcı kimliği, cihaz kimliği ve uygulama kimliği) gibi alanları içermelidir. Çok sayıda cihazın olayları oluşturabileceğini, dolayısıyla şemanın cihaz türüne bağımlı olmaması gerektiğini unutmayın. Buna ek olarak çeşitli cihazlar aynı uygulama için olay oluşturabilir; uygulama dolaşımı veya başka bir biçimde cihazlar arası dağıtımı destekliyor olabilir.

Şema ayrıca farklı uygulamalar arasında yaygın olan belirli bir senaryoya uygun etki alanına ilişkin alanlar da içerebilir. Bu, özel durumlar, uygulama başlangıç ve bitiş olayları ve web hizmeti API çağrılarının başarısı veya başarısızlığı hakkında bilgi olabilir. Etki alanının aynı alan kümesini kullanan tüm uygulamalar aynı olay kümesini yaymalı, böylelikle ortak bir rapor ve analiz kümesinin oluşturulmasına olanak tanımalıdır.

Son olarak, şema uygulamaya özgü olayların ayrıntılarını yakalamak için özel alanlar içerebilir.

Uygulamalarda ölçümlü izleme için en iyi yöntemler

Aşağıdaki listede, bulutta çalıştırılan dağıtılmış bir uygulamada ölçümlü izleme için en iyi yöntemler özetlenmiştir.

• Günlüklerin kolay okunur ve kolay ayrıştırılır olmasını sağlayın. Mümkün olduğunca yapılandırılmış günlük kullanın. Günlük iletilerinin kısa ve açıklayıcı olmasına dikkat edin.

• Tüm günlüklerde, günlük kayıtları yazılırken kaynağı tanımlayın, bağlam ve zamanlama bilgilerini sağlayın.

• Tüm zaman damgaları için aynı saat dilimini ve biçimi kullanın. Bu, farklı coğrafi bölgelerde çalıştırılan donanım ve hizmetlere yayılmış işlemlerin olaylarını ilişkilendirmeye yardımcı olur.

• Günlükleri kategorilere ayırın ve iletileri uygun günlük dosyasına yazın.

• Sistem hakkındaki hassas bilgileri veya kullanıcılar hakkındaki kişisel bilgileri açıklamayın. Günlüğe kaydedilmeden önce bu bilgileri temizleyin ama ilgili ayrıntıların korunduğundan emin olun. Örneğin, tüm veritabanı bağlantı dizelerinden kimlik ve parolayı kaldırın ama analistin sistemin doğru veritabanına eriştiğini belirleyebilmesi için bağlantı dizesindeki kalan bilgileri günlüğe yazın. Tüm kritik özel durumları günlüğe kaydedin ama yöneticinin daha alt düzeylerdeki özel durumlar ve uyarılar için günlüğü etkinleştirmesine ve devre dışı bırakmasına olanak tanıyın. Ayrıca, tüm yeniden deneme mantığı bilgilerini yakalayın ve günlüğe kaydedin. Bu veriler sistemin geçici durumunu izlemek için yararlı olabilir.

• Dış veri hizmetlerine veya veritabanlarına yönelik istekler gibi işlem çağrılarını izleyin.

• Aynı günlük dosyasında günlük iletilerini diğer güvenlik gereksinimleriyle karıştırmayın. Örneğin, hata ayıklama ve denetim bilgilerini aynı günlüğe yazmayın.

• Denetleme olayları haricinde, tüm günlük çağrılarının işle ilgili işlemlerin ilerlemesini engellemeyen, kendi kendine çalışan işlemler olduğundan emin olun. Denetleme olayları özel durumlardır çünkü bunlar iş açısından kritiktir ve işle ilgili işlemlerin temel bir parçası olarak sınıflandırılabilir.

• Günlüğün genişletilebilir olduğundan ve doğrudan somut bir hedefe hiçbir bağımlılığı olmadığından emin olun. Örneğin, bilgileri System.Diagnostics.Trace kullanarak yazmak yerine, günlük yöntemlerini gösteren ve uygun herhangi bir yolla gerçekleştirilebilen soyut bir arabirim (ILogger gibi) tanımlayın.

• Tüm günlüğün hataya dayanıklı olduğundan ve hiçbir zaman basamaklı hataları tetiklemeyeceğinden emin olun. Günlük hiçbir özel durum oluşturmamalıdır.

• Ölçümlü izlemeyi sürekli yinelenen bir işlem olarak ele alın ve günlükleri yalnızca bir sorun olduğunda değil düzenli aralıklarla gözden geçirin.

Verileri toplama ve depolama

İzleme işleminin toplama aşaması ölçümlü izlemenin oluşturduğu bilgileri almak, bu verileri analiz/tanılama aşamasında daha kolay kullanılabilecek şekilde biçimlendirmek ve dönüştürülen verileri güvenilir bir depolama alanına kaydetmekle ilgilidir. Dağıtılmış bir sistemin farklı parçalarından topladığınız ölçümlü izleme verileri çeşitli konumlarda ve çeşitli biçimlerde tutulabilir. Örneğin, uygulama kodunuz izleme günlüğü dosyaları ve uygulama olay günlüğü verileri oluşturabilirken, uygulamanızın kullandığı altyapının önemli yönlerini izleyen performans sayaçları başka teknolojiler aracılığıyla yakalanabilir. Uygulamanızın kullandığı tüm üçüncü taraf bileşenleri ve hizmetleri ayrı izleme dosyaları, blob depolama, hatta özel bir veri deposu kullanıp ölçümlü izleme bilgilerini farklı biçimlerde sağlıyor olabilir.

Veri toplama işlemi çoğunlukla ölçülü izleme verilerini oluşturan uygulamadan ayrı, otonom olarak çalışabilen bir toplama hizmeti tarafından gerçekleştirilir. Şekil 2'de bu mimarinin bir örneği gösterilmektedir ve ölçümlü izleme verilerini toplama alt sistemi vurgulanmıştır.

Şekil 2 - İzleme verilerini toplama.

Bunun basitleştirilmiş bir görünüm olduğuna dikkat edin. Toplama hizmetinin tek bir işlem olması gerekmez ve aşağıdaki bölümlerde açıklandığı gibi farklı makinelerde çalıştırılan birçok bileşen parçasından oluşuyor olabilir. Ayrıca, bazı telemetri verilerinin hızla analiz edilmesi gerekiyorsa (bu belgenin devamındaki Hızlı, orta gecikmeli ve gecikmeli analizi destekleme bölümünde açıklanan hızlı analiz), toplama hizmetinin dışında çalışan yerel bileşenler analiz görevlerini hemen gerçekleştirebilir. Şekil 2'de seçili olaylar için bu durum gösterilmiştir. Analiz işleminden sonra, sonuçlar doğrudan görselleştirme ve uyarı alt sistemine gönderilebilir. Orta gecikmeli veya gecikmeli analize bağlı olan veriler, işlenmeyi beklerken depolama alanında tutulur.

Azure uygulamaları ve hizmetlerinde, Azure Tanılama verileri yakalamayı mümkün kılan bir çözüm sağlar. Azure Tanılama her işlem düğümü için verileri aşağıdaki kaynaklardan toplar, bir araya getirir ve ardından Azure Depolama'ya yükler:

• IIS günlükleri
• IIS Başarısız İstek günlükleri
• Windows olay günlükleri
• Performans sayaçları
• Kilitlenme bilgi dökümleri
• Azure Tanılama altyapısı günlükleri
• Özel hata günlükleri
• .NET EventSource
• Bildirim tabanlı ETW

Daha fazla bilgi için Azure: Telemetri Temel Bilgileri ve Sorun Giderme makalesine bakın.

Ölçümlü izleme verilerini toplama stratejileri

Bulutun esnek yapısını dikkate alarak ve sistemdeki her düğümden telemetri verilerini el ile alma gereksiniminden kaçınmak için, verilerin merkezi bir konuma aktarılması ve birleştirilmesi işlemini ayarlamalısınız. Birden çok veri merkezine yayılan bir sistemde, önce verileri bölge temelinde toplamak, birleştirmek ve depolamak, sonra da bölgesel verileri tek bir merkezi sistemde bir araya getirmek yararlı olabilir.

Bant genişliği kullanımını iyileştirmek için, daha az acil verileri öbekler halinde, toplu olarak aktarmayı seçebilirsiniz. Öte yandan veriler, özellikle de zamana duyarlı bilgiler içeriyorsa, süresiz olarak geciktirilmemelidir.

Ölçümlü izleme verilerini çekme ve gönderme

Ölçümlü izleme verilerini toplama alt sistemi, uygulamanın her örneği için ölçümlü izleme verilerini çeşitli günlüklerden ve başka kaynaklardan etkin olarak alabilir (çekme modeli). Öte yandan, uygulamanın örneklerini oluşturan bileşenlerden verilerin gönderilmesini bekleyen pasif bir alıcı gibi de davranabilir (gönderme modeli).

Çekme modelini uygulamaya yönelik bir yaklaşım, uygulamanın her örneğiyle birlikte yerel olarak çalıştırılan izleme aracılarını kullanmaktır. İzleme aracısı yerel düğümde toplanan telemetri verilerini düzenli aralıklarla alan (çeken) ayrı bir işlemdir ve bu bilgileri doğrudan uygulamanın tüm örnekleri tarafından paylaşılan merkezi depolamaya yazar. Azure Tanılama'nın uyguladığı mekanizma budur. Azure web veya çalışan rolünün her örneği, yerel olarak depolanmış tanılama ve diğer izleme bilgilerini yakalayacak şekilde yapılandırılabilir. Örneklerin yanı sıra çalıştırılan izleme aracısı, belirtilen verileri Azure Depolama'ya kopyalar. Azure Cloud Services'te ve Sanal Makineler'de Tanılamayı Etkinleştirme makalesinde bu işlemle ilgili daha fazla ayrıntı sağlanmıştır. IIS günlükleri, kilitlenme bilgi dökümleri ve özel hata iletileri gibi bazı öğeler blob depolamaya yazılır. Windows olay günlüğü, ETW olayları ve performans sayaçlarından gelen veriler tablo depolamaya kaydedilir. Şekil 3'te bu mekanizma gösterilir.

Şekil 3 - Bilgileri çekmek ve paylaşılan depolama alanına yazmak için izleme aracısı kullanma.

Aynı konumdaki sınırlı sayıda düğüm üzerinde çalıştırılan küçük ölçekli bir uygulamanın telemetri verilerini depolamak için az önce açıklanan yaklaşımı kullanmak mantıklı olur. Öte yandan karmaşık, üst düzeyde ölçeklenebilir, global bir bulut uygulaması yüzlerce web ve çalışan rolünden, veritabanı parçalarından ve diğer hizmetlerden muazzam miktarlarda veri oluşturabilir. Bu veri akımı tek, merkezi bir konumla kullanılabilen G/Ç bant genişliğini kolayca baskı altına alabilir. Bu nedenle, sistem genişledikçe performans sorunu yaratmasını önlemek için telemetri çözümünüzün ölçeklenebilir olması gerekir. İdeal durumda, sistemin bir bölümü başarısız olduğunda önemli izleme bilgilerini (denetim veya faturalama verileri gibi) kaybetme riskini azaltmak için çözümünüz belirli bir düzeyde yedekli çalışma özelliğine sahip olmalıdır.

Bu sorunlara çözüm getirmek için, Şekil 4'te gösterildiği gibi kuyruğa almayı uygulayabilirsiniz. Bu mimaride, yerel izleme aracısı (uygun şekilde yapılandırılabiliyorsa) veya özel veri toplama hizmeti (yapılandırılamıyorsa) verileri kuyruğa gönderir. Zaman uyumsuz çalıştırılan ayrı bir işlem (Şekil 4'teki depolamaya yazma hizmeti) bu kuyruktaki verileri alır ve paylaşılan depolamaya yazar. İleti kuyruğu bu senaryoya uygundur çünkü kuyruğa alınan verilerin gönderildikten sonra kaybolmamasını sağlamaya yardımcı olan "en az bir kez" semantiği sağlar. Depolama yazma hizmetini ayrı bir çalışan rolü kullanarak gerçekleştirebilirsiniz.

Şekil 4 - İzleme verilerini arabelleğe almak için kuyruk kullanma.

Yerel veri toplama hizmeti verileri aldıktan hemen sonra kuyruğa ekleyebilir. Kuyruk bir arabellek işlevi görür ve depolamaya yazma hizmeti verileri kendi belirlediği bir hızda alabilir ve yazabilir. Varsayılan olarak kuyruk, ilk giren ilk çıkar mantığında çalışır. Ama iletiler daha hızlı işlenmesi gereken veriler içeriyorsa, kuyrukta hızlandırmak için bu iletilerin öncelikli olmasını sağlayabilirsiniz. Daha fazla bilgi için bkz. Öncelikli Kuyruk düzeni. Alternatif olarak, gereken analitik işleme biçimine bağlı olarak verileri farklı hedeflere yönlendirmek için farklı kanallar (Service Bus konuları gibi) kullanabilirsiniz.

Ölçeklenebilirlik açısından, depolamaya yazma hizmetinin birden çok örneğini çalıştırabilirsiniz. Çok fazla miktarda olay varsa, verileri işleme ve depolama amacıyla farklı işlem kaynaklarına göndermek için bir olay hub'ı kullanabilirsiniz.

Ölçümlü izleme verilerini birleştirme

Veri toplama hizmetinin uygulamanın tek bir örneğinden aldığı ölçümlü izleme verileri, o örneğin sistem durumu ve performansının yerelleştirilmiş bir görünümünü verir. Sistemin genel durumunu değerlendirmek için verilerin bazı yönlerini yerel görünümlerle birleştirmek gerekir. Bunu veriler depolandıktan sonra yapabilirsiniz, ama bazı durumlarda veriler toplanırken de bunu başarabilirsiniz. Ölçümlü izleme verileri doğrudan paylaşılan depolamaya yazılmak yerine, verileri birleştiren, filtreleme ve temizleme işlevi gibi çalışan ayrı bir veri birleştirme hizmetine de geçirilebilir. Örneğin, etkinlik kimliği gibi aynı ilişkilendirme bilgilerini içeren ölçümlü izleme verileri kaynaştırılabilir. (Kullanıcının bir düğümde iş işlemi gerçekleştirmeye başlaması ve düğüm hatası durumunda veya yük dengelemenin nasıl yapılandırıldığına bağlı olarak başka bir düğüme aktarılması mümkündür.) Bu işlem yinelenen verileri de algılayabilir ve kaldırabilir (telemetri hizmeti izleme verilerini depolama alanına göndermek için ileti kuyruklarını kullanıyorsa her zaman mümkündür). Şekil 5'te bu yapının bir örneği gösterilir.

Şekil 5 - İzleme verilerini birleştirmek ve temizlemek için ayrı bir hizmet kullanma.

Ölçümlü izleme verilerini depolama

Önceki açıklamalarda ölçümlü izleme verilerinin depolanma yönteminin biraz basitleştirilmiş bir görünümü gösterilmişti. Gerçekte, farklı türlerdeki verileri depolarken her türün büyük olasılıkla kullanılacağı yönteme en uygun teknolojileri kullanmak anlamlı olabilir.

Örneğin, Azure blob ve tablo depolamanın erişim yönteminde bazı benzerlikler bulunur. Ancak bunları kullanarak gerçekleştirebileceğiniz işlemlerde sınırlamalar vardır ve bunlarda tutulan verilerin ayrıntı düzeyi oldukça farklıdır. Daha analitik işlemler yapmanız veya verilerde tam metin arama özelliklerine sahip olmanız gerekiyorsa, belirli sorgu ve veri erişimi türleri için iyileştirilmiş özellikler sağlayan veri depolamasını kullanmak daha uygun olabilir. Örneğin:

• Performans sayacı verileri geçici analize olanak tanımak için bir SQL veritabanında depolanabilir.
• İzleme günlüklerini Azure Cosmos DB'de depolamak daha iyi olabilir.
• Güvenlik bilgileri HDFS'ye yazılabilir.
• Tam metin araması gerektiren bilgiler Elasticsearch aracılığıyla depolanabilir (bu, zengin dizin oluşturma kullanarak da aramaları hızlandırabilir).

Şekil 6'da gösterildiği gibi verileri düzenli aralıklarla paylaşılan depolamadan alan, amacına uygun olarak bölümleyen ve filtreleyen, sonra da uygun veri depoları kümesine yazan ek bir hizmet uygulayabilirsiniz. Alternatif bir yaklaşım da bu işlevselliği birleştirme ve temizleme işlemine eklemek ve verileri paylaşılan bir ara depolama alanına kaydetmek yerine alındıklarında doğrudan bu depolara yazmaktır. Her yaklaşımın kendi avantajları ve dezavantajları vardır. Ayrı bir bölümleme hizmeti uygulamak birleştirme ve temizleme hizmetinin yükünü azaltır, gerekirse bölümlenmiş verilerin en azından bir bölümünün yeniden oluşturulmasına olanak tanır (paylaşılan depolamada ne kadar veri tutulduğuna bağlı olarak). Öte yandan bu, ek kaynaklar kullanır. Ayrıca, her uygulama örneğinden ölçümlü izleme verilerinin alınması ile bu verilerin üzerinde işlem yapılabilen bilgilere dönüştürülmesi arasında gecikme olabilir.

Şekil 6 - Verileri analiz ve depolama gereksinimlerine göre bölümleme.

Aynı ölçümlü izleme verileri birden çok amaç için gerekli olabilir. Örneğin, performans sayaçları sistem performansının zaman içindeki geçmiş görünümünü sağlamak için kullanılabilir. Bu bilgiler başka kullanım verileriyle birleştirilerek müşteri faturalama bilgilerini oluşturabilir. Böyle durumlarda, aynı veriler faturalama bilgilerinin barındırıldığı uzun vadeli depo işlevi gören bir belge veritabanı ve karmaşık performans analizi yapmak için çok boyutlu bir depo gibi birden çok hedefe gönderilebilir.

Ayrıca verilere ne kadar acil gerek duyulduğunu da göz önüne almalısınız. Uyarı vermek için bilgi sağlayan verilere hızla erişilmelidir; dolayısıyla bunlar hızlı veri depolamasında tutulmalı ve uyarı sisteminin gerçekleştirdiği sorguları iyileştirmek için dizine alınmalı veya yapılandırılmalıdır. Bazı durumlarda, her düğümde verileri toplayan telemetri hizmetinin verileri yerel olarak biçimlendirmesi ve kaydetmesi gerekebilir; böylelikle uyarı sisteminin yerel örneği sorunları size hızla bildirebilir. Aynı veriler önceki diyagramlarda gösterilen depolamaya yazma hizmetine gönderilebilir ve başka amaçlarla da gerekliyse merkezi olarak depolanabilir.

Daha kapsamlı bir analiz, raporlama ve geçmiş eğilimleri saptama için kullanılan bilgiler o kadar acil değildir ve veri madenciliğini ve geçici sorguları destekleyecek bir şekilde depolanabilir. Daha fazla bilgi için bu belgenin devamındaki Hızlı, orta gecikmeli ve gecikmeli analizi destekleme bölümüne bakın.

Günlük rotasyonu ve veri saklama

Ölçümlü izleme önemli miktarda veri oluşturabilir. Bu veriler ham günlük dosyaları, izleme dosyaları ve her düğümde yakalanan diğer bilgilerden başlayıp bu verilerin paylaşılan depolamada tutulan birleştirilmiş, temizlenmiş ve bölümlenmiş görümüne kadar, çeşitli yerlerde tutulabilir. Bazı durumlarda, veriler işlendikten ve aktarıldıktan sonra, özgün ham kaynak veriler düğümlerden kaldırılabilir. Diğer durumlarda, ham bilgileri kaydetmek gerekli veya yalnızca kullanışlı olabilir. Örneğin, hata ayıklama amacıyla oluşturulan verilerin ham biçimde kullanılabilir durumda bırakılması en iyi yöntem olabilir ama tüm hatalar düzeltildikten sonra bunlar hızla atılabilir.

Performans verileri çoğunlukla daha uzun ömürlüdür çünkü performans eğilimlerini saptama ve kapasite planlama amaçlarıyla kullanılabilir. Bu verilerin birleştirilmiş görünümü, hızlı erişime olanak tanımak için genellikle sınırlı bir süre çevrimiçi tutulur. Bu sürenin sonunda, bunlar arşivlenebilir veya atılabilir. Ölçüm ve müşteri faturalandırması için toplanan verilerin süresiz olarak kaydedilmesi gerekebilir. Bunlara ek olarak, yasal düzenleme gereksinimleri denetim ve güvenlik amacıyla toplanan bilgilerin aynı zamanda arşivlenmesini ve kaydedilmesini zorunlu tutabilir. Ayrıca bunlar hassas verilerdir ve bu verilerin üzerinde oynanmasını önlemek için şifrelenmeleri veya başka bir yolla korunmaları da gerekebilir. Kullanıcıların parolalarını veya kimlik dolandırıcılığı yapmak için kullanılabilecek diğer bilgileri hiçbir zaman kaydetmemelisiniz. Bu tür ayrıntılar depolanmadan önce verilerden temizlenmelidir.

Aşağı örnekleme

Uzun vadeli eğilimleri belirleyebilmeniz için geçmiş verilerini depolamak yararlıdır. Eski verilerin tamamını kaydetmek yerine, çözünürlüğünü azaltmak ve depolama maliyetlerinden tasarruf etmek için verilerin aşağı örneklemesini almak mümkün olabilir. Örneğin, dakikalık performans göstergelerini kaydetmek yerine, bir aydan daha eski olan verileri birleştirip saatlik bir görünüm oluşturabilirsiniz.

Günlük bilgilerini toplamak ve depolamak için en iyi yöntemler

Aşağıdaki listede, yakalama ve günlük kaydı bilgilerini depolamak için en iyi uygulamalar özetlenmektedir:

• İzleme aracısı veya veri toplama hizmeti ayrı işlemde çalışan bir hizmet olarak çalıştırılmalı ve dağıtımı kolay olmalıdır.

• İzleme aracısı veya veri toplama hizmetinden alınan tüm çıkış makineden, işletim sisteminden veya ağ protokolünden bağımsız bir biçime sahip olmalıdır. Örneğin, bilgileri ETL/ETW yerine açıklamasını kendi içinde barındıran JSON, MessagePack veya Protobuf gibi bir biçimde gösterin. Standart bir biçim kullanmak, sistemin işleme için işlem hatlarını oluşturmasına olanak tanır; verileri üzerinde anlaşmaya varılmış olan biçimde okuyan, dönüştüren ve gönderen bileşenler kolayca tümleştirilebilir.

• İzleme ve veri toplama işlemi hataya dayanıklı olmalı, hiçbir basamaklı hata koşulunu tetiklememelidir.

• Bilgileri veri havuzuna gönderirken geçici bir hata oluşması durumunda, izleme aracısı veya veri toplama hizmeti en önce en yeni bilgilerin gönderilmesini sağlamak üzere telemetri verilerini yeniden sıralamak için hazırlıklı olmalıdır. (İzleme aracısı/veri toplama hizmeti daha eski verileri bırakmayı veya bunları yerel olarak depolayıp daha sonra kendi karar verdiği zaman iletip arayı kapatmayı seçebilir.)

Verileri çözümleme ve sorunları tanılama

İzleme ve tanılama işleminin önemli bir bölümü toplanan verileri analiz etmek ve sistemin genel durumunun bir resmini elde etmektir. Kendi KPI'lerinizi ve performans ölçümlerinizi tanımlamış olmalısınız ve analiz gereksinimlerinizi karşılamak için toplanan verileri nasıl yapılandırabileceğinizi anlamanız önemlidir. Ayrıca, farklı ölçümlerde ve günlük dosyalarında yakalanan verilerin nasıl ilişkilendirileceğini anlamak da önemlidir çünkü bu bilgiler bir olay dizisini izlemekte kilit rol oynayabilir ve çıkan sorunları tanılamaya yardımcı olabilir.

Ölçümlü izleme verilerini birleştirme bölümünde açıklandığı gibi, sistemin her parçasına ilişkin veriler normalde yerel olarak yakalanır ama genellikle sisteme katkıda bulunan diğer yerlerde oluşturulan verilerle birleştirilmeleri gerekir. Verilerin doğru birleştirildiğinden emin olmak için bu bilgiler dikkatle ilişkilendirilmelidir. Örneğin, bir işlemin kullanım verileri kullanıcının bağlandığı web sitesini barındıran düğüme, bu işlem kapsamında erişilen ayrı bir hizmetin çalıştırıldığı düğüme yayılabilir ve veri depolaması ayrı bir düğümde tutulabilir. İşlemle ilgili kaynak ve işleme kullanımının genel görünümünü sağlamak için bu bilgilerin birbirine bağlanması gerekir. Verilerin yakalandığı düğümde bazı ön işleme ve filtreleme işlemleri gerçekleşebilirken, toplama ve biçimlendirmenin merkezi bir düğümde gerçekleşmesi daha olasıdır.

Hızlı, orta gecikmeli ve gecikmeli analizi destekleme

Verileri görselleştirme, raporlama ve uyarı verme amacıyla analiz etmek ve yeniden biçimlendirmek, kendi kaynak kümelerini kullanan karmaşık bir işlem olabilir. Bazı izleme biçimleri zamana duyarlıdır ve etkili olması için verilerin hemen analiz edilmesi gerekir. Bu hızlı analiz olarak bilinir. Uyarı vermek için gereken analizler ve güvenlik izlemesinin bazı yönleri (sistemdeki bir saldırıyı algılama gibi) buna örnek verilebilir. Bu amaçlar için gereken veriler hızla sağlanabilmeli ve verimli işleme için yapılandırılabilmelidir. Bazı durumlarda, analiz işleminin verilerin tutulduğu tek tek düğümlere taşınması gerekebilir.

Diğer analiz biçimleri zamana o kadar duyarlı değildir ve ham veriler alındıktan sonra bazı hesaplamalar ve toplamalar yapmayı gerektirebilir. Bu orta gecikmeli analiz olarak adlandırılır. Performans analizi genellikle bu kategoriye girer. Böyle bir durumda, yalıtılmış tek bir performans olayının istatistiksel açıdan anlamlı olması pek olası değildir. (Ani bir ani ani artış veya hatadan kaynaklanıyor olabilir.) Bir dizi olaydaki veriler, sistem performansının daha güvenilir bir resmini sağlamalıdır.

Orta gecikmeli analiz sistem durumu sorunlarını tanılamaya da yardımcı olabilir. Sistem durumu olayları normalde hızlı analiz aracılığıyla işlenir ve hemen uyarı oluşturabilir. Operatörün orta gecikmeli kanaldan gelen verileri inceleyerek sistem durumu olayının nedenlerini ayrıntılı olarak görebilmesi gerekir. Bu veriler, sistem durumu olayına neden olan soruna hangi olayların yol açtığı hakkında bilgiler içerecektir.

Bazı izleme türleri daha uzun vadeli veriler oluşturur. Bu analiz daha ileri bir tarihte, olasılıkla önceden tanımlanmış bir zamanlamaya göre gerçekleştirilebilir. Bazı durumlarda analizde, belirli bir süre boyunca yakalanmış büyük miktarlardaki veriler üzerinde karmaşık filtreleme işlemleri yapılması gerekebilir. Bu gecikmeli analiz olarak adlandırılır. En önemli gereksinim, verilerin yakalandıktan sonra güvenli bir şekilde depolanmasıdır. Örneğin, kullanım izleme ve denetim için zaman içinde düzenli aralıklarla sistemin durumunun doğru bir resmini elde etmek gerekir, ama bu durum bilgilerinin toplandıktan hemen sonra işlenmek için kullanılabilir olması şart değildir.

Operatör tahmine dayalı sistem durumu analizine veri sağlamak için de gecikmeli analizi kullanabilir. Operatör belirli bir süre boyunca geçmiş bilgilerini toplayabilir ve bunları geçerli sistem durumu verileriyle (hızlı kanaldan alınmış veriler) birlikte kullanarak kısa süre içinde sistem durumu sorunlarına neden olabilecek eğilimleri saptayabilir. Böyle durumlarda, düzeltici eylem yapılabilmesi için uyarı oluşturmak gerekebilir.

Verileri ilişkilendirme

Ölçümlü izlemede yakalanan veriler sistem durumunun anlık bir görüntüsünü sağlayabilir ama analizin amacı bu verileri işlenebilir duruma getirmektir. Örneğin:

• Belirli bir zamanda sistem düzeyinde yoğun G/Ç yüküne ne neden oldu?
• Bu çok fazla sayıda veritabanı işleminin sonucu mu?
• Bu durum veritabanı yanıt sürelerine, saniyede yapılan işlem sayısına ve aynı kavşakta uygulamanın yanıt sürelerine yansıdı mı?

Öyleyse, yükü azaltabilecek düzeltici eylem, verileri daha fazla sunucuya parçalamak olabilir. Buna ek olarak, sistemin herhangi bir düzeyindeki bir hata sonucunda özel durumlar oluşabilir. Bir düzeyde yaşanan özel durum genellikle onun üstündeki düzeyde başka bir hatayı tetikler.

Bu nedenlerle, sistemin ve sistem üzerinde çalıştırılan uygulamaların durumunun genel bir görünümünü oluşturmak için her düzeyde elde edilen farklı türlerdeki izleme verilerini birbiriyle ilişkilendirmeniz gerekir. Bundan sonra bu bilgileri kullanarak sistemin çalışma durumunun kabul edilebilir olup olmadığı konusunda karar verebilir ve sistemin kalitesini geliştirmek için neler yapılabileceğini saptayabilirsiniz.

Verileri ilişkilendirmek için gereken bilgiler bölümünde açıklandığı gibi, ham ölçümlü izleme verilerinin olayları ilişkilendirmek için gereken toplama işlemlerini desteklemek için yeterli bağlam ve etkinlik kimliği bilgilerini içerdiğinden emin olmalısınız. Ayrıca, bu bilgiler farklı biçimlerde tutulmuş olabilir ve analiz amacıyla bu bilgileri standart bir biçime dönüştürmek için ayrıştırmak gerekebilir.

Sorunları tanılama ve giderme

Tanılama işlemi, kök neden analizi gerçekleştirmek de dahil olmak üzere hataların veya beklenmedik davranışların nedenini saptayabilmeyi gerektirir. Normal olarak şu bilgiler gerekir:

• Belirtilen bir zaman çerçevesinde sistemin tamamının veya belirli bir alt sistemin olay günlüklerinden ve izlemelerinden alınan ayrıntılı bilgiler.
• Belirtilen bir süre içinde sistemde veya belirli bir alt sistemde oluşan her düzeydeki özel durumlar ve hataların sonucunda alınan eksiksiz yığın izlemesi.
• Belirtilen bir zaman çerçevesinde sistemin herhangi bir yerinde veya belirli bir alt sistemdeki başarısız işlemlerin kilitlenme bilgi dökümleri.
• Belirtilen bir süre içinde tüm kullanıcılar veya seçilen kullanıcılar tarafından gerçekleştirilen işlemlerin etkinlik günlükleri kaydı.

Sorun giderme amacıyla verilerin analiz edilmesi için çoğunlukla sistem mimarisinin ve çözümü oluşturan çeşitli bileşenlerin teknik açıdan ayrıntılı olarak anlaşılması gereklidir. Sonuç olarak, verileri yorumlamak, sorunların nedenini belirlemek ve bunları düzeltmeye yönelik uygun bir strateji önermek için çoğunlukla önemli ölçüde el ile müdahale gerekir. Yalnızca bu bilgilerin özgün biçimlerinde birer kopyasını saklamak ve bir uzmanın bunlar üzerinde gecikmeli analiz yapmasını sağlamak uygun olabilir.

Verileri görselleştirme ve uyarı oluşturma

Tüm izleme sistemlerinin önemli bir yönü, verileri bir operatörün her türlü eğilimi veya sorunu hızla belirleyebilmesini sağlayacak şekilde gösterme özelliğidir. Ayrıca dikkat edilmesi gereken önemli bir olay olduğunda operatörü bu konuda hızla bilgilendirmek de önemli bir özelliktir.

Veriler çeşitli biçimlerde, örneğin panolar,uyarılar ve raporlar kullanılarak görselleştirme yoluyla sunulabilir.

Panoları kullanarak görselleştirme

Verileri görselleştirmenin en yaygın yolu, bilgileri bir dizi grafik, graf veya bazı başka çizimlerle görüntüleyebilen panoları kullanmaktır. Bu öğeler parametreleştirilebilir ve bir analistin belirli herhangi bir durum için önemli parametreleri (örneğin, süre) seçebilmesi gerekir.

Panolar hiyerarşik olarak düzenlenebilir. En üst düzey panolar sistemin her yönünün genel bir görünümünü verebilir ve operatörün ayrıntıya gitmesine olanak tanıyabilir. Örneğin sistemin genel disk G/Ç bilgisini gösteren bir pano, orantısız trafik hacmine belirli bir veya birden çok cihazın neden olup olmadığını belirlemek için analistin her diske ilişkin G/Ç hızlarını görüntülemesine olanak tanımalıdır. İdeal durumda pano, bu G/Ç'yi oluşturan her isteğin kaynağı (kullanıcı veya etkinlik) gibi ilgili bilgileri de görüntülemelidir. Bu bilgiler daha sonra yükün cihazlar arasında daha eşit dağıtılıp dağıtılmayacağını ve bu dağıtımın nasıl yapılacağını, ayrıca daha fazla cihaz eklenirse sistemin daha iyi performans gösterip göstermeyeceğini saptamak için kullanılabilir.

Pano anormal görünen veya beklenen aralığın dışında kalan değerleri göstermek için renk kodlaması veya başka görsel ipuçları da kullanabilir. Önceki örneği kullanırsak:

• Uzun bir süre boyunca G/Ç hızı maksimum kapasitesine yaklaşan bir disk (etkin disk) kırmızıyla vurgulanabilir.
• Düzenli aralıklarla kısa süreler için G/Ç hızı maksimum sınırında çalışan bir disk (yarı etkin disk) sarıyla vurgulanabilir.
• Normal kullanım ortaya koyan bir disk yeşille gösterilebilir.

Pano sisteminin etkili çalışması için, üzerinde çalışacağı ham verileri olması gerektiğini unutmayın. Kendi pano sisteminizi oluşturuyorsanız veya başka bir kuruluşun geliştirdiği panoyu kullanıyorsanız, hangi ölçümlü izleme verilerini, hangi ayrıntı düzeyinde toplamanız gerektiğini ve panonun kullanabilmesi için bu verilerin nasıl biçimlendirileceğini anlamalısınız.

İyi bir pano yalnızca bilgileri görüntülemekle kalmaz, analistin bu bilgilerle ilgili rastgele sorular sorabilmesine de olanak tanır. Bazı sistemler operatörün bu görevleri gerçekleştirmek ve temel verileri incelemek için kullanabileceği yönetim araçları sağlar. Alternatif olarak, bilgileri tutmak için kullanılan depoya bağlı olmak kaydıyla bu verileri doğrudan sorgulamak veya daha fazla analiz ve raporlama için Microsoft Excel gibi araçlara aktarmak da mümkün olabilir.

Uyarı oluşturma

Uyarı verme, izleme ve ölçümlü izleme verilerini analiz etme, önemli bir olay algılanması durumunda da bildirim oluşturma sürecidir.

Uyarı verme süreci sistemin iyi, yanıt verir ve güvenli durumda olduğundan emin olmayı sağlar. Bu, verilerin üzerinde hemen işlem yapılmasının gerekli olabildiği, kullanıcılara performans, kullanılabilirlik ve gizlilik garantileri veren her sistemin önemli bir parçasıdır. Uyarıyı tetikleyen olayın operatöre bildirilmesi gerekebilir. Uyarı verme, otomatik ölçeklendirme gibi sistem işlevlerini çağırmak için de kullanılabilir.

Uyarı verme genellikle aşağıdaki ölçümlü izleme verilerine dayanır:

• Güvenlik olayları. Olay günlükleri yinelenen kimlik doğrulaması veya yetkilendirme hatalarının oluştuğunu gösteriyorsa, sistem saldırı altında olabilir ve bir işleç bilgilendirilmelidir.
• Performans ölçümleri. Belirli bir performans ölçümünün belirtilen eşiği aşması durumunda sistemin hızla yanıt vermesi gerekir.
• Kullanılabilirlik bilgileri. Hata algılanırsa, bir veya birden çok alt sistemi hızla yeniden başlatmak veya yedek kaynağa yük devretmek gerekebilir. Bir alt sistemdeki yinelenen hatalar daha ciddi sorunlara işaret ediyor olabilir.

Operatörler e-posta, çağrı cihazı veya SMS mesajı gibi birçok teslim kanalından birini kullanarak uyarı bilgilerini alabilir. Uyarıda durumun ne kadar kritik olduğuna dair bir gösterge de bulunabilir. Birçok uyarı sistemi abone gruplarını destekler ve aynı gruba üye olan tüm operatörler aynı uyarı kümelerini alabilir.

Uyarı sistemi özelleştirilebilir olmalıdır ve temel ölçümlü izleme verilerinden elde edilen uygun değerler parametre olarak sağlanabilir. Bu yaklaşım operatörün verileri filtrelemesine ve ilgilendiği eşiklere veya değer bileşimlerine odaklanmasına olanak tanır. Bazı durumlarda, uyarı sistemine ham ölçümlü izleme verilerinin sağlanabileceğini unutmayın. Başka durumlarda, toplanan verilerin sağlanması daha uygun olabilir. (Örneğin, bir düğüm için CPU kullanımı son 10 dakika içinde yüzde 90'ı aşarsa bir uyarı tetiklenebilir). Uyarı sistemine sağlanan ayrıntılar uygun bir özeti ve bağlam bilgilerini de içerebilir. Bu veriler hatalı pozitif sonuç veren olayların yanlış uyarılara neden olma olasılığını düşürmeye yardımcı olabilir.

Raporlama

Raporlama sistemin genel bir görünümünü elde etmek için kullanılır. Güncel bilgilere ek olarak geçmiş verilerini de bir araya getirebilir. Raporlama gereksinimleri kendi başına iki büyük kategoriye ayrılır: işlem raporlaması ve güvenlik raporlaması.

İşlem raporlaması normalde aşağıdaki konuları içerir:

• Belirli bir zaman penceresi sırasında genel sistemin veya belirtilen alt sistemlerin kaynak kullanımını anlamak için kullanabileceğiniz istatistikleri toplama.
• Belirli bir süre boyunca genel sistem veya belirtilen alt sistemler için kaynak kullanımı eğilimlerini belirleme.
• Sistem genelinde veya belirtilen bir süre boyunca belirtilen alt sistemlerde oluşan özel durumları izleme.
• Dağıtılan kaynaklar açısından uygulamanın verimliliğini belirlemek ve kaynakların hacminin (ve ilişkili maliyetlerinin) performansı gereksiz yere etkilemeden azaltılıp azaltılamayacağını anlamak.

Güvenlik raporlaması müşterilerin sistem kullanımını izlemekle ilgilidir. Şunları içerebilir:

• Kullanıcı işlemlerini denetleme. Bunun için her kullanıcının gerçekleştirdiği istekleri tek tek, tarih ve saatiyle kaydetmek gerekir. Yöneticinin belirli bir sürede kullanıcının gerçekleştirdiği işlemlerin sırasını hızla yeniden oluşturabilmesi için veriler yapılandırılmalıdır.
• Kullanıcı tarafından kaynak kullanımını izleme. Bunun için kullanıcıyla ilişkili her isteğin sistemi oluşturan çeşitli kaynaklara nasıl ve ne kadar süreyle eriştiğini kaydetmek gerekir. Yönetici bu verileri kullanarak belirli bir süre için kullanıcının kullanım raporunu (muhtemelen faturalama amacıyla) oluşturabilmelidir.

Birçok durumda, tanımlanan zamanlamaya göre raporları toplu işlemler oluşturabilir. (Gecikme normalde bir sorun değildir.) Ancak, gerekirse geçici olarak nesiller için de kullanılabilir olmalıdır. Örneğin, verileri Azure SQL Veritabanı gibi bir ilişkisel veritabanında depoluyorsanız verileri ayıklayıp biçimlendirmek ve bir dizi rapor şeklinde sunmak için SQL Server Reporting Services gibi bir araç kullanabilirsiniz.

Sonraki adımlar

• Azure İzleyici'ye genel bakış
• Microsoft Azure Depolama izleme, tanılama ve sorun giderme
• Microsoft Azure'da uyarılara genel bakış
• Azure portalını kullanarak hizmet durumu bildirimlerini görüntüleme
• Application Insights nedir?
• Azure sanal makineleri için performans tanılamaları
• Visual Studio için SQL Server Veri Araçları (SSDT) indirme ve yükleme

İlgili kaynaklar

• Otomatik ölçeklendirme kılavuzu, kullanıcının sürekli sistem performansını izlemesi ve kaynakları ekleme ve kaldırma hakkında karar vermesi gerekliliğini ortadan kaldırarak yönetim yükünün nasıl azaltılabileceğini açıklar.
• Sistem Durumu Uç Noktası İzleme düzeni , dış araçların belirli aralıklarla kullanıma sunulan uç noktalar aracılığıyla erişebileceği bir uygulama içinde işlevsel denetimlerin nasıl uygulanabileceğini açıklar.
• Öncelik Sırası düzeni , acil isteklerin alınması ve daha az acil iletilerden önce işlenebilmesi için kuyruğa alınan iletilerin önceliklerini belirlemeyi gösterir.