İzleme ve tanılamaMonitoring and diagnostics

Bulutta çalıştırılan dağıtılmış uygulamalar ve hizmetler, doğaları gereği birçok hareketli parçadan oluşan karmaşık yazılımlardır.Distributed applications and services running in the cloud are, by their nature, complex pieces of software that comprise many moving parts. Bir üretim ortamında, kullanıcıların sistemi, kaynak kullanımını şekilde izleyebilmesi ve genel durumunu ve sistem performansını izlemek önemlidir.In a production environment, it's important to be able to track the way in which users use your system, trace resource utilization, and generally monitor the health and performance of your system. 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.You can use this information as a diagnostic aid to detect and correct issues, and also to help spot potential problems and prevent them from occurring.

İzleme ve tanılama senaryolarıMonitoring and diagnostics scenarios

İzlemeyi kullanarak sistemin ne kadar iyi çalıştığı konusunda öngörüler elde edebilirsiniz.You can use monitoring to gain an insight into how well a system is functioning. İzleme, hizmet kalitesi hedeflerini tutturmanın önemli bir parçasıdır.Monitoring is a crucial part of maintaining quality-of-service targets. İzleme verileri toplamaya yönelik yaygın senaryolar şunlardır:Common scenarios for collecting monitoring data include:

  • Sistemin iyi durumda çalışmayı sürdürdüğünden emin olma.Ensuring that the system remains healthy.
  • Sistemin ve bileşen öğelerinin kullanılabilirliğini izleme.Tracking the availability of the system and its component elements.
  • İş hacmi arttığında sistemin aktarım hızının beklenmedik bir düşüş göstermediğinden emin olmak için performansı koruma.Maintaining performance to ensure that the throughput of the system does not degrade unexpectedly as the volume of work increases.
  • Sistemin müşterilerle yapılan tüm hizmet düzeyi sözleşmelerine (SLA) uyduğunu garanti etme.Guaranteeing that the system meets any service-level agreements (SLAs) established with customers.
  • Sistemin, kullanıcıların ve verilerinin gizliliğini ve güvenliğini koruma.Protecting the privacy and security of the system, users, and their data.
  • Denetim ve yasal düzenleme amacıyla gerçekleştirilen işlemleri izleme.Tracking the operations that are performed for auditing or regulatory purposes.
  • Sistemin gündelik kullanımını izleme ve ilgilenilmediği takdirde sorunlara yol açabilecek eğilimleri belirleme.Monitoring the day-to-day usage of the system and spotting trends that might lead to problems if they're not addressed.
  • Ortaya çıkan sorunları ilk rapordan başlayıp olası nedenlerin analizi, düzeltme, izleyen yazılım güncelleştirmeleri ve dağıtım boyunca izleme.Tracking issues that occur, from initial report through to analysis of possible causes, rectification, consequent software updates, and deployment.
  • İşlemleri izleme ve yazılım sürümlerinde hataları ayıklama.Tracing operations and debugging software releases.

Not

Bu listenin kapsamlı bir liste olması amaçlanmamıştır.This list is not intended to be comprehensive. Bu belge, izleme yapmaya yönelik en yaygın durumlar olarak bu senaryolara odaklanır.This document focuses on these scenarios as the most common situations for performing monitoring. Daha az yaygın veya sizin ortamınıza özgü olan başka senaryolar da olabilir.There might be others that are less common or are specific to your environment.

Aşağıdaki bölümlerde bu senaryolar daha ayrıntılı olarak açıklanır.The following sections describe these scenarios in more detail. Her senaryoyla ilgili bilgiler şu biçim kullanılarak ele alınmıştır:The information for each scenario is discussed in the following format:

  1. Senaryoya kısa bir bakış.A brief overview of the scenario.
  2. Bu senaryonun tipik gereksinimleri.The typical requirements of this scenario.
  3. Senaryo ve bu bilgilerin olası kaynakları desteklemek için gereken ham ölçümlü izleme verileri.The raw instrumentation data that's required to support the scenario, and possible sources of this information.
  4. Nasıl bu ham veriler analiz ve anlamlı tanılama bilgileri üretmek için birleştirilmiş.How this raw data can be analyzed and combined to generate meaningful diagnostic information.

Sistem durumunu izlemeHealth monitoring

Sistem çalışıyorsa ve istekleri işleyebiliyorsa iyi durumda demektir.A system is healthy if it is running and capable of processing requests. Sistem durumunu izlemenin amacı, sistemin geçerli durumunun bir anlık görüntüsünü oluşturarak tüm sistem bileşenlerinin beklendiği gibi çalıştığını doğrulayabilmenizdir.The purpose of health monitoring is to generate a snapshot of the current health of the system so that you can verify that all components of the system are functioning as expected.

Sistem durumunu izleme gereksinimleriRequirements for health monitoring

Sistemin herhangi bir bölümü iyi durum değil gibi görünüyorsa, operatör hemen (saniyeler içinde) uyarılmalıdır.An operator should be alerted quickly (within a matter of seconds) if any part of the system is deemed to be unhealthy. Operatör sistemin hangi bölümlerinin normal çalıştığını ve hangi bölümlerinde sorun yaşandığını tespit edebilmelidir.The operator should be able to ascertain which parts of the system are functioning normally, and which parts are experiencing problems. Sistem durumu bir trafik ışığı sistemiyle vurgulanabilir:System health can be highlighted through a traffic-light system:

  • Kırmızı, iyi durumda değil (sistem durduruldu)Red for unhealthy (the system has stopped)
  • Sarı, kısmen iyi durumda (sistem sınırlı işlevsellikte çalıştırılıyor)Yellow for partially healthy (the system is running with reduced functionality)
  • Yeşil, tamamen iyi durumdaGreen for completely healthy

Kapsamlı bir sistem durumu izleme sistemi, operatörün sistem genelinde detaya giderek alt sistemlerin ve bileşenlerin durumunu görüntüleyebilmesine olanak tanır.A comprehensive health-monitoring system enables an operator to drill down through the system to view the health status of subsystems and components. Örneğin, sistemin bir bütün olarak kısmen iyi durumda belirtiliyorsa, operatörün sisteme yakından bakabilmesi ve şu anda hangi işlevselliğin kullanılamadığını saptayabilmesi gerekir.For example, if the overall system is depicted as partially healthy, the operator should be able to zoom in and determine which functionality is currently unavailable.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Sistem durumu izleme işlemini destekleyecek ham veriler, şu işlemler sonucu oluşturulabilir:The raw data that's required to support health monitoring can be generated as a result of:

  • Kullanıcı isteklerinin yürütülmesini izleme.Tracing execution of user requests. Bu bilgiler hangi isteklerin başarılı, hangilerinin başarısız olduğunu ve her isteğin ne kadar zaman aldığını saptamak için kullanılabilir.This information can be used to determine which requests have succeeded, which have failed, and how long each request takes.
  • Yapay kullanıcı izleme.Synthetic user monitoring. Bu işlemde, kullanıcı tarafından gerçekleştirilen adımların benzetimi yapılır ve önceden tanımlanmış bir dizi adım uygulanır.This process simulates the steps performed by a user and follows a predefined series of steps. Her adımın sonuçları yakalanmalıdır.The results of each step should be captured.
  • Özel durumları, hataları ve uyarıları günlüğe kaydetme.Logging exceptions, faults, and warnings. Bu bilgiler hem uygulama koduna eklenmiş izleme deyimlerinin sonucu olarak hem de sistemin başvurduğu tüm hizmetlerin olay günlüklerinden bilgi alarak yakalanabilir.This information can be captured as a result of trace statements embedded into the application code, as well as retrieving information from the event logs of any services that the system references.
  • Sistemin kullandığın tüm üçüncü taraf hizmetlerin durumunu izleme.Monitoring the health of any third-party services that the system uses. Bu izleme için söz konusu hizmetlerin sağladığı durum verilerini almak ve ayrıştırmak gerekebilir.This monitoring might require retrieving and parsing health data that these services supply. Bu bilgiler çeşitli biçimlerde olabilir.This information might take a variety of formats.
  • Uç nokta izleme.Endpoint monitoring. Bu mekanizma "Kullanılabilirliği izleme" bölümünde daha ayrıntılı açıklanmıştır.This mechanism is described in more detail in the "Availability monitoring" section.
  • Arka plan CPU kullanımı veya G/Ç (ağ dahil) etkinliği gibi çevresel performans bilgilerini toplama.Collecting ambient performance information, such as background CPU utilization or I/O (including network) activity.

Sistem durumu verilerinin analiziAnalyzing health data

Sistem durumu izlemenin birincil odak noktası, sistemin çalışıp çalışmadığını hızla göstermektir.The primary focus of health monitoring is to quickly indicate whether the system is running. Anlık verilerin hızlı analizi, kritik bir bileşenin iyi durumda olmadığı algılandığında bir uyarıyı tetikleyebilir.Hot analysis of the immediate data can trigger an alert if a critical component is detected as unhealthy. (Örneğin, arka arkaya bir dizi ping işlemine yanıt verememiştir.) Bundan sonra operatör uygun düzeltici eylemi gerçekleştirebilir.(It fails to respond to a consecutive series of pings, for example.) The operator can then take the appropriate corrective action.

Daha gelişmiş bir sistem, geçmiş ve geçerli iş yükleri üzerinde gecikmeli analiz gerçekleştiren tahmine dayalı bir bölüm içerebilir.A more advanced system might include a predictive element that performs a cold analysis over recent and current workloads. Gecikmeli analiz eğilimleri ortaya koyabilir ve sistemin iyi durumda kalıp kalamayacağını ve ek kaynaklara ihtiyacı olup olmayacağını saptayabilir.A cold analysis can spot trends and determine whether the system is likely to remain healthy or whether the system will need additional resources. Tahmine dayalı bu bölüm, aşağıdakiler gibi kritik performans ölçümlerine dayanmalıdır:This predictive element should be based on critical performance metrics, such as:

  • Her hizmete veya alt sisteme yönlendirilen isteklerin oranı.The rate of requests directed at each service or subsystem.
  • Bu isteklerin yanıt süreleri.The response times of these requests.
  • Her hizmette içeri ve dışarı veri akışının hacmi.The volume of data flowing into and out of each service.

Ölçümlerden herhangi birinin değeri tanımlı eşiği aşarsa, sistemin durumunu korumak üzere operatörün veya otomatik ölçeklendirmenin (varsa) gerekli önleyici eylemleri gerçekleştirebilmesi için sistem uyarı verebilir.If the value of any metric exceeds a defined threshold, the system can raise an alert to enable an operator or autoscaling (if available) to take the preventative actions necessary to maintain system health. Bunlar kaynak ekleme, hatalı durumdaki bir veya birden çok hizmeti yeniden başlatma veya düşük öncelik isteklerin sayısını azaltma gibi eylemler olabilir.These actions might involve adding resources, restarting one or more services that are failing, or applying throttling to lower-priority requests.

Kullanılabilirliği izlemeAvailability monitoring

Gerçekten iyi durumda bir sistem için, sistemi oluşturan bileşenlerin ve alt sistemlerin kullanılabilir olması gerekir.A truly healthy system requires that the components and subsystems that compose the system are available. Kullanılabilirliği izleme, sistem durumunu izlemeyle yakından ilgilidir.Availability monitoring is closely related to health monitoring. Ama sistem durumunu izleme işleminde sistemin geçerli durumunun anlık görüntüsü sağlanırken, kullanılabilirliği izleme sistemin çalışma süresi hakkındaki istatistikleri oluşturmak üzere sistemin ve bileşenlerinin kullanılabilirliğini izlemeyle ilgilenir.But whereas health monitoring provides an immediate view of the current health of the system, availability monitoring is concerned with tracking the availability of the system and its components to generate statistics about the uptime of the system.

Birçok sistemde, ciddi bir hata veya bağlantı kaybı söz konusu olduğunda yükü hızla devredebilmek için bazı bileşenler (örneğin, veritabanı) yerleşik yedekli çalışma özelliğiyle yapılandırılır.In many systems, some components (such as a database) are configured with built-in redundancy to permit rapid failover in the event of a serious fault or loss of connectivity. İdeal olan, kullanıcıların böyle bir hatanın oluştuğunu fark etmemesidir.Ideally, users should not be aware that such a failure has occurred. Ama kullanılabilirliği izleme açısından bakıldığında, bu tür hatalarda nedeni saptamak ve yeniden oluşmasını önleyecek düzeltici eylemleri gerçekleştirmek için mümkün olduğu kadar çok bilgi toplamak gerekir.But from an availability monitoring perspective, it's necessary to gather as much information as possible about such failures to determine the cause and take corrective actions to prevent them from recurring.

Kullanılabilirliği izlemek için gereken veriler, alt düzey faktörlerin sayısına bağlı olabilir.The data that's required to track availability might depend on a number of lower-level factors. Bu faktörlerin birçoğu uygulamaya, sisteme ve ortama özgü olabilir.Many of these factors might be specific to the application, system, and environment. Etkili bir izleme sistemi bu alt düzey faktörlere karşılık gelen kullanılabilirlik verilerini yakalar ve ardından bunları bir araya getirerek sistemin genel bir görüntüsünü çıkarır.An effective monitoring system captures the availability data that corresponds to these low-level factors and then aggregates them to give an overall picture of the system. Örneğin, bir e-ticaret sisteminde müşterinin sipariş vermesine olanak sağlayan işlevsellik, sipariş ayrıntılarının saklandığı depoya ve bu siparişlerin ödenmesine yönelik parasal işlemleri işleyen ödeme sistemine bağlı olabilir.For example, in an e-commerce system, the business functionality that enables a customer to place orders might depend on the repository where order details are stored and the payment system that handles the monetary transactions for paying for these orders. Dolayısıyla sistemin sipariş verme bölümünün kullanılabilirliği deponun ve ödeme alt sisteminin kullanılabilirliğinin bir fonksiyonudur.The availability of the order-placement part of the system is therefore a function of the availability of the repository and the payment subsystem.

Kullanılabilirliği izleme gereksinimleriRequirements for availability monitoring

Operatörün her sisteme ve alt sisteme ilişkin geçmiş kullanılabilirlik bilgilerini de görüntüleyebilmesi ve bu bilgileri kullanarak bir veya birden çok alt sistemin düzenli aralıklarla başarısız olmasına neden olabilecek eğilimleri saptayabilmesi gerekir.An operator should also be able to view the historical availability of each system and subsystem, and use this information to spot any trends that might cause one or more subsystems to periodically fail. (Hizmetler günün yoğun işlem saatlerine denk gelen belirli bir zamanında mı başarısız olmaya başlıyor?)(Do services start to fail at a particular time of day that corresponds to peak processing hours?)

Bir izleme çözümü, her alt sistemin kullanılabilir veya kullanılamaz olduğu durumların anlık ve geçmiş görünümünü sağlamalıdır.A monitoring solution should provide an immediate and historical view of the availability or unavailability of each subsystem. Ayrıca bir veya birden çok hizmet başarısız olduğunda veya kullanıcılar hizmetlere bağlanamadığında operatörü hızla uyarabilme özelliğine de sahip olmalıdır.It should also be capable of quickly alerting an operator when one or more services fail or when users can't connect to services. Söz konusu olan yalnızca her hizmeti izlemek değildir; aynı zamanda kullanıcıların gerçekleştirdiği eylemleri, bu eylemlerin hizmetle iletişim kuramamaları durumunda incelemek de gerekir.This is a matter of not only monitoring each service, but also examining the actions that each user performs if these actions fail when they attempt to communicate with a service. Bağlantının başarısız olması bir noktaya kadar normaldir ve geçici hatalardan kaynaklanıyor olabilir.To some extent, a degree of connectivity failure is normal and might be due to transient errors. Ama sistemin, belirli bir süre boyunca belirli bir alt sisteme başarısız bağlanma denemelerinin sayısına ilişkin uyarı vermesini sağlamak da yararlı olabilir.But it might be useful to allow the system to raise an alert for the number of connectivity failures to a specified subsystem that occur during a specific period.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Sistem durumu izlemesinde olduğu gibi, kullanılabilirliğin izlenmesinde de bu izlemeyi desteklemek için gereken ham veriler yapay kullanıcı izlemesi yoluyla ve oluşabilecek özel durumları, hataları ve uyarıları günlüğe kaydederek oluşturulabilir.As with health monitoring, the raw data that's required to support availability monitoring can be generated as a result of synthetic user monitoring and logging any exceptions, faults, and warnings that might occur. Buna ek olarak, kullanılabilirlik verileri uç nokta izlemesi gerçekleştirerek de elde edilebilir.In addition, availability data can be obtained from performing endpoint monitoring. Uygulama bir veya birden çok sistem durumu uç noktasını ortaya çıkarır ve her biri sistemdeki işlevsel bir alana erişimi test eder.The application can expose one or more health endpoints, each testing access to a functional area within the system. İzleme sistemi tanımlı bir zamanlamaya uygun olarak her uç noktaya ping yapabilir ve sonuçları (başarı veya başarısızlık) toplayabilir.The monitoring system can ping each endpoint by following a defined schedule and collect the results (success or fail).

Tüm zaman aşımları, ağ bağlantısı hataları ve bağlantı yeniden deneme girişimleri kaydedilmelidir.All timeouts, network connectivity failures, and connection retry attempts must be recorded. Tüm verileri zaman damgalı olmalıdır.All data should be timestamped.

Kullanılabilirlik verilerinin analiziAnalyzing availability data

Ölçümlü izleme verileri bir araya toplanmalı ve şu türlerdeki analizleri destekleyecek şekilde ilişkilendirilmelidir:The instrumentation data must be aggregated and correlated to support the following types of analysis:

  • Sistemlerin ve alt sistemlerin anlık kullanılabilirliği.The immediate availability of the system and subsystems.
  • Sistemlerin ve alt sistemlerin kullanılabilirliğinde hata oranları.The availability failure rates of the system and subsystems. İdeal olan, operatörün hataları belirli etkinliklerle ilişkilendirilebilmesidir: Sistem başarısızlığa uğradığında ne oluyordu?Ideally, an operator should be able to correlate failures with specific activities: what was happening when the system failed?
  • Belirli bir süre içinde sistemin veya alt sistemlerin hata oranlarının geçmiş görünümü ve sistemin hata oluştuğu sıradaki yükü (örneğin, kullanıcı isteklerinin sayısı).A historical view of failure rates of the system or any subsystems across any specified period, and the load on the system (number of user requests, for example) when a failure occurred.
  • Sistemin veya alt sistemlerin kullanılabilir olmamasının nedenleri.The reasons for unavailability of the system or any subsystems. Örneğin, nedenler hizmetin çalışmaması, bağlantı kaybı, bağlanmış ama zaman aşıma uğramış olma durumu ve bağlanmış ama hata döndürüyor olma durumu olabilir.For example, the reasons might be service not running, connectivity lost, connected but timing out, and connected but returning errors.

Belirli bir süre içinde hizmetin kullanılabilirlik yüzdesini hesaplamak için şu formülü kullanabilirsiniz:You can calculate the percentage availability of a service over a period of time by using the following formula:

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

Bu, SLA amaçları açısından yararlıdır.This is useful for SLA purposes. (SLA izleme bu kılavuzun devamında daha ayrıntılı olarak açıklanmıştır.) Kapalı kalma süresinin tanımı hizmete bağlıdır.(SLA monitoring is described in more detail later in this guidance.) The definition of downtime depends on the service. Örneğin, Visual Studio Team Services Derleme Hizmeti kapalı kalma süresini Derleme Hizmeti'nin kullanılamaz durumda olduğu süre (toplam dakika sayısı) olarak tanımlar.For example, Visual Studio Team Services Build Service defines downtime as the period (total accumulated minutes) during which Build Service is unavailable. Müşteri tarafından başlatılan işlemleri gerçekleştirmek üzere Derleme Hizmeti’ne yapılan tüm sürekli HTTP isteklerinin bir dakika boyunca hata kodu ile sonuçlandığı veya bir yanıt döndürmediği durumlarda o dakikanın kullanılamaz olduğu kabul edilir.A minute is considered unavailable if all continuous HTTP requests to Build Service to perform customer-initiated operations throughout the minute either result in an error code or do not return a response.

Performans izlemePerformance monitoring

Sistem giderek daha çok baskı altına alındıkça (kullanıcı hacmi artırılarak), bu kullanıcıların eriştiği veri kümelerin boyutu büyür ve bir veya birden çok bileşende hata oluşma olasılığı artar.As the system is placed under more and more stress (by increasing the volume of users), the size of the datasets that these users access grows and the possibility of failure of one or more components becomes more likely. Bileşen hatasından önce sıklıkla performans düşüşü yaşanır.Frequently, component failure is preceded by a decrease in performance. Böyle bir düşüşü algılayabilirseniz, durumu düzeltmek için proaktif adımlar atabilirsiniz.If you're able detect such a decrease, you can take proactive steps to remedy the situation.

