İzleme ve tanılama kılavuzu

Azure İzleyici

Bulutta çalışan dağıtılmış uygulamalar ve hizmetler, doğası gereği birçok hareketli parçadan oluşan karmaşık yazılım parçalarıdı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ı

Bir sistemin ne kadar iyi çalıştığını görmek için izlemeyi kullanabilirsiniz. İzleme, hizmet kalitesi hedeflerini korumanın önemli bir parçasıdır. İzleme verilerini toplamaya yönelik yaygın senaryolar şunlardır:

• Sistemin sağlıklı kalmasını sağlamak.
• Sistemin ve bileşen öğelerinin kullanılabilirliğini izleme.
• Çalışma hacmi arttıkça sistemin aktarım hızının beklenmedik şekilde azalmamasını sağlamak için performansın korunması.
• Sistemin müşterilerle kurulan hizmet düzeyi sözleşmelerini (SLA) karşıladığını garanti eder.
• Sistemin, kullanıcıların ve verilerinin gizliliğini ve güvenliğini koruma.
• Denetim veya düzenleme amacıyla gerçekleştirilen işlemleri izleme.
• Sistemin günlük kullanımını izleme ve ele alınmaması durumunda sorunlara yol açabilecek eğilimleri tespit etme.
• İlk rapordan olası nedenlerin analizine, düzeltmeye, sonuç olarak yazılım güncelleştirmelerine ve dağıtıma kadar oluşan sorunları izleme.
• İşlem izleme ve yazılım sürümlerinde hata ayıklama.

Uyarı

Bu listenin kapsamlı olması amaçlanmamıştır. Bu belge, izleme gerçekleştirmeye yönelik en yaygın durumlar olarak bu senaryolara odaklanır. Daha az yaygın olan veya ortamınıza özgü başkaları da olabilir.

Aşağıdaki bölümlerde bu senaryolar daha ayrıntılı olarak açıklanmaktadır. Her senaryonun bilgileri aşağıdaki biçimde ele alındı:

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.

Sağlık izleme

Sistem çalışıyorsa ve istekleri işliyorsa iyi durumdadır. Sistem durumu izlemenin amacı, sistemin tüm bileşenlerinin beklendiği gibi çalıştığını doğrulayabilmeniz için sistemin geçerli durumunun anlık görüntüsünü oluşturmaktır.

Sağlık izleme gereksinimleri

Sistemin herhangi bir parçasının iyi durumda olmadığının kabul edilmesi durumunda operatör hızla (birkaç saniye içinde) uyarılmalıdır. Operatör, sistemin hangi bölümlerinin normal şekilde çalıştığını ve hangi parçaların sorun yaşadığını doğrulayabilmelidir. Sistem durumu bir trafik ışığı sistemi aracılığıyla vurgulanabilir:

• İyi durumda olmayanlar için kırmızı (sistem durdu)
• Kısmen iyi durumda (sistem sınırlı işlevsellikle çalışıyor) için sarı
• Tamamen sağlıklı olanlar için yeşildir

Kapsamlı bir sistem durumu izleme sistemi, operatörün alt sistemlerin ve bileşenlerin sistem durumunu görüntülemek için sistemde detaya gitmesine olanak tanır. Örneğin, genel sistem kısmen sağlıklı olarak gösteriliyorsa, işletici veya kullanıcı yakınlaştırma yaparak şu anda hangi işlevselliğin düşürüldüğünü veya kullanılamaz olduğunu belirleyebilmelidir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sistem durumu izlemeyi desteklemek için gereken ham veriler aşağıdakilerin sonucu olarak oluşturulabilir:

• Kullanıcı isteklerinin yürütülmesini izleme. Bu bilgiler, hangi isteklerin başarılı olduğunu, hangilerinin başarısız olduğunu ve her isteğin ne kadar sürdüğünü belirlemek için kullanılabilir.
• Yapay kullanıcı izleme. Bu işlem, bir kullanıcı tarafından gerçekleştirilen adımların benzetimini gerçekleştirir ve önceden tanımlanmış bir dizi adımı izler. Her adımın sonuçları yakalanmalıdır.
• Özel durumları, hataları ve uyarıları günlüğe kaydetme. Bu bilgiler, uygulama koduna eklenmiş izleme deyimlerinin bir sonucu olarak yakalanabilir ve sistemin referans aldığı hizmetlerin olay günlüklerinden bilgi toplanabilir.
• Sistemin kullandığı tüm üçüncü taraf hizmetlerinin durumunu izleme. Bu izleme için bu hizmetlerin sağladığı sistem durumu verilerinin alınması ve ayrıştırılması gerekebilir. Bu bilgiler çeşitli biçimlerde olabilir.
• Uç nokta izleme. Bu mekanizma , "Kullanılabilirlik izleme" bölümünde daha ayrıntılı olarak açıklanmıştır.
• Arka plan CPU kullanımı veya G/Ç (ağ dahil) etkinliği gibi ortam performansı bilgilerini toplama.

Sağlık verilerini çözümleme

Sistem durumu izlemenin birincil odağı, sistemin çalışıp çalışmadığını hızla belirtmektir. Anlık verilerin sık erişimli analizi, kritik bir bileşen iyi durumda değil olarak algılanırsa (örneğin, ardışık bir ping dizisine yanıt veremediğinde) bir uyarı tetikleyebilir. İşleç daha sonra uygun düzeltici eylemi gerçekleştirebilir.

Daha gelişmiş bir sistem, son ve geçerli iş yükleri üzerinde soğuk analiz gerçekleştiren tahmine dayalı bir öğe içerebilir. Soğuk analiz eğilimleri belirleyebilir ve sistemin iyi durumda kalma olasılığının yüksek olup olmadığını veya sistemin ek kaynaklara ihtiyacı olup olmadığını belirleyebilir. Bu tahmine dayalı öğe aşağıdakiler gibi kritik performans ölçümlerini temel almalıdır:

• Her hizmet veya alt sisteme yönlendirilen isteklerin oranı.
• Bu isteklerin yanıt süreleri.
• Her hizmete giren ve giden veri hacmi.

Herhangi bir ölçümün değeri tanımlı eşiği aşarsa sistem, bir operatörün veya otomatik ölçeklendirmenin (varsa) sistem durumunu korumak için gerekli önleyici eylemleri gerçekleştirmesini sağlamak için bir uyarı oluşturabilir. Bu eylemler kaynak eklemeyi, başarısız olan bir veya daha fazla hizmeti yeniden başlatmayı veya düşük öncelikli isteklere azaltma uygulamayı içerebilir.

Kullanılabilirlik izleme

Gerçekten iyi durumda olan bir sistem, sistemi oluşturan bileşenlerin ve alt sistemlerin kullanılabilir olmasını gerektirir. Kullanılabilirlik izleme, sistem durumu izlemeyle yakından ilgilidir. Sistem durumu izleme, sistemin geçerli durumunun hemen bir görünümünü sağlarken, kullanılabilirlik izleme, sistemin çalışma süresiyle ilgili istatistikler oluşturmak için sistemin ve bileşenlerinin kullanılabilirliğini izlemekle ilgilidir.

Birçok sistemde, ciddi bir hata veya bağlantı kaybı durumunda hızlı yük devretmeye izin vermek için bazı bileşenler (veritabanı gibi) yerleşik yedeklilikle yapılandırılır. İdeal olarak, kullanıcılar böyle bir hata oluştuğundan haberdar olmamalıdır. Ancak kullanılabilirlik izleme perspektifinden bakıldığında, nedeni belirlemek ve yinelenenleri önlemek için düzeltici eylemler uygulamak için bu tür hatalar hakkında mümkün olduğunca çok bilgi toplamak gerekir.

Kullanılabilirliği izlemek için gereken veriler birden çok alt düzey faktöre bağlı olabilir. Bu faktörlerin çoğu uygulamaya, sisteme ve ortama özgü olabilir. Etkili bir izleme sistemi, bu düşük düzeyli faktörlere karşılık gelen kullanılabilirlik verilerini yakalar ve sonra bunları toplayarak sistemin genel bir resmini verir. Örneğin, bir e-ticaret sisteminde müşterinin sipariş vermesine olanak tanıyan iş işlevselliği, sipariş ayrıntılarının depolandığı depoya ve bu siparişlerin ödemesine yönelik parasal işlemleri işleyen ödeme sistemine bağlı olabilir. Bu nedenle sistemin sipariş yerleştirme bölümünün kullanılabilirliği, deponun ve ödeme alt sisteminin kullanılabilirliğinin bir işlevidir.

Kullanılabilirlik izleme gereksinimleri

Operatör ayrıca her sistemin ve alt sistemin geçmiş kullanılabilirliğini görüntüleyebilmeli ve bir veya daha fazla alt sistemin düzenli aralıklarla başarısız olmasına neden olabilecek eğilimleri saptamak için bu bilgileri kullanabilmelidir. Örneğin, operatör kullanılabilirlik verilerini kullanarak hizmetlerin yoğun işlem saatlerine karşılık gelen günün belirli bir saatinde başarısız olduğunu algılayabilir.

İzleme çözümü, her bir alt sistemin kullanılabilirliği veya kullanılamamasıyla ilgili anlık ve geçmiş bir görünüm sağlamalıdır. Ayrıca, bir veya daha fazla hizmet başarısız olduğunda veya kullanıcılar hizmetlere bağlanamayınca operatörü hızla uyarabilmelidir. Bu, yalnızca her hizmeti izlemekle kalmaz, aynı zamanda bir hizmetle iletişim kurmaya çalıştığında bu eylemlerin başarısız olması durumunda her kullanıcının gerçekleştirdiği eylemleri incelemektir. Bir ölçüde bağlantı hatası normaldir ve geçici hatalardan kaynaklanıyor olabilir. Ancak, sistemin belirli bir süre boyunca belirli bir alt sisteme bağlantı hatası sayısı için uyarı göndermesine izin vermek yararlı olabilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sistem durumu izlemede olduğu gibi, kullanılabilirlik izlemeyi desteklemek için gereken ham veriler yapay kullanıcı izlemesi ve oluşabilecek özel durumları, hataları ve uyarıları günlüğe kaydetmenin bir sonucu olarak oluşturulabilir. Ayrıca, kullanılabilirlik verileri uç nokta izlemesi gerçekleştirilerek elde edilebilir. Uygulama, sistem içindeki işlevsel bir alana erişimi test eden bir veya daha fazla sağlık uç noktasını kullanıma açabilir. İzleme sistemi, tanımlı bir zamanlamaya uyarak her uç noktaya ping yapabilir ve sonuçları toplayabilir (başarılı veya başarısız).

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 verilerini analiz etme

İzleme verilerinin aşağıdaki analiz türlerini desteklemek için toplanması ve bağıntılı olması gerekir:

• Sistemin ve alt sistemlerin hemen kullanılabilirliği.
• Sistemin ve alt sistemlerin kullanılabilirlik hatası oranları. İdeal olarak, bir işleç hataları belirli etkinliklerle ilişkilendirebilmelidir: Sistem başarısız olduğunda ne oluyordu?
• Sistemin veya herhangi bir alt sistemin belirtilen süre boyunca hata oranlarının ve bir hata oluştuğunda sistem üzerindeki yükün (örneğin kullanıcı isteklerinin sayısı) geçmiş görünümü.
• Sistemin veya alt sistemlerin kullanılamama nedenleri. Örneğin, bunun nedenleri hizmetin çalışmaması, bağlantının kaybolması, bağlantının kurulu ancak zaman aşımına uğraması ve bağlantı kurulmasına rağmen hata vermesi olabilir.

Aşağıdaki formülü kullanarak bir hizmetin belirli bir süre boyunca kullanılabilirlik yüzdesini hesaplayabilirsiniz:

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

Bu, SLA amaçları için 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ılamadığı süre (toplam birikmiş dakika) olarak tanımlar. Dakika boyunca müşteri tarafından başlatılan işlemleri gerçekleştirmek için Derleme Hizmeti'ne yapılan tüm sürekli HTTP istekleri hata koduyla sonuçlanırsa veya yanıt döndürmezse bir dakikanın kullanılamaz olduğu kabul edilir.

Performans izleme

Sistem giderek daha fazla stres altında olduğundan (kullanıcı hacmi artırılarak), bu kullanıcıların eriştiği veri kümelerinin boyutu artar ve bir veya daha fazla bileşenin başarısız olma olasılığı artar. Genellikle, bileşen hatasından önce performans düşüşü görülür. Böyle bir düşüşü algılayabilirseniz, durumu düzeltmek için proaktif adımlar atabilirsiniz.