Sistem performansı bir dizi faktöre bağlıdır.System performance depends on a number of factors. Her faktör normal olarak, bir saniyede yapılan veritabanı işlemlerinin sayısı veya belirtilen zaman çerçevesinde başarıyla hizmet verilen ağ isteklerinin hacmi gibi ana performans göstergeleriyle (KPI) ölçülür.Each factor is typically measured through key performance indicators (KPIs), such as the number of database transactions per second or the volume of network requests that are successfully serviced in a specified time frame. Bu KPI'lerden bazıları belirli performans ölçüleri olarak sağlanabilirken, diğerleri ölçümlerin bir bileşiminden türetilebilir.Some of these KPIs might be available as specific performance measures, whereas others might be derived from a combination of metrics.

Not

Kötü veya iyi performansı saptamak için, sistemin hangi performans düzeyinde çalışabilmesi gerektiğini anlamalısınız.Determining poor or good performance requires that you understand the level of performance at which the system should be capable of running. Bunun için sistemin normal yükü altında çalışırken gözlemlenmesi ve belirli bir süre boyunca her KPI'nin verilerinin yakalanması gerekir.This requires observing the system while it's functioning under a typical load and capturing the data for each KPI over a period of time. Bu çalışma, sistemi benzetimi yapılmış bir yük altında test ortamında çalıştırmayı ve sistemin üretim ortamına dağıtımından önce uygun verileri toplamayı içerebilir.This might involve running the system under a simulated load in a test environment and gathering the appropriate data before deploying the system to a production environment.

Bu arada performans için yapılan izlemenin sisteme yük getirmediğinden de emin olmalısınız.You should also ensure that monitoring for performance purposes does not become a burden on the system. Performans izleme işleminde toplanan verilerin ayrıntı düzeyini dinamik olarak ayarlayabilirsiniz.You might be able to dynamically adjust the level of detail for the data that the performance monitoring process gathers.

Performans izleme gereksinimleriRequirements for performance monitoring

Sistem performansını incelemek için, operatörün normalde şu bilgileri görmesi gerekir:To examine system performance, an operator typically needs to see information that includes:

  • Kullanıcı istekleri için yanıt hızları.The response rates for user requests.
  • Eş zamanlı kullanıcı isteklerinin sayısı.The number of concurrent user requests.
  • Ağ trafiğinin hacmi.The volume of network traffic.
  • Kurumsal işlemlerin tamamlanma hızları.The rates at which business transactions are being completed.
  • İstekler için ortalama işlem süresi.The average processing time for requests.

Operatöre ilişkileri saptamasına yardımcı olacak araçlar sağlamak da yararlı olabilir, örneğin:It can also be helpful to provide tools that enable an operator to help spot correlations, such as:

  • Eş zamanlı kullanıcı sayısıyla istek gecikme sürelerinin karşılaştırması (kullanıcı bir istek gönderdikten sonra isteğin işlenmeye başlaması ne kadar sürüyor).The number of concurrent users versus request latency times (how long it takes to start processing a request after the user has sent it).
  • Eş zamanlı kullanıcı sayısıyla ortalama yanıt süresini karşılaştırma (bir isteğin işlenmeye başladıktan sonra tamamlanması ne kadar sürüyor).The number of concurrent users versus the average response time (how long it takes to complete a request after it has started processing).
  • İstek hacmiyle işleme hatalarının sayısını karşılaştırma.The volume of requests versus the number of processing errors.

Bu üst düzey işlevsel bilgilerin yanı sıra, operatörün sistemdeki her bileşenle ilgili ayrıntılı performans görünümünü de alabilmesi gerekir.Along with this high-level functional information, an operator should be able to obtain a detailed view of the performance for each component in the system. Bu veriler normalde aşağıdakiler gibi bilgileri izleyen alt düzey performans sayaçları aracılığıyla sağlanır:This data is typically provided through low-level performance counters that track information such as:

  • Bellek kullanımı.Memory utilization.
  • İş parçacığı sayısı.Number of threads.
  • CPU işleme süresi.CPU processing time.
  • İstek kuyruğu uzunluğu.Request queue length.
  • Disk veya ağ G/Ç oranları ve hataları.Disk or network I/O rates and errors.
  • Yazılan veya okunan bayt sayısı.Number of bytes written or read.
  • Kuyruk uzunluğu gibi ara yazılım göstergeleri.Middleware indicators, such as queue length.

Tüm görselleştirmelerde operatöre bir zaman aralığı belirtme olanağı tanınmalıdır.All visualizations should allow an operator to specify a time period. Görüntülenen veriler, geçerli durumun anlık görüntüsü ve/veya geçmiş performans görünümü olabilir.The displayed data might be a snapshot of the current situation and/or a historical view of the performance.

Operatörün belirli bir süre boyunca belirli bir değer için yapılan herhangi bir performans ölçümü temelinde uyarı oluşturabilmesi gerekir.An operator should be able to raise an alert based on any performance measure for any specified value during any specified time interval.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Kullanıcıların sisteme ulaşan ve sistemden geçen isteklerinin ilerleme durumunu izleyerek üst düzey performans verileri (aktarım hızı, eş zamanlı kullanıcı sayısı, kurumsal işlem sayısı, hata oranları, vb.) toplayabilirsiniz.You can gather high-level performance data (throughput, number of concurrent users, number of business transactions, error rates, and so on) by monitoring the progress of users' requests as they arrive and pass through the system. Bu işlem, uygulama kodundaki önemli noktalarda yer alan izleme deyimlerinin zamanlama bilgileriyle birlikte bir araya getirilmesini içerir.This involves incorporating tracing statements at key points in the application code, together with timing information. Tüm hatalar, özel durumlar ve uyarıların bunlara neden olan isteklerle ilişkilendirilebilmesi için, bunların yeterli veriyle yakalanması gerekir.All faults, exceptions, and warnings should be captured with sufficient data for correlating them with the requests that caused them. Internet Information Services (IIS) günlüğü bir diğer yararlı kaynaktır.The Internet Information Services (IIS) log is another useful source.

Mümkünse, uygulamanın kullandığı tüm dış sistemler için de performans verilerini yakalamalısınız.If possible, you should also capture performance data for any external systems that the application uses. Bu dış sistemler, kendi performans sayaçlarını veya performans verileri istemeye yönelik başka özellikler sağlıyor olabilir.These external systems might provide their own performance counters or other features for requesting performance data. Bu mümkün değilse, dış sisteme yapılan her isteğin başlangıç saati ve bitiş saati gibi bilgileri, ayrıca işlemin durumunu (başarı, başarısızlık veya uyarı) kaydedin.If this is not possible, record information such as the start time and end time of each request made to an external system, together with the status (success, fail, or warning) of the operation. Örneğin, isteklerin zamanını belirlemek için kronometre yaklaşımı kullanabilirsiniz: İstek başlatıldığında süreölçeri başlatın ve istek sona erdiğinde süreölçeri durdurun.For example, you can use a stopwatch approach to time requests: start a timer when the request starts and then stop the timer when the request finishes.

Sistemdeki tek tek bileşenlerin alt düzey performans verileri, Windows performans sayaçları ve Azure Tanılama gibi özellikler ve hizmetler aracılığıyla sağlanabilir.Low-level performance data for individual components in a system might be available through features and services such as Windows performance counters and Azure Diagnostics.

Performans verilerinin analiziAnalyzing performance data

Analiz çalışmalarının büyük bölümü kullanıcı isteği türüne ve/veya her isteğin gönderildiği alt sisteme veya hizmete göre performans verilerini toplamaktan oluşur.Much of the analysis work consists of aggregating performance data by user request type and/or the subsystem or service to which each request is sent. Bir e-ticaret sisteminde alışveriş sepetine öğe eklemek veya alışverişi bitirme işlemi yapmak birer kullanıcı isteği örneğidir.An example of a user request is adding an item to a shopping cart or performing the checkout process in an e-commerce system.

Bir diğer yaygın gereksinim, performans verilerini seçilen yüzdelik dilimlerde özetlemektir.Another common requirement is summarizing performance data in selected percentiles. Örneğin, operatör isteklerin yüzde 99'u için, isteklerin yüzde 95'i için ve isteklerin yüzde 70'i için yanıt sürelerini saptayabilir.For example, an operator might determine the response times for 99 percent of requests, 95 percent of requests, and 70 percent of requests. Her yüzdebirlik dilime ilişkin SLA hedefleri veya başka hedefler ayarlanmış olabilir.There might be SLA targets or other goals set for each percentile. Anlık sorunları algılamaya yardımcı olmak için, devam eden sonuçlar neredeyse gerçek zamanlı olarak raporlanmalıdır.The ongoing results should be reported in near real time to help detect immediate issues. İstatistikleri tutmak amacıyla daha uzun bir sürenin sonuçları da toplanmalıdır.The results should also be aggregated over the longer time for statistical purposes.

Performansı etkileyen gecikme sorunlarıyla karşılaşıldığında, operatörün her istekte gerçekleştirilen her adımı inceleyerek performans sorununun nedenini hızla belirleyebilmesi gerekir.In the case of latency issues affecting performance, an operator should be able to quickly identify the cause of the bottleneck by examining the latency of each step that each request performs. Dolayısıyla performans verileri, her adımın performans ölçümlerini ilişkilendirip bunları belirli bir isteğe bağlamak için bir yol sağlamalıdır.The performance data must therefore provide a means of correlating performance measures for each step to tie them to a specific request.

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.Depending on the visualization requirements, it might be useful to generate and store a data cube that contains views of the raw data. Bu veri küpü performans verilerinin geçici olarak yapılacak karmaşık sorgulama ve analizine olanak tanıyabilir.This data cube can allow complex ad hoc querying and analysis of the performance information.

Güvenliği izlemeSecurity monitoring

Hassas verilerin bulunduğu tüm ticari sistemlerin bir güvenlik yapısına sahip olması gerekir.All commercial systems that include sensitive data must implement a security structure. Güvenlik mekanizmasının karmaşıklık düzeyi çoğunlukla verilerin hassaslık düzeyine göre belirlenir.The complexity of the security mechanism is usually a function of the sensitivity of the data. Kullanıcıların kimlik doğrulaması yapmasını gerektiren bir sistemde şunların kaydını tutmalısınız:In a system that requires users to be authenticated, you should record:

  • Tüm oturum açma girişimleri, bunların başarılı olup olmadığı.All sign-in attempts, whether they fail or succeed.
  • Tarafından gerçekleştirilen tüm işlemlerin—ve tarafından erişilen tüm kaynakların ayrıntıları—kimliği doğrulanmış bir kullanıcı.All operations performed by—and the details of all resources accessed by—an authenticated user.
  • Kullanıcının ne zaman oturumu sona erdirdiği ve kapattığı.When a user ends a session and signs out.

İzleme, sisteme yapılan saldırıları algılamaya yardımcı olabilir.Monitoring might be able to help detect attacks on the system. Örneğin, çok fazla sayıda oturum açma girişimi bir deneme yanılma saldırısına işaret ediyor olabilir.For example, a large number of failed sign-in attempts might indicate a brute-force attack. İsteklerdeki beklenmedik bir artış, bir dağıtılmış hizmet engelleme (DDoS) saldırısının sonucu olabilir.An unexpected surge in requests might be the result of a distributed denial-of-service (DDoS) attack. Nereden başlatılmış olursa olsun tüm kaynaklara yönelik istekleri izlemeye hazırlıklı olmalısınız.You must be prepared to monitor all requests to all resources regardless of the source of these requests. Oturum açma işleminde güvenlik açığı olan bir sistem kullanıcının gerçekten oturum açmasına gerek kalmadan kaynakları yanlışlıkla dış dünyanın kullanımına açabilir.A system that has a sign-in vulnerability might accidentally expose resources to the outside world without requiring a user to actually sign in.

Güvenliği izleme gereksinimleriRequirements for security monitoring

Güvenlik izlemesinin en kritik yönleri operatörün şunları hızla yapabilmesini sağlamalıdır:The most critical aspects of security monitoring should enable an operator to quickly:

  • Kimliği doğrulanmamış bir varlığın yetkisiz erişim denemelerini algılama.Detect attempted intrusions by an unauthenticated entity.
  • Varlıkların, kendilerine erişim verilmemiş veriler üzerinde işlem gerçekleştirme denemelerini belirleme.Identify attempts by entities to perform operations on data for which they have not been granted access.
  • Sistemin veya bazı sistem bölümlerinin dışarıdan veya içeriden saldırı altında olup olmadığını saptama.Determine whether the system, or some part of the system, is under attack from outside or inside. (Örneğin, kimliği doğrulanmamış kötü niyetli bir kullanıcı sistemi kapatmaya çalışıyor olabilir.)(For example, a malicious authenticated user might be attempting to bring the system down.)

Bu gereksinimleri desteklemek için operatörün varsa açamayacakları bildirilmelidir:To support these requirements, an operator should be notified if:

  • Yinelenen başarısız oturum açma denemeleri belirli bir süre içinde bir hesap sağlar.One account makes repeated failed sign-in attempts within a specified period.
  • Kimliği doğrulanmış bir hesabın belirlenen bir süre boyunca yasaklanmış bir kaynağa erişmek sürekli çalışır.One authenticated account repeatedly tries to access a prohibited resource during a specified period.
  • Belirtilen bir süre boyunca çok fazla sayıda kimliği doğrulanmamış veya yetkisiz istek oluşur.A large number of unauthenticated or unauthorized requests occur during a specified period.

Operatöre sağlanan bilgiler her isteğin kaynağının ana bilgisayar adresini içermelidir.The information that's provided to an operator should include the host address of the source for each request. Düzenli olarak belirli bir adres aralığından güvenlik ihlalleri yapılıyorsa, bu ana bilgisayarlar engellenebilir.If security violations regularly arise from a particular range of addresses, these hosts might be blocked.

Normal düzenden sapmayı gösteren eylemlerin hızla algılanabilmesi, sistemin güvenliğini korumakta önemli bir rol oynar.A key part in maintaining the security of a system is being able to quickly detect actions that deviate from the usual pattern. Alışılmadık bir zamanda etkinlikte ani bir artış olup olmadığını saptamaya yardımcı olmak için, başarısız ve/veya başarılı oturum açma isteklerinin sayısı görsel olarak görüntülenebilir.Information such as the number of failed and/or successful sign-in requests can be displayed visually to help detect whether there is a spike in activity at an unusual time. (Bu etkinliğe örnek olarak, iş günü sabah 9:00'da başlayan kullanıcıların 3:00'da oturum açması ve çok fazla sayıda işlem gerçekleştirmesi verilebilir.)(An example of this activity is users signing in at 3:00 AM and performing a large number of operations when their working day starts at 9:00 AM). Bu bilgiler, zamana dayalı otomatik ölçeklendirmeyi yapılandırmaya yardımcı olmak için de kullanılabilir.This information can also be used to help configure time-based autoscaling. Örneğin, operatör günün belirli bir saatinde çok fazla sayıda kullanıcının düzenli olarak oturum açtığını gözlemlerse, iş hacmini üstlenecek ek kimlik doğrulama hizmetlerinin başlatılmasını düzenleyebilir ve yoğunluk geçtikten sonra bu ek hizmetleri kapatabilir.For example, if an operator observes that a large number of users regularly sign in at a particular time of day, the operator can arrange to start additional authentication services to handle the volume of work, and then shut down these additional services when the peak has passed.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Dağıtılmış sistemlerin çoğunda güvenlik sistemin her yönünü kapsar.Security is an all-encompassing aspect of most distributed systems. Sistemin her yanındaki çeşitli noktalarda güvenlikle ilgili veriler oluşturulur.The pertinent data is likely to be generated at multiple points throughout a system. Uygulama, ağ donanımı, sunucu, güvenlik duvarı, virüsten koruma yazılımı ve diğer yetkisiz erişimi önleme öğeleri tarafından oluşturulan olaylardan elde edilen güvenlikle ilgili bilgileri toplamak için bir Güvenlik Bilgileri ve Olay Yönetimi (SIEM) yaklaşımı benimsemeyi göz önünde bulundurabilirsiniz.You should consider adopting a Security Information and Event Management (SIEM) approach to gather the security-related information that results from events raised by the application, network equipment, servers, firewalls, antivirus software, and other intrusion-prevention elements.

Güvenlik izlemesi uygulamanızın parçası olmayan araçlardan gelen verileri bir araya getirebilir.Security monitoring can incorporate data from tools that are not part of your application. Bu araçlar, kimlik doğrulaması yapmadan uygulamanıza ve verilerinize erişme denemelerini algılayan ağ filtrelerinin veya dış aracıların bağlantı noktası tarama etkinliklerini belirleyen hizmet programları içerebilir.These tools can include utilities that identify port-scanning activities by external agencies, or network filters that detect attempts to gain unauthenticated access to your application and data.

Her durumda, yönetici toplanan verilerden yararlanarak herhangi bir saldırının doğasını saptayabilmeli ve uygun önlemleri alabilmelidir.In all cases, the gathered data must enable an administrator to determine the nature of any attack and take the appropriate countermeasures.

Güvenlik verilerinin analiziAnalyzing security data

Güvenlik izlemesinin bir özelliği, verilerin alındığı kaynakların çeşitliliğidir.A feature of security monitoring is the variety of sources from which the data arises. Farklı biçimler ve ayrıntı düzeyleri söz konusu olduğundan, yakalanan verilerin mantıklı bir bilgi dizisi halinde bir araya getirilmesi için çoğunlukla karmaşık bir analiz gerekir.The different formats and level of detail often require complex analysis of the captured data to tie it together into a coherent thread of information. En basit durumlar (çok fazla sayıda başarısız oturum açma denemesini veya kritik kaynaklara yetkisiz erişim kazanmaya yönelik yinelenen girişimleri algılama gibi) bir yana bırakılırsa, güvenlik verileri üzerinde karmaşık otomatik işlemler gerçekleştirmek mümkün olmayabilir.Apart from the simplest of cases (such as detecting a large number of failed sign-ins, or repeated attempts to gain unauthorized access to critical resources), it might not be possible to perform any complex automated processing of security data. Bunun yerine, bu veriler, zaman damgalı özgün biçimlerinde, aksi durumda Uzman el ile analize izin vermek için güvenli bir depoya yazmak için tercih edilebilir.Instead, it might be preferable to write this data, timestamped but otherwise in its original form, to a secure repository to allow for expert manual analysis.

SLA izlemeSLA monitoring

Ücretli müşterileri destekleyen birçok ticari sistem, sistemin performansı hakkında SLA biçiminde garantiler verir.Many commercial systems that support paying customers make guarantees about the performance of the system in the form of SLAs. Temel olarak, SLA'lar sistemin üzerinde anlaşmaya varılmış bir zaman çerçevesinde ve kritik verilerde kayba neden olmadan tanımlı bir iş hacmini işleyebileceğini belirtir.Essentially, SLAs state that the system can handle a defined volume of work within an agreed time frame and without losing critical information. SLA izleme, sistemin ölçülebilir SLA'lara uyum gösterip gösteremediğiyle ilgilidir.SLA monitoring is concerned with ensuring that the system can meet measurable SLAs.

Not

SLA izleme, performans izlemeyle yakından ilgilidir.SLA monitoring is closely related to performance monitoring. Ama performans izleme sistemin optimum çalışmasını sağlamakla ilgilenirken, SLA izleme optimum çalışmanın gerçekte ne anlama geldiğini tanımlayan sözleşme yükümlülüğü tarafından belirlenir.But whereas performance monitoring is concerned with ensuring that the system functions optimally, SLA monitoring is governed by a contractual obligation that defines what optimally actually means.

SLA'ların tanımında genellikle şunlar kullanılır:SLAs are often defined in terms of:

  • Genel sistem kullanılabilirliği.Overall system availability. Örneğin, bir kuruluş sistemin zamanın yüzde 99,9'unda kullanılabilir olacağını garanti edebilir.For example, an organization might guarantee that the system will be available for 99.9 percent of the time. Bu garanti sistemin kapalı kalma süresinin yılda 9 saati veya haftada yaklaşık 10 dakikayı aşmaması anlamına gelir.This equates to no more than 9 hours of downtime per year, or approximately 10 minutes a week.
  • İşlem aktarım hızı.Operational throughput. Garantinin bu yönü genellikle bir veya birden çok üst sınır işaretiyle gösterilir. Örneğin, sistemin en çok 100.000 eş zamanlı kullanıcı isteğini destekleyeceği veya 10.000 eş zamanlı işlemi işleyeceği garanti edilebilir.This aspect is often expressed as one or more high-water marks, such as guaranteeing that the system can support up to 100,000 concurrent user requests or handle 10,000 concurrent business transactions.
  • İşlem yanıt süresi.Operational response time. Sistem kurumsal isteklerin işlenme hızıyla ilgili garantiler de verebilir.The system might also make guarantees for the rate at which requests are processed. Örneğin, tüm kurumsal işlemlerin yüzde 99'unun 2 saniye içinde biteceği ve tek tek hiçbir işlemin 10 saniyeden uzun sürmeyeceği belirtilebilir.An example is that 99 percent of all business transactions will finish within 2 seconds, and no single transaction will take longer than 10 seconds.

Not

Ticari sistemlerle ilgili bazı sözleşmeler müşteri desteği için de SLA'lar içeriyor olabilir.Some contracts for commercial systems might also include SLAs for customer support. Tüm Yardım Masası isteklerini beş dakika içinde bir yanıt çözüleceği ve tüm sorunların yüzde 99'u tam olarak 1 iş günü içinde getirilecektir örneğidir.An example is that all help-desk requests will elicit a response within five minutes, and that 99 percent of all problems will be fully addressed within 1 working day. Bu tür SLA'ların karşılanmasında etkili bir sorun izleme (bu bölümün devamında açıklanmıştır) kilit önem taşır.Effective issue tracking (described later in this section) is key to meeting SLAs such as these.

SLA izleme gereksinimleriRequirements for SLA monitoring

En üst düzeyde, operatör sistemin üzerinde anlaşmaya varılan SLA'lara uyup uymadığını bir bakışta saptayabilmelidir.At the highest level, an operator should be able to determine at a glance whether the system is meeting the agreed SLAs or not. Uymuyorsa, operatör detaya gidebilmeli ve temel faktörleri inceleyerek standardın altına düşen performansın nedenlerini saptayabilmelidir.And if not, the operator should be able to drill down and examine the underlying factors to determine the reasons for substandard performance.

Görsel olarak ortaya konabilecek tipik üst düzey göstergeler şunlardır:Typical high-level indicators that can be depicted visually include:

  • Hizmetin çalışır süresi yüzdesi.The percentage of service uptime.
  • Uygulama aktarım hızı (saniyedeki başarılı işlem sayısı cinsinden ölçülür).The application throughput (measured in terms of successful transactions and/or operations per second).
  • Başarılı/başarısız uygulama isteklerinin sayısı.The number of successful/failing application requests.
  • Uygulama ve sistem hataları, özel durumları ve uyarılarının sayısı.The number of application and system faults, exceptions, and warnings.

Bu göstergelerin hepsi belirli bir zaman aralığına göre filtrelenebilmelidir.All of these indicators should be capable of being filtered by a specified period of time.

Bir bulut uygulaması büyük olasılıkla bir dizi alt sistemden ve bileşenden oluşur.A cloud application will likely comprise a number of subsystems and components. Operatör üst düzey göstergelerden birini seçip bunun nasıl temel öğelerin durumundan oluştuğunu görebilmelidir.An operator should be able to select a high-level indicator and see how it's composed from the health of the underlying elements. Örneğin genel olarak sistemin çalışma süresi kabul edilebilir bir değerin altına düşerse, operatör duruma yakından bakabilmeli ve bu hataya katkıda bulunan öğeleri saptayabilmelidir.For example, if the uptime of the overall system falls below an acceptable value, an operator should be able to zoom in and determine which elements are contributing to this failure.

Not

Sistem çalışma süresinin dikkatle tanımlanması gerekir.System uptime needs to be defined carefully. Maksimum kullanılabilirliği güvence altına almak için yedeklilik kullanan bir sistemde, öğelerin tek tek örnekleri başarısız olsa da sistem işlevsel kalabilir.In a system that uses redundancy to ensure maximum availability, individual instances of elements might fail, but the system can remain functional. Sistem durumu izlemesi tarafından verilen sistem çalışma süresi, her öğenin çalışma süresi toplamını göstermelidir; sistemin aslında durdurulup durdurulmadığını göstermesi gerekmez.System uptime as presented by health monitoring should indicate the aggregate uptime of each element and not necessarily whether the system has actually halted. Ayrıca, hatalar yalıtılabilir.Additionally, failures might be isolated. Dolayısıyla belirli bir sistem kullanılamaz durumda olsa bile, sistemin kalan kısmı azaltılmış işlevsellikle de olsa kullanılabilir.So even if a specific system is unavailable, the remainder of the system might remain available, although with decreased functionality. (E-ticaret sistemlerinde, sistemdeki bir hata müşterinin sipariş vermesini engelleyebilir ama müşteri yine de ürün kataloğunu gözden geçirebilir.)(In an e-commerce system, a failure in the system might prevent a customer from placing orders, but the customer might still be able to browse the product catalog.)

Üst düzey göstergelerden herhangi biri belirlenen eşiği aşarsa, uyarı amacıyla sistem bir olay oluşturabilmelidir.For alerting purposes, the system should be able to raise an event if any of the high-level indicators exceed a specified threshold. Üst düzey göstergeyi oluşturan çeşitli faktörlerin daha alt düzey ayrıntıları, uyarı sistemine bağlamsal veriler olarak sağlanmalıdır.The lower-level details of the various factors that compose the high-level indicator should be available as contextual data to the alerting system.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

SLA izlemesini desteklemek için gereken ham veriler, performans izlemesi için gereken ham verilere, ayrıca bazı açılardan sistem durumu ve kullanılabilirlik izlemesine de benzer.The raw data that's required to support SLA monitoring is similar to the raw data that's required for performance monitoring, together with some aspects of health and availability monitoring. (Diğer ayrıntılar için söz konusu bölümlere bakın.) Bu verileri şu yollarla yakalayabilirsiniz:(See those sections for more details.) You can capture this data by:

  • Uç nokta izlemesi gerçekleştirerek.Performing endpoint monitoring.
  • Özel durumları, hataları ve uyarıları günlüğe kaydetme.Logging exceptions, faults, and warnings.
  • Kullanıcı isteklerinin yürütülmesini izleyerek.Tracing the execution of user requests.
  • Sistemin kullandığın tüm üçüncü taraf hizmetlerinin durumunu izleyerek.Monitoring the availability of any third-party services that the system uses.
  • Performans ölçümlerini ve sayaçlarını kullanarak.Using performance metrics and counters.

Tüm verileri zaman aşımına gerekir ve zaman damgalı.All data must be timed and timestamped.

SLA verilerinin analiziAnalyzing SLA data

Sistemin genel performansının görünümünü oluşturmak için izleme verileri bir araya toplanmalıdır.The instrumentation data must be aggregated to generate a picture of the overall performance of the system. Temel alt sistemlerin performansının incelenebilmesi için toplanan verilerin detaya gitmeyi de desteklemesi gerekir.Aggregated data must also support drill-down to enable examination of the performance of the underlying subsystems. Örneğin, şunları yapabilmelisiniz:For example, you should be able to:

  • Belirli bir süre boyunca gelen kullanıcı isteklerinin toplam sayısını hesaplama ve bu isteklerde başarı ile başarısızlık oranını saptama.Calculate the total number of user requests during a specified period and determine the success and failure rate of these requests.
  • Kullanıcı isteklerinin yanıt sürelerini bir araya getirerek sistem yanıt sürelerinin genel görünümünü oluşturma.Combine the response times of user requests to generate an overall view of system response times.
  • Kullanıcı isteklerinin ilerleme durumunu analiz ederek isteğin genel yanıt süresini bu istek dahilindeki tek tek çalışma öğelerinin yanıt sürelerine bölme.Analyze the progress of user requests to break down the overall response time of a request into the response times of the individual work items in that request.
  • Belirli bir zaman aralığındaki çalışma süresinin yüzdesi olarak sistemin genel kullanılabilirliğini saptama.Determine the overall availability of the system as a percentage of uptime for any specific period.
  • Sistemdeki tek tek bileşenlerin ve hizmetlerin kullanılabilirlik süresi yüzdesini analiz etme.Analyze the percentage time availability of the individual components and services in the system. Bu analiz üçüncü taraf hizmetlerinin oluşturduğu günlükleri ayrıştırmayı içerebilir.This might involve parsing logs that third-party services have generated.

Birçok ticari sistemin belirli bir süreye (normalde bir ay) ait, üzerinde anlaşmaya varılmış SLA'lara karşılık gelen gerçek performans rakamlarını bildirmesi gerekir.Many commercial systems are required to report real performance figures against agreed SLAs for a specified period, typically a month. Bu süre boyunca SLA'lara uyulmamışsa, kredileri veya müşterilere yapılacak başka biçimlerdeki geri ödemeleri hesaplamak için bu bilgiler kullanılabilir.This information can be used to calculate credits or other forms of repayments for customers if the SLAs are not met during that period. Hizmetin kullanılabilirliğini hesaplamak için, Kullanılabilirlik verilerinin analizi bölümünde açıklanan tekniği kullanabilirsiniz.You can calculate availability for a service by using the technique described in the section Analyzing availability data.

Bir kuruluş, dahili nedenlerle hizmetlerin başarısız olmasına neden olan olayların sayısını ve doğasını da izleyebilir.For internal purposes, an organization might also track the number and nature of incidents that caused services to fail. Bu sorunların nasıl hızla çözülebileceğini veya tamamen ortadan kaldırılabileceğini öğrenmek, kapalı kalma sürelerini azaltmaya ve SLA'lara uymaya yardımcı olacaktır.Learning how to resolve these issues quickly, or eliminate them completely, will help to reduce downtime and meet SLAs.

DenetimAuditing

Uygulamanın doğasına bağlı olarak, kullanıcı işlemlerini denetleme ve tüm veri erişiminin kaydını tutma gereksinimlerini belirleyen yasal düzenlemeler olabilir.Depending on the nature of the application, there might be statutory or other legal regulations that specify requirements for auditing users' operations and recording all data access. Denetim, müşterileri belirli isteklere bağlayan kanıtı sağlayabilir.Auditing can provide evidence that links customers to specific requests. Bir müşteri uygulama veya hizmet için sorumlu olduğu kuruluş arasındaki güveni korumaya yardımcı olmak üzere birçok e-ticaret sistemi önemli bir etmen olması kabullenme olur.Nonrepudiation is an important factor in many e-business systems to help maintain trust be between a customer and the organization that's responsible for the application or service.

Denetim gereksinimleriRequirements for auditing

Analistin kullanıcıların eylemlerini yeniden oluşturabilmesi için gerçekleştirdikleri işle ilgili işlemlerin sırasını izleyebilmesi gerekir.An analyst must be able to trace the sequence of business operations that users are performing so that you can reconstruct users' actions. Bu yalnızca kayıtlar için gerekli olabileceği gibi, adli bir soruşturma için de gerekebilir.This might be necessary simply as a matter of record, or as part of a forensic investigation.

Denetim bilgileri son derece hassastır.Audit information is highly sensitive. Büyük olasılıkla, gerçekleştirdikleri görevlerle birlikte sistemin kullanıcılarını da tanımlayan veriler içerir.It will likely include data that identifies the users of the system, together with the tasks that they're performing. Bu nedenle, denetim bilgileri büyük olasılıkla grafik işlemlerde detaya gitmeyi destekleyen etkileşimli bir sistem değil yalnızca güvenilen analistlerin kullanabileceği raporlar biçiminde olacaktır.For this reason, audit information will most likely take the form of reports that are available only to trusted analysts rather than as an interactive system that supports drill-down of graphical operations. Analistin bir dizi rapor oluşturabilmesi gerekir.An analyst should be able to generate a range of reports. Örneğin, raporlarda belirli bir zaman çerçevesinde gerçekleşen tüm kullanıcı etkinlikleri listelenebilir, tek tek kullanıcıların etkinlik kronolojisinin ayrıntıları yer alabilir ya da bir veya birden çok kaynak üzerinde gerçekleştirilen işlemlerin sırası listelenebilir.For example, reports might list all users' activities occurring during a specified time frame, detail the chronology of activity for a single user, or list the sequence of operations performed against one or more resources.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Denetim için birincil bilgi kaynakları şunlardan oluşabilir:The primary sources of information for auditing can include:

  • Kullanıcı kimlik doğrulamasını yöneten güvenlik sistemi.The security system that manages user authentication.
  • Kullanıcı etkinliğini kaydeden izleme günlükleri.Trace logs that record user activity.
  • Tüm tanımlanabilen ve tanımlanamayan ağ isteklerinin izlendiği güvenlik günlükleri.Security logs that track all identifiable and unidentifiable network requests.

Denetim verilerinin biçimini ve bunların depolanma yöntemini, yasal düzenleme gereksinimleri yönlendirebilir.The format of the audit data and the way in which it's stored might be driven by regulatory requirements. Örneğin, verileri herhangi bir şekilde temizlemek mümkün olmayabilir.For example, it might not be possible to clean the data in any way. (Bu veriler özgün biçimlerinde kaydedilmelidir.) Bu verilerle oynanmasını önlemek için bunların tutulduğu depoya erişim koruma altına alınmalıdır.(It must be recorded in its original format.) Access to the repository where it's held must be protected to prevent tampering.

Denetim verilerinin analiziAnalyzing audit data

Analist ham verilerin tamamına, özgün biçimlerinde erişebilmelidir.An analyst must be able to access the raw data in its entirety, in its original form. Ortak denetim raporları oluşturma gereksiniminin dışında, bu verilerin analizinde kullanılan araçlar büyük olasılıkla özelleştirilmiştir ve sistemin dışında tutulur.Aside from the requirement to generate common audit reports, the tools for analyzing this data are likely to be specialized and kept external to the system.

Kullanımı izlemeUsage monitoring

Kullanımı izleme işleminde uygulama özelliklerinin ve bileşenlerinin nasıl kullanıldığı izlenir.Usage monitoring tracks how the features and components of an application are used. Operatör toplanan verileri kullanarak şunları yapabilir:An operator can use the gathered data to:

  • Hangi özelliklerin yoğun kullanıldığını ve sistemdeki olası etkin noktaları saptayabilir.Determine which features are heavily used and determine any potential hotspots in the system. Yoğun trafiği olan öğeler işlevsel bölümlemeden veya işi daha eşit yaymak için çoğaltmadan bile yararlanabilir.High-traffic elements might benefit from functional partitioning or even replication to spread the load more evenly. Operatör bu bilgileri kullanarak hangi özelliklerin sık kullanılmadığından ve sistemin gelecek sürümlerinden birinde kullanım dışı bırakılmaya veya değiştirilmeye aday olduğundan emin olabilir.An operator can also use this information to ascertain which features are infrequently used and are possible candidates for retirement or replacement in a future version of the system.

  • Sistemin normal kullanım koşullarında işletimsel olaylar hakkında bilgi alabilir.Obtain information about the operational events of the system under normal use. Örneğin, bir e-ticaret sitesinde işlem sayısı ve bunlardan sorumlu olan müşterilerin hacmiyle ilgili istatistiksel bilgileri kaydedebilirsiniz.For example, in an e-commerce site, you can record the statistical information about the number of transactions and the volume of customers that are responsible for them. Bu bilgiler, müşteri sayısı arttıkça kapasite planlaması yapmak için kullanılabilir.This information can be used for capacity planning as the number of customers grows.

  • Sistemin performansı ve işlevselliğiyle ilgili müşteri memnuniyetini (büyük olasılıkla dolaylı olarak) saptayabilir.Detect (possibly indirectly) user satisfaction with the performance or functionality of the system. Örneğin, bir e-ticaret sisteminde çok sayıda müşteri düzenli olarak alışveriş sepetini bırakıyorsa, bu durum alışverişi sonuçlandırma işlevindeki bir sorundan kaynaklanıyor olabilir.For example, if a large number of customers in an e-commerce system regularly abandon their shopping carts, this might be due to a problem with the checkout functionality.

  • Fatura bilgilerini oluşturabilir.Generate billing information. Ticari bir uygulama veya çok kiracılı bir hizmet müşterilerini kullandıkları kaynaklara göre ücretlendiriyor olabilir.A commercial application or multitenant service might charge customers for the resources that they use.

  • Kotaları zorunlu kılabilir.Enforce quotas. Çok kiracılı bir sistemde kullanıcı belirli bir süre içinde ücretli işlem süresi veya kaynak kullanımı kotasını aşarsa, erişimi sınırlandırılabilir veya işlem kısıtlanabilir.If a user in a multitenant system exceeds their paid quota of processing time or resource usage during a specified period, their access can be limited or processing can be throttled.

Kullanım izleme gereksinimleriRequirements for usage monitoring

Sistem kullanımını incelemek için, operatörün normalde şu bilgileri görmesi gerekir:To examine system usage, an operator typically needs to see information that includes:

  • Her alt sistem tarafından işlenen ve her kaynağa yönlendirilen isteklerin sayısı.The number of requests that are processed by each subsystem and directed to each resource.
  • Her kullanıcının gerçekleştirdiği çalışma.The work that each user is performing.
  • Her kullanıcının kapladığı veri depolama alanı.The volume of data storage that each user occupies.
  • Her kullanıcının eriştiği kaynaklar.The resources that each user is accessing.

Operatör graflar da oluşturabilmelidir.An operator should also be able to generate graphs. Örneğin, bir grafta en çok kaynak isteyen kullanıcılar ya da en sık erişilen kaynaklar veya sistem özellikleri gösterilebilir.For example, a graph might display the most resource-hungry users, or the most frequently accessed resources or system features.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Kullanım izlemesi görece yüksek bir düzeyde gerçekleştirilir.Usage tracking can be performed at a relatively high level. Her isteğin başlangıç ve bitiş zamanlarını ve isteğin doğasını (söz konusu kaynağa bağlı olarak okuma, yazma, vb.) kaydedebilir.It can note the start and end times of each request and the nature of the request (read, write, and so on, depending on the resource in question). Bu bilgileri şu şekilde elde edebilirsiniz:You can obtain this information by:

  • Kullanıcı etkinliğini izleyerek.Tracing user activity.
  • Her kaynağın kullanımını ölçen performans sayaçlarını yakalayarak.Capturing performance counters that measure the utilization for each resource.
  • Her kullanıcının kaynak tüketimini izleyerek.Monitoring the resource consumption by each user.

Ölçüm amacıyla, ayrıca hangi kullanıcıların hangi işlemlerin yanı sıra, bu işlemleri kullanmanız kaynakları gerçekleştirilmesinden sorumlu olduğunu belirlemek mümkün olması gerekir.For metering purposes, you also need to be able to identify which users are responsible for performing which operations, and the resources that these operations use. Doğru faturalama için, toplanan bilgiler yeterince ayrıntılı olmalıdır.The gathered information should be detailed enough to enable accurate billing.

Sorun izlemeIssue tracking

Sistemde beklenmedik olaylar veya davranışlarla karşılaşan müşteriler veya diğer kullanıcılar sorun bildirebilir.Customers and other users might report issues if unexpected events or behavior occurs in the system. Sorun izleme işlemi bu sorunları yönetmekle, bunları sistemdeki temel sorun çözümü çalışmalarıyla ilişkilendirmekle ve olası çözümler konusunda müşterileri bilgilendirmekle ilgilidir.Issue tracking is concerned with managing these issues, associating them with efforts to resolve any underlying problems in the system, and informing customers of possible resolutions.

Sorun izleme gereksinimleriRequirements for issue tracking