Sistem performansı birden çok faktöre bağlıdır. Her faktör genellikle saniyedeki veritabanı işlemlerinin sayısı veya belirtilen bir zaman diliminde başarıyla hizmet veren ağ isteklerinin hacmi gibi temel performans göstergeleri (KPI' ler) aracılığıyla ölçülür. Bu KPI'lerden bazıları belirli performans ölçüleri olarak kullanılabilirken, diğerleri ölçümlerin birleşiminden türetilebilir.

Uyarı

Düşük veya iyi performansı belirlemek için sistemin çalışabilecek performans düzeyini anlamanız gerekir. Bunun için sistemin tipik bir yük altında çalışırken gözlemlenmesi ve belirli bir süre boyunca her KPI için verileri yakalaması gerekir. Bu, sistemi bir test ortamında sanal yük altında çalıştırmayı ve sistemi üretim ortamına dağıtmadan önce uygun verileri toplamayı içerebilir.

Ayrıca performans amacıyla izlemenin sistem üzerinde bir yük haline gelmediğinden de emin olmanız gerekir. Performans izleme işleminin topladığı verilerin ayrıntı düzeyini ayarlamak performansınızı iyileştirmenize yardımcı olur.

Performans izleme gereksinimleri

Bir operatörün sistem performansını incelemek için genellikle şunları içeren bilgileri görmesi gerekir:

• Kullanıcı isteklerinin yanıt oranları.
• Eşzamanlı kullanıcı isteklerinin sayısı.
• Ağ trafiğinin hacmi.
• İş işlemlerinin tamamlanma oranları.
• İstekler için ortalama işleme süresi.

Ayrıca, bir operatörün aşağıdakiler gibi bağıntıları belirlemesine yardımcı olacak araçlar sağlamak da yararlı olabilir:

• Eşzamanlı kullanıcıların sayısı ve istek gecikme süresi süreleri (kullanıcı gönderdikten sonra bir isteği işlemeye başlama süresi).
• Eş zamanlı kullanıcı sayısı ile ortalama yanıt süresi (işleme başladıktan sonra bir isteğin tamamlanmasının ne kadar sürdüğü).
• İsteklerin hacmiyle işleme hatalarının sayısı karşılaştırması.

Bu üst düzey işlevsel bilgilerle birlikte, bir operatörün sistemdeki her bileşenin performansına ilişkin ayrıntılı bir görünüm elde edebilmesi gerekir. Bu veriler genellikle aşağıdakiler gibi bilgileri izleyen düşük 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ğ giriş/çıkış hızları ve hataları
• Yazılan veya okunan bayt sayısı
• Kuyruk uzunluğu gibi ara yazılım göstergeleri

Tüm görselleştirmeler operatörün bir zaman aralığı belirtmesine izin vermelidir. 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, belirtilen herhangi bir zaman aralığında belirtilen herhangi bir değer için herhangi bir performans ölçüsüne göre uyarı oluşturabilmelidir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sistemden geçen kullanıcıların isteklerinin ilerleme durumunu izleyerek üst düzey performans verilerini (aktarım hızı, eşzamanlı kullanıcı sayısı, iş işlemleri sayısı ve hata oranları gibi) toplayabilirsiniz. Bu, zamanlama bilgileriyle birlikte uygulama kodundaki önemli noktalarda izleme deyimlerini birleştirmeyi içerir. Tüm hatalar, özel durumlar ve uyarılar, bunlara neden olan isteklerle ilişkilendirmek için yeterli veriyle yakalanmalıdır.

Mümkünse, uygulamanın kullandığı tüm dış sistemler için performans verilerini de yakalamanız gerekir. Bu dış sistemler, performans verilerini istemek için kendi performans sayaçlarını veya diğer özellikleri sağlayabilir. Bu mümkün değilse, bir dış sisteme yapılan her isteğin başlangıç saati ve bitiş saati gibi bilgileri işlemin durumuyla (başarılı, başarısız veya uyarı) birlikte kaydedin. Örneğin, istekleri zamanlarken kronometre yaklaşımını kullanabilirsiniz: İstek başladığında bir zamanlayıcı başlatın ve istek tamamlandığında zamanlayıcıyı durdurun.

Sistemdeki tek tek bileşenler için düşük düzey performans verileri, Windows performans sayaçları ve Azure Tanılama gibi özellikler ve hizmetler aracılığıyla kullanılabilir.

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. Kullanıcı isteğine örnek olarak alışveriş sepetine öğe ekleme veya e-ticaret sisteminde kullanıma alma işlemini gerçekleştirme işlemi gösterilebilir.

Bir diğer yaygın gereksinim de seçilen yüzdebirlik dilimlerdeki performans verilerini özetlemektir. Örneğin, bir işleç isteklerin yüzde 99'unun yanıt sürelerini, isteklerin yüzde 95'ini ve isteklerin yüzde 70'ini belirleyebilir. Her yüzdelik dilim için belirlenmiş SLA hedefleri veya başka hedefler olabilir. Anlık sorunları algılamaya yardımcı olmak için devam eden sonuçlar neredeyse gerçek zamanlı olarak bildirilmelidir. İstatistiksel amaçlar için sonuçlar da daha uzun bir süre içinde toplanmalıdır.

Performansı etkileyen gecikme sorunları söz konusu olduğunda, operatörün her isteğin gerçekleştirdiği her adımın gecikme süresini inceleyerek performans sorununun nedenini hızla belirleyebilmesi gerekir. Bu nedenle performans verilerinin, bunları belirli bir istekle ilişkilendirmek için her adım için performans ölçülerini ilişkilendirmek için bir araç sağlaması gerekir.

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 bilgilerinin karmaşık geçici sorgulamasına ve analizine izin verebilir.

Güvenlik izleme

Hassas veriler içeren tüm ticari sistemlerin bir güvenlik yapısı uygulaması gerekir. Güvenlik mekanizmasının karmaşıklığı genellikle verilerin duyarlılığının bir işlevidir. Kullanıcıların kimliğinin doğrulanması gereken bir sistemde şunları kaydetmelisiniz:

• İster başarısız ister başarılı olsun, tüm oturum açma girişimleri.
• 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ı oturumu bitirip oturumu kapattığında.

İzleme, sistemdeki saldırıları algılamaya yardımcı olabilir. Örneğin, çok sayıda başarısız oturum açma denemesi bir brute force saldırısına işaret edebilir. İsteklerde beklenmeyen bir artış, dağıtılmış bir hizmet reddi (DDoS) saldırısının sonucu olabilir. Bu isteklerin kaynağından bağımsız olarak tüm kaynaklara yönelik tüm istekleri izlemeye hazırlıklı olmanız gerekir. Oturum açma güvenlik açığı olan bir sistem, bir kullanıcının gerçekten oturum açmasına gerek kalmadan kaynakları yanlışlıkla dış dünyaya açıklayabilir.

Güvenlik izleme gereksinimleri

Güvenlik izlemenin en kritik unsurları, bir operatörün hızla gerçekleştirebilmesini sağlamalıdır.

• Kimliği doğrulanmamış bir varlık tarafından yetkisiz erişim girişimini algılayın.
• Yetkisi olmayan varlıkların verilere erişim sağlamak için girişimlerini belirleyin.
• Sistemin veya sistemin bir bölümünün dışarıdan mı yoksa içeriden mi saldırı altında olduğunu belirleyin. Örneğin, kimliği doğrulanmış kötü amaçlı bir kullanıcı sistemi çökertmeye çalışabilir.

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.

Bir operatör için sağlanan bilgiler, her istek için kaynağın ana bilgisayar adresini içermelidir. Belirli bir adres aralığından düzenli olarak güvenlik ihlalleri meydana gelirse, bu ana bilgisayarlar engellenebilir.

Sistemin güvenliğini korumanın önemli bir parçası, her zamanki desenden sapan eylemleri hızlı bir şekilde algılayabilmektir. 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ğin bir örneği, kullanıcıların 03:00'te oturum açması ve çalışma günü 09:00'da başladığında çok sayıda işlem gerçekleştirmesidir.

Bu bilgiler, zamana bağlı otomatik ölçeklendirmeyi yapılandırmaya yardımcı olmak için de kullanılabilir. Örneğin, bir operatör, günün belirli bir saatinde çok sayıda kullanıcının düzenli olarak oturum açtığını gözlemler ise, operatör iş yükünü karşılamak için ek kimlik doğrulama hizmetleri başlatabilir ve tepe noktası geçtikten sonra bu ek hizmetleri kapatabilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Güvenlik, çoğu dağıtılmış sistemi kapsayan bir özelliktir. Uygun veriler büyük olasılıkla sistem genelinde birden çok noktada oluşturulmalıdır. Uygulama, ağ donanımı, sunucular, güvenlik duvarları, virüsten koruma yazılımları ve diğer yetkisiz erişim önleme öğeleri tarafından ortaya çıkarılan olaylardan kaynaklanan güvenlikle ilgili bilgileri toplamak için Güvenlik Bilgileri ve Olay Yönetimi (SIEM) yaklaşımını benimsemeyi düşünmelisiniz.

Güvenlik izleme, uygulamanızın parçası olmayan araçlardan veri içerebilir. Bu araçlar, dış kurumlar tarafından yapılan bağlantı noktası tarama etkinliklerini tanımlayan yardımcı programları veya uygulamanıza ve verilerinize kimliği doğrulanmamış erişim elde etme girişimlerini algılayan ağ filtrelerini içerebilir. Bazı durumlarda, CI/CD dağıtım araçları da uygulama yaşam döngüsünün önemli bir parçasını oluşturur ve bu araçların anormal davranışları da işaretlemesi gerekir.

Her durumda, toplanan veriler bir yöneticinin herhangi bir saldırının doğasını belirlemesine ve uygun önlemleri almasına olanak sağlamalıdır.

Güvenlik verilerini çözümleme

Güvenlik izlemenin temel özelliklerinden biri, birçok kaynaktan veri toplamasıdır. Farklı biçimler ve ayrıntı düzeyi genellikle yakalanan verilerin karmaşık bir şekilde analiz ederek bunları tutarlı bir bilgi dizisine bağlamasını gerektirir. Temel durumlar (birçok başarısız oturum açma işleminin algılanması veya kritik kaynaklara yetkisiz erişim elde etme girişimlerinin tekrarlanması gibi) dışında, güvenlik verilerinin karmaşık otomatik olarak işlenmesi 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

Ödeme yapan müşterileri destekleyen birçok ticari sistem, sistemin performansı hakkında SLA biçiminde taahhütlerde bulunur. Temel olarak, SLA'lar sistemin belirlenen bir iş hacmini üzerinde anlaşmaya varılan bir zaman dilimi içinde ve kritik bilgileri kaybetmeden işleyebileceğini belirtir. SLA izleme, sistemin ölçülebilir SLA'ları karşılayabilmesini sağlamakla ilgilidir.

Uyarı

SLA izleme, performans izleme ile yakından ilgilidir. Ancak performans izleme, sistemin en iyi şekilde çalışmasını sağlamakla ilgilenirken, SLA izleme, en uygun şekilde gerçekte ne anlama geldiğini tanımlayan sözleşme yükümlülüğüne tabidir.

SLA'lar genellikle şu terimlerle tanımlanır:

• Genel sistem kullanılabilirliği. Örneğin, bir kuruluş sistemin yüzde 99,9 oranında kullanılabilir olduğunu taahhüt edebilir. Bu, yılda en fazla 9 saat veya haftada yaklaşık 10 dakika kapalı kalma süresine eşittir.
• İşletimsel aktarım hızı. Bu özellik, genellikle sistemin 100.000'e kadar eşzamanlı kullanıcı isteğini destekleyebileceğine veya 10.000 eşzamanlı iş işlemini gerçekleştirebileceğine dair taahhüt gibi bir veya birden fazla kapasite sınırı olarak ifade edilir.
• İşletimsel yanıt süresi. Sistem, isteklerin işlenme hızı için de taahhütlerde bulunabilir. Örnek olarak tüm iş işlemlerinin yüzde 99'u iki saniye içinde tamamlanır ve tek bir işlem 10 saniyeden uzun sürmez.

Uyarı

Ticari sistemlere yönelik bazı sözleşmeler müşteri desteği için SLA'ları da içerebilir. Örnek olarak, tüm yardım masası istekleri beş dakika içinde yanıt alabilir ve tüm sorunların yüzde 99'u bir iş günü içinde tamamen giderilir. Etkili sorun izleme (bu bölümde daha ayrıntılı olarak açıklanmaktadır), bu tür SLA'ların karşılanması için anahtardır.

SLA izleme gereksinimleri

En yüksek düzeyde, bir operatör sistemin üzerinde anlaşmaya varılan SLA'ları karşılayıp karşılamadığını bir bakışta saptayabilmelidir. Aksi takdirde işleç, standart dışı performansın nedenlerini belirlemek için detaya gidebilir ve temel faktörleri inceleyebilmelidir.

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

• Hizmet çalışabilirlik 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ının, özel durumlarının ve uyarılarının sayısı.

Bu göstergelerin tümü belirli bir süreye göre filtrelenebilir olmalıdır.

Bulut uygulaması büyük olasılıkla birden çok alt sistem ve bileşenden oluşur. Operatör üst düzey bir gösterge seçebilmeli ve temel öğelerin sağlık durumuna bağlı olarak nasıl oluştuğunu görebilmelidir. Örneğin, genel sistemin çalışma süresi kabul edilebilir bir değerin altına düşerse, operatörün bu hataya katkıda bulunan öğeleri yakınlaştırabilmesi ve belirleyebilmesi gerekir.

Uyarı

Sistem çalışma süresinin dikkatli bir şekilde tanımlanması gerekir. Maksimum kullanılabilirliği sağlamak için yedeklilik kullanan bir sistemde, öğelerin tek tek örnekleri başarısız olabilir, ancak sistem işlevsel kalabilir. Sağlık izleme tarafından sunulan sistem çalışma süresi, her bir öğenin toplam çalışma süresini göstermeli ve sistemin gerçekten durup durmadığını belirtmesi gerekmemelidir. Ayrıca, hatalar izole edilmiş olabilir. Bu nedenle, belirli bir sistem kullanılamıyor olsa bile, sistemin geri kalanı kullanılabilir durumda kalabilir, ancak işlevsellik azalmış olabilir. Bir e-ticaret sisteminde, sistemdeki bir hata müşterinin sipariş vermesini engelleyebilir, ancak müşteri yine de ürün kataloğuna göz atabilir.

Uyarı amacıyla, üst düzey göstergelerden herhangi biri belirtilen eşiği aşarsa sistem bir olay oluşturabilmelidir. Üst düzey göstergeyi oluşturan çeşitli faktörlerin alt düzey ayrıntıları, uyarı sistemi için bağlamsal veriler olarak kullanılabilir olmalıdır.

Veri kaynakları, izleme ve veri toplama gereksinimleri

SLA izlemeyi desteklemek için gereken ham veriler, sistem durumu ve kullanılabilirlik izlemesinin bazı yönleriyle birlikte performans izleme için gereken ham verilere benzer. Daha fazla bilgi için bu bölümlere bakın. Bu verileri şu şekilde yakalayabilirsiniz:

• Uç nokta izleme gerçekleştirme.
• Özel durumları, hataları ve uyarıları günlüğe kaydetme.
• Kullanıcı isteklerinin yürütülmesini izleme.
• Sistemin kullandığı üçüncü taraf hizmetlerin kullanılabilirliğini izleme.
• Performans ölçümlerini ve sayaçlarını kullanma.

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

SLA verilerini çözümleme

Sistemin genel performansının bir resmini oluşturmak için izleme verilerinin toplanması gerekir. Toplanan verilerin, temel alınan alt sistemlerin performansının incelenmesini sağlamak için detaya gitmeyi de desteklemesi gerekir. Örneğin şunları yapabilmeniz gerekir:

• Belirtilen süre boyunca kullanıcı isteklerinin toplam sayısını hesaplayın ve bu isteklerin başarı ve başarısızlık oranını belirleyin.
• Sistem yanıt sürelerinin genel bir görünümünü oluşturmak için kullanıcı isteklerinin yanıt sürelerini birleştirin.
• Bir isteğin genel yanıt süresini, istekteki tek tek iş öğelerinin yanıt sürelerine bölmek için kullanıcı isteklerinin ilerleme durumunu analiz edin.
• Sistemin genel kullanılabilirliğini belirli bir dönem için çalışma süresi yüzdesi olarak belirleyin.
• Sistemdeki tek tek bileşenlerin ve hizmetlerin kullanılabilirlik yüzdesini analiz edin. Bu, üçüncü taraf hizmetlerin oluşturduğu günlüklerin ayrıştırılmasını içerebilir.

Birçok ticari sistemin, belirli bir süre boyunca (genellikle bir ay) üzerinde anlaşmaya varılan SLA'lara karşı gerçek performans rakamlarını raporlaması gerekir. Bu bilgiler, SLA'lar bu dönemde karşılanmazsa müşterilerin kredilerini veya diğer geri ödeme biçimlerini hesaplamak için kullanılabilir. Kullanılabilirlik verilerini çözümleme bölümünde açıklanan tekniği kullanarak bir hizmetin kullanılabilirliğini hesaplayabilirsiniz.

Kuruluş, iç amaçlar doğrultusunda hizmetlerin başarısız olmasına neden olan olayların sayısını ve doğasını da izleyebilir. Bu sorunları hızla çözmeyi veya tamamen ortadan kaldırmayı öğrenmek, kapalı kalma süresini azaltmaya ve SLA'ları karşılamaya yardımcı olur.

Denetim

Uygulamanın niteliğine bağlı olarak, kullanıcıların işlemlerini denetleme ve tüm veri erişimini kaydetme gereksinimlerini belirten yasal veya diğer 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

Bir analistin, kullanıcıların eylemlerini yeniden oluşturabilmeniz için kullanıcıların gerçekleştirdiği iş işlemlerinin sırasını izleyebilmesi gerekir. Bu kayıt, belgeleme amacıyla veya adli araştırmanın bir parçası olarak gerekli olabilir.

Denetim bilgileri son derece hassastır. Büyük olasılıkla, sistem kullanıcılarını ve gerçekleştirdikleri görevleri tanımlayan verileri içerir. Bu nedenle, denetim bilgileri büyük olasılıkla grafik işlemlerin detayına gitmeyi destekleyen etkileşimli bir sistem yerine yalnızca güvenilen analistlerin kullanımına sunulan raporlar biçimindedir. Bir analistin bir dizi rapor oluşturabilmesi gerekir. Örneğin, raporlar belirli bir zaman diliminde gerçekleşen tüm kullanıcıların etkinliklerini listeleyebilir, tek bir kullanıcının etkinlik kronolojisini ayrıntılı olarak gösterebilir veya bir veya daha fazla kaynakta gerçekleştirilen işlemlerin sırasını listeleyebilirsiniz.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Denetim için birincil bilgi kaynakları şunlar olabilir:

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

Denetim verilerinin biçimi ve depolanma şekli mevzuat gereksinimleri tarafından yönlendirilebilir. Düzenlemeler, verilerin özgün biçiminde kaydedilmesini gerektiriyorsa, verilerin hiçbir şekilde temizlenmesi mümkün olmayabilir. Bu yüzden, manipülasyonu önlemek için deponun erişimi sıkı bir şekilde korunmalıdır.

Denetim verilerini çözümleme

Bir analistin ham verilere özgün biçiminde tamamen erişebilmesi gerekir. Ortak denetim raporları oluşturma gereksiniminin yanı sıra, bu verileri analiz etme araçları büyük olasılıkla özelleştirilebilir ve sistemin dışında tutulmalıdır.

Kullanım izleme

Kullanım izleme, bir uygulamanın özelliklerinin ve bileşenlerinin nasıl kullanıldığını izler. Bir operatör, toplanan verileri kullanarak:

• Hangi özelliklerin yoğun kullanıldığını belirleyin ve sistemdeki olası etkin noktaları belirleyin. Yüksek trafikli öğeler, yükü daha eşit bir şekilde yaymak için işlevsel bölümleme ve hatta çoğaltmadan yararlanabilir. Operatör bu bilgileri, hangi özelliklerin seyrek kullanıldığını ve sistemin gelecekteki bir sürümünde kullanımdan kaldırılması veya değiştirilmesi için olası adaylar olduğunu belirlemek için de kullanabilir.

• Sistemin normal kullanımdaki operasyonel olayları hakkında bilgi edinin. Örneğin, bir e-ticaret sitesinde, işlem sayısı ve bunlardan sorumlu olan müşterilerin hacmi hakkındaki istatistiksel bilgileri kaydedebilirsiniz. Bu bilgiler, müşteri sayısı arttıkça kapasite planlaması için kullanılabilir.

• Sistemin performansından veya işlevselliğinden kullanıcı memnuniyetini (muhtemelen dolaylı olarak) algılayın. Örneğin, bir e-ticaret sistemindeki çok sayıda müşteri alışveriş sepetlerini düzenli olarak terk ederse, bunun nedeni ödeme işleviyle ilgili bir sorun olabilir.

• Faturalama bilgileri oluşturun. Ticari bir uygulama veya çok kiracılı hizmet, müşterilerin kullandıkları kaynaklar için ücret alabilir.

• Kotaları zorunlu kılma. Çok kiracılı bir sistemdeki bir kullanıcı, belirtilen süre boyunca ü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.

• Gürültülü komşu sorunlarını algılama. Trafiğin eşit bir şekilde dağılıp dağılmadığını veya küçük bir kullanıcı grubunun trafiğin çoğunu oluşturup oluşturmadığını belirleyebilmek, hata araştırmalarını yönlendirebilir veya ürün kararlarına yardımcı olabilir. Uygulama özelliğini kullanan tek kullanıcı tek kullanıcıysa ve bu da büyük miktarda trafik oluşturuyorsa bu, özelliğin biraz performans ayarlaması gerektiği anlamına gelebilir. Alternatif olarak, sorunu çözmek için ek kotalar uygulamaya karar vekleyebilirsiniz.

Kullanım izleme gereksinimleri

Bir operatörün sistem kullanımını incelemek için genellikle şunları içeren 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 kullandığı veri depolama miktarı.
• Her kullanıcının eriştiği kaynaklar.

Bir işleç de graf oluşturabilmelidir. Oluşturulan graflara örnek olarak en çok kaynak kullanan kullanıcıları ve en sık erişilen kaynakları veya sistem özelliklerini gösteren bir grafik verilebilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Kullanım izleme, nispeten yüksek düzeyde gerçekleştirilebilir. Her isteğin başlangıç ve bitiş saatlerini ve isteğin niteliğini (söz konusu kaynağa bağlı olarak okuma, yazma ve diğer istekler) not alabilir. Bu bilgileri şu şekilde edinebilirsiniz:

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

Ö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. Toplanan bilgiler doğru faturalamayı etkinleştirecek kadar ayrıntılı olmalıdır.

Sorun izleme

Sistemde beklenmeyen olaylar veya davranışlar oluşursa müşteriler ve diğer kullanıcılar sorun bildirebilir. Sorun izleme, bu sorunları yönetmek, bunları sistemdeki temel sorunları çözmeye yönelik çabalarla ilişkilendirmek ve müşterileri olası çözümler hakkında bilgilendirmekle ilgilidir.

Sorun izleme gereksinimleri

Operatörler genellikle kullanıcıların bildirdiği sorunların ayrıntılarını kaydetmelerine ve raporlamalarına olanak tanıyan ayrı bir sistem kullanarak sorun izleme gerçekleştirir. Bu ayrıntılar kullanıcının gerçekleştirmeye çalıştığı görevleri, sorunun belirtilerini, olayların sırasını ve verilen hata veya uyarı iletilerini içerebilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sorun izleme verilerinin ilk veri kaynağı, sorunu ilk olarak 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ışan bir bileşen içeriyorsa).
• Ekran anlık görüntüsü.
• Hatanın oluştuğu tarih ve saat, kullanıcının konumu gibi diğer ortam bilgileriyle birlikte.

Bu bilgiler, hata ayıklama çabalarına yardımcı olmak ve yazılımın gelecekteki sürümleri için bir bekleme listesi oluşturmak amacıyla kullanılabilir.

Sorun izleme verilerini çözümleme

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

Hata ayıklama çalışmasının ilerleme durumu her sorun raporuna göre kaydedilmelidir. Sorun çözüldüğünde müşteri çözümden haberdar edilebilir.

Kullanıcı sorun izleme sisteminde bilinen bir çözümü olan bir sorun bildirirse, operatör kullanıcıyı çözümü hemen bilgilendirebilmelidir.

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

Bir kullanıcı bir sorun bildirdiğinde, kullanıcı genellikle yalnızca işlemleri üzerindeki hemen etkisinin farkında olur. Kullanıcı yalnızca kendi deneyiminin sonuçlarını sistemin bakımını yapmakla sorumlu olan bir operatöre bildirebilir. Bu deneyimler genellikle bir veya daha fazla temel sorunun görünür bir belirtisidir. Çoğu durumda, bir analistin sorunun kök nedenini oluşturmak için temel işlemlerin kronolojisini incelemesi gerekir. Bu işleme kök neden analizi adı verilir.

Uyarı

Kök neden analizi, bir uygulamanın tasarımındaki verimsizlikleri ortaya çıkartabilir. Bu gibi durumlarda, etkilenen öğelerin yeniden çalışması ve sonraki bir sürüm kapsamında dağıtılması mümkün olabilir. Bu işlem dikkatli bir denetim gerektirir ve güncelleştirilmiş bileşenler yakından izlenmelidir.

İzleme ve hata ayıklama gereksinimleri

Beklenmeyen olayları ve diğer sorunları izlemek için izleme verilerinin bir analistin bu sorunların çıkış noktalarını izlemesine ve oluşan olayların sırasını yeniden oluşturmasına olanak tanıyacak kadar bilgi sağlaması çok önemlidir. Bu bilgiler, analistin herhangi bir sorunun kök nedenini tanılamasını sağlamak için yeterli olmalıdır. Daha sonra bir geliştirici, yinelenenleri önlemek için gerekli değişiklikleri yapabilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sorun giderme, bir müşteri belirli bir istekte bulunduğunda sistemdeki mantıksal akışı gösteren bir ağaç oluşturmak için bir işlemin parçası olarak çağrılan tüm yöntemlerin (ve parametrelerinin) izlemeyi içerebilir. Sistemin bu akışın sonucu olarak oluşturduğu özel durumlar ve uyarıların yakalanması ve günlüğe kaydedilmesi gerekir.

Sistem, hata ayıklamayı desteklemek için operatörün sistemdeki önemli noktalarda durum bilgilerini yakalamasını sağlayan kancalar sağlayabilir. Alternatif olarak, seçilen işlemler ilerledikçe sistem ayrıntılı adım adım bilgi sağlayabilir. Verileri bu ayrıntı düzeyinde yakalamak sisteme ek yük oluşturabilir ve geçici bir işlem olmalıdır. tr-TR: Operatör, bu süreci özellikle, son derece sıra dışı bir dizi olay meydana geldiğinde ve tekrar etmesi zor olduğunda ya da bir veya birden fazla öğenin sisteme yeni bir sürümü dahil edildiğinde ve bu öğelerin beklendiği gibi çalıştığından emin olmak için dikkatli bir şekilde izlenmesi gerektiğinde 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 senaryoların her biri yalıtılmış olarak düşünülmemelidir. Her durum için gerekli olan izleme ve tanılama verilerinde büyük olasılıkla önemli bir çakışma olabilir, ancak bu verilerin farklı şekillerde işlenmesi ve sunulması gerekebilir. Bu nedenlerden dolayı izleme ve tanılamanın bütünsel bir görünümünü almalısınız.

İzleme ve tanılama işleminin tamamını Şekil 1'de gösterilen aşamaları oluşturan bir işlem hattı olarak öngörebilirsiniz.

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

Şekil 1'de izleme ve tanılama verilerinin çeşitli veri kaynaklarından nasıl alınabileceği vurgulanır. İzleme ve toplama aşamaları, verilerin yakalanması gereken kaynakları belirleme, hangi verilerin yakalanacağı, nasıl yakalanacağı ve kolayca incelenebilmesi için bu verilerin nasıl biçimlendirileceğiyle ilgilidir. Analiz/tanılama aşaması ham verileri alır ve bir operatörün sistemin durumunu belirlemek için kullanabileceği anlamlı bilgiler oluşturmak için kullanır. operatör, bu bilgileri, alınacak olası eylemler hakkında kararlar almak ve ardından sonuçları izleme ve toplama aşamalarına geri beslemek için kullanabilir. Görselleştirme/uyarı aşaması aşaması, sistem durumunun kullanılabilir bir görünümünü sunar. Bir dizi pano kullanarak bilgileri neredeyse gerçek zamanlı olarak görüntüleyebilir. Ayrıca, uzun vadeli eğilimleri belirlemeye yardımcı olabilecek verilerin geçmiş görünümünü sağlamak için raporlar, grafikler ve grafikler oluşturabilir. Bilgiler bir KPI'nın kabul edilebilir sınırları aşma olasılığını gösterirse, bu aşama bir operatör için uyarı da tetikleyebilir. Bazı durumlarda, otomatik ölçeklendirme gibi düzeltici eylemler gerçekleştirmeye çalışan otomatik bir işlemi tetikleyen bir uyarı da kullanılabilir.

Bu adımlar, aşamaların paralel olarak gerçekleştiği bir sürekli akış süreci oluşturur. İdeal olan, tüm aşamaların dinamik olarak yapılandırılabilir olmasıdır. Bazı noktalarda, özellikle bir sistem yeni dağıtıldığında veya sorunlarla karşılaştığında, genişletilmiş verilerin daha sık toplanması gerekebilir. Diğer durumlarda, sistemin düzgün çalıştığını doğrulamak için temel düzeyde temel bilgileri yakalamaya geri dönmek mümkün olmalıdır.

Buna ek olarak, tüm izleme süreci, geri bildirim sonucunda ince ayar ve iyileştirmelere tabi canlı ve sürekli bir çözüm olarak kabul edilmelidir. Örneğin, sistem durumunu belirlemek için birçok faktörü ölçmekle başlayabilirsiniz. Zaman içinde analiz, ilgili olmayan ölçüleri atarken iyileştirmeye yol açabilir ve arka plan gürültüsünü en aza indirirken ihtiyacınız olan verilere daha hassas bir şekilde odaklanmanızı sağlar.

İ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, sistemin koduna dahil edilen izleme günlüklerinden gelir. Geliştiriciler, kodlarında denetim akışını izlemek için standart bir yaklaşım izlemelidir. Örneğin, bir yönteme giriş yöntemin adını, geçerli saati, her parametrenin değerini ve diğer ilgili bilgileri belirten bir izleme iletisi yayar. Giriş ve çıkış saatlerinin kaydedilmesi de yararlı olabilir.

Tüm istisnaları ve uyarıları günlüğe kaydetmeli ve iç içe geçmiş istisnaların ve uyarıların tam izini muhafaza ettiğinizden emin olmalısınız. İdeal olarak, etkinlik bağıntı bilgileriyle birlikte (istekleri sistemden geçerken izlemek için) kodu çalıştıran kullanıcıyı tanımlayan bilgileri de yakalamanız gerekir. Ayrıca ileti kuyrukları, veritabanları, dosyalar ve diğer bağımlı hizmetler gibi tüm kaynaklara erişme girişimlerini günlüğe kaydetmeniz gerekir. Bu bilgiler ölçüm ve denetim amacı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 işlem hızları ile veri iletim başarıları ve hataları gibi ham tanılama bilgilerini sağlamak için yapılandırılabilir.

Uyarı

Birçok modern çerçeve, performans ve izleme olaylarını otomatik olarak yayımlar. Bu bilgilerin yakalanması, olayları almak ve depolamak için bir yol sağlayarak bunların işlenip analiz edilebilmesini sağlar.

Uygulamanın çalıştığı işletim sistemi G/Ç hızlarını, bellek kullanımını ve CPU kullanımını gösteren performans sayaçları gibi düşük düzey sistem genelindeki bilgilerin kaynağı olabilir. İşletim sistemi hataları (örneğin, bir dosyayı doğru açma hatası) da bildirilebilir.

Ayrıca, sisteminizin üzerinde çalıştığı temel altyapıyı ve bileşenleri de göz önünde bulundurmalısınız. Sanal makineler, sanal ağlar ve depolama hizmetlerinin tümü altyapı düzeyindeki önemli performans sayaçlarının ve diğer tanılama verilerinin kaynakları olabilir.

Uygulamanız web sunucusu veya veritabanı yönetim sistemi gibi diğer dış hizmetleri kullanıyorsa, bu hizmetler kendi izleme bilgilerini, günlüklerini ve performans sayaçlarını yayımlayabilir. Örnek olarak SQL Server veritabanında gerçekleştirilen işlemleri izlemeye yönelik SQL Server Dinamik Yönetim Görünümleri ve Azure App Service'e yapılan istekleri kaydetmek için Application Insights izleme günlükleri verilebilir.

Bir sistemin bileşenleri değiştirilip yeni sürümler dağıtıldığından, sorunları, olayları ve ölçümleri her sürüme özniteliklendirebilmek önemlidir. Bu bilgiler, bir bileşenin belirli bir sürümüyle ilgili sorunların hızla izlenebilmesi ve düzeltilmesi için yayın işlem hattına geri bağlanmalıdır.

Güvenlik sorunları sistemin herhangi bir noktasında oluşabilir. Örneğin, bir kullanıcı geçersiz bir 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. Veya bir kullanıcı şifrelenmiş bilgilere erişmek için geçersiz veya güncel olmayan bir anahtar sağlayabilir. Başarılı ve başarısız istekler için güvenlikle ilgili bilgiler her zaman günlüğe kaydedilmelidir.

Bir uygulamayı izleme bölümü, yakalamanız gereken bilgiler hakkında daha fazla kılavuz içerir. Ancak bu bilgileri toplamak için çeşitli stratejiler kullanabilirsiniz:

• Uygulama/sistem izleme. Bu strateji uygulama, uygulama çerçeveleri, işletim sistemi ve altyapı içindeki iç kaynakları kullanır. Uygulama kodu, bir istemci isteğinin yaşam döngüsü sırasında dikkate değer noktalarda kendi izleme verilerini oluşturabilir. Uygulama, koşullar gerektirdiğinde seçmeli olarak etkinleştirilebilen veya devre dışı bırakılmış olabilecek izleme deyimleri içerebilir. Tanılama çerçevesini kullanarak tanılamayı dinamik olarak eklemek de mümkün olabilir. Bu çerçeveler genellikle kodunuzdaki çeşitli izleme noktalarına eklenebilen ve bu noktalarda izleme verilerini yakalayabilen eklentiler sağlar.

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