Operatörler sorun izlemesi gerçekleştirmek için genellikle kullanıcıların bildirdiği sorunların ayrıntılarını kaydetmelerine ve raporlamalarına olanak tanıyan ayrı bir sistem kullanır.Operators often perform issue tracking by using a separate system that enables them to record and report the details of problems that users report. Bu ayrıntılar kullanıcının gerçekleştirmeye çalıştığı görevlerden, sorunun belirtilerinden, olayların sırasından ve gönderilen hata veya uyarı iletilerinden oluşabilir.These details can include the tasks that the user was trying to perform, symptoms of the problem, the sequence of events, and any error or warning messages that were issued.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Sorun izleme verileri için ilk veri kaynağı, en başta sorunu bildiren kullanıcıdır.The initial data source for issue-tracking data is the user who reported the issue in the first place. Kullanıcı aşağıdakiler gibi ek veriler sağlayabilir:The user might be able to provide additional data such as:

  • Kilitlenme bilgi dökümü (uygulama kullanıcının masaüstünde çalıştırılan bir bileşen içeriyorsa).A crash dump (if the application includes a component that runs on the user's desktop).
  • Ekran anlık görüntüsü.A screen snapshot.
  • Hatanın oluştuğu tarih ve saat, ayrıca kullanıcının konumu gibi ortamla ilgili diğer bilgiler.The date and time when the error occurred, together with any other environmental information such as the user's location.

Bu bilgiler hata ayıklama çalışmalarına ve yazılımın gelecek sürümleri için kapsam oluşturmaya yardımcı olmak için kullanılabilir.This information can be used to help the debugging effort and help construct a backlog for future releases of the software.

Sorun izleme verilerinin analiziAnalyzing issue-tracking data

Farklı kullanıcılar aynı sorunu bildirebilir.Different users might report the same problem. Sorun izleme sistemi ortak raporları birbiriyle ilişkilendirmelidir.The issue-tracking system should associate common reports.

Her sorun raporunda hata ayıklama çalışmasının ilerleme durumu kaydedilmelidir.The progress of the debugging effort should be recorded against each issue report. Sorun çözüldüğünde, müşteri çözüm konusunda bilgilendirilebilir.When the problem is resolved, the customer can be informed of the solution.

Kullanıcının bildirdiği sorunun sorun izleme sisteminde bilinen bir çözümü varsa, operatör kullanıcıyı çözüm hakkında hemen bilgilendirebilmelidir.If a user reports an issue that has a known solution in the issue-tracking system, the operator should be able to inform the user of the solution immediately.

İşlemleri izleme ve yazılım sürümlerinde hataları ayıklamaTracing operations and debugging software releases

Bir kullanıcı bir sorun bildirdiğinde, kullanıcı genellikle yalnızca, işlemleri üzerindeki anlık etkisini farkında değil.When a user reports an issue, the user is often only aware of the immediate effect that it has on their operations. Kullanıcı, sistemin bakımından sorumlu olan operatöre sadece kendi deneyiminin sonuçlarını bildirebilir.The user can only report the results of their own experience back to an operator who is responsible for maintaining the system. Bu deneyimler ise çoğunlukla bir veya birden çok temel sorunun yalnızca görünür belirtileridir.These experiences are usually just a visible symptom of one or more fundamental problems. Birçok durumda, sorunun kök nedenini belirlemek için analistin temeldeki işlemlerin kronolojisini sorgulaması gerekecektir.In many cases, an analyst will need to dig through the chronology of the underlying operations to establish the root cause of the problem. Bu işlem kök neden analizi olarak adlandırılır.This process is called root cause analysis.

Not

Kök neden analizi uygulamanın tasarımındaki verimsizlikleri ortaya çıkarabilir.Root cause analysis might uncover inefficiencies in the design of an application. Böyle durumlarda, etkilenen öğeler üzerinde yeniden çalışma yapmak ve bunları bir sonraki sürüm kapsamında dağıtmak mümkün olabilir.In these situations, it might be possible to rework the affected elements and deploy them as part of a subsequent release. Bu işlem dikkatli bir denetim gerektirir ve güncelleştirilen bileşenler yakından izlenmelidir.This process requires careful control, and the updated components should be monitored closely.

İzleme ve hata ayıklama gereksinimleriRequirements for tracing and debugging

Beklenmedik olayları ve diğer sorunları izlemek için, izleme verilerinin analistin bu sorunların kökenine dönmesine ve gerçekleşen olayların sırasını yeniden oluşturmasına olarak tanıyacak kadar bilgi sağlayabilmesi yaşamsal önem taşır.For tracing unexpected events and other problems, it's vital that the monitoring data provides enough information to enable an analyst to trace back to the origins of these issues and reconstruct the sequence of events that occurred. Bu bilgiler bir analistin tüm sorunların kök nedenini tanımlaması için yeterli olmalıdır.This information must be sufficient to enable an analyst to diagnose the root cause of any problems. Bundan sonra bir geliştirici bu sorunların yeniden ortaya çıkmasını önlemek için gerekli değişiklikleri yapabilir.A developer can then make the necessary modifications to prevent them from recurring.

Veri kaynakları, ölçümlü izleme ve veri toplama gereksinimleriData sources, instrumentation, and data-collection requirements

Sorun giderme, müşteri belirli bir istekte bulunduğunda sistemdeki mantıksal akışı çizen bir ağaç oluşturmak için işlemin parçası olarak çağrılan tüm yöntemlerin (ve parametrelerinin) izlenmesini içerebilir.Troubleshooting can involve tracing all the methods (and their parameters) invoked as part of an operation to build up a tree that depicts the logical flow through the system when a customer makes a specific request. Bu akışın sonucu olarak sistemin oluşturduğu özel durumlar ve uyarılar yakalanmalı ve günlüğe kaydedilmelidir.Exceptions and warnings that the system generates as a result of this flow need to be captured and logged.

Hata ayıklamayı desteklemek için sistem operatörün sistemin kritik noktalarında durumu yakalamasına olanak tanıyan kancalar sağlayabilir.To support debugging, the system can provide hooks that enable an operator to capture state information at crucial points in the system. Öte yandan, seçili işlemlerde devam ederken sistem adım adım ayrıntılı bilgiler de verebilir.Or, the system can deliver detailed step-by-step information as selected operations progress. Verilerin bu ayrıntı düzeyinde yakalanması sisteme ek yük getirebilir ve geçici bir işlem olmalıdır.Capturing data at this level of detail can impose an additional load on the system and should be a temporary process. Operatör, asıl olarak son derece alışılmamış ve yinelenmesi güç bir dizi olay gerçekleştiğinde veya sistemde yeni kullanıma sunulan bir veya birden çok öğenin dikkatle izlenip bunların beklendiği gibi çalıştığından emin olmak gerektiğinde bu işlemi kullanır.An operator uses this process mainly when a highly unusual series of events occurs and is difficult to replicate, or when a new release of one or more elements into a system requires careful monitoring to ensure that the elements function as expected.

İzleme ve tanılama işlem hattıThe monitoring and diagnostics pipeline

Büyük ölçekli bir dağıtılmış sistemin izlenmesi son derece zor olabilir.Monitoring a large-scale distributed system poses a significant challenge. Önceki bölümde açıklanan senaryolardan her birinin yalıtılmış olarak ele alınması gerekmez.Each of the scenarios described in the previous section should not necessarily be considered in isolation. Büyük olasılıkla her durumda gereken izleme ve tanılama verilerinde ciddi bir çakışma olur; ama bu verilerin farklı yollarla işlenmesi ve sunulması gerekebilir.There is likely to be a significant overlap in the monitoring and diagnostic data that's required for each situation, although this data might need to be processed and presented in different ways. Bu nedenlerle, izleme ve tanılamaya bütüncül bir yaklaşım benimsemelisiniz.For these reasons, you should take a holistic view of monitoring and diagnostics.

İzleme ve tanılama işleminin tamamını Şekil 1'de gösterilen aşamalardan oluşmuş bir işlem hattı olarak gözünüzde canlandırabilirsiniz.You can envisage the entire monitoring and diagnostics process as a pipeline that comprises the stages shown in Figure 1.

İzleme ve tanılama işlem hattının aşamaları

Şekil 1. İzleme ve tanılama işlem hattının aşamaları.Figure 1. The stages in the monitoring and diagnostics pipeline.

Şekil 1'de izleme ve tanılamaya yönelik verilerin nasıl çeşitli veri kaynaklarından gelebildiği vurgulanmaktadır.Figure 1 highlights how the data for monitoring and diagnostics can come from a variety of data sources. Ölçümlü izleme ve toplama aşamaları verilerin hangi kaynaklardan yakalanması gerektiğini belirlemek, hangi verilerin yakalanacağını, nasıl yakalanacağını ve kolayca incelenebilmesi için bu verilerin nasıl biçimlendirileceğini saptamakla ilgilidir.The instrumentation and collection stages are concerned with identifying the sources from where the data needs to be captured, determining which data to capture, how to capture it, and how to format this data so that it can be easily examined. Analiz/tanılama aşaması ham verileri alır ve bunları kullanarak bir operatörün sistemin durumunu saptamak için yararlanabileceği anlamlı bilgiler oluşturur.The analysis/diagnosis stage takes the raw data and uses it to generate meaningful information that an operator can use to determine the state of the system. Operatör bu bilgileri gerçekleştirilecek olası eylemler hakkında karar vermek için kullanabilir ve ardından sonuçları yeniden ölçümlü izleme ve toplama aşamalarına sağlar.The operator can use this information to make decisions about possible actions to take, and then feed the results back into the instrumentation and collection stages. Görselleştirme/uyarı verme aşaması sistem durumunun kullanılabilir bir görünümünü sunar.The visualization/alerting stage phase presents a consumable view of the system state. Bir dizi panoyu kullanarak neredeyse gerçek zamanlı bilgiler görüntüleyebilir.It can display information in near real time by using a series of dashboards. Ayrıca verilerin, uzun vadeli eğilimleri belirlemeye yardımcı olabilecek bir geçmiş görünümünü sağlamak için raporlar, graflar ve grafikler oluşturabilir.And it can generate reports, graphs, and charts to provide a historical view of the data that can help identify long-term trends. Bilgiler bir KPI'nin kabul edilebilir sınırları aşma eğiliminde olduğunu gösterirse, bu aşama operatöre bir uyarı da tetikleyebilir.If information indicates that a KPI is likely to exceed acceptable bounds, this stage can also trigger an alert to an operator. Bazı durumlarda, otomatik ölçeklendirme gibi düzeltici eylemler gerçekleştirmeyi deneyen otomatik bir süreci tetiklemek için de uyarı kullanılabilir.In some cases, an alert can also be used to trigger an automated process that attempts to take corrective actions, such as autoscaling.

Bu adımların sürekli akan bir süreç oluşturduğuna ve aşamaların paralel yürütüldüğüne dikkat edin.Note that these steps constitute a continuous-flow process where the stages are happening in parallel. İdeal olan tüm aşamaların dinamik olarak yapılandırılabilir olmasıdır.Ideally, all the phases should be dynamically configurable. Bazı noktalarda, özellikle de sistemin yeni dağıtıldığı ve sorunlarla karşılaştığı durumlarda, daha sık olarak daha kapsamlı veriler toplamak gerekebilir.At some points, especially when a system has been newly deployed or is experiencing problems, it might be necessary to gather extended data on a more frequent basis. Bunun dışındaki zamanlarda, sistemin düzgün çalıştığını doğrulamak için temel düzeyde gerekli verileri yakalama uygulamasına dönmek mümkündür.At other times, it should be possible to revert to capturing a base level of essential information to verify that the system is functioning properly.

Ayrıca, izleme işleminin tamamı canlı, devam eden ve geri bildirimlere bağlı olarak ince ayarlamalar ve geliştirmeler yapılan bir çözüm olarak değerlendirilmelidir.Additionally, the entire monitoring process should be considered a live, ongoing solution that's subject to fine-tuning and improvements as a result of feedback. Örneğin, sistem durumunu saptamak için birçok faktörün ölçümünü almakla işe başlayabilirsiniz.For example, you might start with measuring many factors to determine system health. Zaman içinde siz konuyla ilgili olmayan ölçümleri attıkça analizde kapsam daraltılabilir ve arka plan gürültüsünü en aza indirip ihtiyacınız olan verilere daha net odaklanmanıza olanak tanınabilir.Analysis over time might lead to a refinement as you discard measures that aren't relevant, enabling you to more precisely focus on the data that you need while minimizing background noise.

İzleme ve tanılama verilerinin kaynaklarıSources of monitoring and diagnostic data

İzleme işleminin kullandığı bilgiler Şekil 1'de gösterildiği gibi çeşitli kaynaklardan gelebilir.The information that the monitoring process uses can come from several sources, as illustrated in Figure 1. Uygulama düzeyinde, bilgiler sistem kodunun içine eklenmiş izleme günlüklerinden gelir.At the application level, information comes from trace logs incorporated into the code of the system. Geliştiriciler kodlarında denetim akışını izlerken standart bir yaklaşım benimsemelidir.Developers should follow a standard approach for tracking the flow of control through their code. Örneğin bir yönteme yapılacak giriş, yöntemin adını, geçerli zamanı, her parametrenin değerini ve diğer ilgili bilgileri belirten bir izleme iletisi gönderebilir.For example, an entry to a method can emit a trace message that specifies the name of the method, the current time, the value of each parameter, and any other pertinent information. Giriş ve çıkış zamanlarının kaydedilmesi de yararlı olabilir.Recording the entry and exit times can also prove useful.

Tüm özel durumları ve uyarıları günlüğe kaydetmeli ve iç içe yerleştirilmiş özel durumların ve uyarıların tümünün tam izlemesini tuttuğunuzdan emin olmalısınız.You should log all exceptions and warnings, and ensure that you retain a full trace of any nested exceptions and warnings. İdeal olan, kodu çalıştıran kullanıcıyı tanımlayan bilgileri, etkinlik ilişkilendirme bilgileriyle birlikte (istekleri sistemden geçerken izlemek için) yakalamanızdır.Ideally, you should also capture information that identifies the user who is running the code, together with activity correlation information (to track requests as they pass through the system). Ayrıca, ileti kuyrukları, veritabanları, dosyalar ve diğer bağımlı hizmetler gibi tüm kaynaklara erişim girişimlerini de günlüğe kaydetmelisiniz.And you should log attempts to access all resources such as message queues, databases, files, and other dependent services. Bu bilgiler ölçüm ve denetim amaçlarıyla kullanılabilir.This information can be used for metering and auditing purposes.

Birçok uygulama, bir 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ın.Many applications use libraries and frameworks to perform common tasks such as accessing a data store or communicating over a network. Bu çerçeveler kendi izleme iletilerini ve ham tanılama bilgilerini (örneğin işlem hızları ve başarılı/başarısız veri iletimleri) sağlayacak şekilde yapılandırılabilme özelliğine sahip olabilir.These frameworks might be configurable to provide their own trace messages and raw diagnostic information, such as transaction rates and data transmission successes and failures.

Not

Birçok modern çerçeve performans ve izleme olaylarını otomatik olarak yayımlar.Many modern frameworks automatically publish performance and trace events. Bu bilgilerin yakalanması için tek gereken bunların alınması, sonra da işlenebilecekleri ve analiz edilebilecekleri bir yerde depolanması için bir yol sağlamaktır.Capturing this information is simply a matter of providing a means to retrieve and store it where it can be processed and analyzed.

Uygulamanın çalıştırıldığı işletim sistemi I/O hızları, bellek kullanımı ve CPU kullanımını gösteren performans sayaçları gibi sistem geneline ilişkin alt düzey bilgilerin alındığı bir kaynak olabilir.The operating system where the application is running can be a source of low-level system-wide information, such as performance counters that indicate I/O rates, memory utilization, and CPU usage. İşletim sistemi hataları (örneğin bir dosyanın düzgün açılamaması) da raporlanabilir.Operating system errors (such as the failure to open a file correctly) might also be reported.

Ayrıca sisteminizin üzerinde çalıştığı temel altyapıyı ve bileşenleri de dikkate almalısınız.You should also consider the underlying infrastructure and components on which your system runs. Sanal makineler, sanal ağlar ve depolama hizmetlerinin hepsi altyapı düzeyinde önemli performans sayaçları ve diğer tanılama verilerinin kaynağı olabilir.Virtual machines, virtual networks, and storage services can all be sources of important infrastructure-level performance counters and other diagnostic data.

Uygulamanızda web sunucusu veya veritabanı yönetim sistemi gibi başka dış hizmetler kullanılıyorsa, bu hizmetler kendi izleme bilgilerini, günlüklerini ve performans sayaçlarını yayımlıyor olabilir.If your application uses other external services, such as a web server or database management system, these services might publish their own trace information, logs, and performance counters. SQL Server veritabanında gerçekleştirilen izleme işlemleri için SQL Server Dinamik Yönetim Görünümleri ve web sunucusuna yönelik istekleri kaydetmek için ISS izleme günlükleri buna örnek verilebilir.Examples include SQL Server Dynamic Management Views for tracking operations performed against a SQL Server database, and IIS trace logs for recording requests made to a web server.

Sistemin bileşenleri değiştikçe ve yeni sürümler dağıtıldıkça, sorunların, olayların ve ölçümlerin hangi sürümle bağlantılı olduğunu belirlemek önemlidir.As the components of a system are modified and new versions are deployed, it's important to be able to attribute issues, events, and metrics to each version. Bir bileşenin belirli bir sürümüyle ilişkili sorunların hızla izlenmesi ve düzeltilmesi için, bu bilgilerin geriye, yayın işlem hattında bağlanması gerekir.This information should be tied back to the release pipeline so that problems with a specific version of a component can be tracked quickly and rectified.

Güvenlik sorunları sistemin herhangi bir noktasında oluşabilir.Security issues might occur at any point in the system. Örneğin, bir kullanıcı geçersiz kullanıcı kimliği veya parolayla oturum açmaya çalışabilir.For example, a user might attempt to sign in with an invalid user ID or password. Kimliği doğrulanmış bir kullanıcı bir kaynağa yetkisiz erişim elde etmeyi deneyebilir.An authenticated user might try to obtain unauthorized access to a resource. Bir kullanıcı şifrelenmiş bilgilere erişmek için geçersiz veya eski bir anahtar sağlayabilir.Or a user might provide an invalid or outdated key to access encrypted information. Başarılı ve başarısız isteklerin güvenlikle ilgili bilgileri her zaman günlüğe kaydedilmelidir.Security-related information for successful and failing requests should always be logged.

Uygulamada ölçümlü izleme yapma bölümü yakalamanız gereken bilgilerle ilgili daha fazla rehberlik sağlar.The section Instrumenting an application contains more guidance on the information that you should capture. Ama bu bilgileri toplamak için çeşitli stratejiler kullanabilirsiniz:But you can use a variety of strategies to gather this information:

  • Uygulama/sistem izleme.Application/system monitoring. Bu stratejide uygulamanın, uygulama çerçevelerinin, işletim sisteminin ve altyapının içinde bulunan dahili kaynaklar kullanılır.This strategy uses internal sources within the application, application frameworks, operating system, and infrastructure. İstemci isteğinin yaşam döngüsü boyunca dikkate değer noktalarda uygulama kodu kendi izleme verilerini oluşturabilir.The application code can generate its own monitoring data at notable points during the lifecycle of a client request. Uygulama, koşulların gerektirdiği şekilde seçmeli olarak etkinleştirilebilen veya devre dışı bırakılabilen izleme deyimleri içerebilir.The application can include tracing statements that might be selectively enabled or disabled as circumstances dictate. Ayrıca bir tanılama çerçevesi kullanıp tanılamayı dinamik olarak eklemek de mümkün olabilir.It might also be possible to inject diagnostics dynamically by using a diagnostics framework. Bu çerçeveler normalde kodunuzdaki çeşitli ölçümlü izleme noktalarına ekleyebildiği ve bu noktalarda izleme verilerini yakalayan eklentiler sağlar.These frameworks typically provide plug-ins that can attach to various instrumentation points in your code and capture trace data at these points.

    Buna ek olarak, kodunuz ve/veya temel altyapı kritik noktalarda olaylar oluşturabilir.Additionally, your code and/or the underlying infrastructure might raise events at critical points. Bu olayları dinleyecek şekilde yapılandırılan izleme aracıları olay bilgilerini kaydedebilir.Monitoring agents that are configured to listen for these events can record the event information.

  • Gerçek kullanıcı izleme.Real user monitoring. Bu yaklaşım kullanıcıyla uygulama arasındaki etkileşimleri kaydeder ve her istekle yanıtın akışını gözlemler.This approach records the interactions between a user and the application and observes the flow of each request and response. Bu bilgilerin iki amacı olabilir: her kullanıcı tarafından ölçüm kullanımına yönelik olarak kullanılabilir ve kullanıcıların uygun kalitede hizmet (örneğin, hızlı yanıt süresi, düşük gecikme süresi ve minimum hata) alıp almadıklarını saptamak için kullanılabilir.This information can have a two-fold purpose: it can be used for metering usage by each user, and it can be used to determine whether users are receiving a suitable quality of service (for example, fast response times, low latency, and minimal errors). Yakalanan verileri kullanarak en sık hata oluşan sorunlu alanları tanımlayabilirsiniz.You can use the captured data to identify areas of concern where failures occur most often. Ayrıca, uygulamadaki etkin noktalardan veya başka herhangi bir performans sorunundan dolayı sistemin yavaşladığı öğeleri tanımlamak için de verileri kullanabilirsiniz.You can also use the data to identify elements where the system slows down, possibly due to hotspots in the application or some other form of bottleneck. Bu yaklaşımı özenle uygularsanız, hata ayıklama ve test amacıyla uygulama içinde kullanıcı akışlarını yeniden oluşturmanız mümkün olabilir.If you implement this approach carefully, it might be possible to reconstruct users' flows through the application for debugging and testing purposes.

    Önemli

    Gerçek kullanıcıların izlenmesiyle yakalanan verilerin son derece hassas olduğunu çünkü gizli malzemeler içerebileceğini dikkate almalısınız.You should consider the data that's captured by monitoring real users to be highly sensitive because it might include confidential material. Yakalanan verileri kaydederseniz, güvenli bir şekilde saklayın.If you save captured data, store it securely. Verileri performans izleme veya hata ayıklama amacıyla kullanmak istiyorsanız, önce tüm kişisel bilgileri ayıklayıp çıkarın.If you want to use the data for performance monitoring or debugging purposes, strip out all personally identifiable information first.

  • Yapay kullanıcı izleme.Synthetic user monitoring. Bu yaklaşımda, bir kullanıcının benzetimini yaparak kendi test istemcinizi yazar ve yapılandırılabilir ama tipik bir işlem serisi gerçekleştirirsiniz.In this approach, you write your own test client that simulates a user and performs a configurable but typical series of operations. Sistemin durumunu saptamak için test istemcisinin performansını izleyebilirsiniz.You can track the performance of the test client to help determine the state of the system. Ayrıca, sistemin baskı altında nasıl yanıt verdiğini ve bu koşullarda ne tür bir izleme çıkışı oluşturulduğunu belirlemek için yapılan bir yük testi işlemi kapsamında test istemcisinin birden çok örneğini de kullanabilirsiniz.You can also use multiple instances of the test client as part of a load-testing operation to establish how the system responds under stress, and what sort of monitoring output is generated under these conditions.

    Not

    Yöntem çağrılarının ve uygulamanın diğer kritik parçalarının yürütülmesini izleyen ve zamanını belirleyen kodu ekleyerek gerçek veya yapay kullanıcı izlemesi gerçekleştirebilirsiniz.You can implement real and synthetic user monitoring by including code that traces and times the execution of method calls and other critical parts of an application.

  • Profil oluşturma.Profiling. Bu yaklaşımın birincil hedefi uygulama performansını izlemek ve geliştirmektir.This approach is primarily targeted at monitoring and improving application performance. Gerçek ve yapay kullanıcı izlemenin işlevsel düzeyinde çalışmak yerine, uygulamanın çalıştırılması sırasında alt düzey bilgileri yakalar.Rather than operating at the functional level of real and synthetic user monitoring, it captures lower-level information as the application runs. Uygulamanın yürütme durumdan düzenli aralıklarla yapılan örneklemeyi kullanarak (belirli bir anda uygulamanın hangi kod parçasını çalıştırdığını saptayarak) profil oluşturabilirsiniz.You can implement profiling by using periodic sampling of the execution state of an application (determining which piece of code that the application is running at a given point in time). Ayrıca önemli kavşaklarda (bir yöntem çağrısının başlangıcı ve bitişi gibi) koda yoklamalar ekleyen ölçümlü izlemeyi de kullanabilir ve hangi yöntemin ne zaman çağrıldığını, her çağrının ne kadar sürdüğünü kaydedebilirsiniz.You can also use instrumentation that inserts probes into the code at important junctures (such as the start and end of a method call) and records which methods were invoked, at what time, and how long each call took. Ardından bu verileri analiz ederek uygulamanın hangi parçalarının performans sorunlarına yol açabileceğini saptayabilirsiniz.You can then analyze this data to determine which parts of the application might cause performance problems.

  • Uç nokta izleme.Endpoint monitoring. Bu teknikte uygulamanın özellikle izleme için açığa çıkardığı bir veya birden çok tanılama uç noktası kullanılır.This technique uses one or more diagnostic endpoints that the application exposes specifically to enable monitoring. Uç nokta uygulama kodunda bir yol sağlar ve sistemin durumu hakkındaki bilgileri döndürebilir.An endpoint provides a pathway into the application code and can return information about the health of the system. Farklı uç noktalar işlevin farklı yönlerine odaklanabilir.Different endpoints can focus on various aspects of the functionality. Bu uç noktalara düzenli aralıklarla istekler gönderen ve yanıtları toparlayan kendi tanılama istemcinizi yazabilirsiniz.You can write your own diagnostics client that sends periodic requests to these endpoints and assimilate the responses. Daha fazla bilgi için sistem durumu uç nokta izleme düzeni.For more information, see the Health Endpoint Monitoring pattern.

En geniş kapsamı elde etmek için, bu tekniklerin bir bileşimini kullanmalısınız.For maximum coverage, you should use a combination of these techniques.

Uygulamada ölçümlü izleme yapmaInstrumenting an application

İzleme işleminin kritik parçalarından biri de ölçümlü izlemedir.Instrumentation is a critical part of the monitoring process. Sistemin performansı ve durumu hakkında anlamlı kararlar verebilmek için, önce bu kararları vermenizi sağlayacak verileri yakalamalısınız.You can make meaningful decisions about the performance and health of a system only if you first capture the data that enables you to make these decisions. Ölçümlü izleme kullanarak topladığınız bilgiler, el ile izleme (ve hata ayıklama) yapmak için uzak bir üretim sunucusunda oturum açmanıza gerek kalmadan performansı değerlendirmeniz, sorunları tanılamanız ve kararlar vermeniz için yeterli olmalıdır.The information that you gather by using instrumentation should be sufficient to enable you to assess performance, diagnose problems, and make decisions without requiring you to sign in to a remote production server to perform tracing (and debugging) manually. Ölçümlü izleme verileri normalde izleme günlüklerine yazılan ölçümler ve bilgilerden oluşur.Instrumentation data typically comprises metrics and information that's written to trace logs.

İzleme günlüğünün içeriği, uygulama tarafından yazılan metin verileri veya izleme olayı sonucu oluşturulan ikili verilerden (uygulama Windows için Olay İzleme--ETW kullanıyorsa) elde edilmiş olabilir.The contents of a trace log can be the result of textual data that's written by the application or binary data that's created as the result of a trace event (if the application is using Event Tracing for Windows--ETW). Bunlar altyapının parçalarından, örneğin bir web sunucusundan ortaya çıkan olayların kaydedildiği sistem günlüklerinden de üretilebilir.They can also be generated from system logs that record events arising from parts of the infrastructure, such as a web server. Metin biçimindeki günlük iletileri çoğunlukla insanlar tarafından okunabilecek şekilde tasarlanır, ama bunların aynı zamanda otomatik bir sistemin kolayca ayrıştırabileceği biçimde yazılmış olması gerekir.Textual log messages are often designed to be human-readable, but they should also be written in a format that enables an automated system to parse them easily.

Günlükleri kategorilere ayırmalısınız.You should also categorize logs. Tüm izleme verilerini tek bir günlüğe yazmayın; sistemin farklı işletim alanlarından gelen izleme çıkışını kaydetmek için ayrı günlükler kullanın.Don't write all trace data to a single log, but use separate logs to record the trace output from different operational aspects of the system. Bundan sonra tek bir büyük dosyayı işlemek zorunda kalmadan uygun günlükten okuyarak günlük iletilerini hızla filtreleyebilirsiniz.You can then quickly filter log messages by reading from the appropriate log rather than having to process a single lengthy file. Farklı güvenlik gereksinimleri olan bilgileri (denetim bilgileri ile hata ayıklama verileri gibi) hiçbir zaman aynı günlüğe yazmayın.Never write information that has different security requirements (such as audit information and debugging data) to the same log.

Not

Günlük, dosya sistemindeki bir dosya gibi oluşturulabilir veya blob depolamasındaki bir blob gibi başka herhangi bir biçimde tutulabilir.A log might be implemented as a file on the file system, or it might be held in some other format, such as a blob in blob storage. Ayrıca günlük bilgilerinin tablodaki satırlar gibi daha yapılandırılmış bir depolamada tutulması gerekir.Log information might also be held in more structured storage, such as rows in a table.

Ölçümler genellikle belirli bir zamanda sistemdeki bir alanın veya kaynağın ölçüsü veya sayısı olacak, bir veya birden çok ilişkili etiket veya boyut (bazen örnek olarak adlandırılır) içerecektir.Metrics will generally be a measure or count of some aspect or resource in the system at a specific time, with one or more associated tags or dimensions (sometimes called a sample). Çoğunlukla ölçümün tek bir örneği yalıtılmış olarak yararlı olmaz.A single instance of a metric is usually not useful in isolation. Zaman içinde değişen ölçümlerin yakalanması gerekir.Instead, metrics have to be captured over time. Dikkate alınması gereken en önemli konu hangi ölçümleri ne sıklıkta kaydetmeniz gerektiğidir.The key issue to consider is which metrics you should record and how frequently. Ölçümleri için veri oluşturmak büyük çoğunlukla sisteme önemli bir ek yük getirebilirken, ölçümlerin fazla seyrek yakalanması da önemli bir olaya yol açan koşulları kaçırmanıza neden olabilir.Generating data for metrics too often can impose a significant additional load on the system, whereas capturing metrics infrequently might cause you to miss the circumstances that lead to a significant event. Dikkate alınacak noktalar her ölçümde değişiklik gösterir.The considerations will vary from metric to metric. Örneğin, sunucudaki CPU kullanımı bir saniyeden diğerine ciddi ölçüde değişiklik gösterebilir, ama yüksek kullanım birkaç dakika boyunca durmadan sürüyorsa bir sorun haline gelir.For example, CPU utilization on a server might vary significantly from second to second, but high utilization becomes an issue only if it's long-lived over a number of minutes.

Verileri ilişkilendirmek için gereken bilgilerInformation for correlating data

Tek tek sistem düzeyi performans sayaçlarını kolayca izleyebilir, kaynakların ölçümlerini yakalayabilir ve çeşitli günlük dosyalarından uygulama izleme bilgilerini alabilirsiniz.You can easily monitor individual system-level performance counters, capture metrics for resources, and obtain application trace information from various log files. Ama bazı izleme biçimlerinde, çeşitli kaynaklardan alınan verileri ilişkilendirmek için izleme işlem hattında analiz ve tanılama aşaması gereklidir.But some forms of monitoring require the analysis and diagnostics stage in the monitoring pipeline to correlate the data that's retrieved from several sources. Bu veriler ham verilerde çeşitli biçimlerde olabilir ve bu farklı biçimlerin eşlenebilmesi için analiz işlemine yeterli ölçümlü izleme verisi sağlanmalıdır.This data might take several forms in the raw data, and the analysis process must be provided with sufficient instrumentation data to be able to map these different forms. Örneğin uygulama çerçevesi düzeyinde, bir görev iş parçacığı kimliğiyle tanımlanabilir.For example, at the application framework level, a task might be identified by a thread ID. Uygulamanın içinde, aynı çalışma bu görevi gerçekleştiren kullanıcının kullanıcı kimliğiyle ilişkilendirilmiş olabilir.Within an application, the same work might be associated with the user ID for the user who is performing that task.

Aynı zamanda, iş parçacıklarıyla kullanıcı istekleri arasında bire bir eşleme olma olasılığı pek yüksek değildir, çünkü zaman uyumsuz işlemler birden çok kullanıcı adına işlem gerçekleştirirken aynı iş parçacıklarını yeniden kullanabilir.Also, there's unlikely to be a 1:1 mapping between threads and user requests, because asynchronous operations might reuse the same threads to perform operations on behalf of more than one user. İşleri daha da karmaşık hale getirmek için, tek bir istek sistemdeki yürütme akışları şeklinde birden çok iş parçacığı tarafından işleniyor da olabilir.To complicate matters further, a single request might be handled by more than one thread as execution flows through the system. Mümkünse, her isteği istek bağlamının bir parçası olarak sistem geneline yayılan benzersiz bir etkinlik kimliğiyle ilişkilendirin.If possible, associate each request with a unique activity ID that's propagated through the system as part of the request context. (Etkinlik kimliklerini oluşturma ve izleme bilgilerine ekleme tekniği, izleme verilerini yakalarken kullanılan teknolojiye bağlıdır.)(The technique for generating and including activity IDs in trace information depends on the technology that's used to capture the trace data.)

Tüm izleme verilerini aynı şekilde zaman damgalı olmalıdır.All monitoring data should be timestamped in the same way. Tutarlılık sağlamak için, tüm tarihleri ve saatleri Eşgüdümlü Evrensel Saat kullanarak kaydedin.For consistency, record all dates and times by using Coordinated Universal Time. Bu, olayların sırasına daha kolay izlemenize yardımcı olacaktır.This will help you more easily trace sequences of events.

Not

Farklı saat dilimlerinde ve ağlarda çalışan bilgisayarlar eşitlenemeyebilir.Computers operating in different time zones and networks might not be synchronized. Birden çok makineye yayılmış ölçümlü izleme verilerini ilişkilendirmek için zaman damgaları tek başına kullanarak bağlı değildir.Don't depend on using timestamps alone for correlating instrumentation data that spans multiple machines.

Ölçümlü izleme verilerine dahil edilecek bilgilerInformation to include in the instrumentation data

Hangi ölçümlü izleme verilerini toplamanız gerektiğine karar verirken aşağıdaki noktaları dikkate alın:Consider the following points when you're deciding which instrumentation data you need to collect:

  • İzleme olayları tarafından yakalanan bilgilerin makine ve insan tarafından okunabilir olduğundan emin olun.Make sure that information captured by trace events is machine and human readable. Sistemler arasında günlük verilerinin otomatik olarak işlenmesini kolaylaştırmak ve günlükleri okuyan operasyon ve mühendislik personeline tutarlılık sağlamak için, bu bilgilerde iyi tanımlanmış şemalar benimseyin.Adopt well-defined schemas for this information to facilitate automated processing of log data across systems, and to provide consistency to operations and engineering staff reading the logs. Dağıtım ortamı, işlemin üzerinde çalıştırıldığı makine, işlem ayrıntıları ve çağrı yığını gibi ortam bilgilerini de ekleyin.Include environmental information, such as the deployment environment, the machine on which the process is running, the details of the process, and the call stack.

  • Profil oluşturma sisteme ciddi bir ek yük getirebileceğinden profil oluşturmayı yalnızca gerektiğinde etkinleştirin.Enable profiling only when necessary because it can impose a significant overhead on the system. Ölçümlü izleme verilerini kullanarak profil oluşturma bir olayı (örneğin bir yöntem çağrısını) her gerçekleştiğinde kaydederken, örnekleme yalnızca seçili olayları kaydeder.Profiling by using instrumentation records an event (such as a method call) every time it occurs, whereas sampling records only selected events. Seçim zamana dayalı (sonra her n saniye), veya sıklığa dayalı (sonra her n istekleri).The selection can be time-based (once every n seconds), or frequency-based (once every n requests). Olaylar çok sık gerçekleşiyorsa, ölçümlü izlemeyle profil oluşturma çok fazla yüke neden olabilir ve genel olarak performansı bu işlemin kendisi etkileyebilir.If events occur very frequently, profiling by instrumentation might cause too much of a burden and itself affect overall performance. Böyle bir durumda, örnekleme yaklaşımı tercih edilebilir.In this case, the sampling approach might be preferable. Öte yandan, olayların sıklığı düşükse örneklemeyle bu olaylar kaçırılabilir.However, if the frequency of events is low, sampling might miss them. Böyle bir durumda, ölçümlü izleme daha iyi bir yaklaşım olabilir.In this case, instrumentation might be the better approach.

  • Geliştiricinin veya yöneticinin her isteğin kaynağını saptayabilmesi için yeterli bağlam sağlayın.Provide sufficient context to enable a developer or administrator to determine the source of each request. İsteğin belirli bir örneğini tanımlayan bir tür etkinlik kimliği ekleyebilirsiniz.This might include some form of activity ID that identifies a specific instance of a request. Bu etkinliği gerçekleştirilen hesaplama çalışması ve kullanılan kaynaklarla ilişkilendirmek için kullanılabilecek bilgiler de eklenebilir.It might also include information that can be used to correlate this activity with the computational work performed and the resources used. Bu çalışmanın birden çok işlem ve makineye yayılabileceğini aklınızda bulundurun.Note that this work might cross process and machine boundaries. Ölçüm amacıyla, bağlam (doğrudan veya ilişkilendirilmiş bilgiler yoluyla dolaylı olarak) isteğin yapılmasına neden olan müşteriye de bir başvuru içermelidir.For metering, the context should also include (either directly or indirectly via other correlated information) a reference to the customer who caused the request to be made. Bu bağlam, izleme verilerinin yakalandığı sırada uygulamanın durumu hakkında değerli bilgiler sağlar.This context provides valuable information about the application state at the time that the monitoring data was captured.

  • Tüm istekleri ve bu isteklerin yapıldığı konumları ve bölgeleri kaydedin.Record all requests, and the locations or regions from which these requests are made. Bu bilgiler konuma özgü etkin noktalar olup olmadığını saptamaya yardımcı olabilir.This information can assist in determining whether there are any location-specific hotspots. Bu bilgiler uygulamanın veya onun kullandığı verilerin yeniden bölümlenip bölümlenmeyeceğini saptama açısından da yararlı olabilir.This information can also be useful in determining whether to repartition an application or the data that it uses.

  • Özel durumların ayrıntılarını dikkatle kaydedin ve yakalayın.Record and capture the details of exceptions carefully. Özel durumların kötü işlenmesinin sonucu olarak sıklıkla kritik hata ayıklama bilgileri kaybolur.Often, critical debug information is lost as a result of poor exception handling. Uygulamanın oluşturduğu özel durumların tüm ayrıntılarını, tüm iç özel durumlar ve diğer bağlam bilgileriyle birlikte yakalayın.Capture the full details of exceptions that the application throws, including any inner exceptions and other context information. Mümkünse çağrı yığınını da ekleyin.Include the call stack if possible.

  • Uygulamanızın farklı öğelerinin yakaladığı verilerde tutarlılığı koruyun, çünkü olayları incelerken ve bunları kullanıcı istekleriyle ilişkilendirirken yararlı olabilir.Be consistent in the data that the different elements of your application capture, because this can assist in analyzing events and correlating them with user requests. Sistemin farklı parçalarını oluştururken geliştiricilerin aynı yaklaşımı benimsemesine bağımlı kalmak yerine, bilgi toplamak için kapsamlı ve yapılandırılabilir bir günlük paketi kullanmayı göz önünde bulundurun.Consider using a comprehensive and configurable logging package to gather information, rather than depending on developers to adopt the same approach as they implement different parts of the system. Gerçekleştirilen G/Ç hacmi, ağ kullanımı, istek sayısı, bellek kullanımı ve CPU kullanımı gibi ana performans sayaçlarından veri toplayın.Gather data from key performance counters, such as the volume of I/O being performed, network utilization, number of requests, memory use, and CPU utilization. Bazı altyapı hizmetleri veritabanına yönelik bağlantıların sayısı, işlemlerin gerçekleştirilme hızı ve başarılı veya başarısız olan işlem sayısı gibi kendi özel performans sayaçlarını sağlayabilir.Some infrastructure services might provide their own specific performance counters, such as the number of connections to a database, the rate at which transactions are being performed, and the number of transactions that succeed or fail. Uygulamalar da kendi özel performans sayaçlarını tanımlayabilir.Applications might also define their own specific performance counters.

  • Veritabanı sistemleri, web hizmetleri veya altyapının parçası olan diğer sistem düzeyi hizmetler gibi dış hizmetlere yapılan tüm çağrıları günlüğe kaydedin.Log all calls made to external services, such as database systems, web services, or other system-level services that are part of the infrastructure. Her çağrıyı gerçekleştirmenin ne kadar sürdüğü ve çağrının başarısı veya başarısızlığı hakkındaki bilgileri kaydedin.Record information about the time taken to perform each call, and the success or failure of the call. Mümkünse, oluşan geçici hatalar için tüm yeniden deneme girişimleri ve başarısızlıklar hakkındaki bilgileri yakalayın.If possible, capture information about all retry attempts and failures for any transient errors that occur.

Telemetri sistemleriyle uyumluluğu sağlamaEnsuring compatibility with telemetry systems

Birçok durumda, ölçümlü izlemenin ürettiği bilgiler bir dizi olay olarak oluşturulur, sonra da işleme ve analiz için ayrı bir telemetri sistemine geçirilir.In many cases, the information that instrumentation produces is generated as a series of events and passed to a separate telemetry system for processing and analysis. Normalde telemetri sistemi belirli herhangi bir uygulama veya teknolojiden bağımsızdır ama bilgilerin çoğunlukla bir şema tarafından tanımlanan belirli bir biçime uymasını bekler.A telemetry system is typically independent of any specific application or technology, but it expects information to follow a specific format that's usually defined by a schema. Şema etkili bir şekilde, telemetri sisteminin alabileceği veri alanlarıyla türlerini tanımlayan bir anlaşma belirtir.The schema effectively specifies a contract that defines the data fields and types that the telemetry system can ingest. Bir dizi platform ve cihazdan veri gelmesine izin vermek için şema genelleştirilmelidir.The schema should be generalized to allow for data arriving from a range of platforms and devices.

Yaygın bir şema tüm ölçümlü izleme olaylarında ortak olan olay adı, olay saati, gönderenin IP adresi ve diğer olaylarla ilişkilendirmek için gereken ayrıntılar (örneğin kullanıcı kimliği, cihaz kimliği ve uygulama kimliği) gibi alanları içermelidir.A common schema should include fields that are common to all instrumentation events, such as the event name, the event time, the IP address of the sender, and the details that are required for correlating with other events (such as a user ID, a device ID, and an application ID). Çok sayıda cihazın olayları oluşturabileceğini, dolayısıyla şemanın cihaz türüne bağımlı olmaması gerektiğini unutmayın.Remember that any number of devices might raise events, so the schema should not depend on the device type. Buna ek olarak çeşitli cihazlar aynı uygulama için olay oluşturabilir; uygulama dolaşımı veya başka bir biçimde cihazlar arası dağıtımı destekliyor olabilir.Additionally, various devices might raise events for the same application; the application might support roaming or some other form of cross-device distribution.

Şema ayrıca farklı uygulamalar arasında yaygın olan belirli bir senaryoya uygun etki alanına ilişkin alanlar da içerebilir.The schema might also include domain fields that are relevant to a particular scenario that's common across different applications. Bunlar özel durumlar, uygulama başlangıç ve bitiş olayları ve web hizmeti API çağrılarının başarısı ve/veya başarısızlığı hakkındaki bilgiler olabilir.This might be information about exceptions, application start and end events, and success and/or failure of web service API calls. Etki alanının aynı alan kümesini kullanan tüm uygulamalar aynı olay kümesini yaymalı, böylelikle ortak bir rapor ve analiz kümesinin oluşturulmasına olanak tanımalıdır.All applications that use the same set of domain fields should emit the same set of events, enabling a set of common reports and analytics to be built.

Son olarak, şema uygulamaya özgü olayların ayrıntılarını yakalamak için özel alanlar içerebilir.Finally, a schema might contain custom fields for capturing the details of application-specific events.

Uygulamalarda ölçümlü izleme için en iyi yöntemlerBest practices for instrumenting applications

Aşağıdaki listede, bulutta çalıştırılan dağıtılmış bir uygulamada ölçümlü izleme için en iyi yöntemler özetlenmiştir.The following list summarizes best practices for instrumenting a distributed application running in the cloud.

  • Günlüklerin kolay okunur ve kolay ayrıştırılır olmasını sağlayın.Make logs easy to read and easy to parse. Mümkün olduğunca yapılandırılmış günlük kullanın.Use structured logging where possible. Günlük iletilerinin kısa ve açıklayıcı olmasına dikkat edin.Be concise and descriptive in log messages.

  • Tüm günlüklerde, günlük kayıtları yazılırken kaynağı tanımlayın, bağlam ve zamanlama bilgilerini sağlayın.In all logs, identify the source and provide context and timing information as each log record is written.

  • İçin tüm zaman damgaları aynı zaman dilimini ve biçimini kullanın.Use the same time zone and format for all timestamps. Bu, farklı coğrafi bölgelerde çalıştırılan donanım ve hizmetlere yayılmış işlemlerin olaylarını ilişkilendirmeye yardımcı olur.This will help to correlate events for operations that span hardware and services running in different geographic regions.

  • Günlükleri kategorilere ayırın ve iletileri uygun günlük dosyasına yazın.Categorize logs and write messages to the appropriate log file.

  • Sistem hakkındaki hassas bilgileri veya kullanıcılar hakkındaki kişisel bilgileri açıklamayın.Do not disclose sensitive information about the system or personal information about users. Günlüğe kaydedilmeden önce bu bilgileri temizleyin ama ilgili ayrıntıların korunduğundan emin olun.Scrub this information before it's logged, but ensure that the relevant details are retained. Örneğin, tüm veritabanı bağlantı dizelerinden kimlik ve parolayı kaldırın ama analistin sistemin doğru veritabanına eriştiğini belirleyebilmesi için bağlantı dizesindeki kalan bilgileri günlüğe yazın.For example, remove the ID and password from any database connection strings, but write the remaining information to the log so that an analyst can determine that the system is accessing the correct database. Tüm kritik özel durumları günlüğe kaydedin ama yöneticinin daha alt düzeylerdeki özel durumlar ve uyarılar için günlüğü etkinleştirmesine ve devre dışı bırakmasına olanak tanıyın.Log all critical exceptions, but enable the administrator to turn logging on and off for lower levels of exceptions and warnings. Ayrıca, tüm yeniden deneme mantığı bilgilerini yakalayın ve günlüğe kaydedin.Also, capture and log all retry logic information. Bu veriler sistemin geçici durumunu izlemek için yararlı olabilir.This data can be useful in monitoring the transient health of the system.

  • Dış veri hizmetlerine veya veritabanlarına yönelik istekler gibi işlem çağrılarını izleyin.Trace out of process calls, such as requests to external web services or databases.

  • Aynı günlük dosyasında günlük iletilerini diğer güvenlik gereksinimleriyle karıştırmayın.Don't mix log messages with different security requirements in the same log file. Örneğin, hata ayıklama ve denetim bilgilerini aynı günlüğe yazmayın.For example, don't write debug and audit information to the same log.

  • Denetleme olayları haricinde, tüm günlük çağrılarının işle ilgili işlemlerin ilerlemesini engellemeyen, kendi kendine çalışan işlemler olduğundan emin olun.With the exception of auditing events, make sure that all logging calls are fire-and-forget operations that do not block the progress of business operations. Denetleme olayları özel durumlardır çünkü bunlar iş açısından kritiktir ve işle ilgili işlemlerin temel bir parçası olarak sınıflandırılabilir.Auditing events are exceptional because they are critical to the business and can be classified as a fundamental part of business operations.

  • Günlüğün genişletilebilir olduğundan ve doğrudan somut bir hedefe hiçbir bağımlılığı olmadığından emin olun.Make sure that logging is extensible and does not have any direct dependencies on a concrete target. Örneğin, bilgileri System.Diagnostics.Trace kullanarak yazmak yerine, günlük yöntemlerini gösteren ve uygun herhangi bir yolla gerçekleştirilebilen soyut bir arabirim (ILogger gibi) tanımlayın.For example, rather than writing information by using System.Diagnostics.Trace, define an abstract interface (such as ILogger) that exposes logging methods and that can be implemented through any appropriate means.

  • Tüm günlüğün hataya dayanıklı olduğundan ve hiçbir zaman basamaklı hataları tetiklemeyeceğinden emin olun.Make sure that all logging is fail-safe and never triggers any cascading errors. Günlük hiçbir özel durum oluşturmamalıdır.Logging must not throw any exceptions.

  • Ölçümlü izlemeyi sürekli yinelenen bir işlem olarak ele alın ve günlükleri yalnızca bir sorun olduğunda değil düzenli aralıklarla gözden geçirin.Treat instrumentation as an ongoing iterative process and review logs regularly, not just when there is a problem.

Verileri toplama ve depolamaCollecting and storing data

İzleme işleminin toplama aşaması ölçümlü izlemenin oluşturduğu bilgileri almak, bu verileri analiz/tanılama aşamasında daha kolay kullanılabilecek şekilde biçimlendirmek ve dönüştürülen verileri güvenilir bir depolama alanına kaydetmekle ilgilidir.The collection stage of the monitoring process is concerned with retrieving the information that instrumentation generates, formatting this data to make it easier for the analysis/diagnosis stage to consume, and saving the transformed data in reliable storage. Dağıtılmış bir sistemin farklı parçalarından topladığınız ölçümlü izleme verileri çeşitli konumlarda ve çeşitli biçimlerde tutulabilir.The instrumentation data that you gather from different parts of a distributed system can be held in a variety of locations and with varying formats. Örneğin, uygulama kodunuz izleme günlüğü dosyaları ve uygulama olay günlüğü verileri oluşturabilirken, uygulamanızın kullandığı altyapının önemli yönlerini izleyen performans sayaçları başka teknolojiler aracılığıyla yakalanabilir.For example, your application code might generate trace log files and generate application event log data, whereas performance counters that monitor key aspects of the infrastructure that your application uses can be captured through other technologies. Uygulamanızın kullandığı tüm üçüncü taraf bileşenleri ve hizmetleri ayrı izleme dosyaları, blob depolama, hatta özel bir veri deposu kullanıp ölçümlü izleme bilgilerini farklı biçimlerde sağlıyor olabilir.Any third-party components and services that your application uses might provide instrumentation information in different formats, by using separate trace files, blob storage, or even a custom data store.

Veri toplama işlemi çoğunlukla ölçülü izleme verilerini oluşturan uygulamadan ayrı, otonom olarak çalışabilen bir toplama hizmeti tarafından gerçekleştirilir.Data collection is often performed through a collection service that can run autonomously from the application that generates the instrumentation data. Şekil 2'de bu mimarinin bir örneği gösterilmektedir ve ölçümlü izleme verilerini toplama alt sistemi vurgulanmıştır.Figure 2 illustrates an example of this architecture, highlighting the instrumentation data-collection subsystem.

Ölçümlü izleme verilerini toplama örneği

Şekil 2. Ölçümlü izleme verilerini toplama.Figure 2. Collecting instrumentation data.

Bunun basitleştirilmiş bir görünüm olduğuna dikkat edin.Note that this is a simplified view. Toplama hizmetinin tek bir işlem olması gerekmez ve aşağıdaki bölümlerde açıklandığı gibi farklı makinelerde çalıştırılan birçok bileşen parçasından oluşuyor olabilir.The collection service is not necessarily a single process and might comprise many constituent parts running on different machines, as described in the following sections. Ayrıca, bazı telemetri verilerinin hızla analiz edilmesi gerekiyorsa (bu belgenin devamındaki Hızlı, orta gecikmeli ve gecikmeli analizi destekleme bölümünde açıklanan hızlı analiz), toplama hizmetinin dışında çalışan yerel bileşenler analiz görevlerini hemen gerçekleştirebilir.Additionally, if the analysis of some telemetry data must be performed quickly (hot analysis, as described in the section Supporting hot, warm, and cold analysis later in this document), local components that operate outside the collection service might perform the analysis tasks immediately. Şekil 2'de seçili olaylar için bu durum gösterilmiştir.Figure 2 depicts this situation for selected events. Analiz işleminden sonra, sonuçlar doğrudan görselleştirme ve uyarı alt sistemine gönderilebilir.After analytical processing, the results can be sent directly to the visualization and alerting subsystem. Orta gecikmeli veya gecikmeli analize bağlı olan veriler, işlenmeyi beklerken depolama alanında tutulur.Data that's subjected to warm or cold analysis is held in storage while it awaits processing.

Azure uygulamaları ve hizmetlerinde, Azure Tanılama verileri yakalamayı mümkün kılan bir çözüm sağlar.For Azure applications and services, Azure Diagnostics provides one possible solution for capturing data. Azure Tanılama her işlem düğümü için verileri aşağıdaki kaynaklardan toplar, bir araya getirir ve ardından Azure Depolama'ya yükler:Azure Diagnostics gathers data from the following sources for each compute node, aggregates it, and then uploads it to Azure Storage:

  • IIS günlükleriIIS logs
  • IIS Başarısız İstek günlükleriIIS Failed Request logs
  • Windows olay günlükleriWindows event logs
  • Performans sayaçlarıPerformance counters
  • Kilitlenme dökümleriCrash dumps
  • Azure Tanılama altyapısı günlükleriAzure Diagnostics infrastructure logs
  • Özel hata günlükleriCustom error logs
  • .NET EventSource.NET EventSource
  • Bildirim tabanlı ETWManifest-based ETW

Daha fazla bilgi için bkz Azure: Telemetri temel bilgileri ve sorun giderme.For more information, see the article Azure: Telemetry Basics and Troubleshooting.

Ölçümlü izleme verilerini toplama stratejileriStrategies for collecting instrumentation data

Bulutun esnek yapısını dikkate alarak ve sistemdeki her düğümden telemetri verilerini el ile alma gereksiniminden kaçınmak için, verilerin merkezi bir konuma aktarılması ve birleştirilmesi işlemini ayarlamalısınız.Considering the elastic nature of the cloud, and to avoid the necessity of manually retrieving telemetry data from every node in the system, you should arrange for the data to be transferred to a central location and consolidated. Birden çok veri merkezine yayılan bir sistemde, önce verileri bölge temelinde toplamak, birleştirmek ve depolamak, sonra da bölgesel verileri tek bir merkezi sistemde bir araya getirmek yararlı olabilir.In a system that spans multiple datacenters, it might be useful to first collect, consolidate, and store data on a region-by-region basis, and then aggregate the regional data into a single central system.

Bant genişliği kullanımını iyileştirmek için, daha az acil verileri öbekler halinde, toplu olarak aktarmayı seçebilirsiniz.To optimize the use of bandwidth, you can elect to transfer less urgent data in chunks, as batches. Öte yandan veriler, özellikle de zamana duyarlı bilgiler içeriyorsa, süresiz olarak geciktirilmemelidir.However, the data must not be delayed indefinitely, especially if it contains time-sensitive information.

Ölçümlü izleme verilerini çekme ve göndermePulling and pushing instrumentation data

Ölçümlü izleme verilerini toplama alt sistemi, uygulamanın her örneği için ölçümlü izleme verilerini çeşitli günlüklerden ve başka kaynaklardan etkin olarak alabilir (çekme modeli).The instrumentation data-collection subsystem can actively retrieve instrumentation data from the various logs and other sources for each instance of the application (the pull model). Öte yandan, uygulamanın örneklerini oluşturan bileşenlerden verilerin gönderilmesini bekleyen pasif bir alıcı gibi de davranabilir (gönderme modeli).Or, it can act as a passive receiver that waits for the data to be sent from the components that constitute each instance of the application (the push model).

Çekme modelini uygulamaya yönelik bir yaklaşım, uygulamanın her örneğiyle birlikte yerel olarak çalıştırılan izleme aracılarını kullanmaktır.One approach to implementing the pull model is to use monitoring agents that run locally with each instance of the application. İzleme aracısı yerel düğümde toplanan telemetri verilerini düzenli aralıklarla alan (çeken) ayrı bir işlemdir ve bu bilgileri doğrudan uygulamanın tüm örnekleri tarafından paylaşılan merkezi depolamaya yazar.A monitoring agent is a separate process that periodically retrieves (pulls) telemetry data collected at the local node and writes this information directly to centralized storage that all instances of the application share. Azure Tanılama'nın uyguladığı mekanizma budur.This is the mechanism that Azure Diagnostics implements. Azure web veya çalışan rolünün her örneği, yerel olarak depolanmış tanılama ve diğer izleme bilgilerini yakalayacak şekilde yapılandırılabilir.Each instance of an Azure web or worker role can be configured to capture diagnostic and other trace information that's stored locally. Örneklerin yanı sıra çalıştırılan izleme aracısı, belirtilen verileri Azure Depolama'ya kopyalar.The monitoring agent that runs alongside each instance copies the specified data to Azure Storage. Azure Cloud Services'te ve Sanal Makineler'de Tanılamayı Etkinleştirme makalesinde bu işlemle ilgili daha fazla ayrıntı sağlanmıştır.The article Enabling Diagnostics in Azure Cloud Services and Virtual Machines provides more details on this process. IIS günlükleri, kilitlenme bilgi dökümleri ve özel hata iletileri gibi bazı öğeler blob depolamaya yazılır.Some elements, such as IIS logs, crash dumps, and custom error logs, are written to blob storage. Windows olay günlüğü, ETW olayları ve performans sayaçlarından gelen veriler tablo depolamaya kaydedilir.Data from the Windows event log, ETW events, and performance counters is recorded in table storage. Şekil 3'te bu mekanizma gösterilir.Figure 3 illustrates this mechanism.

Bilgileri çekmek ve paylaşılan depolamaya yazmak için izleme aracısı kullanımının çizimi

Şekil 3. Bilgileri çekmek ve paylaşılan depolamaya yazmak için izleme Aracısı'nı kullanarak.Figure 3. Using a monitoring agent to pull information and write to shared storage.

Not

İzleme aracısının kullanımı, veri kaynağından doğal olarak çekilen ölçümlü izleme verilerini yakalamaya çok uygundur.Using a monitoring agent is ideally suited to capturing instrumentation data that's naturally pulled from a data source. SQL Server Dinamik Yönetim Görünümleri'nden alınan bilgiler veya Azure Service Bus kuyruğunun uzunluğu buna örnek verilebilir.An example is information from SQL Server Dynamic Management Views or the length of an Azure Service Bus queue.

Aynı konumdaki sınırlı sayıda düğüm üzerinde çalıştırılan küçük ölçekli bir uygulamanın telemetri verilerini depolamak için az önce açıklanan yaklaşımı kullanmak mantıklı olur.It's feasible to use the approach just described to store telemetry data for a small-scale application running on a limited number of nodes in a single location. Öte yandan karmaşık, üst düzeyde ölçeklenebilir, global bir bulut uygulaması yüzlerce web ve çalışan rolünden, veritabanı parçalarından ve diğer hizmetlerden muazzam miktarlarda veri oluşturabilir.However, a complex, highly scalable, global cloud application might generate huge volumes of data from hundreds of web and worker roles, database shards, and other services. Bu veri akımı tek, merkezi bir konumla kullanılabilen G/Ç bant genişliğini kolayca baskı altına alabilir.This flood of data can easily overwhelm the I/O bandwidth available with a single, central location. Bu nedenle, sistem genişledikçe performans sorunu yaratmasını önlemek için telemetri çözümünüzün ölçeklenebilir olması gerekir.Therefore, your telemetry solution must be scalable to prevent it from acting as a bottleneck as the system expands. İdeal durumda, sistemin bir bölümü başarısız olduğunda önemli izleme bilgilerini (denetim veya faturalama verileri gibi) kaybetme riskini azaltmak için çözümünüz belirli bir düzeyde yedekli çalışma özelliğine sahip olmalıdır.Ideally, your solution should incorporate a degree of redundancy to reduce the risks of losing important monitoring information (such as auditing or billing data) if part of the system fails.

Bu sorunlara çözüm getirmek için, Şekil 4'te gösterildiği gibi kuyruğa almayı uygulayabilirsiniz.To address these issues, you can implement queuing, as shown in Figure 4. Bu mimaride, yerel izleme aracısı (uygun şekilde yapılandırılabiliyorsa) veya özel veri toplama hizmeti (yapılandırılamıyorsa) verileri kuyruğa gönderir.In this architecture, the local monitoring agent (if it can be configured appropriately) or custom data-collection service (if not) posts data to a queue. Zaman uyumsuz çalıştırılan ayrı bir işlem (Şekil 4'teki depolamaya yazma hizmeti) bu kuyruktaki verileri alır ve paylaşılan depolamaya yazar.A separate process running asynchronously (the storage writing service in Figure 4) takes the data in this queue and writes it to shared storage. İleti kuyruğu bu senaryoya uygundur çünkü kuyruğa alınan verilerin gönderildikten sonra kaybolmamasını sağlamaya yardımcı olan "en az bir kez" semantiği sağlar.A message queue is suitable for this scenario because it provides "at least once" semantics that help ensure that queued data will not be lost after it's posted. Depolama yazma hizmetini ayrı bir çalışan rolü kullanarak gerçekleştirebilirsiniz.You can implement the storage writing service by using a separate worker role.

Ölçümlü izleme verilerini arabelleğe almak için kuyruk kullanmanın çizimi

Şekil 4. Ölçümlü izleme verilerini arabelleğe için bir kuyruk kullanma.Figure 4. Using a queue to buffer instrumentation data.

Yerel veri toplama hizmeti verileri aldıktan hemen sonra kuyruğa ekleyebilir.The local data-collection service can add data to a queue immediately after it's received. Kuyruk bir arabellek işlevi görür ve depolamaya yazma hizmeti verileri kendi belirlediği bir hızda alabilir ve yazabilir.The queue acts as a buffer, and the storage writing service can retrieve and write the data at its own pace. Varsayılan olarak kuyruk, ilk giren ilk çıkar mantığında çalışır.By default, a queue operates on a first-in, first-out basis. Ama iletiler daha hızlı işlenmesi gereken veriler içeriyorsa, kuyrukta hızlandırmak için bu iletilerin öncelikli olmasını sağlayabilirsiniz.But you can prioritize messages to accelerate them through the queue if they contain data that must be handled more quickly. Daha fazla bilgi için öncelikli kuyruk düzeni.For more information, see the Priority Queue pattern. Alternatif olarak, gereken analitik işleme biçimine bağlı olarak verileri farklı hedeflere yönlendirmek için farklı kanallar (Service Bus konuları gibi) kullanabilirsiniz.Alternatively, you can use different channels (such as Service Bus topics) to direct data to different destinations depending on the form of analytical processing that's required.

Ölçeklenebilirlik açısından, depolamaya yazma hizmetinin birden çok örneğini çalıştırabilirsiniz.For scalability, you can run multiple instances of the storage writing service. Çok fazla miktarda olay varsa, verileri işleme ve depolama amacıyla farklı işlem kaynaklarına göndermek için bir olay hub'ı kullanabilirsiniz.If there is a high volume of events, you can use an event hub to dispatch the data to different compute resources for processing and storage.

Ölçümlü izleme verilerini birleştirmeConsolidating instrumentation data

Veri toplama hizmetinin uygulamanın tek bir örneğinden aldığı ölçümlü izleme verileri, o örneğin sistem durumu ve performansının yerelleştirilmiş bir görünümünü verir.The instrumentation data that the data-collection service retrieves from a single instance of an application gives a localized view of the health and performance of that instance. Sistemin genel durumunu değerlendirmek için verilerin bazı yönlerini yerel görünümlerle birleştirmek gerekir.To assess the overall health of the system, it's necessary to consolidate some aspects of the data in the local views. Bunu veriler depolandıktan sonra yapabilirsiniz, ama bazı durumlarda veriler toplanırken de bunu başarabilirsiniz.You can perform this after the data has been stored, but in some cases, you can also achieve it as the data is collected. Ölçümlü izleme verileri doğrudan paylaşılan depolamaya yazılmak yerine, verileri birleştiren, filtreleme ve temizleme işlevi gibi çalışan ayrı bir veri birleştirme hizmetine de geçirilebilir.Rather than being written directly to shared storage, the instrumentation data can pass through a separate data consolidation service that combines data and acts as a filter and cleanup process. Örneğin, etkinlik kimliği gibi aynı ilişkilendirme bilgilerini içeren ölçümlü izleme verileri kaynaştırılabilir.For example, instrumentation data that includes the same correlation information such as an activity ID can be amalgamated. (Kullanıcı bir düğümde işle ilgili bir işlemi gerçekleştirmeye başlayabilir ve düğümde hata olması durumunda veya yük dengelemenin yapılandırmasına bağlı olarak başka bir düğüme aktarılabilir.) Bu işlem yinelenen verileri de algılayabilir ve kaldırabilir (telemetri hizmeti ölçümlü izleme verilerini depolamaya göndermek için ileti kuyruklarını kullanıyorsa her zaman verilerin yinelenme olasılığı vardır).(It's possible that a user starts performing a business operation on one node and then gets transferred to another node in the event of node failure, or depending on how load balancing is configured.) This process can also detect and remove any duplicated data (always a possibility if the telemetry service uses message queues to push instrumentation data out to storage). Şekil 5'te bu yapının bir örneği gösterilir.Figure 5 illustrates an example of this structure.

Ölçümlü izleme verilerini birleştirmek için bir hizmet kullanma örneği

Şekil 5. Birleştirme ve ölçümlü izleme verilerini temizlemek için ayrı bir hizmet kullanma.Figure 5. Using a separate service to consolidate and clean up instrumentation data.

Ölçümlü izleme verilerini depolamaStoring instrumentation data

Önceki açıklamalarda ölçümlü izleme verilerinin depolanma yönteminin biraz basitleştirilmiş bir görünümü gösterilmişti.The previous discussions have depicted a rather simplistic view of the way in which instrumentation data is stored. Gerçekte, farklı türlerdeki verileri depolarken her türün büyük olasılıkla kullanılacağı yönteme en uygun teknolojileri kullanmak anlamlı olabilir.In reality, it can make sense to store the different types of information by using technologies that are most appropriate to the way in which each type is likely to be used.

Örneğin, Azure blob ve tablo depolamanın erişim yönteminde bazı benzerlikler bulunur.For example, Azure blob and table storage have some similarities in the way in which they're accessed. Ancak bunları kullanarak gerçekleştirebileceğiniz işlemlerde sınırlamalar vardır ve bunlarda tutulan verilerin ayrıntı düzeyi oldukça farklıdır.But they have limitations in the operations that you can perform by using them, and the granularity of the data that they hold is quite different. 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.If you need to perform more analytical operations or require full-text search capabilities on the data, it might be more appropriate to use data storage that provides capabilities that are optimized for specific types of queries and data access. Örneğin:For example:

  • Performans sayacı verileri geçici analize olanak tanımak için bir SQL veritabanında depolanabilir.Performance counter data can be stored in a SQL database to enable ad hoc analysis.
  • İzleme günlüklerini Azure Cosmos DB'de depolamak daha iyi olabilir.Trace logs might be better stored in Azure Cosmos DB.
  • Güvenlik bilgileri HDFS'ye yazılabilir.Security information can be written to HDFS.
  • Tam metin araması gerektiren bilgiler Elasticsearch aracılığıyla depolanabilir (bu, zengin dizin oluşturma kullanarak da aramaları hızlandırabilir).Information that requires full-text search can be stored through Elasticsearch (which can also speed searches by using rich indexing).