• Gerçek kullanıcı izleme. Bu yaklaşım, kullanıcı ve uygulama arasındaki etkileşimleri kaydeder ve her isteğin ve yanıtın akışını gözlemler. Bu bilgilerin iki katlı bir amacı olabilir: Her kullanıcı tarafından kullanım ölçümü için kullanılabilir ve kullanıcıların uygun bir hizmet kalitesi (örneğin, hızlı yanıt süreleri, düşük gecikme süresi ve en düşük hatalar) alıp almadığını belirlemek için kullanılabilir. Yakalanan verileri, hataların en sık oluştuğu sorunları belirlemek için kullanabilirsiniz. Ayrıca, büyük olasılıkla uygulamadaki etkin noktalardan veya başka bir performans sorunundan dolayı sistemin yavaşladığı öğeleri tanımlamak için de verileri kullanabilirsiniz. Bu yaklaşımı dikkatli bir şekilde uygularsanız, hata ayıklama ve test amacıyla uygulama üzerinden kullanıcı akışlarını yeniden yapılandırmak mümkün olabilir.

  Önemli

  Gerçek kullanıcıların izlenmesiyle yakalanan verilerin gizli malzeme içerebileceğinden yüksek oranda hassas olduğunu göz önünde bulundurmalısınız. Yakalanan verileri kaydederseniz güvenli bir şekilde depolayı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 simülasyonunu yapan ve yapılandırılabilir ancak tipik bir işlem serisi gerçekleştiren kendi test istemcinizi yazarsınız. Sistemin durumunu belirlemeye yardımcı olması için test istemcisinin performansını izleyebilirsiniz. Sistemin stres altında nasıl yanıt verdiğini ve bu koşullar altında ne tür bir izleme çıkışı oluşturulduğunu oluşturmak için yük testi işleminin bir parçası olarak test istemcisinin birden çok örneğini de kullanabilirsiniz.

  Uyarı

  Bir uygulamanın yöntem çağrılarını ve diğer kritik bölümlerini izleyen ve zamanlayan kod ekleyerek gerçek ve yapay kullanıcı izleme uygulayabilirsiniz.

• Profil oluşturma. Bu yaklaşım öncelikli olarak uygulama performansını izlemeyi ve geliştirmeyi hedefler. Gerçek ve yapay kullanıcı izlemenin işlevsel düzeyinde çalışmaktansa, uygulama çalışırken alt düzey bilgileri yakalar. Bir uygulamanın yürütme durumunun düzenli örneklemesini kullanarak profil oluşturma uygulayabilirsiniz (uygulamanın belirli bir zamanda hangi kod parçasını çalıştırdığını belirleme). Ayrıca önemli noktalarda (yöntem çağrısının başlangıcı ve sonu gibi) koda yoklamalar ekleyen ve hangi yöntemlerin çağrıldığı, ne zaman ve her çağrının ne kadar sürdüğünü kaydeden izleme özelliğini de kullanabilirsiniz. Ardından, uygulamanın hangi bölümlerinin performans sorunlarına neden olabileceğini belirlemek için bu verileri analiz edebilirsiniz.

• Uç nokta izleme. Bu teknik, uygulamanın izlemeyi etkinleştirmek için özel olarak kullanıma sağladığı bir veya daha fazla tanılama uç noktasını kullanır. Uç nokta, uygulama koduna bir yol sağlar ve sistemin durumu hakkında bilgi döndürebilir. Farklı uç noktalar işlevselliğin çeşitli yönlerine odaklanabilir. Bu uç noktalara düzenli aralıklarla istek gönderen ve yanıtları asimile eden kendi tanılama istemcinizi yazabilirsiniz. Daha fazla bilgi için bkz. Sağlık Uç Noktası İzleme deseni.

• Kullanıcı hata dökümleri. Bu teknik, bir uygulamanın kurtarılamadığı durumlarda uygulama durumunun bir anlık görüntüsünü toplamaya ve kullanıcıların bu anlık görüntüyü gönüllü olarak paylaşmasına düzgün bir yol sağlamaya dayanır. Her zaman çalıştırılması garanti edilmese de, hata dökümü tarafından sağlanan alt düzey veriler, hataların kök nedenini belirlemek için son derece yararlı olabilir. Bu, özellikle söz konusu hataların seyrek gerçekleşmesi veya hataların uygulamada yaygın olarak kullanılan bir özelliğe yalıtılmış olması durumunda geçerlidir.

Maksimum kapsam için bu tekniklerin bir bileşimini kullanmanız gerekir.

Uygulamayı araçlarla donatma

Enstrümantasyon, izleme sürecinin kritik bir parçasıdır. Bir sistemin performansı ve durumu hakkında anlamlı kararlar almak için bu kararları vermenizi sağlayan verileri ilk kez yakalamanız gerekir. Enstrümantasyon kullanarak topladığınız bilgiler, uzaktan üretim sunucusuna giriş yaparak manuel izleme (ve hata ayıklama) yapmanıza gerek kalmadan, performansı değerlendirebilmenizi, sorunları teşhis edebilmenizi ve kararlar alabilmenizi sağlamak için yeterli olmalıdır. Enstrümantasyon verileri, genellikle 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. Ayrıca, altyapının web sunucusu gibi bölümlerinden kaynaklanan olayları kaydeden sistem günlüklerinden de oluşturulabilirler. Metin günlüğü iletileri genellikle insan tarafından okunabilir olacak şekilde tasarlanmıştır, ancak otomatik bir sistemin bunları kolayca ayrıştırmasını sağlayan bir biçimde de yazılmalıdır.

Günlükleri de kategorilere ayırmanız gerekir. Tüm izleme verilerini tek bir günlüğe yazmayın, ancak izleme çıkışını sistemin farklı işletimsel yönlerinden kaydetmek için ayrı günlükler kullanın. Daha sonra, tek bir uzun dosyayı işlemek yerine uygun günlükten okuyarak günlük iletilerini hızla filtreleyebilirsiniz. Farklı güvenlik gereksinimleri (denetim bilgileri ve hata ayıklama verileri gibi) olan bilgileri hiçbir zaman aynı günlüğe yazmayın.

Uyarı

Günlük, dosya sisteminde dosya olarak gerçekleştirilebilir veya blob depolamadaki blob gibi farklı bir biçimde tutulabilir. Günlük bilgileri, tablodaki satırlar gibi daha yapılandırılmış bir depolama alanında da tutulabilir.

Ölçümler genellikle bir veya daha fazla ilişkili etiket veya boyutla (bazen örnek olarak da adlandırılır) belirli bir zamanda sistemdeki bazı yön veya kaynakların ölçüsü veya sayısıdır. Bir ölçümün tek bir örneği genellikle yalıtımlı olarak yararlı olmaz. Bunun yerine ölçümlerin zaman içinde yakalanması gerekir. Dikkate alınması gereken temel sorun, hangi ölçümleri ve ne sıklıkta kaydetmeniz gerektiğidir. Ölçümler için verilerin çok sık oluşturulması sisteme önemli bir ek yük oluşturabilirken, ölçümleri nadiren yakalamak önemli bir olaya neden olan koşulları kaçırmanıza neden olabilir. Dikkat edilmesi gerekenler ölçümden ölçüme farklılık gösterir. Örneğin, bir sunucudaki CPU kullanımı saniyeden saniyeye dalgalanabilir, ancak yüksek kullanım yalnızca birkaç dakika devam ederse sorun haline gelir.

Verileri ilişkilendirmeye yönelik bilgiler

Sistem düzeyindeki performans sayaçlarını kolayca izleyebilir, kaynaklar için ölçümleri yakalayabilir ve çeşitli günlük dosyalarından uygulama izleme bilgilerini alabilirsiniz. Ancak bazı izleme biçimleri, çeşitli kaynaklardan alınan verileri ilişkilendirmek için izleme işlem hattındaki analiz ve tanılama aşamasını gerektirir. Bu veriler ham verilerde çeşitli formlar alabilir ve analiz işlemine bu farklı formları eşleyebilmek için yeterli izleme verileri sağlanmalıdır. Örneğin, uygulama çerçevesi düzeyinde bir görev iş parçacığı kimliğiyle tanımlanabilir. Bir uygulama içinde aynı çalışma, bu görevi gerçekleştiren kullanıcının kullanıcı kimliğiyle ilişkilendirilebilir.

Ayrıca, zaman uyumsuz işlemler birden fazla kullanıcı adına işlem gerçekleştirmek için aynı iş parçacıklarını yeniden kullanabileceğinden, iş parçacıkları ve kullanıcı istekleri arasında 1:1 eşlemesi olması pek olası değildir. Durumu daha da karmaşıklaştırmak için, tek bir istek, yürütme sistem içinde aktıkça birden fazla iş parçacığı tarafından işlenebilir. Mümkünse, her isteği istek bağlamının bir parçası olarak sistem aracılığıyla yayılan benzersiz bir etkinlik kimliğiyle ilişkilendirin. (İzleme bilgilerine etkinlik kimlikleri oluşturma ve ekleme tekniği, izleme verilerini yakalamak için kullanılan teknolojiye bağlıdır.)

Tüm izleme verileri aynı şekilde zaman damgasına alınmalıdır. Tutarlılık için Eşgüdümlü Evrensel Saat (UTC) kullanarak tüm tarih ve saatleri kaydedin. Bu, olay dizilerini daha kolay izlemenize yardımcı olur.

Uyarı

Farklı saat dilimlerinde ve ağlarda çalışan bilgisayarlar eşitlenmeyebilir. Birden çok makineye yayılan izleme verilerini ilişkilendirmek için yalnızca zaman damgalarını kullanmaya bağımlı değilsiniz.

Enstrümantasyon verilerine eklenecek bilgiler

Hangi izleme verilerini toplamanız gerektiğini belirlerken aşağıdaki noktaları göz önünde bulundurun:

• İzleme olayları tarafından yakalanan bilgilerin makine ve insan tarafından okunabilir olduğundan emin olun. Sistemlerde 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 bilgiler için iyi tanımlanmış şemaları benimseyin. Dağıtım ortamı, işlemin çalıştığı makine, işlemin ayrıntıları ve çağrı yığını gibi ortam bilgilerini ekleyin.

• Profil oluşturmayı yalnızca gerektiğinde etkinleştirin çünkü sistemde önemli bir ek yük oluşturabilir. Araç kullanımı ile profil çıkarma, her gerçekleştiğinde bir olayı (yöntem çağrısı gibi) 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şirse, izleme yoluyla profil oluşturma çok fazla yüke neden olabilir ve genel performansı etkileyebilir. Bu durumda örnekleme yaklaşımı tercih edilebilir. Ancak olayların sıklığı düşükse örnekleme bunları kaçırabilir. Bu durumda araçlandırma daha iyi bir yaklaşım olabilir.

• Bir geliştiricinin veya yöneticinin her isteğin kaynağını belirlemesini sağlamak için yeterli bağlam sağlayın. Bu, bir isteğin belirli bir örneğini tanımlayan bir etkinlik kimliği biçimi içerebilir. Ayrıca, bu etkinliği gerçekleştirilen hesaplama çalışması ve kullanılan kaynaklarla ilişkilendirmek için kullanılabilecek bilgiler de içerebilir. Bu çalışma işlem ve makine sınırlarını aşabilir. Ölçüm için bağlam, isteğin yapılmasına neden olan müşteriye yönelik bir başvuruyu da (doğrudan veya dolaylı olarak diğer bağıntılı bilgiler aracılığıyla) içermelidir. Bu bağlam, izleme verilerinin yakalandığı sırada uygulama durumu hakkında değerli bilgiler sağlar.

• Tüm istekleri ve bu isteklerin yapıldığı konumları veya bölgeleri kaydedin. Bu bilgiler konuma özgü etkin noktaların olup olmadığını belirlemeye yardımcı olabilir. Bu bilgiler, bir uygulamanın mı yoksa kullandığı verilerin mi yeniden bölümlendiğini belirlemede de yararlı olabilir.

• Özel durumların ayrıntılarını dikkatle kaydedin ve yakalayın. Genellikle, kötü özel durum işlemenin bir sonucu olarak kritik hata ayıklama bilgileri kaybolur. İç özel durumlar ve diğer bağlam bilgileri de dahil olmak üzere uygulamanın attığı özel durumların tüm ayrıntılarını yakalayın. Mümkünse çağrı yığınını ekleyin.

• Uygulamanızın farklı öğelerinin yakaladığı verilerde tutarlı olun çünkü bu, olayları analiz etmeye ve bunları kullanıcı istekleriyle ilişkilendirmeye yardımcı olabilir. Geliştiricilerin sistemi farklı şekillerde uygularken aynı yaklaşımı benimsemelerine bağlı kalmak yerine, bilgi toplamak için kapsamlı ve yapılandırılabilir bir günlük paketi kullanmayı düşünün. Gerçekleştirilen G/Ç hacmi, ağ kullanımı, istek sayısı, bellek kullanımı ve CPU kullanımı gibi önemli performans sayaçlarından veri toplayın. Bazı altyapı hizmetleri, bir veritabanına bağlantı sayısı, işlemlerin gerçekleştirilma hızı ve başarılı veya başarısız olan işlem sayısı gibi kendi performans sayaçlarını sağlayabilir. Uygulamalar kendi performans sayaçlarını da tanımlayabilir.

• Veritabanı sistemleri, web hizmetleri veya altyapının parçası olan diğer sistem düzeyindeki hizmetler gibi dış hizmetlere yapılan tüm çağrıları günlüğe kaydedin. Her çağrıyı gerçekleştirmek için geçen süre ve çağrının başarısı veya başarısızlığı hakkındaki bilgileri kaydedin. Mümkünse, meydana gelen geçici hatalarla ilgili tüm yeniden deneme girişimlerini ve hataları hakkındaki bilgileri yakalayın.

Telemetri sistemleriyle uyumluluğu sağlama

Çoğu durumda, izlemenin ürettiği bilgiler bir dizi olay olarak oluşturulur ve işleme ve analiz için ayrı bir telemetri sistemine geçirilir. Telemetri sistemi genellikle belirli bir uygulama veya teknolojiden bağımsızdır, ancak bilgilerin genellikle şema tarafından tanımlanan belirli bir biçimi izlemesini bekler. Şema, telemetri sisteminin alabildiği veri alanlarını ve türlerini tanımlayan bir sözleşmeyi etkili bir şekilde belirtir. Şema, çeşitli platformlardan ve cihazlardan gelen verilere izin verecek şekilde genelleştirilmelidir. Yaygın olarak kullanılan çerçeve ve şemalardan biri OpenTelemetry'dir.

Ortak şema, olay adı, olay zamanı, gönderenin IP adresi ve diğer olaylarla (kullanıcı kimliği, cihaz kimliği ve uygulama kimliği gibi) bağıntı için gereken ayrıntılar gibi tüm izleme olaylarında ortak olan alanları içermelidir. Herhangi bir sayıda cihazın olay oluşturabileceğini, dolayısıyla şemanın cihaz türüne bağlı olmaması gerektiğini unutmayın. Ayrıca, çeşitli cihazlar aynı uygulama için olaylar tetikleyebilir. Uygulama, dolaşım veya diğer bir cihazlar arası dağıtım biçimini destekleyebilir.

Şema, farklı uygulamalarda ortak olan belirli bir senaryoyla ilgili etki alanı alanlarını 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. Aynı etki alanı alanı kümesini kullanan tüm uygulamalar aynı olay kümesini yayarak bir dizi ortak rapor ve analiz oluşturulabilmesini sağlamalıdır.

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

Uygulamaların enstrümantasyonu için en iyi yöntemler

Aşağıdaki listede, bulutta çalışan bir dağıtılmış uygulamayı izlemeye yönelik en iyi yöntemler özetlemektedir.

• Günlükleri okunabilir ve ayrıştırılabilir hale getirin. Mümkün olduğunda yapılandırılmış günlüğe kaydetmeyi kullanın. Günlük iletilerinde kısa ve açıklayıcı olun.

• Tüm günlüklerde kaynağı tanımlayın ve her günlük kaydı yazılırken 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ışan donanım ve hizmetlere yayılan işlemler için olayları ilişkilendirmeye yardımcı olur.

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

• Sistemle ilgili hassas bilgileri veya kullanıcılar hakkındaki kişisel bilgileri ifşa etmeyin. Bu bilgileri günlüğe kaydetmeden önce temizleyin, ancak ilgili ayrıntıların korunduğundan emin olun. Örneğin, herhangi bir veritabanı bağlantı dizesinden kimlik ve parolayı kaldırın, ancak analistin sistemin doğru veritabanına eriştiğini belirleyebilmesi için kalan bilgileri günlüğe yazın. Tüm kritik özel durumları günlüğe kaydedin, ancak yöneticinin daha düşük özel durum ve uyarı düzeyleri için günlüğe kaydetmeyi açıp kapatmasını sağlayın. Ayrıca, tüm yeniden deneme mantığı bilgilerini yakalayın ve günlüğe yazın. Bu veriler, sistemin geçici durumunu izlemede yararlı olabilir.

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

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

• Denetim olayları dışında, tüm günlük çağrılarının iş işlemlerinin ilerleme durumunu engellemeyen tetikleme ve unutma işlemleri olduğundan emin olun. Denetim olayları istisnaidir çünkü bunlar iş için kritik öneme sahiptir ve iş operasyonlarının temel bir parçası olarak sınıflandırılabilir.

• Günlüğün genişletilebilir olduğundan ve somut bir hedefe doğrudan bağımlılıkları olmadığından emin olun. Örneğin, System.Diagnostics.Trace kullanarak bilgi yazmak yerine, ILogger gibi günlükleme yöntemlerine imkan sağlayan ve uygun herhangi bir yöntemle uygulanabilen bir soyut arabirim tanımlayın.

• Tüm günlüklerin güvenli bir şekilde çalıştığından ve asla basamaklı hataları tetiklemediğinden emin olun. Kayıt tutma hiçbir istisna oluşturmamalıdır.

• Enstrümantasyonu sürekli tekrarlanan bir süreç olarak ele alın ve yalnızca sorun olduğunda değil, günlükleri düzenli olarak gözden geçirin.

Veri toplama ve depolama

İzleme işleminin toplama aşaması, izlemenin oluşturduğu bilgilerin alınması, analiz/tanılama aşamasının daha kolay tüketilmesi için bu verileri biçimlendirme ve dönüştürülen verilerin güvenilir depolama alanına kaydedilmesiyle ilgilidir. Dağıtılmış bir sistemin farklı bölümlerinden topladığınız izleme verileri çeşitli konumlarda ve farklı 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ı diğer teknolojiler aracılığıyla yakalanabilir. Uygulamanızın kullandığı tüm üçüncü taraf bileşenler ve hizmetler ayrı izleme dosyaları, blob depolama ve hatta özel bir veri deposu kullanarak izleme bilgilerini farklı biçimlerde sağlayabilir.

Veri toplama genellikle izleme verilerini oluşturan uygulamadan otonom olarak çalışabilen bir toplama hizmeti aracılığıyla gerçekleştirilir. Şekil 2'de bu mimarinin bir örneği gösterilmektedir ve izleme veri toplama alt sistemi vurgulanmaktadır.

Şekil 2 - İzleme verilerini toplama.

Bu basitleştirilmiş bir görünümdür. Koleksiyon hizmetinin tek bir işlem olması şart değildir ve aşağıdaki bölümlerde açıklandığı gibi farklı makinelerde çalışan birçok kurucu parçadan oluşabilir. Ayrıca, bazı telemetri verilerinin hızlı bir şekilde analiz edilmesi gerekiyorsa (bu belgenin devamında Sıcak, ılık ve soğuk analiz desteği bölümünde açıklandığı gibi sıcak analiz), toplama hizmeti 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österilmektedir. Analiz işlemeden sonra sonuçlar doğrudan görselleştirmeye ve uyarı alt sistemine gönderilebilir. Sıcak veya soğuk analize tabi tutulan veriler, işlenmeyi beklerken depolamada tutulur.

Azure uygulamaları ve hizmetleri için Azure Tanılama, veri yakalamaya yönelik olası bir çözüm sağlar. Azure Tanılama, her işlem düğümü için aşağıdaki kaynaklardan verileri 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ı
• Çökme dökümleri
• Azure Tanılama altyapısı günlükleri
• Özel hata günlükleri
• .NET Olay Kaynağı
• Manifesto tabanlı ETW

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

Araç verilerini toplama stratejileri

Bulutun elastik niteliğini göz önünde bulundurarak ve sistemdeki her düğümden telemetri verilerini el ile alma zorunluluğunu önlemek için, verilerin merkezi bir konuma aktarılmasını ve birleştirilmesini düzenlemeniz gerekir. Birden çok veri merkezine yayılan bir sistemde, önce verileri bölgelere göre toplamak, birleştirmek ve depolamak ve ardından bölgesel verileri tek bir merkezi sistemde toplamak yararlı olabilir.

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

Araçsal verileri çekme ve gönderme

İnstrümantasyon veri toplama alt sistemi, her uygulama örneği için çeşitli günlüklerden ve diğer kaynaklardan instrümantasyon verilerini etkin bir şekilde alabilir ( çekme modeli). Alternatif olarak, uygulamanın her örneğini oluşturan bileşenlerden ( gönderim modeli) verilerin gönderilmesini bekleyen pasif bir alıcı gibi davranabilir.

Çekme modelini uygulamaya yönelik bir yaklaşım, uygulamanın her örneğiyle yerel olarak çalışan izleme aracılarını kullanmaktır. İzleme aracısı, yerel düğümde toplanan telemetri verilerini düzenli aralıklarla alan (çeken) ve bu bilgileri doğrudan uygulama örneklerinin paylaştığı merkezi depolama alanına yazan ayrı bir işlemdir. Bu, Azure İzleyici Aracısı'nın uyguladığı mekanizmadır. Her işlem örneği, tanılamayı ve yerel olarak depolanan diğer izleme bilgilerini yakalayacak şekilde yapılandırılabilir. Her örnekle birlikte çalışan izleme aracısı belirtilen verileri toplar ve Azure İzleyici'ye gönderir. IIS günlükleri, kilitlenme dökümleri ve özel hata günlükleri gibi bazı öğeler blob depolamaya yazılır. Windows olay günlüğü, ETW olayları ve performans sayaçlarındaki veriler tablo depolama alanına kaydedilir. Şekil 3'de bu mekanizma gösterilmektedir.

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

Uyarı

İzleme aracısının kullanımı, veri kaynağından doğal olarak çekilen ölçümlü izleme verilerini yakalamaya çok uygundur. Sql Server Dinamik Yönetim Görünümlerindeki bilgiler veya Azure Service Bus kuyruğunun uzunluğu buna örnek olarak verilmiştir.

Sınırlı sayıda düğümde çalışan küçük ölçekli bir uygulamanın telemetri verilerini tek bir konumda depolamak için az önce açıklanan yaklaşımı kullanmak mümkündür. Ancak karmaşık, yüksek oranda ölçeklenebilir, küresel bir bulut uygulaması yüzlerce işlem örneğinden, veritabanı parçalarından ve diğer hizmetlerden çok büyük miktarlarda veri oluşturabilir. Bu veri akışı, tek bir merkezi konumla sağlanan G/Ç bant genişliğini kolayca zorlayabilir. Bu nedenle, sistem genişledikçe performans sorunu olarak davranmasını önlemek için telemetri çözümünüzün ölçeklenebilir olması gerekir. İdeal olarak, sistemin bir parçasının başarısız olması durumunda önemli izleme bilgilerini (denetim veya faturalama verileri gibi) kaybetme risklerini azaltmak için çözümünüz bir derece yedeklilik içermelidir.

Bu sorunları gidermek için, Şekil 4'te gösterildiği gibi kuyruğa alma uygulayabilirsiniz. Bu mimaride, yerel izleme aracısı (uygun şekilde yapılandırılabilirse) veya özel veri toplama hizmeti (değilse) verileri kuyruğa gönderir. Zaman uyumsuz olarak çalışan ayrı bir işlem (Şekil 4'teki depolama yazma hizmeti), bu kuyruktaki verileri alır ve paylaşılan depolama alanına yazar. İleti kuyruğu, kuyruğa alınan verilerin gönderildikten sonra kaybolmamasını sağlamaya yardımcı olan "en az bir kez" semantik sağladığından bu senaryo için uygundur. Ayrı bir arka plan işlemi kullanarak depolama yazma hizmetini uygulayabilirsiniz.

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