Şekil 6'da gösterildiği gibi verileri düzenli aralıklarla paylaşılan depolamadan alan, amacına uygun olarak bölümleyen ve filtreleyen, sonra da uygun veri depoları kümesine yazan ek bir hizmet uygulayabilirsiniz.You can implement an additional service that periodically retrieves the data from shared storage, partitions and filters the data according to its purpose, and then writes it to an appropriate set of data stores as shown in Figure 6. 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.An alternative approach is to include this functionality in the consolidation and cleanup process and write the data directly to these stores as it's retrieved rather than saving it in an intermediate shared storage area. Her yaklaşımın kendi avantajları ve dezavantajları vardır.Each approach has its advantages and disadvantages. Ayrı bir bölümleme hizmeti uygulamak birleştirme ve temizleme hizmetinin yükünü azaltır, gerekirse bölümlenmiş verilerin en azından bir bölümünün yeniden oluşturulmasına olanak tanır (paylaşılan depolamada ne kadar veri tutulduğuna bağlı olarak).Implementing a separate partitioning service lessens the load on the consolidation and cleanup service, and it enables at least some of the partitioned data to be regenerated if necessary (depending on how much data is retained in shared storage). Öte yandan bu, ek kaynaklar kullanır.However, it consumes additional resources. 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.Also, there might be a delay between the receipt of instrumentation data from each application instance and the conversion of this data into actionable information.