Yerel veri toplama hizmeti, alındıktan hemen sonra kuyruğa veri ekleyebilir. Kuyruk bir arabellek görevi görür ve depolama yazma hizmeti verileri kendi hızıyla alıp yazabilir. Varsayılan olarak, kuyruk ilk gelen ilk çıkar temelinde çalışır. Ancak, daha hızlı işlenmesi gereken veriler içeriyorsa, iletileri kuyruk aracılığıyla hızlandırmak için önceliklerini belirtebilirsiniz. Daha fazla bilgi için bkz . Öncelik Sırası düzeni. Alternatif olarak, gerekli analitik işleme biçimine bağlı olarak verileri farklı hedeflere yönlendirmek için farklı kanallar (Service Bus konuları gibi) kullanabilirsiniz.

Ölçeklenebilirlik için depolama yazma hizmetinin birden çok örneğini çalıştırabilirsiniz. Yüksek hacimli olaylar varsa, verileri işleme ve depolama için farklı işlem kaynaklarına göndermek için bir olay hub'ı kullanabilirsiniz.

Enstrümantasyon verilerini birleştirme

Veri toplama hizmetinin bir uygulamanın tek bir örneğinden edindiği izleme verileri, bu örneğin sistem durumu ve performansına ilişkin yerelleştirilmiş bir görünüm sağlar. Sistemin genel durumunu değerlendirmek için verilerin bazı yönlerini yerel görünümlerde birleştirmek gerekir. Veriler depolandıktan sonra bunu gerçekleştirebilirsiniz, ancak bazı durumlarda veriler toplandıktan sonra da bunu gerçekleştirebilirsiniz. İzleme verileri, doğrudan paylaşılan depolamaya yazılmak yerine verileri birleştiren ve filtre ve temizleme işlemi işlevi gören ayrı bir veri birleştirme hizmetinden geçebilir. Örneğin, etkinlik kimliği gibi aynı bağıntı bilgilerini içeren izleme verileri birleştirilebilir. (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'de bu yapıya bir örnek gösterilmiştir.

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

Enstrümantasyon verilerini depolama

Önceki tartışmalarda izleme verilerinin nasıl depolandığına ilişkin oldukça basit bir görünüm gösteriliyordu. Gerçekte, her türün kullanılma olasılığına en uygun teknolojileri kullanarak farklı bilgi türlerini depolamak mantıklı olabilir.

Örneğin, Azure blob ve tablo depolama, erişim yolları açısından bazı benzerliklere sahiptir. Ancak, bunları kullanarak gerçekleştirebileceğiniz işlemlerde sınırlamaları vardır ve bunların barındırdığı 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ükleri Azure Cosmos DB'de daha iyi depolanabilir.
• Güvenlik bilgileri HDFS'ye yazılabilir.
• Tam metin araması gerektiren bilgiler Elasticsearch aracılığıyla depolanabilir (bu da zengin dizin oluşturma kullanarak aramaları hızlandırabilir).

Verileri paylaşılan depolama alanından düzenli aralıklarla alan, verileri amacına göre bölümleyen ve filtreleyen ve ardından Şekil 6'da gösterildiği gibi uygun bir veri deposu 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 hizmeti üzerindeki yükü azaltır ve gerekirse bölümlenmiş verilerin en az bir kısmının yeniden üretilmesini sağlar (paylaşılan depolamada ne kadar veri bulunduğuna bağlı olarak). Ancak, 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. Bu gibi durumlarda, aynı veriler faturalama bilgilerini tutmak için uzun vadeli bir depo olarak davranabilen bir belge veritabanı ve karmaşık performans analizini işlemek için çok boyutlu bir depo gibi birden fazla hedefe gönderilebilir.

Ayrıca verilerin ne kadar acil bir şekilde gerekli olduğunu da göz önünde bulundurmalısınız. Uyarı için bilgi sağlayan verilere hızlı bir şekilde erişilmelidir, bu nedenle hızlı veri depolamada tutulmalıdır ve uyarı sisteminin gerçekleştirdiği sorguları iyileştirmek için dizine alınmalıdır veya yapılandırılmış olmalıdır. Bazı durumlarda, her düğümdeki verileri toplayan telemetri hizmetinin verileri yerel olarak biçimlendirmesi ve kaydetmesi gerekebilir; böylece uyarı sisteminin yerel bir ö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 dikkate alınması gereken analiz, raporlama ve geçmiş eğilimleri tespit etme amacıyla kullanılan bilgiler daha az acildir ve veri madenciliği ve geçici sorguları destekleyecek şekilde depolanabilir. Daha fazla bilgi için, bu belgenin devamındaki Sıcak, ılık ve soğuk analiz desteği bölümüne bakın.

Günlük döndürme ve veri saklama

Enstrümantasyon, büyük miktarda veri oluşturabilir. Bu veriler, ham günlük dosyaları, iz dosyaları ve her düğümde yakalanan diğer bilgilerden başlayan ve paylaşılan depolamada tutulan bu verilerin birleştirilmiş, temizlenmiş ve bölümlenmiş görünümüne kadar farklı yerlerde tutulabilir. Bazı durumlarda veriler işlenip aktarıldıktan sonra özgün ham kaynak verileri her düğümden kaldırılabilir. Diğer durumlarda ham bilgileri kaydetmek gerekli veya yararlı olabilir. Örneğin, hata ayıklama amacıyla oluşturulan veriler en iyi şekilde ham biçiminde kullanılabilir durumda kalabilir, ancak hatalar düzeltildikten sonra hızla atılabilir.

Performans verilerinin ömrü genellikle daha uzundur, böylece performans eğilimlerini saptamak ve kapasite planlaması için 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. Ayrıca, mevzuat gereksinimleri denetim ve güvenlik amacıyla toplanan bilgilerin de arşivlenmesi ve kaydedilmesini gerektirebilir. Bu veriler de hassastır ve müdahaleyi önlemek için şifrelenmesi veya başka türlü korunması gerekebilir. Kullanıcıların parolalarını veya kimlik sahtekarlığı 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 verileri tamamen kaydetmek yerine, çözünürlüğünü azaltmak ve depolama maliyetlerinden tasarruf etmek için verileri aşağı örneklemek mümkün olabilir. Örneğin, dakika dakika performans göstergelerini kaydetmek yerine, bir aydan daha eski olan verileri birleştirerek bir saatlik görünüm oluşturabilirsiniz.

Günlük bilgilerini toplamak ve depolamak için en iyi uygulamalar

Aşağıdaki listede günlük bilgilerini yakalamaya ve depolamaya yönelik en iyi uygulamalar özetlenmektedir:

• İzleme aracısı veya veri toplama hizmeti, işlem dışı bir hizmet olarak çalışmalı ve dağıtımı basit olmalıdır.

• İzleme aracısından veya veri toplama hizmetinden alınan tüm çıkışlar makineden, işletim sisteminden veya ağ protokolünden bağımsız, belirsiz bir biçim olmalıdır. Örneğin, bilgileri ETL/ETW yerine JSON, MessagePack veya Protobuf gibi kendi kendine açıklayan bir biçimde yayımlayın. Standart bir biçim kullanmak, sistemin işlem hatlarını oluşturmasına olanak tanır; üzerinde anlaşmaya varılan biçimde veri okuyan, dönüştüren ve gönderen bileşenler kolayca tümleştirilebilir.

• İzleme ve veri toplama işlemi, başarısızlığa karşı güvenli olmalı ve basamaklı hata koşullarını tetiklememelidir.

• Veri havuzuna bilgi gönderirken geçici bir hata olması durumunda, izleme aracısı veya veri toplama hizmeti en yeni bilgilerin ilk olarak gönderilmesi için telemetri verilerini yeniden sıralamaya hazır olmalıdır. (İzleme aracısı/veri toplama hizmeti, kendi takdirine bağlı olarak eski verileri bırakmayı veya yerel olarak kaydedip daha sonra iletmeyi seçebilir.)

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

İzleme ve tanılama sürecinin önemli bir parçası, toplanan verileri analiz ederek sistemin genel refahının bir resmini elde etmektir. Kendi KPI'lerinizi ve performans ölçümlerinizi tanımlamış olmanız gerekir ve analiz gereksinimlerinizi karşılamak için toplanan verileri nasıl yapılandırabileceğinizi anlamanız önemlidir. Farklı ölçümlerde ve günlük dosyalarında yakalanan verilerin nasıl ilişkilendirildiğini anlamak da önemlidir, çünkü bu bilgiler bir dizi olayı izlemenin ve ortaya çıkan sorunların tanılanmasında önemli olabilir.

İzleme verilerini birleştirme bölümünde açıklandığı gibi, sistemin her bir parçasına ait veriler genellikle yerel olarak yakalanır, ancak genellikle sisteme katılan diğer sitelerde oluşturulan verilerle birleştirilmelidir. Bu bilgiler, verilerin doğru bir şekilde birleştirildiğinden emin olmak için dikkatli bir bağıntı gerektirir. Örneğin, bir işlemin kullanım verileri kullanıcının bağlandığı bir web sitesini barındıran bir düğüme, bu işlemin bir parçası olarak erişilen ayrı bir hizmeti çalıştıran bir düğüme ve başka bir düğümde tutulan veri depolama alanına yayabilir. Bu bilgilerin, işlemin kaynak ve işleme kullanımının genel bir görünümünü sağlamak için 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.

Sıcak, ılık ve soğuk analizi destekleme

Görselleştirme, raporlama ve uyarı amacıyla verileri çözümlemek ve yeniden biçimlendirmek, kendi kaynak kümesini kullanan karmaşık bir işlem olabilir. Bazı izleme biçimleri zaman açısından kritiktir ve etkili olması için verilerin hemen analiz edilmesini gerektirir. Bu, sıcak analiz olarak bilinir. Uyarılar için gerekli analizler ve güvenlik izlemenin bazı yönleri (sisteme yönelik bir saldırıyı algılama gibi) örnekler verilebilir. Bu amaçlar için gerekli olan verilerin verimli işleme için hızlı bir şekilde kullanılabilir ve yapılandırılmış olması gerekir. Bazı durumlarda analiz işleminin verilerin tutulduğu tek tek düğümlere taşınması gerekebilir.

Diğer analiz biçimleri daha az zaman açısından kritiktir ve ham veriler alındıktan sonra biraz hesaplama ve toplama gerektirebilir. Buna sıcak analiz denir. Performans analizi genellikle bu kategoriye girer. Bu durumda, yalıtılmış, tek bir performans olayının istatistiksel olarak anlamlı olma olasılığı düşüktür. (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.

Isı analizi, sağlık sorunlarını tanılamaya yardımcı olmak için de kullanılabilir. Bir sağlık olayı genellikle anlık analiz aracılığıyla işlenir ve hemen bir uyarı oluşturabilir. Operatör, sıcak yoldan verileri inceleyerek sağlık durumu olayının nedenlerini inceleyebilmelidir. Bu veriler, sağlık olayına neden olan soruna yol açan olaylar hakkında bilgi içermelidir.

Bazı izleme türleri daha uzun vadeli veriler oluşturur. Bu analiz, muhtemelen önceden tanımlanmış bir zamanlamaya göre daha sonraki bir tarihte gerçekleştirilebilir. Bazı durumlarda, analizin belirli bir süre boyunca yakalanan büyük hacimli verilerde karmaşık filtreleme gerçekleştirmesi gerekebilir. Buna soğuk analiz denir. Önemli gereksinim, verilerin yakalandıktan sonra güvenli bir şekilde depolanmasıdır. Örneğin, kullanım izleme ve denetim, sistemin zaman içindeki normal noktalarında durumunun doğru bir resmini gerektirir, ancak bu durum bilgilerinin toplandıktan hemen sonra işlenmek üzere kullanılabilir olması gerekmez.

Operatör, tahmine dayalı sistem durumu analizi için verileri sağlamak üzere soğuk analizi de kullanabilir. Operatör, geçmiş bilgileri belirli bir süre boyunca toplayabilir ve kısa süre içinde sağlık durumu sorunlarına neden olabilecek eğilimleri saptamak amacıyla geçerli sağlık verileriyle (sık erişimli yoldan alınan) destekleyebilir. Bu gibi durumlarda, düzeltici eylemin yapılabilmesi için bir uyarı tetiklemeniz gerekebilir.

Verileri ilişkilendirme

İzlemenin yakaladığı veriler sistem durumunun anlık görüntüsünü sağlayabilir, ancak çözümlemenin amacı bu verileri eyleme dönüştürülebilir hale getirmektir. Örneğin:

• Sistem düzeyinde belirli bir zamanda yoğun G/Ç yüklemesine neden olan şey nedir?
• Çok sayıda veritabanı işleminin sonucu mu?
• Bu durum veritabanı yanıt sürelerine, saniye başına işlem sayısına ve aynı noktada uygulama yanıt sürelerine yansıtılıyor mu?

Bu durumda yükü azaltabilecek bir düzeltme eylemi verileri daha fazla sunucuya parçalayabilir. Ayrıca, sistemin herhangi bir düzeyindeki bir hatanın sonucu olarak özel durumlar ortaya çıkabilir. Bir düzeydeki bir özel durum genellikle yukarıdaki düzeyde başka bir hatayı tetikler.

Bu nedenlerden dolayı, sistemin durumunun ve üzerinde çalışan uygulamaların genel bir görünümünü oluşturmak için her düzeydeki farklı izleme verileri türlerini ilişkilendirmeniz gerekir. Daha sonra bu bilgileri kullanarak sistemin kabul edilebilir bir şekilde çalışıp çalışmadığına karar verebilir ve sistemin kalitesini artırmak için neler yapılıp yapılamayacağını belirleyebilirsiniz.

Verileri ilişkilendirmeye yönelik bilgiler bölümünde açıklandığı gibi, ham izleme verilerinin olayları ilişkilendirmek için gerekli toplamaları desteklemek için yeterli bağlam ve etkinlik kimliği bilgilerini içerdiğinden emin olmanız gerekir. Ayrıca, bu veriler farklı biçimlerde tutulabilir ve bu bilgileri analiz için standartlaştırılmış bir biçime dönüştürmek için ayrıştırmak gerekebilir.

Sorunları tanılama ve giderme

Tanılama, kök neden analizi gerçekleştirmek de dahil olmak üzere hataların veya beklenmeyen davranışların nedenini belirleyebilmeyi gerektirir. Gerekli bilgiler genellikle şunları içerir:

• Tüm sistem veya belirtilen bir zaman penceresi sırasında belirtilen bir alt sistem için olay günlüklerinden ve izlemelerden ayrıntılı bilgiler.
• Sistem içinde veya belirtilen bir alt sistemde belirtilen bir süre boyunca oluşan herhangi bir düzeyin özel durumlarından ve hatalarından kaynaklanan tam yığın izlemeleri.
• Sistemin herhangi bir yerindeki veya belirtilen bir alt sistemdeki başarısız işlemler için, belirtilen bir zaman aralığında kilitlenme dökümleri.
• Belirtilen süre boyunca tüm kullanıcılar veya seçili kullanıcılar tarafından gerçekleştirilen işlemleri kaydeden etkinlik günlükleri.

Sorun giderme amacıyla verilerin çözümlenmesi genellikle sistem mimarisinin ve çözümü oluşturan çeşitli bileşenlerin ayrıntılı teknik bir şekilde anlaşılmasını gerektirir. Sonuç olarak, verileri yorumlamak, sorunların nedenini oluşturmak ve bunları düzeltmek için uygun bir strateji önermek için genellikle büyük ölçüde el ile müdahale gerekir. Bu bilgilerin bir kopyasını özgün biçiminde depolamak ve bir uzman tarafından soğuk analiz için kullanılabilir hale getirmek uygun olabilir.

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

Herhangi bir izleme sisteminin önemli bir yönü, verileri operatörün eğilimleri veya sorunları hızla tespit edebilmesi için sunabilmektir. Ayrıca dikkat gerektiren önemli bir olay oluştuğunda operatörü hızla bilgilendirebilme özelliği de önemlidir.

Veri sunusu, panoları kullanarak görselleştirme, uyarı ve raporlama gibi çeşitli biçimler alabilir.

Panoları kullanarak görselleştirme

Verileri görselleştirmenin en yaygın yolu, bilgileri bir dizi grafik, grafik veya başka bir çizim olarak görüntüleyebilen panoları kullanmaktır. Bu öğeler parametrelendirilebilir ve analistin belirli bir durum için önemli parametreleri (zaman aralığı gibi) seçebilmesi gerekir.

Panolar hiyerarşik olarak düzenlenebilir. Üst düzey panolar, sistemin her yönüne ilişkin genel bir görünüm verebilir, ancak operatörün ayrıntılara inebilmesini sağlar. Örneğin, sistemin genel disk G/Ç'sini gösteren bir pano, bir analistin bir veya daha fazla belirli cihazın orantısız bir trafik hacmine sahip olup olmadığını belirlemek için her disk için G/Ç oranlarını görüntülemesine izin vermelidir. İdeal olan panonun, bu G/Ç'yi oluşturan her isteğin kaynağı (kullanıcı veya etkinlik) gibi ilgili bilgileri de görüntülemesi gerekir. Bu bilgiler daha sonra yükün cihazlar arasında daha eşit bir şekilde yayılıp yayılmayacağını (ve) ve daha fazla cihaz eklendiğinde sistemin daha iyi çalışıp çalışmayacağını belirlemek için kullanılabilir.

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

• Uzun bir süre boyunca maksimum kapasitesine yaklaşan G/Ç oranına sahip bir disk (sıcak disk) kırmızı renkle vurgulanabilir.
• Periyodik olarak kısa süreler boyunca en yüksek sınırında çalışan (sıcak disk olarak adlandırılan) G/Ç hızına sahip bir disk sarı renkle vurgulanabilir.
• Normal kullanım sergileyen bir disk yeşil renkte görüntülenebilir.

Pano sisteminin etkili bir şekilde çalışması için, çalışmak için ham verilere sahip olması gerekir. Kendi pano sisteminizi oluşturuyorsanız veya başka bir kuruluş tarafından geliştirilen bir pano kullanıyorsanız, hangi izleme verilerini toplamanız gerektiğini, hangi ayrıntı düzeylerinde ve panonun kullanmasının nasıl biçimlendirilmesi gerektiğini anlamanız gerekir.

İyi bir pano, bilgileri görüntülemenin yanı sıra analistin bu bilgiler hakkında sorular sormasını da sağlar. Bazı sistemler, bir operatörün bu görevleri gerçekleştirmek ve temel alınan verileri keşfetmek için kullanabileceği yönetim araçları sağlar. Alternatif olarak, bu bilgileri tutmak için kullanılan depoya bağlı olarak, bu verileri doğrudan sorgulamak veya daha fazla analiz ve raporlama için Microsoft Excel gibi araçlara aktarmak mümkün olabilir.

Uyarı

Bu bilgiler ticari olarak hassas olabileceği için panolara erişimi yetkili personelle kısıtlamanız gerekir. Ayrıca, kullanıcıların panoları değiştirmesini önlemek için temel alınan verileri de korumanız gerekir.

Uyarı oluşturma

Uyarı, izleme ve izleme verilerini analiz etme ve önemli bir olay algılanırsa bildirim oluşturma işlemidir.

Uyarı, sistemin sağlıklı, duyarlı ve güvenli kalmasını sağlamaya yardımcı olur. Verilerin hemen üzerinde işlem yapılması gerekebilecek kullanıcılara performans, kullanılabilirlik ve gizlilik garantileri veren tüm sistemlerin önemli bir parçasıdır. Uyarıyı tetikleyen olay bir operatöre bildirilmesi gerekebilir. Uyarı, otomatik ölçeklendirme gibi sistem işlevlerini çağırmak için de kullanılabilir.

Uyarı genellikle aşağıdaki izleme verilerine bağlıdır:

• Güvenlik olayları. Olay günlükleri, yinelenen kimlik doğrulama veya yetkilendirme hatalarının oluştuğunu gösteriyorsa, sistem saldırı altında olabilir ve bir operatör bilgilendirilmelidir.
• Performans ölçümleri. Belirli bir performans ölçümü belirtilen eşiği aşarsa sistemin hızla yanıt vermesi gerekir.
• Kullanılabilirlik bilgileri. Hata algılanırsa, bir veya daha fazla alt sistemin hızlı bir şekilde yeniden başlatılması veya bir yedekleme kaynağına yük devretme yapılması gerekebilir. Bir alt sistemdeki yinelenen hatalar daha ciddi endişelere işaret edebilir.

Operatörler e-posta, çağrı cihazı veya SMS kısa mesaj gibi birçok teslim kanalını kullanarak uyarı bilgilerini alabilir. Uyarı, bir durumun ne kadar kritik olduğunu gösteren bir gösterge de içerebilir. Birçok uyarı sistemi abone gruplarını destekler ve aynı grubun üyesi olan tüm operatörler aynı uyarı kümesini alabilir.

Bir uyarı sistemi özelleştirilebilir olmalıdır ve temel alınan izleme verilerinden uygun değerler parametre olarak sağlanabilir. Bu yaklaşım, bir operatörün verileri filtrelemesini ve bu eşiklere veya ilgi çekici değer birleşimlerine odaklanmasını sağlar. Bazı durumlarda ham izleme verileri uyarı sistemine sağlanabilir. Diğer durumlarda, toplanan verileri sağlamak daha uygun olabilir. (Örneğin, bir düğümün CPU kullanımı son 10 dakika içinde yüzde 90'ı aştıysa bir uyarı tetiklenebilir). Uyarı sistemine sağlanan ayrıntılar uygun özet ve bağlam bilgilerini de içermelidir. Bu veriler, hatalı pozitif olayların bir uyarıyı tetiklemesi olasılığını azaltmaya yardımcı olabilir.

Raporlama

Raporlama, sistemin genel bir görünümünü oluşturmak için kullanılır. Geçerli bilgilere ek olarak geçmiş verileri de içerebilir. Raporlama gereksinimleri iki geniş kategoriye ayrılır: operasyonel raporlama ve güvenlik raporlaması.

operasyonel raporlama genellikle aşağıdaki özellikleri 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 dönemde, genel sistem veya belirtilen alt sistemler için kaynak kullanımındaki eğilimleri tanımlama.
• 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. Bu, her kullanıcının gerçekleştirdiği isteklerin tarih ve saatlerle birlikte kaydedilmesini gerektirir. Veriler, bir yöneticinin kullanıcının belirli bir süre boyunca gerçekleştirdiği işlem dizisini hızla yeniden oluşturmasını sağlayacak şekilde yapılandırılmalıdır.
• Kullanıcı tarafından kaynak kullanımını izleme. Bu, bir kullanıcı için her isteğin sistemi oluşturan çeşitli kaynaklara nasıl ve ne kadar süreyle eriştiğinin kaydedilmesini gerektirir. Yöneticinin bu verileri kullanarak belirli bir süre boyunca (faturalama amacıyla) kullanıcı tarafından kullanım raporu oluşturabilmesi gerekir.

Birçok durumda, toplu işlemler tanımlanan zamanlamaya göre raporlar oluşturabilir. (Gecikme normalde bir sorun değildir.) Ancak, gerekirse isteğe bağlı olarak oluşturma için de kullanılabilir olmalıdır. Örneğin, verileri Azure SQL Veritabanı gibi bir ilişkisel veritabanında depoluyorsanız, verileri ayıklamak ve biçimlendirmek ve bir rapor kümesi olarak sunmak için SQL Server Reporting Services gibi bir araç kullanabilirsiniz.

Sonraki Adımlar

• Azure Monitor'a genel bakış
• Microsoft Azure Depolama izleme, tanılama ve sorun giderme
• Microsoft Azure'da uyarılara genel bakış
• Application Insights nedir?
• Azure sanal makineleri için performans tanılamaları
• Visual Studio için SQL Server Veri Araçları'nı (SSDT) indirme ve yükleme

İlgili kaynaklar

• Otomatik ölçeklendirme kılavuzu , bir operatörün sistemin performansını sürekli izlemesi ve kaynak ekleme veya kaldırma konusunda karar verme gereksinimini azaltarak yönetim yükünü nasıl azaltacaklarını 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.

Bulutta çalışan dağıtılmış uygulamalar ve hizmetler, doğası gereği birçok hareketli parçadan oluşan karmaşık yazılım parçalarıdı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ı

Bir sistemin ne kadar iyi çalıştığını görmek için izlemeyi kullanabilirsiniz. İzleme, hizmet kalitesi hedeflerini korumanın önemli bir parçasıdır. İzleme verilerini toplamaya yönelik yaygın senaryolar şunlardır:

• Sistemin sağlıklı kalmasını sağlamak.
• Sistemin ve bileşen öğelerinin kullanılabilirliğini izleme.
• Çalışma hacmi arttıkça sistemin aktarım hızının beklenmedik şekilde azalmamasını sağlamak için performansın korunması.
• Sistemin müşterilerle kurulan hizmet düzeyi sözleşmelerini (SLA) karşıladığını garanti eder.
• Sistemin, kullanıcıların ve verilerinin gizliliğini ve güvenliğini koruma.
• Denetim veya düzenleme amacıyla gerçekleştirilen işlemleri izleme.
• Sistemin günlük kullanımını izleme ve ele alınmaması durumunda sorunlara yol açabilecek eğilimleri tespit etme.
• İlk rapordan olası nedenlerin analizine, düzeltmeye, sonuç olarak yazılım güncelleştirmelerine ve dağıtıma kadar oluşan sorunları izleme.
• İşlem izleme ve yazılım sürümlerinde hata ayıklama.

Uyarı

Bu listenin kapsamlı olması amaçlanmamıştır. Bu belge, izleme gerçekleştirmeye yönelik en yaygın durumlar olarak bu senaryolara odaklanır. Daha az yaygın olan veya ortamınıza özgü başkaları da olabilir.

Aşağıdaki bölümlerde bu senaryolar daha ayrıntılı olarak açıklanmaktadır. Her senaryonun bilgileri aşağıdaki biçimde ele alındı:

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.

Sağlık izleme

Sistem çalışıyorsa ve istekleri işliyorsa iyi durumdadır. Sistem durumu izlemenin amacı, sistemin tüm bileşenlerinin beklendiği gibi çalıştığını doğrulayabilmeniz için sistemin geçerli durumunun anlık görüntüsünü oluşturmaktır.

Sağlık izleme gereksinimleri

Sistemin herhangi bir parçasının iyi durumda olmadığının kabul edilmesi durumunda operatör hızla (birkaç saniye içinde) uyarılmalıdır. Operatör, sistemin hangi bölümlerinin normal şekilde çalıştığını ve hangi parçaların sorun yaşadığını doğrulayabilmelidir. Sistem durumu bir trafik ışığı sistemi aracılığıyla vurgulanabilir:

• İyi durumda olmayanlar için kırmızı (sistem durdu)
• Kısmen iyi durumda (sistem sınırlı işlevsellikle çalışıyor) için sarı
• Tamamen sağlıklı olanlar için yeşildir

Kapsamlı bir sistem durumu izleme sistemi, operatörün alt sistemlerin ve bileşenlerin sistem durumunu görüntülemek için sistemde detaya gitmesine olanak tanır. Örneğin, genel sistem kısmen sağlıklı olarak gösteriliyorsa, işletici veya kullanıcı yakınlaştırma yaparak şu anda hangi işlevselliğin düşürüldüğünü veya kullanılamaz olduğunu belirleyebilmelidir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sistem durumu izlemeyi desteklemek için gereken ham veriler aşağıdakilerin sonucu olarak oluşturulabilir:

• Kullanıcı isteklerinin yürütülmesini izleme. Bu bilgiler, hangi isteklerin başarılı olduğunu, hangilerinin başarısız olduğunu ve her isteğin ne kadar sürdüğünü belirlemek için kullanılabilir.
• Yapay kullanıcı izleme. Bu işlem, bir kullanıcı tarafından gerçekleştirilen adımların benzetimini gerçekleştirir ve önceden tanımlanmış bir dizi adımı izler. Her adımın sonuçları yakalanmalıdır.
• Özel durumları, hataları ve uyarıları günlüğe kaydetme. Bu bilgiler, uygulama koduna eklenmiş izleme deyimlerinin bir sonucu olarak yakalanabilir ve sistemin referans aldığı hizmetlerin olay günlüklerinden bilgi toplanabilir.
• Sistemin kullandığı tüm üçüncü taraf hizmetlerinin durumunu izleme. Bu izleme için bu hizmetlerin sağladığı sistem durumu verilerinin alınması ve ayrıştırılması gerekebilir. Bu bilgiler çeşitli biçimlerde olabilir.
• Uç nokta izleme. Bu mekanizma , "Kullanılabilirlik izleme" bölümünde daha ayrıntılı olarak açıklanmıştır.
• Arka plan CPU kullanımı veya G/Ç (ağ dahil) etkinliği gibi ortam performansı bilgilerini toplama.

Sağlık verilerini çözümleme

Sistem durumu izlemenin birincil odağı, sistemin çalışıp çalışmadığını hızla belirtmektir. Anlık verilerin sık erişimli analizi, kritik bir bileşen iyi durumda değil olarak algılanırsa (örneğin, ardışık bir ping dizisine yanıt veremediğinde) bir uyarı tetikleyebilir. İşleç daha sonra uygun düzeltici eylemi gerçekleştirebilir.

Daha gelişmiş bir sistem, son ve geçerli iş yükleri üzerinde soğuk analiz gerçekleştiren tahmine dayalı bir öğe içerebilir. Soğuk analiz eğilimleri belirleyebilir ve sistemin iyi durumda kalma olasılığının yüksek olup olmadığını veya sistemin ek kaynaklara ihtiyacı olup olmadığını belirleyebilir. Bu tahmine dayalı öğe aşağıdakiler gibi kritik performans ölçümlerini temel almalıdır:

• Her hizmet veya alt sisteme yönlendirilen isteklerin oranı.
• Bu isteklerin yanıt süreleri.
• Her hizmete giren ve giden veri hacmi.

Herhangi bir ölçümün değeri tanımlı eşiği aşarsa sistem, bir operatörün veya otomatik ölçeklendirmenin (varsa) sistem durumunu korumak için gerekli önleyici eylemleri gerçekleştirmesini sağlamak için bir uyarı oluşturabilir. Bu eylemler kaynak eklemeyi, başarısız olan bir veya daha fazla hizmeti yeniden başlatmayı veya düşük öncelikli isteklere azaltma uygulamayı içerebilir.

Kullanılabilirlik izleme

Gerçekten iyi durumda olan bir sistem, sistemi oluşturan bileşenlerin ve alt sistemlerin kullanılabilir olmasını gerektirir. Kullanılabilirlik izleme, sistem durumu izlemeyle yakından ilgilidir. Sistem durumu izleme, sistemin geçerli durumunun hemen bir görünümünü sağlarken, kullanılabilirlik izleme, sistemin çalışma süresiyle ilgili istatistikler oluşturmak için sistemin ve bileşenlerinin kullanılabilirliğini izlemekle ilgilidir.

Birçok sistemde, ciddi bir hata veya bağlantı kaybı durumunda hızlı yük devretmeye izin vermek için bazı bileşenler (veritabanı gibi) yerleşik yedeklilikle yapılandırılır. İdeal olarak, kullanıcılar böyle bir hata oluştuğundan haberdar olmamalıdır. Ancak kullanılabilirlik izleme perspektifinden bakıldığında, nedeni belirlemek ve yinelenenleri önlemek için düzeltici eylemler uygulamak için bu tür hatalar hakkında mümkün olduğunca çok bilgi toplamak gerekir.

Kullanılabilirliği izlemek için gereken veriler birden çok alt düzey faktöre bağlı olabilir. Bu faktörlerin çoğu uygulamaya, sisteme ve ortama özgü olabilir. Etkili bir izleme sistemi, bu düşük düzeyli faktörlere karşılık gelen kullanılabilirlik verilerini yakalar ve sonra bunları toplayarak sistemin genel bir resmini verir. Örneğin, bir e-ticaret sisteminde müşterinin sipariş vermesine olanak tanıyan iş işlevselliği, sipariş ayrıntılarının depolandığı depoya ve bu siparişlerin ödemesine yönelik parasal işlemleri işleyen ödeme sistemine bağlı olabilir. Bu nedenle sistemin sipariş yerleştirme bölümünün kullanılabilirliği, deponun ve ödeme alt sisteminin kullanılabilirliğinin bir işlevidir.

Kullanılabilirlik izleme gereksinimleri

Operatör ayrıca her sistemin ve alt sistemin geçmiş kullanılabilirliğini görüntüleyebilmeli ve bir veya daha fazla alt sistemin düzenli aralıklarla başarısız olmasına neden olabilecek eğilimleri saptamak için bu bilgileri kullanabilmelidir. Örneğin, operatör kullanılabilirlik verilerini kullanarak hizmetlerin yoğun işlem saatlerine karşılık gelen günün belirli bir saatinde başarısız olduğunu algılayabilir.

İzleme çözümü, her bir alt sistemin kullanılabilirliği veya kullanılamamasıyla ilgili anlık ve geçmiş bir görünüm sağlamalıdır. Ayrıca, bir veya daha fazla hizmet başarısız olduğunda veya kullanıcılar hizmetlere bağlanamayınca operatörü hızla uyarabilmelidir. Bu, yalnızca her hizmeti izlemekle kalmaz, aynı zamanda bir hizmetle iletişim kurmaya çalıştığında bu eylemlerin başarısız olması durumunda her kullanıcının gerçekleştirdiği eylemleri incelemektir. Bir ölçüde bağlantı hatası normaldir ve geçici hatalardan kaynaklanıyor olabilir. Ancak, sistemin belirli bir süre boyunca belirli bir alt sisteme bağlantı hatası sayısı için uyarı göndermesine izin vermek yararlı olabilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sistem durumu izlemede olduğu gibi, kullanılabilirlik izlemeyi desteklemek için gereken ham veriler yapay kullanıcı izlemesi ve oluşabilecek özel durumları, hataları ve uyarıları günlüğe kaydetmenin bir sonucu olarak oluşturulabilir. Ayrıca, kullanılabilirlik verileri uç nokta izlemesi gerçekleştirilerek elde edilebilir. Uygulama, sistem içindeki işlevsel bir alana erişimi test eden bir veya daha fazla sağlık uç noktasını kullanıma açabilir. İzleme sistemi, tanımlı bir zamanlamaya uyarak her uç noktaya ping yapabilir ve sonuçları toplayabilir (başarılı veya başarısız).

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 verilerini analiz etme

İzleme verilerinin aşağıdaki analiz türlerini desteklemek için toplanması ve bağıntılı olması gerekir:

• Sistemin ve alt sistemlerin hemen kullanılabilirliği.
• Sistemin ve alt sistemlerin kullanılabilirlik hatası oranları. İdeal olarak, bir işleç hataları belirli etkinliklerle ilişkilendirebilmelidir: Sistem başarısız olduğunda ne oluyordu?
• Sistemin veya herhangi bir alt sistemin belirtilen süre boyunca hata oranlarının ve bir hata oluştuğunda sistem üzerindeki yükün (örneğin kullanıcı isteklerinin sayısı) geçmiş görünümü.
• Sistemin veya alt sistemlerin kullanılamama nedenleri. Örneğin, bunun nedenleri hizmetin çalışmaması, bağlantının kaybolması, bağlantının kurulu ancak zaman aşımına uğraması ve bağlantı kurulmasına rağmen hata vermesi olabilir.

Aşağıdaki formülü kullanarak bir hizmetin belirli bir süre boyunca kullanılabilirlik yüzdesini hesaplayabilirsiniz:

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

Bu, SLA amaçları için 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ılamadığı süre (toplam birikmiş dakika) olarak tanımlar. Dakika boyunca müşteri tarafından başlatılan işlemleri gerçekleştirmek için Derleme Hizmeti'ne yapılan tüm sürekli HTTP istekleri hata koduyla sonuçlanırsa veya yanıt döndürmezse bir dakikanın kullanılamaz olduğu kabul edilir.

Performans izleme

Sistem giderek daha fazla stres altında olduğundan (kullanıcı hacmi artırılarak), bu kullanıcıların eriştiği veri kümelerinin boyutu artar ve bir veya daha fazla bileşenin başarısız olma olasılığı artar. Genellikle, bileşen hatasından önce performans düşüşü görülür. Böyle bir düşüşü algılayabilirseniz, durumu düzeltmek için proaktif adımlar atabilirsiniz.

Sistem performansı birden çok faktöre bağlıdır. Her faktör genellikle saniyedeki veritabanı işlemlerinin sayısı veya belirtilen bir zaman diliminde başarıyla hizmet veren ağ isteklerinin hacmi gibi temel performans göstergeleri (KPI' ler) aracılığıyla ölçülür. Bu KPI'lerden bazıları belirli performans ölçüleri olarak kullanılabilirken, diğerleri ölçümlerin birleşiminden türetilebilir.

Uyarı

Düşük veya iyi performansı belirlemek için sistemin çalışabilecek performans düzeyini anlamanız gerekir. Bunun için sistemin tipik bir yük altında çalışırken gözlemlenmesi ve belirli bir süre boyunca her KPI için verileri yakalaması gerekir. Bu, sistemi bir test ortamında sanal yük altında çalıştırmayı ve sistemi üretim ortamına dağıtmadan önce uygun verileri toplamayı içerebilir.

Ayrıca performans amacıyla izlemenin sistem üzerinde bir yük haline gelmediğinden de emin olmanız gerekir. Performans izleme işleminin topladığı verilerin ayrıntı düzeyini ayarlamak performansınızı iyileştirmenize yardımcı olur.

Performans izleme gereksinimleri

Bir operatörün sistem performansını incelemek için genellikle şunları içeren bilgileri görmesi gerekir:

• Kullanıcı isteklerinin yanıt oranları.
• Eşzamanlı kullanıcı isteklerinin sayısı.
• Ağ trafiğinin hacmi.
• İş işlemlerinin tamamlanma oranları.
• İstekler için ortalama işleme süresi.

Ayrıca, bir operatörün aşağıdakiler gibi bağıntıları belirlemesine yardımcı olacak araçlar sağlamak da yararlı olabilir:

• Eşzamanlı kullanıcıların sayısı ve istek gecikme süresi süreleri (kullanıcı gönderdikten sonra bir isteği işlemeye başlama süresi).
• Eş zamanlı kullanıcı sayısı ile ortalama yanıt süresi (işleme başladıktan sonra bir isteğin tamamlanmasının ne kadar sürdüğü).
• İsteklerin hacmiyle işleme hatalarının sayısı karşılaştırması.

Bu üst düzey işlevsel bilgilerle birlikte, bir operatörün sistemdeki her bileşenin performansına ilişkin ayrıntılı bir görünüm elde edebilmesi gerekir. Bu veriler genellikle aşağıdakiler gibi bilgileri izleyen düşük 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ğ giriş/çıkış hızları ve hataları
• Yazılan veya okunan bayt sayısı
• Kuyruk uzunluğu gibi ara yazılım göstergeleri

Tüm görselleştirmeler operatörün bir zaman aralığı belirtmesine izin vermelidir. 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, belirtilen herhangi bir zaman aralığında belirtilen herhangi bir değer için herhangi bir performans ölçüsüne göre uyarı oluşturabilmelidir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sistemden geçen kullanıcıların isteklerinin ilerleme durumunu izleyerek üst düzey performans verilerini (aktarım hızı, eşzamanlı kullanıcı sayısı, iş işlemleri sayısı ve hata oranları gibi) toplayabilirsiniz. Bu, zamanlama bilgileriyle birlikte uygulama kodundaki önemli noktalarda izleme deyimlerini birleştirmeyi içerir. Tüm hatalar, özel durumlar ve uyarılar, bunlara neden olan isteklerle ilişkilendirmek için yeterli veriyle yakalanmalıdır.

Mümkünse, uygulamanın kullandığı tüm dış sistemler için performans verilerini de yakalamanız gerekir. Bu dış sistemler, performans verilerini istemek için kendi performans sayaçlarını veya diğer özellikleri sağlayabilir. Bu mümkün değilse, bir dış sisteme yapılan her isteğin başlangıç saati ve bitiş saati gibi bilgileri işlemin durumuyla (başarılı, başarısız veya uyarı) birlikte kaydedin. Örneğin, istekleri zamanlarken kronometre yaklaşımını kullanabilirsiniz: İstek başladığında bir zamanlayıcı başlatın ve istek tamamlandığında zamanlayıcıyı durdurun.

Sistemdeki tek tek bileşenler için düşük düzey performans verileri, Windows performans sayaçları ve Azure Tanılama gibi özellikler ve hizmetler aracılığıyla kullanılabilir.

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. Kullanıcı isteğine örnek olarak alışveriş sepetine öğe ekleme veya e-ticaret sisteminde kullanıma alma işlemini gerçekleştirme işlemi gösterilebilir.

Bir diğer yaygın gereksinim de seçilen yüzdebirlik dilimlerdeki performans verilerini özetlemektir. Örneğin, bir işleç isteklerin yüzde 99'unun yanıt sürelerini, isteklerin yüzde 95'ini ve isteklerin yüzde 70'ini belirleyebilir. Her yüzdelik dilim için belirlenmiş SLA hedefleri veya başka hedefler olabilir. Anlık sorunları algılamaya yardımcı olmak için devam eden sonuçlar neredeyse gerçek zamanlı olarak bildirilmelidir. İstatistiksel amaçlar için sonuçlar da daha uzun bir süre içinde toplanmalıdır.

Performansı etkileyen gecikme sorunları söz konusu olduğunda, operatörün her isteğin gerçekleştirdiği her adımın gecikme süresini inceleyerek performans sorununun nedenini hızla belirleyebilmesi gerekir. Bu nedenle performans verilerinin, bunları belirli bir istekle ilişkilendirmek için her adım için performans ölçülerini ilişkilendirmek için bir araç sağlaması gerekir.

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 bilgilerinin karmaşık geçici sorgulamasına ve analizine izin verebilir.

Güvenlik izleme

Hassas veriler içeren tüm ticari sistemlerin bir güvenlik yapısı uygulaması gerekir. Güvenlik mekanizmasının karmaşıklığı genellikle verilerin duyarlılığının bir işlevidir. Kullanıcıların kimliğinin doğrulanması gereken bir sistemde şunları kaydetmelisiniz:

• İster başarısız ister başarılı olsun, tüm oturum açma girişimleri.
• 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ı oturumu bitirip oturumu kapattığında.

İzleme, sistemdeki saldırıları algılamaya yardımcı olabilir. Örneğin, çok sayıda başarısız oturum açma denemesi bir brute force saldırısına işaret edebilir. İsteklerde beklenmeyen bir artış, dağıtılmış bir hizmet reddi (DDoS) saldırısının sonucu olabilir. Bu isteklerin kaynağından bağımsız olarak tüm kaynaklara yönelik tüm istekleri izlemeye hazırlıklı olmanız gerekir. Oturum açma güvenlik açığı olan bir sistem, bir kullanıcının gerçekten oturum açmasına gerek kalmadan kaynakları yanlışlıkla dış dünyaya açıklayabilir.

Güvenlik izleme gereksinimleri

Güvenlik izlemenin en kritik unsurları, bir operatörün hızla gerçekleştirebilmesini sağlamalıdır.

• Kimliği doğrulanmamış bir varlık tarafından yetkisiz erişim girişimini algılayın.
• Yetkisi olmayan varlıkların verilere erişim sağlamak için girişimlerini belirleyin.
• Sistemin veya sistemin bir bölümünün dışarıdan mı yoksa içeriden mi saldırı altında olduğunu belirleyin. Örneğin, kimliği doğrulanmış kötü amaçlı bir kullanıcı sistemi çökertmeye çalışabilir.

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.

Bir operatör için sağlanan bilgiler, her istek için kaynağın ana bilgisayar adresini içermelidir. Belirli bir adres aralığından düzenli olarak güvenlik ihlalleri meydana gelirse, bu ana bilgisayarlar engellenebilir.

Sistemin güvenliğini korumanın önemli bir parçası, her zamanki desenden sapan eylemleri hızlı bir şekilde algılayabilmektir. 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ğin bir örneği, kullanıcıların 03:00'te oturum açması ve çalışma günü 09:00'da başladığında çok sayıda işlem gerçekleştirmesidir.

Bu bilgiler, zamana bağlı otomatik ölçeklendirmeyi yapılandırmaya yardımcı olmak için de kullanılabilir. Örneğin, bir operatör, günün belirli bir saatinde çok sayıda kullanıcının düzenli olarak oturum açtığını gözlemler ise, operatör iş yükünü karşılamak için ek kimlik doğrulama hizmetleri başlatabilir ve tepe noktası geçtikten sonra bu ek hizmetleri kapatabilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Güvenlik, çoğu dağıtılmış sistemi kapsayan bir özelliktir. Uygun veriler büyük olasılıkla sistem genelinde birden çok noktada oluşturulmalıdır. Uygulama, ağ donanımı, sunucular, güvenlik duvarları, virüsten koruma yazılımları ve diğer yetkisiz erişim önleme öğeleri tarafından ortaya çıkarılan olaylardan kaynaklanan güvenlikle ilgili bilgileri toplamak için Güvenlik Bilgileri ve Olay Yönetimi (SIEM) yaklaşımını benimsemeyi düşünmelisiniz.

Güvenlik izleme, uygulamanızın parçası olmayan araçlardan veri içerebilir. Bu araçlar, dış kurumlar tarafından yapılan bağlantı noktası tarama etkinliklerini tanımlayan yardımcı programları veya uygulamanıza ve verilerinize kimliği doğrulanmamış erişim elde etme girişimlerini algılayan ağ filtrelerini içerebilir. Bazı durumlarda, CI/CD dağıtım araçları da uygulama yaşam döngüsünün önemli bir parçasını oluşturur ve bu araçların anormal davranışları da işaretlemesi gerekir.

Her durumda, toplanan veriler bir yöneticinin herhangi bir saldırının doğasını belirlemesine ve uygun önlemleri almasına olanak sağlamalıdır.

Güvenlik verilerini çözümleme

Güvenlik izlemenin temel özelliklerinden biri, birçok kaynaktan veri toplamasıdır. Farklı biçimler ve ayrıntı düzeyi genellikle yakalanan verilerin karmaşık bir şekilde analiz ederek bunları tutarlı bir bilgi dizisine bağlamasını gerektirir. Temel durumlar (birçok başarısız oturum açma işleminin algılanması veya kritik kaynaklara yetkisiz erişim elde etme girişimlerinin tekrarlanması gibi) dışında, güvenlik verilerinin karmaşık otomatik olarak işlenmesi 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

Ödeme yapan müşterileri destekleyen birçok ticari sistem, sistemin performansı hakkında SLA biçiminde taahhütlerde bulunur. Temel olarak, SLA'lar sistemin belirlenen bir iş hacmini üzerinde anlaşmaya varılan bir zaman dilimi içinde ve kritik bilgileri kaybetmeden işleyebileceğini belirtir. SLA izleme, sistemin ölçülebilir SLA'ları karşılayabilmesini sağlamakla ilgilidir.

Uyarı

SLA izleme, performans izleme ile yakından ilgilidir. Ancak performans izleme, sistemin en iyi şekilde çalışmasını sağlamakla ilgilenirken, SLA izleme, en uygun şekilde gerçekte ne anlama geldiğini tanımlayan sözleşme yükümlülüğüne tabidir.

SLA'lar genellikle şu terimlerle tanımlanır:

• Genel sistem kullanılabilirliği. Örneğin, bir kuruluş sistemin yüzde 99,9 oranında kullanılabilir olduğunu taahhüt edebilir. Bu, yılda en fazla 9 saat veya haftada yaklaşık 10 dakika kapalı kalma süresine eşittir.
• İşletimsel aktarım hızı. Bu özellik, genellikle sistemin 100.000'e kadar eşzamanlı kullanıcı isteğini destekleyebileceğine veya 10.000 eşzamanlı iş işlemini gerçekleştirebileceğine dair taahhüt gibi bir veya birden fazla kapasite sınırı olarak ifade edilir.
• İşletimsel yanıt süresi. Sistem, isteklerin işlenme hızı için de taahhütlerde bulunabilir. Örnek olarak tüm iş işlemlerinin yüzde 99'u iki saniye içinde tamamlanır ve tek bir işlem 10 saniyeden uzun sürmez.

Uyarı

Ticari sistemlere yönelik bazı sözleşmeler müşteri desteği için SLA'ları da içerebilir. Örnek olarak, tüm yardım masası istekleri beş dakika içinde yanıt alabilir ve tüm sorunların yüzde 99'u bir iş günü içinde tamamen giderilir. Etkili sorun izleme (bu bölümde daha ayrıntılı olarak açıklanmaktadır), bu tür SLA'ların karşılanması için anahtardır.

SLA izleme gereksinimleri

En yüksek düzeyde, bir operatör sistemin üzerinde anlaşmaya varılan SLA'ları karşılayıp karşılamadığını bir bakışta saptayabilmelidir. Aksi takdirde işleç, standart dışı performansın nedenlerini belirlemek için detaya gidebilir ve temel faktörleri inceleyebilmelidir.

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

• Hizmet çalışabilirlik 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ının, özel durumlarının ve uyarılarının sayısı.

Bu göstergelerin tümü belirli bir süreye göre filtrelenebilir olmalıdır.

Bulut uygulaması büyük olasılıkla birden çok alt sistem ve bileşenden oluşur. Operatör üst düzey bir gösterge seçebilmeli ve temel öğelerin sağlık durumuna bağlı olarak nasıl oluştuğunu görebilmelidir. Örneğin, genel sistemin çalışma süresi kabul edilebilir bir değerin altına düşerse, operatörün bu hataya katkıda bulunan öğeleri yakınlaştırabilmesi ve belirleyebilmesi gerekir.

Uyarı

Sistem çalışma süresinin dikkatli bir şekilde tanımlanması gerekir. Maksimum kullanılabilirliği sağlamak için yedeklilik kullanan bir sistemde, öğelerin tek tek örnekleri başarısız olabilir, ancak sistem işlevsel kalabilir. Sağlık izleme tarafından sunulan sistem çalışma süresi, her bir öğenin toplam çalışma süresini göstermeli ve sistemin gerçekten durup durmadığını belirtmesi gerekmemelidir. Ayrıca, hatalar izole edilmiş olabilir. Bu nedenle, belirli bir sistem kullanılamıyor olsa bile, sistemin geri kalanı kullanılabilir durumda kalabilir, ancak işlevsellik azalmış olabilir. Bir e-ticaret sisteminde, sistemdeki bir hata müşterinin sipariş vermesini engelleyebilir, ancak müşteri yine de ürün kataloğuna göz atabilir.

Uyarı amacıyla, üst düzey göstergelerden herhangi biri belirtilen eşiği aşarsa sistem bir olay oluşturabilmelidir. Üst düzey göstergeyi oluşturan çeşitli faktörlerin alt düzey ayrıntıları, uyarı sistemi için bağlamsal veriler olarak kullanılabilir olmalıdır.

Veri kaynakları, izleme ve veri toplama gereksinimleri

SLA izlemeyi desteklemek için gereken ham veriler, sistem durumu ve kullanılabilirlik izlemesinin bazı yönleriyle birlikte performans izleme için gereken ham verilere benzer. Daha fazla bilgi için bu bölümlere bakın. Bu verileri şu şekilde yakalayabilirsiniz:

• Uç nokta izleme gerçekleştirme.
• Özel durumları, hataları ve uyarıları günlüğe kaydetme.
• Kullanıcı isteklerinin yürütülmesini izleme.
• Sistemin kullandığı üçüncü taraf hizmetlerin kullanılabilirliğini izleme.
• Performans ölçümlerini ve sayaçlarını kullanma.

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

SLA verilerini çözümleme

Sistemin genel performansının bir resmini oluşturmak için izleme verilerinin toplanması gerekir. Toplanan verilerin, temel alınan alt sistemlerin performansının incelenmesini sağlamak için detaya gitmeyi de desteklemesi gerekir. Örneğin şunları yapabilmeniz gerekir:

• Belirtilen süre boyunca kullanıcı isteklerinin toplam sayısını hesaplayın ve bu isteklerin başarı ve başarısızlık oranını belirleyin.
• Sistem yanıt sürelerinin genel bir görünümünü oluşturmak için kullanıcı isteklerinin yanıt sürelerini birleştirin.
• Bir isteğin genel yanıt süresini, istekteki tek tek iş öğelerinin yanıt sürelerine bölmek için kullanıcı isteklerinin ilerleme durumunu analiz edin.
• Sistemin genel kullanılabilirliğini belirli bir dönem için çalışma süresi yüzdesi olarak belirleyin.
• Sistemdeki tek tek bileşenlerin ve hizmetlerin kullanılabilirlik yüzdesini analiz edin. Bu, üçüncü taraf hizmetlerin oluşturduğu günlüklerin ayrıştırılmasını içerebilir.

Birçok ticari sistemin, belirli bir süre boyunca (genellikle bir ay) üzerinde anlaşmaya varılan SLA'lara karşı gerçek performans rakamlarını raporlaması gerekir. Bu bilgiler, SLA'lar bu dönemde karşılanmazsa müşterilerin kredilerini veya diğer geri ödeme biçimlerini hesaplamak için kullanılabilir. Kullanılabilirlik verilerini çözümleme bölümünde açıklanan tekniği kullanarak bir hizmetin kullanılabilirliğini hesaplayabilirsiniz.

Kuruluş, iç amaçlar doğrultusunda hizmetlerin başarısız olmasına neden olan olayların sayısını ve doğasını da izleyebilir. Bu sorunları hızla çözmeyi veya tamamen ortadan kaldırmayı öğrenmek, kapalı kalma süresini azaltmaya ve SLA'ları karşılamaya yardımcı olur.

Denetim

Uygulamanın niteliğine bağlı olarak, kullanıcıların işlemlerini denetleme ve tüm veri erişimini kaydetme gereksinimlerini belirten yasal veya diğer 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

Bir analistin, kullanıcıların eylemlerini yeniden oluşturabilmeniz için kullanıcıların gerçekleştirdiği iş işlemlerinin sırasını izleyebilmesi gerekir. Bu kayıt, belgeleme amacıyla veya adli araştırmanın bir parçası olarak gerekli olabilir.

Denetim bilgileri son derece hassastır. Büyük olasılıkla, sistem kullanıcılarını ve gerçekleştirdikleri görevleri tanımlayan verileri içerir. Bu nedenle, denetim bilgileri büyük olasılıkla grafik işlemlerin detayına gitmeyi destekleyen etkileşimli bir sistem yerine yalnızca güvenilen analistlerin kullanımına sunulan raporlar biçimindedir. Bir analistin bir dizi rapor oluşturabilmesi gerekir. Örneğin, raporlar belirli bir zaman diliminde gerçekleşen tüm kullanıcıların etkinliklerini listeleyebilir, tek bir kullanıcının etkinlik kronolojisini ayrıntılı olarak gösterebilir veya bir veya daha fazla kaynakta gerçekleştirilen işlemlerin sırasını listeleyebilirsiniz.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Denetim için birincil bilgi kaynakları şunlar olabilir:

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

Denetim verilerinin biçimi ve depolanma şekli mevzuat gereksinimleri tarafından yönlendirilebilir. Düzenlemeler, verilerin özgün biçiminde kaydedilmesini gerektiriyorsa, verilerin hiçbir şekilde temizlenmesi mümkün olmayabilir. Bu yüzden, manipülasyonu önlemek için deponun erişimi sıkı bir şekilde korunmalıdır.

Denetim verilerini çözümleme

Bir analistin ham verilere özgün biçiminde tamamen erişebilmesi gerekir. Ortak denetim raporları oluşturma gereksiniminin yanı sıra, bu verileri analiz etme araçları büyük olasılıkla özelleştirilebilir ve sistemin dışında tutulmalıdır.

Kullanım izleme

Kullanım izleme, bir uygulamanın özelliklerinin ve bileşenlerinin nasıl kullanıldığını izler. Bir operatör, toplanan verileri kullanarak:

• Hangi özelliklerin yoğun kullanıldığını belirleyin ve sistemdeki olası etkin noktaları belirleyin. Yüksek trafikli öğeler, yükü daha eşit bir şekilde yaymak için işlevsel bölümleme ve hatta çoğaltmadan yararlanabilir. Operatör bu bilgileri, hangi özelliklerin seyrek kullanıldığını ve sistemin gelecekteki bir sürümünde kullanımdan kaldırılması veya değiştirilmesi için olası adaylar olduğunu belirlemek için de kullanabilir.

• Sistemin normal kullanımdaki operasyonel olayları hakkında bilgi edinin. Örneğin, bir e-ticaret sitesinde, işlem sayısı ve bunlardan sorumlu olan müşterilerin hacmi hakkındaki istatistiksel bilgileri kaydedebilirsiniz. Bu bilgiler, müşteri sayısı arttıkça kapasite planlaması için kullanılabilir.

• Sistemin performansından veya işlevselliğinden kullanıcı memnuniyetini (muhtemelen dolaylı olarak) algılayın. Örneğin, bir e-ticaret sistemindeki çok sayıda müşteri alışveriş sepetlerini düzenli olarak terk ederse, bunun nedeni ödeme işleviyle ilgili bir sorun olabilir.

• Faturalama bilgileri oluşturun. Ticari bir uygulama veya çok kiracılı hizmet, müşterilerin kullandıkları kaynaklar için ücret alabilir.

• Kotaları zorunlu kılma. Çok kiracılı bir sistemdeki bir kullanıcı, belirtilen süre boyunca ü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.

• Gürültülü komşu sorunlarını algılama. Trafiğin eşit bir şekilde dağılıp dağılmadığını veya küçük bir kullanıcı grubunun trafiğin çoğunu oluşturup oluşturmadığını belirleyebilmek, hata araştırmalarını yönlendirebilir veya ürün kararlarına yardımcı olabilir. Uygulama özelliğini kullanan tek kullanıcı tek kullanıcıysa ve bu da büyük miktarda trafik oluşturuyorsa bu, özelliğin biraz performans ayarlaması gerektiği anlamına gelebilir. Alternatif olarak, sorunu çözmek için ek kotalar uygulamaya karar vekleyebilirsiniz.

Kullanım izleme gereksinimleri

Bir operatörün sistem kullanımını incelemek için genellikle şunları içeren 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 kullandığı veri depolama miktarı.
• Her kullanıcının eriştiği kaynaklar.

Bir işleç de graf oluşturabilmelidir. Oluşturulan graflara örnek olarak en çok kaynak kullanan kullanıcıları ve en sık erişilen kaynakları veya sistem özelliklerini gösteren bir grafik verilebilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Kullanım izleme, nispeten yüksek düzeyde gerçekleştirilebilir. Her isteğin başlangıç ve bitiş saatlerini ve isteğin niteliğini (söz konusu kaynağa bağlı olarak okuma, yazma ve diğer istekler) not alabilir. Bu bilgileri şu şekilde edinebilirsiniz:

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

Ö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. Toplanan bilgiler doğru faturalamayı etkinleştirecek kadar ayrıntılı olmalıdır.

Sorun izleme

Sistemde beklenmeyen olaylar veya davranışlar oluşursa müşteriler ve diğer kullanıcılar sorun bildirebilir. Sorun izleme, bu sorunları yönetmek, bunları sistemdeki temel sorunları çözmeye yönelik çabalarla ilişkilendirmek ve müşterileri olası çözümler hakkında bilgilendirmekle ilgilidir.

Sorun izleme gereksinimleri

Operatörler genellikle kullanıcıların bildirdiği sorunların ayrıntılarını kaydetmelerine ve raporlamalarına olanak tanıyan ayrı bir sistem kullanarak sorun izleme gerçekleştirir. Bu ayrıntılar kullanıcının gerçekleştirmeye çalıştığı görevleri, sorunun belirtilerini, olayların sırasını ve verilen hata veya uyarı iletilerini içerebilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sorun izleme verilerinin ilk veri kaynağı, sorunu ilk olarak 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ışan bir bileşen içeriyorsa).
• Ekran anlık görüntüsü.
• Hatanın oluştuğu tarih ve saat, kullanıcının konumu gibi diğer ortam bilgileriyle birlikte.

Bu bilgiler, hata ayıklama çabalarına yardımcı olmak ve yazılımın gelecekteki sürümleri için bir bekleme listesi oluşturmak amacıyla kullanılabilir.

Sorun izleme verilerini çözümleme

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

Hata ayıklama çalışmasının ilerleme durumu her sorun raporuna göre kaydedilmelidir. Sorun çözüldüğünde müşteri çözümden haberdar edilebilir.

Kullanıcı sorun izleme sisteminde bilinen bir çözümü olan bir sorun bildirirse, operatör kullanıcıyı çözümü hemen bilgilendirebilmelidir.

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

Bir kullanıcı bir sorun bildirdiğinde, kullanıcı genellikle yalnızca işlemleri üzerindeki hemen etkisinin farkında olur. Kullanıcı yalnızca kendi deneyiminin sonuçlarını sistemin bakımını yapmakla sorumlu olan bir operatöre bildirebilir. Bu deneyimler genellikle bir veya daha fazla temel sorunun görünür bir belirtisidir. Çoğu durumda, bir analistin sorunun kök nedenini oluşturmak için temel işlemlerin kronolojisini incelemesi gerekir. Bu işleme kök neden analizi adı verilir.

Uyarı

Kök neden analizi, bir uygulamanın tasarımındaki verimsizlikleri ortaya çıkartabilir. Bu gibi durumlarda, etkilenen öğelerin yeniden çalışması ve sonraki bir sürüm kapsamında dağıtılması mümkün olabilir. Bu işlem dikkatli bir denetim gerektirir ve güncelleştirilmiş bileşenler yakından izlenmelidir.

İzleme ve hata ayıklama gereksinimleri

Beklenmeyen olayları ve diğer sorunları izlemek için izleme verilerinin bir analistin bu sorunların çıkış noktalarını izlemesine ve oluşan olayların sırasını yeniden oluşturmasına olanak tanıyacak kadar bilgi sağlaması çok önemlidir. Bu bilgiler, analistin herhangi bir sorunun kök nedenini tanılamasını sağlamak için yeterli olmalıdır. Daha sonra bir geliştirici, yinelenenleri önlemek için gerekli değişiklikleri yapabilir.

Veri kaynakları, izleme ve veri toplama gereksinimleri

Sorun giderme, bir müşteri belirli bir istekte bulunduğunda sistemdeki mantıksal akışı gösteren bir ağaç oluşturmak için bir işlemin parçası olarak çağrılan tüm yöntemlerin (ve parametrelerinin) izlemeyi içerebilir. Sistemin bu akışın sonucu olarak oluşturduğu özel durumlar ve uyarıların yakalanması ve günlüğe kaydedilmesi gerekir.

Sistem, hata ayıklamayı desteklemek için operatörün sistemdeki önemli noktalarda durum bilgilerini yakalamasını sağlayan kancalar sağlayabilir. Alternatif olarak, seçilen işlemler ilerledikçe sistem ayrıntılı adım adım bilgi sağlayabilir. Verileri bu ayrıntı düzeyinde yakalamak sisteme ek yük oluşturabilir ve geçici bir işlem olmalıdır. tr-TR: Operatör, bu süreci özellikle, son derece sıra dışı bir dizi olay meydana geldiğinde ve tekrar etmesi zor olduğunda ya da bir veya birden fazla öğenin sisteme yeni bir sürümü dahil edildiğinde ve bu öğelerin beklendiği gibi çalıştığından emin olmak için dikkatli bir şekilde izlenmesi gerektiğinde 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 senaryoların her biri yalıtılmış olarak düşünülmemelidir. Her durum için gerekli olan izleme ve tanılama verilerinde büyük olasılıkla önemli bir çakışma olabilir, ancak bu verilerin farklı şekillerde işlenmesi ve sunulması gerekebilir. Bu nedenlerden dolayı izleme ve tanılamanın bütünsel bir görünümünü almalısınız.

İzleme ve tanılama işleminin tamamını Şekil 1'de gösterilen aşamaları oluşturan bir işlem hattı olarak öngörebilirsiniz.

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

Şekil 1'de izleme ve tanılama verilerinin çeşitli veri kaynaklarından nasıl alınabileceği vurgulanır. İzleme ve toplama aşamaları, verilerin yakalanması gereken kaynakları belirleme, hangi verilerin yakalanacağı, nasıl yakalanacağı ve kolayca incelenebilmesi için bu verilerin nasıl biçimlendirileceğiyle ilgilidir. Analiz/tanılama aşaması ham verileri alır ve bir operatörün sistemin durumunu belirlemek için kullanabileceği anlamlı bilgiler oluşturmak için kullanır. operatör, bu bilgileri, alınacak olası eylemler hakkında kararlar almak ve ardından sonuçları izleme ve toplama aşamalarına geri beslemek için kullanabilir. Görselleştirme/uyarı aşaması aşaması, sistem durumunun kullanılabilir bir görünümünü sunar. Bir dizi pano kullanarak bilgileri neredeyse gerçek zamanlı olarak görüntüleyebilir. Ayrıca, uzun vadeli eğilimleri belirlemeye yardımcı olabilecek verilerin geçmiş görünümünü sağlamak için raporlar, grafikler ve grafikler oluşturabilir. Bilgiler bir KPI'nın kabul edilebilir sınırları aşma olasılığını gösterirse, bu aşama bir operatör için uyarı da tetikleyebilir. Bazı durumlarda, otomatik ölçeklendirme gibi düzeltici eylemler gerçekleştirmeye çalışan otomatik bir işlemi tetikleyen bir uyarı da kullanılabilir.

Bu adımlar, aşamaların paralel olarak gerçekleştiği bir sürekli akış süreci oluşturur. İdeal olan, tüm aşamaların dinamik olarak yapılandırılabilir olmasıdır. Bazı noktalarda, özellikle bir sistem yeni dağıtıldığında veya sorunlarla karşılaştığında, genişletilmiş verilerin daha sık toplanması gerekebilir. Diğer durumlarda, sistemin düzgün çalıştığını doğrulamak için temel düzeyde temel bilgileri yakalamaya geri dönmek mümkün olmalıdır.

Buna ek olarak, tüm izleme süreci, geri bildirim sonucunda ince ayar ve iyileştirmelere tabi canlı ve sürekli bir çözüm olarak kabul edilmelidir. Örneğin, sistem durumunu belirlemek için birçok faktörü ölçmekle başlayabilirsiniz. Zaman içinde analiz, ilgili olmayan ölçüleri atarken iyileştirmeye yol açabilir ve arka plan gürültüsünü en aza indirirken ihtiyacınız olan verilere daha hassas bir şekilde odaklanmanızı sağlar.

İ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, sistemin koduna dahil edilen izleme günlüklerinden gelir. Geliştiriciler, kodlarında denetim akışını izlemek için standart bir yaklaşım izlemelidir. Örneğin, bir yönteme giriş yöntemin adını, geçerli saati, her parametrenin değerini ve diğer ilgili bilgileri belirten bir izleme iletisi yayar. Giriş ve çıkış saatlerinin kaydedilmesi de yararlı olabilir.

Tüm istisnaları ve uyarıları günlüğe kaydetmeli ve iç içe geçmiş istisnaların ve uyarıların tam izini muhafaza ettiğinizden emin olmalısınız. İdeal olarak, etkinlik bağıntı bilgileriyle birlikte (istekleri sistemden geçerken izlemek için) kodu çalıştıran kullanıcıyı tanımlayan bilgileri de yakalamanız gerekir. Ayrıca ileti kuyrukları, veritabanları, dosyalar ve diğer bağımlı hizmetler gibi tüm kaynaklara erişme girişimlerini günlüğe kaydetmeniz gerekir. Bu bilgiler ölçüm ve denetim amacı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 işlem hızları ile veri iletim başarıları ve hataları gibi ham tanılama bilgilerini sağlamak için yapılandırılabilir.

Uyarı

Birçok modern çerçeve, performans ve izleme olaylarını otomatik olarak yayımlar. Bu bilgilerin yakalanması, olayları almak ve depolamak için bir yol sağlayarak bunların işlenip analiz edilebilmesini sağlar.

Uygulamanın çalıştığı işletim sistemi G/Ç hızlarını, bellek kullanımını ve CPU kullanımını gösteren performans sayaçları gibi düşük düzey sistem genelindeki bilgilerin kaynağı olabilir. İşletim sistemi hataları (örneğin, bir dosyayı doğru açma hatası) da bildirilebilir.

Ayrıca, sisteminizin üzerinde çalıştığı temel altyapıyı ve bileşenleri de göz önünde bulundurmalısınız. Sanal makineler, sanal ağlar ve depolama hizmetlerinin tümü altyapı düzeyindeki önemli performans sayaçlarının ve diğer tanılama verilerinin kaynakları olabilir.

Uygulamanız web sunucusu veya veritabanı yönetim sistemi gibi diğer dış hizmetleri kullanıyorsa, bu hizmetler kendi izleme bilgilerini, günlüklerini ve performans sayaçlarını yayımlayabilir. Örnek olarak SQL Server veritabanında gerçekleştirilen işlemleri izlemeye yönelik SQL Server Dinamik Yönetim Görünümleri ve Azure App Service'e yapılan istekleri kaydetmek için Application Insights izleme günlükleri verilebilir.

Bir sistemin bileşenleri değiştirilip yeni sürümler dağıtıldığından, sorunları, olayları ve ölçümleri her sürüme özniteliklendirebilmek önemlidir. Bu bilgiler, bir bileşenin belirli bir sürümüyle ilgili sorunların hızla izlenebilmesi ve düzeltilmesi için yayın işlem hattına geri bağlanmalıdır.

Güvenlik sorunları sistemin herhangi bir noktasında oluşabilir. Örneğin, bir kullanıcı geçersiz bir 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. Veya bir kullanıcı şifrelenmiş bilgilere erişmek için geçersiz veya güncel olmayan bir anahtar sağlayabilir. Başarılı ve başarısız istekler için güvenlikle ilgili bilgiler her zaman günlüğe kaydedilmelidir.

Bir uygulamayı izleme bölümü, yakalamanız gereken bilgiler hakkında daha fazla kılavuz içerir. Ancak bu bilgileri toplamak için çeşitli stratejiler kullanabilirsiniz:

• Uygulama/sistem izleme. Bu strateji uygulama, uygulama çerçeveleri, işletim sistemi ve altyapı içindeki iç kaynakları kullanır. Uygulama kodu, bir istemci isteğinin yaşam döngüsü sırasında dikkate değer noktalarda kendi izleme verilerini oluşturabilir. Uygulama, koşullar gerektirdiğinde seçmeli olarak etkinleştirilebilen veya devre dışı bırakılmış olabilecek izleme deyimleri içerebilir. Tanılama çerçevesini kullanarak tanılamayı dinamik olarak eklemek de mümkün olabilir. Bu çerçeveler genellikle kodunuzdaki çeşitli izleme noktalarına eklenebilen ve bu noktalarda izleme verilerini yakalayabilen eklentiler sağlar.

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

• Gerçek kullanıcı izleme. Bu yaklaşım, kullanıcı ve uygulama arasındaki etkileşimleri kaydeder ve her isteğin ve yanıtın akışını gözlemler. Bu bilgilerin iki katlı bir amacı olabilir: Her kullanıcı tarafından kullanım ölçümü için kullanılabilir ve kullanıcıların uygun bir hizmet kalitesi (örneğin, hızlı yanıt süreleri, düşük gecikme süresi ve en düşük hatalar) alıp almadığını belirlemek için kullanılabilir. Yakalanan verileri, hataların en sık oluştuğu sorunları belirlemek için kullanabilirsiniz. Ayrıca, büyük olasılıkla uygulamadaki etkin noktalardan veya başka bir performans sorunundan dolayı sistemin yavaşladığı öğeleri tanımlamak için de verileri kullanabilirsiniz. Bu yaklaşımı dikkatli bir şekilde uygularsanız, hata ayıklama ve test amacıyla uygulama üzerinden kullanıcı akışlarını yeniden yapılandırmak mümkün olabilir.

  Önemli

  Gerçek kullanıcıların izlenmesiyle yakalanan verilerin gizli malzeme içerebileceğinden yüksek oranda hassas olduğunu göz önünde bulundurmalısınız. Yakalanan verileri kaydederseniz güvenli bir şekilde depolayı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 simülasyonunu yapan ve yapılandırılabilir ancak tipik bir işlem serisi gerçekleştiren kendi test istemcinizi yazarsınız. Sistemin durumunu belirlemeye yardımcı olması için test istemcisinin performansını izleyebilirsiniz. Sistemin stres altında nasıl yanıt verdiğini ve bu koşullar altında ne tür bir izleme çıkışı oluşturulduğunu oluşturmak için yük testi işleminin bir parçası olarak test istemcisinin birden çok örneğini de kullanabilirsiniz.

  Uyarı

  Bir uygulamanın yöntem çağrılarını ve diğer kritik bölümlerini izleyen ve zamanlayan kod ekleyerek gerçek ve yapay kullanıcı izleme uygulayabilirsiniz.

• Profil oluşturma. Bu yaklaşım öncelikli olarak uygulama performansını izlemeyi ve geliştirmeyi hedefler. Gerçek ve yapay kullanıcı izlemenin işlevsel düzeyinde çalışmaktansa, uygulama çalışırken alt düzey bilgileri yakalar. Bir uygulamanın yürütme durumunun düzenli örneklemesini kullanarak profil oluşturma uygulayabilirsiniz (uygulamanın belirli bir zamanda hangi kod parçasını çalıştırdığını belirleme). Ayrıca önemli noktalarda (yöntem çağrısının başlangıcı ve sonu gibi) koda yoklamalar ekleyen ve hangi yöntemlerin çağrıldığı, ne zaman ve her çağrının ne kadar sürdüğünü kaydeden izleme özelliğini de kullanabilirsiniz. Ardından, uygulamanın hangi bölümlerinin performans sorunlarına neden olabileceğini belirlemek için bu verileri analiz edebilirsiniz.

• Uç nokta izleme. Bu teknik, uygulamanın izlemeyi etkinleştirmek için özel olarak kullanıma sağladığı bir veya daha fazla tanılama uç noktasını kullanır. Uç nokta, uygulama koduna bir yol sağlar ve sistemin durumu hakkında bilgi döndürebilir. Farklı uç noktalar işlevselliğin çeşitli yönlerine odaklanabilir. Bu uç noktalara düzenli aralıklarla istek gönderen ve yanıtları asimile eden kendi tanılama istemcinizi yazabilirsiniz. Daha fazla bilgi için bkz. Sağlık Uç Noktası İzleme deseni.

• Kullanıcı hata dökümleri. Bu teknik, bir uygulamanın kurtarılamadığı durumlarda uygulama durumunun bir anlık görüntüsünü toplamaya ve kullanıcıların bu anlık görüntüyü gönüllü olarak paylaşmasına düzgün bir yol sağlamaya dayanır. Her zaman çalıştırılması garanti edilmese de, hata dökümü tarafından sağlanan alt düzey veriler, hataların kök nedenini belirlemek için son derece yararlı olabilir. Bu, özellikle söz konusu hataların seyrek gerçekleşmesi veya hataların uygulamada yaygın olarak kullanılan bir özelliğe yalıtılmış olması durumunda geçerlidir.

Maksimum kapsam için bu tekniklerin bir bileşimini kullanmanız gerekir.

Uygulamayı araçlarla donatma

Enstrümantasyon, izleme sürecinin kritik bir parçasıdır. Bir sistemin performansı ve durumu hakkında anlamlı kararlar almak için bu kararları vermenizi sağlayan verileri ilk kez yakalamanız gerekir. Enstrümantasyon kullanarak topladığınız bilgiler, uzaktan üretim sunucusuna giriş yaparak manuel izleme (ve hata ayıklama) yapmanıza gerek kalmadan, performansı değerlendirebilmenizi, sorunları teşhis edebilmenizi ve kararlar alabilmenizi sağlamak için yeterli olmalıdır. Enstrümantasyon verileri, genellikle 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. Ayrıca, altyapının web sunucusu gibi bölümlerinden kaynaklanan olayları kaydeden sistem günlüklerinden de oluşturulabilirler. Metin günlüğü iletileri genellikle insan tarafından okunabilir olacak şekilde tasarlanmıştır, ancak otomatik bir sistemin bunları kolayca ayrıştırmasını sağlayan bir biçimde de yazılmalıdır.

Günlükleri de kategorilere ayırmanız gerekir. Tüm izleme verilerini tek bir günlüğe yazmayın, ancak izleme çıkışını sistemin farklı işletimsel yönlerinden kaydetmek için ayrı günlükler kullanın. Daha sonra, tek bir uzun dosyayı işlemek yerine uygun günlükten okuyarak günlük iletilerini hızla filtreleyebilirsiniz. Farklı güvenlik gereksinimleri (denetim bilgileri ve hata ayıklama verileri gibi) olan bilgileri hiçbir zaman aynı günlüğe yazmayın.

Uyarı

Günlük, dosya sisteminde dosya olarak gerçekleştirilebilir veya blob depolamadaki blob gibi farklı bir biçimde tutulabilir. Günlük bilgileri, tablodaki satırlar gibi daha yapılandırılmış bir depolama alanında da tutulabilir.

Ölçümler genellikle bir veya daha fazla ilişkili etiket veya boyutla (bazen örnek olarak da adlandırılır) belirli bir zamanda sistemdeki bazı yön veya kaynakların ölçüsü veya sayısıdır. Bir ölçümün tek bir örneği genellikle yalıtımlı olarak yararlı olmaz. Bunun yerine ölçümlerin zaman içinde yakalanması gerekir. Dikkate alınması gereken temel sorun, hangi ölçümleri ve ne sıklıkta kaydetmeniz gerektiğidir. Ölçümler için verilerin çok sık oluşturulması sisteme önemli bir ek yük oluşturabilirken, ölçümleri nadiren yakalamak önemli bir olaya neden olan koşulları kaçırmanıza neden olabilir. Dikkat edilmesi gerekenler ölçümden ölçüme farklılık gösterir. Örneğin, bir sunucudaki CPU kullanımı saniyeden saniyeye dalgalanabilir, ancak yüksek kullanım yalnızca birkaç dakika devam ederse sorun haline gelir.

Verileri ilişkilendirmeye yönelik bilgiler

Sistem düzeyindeki performans sayaçlarını kolayca izleyebilir, kaynaklar için ölçümleri yakalayabilir ve çeşitli günlük dosyalarından uygulama izleme bilgilerini alabilirsiniz. Ancak bazı izleme biçimleri, çeşitli kaynaklardan alınan verileri ilişkilendirmek için izleme işlem hattındaki analiz ve tanılama aşamasını gerektirir. Bu veriler ham verilerde çeşitli formlar alabilir ve analiz işlemine bu farklı formları eşleyebilmek için yeterli izleme verileri sağlanmalıdır. Örneğin, uygulama çerçevesi düzeyinde bir görev iş parçacığı kimliğiyle tanımlanabilir. Bir uygulama içinde aynı çalışma, bu görevi gerçekleştiren kullanıcının kullanıcı kimliğiyle ilişkilendirilebilir.

Ayrıca, zaman uyumsuz işlemler birden fazla kullanıcı adına işlem gerçekleştirmek için aynı iş parçacıklarını yeniden kullanabileceğinden, iş parçacıkları ve kullanıcı istekleri arasında 1:1 eşlemesi olması pek olası değildir. Durumu daha da karmaşıklaştırmak için, tek bir istek, yürütme sistem içinde aktıkça birden fazla iş parçacığı tarafından işlenebilir. Mümkünse, her isteği istek bağlamının bir parçası olarak sistem aracılığıyla yayılan benzersiz bir etkinlik kimliğiyle ilişkilendirin. (İzleme bilgilerine etkinlik kimlikleri oluşturma ve ekleme tekniği, izleme verilerini yakalamak için kullanılan teknolojiye bağlıdır.)

Tüm izleme verileri aynı şekilde zaman damgasına alınmalıdır. Tutarlılık için Eşgüdümlü Evrensel Saat (UTC) kullanarak tüm tarih ve saatleri kaydedin. Bu, olay dizilerini daha kolay izlemenize yardımcı olur.

Uyarı

Farklı saat dilimlerinde ve ağlarda çalışan bilgisayarlar eşitlenmeyebilir. Birden çok makineye yayılan izleme verilerini ilişkilendirmek için yalnızca zaman damgalarını kullanmaya bağımlı değilsiniz.

Enstrümantasyon verilerine eklenecek bilgiler

Hangi izleme verilerini toplamanız gerektiğini belirlerken aşağıdaki noktaları göz önünde bulundurun:

• İzleme olayları tarafından yakalanan bilgilerin makine ve insan tarafından okunabilir olduğundan emin olun. Sistemlerde 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 bilgiler için iyi tanımlanmış şemaları benimseyin. Dağıtım ortamı, işlemin çalıştığı makine, işlemin ayrıntıları ve çağrı yığını gibi ortam bilgilerini ekleyin.

• Profil oluşturmayı yalnızca gerektiğinde etkinleştirin çünkü sistemde önemli bir ek yük oluşturabilir. Araç kullanımı ile profil çıkarma, her gerçekleştiğinde bir olayı (yöntem çağrısı gibi) 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şirse, izleme yoluyla profil oluşturma çok fazla yüke neden olabilir ve genel performansı etkileyebilir. Bu durumda örnekleme yaklaşımı tercih edilebilir. Ancak olayların sıklığı düşükse örnekleme bunları kaçırabilir. Bu durumda araçlandırma daha iyi bir yaklaşım olabilir.

• Bir geliştiricinin veya yöneticinin her isteğin kaynağını belirlemesini sağlamak için yeterli bağlam sağlayın. Bu, bir isteğin belirli bir örneğini tanımlayan bir etkinlik kimliği biçimi içerebilir. Ayrıca, bu etkinliği gerçekleştirilen hesaplama çalışması ve kullanılan kaynaklarla ilişkilendirmek için kullanılabilecek bilgiler de içerebilir. Bu çalışma işlem ve makine sınırlarını aşabilir. Ölçüm için bağlam, isteğin yapılmasına neden olan müşteriye yönelik bir başvuruyu da (doğrudan veya dolaylı olarak diğer bağıntılı bilgiler aracılığıyla) içermelidir. Bu bağlam, izleme verilerinin yakalandığı sırada uygulama durumu hakkında değerli bilgiler sağlar.

• Tüm istekleri ve bu isteklerin yapıldığı konumları veya bölgeleri kaydedin. Bu bilgiler konuma özgü etkin noktaların olup olmadığını belirlemeye yardımcı olabilir. Bu bilgiler, bir uygulamanın mı yoksa kullandığı verilerin mi yeniden bölümlendiğini belirlemede de yararlı olabilir.

• Özel durumların ayrıntılarını dikkatle kaydedin ve yakalayın. Genellikle, kötü özel durum işlemenin bir sonucu olarak kritik hata ayıklama bilgileri kaybolur. İç özel durumlar ve diğer bağlam bilgileri de dahil olmak üzere uygulamanın attığı özel durumların tüm ayrıntılarını yakalayın. Mümkünse çağrı yığınını ekleyin.

• Uygulamanızın farklı öğelerinin yakaladığı verilerde tutarlı olun çünkü bu, olayları analiz etmeye ve bunları kullanıcı istekleriyle ilişkilendirmeye yardımcı olabilir. Geliştiricilerin sistemi farklı şekillerde uygularken aynı yaklaşımı benimsemelerine bağlı kalmak yerine, bilgi toplamak için kapsamlı ve yapılandırılabilir bir günlük paketi kullanmayı düşünün. Gerçekleştirilen G/Ç hacmi, ağ kullanımı, istek sayısı, bellek kullanımı ve CPU kullanımı gibi önemli performans sayaçlarından veri toplayın. Bazı altyapı hizmetleri, bir veritabanına bağlantı sayısı, işlemlerin gerçekleştirilma hızı ve başarılı veya başarısız olan işlem sayısı gibi kendi performans sayaçlarını sağlayabilir. Uygulamalar kendi performans sayaçlarını da tanımlayabilir.

• Veritabanı sistemleri, web hizmetleri veya altyapının parçası olan diğer sistem düzeyindeki hizmetler gibi dış hizmetlere yapılan tüm çağrıları günlüğe kaydedin. Her çağrıyı gerçekleştirmek için geçen süre ve çağrının başarısı veya başarısızlığı hakkındaki bilgileri kaydedin. Mümkünse, meydana gelen geçici hatalarla ilgili tüm yeniden deneme girişimlerini ve hataları hakkındaki bilgileri yakalayın.

Telemetri sistemleriyle uyumluluğu sağlama

Çoğu durumda, izlemenin ürettiği bilgiler bir dizi olay olarak oluşturulur ve işleme ve analiz için ayrı bir telemetri sistemine geçirilir. Telemetri sistemi genellikle belirli bir uygulama veya teknolojiden bağımsızdır, ancak bilgilerin genellikle şema tarafından tanımlanan belirli bir biçimi izlemesini bekler. Şema, telemetri sisteminin alabildiği veri alanlarını ve türlerini tanımlayan bir sözleşmeyi etkili bir şekilde belirtir. Şema, çeşitli platformlardan ve cihazlardan gelen verilere izin verecek şekilde genelleştirilmelidir. Yaygın olarak kullanılan çerçeve ve şemalardan biri OpenTelemetry'dir.

Ortak şema, olay adı, olay zamanı, gönderenin IP adresi ve diğer olaylarla (kullanıcı kimliği, cihaz kimliği ve uygulama kimliği gibi) bağıntı için gereken ayrıntılar gibi tüm izleme olaylarında ortak olan alanları içermelidir. Herhangi bir sayıda cihazın olay oluşturabileceğini, dolayısıyla şemanın cihaz türüne bağlı olmaması gerektiğini unutmayın. Ayrıca, çeşitli cihazlar aynı uygulama için olaylar tetikleyebilir. Uygulama, dolaşım veya diğer bir cihazlar arası dağıtım biçimini destekleyebilir.

Şema, farklı uygulamalarda ortak olan belirli bir senaryoyla ilgili etki alanı alanlarını 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. Aynı etki alanı alanı kümesini kullanan tüm uygulamalar aynı olay kümesini yayarak bir dizi ortak rapor ve analiz oluşturulabilmesini sağlamalıdır.

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

Uygulamaların enstrümantasyonu için en iyi yöntemler

Aşağıdaki listede, bulutta çalışan bir dağıtılmış uygulamayı izlemeye yönelik en iyi yöntemler özetlemektedir.

• Günlükleri okunabilir ve ayrıştırılabilir hale getirin. Mümkün olduğunda yapılandırılmış günlüğe kaydetmeyi kullanın. Günlük iletilerinde kısa ve açıklayıcı olun.

• Tüm günlüklerde kaynağı tanımlayın ve her günlük kaydı yazılırken 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ışan donanım ve hizmetlere yayılan işlemler için olayları ilişkilendirmeye yardımcı olur.

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

• Sistemle ilgili hassas bilgileri veya kullanıcılar hakkındaki kişisel bilgileri ifşa etmeyin. Bu bilgileri günlüğe kaydetmeden önce temizleyin, ancak ilgili ayrıntıların korunduğundan emin olun. Örneğin, herhangi bir veritabanı bağlantı dizesinden kimlik ve parolayı kaldırın, ancak analistin sistemin doğru veritabanına eriştiğini belirleyebilmesi için kalan bilgileri günlüğe yazın. Tüm kritik özel durumları günlüğe kaydedin, ancak yöneticinin daha düşük özel durum ve uyarı düzeyleri için günlüğe kaydetmeyi açıp kapatmasını sağlayın. Ayrıca, tüm yeniden deneme mantığı bilgilerini yakalayın ve günlüğe yazın. Bu veriler, sistemin geçici durumunu izlemede yararlı olabilir.

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

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

• Denetim olayları dışında, tüm günlük çağrılarının iş işlemlerinin ilerleme durumunu engellemeyen tetikleme ve unutma işlemleri olduğundan emin olun. Denetim olayları istisnaidir çünkü bunlar iş için kritik öneme sahiptir ve iş operasyonlarının temel bir parçası olarak sınıflandırılabilir.

• Günlüğün genişletilebilir olduğundan ve somut bir hedefe doğrudan bağımlılıkları olmadığından emin olun. Örneğin, System.Diagnostics.Trace kullanarak bilgi yazmak yerine, ILogger gibi günlükleme yöntemlerine imkan sağlayan ve uygun herhangi bir yöntemle uygulanabilen bir soyut arabirim tanımlayın.

• Tüm günlüklerin güvenli bir şekilde çalıştığından ve asla basamaklı hataları tetiklemediğinden emin olun. Kayıt tutma hiçbir istisna oluşturmamalıdır.

• Enstrümantasyonu sürekli tekrarlanan bir süreç olarak ele alın ve yalnızca sorun olduğunda değil, günlükleri düzenli olarak gözden geçirin.

Veri toplama ve depolama

İzleme işleminin toplama aşaması, izlemenin oluşturduğu bilgilerin alınması, analiz/tanılama aşamasının daha kolay tüketilmesi için bu verileri biçimlendirme ve dönüştürülen verilerin güvenilir depolama alanına kaydedilmesiyle ilgilidir. Dağıtılmış bir sistemin farklı bölümlerinden topladığınız izleme verileri çeşitli konumlarda ve farklı 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ı diğer teknolojiler aracılığıyla yakalanabilir. Uygulamanızın kullandığı tüm üçüncü taraf bileşenler ve hizmetler ayrı izleme dosyaları, blob depolama ve hatta özel bir veri deposu kullanarak izleme bilgilerini farklı biçimlerde sağlayabilir.

Veri toplama genellikle izleme verilerini oluşturan uygulamadan otonom olarak çalışabilen bir toplama hizmeti aracılığıyla gerçekleştirilir. Şekil 2'de bu mimarinin bir örneği gösterilmektedir ve izleme veri toplama alt sistemi vurgulanmaktadır.

Şekil 2 - İzleme verilerini toplama.

Bu basitleştirilmiş bir görünümdür. Koleksiyon hizmetinin tek bir işlem olması şart değildir ve aşağıdaki bölümlerde açıklandığı gibi farklı makinelerde çalışan birçok kurucu parçadan oluşabilir. Ayrıca, bazı telemetri verilerinin hızlı bir şekilde analiz edilmesi gerekiyorsa (bu belgenin devamında Sıcak, ılık ve soğuk analiz desteği bölümünde açıklandığı gibi sıcak analiz), toplama hizmeti 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österilmektedir. Analiz işlemeden sonra sonuçlar doğrudan görselleştirmeye ve uyarı alt sistemine gönderilebilir. Sıcak veya soğuk analize tabi tutulan veriler, işlenmeyi beklerken depolamada tutulur.

Azure uygulamaları ve hizmetleri için Azure Tanılama, veri yakalamaya yönelik olası bir çözüm sağlar. Azure Tanılama, her işlem düğümü için aşağıdaki kaynaklardan verileri 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ı
• Çökme dökümleri
• Azure Tanılama altyapısı günlükleri
• Özel hata günlükleri
• .NET Olay Kaynağı
• Manifesto tabanlı ETW

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

Araç verilerini toplama stratejileri

Bulutun elastik niteliğini göz önünde bulundurarak ve sistemdeki her düğümden telemetri verilerini el ile alma zorunluluğunu önlemek için, verilerin merkezi bir konuma aktarılmasını ve birleştirilmesini düzenlemeniz gerekir. Birden çok veri merkezine yayılan bir sistemde, önce verileri bölgelere göre toplamak, birleştirmek ve depolamak ve ardından bölgesel verileri tek bir merkezi sistemde toplamak yararlı olabilir.

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

Araçsal verileri çekme ve gönderme

İnstrümantasyon veri toplama alt sistemi, her uygulama örneği için çeşitli günlüklerden ve diğer kaynaklardan instrümantasyon verilerini etkin bir şekilde alabilir ( çekme modeli). Alternatif olarak, uygulamanın her örneğini oluşturan bileşenlerden ( gönderim modeli) verilerin gönderilmesini bekleyen pasif bir alıcı gibi davranabilir.

Çekme modelini uygulamaya yönelik bir yaklaşım, uygulamanın her örneğiyle yerel olarak çalışan izleme aracılarını kullanmaktır. İzleme aracısı, yerel düğümde toplanan telemetri verilerini düzenli aralıklarla alan (çeken) ve bu bilgileri doğrudan uygulama örneklerinin paylaştığı merkezi depolama alanına yazan ayrı bir işlemdir. Bu, Azure İzleyici Aracısı'nın uyguladığı mekanizmadır. Her işlem örneği, tanılamayı ve yerel olarak depolanan diğer izleme bilgilerini yakalayacak şekilde yapılandırılabilir. Her örnekle birlikte çalışan izleme aracısı belirtilen verileri toplar ve Azure İzleyici'ye gönderir. IIS günlükleri, kilitlenme dökümleri ve özel hata günlükleri gibi bazı öğeler blob depolamaya yazılır. Windows olay günlüğü, ETW olayları ve performans sayaçlarındaki veriler tablo depolama alanına kaydedilir. Şekil 3'de bu mekanizma gösterilmektedir.

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

Uyarı

İzleme aracısının kullanımı, veri kaynağından doğal olarak çekilen ölçümlü izleme verilerini yakalamaya çok uygundur. Sql Server Dinamik Yönetim Görünümlerindeki bilgiler veya Azure Service Bus kuyruğunun uzunluğu buna örnek olarak verilmiştir.

Sınırlı sayıda düğümde çalışan küçük ölçekli bir uygulamanın telemetri verilerini tek bir konumda depolamak için az önce açıklanan yaklaşımı kullanmak mümkündür. Ancak karmaşık, yüksek oranda ölçeklenebilir, küresel bir bulut uygulaması yüzlerce işlem örneğinden, veritabanı parçalarından ve diğer hizmetlerden çok büyük miktarlarda veri oluşturabilir. Bu veri akışı, tek bir merkezi konumla sağlanan G/Ç bant genişliğini kolayca zorlayabilir. Bu nedenle, sistem genişledikçe performans sorunu olarak davranmasını önlemek için telemetri çözümünüzün ölçeklenebilir olması gerekir. İdeal olarak, sistemin bir parçasının başarısız olması durumunda önemli izleme bilgilerini (denetim veya faturalama verileri gibi) kaybetme risklerini azaltmak için çözümünüz bir derece yedeklilik içermelidir.

Bu sorunları gidermek için, Şekil 4'te gösterildiği gibi kuyruğa alma uygulayabilirsiniz. Bu mimaride, yerel izleme aracısı (uygun şekilde yapılandırılabilirse) veya özel veri toplama hizmeti (değilse) verileri kuyruğa gönderir. Zaman uyumsuz olarak çalışan ayrı bir işlem (Şekil 4'teki depolama yazma hizmeti), bu kuyruktaki verileri alır ve paylaşılan depolama alanına yazar. İleti kuyruğu, kuyruğa alınan verilerin gönderildikten sonra kaybolmamasını sağlamaya yardımcı olan "en az bir kez" semantik sağladığından bu senaryo için uygundur. Ayrı bir arka plan işlemi kullanarak depolama yazma hizmetini uygulayabilirsiniz.

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

Yerel veri toplama hizmeti, alındıktan hemen sonra kuyruğa veri ekleyebilir. Kuyruk bir arabellek görevi görür ve depolama yazma hizmeti verileri kendi hızıyla alıp yazabilir. Varsayılan olarak, kuyruk ilk gelen ilk çıkar temelinde çalışır. Ancak, daha hızlı işlenmesi gereken veriler içeriyorsa, iletileri kuyruk aracılığıyla hızlandırmak için önceliklerini belirtebilirsiniz. Daha fazla bilgi için bkz . Öncelik Sırası düzeni. Alternatif olarak, gerekli analitik işleme biçimine bağlı olarak verileri farklı hedeflere yönlendirmek için farklı kanallar (Service Bus konuları gibi) kullanabilirsiniz.

Ölçeklenebilirlik için depolama yazma hizmetinin birden çok örneğini çalıştırabilirsiniz. Yüksek hacimli olaylar varsa, verileri işleme ve depolama için farklı işlem kaynaklarına göndermek için bir olay hub'ı kullanabilirsiniz.

Enstrümantasyon verilerini birleştirme

Veri toplama hizmetinin bir uygulamanın tek bir örneğinden edindiği izleme verileri, bu örneğin sistem durumu ve performansına ilişkin yerelleştirilmiş bir görünüm sağlar. Sistemin genel durumunu değerlendirmek için verilerin bazı yönlerini yerel görünümlerde birleştirmek gerekir. Veriler depolandıktan sonra bunu gerçekleştirebilirsiniz, ancak bazı durumlarda veriler toplandıktan sonra da bunu gerçekleştirebilirsiniz. İzleme verileri, doğrudan paylaşılan depolamaya yazılmak yerine verileri birleştiren ve filtre ve temizleme işlemi işlevi gören ayrı bir veri birleştirme hizmetinden geçebilir. Örneğin, etkinlik kimliği gibi aynı bağıntı bilgilerini içeren izleme verileri birleştirilebilir. (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'de bu yapıya bir örnek gösterilmiştir.

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

Enstrümantasyon verilerini depolama

Önceki tartışmalarda izleme verilerinin nasıl depolandığına ilişkin oldukça basit bir görünüm gösteriliyordu. Gerçekte, her türün kullanılma olasılığına en uygun teknolojileri kullanarak farklı bilgi türlerini depolamak mantıklı olabilir.

Örneğin, Azure blob ve tablo depolama, erişim yolları açısından bazı benzerliklere sahiptir. Ancak, bunları kullanarak gerçekleştirebileceğiniz işlemlerde sınırlamaları vardır ve bunların barındırdığı 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ükleri Azure Cosmos DB'de daha iyi depolanabilir.
• Güvenlik bilgileri HDFS'ye yazılabilir.
• Tam metin araması gerektiren bilgiler Elasticsearch aracılığıyla depolanabilir (bu da zengin dizin oluşturma kullanarak aramaları hızlandırabilir).

Verileri paylaşılan depolama alanından düzenli aralıklarla alan, verileri amacına göre bölümleyen ve filtreleyen ve ardından Şekil 6'da gösterildiği gibi uygun bir veri deposu 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 hizmeti üzerindeki yükü azaltır ve gerekirse bölümlenmiş verilerin en az bir kısmının yeniden üretilmesini sağlar (paylaşılan depolamada ne kadar veri bulunduğuna bağlı olarak). Ancak, 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. Bu gibi durumlarda, aynı veriler faturalama bilgilerini tutmak için uzun vadeli bir depo olarak davranabilen bir belge veritabanı ve karmaşık performans analizini işlemek için çok boyutlu bir depo gibi birden fazla hedefe gönderilebilir.

Ayrıca verilerin ne kadar acil bir şekilde gerekli olduğunu da göz önünde bulundurmalısınız. Uyarı için bilgi sağlayan verilere hızlı bir şekilde erişilmelidir, bu nedenle hızlı veri depolamada tutulmalıdır ve uyarı sisteminin gerçekleştirdiği sorguları iyileştirmek için dizine alınmalıdır veya yapılandırılmış olmalıdır. Bazı durumlarda, her düğümdeki verileri toplayan telemetri hizmetinin verileri yerel olarak biçimlendirmesi ve kaydetmesi gerekebilir; böylece uyarı sisteminin yerel bir ö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 dikkate alınması gereken analiz, raporlama ve geçmiş eğilimleri tespit etme amacıyla kullanılan bilgiler daha az acildir ve veri madenciliği ve geçici sorguları destekleyecek şekilde depolanabilir. Daha fazla bilgi için, bu belgenin devamındaki Sıcak, ılık ve soğuk analiz desteği bölümüne bakın.

Günlük döndürme ve veri saklama

Enstrümantasyon, büyük miktarda veri oluşturabilir. Bu veriler, ham günlük dosyaları, iz dosyaları ve her düğümde yakalanan diğer bilgilerden başlayan ve paylaşılan depolamada tutulan bu verilerin birleştirilmiş, temizlenmiş ve bölümlenmiş görünümüne kadar farklı yerlerde tutulabilir. Bazı durumlarda veriler işlenip aktarıldıktan sonra özgün ham kaynak verileri her düğümden kaldırılabilir. Diğer durumlarda ham bilgileri kaydetmek gerekli veya yararlı olabilir. Örneğin, hata ayıklama amacıyla oluşturulan veriler en iyi şekilde ham biçiminde kullanılabilir durumda kalabilir, ancak hatalar düzeltildikten sonra hızla atılabilir.

Performans verilerinin ömrü genellikle daha uzundur, böylece performans eğilimlerini saptamak ve kapasite planlaması için 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. Ayrıca, mevzuat gereksinimleri denetim ve güvenlik amacıyla toplanan bilgilerin de arşivlenmesi ve kaydedilmesini gerektirebilir. Bu veriler de hassastır ve müdahaleyi önlemek için şifrelenmesi veya başka türlü korunması gerekebilir. Kullanıcıların parolalarını veya kimlik sahtekarlığı 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 verileri tamamen kaydetmek yerine, çözünürlüğünü azaltmak ve depolama maliyetlerinden tasarruf etmek için verileri aşağı örneklemek mümkün olabilir. Örneğin, dakika dakika performans göstergelerini kaydetmek yerine, bir aydan daha eski olan verileri birleştirerek bir saatlik görünüm oluşturabilirsiniz.

Günlük bilgilerini toplamak ve depolamak için en iyi uygulamalar

Aşağıdaki listede günlük bilgilerini yakalamaya ve depolamaya yönelik en iyi uygulamalar özetlenmektedir:

• İzleme aracısı veya veri toplama hizmeti, işlem dışı bir hizmet olarak çalışmalı ve dağıtımı basit olmalıdır.

• İzleme aracısından veya veri toplama hizmetinden alınan tüm çıkışlar makineden, işletim sisteminden veya ağ protokolünden bağımsız, belirsiz bir biçim olmalıdır. Örneğin, bilgileri ETL/ETW yerine JSON, MessagePack veya Protobuf gibi kendi kendine açıklayan bir biçimde yayımlayın. Standart bir biçim kullanmak, sistemin işlem hatlarını oluşturmasına olanak tanır; üzerinde anlaşmaya varılan biçimde veri okuyan, dönüştüren ve gönderen bileşenler kolayca tümleştirilebilir.

• İzleme ve veri toplama işlemi, başarısızlığa karşı güvenli olmalı ve basamaklı hata koşullarını tetiklememelidir.

• Veri havuzuna bilgi gönderirken geçici bir hata olması durumunda, izleme aracısı veya veri toplama hizmeti en yeni bilgilerin ilk olarak gönderilmesi için telemetri verilerini yeniden sıralamaya hazır olmalıdır. (İzleme aracısı/veri toplama hizmeti, kendi takdirine bağlı olarak eski verileri bırakmayı veya yerel olarak kaydedip daha sonra iletmeyi seçebilir.)

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

İzleme ve tanılama sürecinin önemli bir parçası, toplanan verileri analiz ederek sistemin genel refahının bir resmini elde etmektir. Kendi KPI'lerinizi ve performans ölçümlerinizi tanımlamış olmanız gerekir ve analiz gereksinimlerinizi karşılamak için toplanan verileri nasıl yapılandırabileceğinizi anlamanız önemlidir. Farklı ölçümlerde ve günlük dosyalarında yakalanan verilerin nasıl ilişkilendirildiğini anlamak da önemlidir, çünkü bu bilgiler bir dizi olayı izlemenin ve ortaya çıkan sorunların tanılanmasında önemli olabilir.

İzleme verilerini birleştirme bölümünde açıklandığı gibi, sistemin her bir parçasına ait veriler genellikle yerel olarak yakalanır, ancak genellikle sisteme katılan diğer sitelerde oluşturulan verilerle birleştirilmelidir. Bu bilgiler, verilerin doğru bir şekilde birleştirildiğinden emin olmak için dikkatli bir bağıntı gerektirir. Örneğin, bir işlemin kullanım verileri kullanıcının bağlandığı bir web sitesini barındıran bir düğüme, bu işlemin bir parçası olarak erişilen ayrı bir hizmeti çalıştıran bir düğüme ve başka bir düğümde tutulan veri depolama alanına yayabilir. Bu bilgilerin, işlemin kaynak ve işleme kullanımının genel bir görünümünü sağlamak için 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.

Sıcak, ılık ve soğuk analizi destekleme

Görselleştirme, raporlama ve uyarı amacıyla verileri çözümlemek ve yeniden biçimlendirmek, kendi kaynak kümesini kullanan karmaşık bir işlem olabilir. Bazı izleme biçimleri zaman açısından kritiktir ve etkili olması için verilerin hemen analiz edilmesini gerektirir. Bu, sıcak analiz olarak bilinir. Uyarılar için gerekli analizler ve güvenlik izlemenin bazı yönleri (sisteme yönelik bir saldırıyı algılama gibi) örnekler verilebilir. Bu amaçlar için gerekli olan verilerin verimli işleme için hızlı bir şekilde kullanılabilir ve yapılandırılmış olması gerekir. Bazı durumlarda analiz işleminin verilerin tutulduğu tek tek düğümlere taşınması gerekebilir.

Diğer analiz biçimleri daha az zaman açısından kritiktir ve ham veriler alındıktan sonra biraz hesaplama ve toplama gerektirebilir. Buna sıcak analiz denir. Performans analizi genellikle bu kategoriye girer. Bu durumda, yalıtılmış, tek bir performans olayının istatistiksel olarak anlamlı olma olasılığı düşüktür. (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.

Isı analizi, sağlık sorunlarını tanılamaya yardımcı olmak için de kullanılabilir. Bir sağlık olayı genellikle anlık analiz aracılığıyla işlenir ve hemen bir uyarı oluşturabilir. Operatör, sıcak yoldan verileri inceleyerek sağlık durumu olayının nedenlerini inceleyebilmelidir. Bu veriler, sağlık olayına neden olan soruna yol açan olaylar hakkında bilgi içermelidir.

Bazı izleme türleri daha uzun vadeli veriler oluşturur. Bu analiz, muhtemelen önceden tanımlanmış bir zamanlamaya göre daha sonraki bir tarihte gerçekleştirilebilir. Bazı durumlarda, analizin belirli bir süre boyunca yakalanan büyük hacimli verilerde karmaşık filtreleme gerçekleştirmesi gerekebilir. Buna soğuk analiz denir. Önemli gereksinim, verilerin yakalandıktan sonra güvenli bir şekilde depolanmasıdır. Örneğin, kullanım izleme ve denetim, sistemin zaman içindeki normal noktalarında durumunun doğru bir resmini gerektirir, ancak bu durum bilgilerinin toplandıktan hemen sonra işlenmek üzere kullanılabilir olması gerekmez.

Operatör, tahmine dayalı sistem durumu analizi için verileri sağlamak üzere soğuk analizi de kullanabilir. Operatör, geçmiş bilgileri belirli bir süre boyunca toplayabilir ve kısa süre içinde sağlık durumu sorunlarına neden olabilecek eğilimleri saptamak amacıyla geçerli sağlık verileriyle (sık erişimli yoldan alınan) destekleyebilir. Bu gibi durumlarda, düzeltici eylemin yapılabilmesi için bir uyarı tetiklemeniz gerekebilir.

Verileri ilişkilendirme

İzlemenin yakaladığı veriler sistem durumunun anlık görüntüsünü sağlayabilir, ancak çözümlemenin amacı bu verileri eyleme dönüştürülebilir hale getirmektir. Örneğin:

• Sistem düzeyinde belirli bir zamanda yoğun G/Ç yüklemesine neden olan şey nedir?
• Çok sayıda veritabanı işleminin sonucu mu?
• Bu durum veritabanı yanıt sürelerine, saniye başına işlem sayısına ve aynı noktada uygulama yanıt sürelerine yansıtılıyor mu?

Bu durumda yükü azaltabilecek bir düzeltme eylemi verileri daha fazla sunucuya parçalayabilir. Ayrıca, sistemin herhangi bir düzeyindeki bir hatanın sonucu olarak özel durumlar ortaya çıkabilir. Bir düzeydeki bir özel durum genellikle yukarıdaki düzeyde başka bir hatayı tetikler.

Bu nedenlerden dolayı, sistemin durumunun ve üzerinde çalışan uygulamaların genel bir görünümünü oluşturmak için her düzeydeki farklı izleme verileri türlerini ilişkilendirmeniz gerekir. Daha sonra bu bilgileri kullanarak sistemin kabul edilebilir bir şekilde çalışıp çalışmadığına karar verebilir ve sistemin kalitesini artırmak için neler yapılıp yapılamayacağını belirleyebilirsiniz.

Verileri ilişkilendirmeye yönelik bilgiler bölümünde açıklandığı gibi, ham izleme verilerinin olayları ilişkilendirmek için gerekli toplamaları desteklemek için yeterli bağlam ve etkinlik kimliği bilgilerini içerdiğinden emin olmanız gerekir. Ayrıca, bu veriler farklı biçimlerde tutulabilir ve bu bilgileri analiz için standartlaştırılmış bir biçime dönüştürmek için ayrıştırmak gerekebilir.

Sorunları tanılama ve giderme

Tanılama, kök neden analizi gerçekleştirmek de dahil olmak üzere hataların veya beklenmeyen davranışların nedenini belirleyebilmeyi gerektirir. Gerekli bilgiler genellikle şunları içerir:

• Tüm sistem veya belirtilen bir zaman penceresi sırasında belirtilen bir alt sistem için olay günlüklerinden ve izlemelerden ayrıntılı bilgiler.
• Sistem içinde veya belirtilen bir alt sistemde belirtilen bir süre boyunca oluşan herhangi bir düzeyin özel durumlarından ve hatalarından kaynaklanan tam yığın izlemeleri.
• Sistemin herhangi bir yerindeki veya belirtilen bir alt sistemdeki başarısız işlemler için, belirtilen bir zaman aralığında kilitlenme dökümleri.
• Belirtilen süre boyunca tüm kullanıcılar veya seçili kullanıcılar tarafından gerçekleştirilen işlemleri kaydeden etkinlik günlükleri.

Sorun giderme amacıyla verilerin çözümlenmesi genellikle sistem mimarisinin ve çözümü oluşturan çeşitli bileşenlerin ayrıntılı teknik bir şekilde anlaşılmasını gerektirir. Sonuç olarak, verileri yorumlamak, sorunların nedenini oluşturmak ve bunları düzeltmek için uygun bir strateji önermek için genellikle büyük ölçüde el ile müdahale gerekir. Bu bilgilerin bir kopyasını özgün biçiminde depolamak ve bir uzman tarafından soğuk analiz için kullanılabilir hale getirmek uygun olabilir.

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

Herhangi bir izleme sisteminin önemli bir yönü, verileri operatörün eğilimleri veya sorunları hızla tespit edebilmesi için sunabilmektir. Ayrıca dikkat gerektiren önemli bir olay oluştuğunda operatörü hızla bilgilendirebilme özelliği de önemlidir.

Veri sunusu, panoları kullanarak görselleştirme, uyarı ve raporlama gibi çeşitli biçimler alabilir.

Panoları kullanarak görselleştirme

Verileri görselleştirmenin en yaygın yolu, bilgileri bir dizi grafik, grafik veya başka bir çizim olarak görüntüleyebilen panoları kullanmaktır. Bu öğeler parametrelendirilebilir ve analistin belirli bir durum için önemli parametreleri (zaman aralığı gibi) seçebilmesi gerekir.

Panolar hiyerarşik olarak düzenlenebilir. Üst düzey panolar, sistemin her yönüne ilişkin genel bir görünüm verebilir, ancak operatörün ayrıntılara inebilmesini sağlar. Örneğin, sistemin genel disk G/Ç'sini gösteren bir pano, bir analistin bir veya daha fazla belirli cihazın orantısız bir trafik hacmine sahip olup olmadığını belirlemek için her disk için G/Ç oranlarını görüntülemesine izin vermelidir. İdeal olan panonun, bu G/Ç'yi oluşturan her isteğin kaynağı (kullanıcı veya etkinlik) gibi ilgili bilgileri de görüntülemesi gerekir. Bu bilgiler daha sonra yükün cihazlar arasında daha eşit bir şekilde yayılıp yayılmayacağını (ve) ve daha fazla cihaz eklendiğinde sistemin daha iyi çalışıp çalışmayacağını belirlemek için kullanılabilir.

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

• Uzun bir süre boyunca maksimum kapasitesine yaklaşan G/Ç oranına sahip bir disk (sıcak disk) kırmızı renkle vurgulanabilir.
• Periyodik olarak kısa süreler boyunca en yüksek sınırında çalışan (sıcak disk olarak adlandırılan) G/Ç hızına sahip bir disk sarı renkle vurgulanabilir.
• Normal kullanım sergileyen bir disk yeşil renkte görüntülenebilir.

Pano sisteminin etkili bir şekilde çalışması için, çalışmak için ham verilere sahip olması gerekir. Kendi pano sisteminizi oluşturuyorsanız veya başka bir kuruluş tarafından geliştirilen bir pano kullanıyorsanız, hangi izleme verilerini toplamanız gerektiğini, hangi ayrıntı düzeylerinde ve panonun kullanmasının nasıl biçimlendirilmesi gerektiğini anlamanız gerekir.

İyi bir pano, bilgileri görüntülemenin yanı sıra analistin bu bilgiler hakkında sorular sormasını da sağlar. Bazı sistemler, bir operatörün bu görevleri gerçekleştirmek ve temel alınan verileri keşfetmek için kullanabileceği yönetim araçları sağlar. Alternatif olarak, bu bilgileri tutmak için kullanılan depoya bağlı olarak, bu verileri doğrudan sorgulamak veya daha fazla analiz ve raporlama için Microsoft Excel gibi araçlara aktarmak mümkün olabilir.

Uyarı

Bu bilgiler ticari olarak hassas olabileceği için panolara erişimi yetkili personelle kısıtlamanız gerekir. Ayrıca, kullanıcıların panoları değiştirmesini önlemek için temel alınan verileri de korumanız gerekir.

Uyarı oluşturma

Uyarı, izleme ve izleme verilerini analiz etme ve önemli bir olay algılanırsa bildirim oluşturma işlemidir.

Uyarı, sistemin sağlıklı, duyarlı ve güvenli kalmasını sağlamaya yardımcı olur. Verilerin hemen üzerinde işlem yapılması gerekebilecek kullanıcılara performans, kullanılabilirlik ve gizlilik garantileri veren tüm sistemlerin önemli bir parçasıdır. Uyarıyı tetikleyen olay bir operatöre bildirilmesi gerekebilir. Uyarı, otomatik ölçeklendirme gibi sistem işlevlerini çağırmak için de kullanılabilir.

Uyarı genellikle aşağıdaki izleme verilerine bağlıdır:

• Güvenlik olayları. Olay günlükleri, yinelenen kimlik doğrulama veya yetkilendirme hatalarının oluştuğunu gösteriyorsa, sistem saldırı altında olabilir ve bir operatör bilgilendirilmelidir.
• Performans ölçümleri. Belirli bir performans ölçümü belirtilen eşiği aşarsa sistemin hızla yanıt vermesi gerekir.
• Kullanılabilirlik bilgileri. Hata algılanırsa, bir veya daha fazla alt sistemin hızlı bir şekilde yeniden başlatılması veya bir yedekleme kaynağına yük devretme yapılması gerekebilir. Bir alt sistemdeki yinelenen hatalar daha ciddi endişelere işaret edebilir.

Operatörler e-posta, çağrı cihazı veya SMS kısa mesaj gibi birçok teslim kanalını kullanarak uyarı bilgilerini alabilir. Uyarı, bir durumun ne kadar kritik olduğunu gösteren bir gösterge de içerebilir. Birçok uyarı sistemi abone gruplarını destekler ve aynı grubun üyesi olan tüm operatörler aynı uyarı kümesini alabilir.

Bir uyarı sistemi özelleştirilebilir olmalıdır ve temel alınan izleme verilerinden uygun değerler parametre olarak sağlanabilir. Bu yaklaşım, bir operatörün verileri filtrelemesini ve bu eşiklere veya ilgi çekici değer birleşimlerine odaklanmasını sağlar. Bazı durumlarda ham izleme verileri uyarı sistemine sağlanabilir. Diğer durumlarda, toplanan verileri sağlamak daha uygun olabilir. (Örneğin, bir düğümün CPU kullanımı son 10 dakika içinde yüzde 90'ı aştıysa bir uyarı tetiklenebilir). Uyarı sistemine sağlanan ayrıntılar uygun özet ve bağlam bilgilerini de içermelidir. Bu veriler, hatalı pozitif olayların bir uyarıyı tetiklemesi olasılığını azaltmaya yardımcı olabilir.

Raporlama

Raporlama, sistemin genel bir görünümünü oluşturmak için kullanılır. Geçerli bilgilere ek olarak geçmiş verileri de içerebilir. Raporlama gereksinimleri iki geniş kategoriye ayrılır: operasyonel raporlama ve güvenlik raporlaması.

operasyonel raporlama genellikle aşağıdaki özellikleri 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 dönemde, genel sistem veya belirtilen alt sistemler için kaynak kullanımındaki eğilimleri tanımlama.
• 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. Bu, her kullanıcının gerçekleştirdiği isteklerin tarih ve saatlerle birlikte kaydedilmesini gerektirir. Veriler, bir yöneticinin kullanıcının belirli bir süre boyunca gerçekleştirdiği işlem dizisini hızla yeniden oluşturmasını sağlayacak şekilde yapılandırılmalıdır.
• Kullanıcı tarafından kaynak kullanımını izleme. Bu, bir kullanıcı için her isteğin sistemi oluşturan çeşitli kaynaklara nasıl ve ne kadar süreyle eriştiğinin kaydedilmesini gerektirir. Yöneticinin bu verileri kullanarak belirli bir süre boyunca (faturalama amacıyla) kullanıcı tarafından kullanım raporu oluşturabilmesi gerekir.

Birçok durumda, toplu işlemler tanımlanan zamanlamaya göre raporlar oluşturabilir. (Gecikme normalde bir sorun değildir.) Ancak, gerekirse isteğe bağlı olarak oluşturma için de kullanılabilir olmalıdır. Örneğin, verileri Azure SQL Veritabanı gibi bir ilişkisel veritabanında depoluyorsanız, verileri ayıklamak ve biçimlendirmek ve bir rapor kümesi olarak sunmak için SQL Server Reporting Services gibi bir araç kullanabilirsiniz.

Sonraki Adımlar

• Azure Monitor'a genel bakış
• Microsoft Azure Depolama izleme, tanılama ve sorun giderme
• Microsoft Azure'da uyarılara genel bakış
• Application Insights nedir?
• Azure sanal makineleri için performans tanılamaları
• Visual Studio için SQL Server Veri Araçları'nı (SSDT) indirme ve yükleme

İlgili kaynaklar

• Otomatik ölçeklendirme kılavuzu , bir operatörün sistemin performansını sürekli izlemesi ve kaynak ekleme veya kaldırma konusunda karar verme gereksinimini azaltarak yönetim yükünü nasıl azaltacaklarını 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.