Verileri bölümleme ve depolama

Şekil 6. Analitik veriler ve depolama gereksinimlerini bölümleme.Figure 6. Partitioning data according to analytical and storage requirements.

Aynı ölçümlü izleme verileri birden çok amaç için gerekli olabilir.The same instrumentation data might be required for more than one purpose. Ö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.For example, performance counters can be used to provide a historical view of system performance over time. Bu bilgiler başka kullanım verileriyle birleştirilerek müşteri faturalama bilgilerini oluşturabilir.This information might be combined with other usage data to generate customer billing information. Böyle durumlarda, aynı veriler faturalama bilgilerinin barındırıldığı uzun vadeli depo işlevi gören bir belge veritabanı ve karmaşık performans analizi yapmak için çok boyutlu bir depo gibi birden çok hedefe gönderilebilir.In these situations, the same data might be sent to more than one destination, such as a document database that can act as a long-term store for holding billing information, and a multidimensional store for handling complex performance analytics.

Ayrıca verilere ne kadar acil gerek duyulduğunu da göz önüne almalısınız.You should also consider how urgently the data is required. Uyarı vermek için bilgi sağlayan verilere hızla erişilmelidir; dolayısıyla bunlar hızlı veri depolamasında tutulmalı ve uyarı sisteminin gerçekleştirdiği sorguları iyileştirmek için dizine alınmalı veya yapılandırılmalıdır.Data that provides information for alerting must be accessed quickly, so it should be held in fast data storage and indexed or structured to optimize the queries that the alerting system performs. Bazı durumlarda, her düğümde verileri toplayan telemetri hizmetinin verileri yerel olarak biçimlendirmesi ve kaydetmesi gerekebilir; böylelikle uyarı sisteminin yerel örneği sorunları size hızla bildirebilir.In some cases, it might be necessary for the telemetry service that gathers the data on each node to format and save data locally so that a local instance of the alerting system can quickly notify you of any issues. Aynı veriler önceki diyagramlarda gösterilen depolamaya yazma hizmetine gönderilebilir ve başka amaçlarla da gerekliyse merkezi olarak depolanabilir.The same data can be dispatched to the storage writing service shown in the previous diagrams and stored centrally if it's also required for other purposes.

Daha kapsamlı bir analiz, raporlama ve geçmiş eğilimleri saptama için kullanılan bilgiler o kadar acil değildir ve veri madenciliğini ve geçici sorguları destekleyecek bir şekilde depolanabilir.Information that's used for more considered analysis, for reporting, and for spotting historical trends is less urgent and can be stored in a manner that supports data mining and ad hoc queries. Daha fazla bilgi için bu belgenin devamındaki Hızlı, orta gecikmeli ve gecikmeli analizi destekleme bölümüne bakın.For more information, see the section Supporting hot, warm, and cold analysis later in this document.

Günlük rotasyonu ve veri saklamaLog rotation and data retention

Ölçümlü izleme önemli miktarda veri oluşturabilir.Instrumentation can generate considerable volumes of data. Bu veriler ham günlük dosyaları, izleme dosyaları ve her düğümde yakalanan diğer bilgilerden başlayıp bu verilerin paylaşılan depolamada tutulan birleştirilmiş, temizlenmiş ve bölümlenmiş görümüne kadar, çeşitli yerlerde tutulabilir.This data can be held in several places, starting with the raw log files, trace files, and other information captured at each node to the consolidated, cleaned, and partitioned view of this data held in shared storage. Bazı durumlarda, veriler işlendikten ve aktarıldıktan sonra, özgün ham kaynak veriler düğümlerden kaldırılabilir.In some cases, after the data has been processed and transferred, the original raw source data can be removed from each node. Diğer durumlarda, ham bilgileri kaydetmek gerekli veya yalnızca kullanışlı olabilir.In other cases, it might be necessary or simply useful to save the raw information. Örneğin, hata ayıklama amacıyla oluşturulan verilerin ham biçimde kullanılabilir durumda bırakılması en iyi yöntem olabilir ama tüm hatalar düzeltildikten sonra bunlar hızla atılabilir.For example, data that's generated for debugging purposes might be best left available in its raw form but can then be discarded quickly after any bugs have been rectified.

Performans verileri çoğunlukla daha uzun ömürlüdür çünkü performans eğilimlerini saptama ve kapasite planlama amaçlarıyla kullanılabilir.Performance data often has a longer life so that it can be used for spotting performance trends and for capacity planning. 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.The consolidated view of this data is usually kept online for a finite period to enable fast access. Bu sürenin sonunda, bunlar arşivlenebilir veya atılabilir.After that, it can be archived or discarded. Ölçüm ve müşteri faturalandırması için toplanan verilerin süresiz olarak kaydedilmesi gerekebilir.Data gathered for metering and billing customers might need to be saved indefinitely. Bunlara ek olarak, yasal düzenleme gereksinimleri denetim ve güvenlik amacıyla toplanan bilgilerin aynı zamanda arşivlenmesini ve kaydedilmesini zorunlu tutabilir.Additionally, regulatory requirements might dictate that information collected for auditing and security purposes also needs to be archived and saved. Ayrıca bunlar hassas verilerdir ve bu verilerin üzerinde oynanmasını önlemek için şifrelenmeleri veya başka bir yolla korunmaları da gerekebilir.This data is also sensitive and might need to be encrypted or otherwise protected to prevent tampering. Kullanıcıların parolalarını veya kimlik dolandırıcılığı yapmak için kullanılabilecek diğer bilgileri hiçbir zaman kaydetmemelisiniz.You should never record users' passwords or other information that might be used to commit identity fraud. Bu tür ayrıntılar depolanmadan önce verilerden temizlenmelidir.Such details should be scrubbed from the data before it's stored.

Aşağı örneklemeDown-sampling

Uzun vadeli eğilimleri belirleyebilmeniz için geçmiş verilerini depolamak yararlıdır.It's useful to store historical data so you can spot long-term trends. Eski verilerin tamamını kaydetmek yerine, çözünürlüğünü azaltmak ve depolama maliyetlerinden tasarruf etmek için verilerin aşağı örneklemesini almak mümkün olabilir.Rather than saving old data in its entirety, it might be possible to down-sample the data to reduce its resolution and save storage costs. Örneğin, dakikalık performans göstergelerini kaydetmek yerine, bir aydan daha eski olan verileri birleştirip saatlik bir görünüm oluşturabilirsiniz.As an example, rather than saving minute-by-minute performance indicators, you can consolidate data that's more than a month old to form an hour-by-hour view.

Günlük bilgilerini toplamak ve depolamak için en iyi yöntemlerBest practices for collecting and storing logging information

Aşağıdaki listede, yakalama ve günlük kaydı bilgilerini depolamak için en iyi uygulamalar özetlenmektedir:The following list summarizes best practices for capturing and storing logging information:

  • İzleme aracısı veya veri toplama hizmeti ayrı işlemde çalışan bir hizmet olarak çalıştırılmalı ve dağıtımı kolay olmalıdır.The monitoring agent or data-collection service should run as an out-of-process service and should be simple to deploy.

  • İzleme aracısı veya veri toplama hizmetinden alınan tüm çıkış makineden, işletim sisteminden veya ağ protokolünden bağımsız bir biçime sahip olmalıdır.All output from the monitoring agent or data-collection service should be an agnostic format that's independent of the machine, operating system, or network protocol. Örneğin, bilgileri ETL/ETW yerine açıklamasını kendi içinde barındıran JSON, MessagePack veya Protobuf gibi bir biçimde gösterin.For example, emit information in a self-describing format such as JSON, MessagePack, or Protobuf rather than ETL/ETW. Standart bir biçim kullanmak, sistemin işleme için işlem hatlarını oluşturmasına olanak tanır; verileri üzerinde anlaşmaya varılmış olan biçimde okuyan, dönüştüren ve gönderen bileşenler kolayca tümleştirilebilir.Using a standard format enables the system to construct processing pipelines; components that read, transform, and send data in the agreed format can be easily integrated.

  • İzleme ve veri toplama işlemi hataya dayanıklı olmalı, hiçbir basamaklı hata koşulunu tetiklememelidir.The monitoring and data-collection process must be fail-safe and must not trigger any cascading error conditions.

  • Bilgileri veri havuzuna gönderirken geçici bir hata oluşması durumunda, izleme aracısı veya veri toplama hizmeti en önce en yeni bilgilerin gönderilmesini sağlamak üzere telemetri verilerini yeniden sıralamak için hazırlıklı olmalıdır.In the event of a transient failure in sending information to a data sink, the monitoring agent or data-collection service should be prepared to reorder telemetry data so that the newest information is sent first. (İzleme aracısı/veri toplama hizmeti daha eski verileri bırakmayı veya bunları yerel olarak depolayıp daha sonra kendi karar verdiği zaman iletip arayı kapatmayı seçebilir.)(The monitoring agent/data-collection service might elect to drop the older data, or save it locally and transmit it later to catch up, at its own discretion.)

Verileri çözümleme ve sorunları tanılamaAnalyzing data and diagnosing issues

İzleme ve tanılama işleminin önemli bir bölümü toplanan verileri analiz etmek ve sistemin genel durumunun bir resmini elde etmektir.An important part of the monitoring and diagnostics process is analyzing the gathered data to obtain a picture of the overall well-being of the system. Kendi KPI'lerinizi ve performans ölçümlerinizi tanımlamış olmalısınız ve analiz gereksinimlerinizi karşılamak için toplanan verileri nasıl yapılandırabileceğinizi anlamanız önemlidir.You should have defined your own KPIs and performance metrics, and it's important to understand how you can structure the data that has been gathered to meet your analysis requirements. Ayrıca, farklı ölçümlerde ve günlük dosyalarında yakalanan verilerin nasıl ilişkilendirileceğini anlamak da önemlidir çünkü bu bilgiler bir olay dizisini izlemekte kilit rol oynayabilir ve çıkan sorunları tanılamaya yardımcı olabilir.It's also important to understand how the data that's captured in different metrics and log files is correlated, because this information can be key to tracking a sequence of events and help diagnose problems that arise.

Ölçümlü izleme verilerini birleştirme bölümünde açıklandığı gibi, sistemin her parçasına ilişkin veriler normalde yerel olarak yakalanır ama genellikle sisteme katkıda bulunan diğer yerlerde oluşturulan verilerle birleştirilmeleri gerekir.As described in the section Consolidating instrumentation data, the data for each part of the system is typically captured locally, but it generally needs to be combined with data generated at other sites that participate in the system. Verilerin doğru birleştirildiğinden emin olmak için bu bilgiler dikkatle ilişkilendirilmelidir.This information requires careful correlation to ensure that data is combined accurately. Örneğin, bir işlemin kullanım verileri kullanıcının bağlandığı web sitesini barındıran düğüme, bu işlem kapsamında erişilen ayrı bir hizmetin çalıştırıldığı düğüme yayılabilir ve veri depolaması ayrı bir düğümde tutulabilir.For example, the usage data for an operation might span a node that hosts a website to which a user connects, a node that runs a separate service accessed as part of this operation, and data storage held on another node. İşlemle ilgili kaynak ve işleme kullanımının genel görünümünü sağlamak için bu bilgilerin birbirine bağlanması gerekir.This information needs to be tied together to provide an overall view of the resource and processing usage for the operation. Toplama ve biçimlendirme büyük olasılıkla merkezi bir düğümde ise bazı ön işleme ve verileri filtreleme, veriler yakalanır, düğüm üzerinde oluşabilir.Some preprocessing and filtering of data might occur on the node on which the data is captured, whereas aggregation and formatting are more likely to occur on a central node.

Hızlı, orta gecikmeli ve gecikmeli analizi desteklemeSupporting hot, warm, and cold analysis

Verileri görselleştirme, raporlama ve uyarı verme amacıyla analiz etmek ve yeniden biçimlendirmek, kendi kaynak kümelerini kullanan karmaşık bir işlem olabilir.Analyzing and reformatting data for visualization, reporting, and alerting purposes can be a complex process that consumes its own set of resources. Bazı izleme biçimleri zamana duyarlıdır ve etkili olması için verilerin hemen analiz edilmesi gerekir.Some forms of monitoring are time-critical and require immediate analysis of data to be effective. Bu hızlı analiz olarak bilinir.This is known as hot analysis. Uyarı vermek için gereken analizler ve güvenlik izlemesinin bazı yönleri (sistemdeki bir saldırıyı algılama gibi) buna örnek verilebilir.Examples include the analyses that are required for alerting and some aspects of security monitoring (such as detecting an attack on the system). Bu amaçlar için gereken veriler hızla sağlanabilmeli ve verimli işleme için yapılandırılabilmelidir.Data that's required for these purposes must be quickly available and structured for efficient processing. Bazı durumlarda, analiz işleminin verilerin tutulduğu tek tek düğümlere taşınması gerekebilir.In some cases, it might be necessary to move the analysis processing to the individual nodes where the data is held.

Diğer analiz biçimleri zamana o kadar duyarlı değildir ve ham veriler alındıktan sonra bazı hesaplamalar ve toplamalar yapmayı gerektirebilir.Other forms of analysis are less time-critical and might require some computation and aggregation after the raw data has been received. Bu orta gecikmeli analiz olarak adlandırılır.This is called warm analysis. Performans analizi genellikle bu kategoriye girer.Performance analysis often falls into this category. Böyle bir durumda, yalıtılmış tek bir performans olayının istatistiksel açıdan anlamlı olması pek olası değildir.In this case, an isolated, single performance event is unlikely to be statistically significant. (Ani bir değişiklik veya hata buna neden olmuş olabilir.) Bir dizi olaydan gelen veriler sistem performansının çok daha güvenilir bir resmini sağlayacaktır.(It might be caused by a sudden spike or glitch.) The data from a series of events should provide a more reliable picture of system performance.

Orta gecikmeli analiz sistem durumu sorunlarını tanılamaya da yardımcı olabilir.Warm analysis can also be used to help diagnose health issues. Sistem durumu olayları normalde hızlı analiz aracılığıyla işlenir ve hemen uyarı oluşturabilir.A health event is typically processed through hot analysis and can raise an alert immediately. Operatörün orta gecikmeli kanaldan gelen verileri inceleyerek sistem durumu olayının nedenlerini ayrıntılı olarak görebilmesi gerekir.An operator should be able to drill into the reasons for the health event by examining the data from the warm path. Bu veriler, sistem durumu olayına neden olan soruna hangi olayların yol açtığı hakkında bilgiler içerecektir.This data should contain information about the events leading up to the issue that caused the health event.

Bazı izleme türleri daha uzun vadeli veriler oluşturur.Some types of monitoring generate more long-term data. Bu analiz daha ileri bir tarihte, olasılıkla önceden tanımlanmış bir zamanlamaya göre gerçekleştirilebilir.This analysis can be performed at a later date, possibly according to a predefined schedule. Bazı durumlarda analizde, belirli bir süre boyunca yakalanmış büyük miktarlardaki veriler üzerinde karmaşık filtreleme işlemleri yapılması gerekebilir.In some cases, the analysis might need to perform complex filtering of large volumes of data captured over a period of time. Bu gecikmeli analiz olarak adlandırılır.This is called cold analysis. En önemli gereksinim, verilerin yakalandıktan sonra güvenli bir şekilde depolanmasıdır.The key requirement is that the data is stored safely after it has been captured. Örneğin, kullanım izleme ve denetim için zaman içinde düzenli aralıklarla sistemin durumunun doğru bir resmini elde etmek gerekir, ama bu durum bilgilerinin toplandıktan hemen sonra işlenmek için kullanılabilir olması şart değildir.For example, usage monitoring and auditing require an accurate picture of the state of the system at regular points in time, but this state information does not have to be available for processing immediately after it has been gathered.

Operatör tahmine dayalı sistem durumu analizine veri sağlamak için de gecikmeli analizi kullanabilir.An operator can also use cold analysis to provide the data for predictive health analysis. Operatör belirli bir süre boyunca geçmiş bilgilerini toplayabilir ve bunları geçerli sistem durumu verileriyle (hızlı kanaldan alınmış veriler) birlikte kullanarak kısa süre içinde sistem durumu sorunlarına neden olabilecek eğilimleri saptayabilir.The operator can gather historical information over a specified period and use it in conjunction with the current health data (retrieved from the hot path) to spot trends that might soon cause health issues. Böyle durumlarda, düzeltici eylem yapılabilmesi için uyarı oluşturmak gerekebilir.In these cases, it might be necessary to raise an alert so that corrective action can be taken.

Verileri ilişkilendirmeCorrelating data

Ölçümlü izlemede yakalanan veriler sistem durumunun anlık bir görüntüsünü sağlayabilir ama analizin amacı bu verileri işlenebilir duruma getirmektir.The data that instrumentation captures can provide a snapshot of the system state, but the purpose of analysis is to make this data actionable. Örneğin:For example:

  • Belirli bir zamanda sistem düzeyinde yoğun G/Ç yüküne ne neden oldu?What has caused an intense I/O loading at the system level at a specific time?
  • Bu çok fazla sayıda veritabanı işleminin sonucu mu?Is it the result of a large number of database operations?
  • Bu durum veritabanı yanıt sürelerine, saniyede yapılan işlem sayısına ve aynı kavşakta uygulamanın yanıt sürelerine yansıdı mı?Is this reflected in the database response times, the number of transactions per second, and application response times at the same juncture?

Öyleyse, yükü azaltabilecek düzeltici eylem, verileri daha fazla sunucuya parçalamak olabilir.If so, one remedial action that might reduce the load might be to shard the data over more servers. Buna ek olarak, sistemin herhangi bir düzeyindeki bir hata sonucunda özel durumlar oluşabilir.In addition, exceptions can arise as a result of a fault in any level of the system. Bir düzeyde yaşanan özel durum genellikle onun üstündeki düzeyde başka bir hatayı tetikler.An exception in one level often triggers another fault in the level above.

Bu nedenlerle, sistemin ve sistem üzerinde çalıştırılan uygulamaların durumunun genel bir görünümünü oluşturmak için her düzeyde elde edilen farklı türlerdeki izleme verilerini birbiriyle ilişkilendirmeniz gerekir.For these reasons, you need to be able to correlate the different types of monitoring data at each level to produce an overall view of the state of the system and the applications that are running on it. Bundan sonra bu bilgileri kullanarak sistemin çalışma durumunun kabul edilebilir olup olmadığı konusunda karar verebilir ve sistemin kalitesini geliştirmek için neler yapılabileceğini saptayabilirsiniz.You can then use this information to make decisions about whether the system is functioning acceptably or not, and determine what can be done to improve the quality of the system.

Verileri ilişkilendirmek için gereken bilgiler bölümünde açıklandığı gibi, ham ölçümlü izleme verilerinin olayları ilişkilendirmek için gereken toplama işlemlerini desteklemek için yeterli bağlam ve etkinlik kimliği bilgilerini içerdiğinden emin olmalısınız.As described in the section Information for correlating data, you must ensure that the raw instrumentation data includes sufficient context and activity ID information to support the required aggregations for correlating events. Ayrıca, bu bilgiler farklı biçimlerde tutulmuş olabilir ve analiz amacıyla bu bilgileri standart bir biçime dönüştürmek için ayrıştırmak gerekebilir.Additionally, this data might be held in different formats, and it might be necessary to parse this information to convert it into a standardized format for analysis.

Sorunları tanılama ve gidermeTroubleshooting and diagnosing issues

Tanılama işlemi, kök neden analizi gerçekleştirmek de dahil olmak üzere hataların veya beklenmedik davranışların nedenini saptayabilmeyi gerektirir.Diagnosis requires the ability to determine the cause of faults or unexpected behavior, including performing root cause analysis. Normal olarak şu bilgiler gerekir:The information that's required typically includes:

  • Belirtilen bir zaman çerçevesinde sistemin tamamının veya belirli bir alt sistemin olay günlüklerinden ve izlemelerinden alınan ayrıntılı bilgiler.Detailed information from event logs and traces, either for the entire system or for a specified subsystem during a specified time window.
  • Belirtilen bir süre içinde sistemde veya belirli bir alt sistemde oluşan her düzeydeki özel durumlar ve hataların sonucunda alınan eksiksiz yığın izlemesi.Complete stack traces resulting from exceptions and faults of any specified level that occur within the system or a specified subsystem during a specified period.
  • Belirtilen bir zaman çerçevesinde sistemin herhangi bir yerinde veya belirli bir alt sistemdeki başarısız işlemlerin kilitlenme bilgi dökümleri.Crash dumps for any failed processes either anywhere in the system or for a specified subsystem during a specified time window.
  • Belirtilen bir süre içinde tüm kullanıcılar veya seçilen kullanıcılar tarafından gerçekleştirilen işlemlerin etkinlik günlükleri kaydı.Activity logs recording the operations that are performed either by all users or for selected users during a specified period.

Sorun giderme amacıyla verilerin analiz edilmesi için çoğunlukla sistem mimarisinin ve çözümü oluşturan çeşitli bileşenlerin teknik açıdan ayrıntılı olarak anlaşılması gereklidir.Analyzing data for troubleshooting purposes often requires a deep technical understanding of the system architecture and the various components that compose the solution. Sonuç olarak, verileri yorumlamak, sorunların nedenini belirlemek ve bunları düzeltmeye yönelik uygun bir strateji önermek için çoğunlukla önemli ölçüde el ile müdahale gerekir.As a result, a large degree of manual intervention is often required to interpret the data, establish the cause of problems, and recommend an appropriate strategy to correct them. Yalnızca bu bilgilerin özgün biçimlerinde birer kopyasını saklamak ve bir uzmanın bunlar üzerinde gecikmeli analiz yapmasını sağlamak uygun olabilir.It might be appropriate simply to store a copy of this information in its original format and make it available for cold analysis by an expert.

Verileri görselleştirme ve uyarı oluşturmaVisualizing data and raising alerts

Tüm izleme sistemlerinin önemli bir yönü, verileri bir operatörün her türlü eğilimi veya sorunu hızla belirleyebilmesini sağlayacak şekilde gösterme özelliğidir.An important aspect of any monitoring system is the ability to present the data in such a way that an operator can quickly spot any trends or problems. Ayrıca dikkat edilmesi gereken önemli bir olay olduğunda operatörü bu konuda hızla bilgilendirmek de önemli bir özelliktir.Also important is the ability to quickly inform an operator if a significant event has occurred that might require attention.

Veriler çeşitli biçimlerde, örneğin panolar,uyarılar ve raporlar kullanılarak görselleştirme yoluyla sunulabilir.Data presentation can take several forms, including visualization by using dashboards, alerting, and reporting.

Panoları kullanarak görselleştirmeVisualization by using dashboards

Verileri görselleştirmenin en yaygın yolu, bilgileri bir dizi grafik, graf veya bazı başka çizimlerle görüntüleyebilen panoları kullanmaktır.The most common way to visualize data is to use dashboards that can display information as a series of charts, graphs, or some other illustration. Bu öğeler parametreleştirilebilir ve bir analistin belirli herhangi bir durum için önemli parametreleri (örneğin, süre) seçebilmesi gerekir.These items can be parameterized, and an analyst should be able to select the important parameters (such as the time period) for any specific situation.

Panolar hiyerarşik olarak düzenlenebilir.Dashboards can be organized hierarchically. En üst düzey panolar sistemin her yönünün genel bir görünümünü verebilir ve operatörün ayrıntıya gitmesine olanak tanıyabilir.Top-level dashboards can give an overall view of each aspect of the system but enable an operator to drill down to the details. Örneğin sistemin genel disk G/Ç bilgisini gösteren bir pano, orantısız trafik hacmine belirli bir veya birden çok cihazın neden olup olmadığını belirlemek için analistin her diske ilişkin G/Ç hızlarını görüntülemesine olanak tanımalıdır.For example, a dashboard that depicts the overall disk I/O for the system should allow an analyst to view the I/O rates for each individual disk to ascertain whether one or more specific devices account for a disproportionate volume of traffic. İdeal durumda pano, bu G/Ç'yi oluşturan her isteğin kaynağı (kullanıcı veya etkinlik) gibi ilgili bilgileri de görüntülemelidir.Ideally, the dashboard should also display related information, such as the source of each request (the user or activity) that's generating this I/O. Bu bilgiler daha sonra yükün cihazlar arasında daha eşit dağıtılıp dağıtılmayacağını ve bu dağıtımın nasıl yapılacağını, ayrıca daha fazla cihaz eklenirse sistemin daha iyi performans gösterip göstermeyeceğini saptamak için kullanılabilir.This information can then be used to determine whether (and how) to spread the load more evenly across devices, and whether the system would perform better if more devices were added.

Pano anormal görünen veya beklenen aralığın dışında kalan değerleri göstermek için renk kodlaması veya başka görsel ipuçları da kullanabilir.A dashboard might also use color-coding or some other visual cues to indicate values that appear anomalous or that are outside an expected range. Önceki örneği kullanırsak:Using the previous example:

  • Uzun bir süre boyunca G/Ç hızı maksimum kapasitesine yaklaşan bir disk (etkin disk) kırmızıyla vurgulanabilir.A disk with an I/O rate that's approaching its maximum capacity over an extended period (a hot disk) can be highlighted in red.
  • Düzenli aralıklarla kısa süreler için G/Ç hızı maksimum sınırında çalışan bir disk (yarı etkin disk) sarıyla vurgulanabilir.A disk with an I/O rate that periodically runs at its maximum limit over short periods (a warm disk) can be highlighted in yellow.
  • Normal kullanım ortaya koyan bir disk yeşille gösterilebilir.A disk that's exhibiting normal usage can be displayed in green.

Pano sisteminin etkili çalışması için, üzerinde çalışacağı ham verileri olması gerektiğini unutmayın.Note that for a dashboard system to work effectively, it must have the raw data to work with. Kendi pano sisteminizi oluşturuyorsanız veya başka bir kuruluşun geliştirdiği panoyu kullanıyorsanız, hangi ölçümlü izleme verilerini, hangi ayrıntı düzeyinde toplamanız gerektiğini ve panonun kullanabilmesi için bu verilerin nasıl biçimlendirileceğini anlamalısınız.If you are building your own dashboard system, or using a dashboard developed by another organization, you must understand which instrumentation data you need to collect, at what levels of granularity, and how it should be formatted for the dashboard to consume.

İyi bir pano yalnızca bilgileri görüntülemekle kalmaz, analistin bu bilgilerle ilgili rastgele sorular sorabilmesine de olanak tanır.A good dashboard does not only display information, it also enables an analyst to pose ad hoc questions about that information. Bazı sistemler operatörün bu görevleri gerçekleştirmek ve temel verileri incelemek için kullanabileceği yönetim araçları sağlar.Some systems provide management tools that an operator can use to perform these tasks and explore the underlying data. Alternatif olarak, bilgileri tutmak için kullanılan depoya bağlı olmak kaydıyla bu verileri doğrudan sorgulamak veya daha fazla analiz ve raporlama için Microsoft Excel gibi araçlara aktarmak da mümkün olabilir.Alternatively, depending on the repository that's used to hold this information, it might be possible to query this data directly, or import it into tools such as Microsoft Excel for further analysis and reporting.

Not

Bunlar ticari açıdan hassas bilgiler olabileceğinden, panolara erişimi yetkili personelle sınırlandırmalısınız.You should restrict access to dashboards to authorized personnel, because this information might be commercially sensitive. Ayrıca panoların temel verilerini koruyarak bunların kullanıcılar tarafından değiştirilmesini de engellemeniz gerekir.You should also protect the underlying data for dashboards to prevent users from changing it.

Uyarı oluşturmaRaising alerts

Uyarı verme, izleme ve ölçümlü izleme verilerini analiz etme, önemli bir olay algılanması durumunda da bildirim oluşturma sürecidir.Alerting is the process of analyzing the monitoring and instrumentation data and generating a notification if a significant event is detected.

Uyarı verme süreci sistemin iyi, yanıt verir ve güvenli durumda olduğundan emin olmayı sağlar.Alerting helps ensure that the system remains healthy, responsive, and secure. Bu, verilerin üzerinde hemen işlem yapılmasının gerekli olabildiği, kullanıcılara performans, kullanılabilirlik ve gizlilik garantileri veren her sistemin önemli bir parçasıdır.It's an important part of any system that makes performance, availability, and privacy guarantees to the users where the data might need to be acted on immediately. Uyarıyı tetikleyen olayın operatöre bildirilmesi gerekebilir.An operator might need to be notified of the event that triggered the alert. Uyarı verme, otomatik ölçeklendirme gibi sistem işlevlerini çağırmak için de kullanılabilir.Alerting can also be used to invoke system functions such as autoscaling.

Uyarı verme genellikle aşağıdaki ölçümlü izleme verilerine dayanır:Alerting usually depends on the following instrumentation data:

  • Güvenlik olayları.Security events. Olay günlükleri yinelenen kimlik doğrulama ve/veya yetkilendirme hataları oluştuğunu gösteriyorsa, sistem saldırı altında olabilir ve operatörün bilgilendirilmesi gerekebilir.If the event logs indicate that repeated authentication and/or authorization failures are occurring, the system might be under attack and an operator should be informed.
  • Performans ölçümleri.Performance metrics. Belirli bir performans ölçümünün belirtilen eşiği aşması durumunda sistemin hızla yanıt vermesi gerekir.The system must quickly respond if a particular performance metric exceeds a specified threshold.
  • Kullanılabilirlik bilgileri.Availability information. Hata algılanırsa, bir veya birden çok alt sistemi hızla yeniden başlatmak veya yedek kaynağa yük devretmek gerekebilir.If a fault is detected, it might be necessary to quickly restart one or more subsystems, or fail over to a backup resource. Bir alt sistemdeki yinelenen hatalar daha ciddi sorunlara işaret ediyor olabilir.Repeated faults in a subsystem might indicate more serious concerns.

Operatörler e-posta, çağrı cihazı veya SMS mesajı gibi birçok teslim kanalından birini kullanarak uyarı bilgilerini alabilir.Operators might receive alert information by using many delivery channels such as email, a pager device, or an SMS text message. Uyarıda durumun ne kadar kritik olduğuna dair bir gösterge de bulunabilir.An alert might also include an indication of how critical a situation is. Birçok uyarı sistemi abone gruplarını destekler ve aynı gruba üye olan tüm operatörler aynı uyarı kümelerini alabilir.Many alerting systems support subscriber groups, and all operators who are members of the same group can receive the same set of alerts.

Uyarı sistemi özelleştirilebilir olmalıdır ve temel ölçümlü izleme verilerinden elde edilen uygun değerler parametre olarak sağlanabilir.An alerting system should be customizable, and the appropriate values from the underlying instrumentation data can be provided as parameters. Bu yaklaşım operatörün verileri filtrelemesine ve ilgilendiği eşiklere veya değer bileşimlerine odaklanmasına olanak tanır.This approach enables an operator to filter data and focus on those thresholds or combinations of values that are of interest. Bazı durumlarda, uyarı sistemine ham ölçümlü izleme verilerinin sağlanabileceğini unutmayın.Note that in some cases, the raw instrumentation data can be provided to the alerting system. Başka durumlarda, toplanan verilerin sağlanması daha uygun olabilir.In other situations, it might be more appropriate to supply aggregated data. (Örneğin, bir düğüm için CPU kullanımı son 10 dakika içinde yüzde 90'ı aşarsa bir uyarı tetiklenebilir).(For example, an alert can be triggered if the CPU utilization for a node has exceeded 90 percent over the last 10 minutes). Uyarı sistemine sağlanan ayrıntılar uygun bir özeti ve bağlam bilgilerini de içerebilir.The details provided to the alerting system should also include any appropriate summary and context information. Bu veriler hatalı pozitif sonuç veren olayların yanlış uyarılara neden olma olasılığını düşürmeye yardımcı olabilir.This data can help reduce the possibility that false-positive events will trip an alert.

RaporlamaReporting

Raporlama sistemin genel bir görünümünü elde etmek için kullanılır.Reporting is used to generate an overall view of the system. Güncel bilgilere ek olarak geçmiş verilerini de bir araya getirebilir.It might incorporate historical data in addition to current information. Raporlama gereksinimleri kendi başına iki büyük kategoriye ayrılır: işlem raporlaması ve güvenlik raporlaması.Reporting requirements themselves fall into two broad categories: operational reporting and security reporting.

İşlem raporlaması normalde aşağıdaki konuları içerir:Operational reporting typically includes the following aspects:

  • Belirtilen zaman çerçevesinde sistemin veya belirtilen alt sistemlerin kaynak kullanımını anlamak için kullanabileceğiniz istatistikleri bir araya toplama.Aggregating statistics that you can use to understand resource utilization of the overall system or specified subsystems during a specified time window.
  • Belirtilen bir süre boyunca bir bütün olarak sistemin veya belirtilen alt sistemlerin kaynak kullanım eğilimlerini tanımlama.Identifying trends in resource usage for the overall system or specified subsystems during a specified period.
  • Sistem genelinde oluştu veya belirlenen bir süre boyunca belirtilen alt sistemlerin özel durumları izleme.Monitoring the exceptions that have occurred throughout the system or in specified subsystems during a specified period.
  • Uygulamanın dağıtılan kaynaklar cinsinden verimliliğini belirleme ve kaynak hacminin (ve ilişkili maliyetin) gereksiz yere performansını etkilemeden azaltılabilir olup olmadığını anlama.Determining the efficiency of the application in terms of the deployed resources, and understanding whether the volume of resources (and their associated cost) can be reduced without affecting performance unnecessarily.

Güvenlik raporlaması müşterilerin sistem kullanımını izlemekle ilgilidir.Security reporting is concerned with tracking customers' use of the system. Şunları içerebilir:It can include:

  • Kullanıcı işlemlerini denetleme.Auditing user operations. Bunun için her kullanıcının gerçekleştirdiği istekleri tek tek, tarih ve saatiyle kaydetmek gerekir.This requires recording the individual requests that each user performs, together with dates and times. Yöneticinin belirli bir sürede kullanıcının gerçekleştirdiği işlemlerin sırasını hızla yeniden oluşturabilmesi için veriler yapılandırılmalıdır.The data should be structured to enable an administrator to quickly reconstruct the sequence of operations that a user performs over a specified period.
  • Kullanıcının kaynak kullanımını izleme.Tracking resource use by user. Bunun için kullanıcıyla ilişkili her isteğin sistemi oluşturan çeşitli kaynaklara nasıl ve ne kadar süreyle eriştiğini kaydetmek gerekir.This requires recording how each request for a user accesses the various resources that compose the system, and for how long. Yönetici bu verileri kullanarak belirli bir süre için kullanıcının kullanım raporunu (muhtemelen faturalama amacıyla) oluşturabilmelidir.An administrator must be able to use this data to generate a utilization report by user over a specified period, possibly for billing purposes.

Birçok durumda, tanımlanan zamanlamaya göre raporları toplu işlemler oluşturabilir.In many cases, batch processes can generate reports according to a defined schedule. (Normalde gecikme sorunu yaşanmaz.) Ama gerektiğinde bu raporlar zamanlama dışında da oluşturulabilmelidir.(Latency is not normally an issue.) But they should also be available for generation on an ad hoc basis if needed. Örneğin, verileri Azure SQL Veritabanı gibi bir ilişkisel veritabanında depoluyorsanız verileri ayıklayıp biçimlendirmek ve bir dizi rapor şeklinde sunmak için SQL Server Reporting Services gibi bir araç kullanabilirsiniz.As an example, if you are storing data in a relational database such as Azure SQL Database, you can use a tool such as SQL Server Reporting Services to extract and format data and present it as a set of reports.

  • Otomatik ölçeklendirme kılavuzu, kullanıcının sürekli sistem performansını izlemesi ve kaynakları ekleme ve kaldırma hakkında karar vermesi gerekliliğini ortadan kaldırarak yönetim yükünün nasıl azaltılabileceğini açıklar.Autoscaling guidance describes how to decrease management overhead by reducing the need for an operator to continually monitor the performance of a system and make decisions about adding or removing resources.
  • Sistem durumu uç nokta izleme düzeni nasıl işlev denetimleri dış araçların düzenli aralıklarla ortaya çıkarılan uç noktalar erişebildiği bir uygulama içinde uygulanacağını açıklar.Health Endpoint Monitoring pattern describes how to implement functional checks within an application that external tools can access through exposed endpoints at regular intervals.
  • Öncelikli kuyruk düzeni Acil isteklerin alınır ve daha az Acil isteklerden önce işlenir böylece kuyruğa alınan iletilerde önceliğin nasıl gösterir.Priority Queue pattern shows how to prioritize queued messages so that urgent requests are received and can be processed before less urgent messages.

Daha fazla bilgiMore information