Bir mikro hizmet mimarisi Azure Kubernetes Service (AKS) izlemeMonitoring a microservices architecture in Azure Kubernetes Service (AKS)

Bu makalede, Azure Kubernetes Service (AKS) üzerinde çalışan bir mikro Hizmetler uygulaması izleme için en iyi uygulamaları açıklar.This article describes best practices for monitoring a microservices application that runs on Azure Kubernetes Service (AKS).

Karmaşık bir uygulamada belirli bir noktada bir şey yanlış geçer.In any complex application, at some point something will go wrong. Bir mikro Hizmetler uygulaması düzinelerce, ister yüzlerce hatta hizmeti arasında neler olduğunu izlemek gerekir.In a microservices application, you need to track what's happening across dozens or even hundreds of services. Anlamlı olup bitenleri için uygulamadan telemetri toplamanız gerekir.To make sense of what's happening, you must collect telemetry from the application. Telemetri, içine ayrılabilir günlükleri ve ölçümleri.Telemetry can be divided into logs and metrics.

Günlükleri uygulama çalışırken meydana gelen olayları kayıtları metin tabanlı.Logs are text-based records of events that occur while the application is running. Uygulama günlükleri (izleme deyimleri) veya web sunucusu günlükleri gibi şeyleri içerirler.They include things like application logs (trace statements) or web server logs. Günlükleri adli araştırma ve ve kök neden çözümlemesi için öncelikle yararlıdır.Logs are primarily useful for forensics and root cause analysis.

Ölçümleri çözümlenebilir sayısal değerler.Metrics are numerical values that can be analyzed. Bunları, gerçek zamanlı olarak (veya gerçek zamanlı yakın) olarak sistemi gözlemleyin veya zaman içinde performans eğilimlerini analiz etmek için kullanabilirsiniz.You can use them to observe the system in real time (or close to real time), or to analyze performance trends over time. Sistem bütünlüklü olarak anlamak için fiziksel altyapı, uygulama mimarisinin çeşitli düzeylerde ölçümleri toplamanızı gerekir dahil olmak üzere:To understand the system holistically, you must collect metrics at various levels of the architecture, from the physical infrastructure to the application, including:

  • Düğüm düzeyi CPU, bellek, ağ, disk ve dosya sistemi kullanımı da dahil seçilen ölçümlerin,.Node-level metrics, including CPU, memory, network, disk, and file system usage. Sistem ölçümlerini, kümedeki her düğüm için kaynak ayırma anlamanıza yardımcı ve aykırı değerleri sorun giderme.System metrics help you to understand resource allocation for each node in the cluster, and troubleshoot outliers.

  • Kapsayıcı ölçümleri.Container metrics. Kapsayıcılı uygulamalar için ölçümleri kapsayıcı düzeyinde, yalnızca VM düzeyinde toplamanız gerekir.For containerized applications, you need to collect metrics at the container level, not just at the VM level.

  • Uygulama ölçümleri.Application metrics. Bu, bir hizmet davranışını anlamak için uygun olan tüm ölçümleri içerir.This includes any metrics that are relevant to understanding the behavior of a service. Sıraya alınan gelen HTTP isteklerini, istek gecikme süresi veya ileti sırası uzunluğu sayısı verilebilir.Examples include the number of queued inbound HTTP requests, request latency, or message queue length. Uygulamalar Ayrıca dakikada işlenen iş işlem sayısı gibi etki alanına özgü özel ölçümler oluşturabilirsiniz.Applications can also create custom metrics that are specific to the domain, such as the number of business transactions processed per minute.

  • Bağımlı hizmet ölçümleri.Dependent service metrics. Hizmet uç noktaları, yönetilen PaaS Hizmetleri veya SaaS Hizmetleri gibi dış hizmetlere ya da çağırabilir.Services may call external services or endpoints, such as managed PaaS services or SaaS services. Üçüncü taraf hizmetleri olabilir veya tüm ölçümleri sağlamayabilir.Third-party services may or may not provide any metrics. Aksi durumda, gecikme süresi ve hata oranı istatistiklerini izlemek için kendi uygulama ölçümleri dayanan zorunda kalırsınız.If not, you'll have to rely on your own application metrics to track statistics for latency and error rate.

Küme durumunu izlemeMonitoring cluster status

Kullanım [Azure İzleyici] azure-monitor kümelerinizi genel durumunu izlemek için.Use Azure Monitor to monitor the overall health of your clusters. Aşağıdaki ekran görüntüsünde, kullanıcı tarafından dağıtılan pod'ların kritik hataları olan bir küme gösterir.The following screenshot shows a cluster with critical errors in user-deployed pods.

Azure ekran izleme Panosu

Buradan, sorunu bulma daha fazla sınırlandıramazsınız gidebilir.From here, you can drill in further to find the issue. Örneğin, pod durum ise ImagePullBackoff, Kubernetes kapsayıcı görüntüsünü kayıt defterinden çektiğini değil anlamına gelir.For example, if the pod status is ImagePullBackoff, it means that Kubernetes could not pull the container image from the registry. Bu geçersiz kapsayıcı etiketi veya kayıt defterinden çekme çalışılırken bir kimlik doğrulama hata tarafından kaynaklanabilir.This could be caused by an invalid container tag or an authentication error trying to pull from the registry.

Bir kapsayıcı kilitlenen kapsayıcı durumuna sokar Not State = Waiting, ile Reason = CrashLoopBackOff.Note that a container crashing will put the container state into State = Waiting,with Reason = CrashLoopBackOff. Bir çoğaltma bir parçası olduğu bir pod tipik bir senaryo için ve yeniden deneme ilkesi topluluğudur Always, bu küme durumunu hata olarak gösterilmez.For a typical scenario where a pod is part of a replica set and the retry policy is Always, this won’t show as an error in the cluster status. Ancak, sorguları çalıştırmak veya bu koşul için uyarılar ayarlayın.However, you can run queries or set up alerts for this condition. Daha fazla bilgi için anlamak AKS, kapsayıcılar için Azure İzleyici ile performans küme.For more information, see Understand AKS cluster performance with Azure Monitor for containers.

ÖlçümlerMetrics

Kullanmanızı öneririz [Azure İzleyici] azure-monitor toplayıp AKS kümeleriniz ve diğer bağımlı Azure Hizmetleri için ölçümleri görüntüleyin.We recommend using Azure Monitor to collect and view metrics for your AKS clusters and any other dependent Azure services.

  • Küme ve kapsayıcı ölçümlerini etkinleştirmeniz kapsayıcılar için Azure İzleyici.For cluster and container metrics, enable Azure Monitor for containers. Bu özellik etkinleştirildiğinde, Azure İzleyici ölçümleri bellek ve işlemci denetleyicileri, düğümlerin ve kapsayıcıların Kubernetes ölçüm API'si toplar.When this feature is enabled, Azure Monitor collects memory and processor metrics from controllers, nodes, and containers via the Kubernetes metrics API. Kapsayıcılar için Azure İzleyici kullanılabilir ölçümler hakkında daha fazla bilgi için bkz. anlamak AKS, kapsayıcılar için Azure İzleyici ile performans küme.For more information about the metrics that are available through Azure Monitor for containers, see Understand AKS cluster performance with Azure Monitor for containers.

  • Kullanım Application Insights uygulama ölçümleri toplamak için.Use Application Insights to collect application metrics. Application Insights, Genişletilebilir bir uygulama performans yönetimi (APM) hizmetidir.Application Insights is an extensible Application Performance Management (APM) service. Bunu kullanmak için uygulamanızda bir izleme paketi yükleyin.To use it, you install an instrumentation package in your application. Bu paket, uygulama izler ve telemetri verilerini Application Insights hizmetine gönderir.This package monitors the app and sends telemetry data to the Application Insights service. Ayrıca, ana bilgisayar ortamının telemetri verilerini de çekebilirsiniz.It can also pull telemetry data from the host environment. Veriler, Azure İzleyici sonra gönderilir.The data is then sent to Azure Monitor. Application Insights ayrıca yerleşik bağıntı ve bağımlılık izleme sağlar (bkz dağıtılmış izlemeaşağıdaki).Application Insights also provides built-in correlation and dependency tracking (see Distributed tracing, below).

Application Insights sahip olay/saniye cinsinden en yüksek aktarım hızı ve veri hızı bu sınırı aşarsa, kısıtlar.Application Insights has a maximum throughput measured in events/second, and it throttles if the data rate exceeds the limit. Ayrıntılar için bkz Application Insights sınırlar.For details, see Application Insights limits. Her ortam, farklı Application Insights örnekleri oluşturun, böylece geliştirme ve test ortamları kotası için üretim telemetri karşı göstermiyoruz.Create different Application Insights instances per environment, so that dev/test environments don't compete against the production telemetry for quota.

Birkaç telemetri olaylarını tek bir işlem oluşturmak için kullanabileceğiniz uygulama trafiği yüksek hacimli karşılaşırsa, kısıtlanan olasılığınız olacak şekilde.A single operation may generate several telemetry events, so if the application experiences a high volume of traffic, it is likely to get throttled. Bu sorunu gidermek için telemetri trafiğini azaltmak için örnekleme gerçekleştirebilirsiniz.To mitigate this problem, you can perform sampling to reduce the telemetry traffic. Artırabilen ölçümlerinizi daha az kesin duruma geleceğidir.The tradeoff is that your metrics will be less precise. Daha fazla bilgi için Application Insights'ta örnekleme.For more information, see Sampling in Application Insights. Veri hacmi tarafından önceden toplama ölçümleri azaltabilir — diğer bir deyişle, ortalama ve standart sapma gibi istatistiksel değerleri hesaplama ve bu değerler yerine ham telemetri gönderme.You can also reduce the data volume by pre-aggregating metrics — that is, calculating statistical values such as average and standard deviation, and sending those values instead of the raw telemetry. Aşağıdaki Web günlüğü gönderisinde ölçekte Application Insights'ı kullanarak bir yaklaşım açıklanmaktadır: Azure izleme ve analiz uygun ölçekte.The following blog post describes an approach to using Application Insights at scale: Azure Monitoring and Analytics at Scale.

Varsa, veri hızı azaltma tetikleyici için yeterince yüksek ve örnekleme veya toplama kabul edilebilir olmayan bir zaman serisi veritabanına gibi ölçümleri dışa göz önünde bulundurun Prometheus veya InfluxDB çalıştırma Küme.If your data rate is high enough to trigger throttling, and sampling or aggregation are not acceptable, consider exporting metrics to a time-series database such as Prometheus or InfluxDB running in the cluster.

  • InfluxDB gönderim temelli bir sistemdir.InfluxDB is a push-based system. İletme ölçümleri bir aracı gerekir.An agent needs to push the metrics. Kullanabileceğiniz Heapster, kubelet, küme çapında ölçümleri toplayan bir hizmet olan verileri toplar ve InfluxDB veya başka bir zaman serisi depolama çözümü için anında bildirim gönderir.You can use Heapster, which is a service that collects cluster-wide metrics from kubelet, aggregates the data, and pushes it to InfluxDB or other time-series storage solution. Azure Container Service kümesi kurulumun bir parçası olarak Heapster dağıtır.Azure Container Service deploys Heapster as part of the cluster setup. Başka bir seçenek Telegraf, toplama ve ölçümleri raporlama için bir aracı olduğunu.Another option is Telegraf, which is an agent for collecting and reporting metrics.

  • Prometheus çekme tabanlı bir sistemdir.Prometheus is a pull-based system. Düzenli aralıklarla ölçümleri yapılandırılmış konumlardan scrapes.It periodically scrapes metrics from configured locations. Prometheus cAdvisor kube-durumunu-metrics tarafından mı ölçümleri scrape.Prometheus can scrape metrics generated by cAdvisor or kube-state-metrics. [kube durum ölçümleri] kube-state-metrics , Kubernetes API sunucudan ölçümleri toplar ve bunları Prometheus (veya Prometheus istemci uç noktası ile uyumlu bir scraper) kullanımına bir hizmettir.kube-state-metrics is a service that collects metrics from the Kubernetes API server and makes them available to Prometheus (or a scraper that is compatible with a Prometheus client endpoint). Heapster Kubernetes oluşturur ve bunları bir havuz için iletir ölçümleri toplar ancak kube-durumunu-metrics kendi ölçümleri oluşturur ve bir uç nokta değiştirilene için kullanılabilir hale getirir.Whereas Heapster aggregates metrics that Kubernetes generates and forwards them to a sink, kube-state-metrics generates its own metrics and makes them available through an endpoint for scraping. Sistem ölçümlerini için kullanmak düğüm verici, sistem ölçümler için bir Prometheus verici olduğu.For system metrics, use Node exporter, which is a Prometheus exporter for system metrics. Veri noktası, ancak dize verileri kayan Prometheus destekler, böylece sistem ölçümlerini ancak değil günlükleri için uygundur.Prometheus supports floating point data, but not string data, so it is appropriate for system metrics but not logs.

Günlüğe kaydetmeLogging

Bir mikro hizmet uygulamasında oturum genel sorunlarından bazıları şunlardır:Here are some of the general challenges of logging in a microservices application:

  • Burada birden çok hizmet tek bir isteği işlemek için çağrılan bir istemci isteği uçtan uca işlenmesini anlama.Understanding the end-to-end processing of a client request, where multiple services might be invoked to handle a single request.
  • Birden çok hizmet günlüklerini tek bir toplu görünüm birleştiriliyor.Consolidating logs from multiple services into a single aggregated view.
  • Birden fazla kaynaktan gelen günlükler ayrıştırma, hangi kendi günlüğü şemaları kullanabilir veya hiçbir belirli bir şemaya sahip.Parsing logs that come from multiple sources, which use their own logging schemas or have no particular schema. Günlükleri kontrol olmayan üçüncü taraf bileşenleri tarafından oluşturulabilir.Logs may be generated by third-party components that you don't control.
  • Daha fazla Hizmetleri, ağ çağrıları ve adımları bir işlemde olduğundan mikro hizmet mimarileri genellikle günlüklerin daha büyük bir birime daha geleneksel hamleye olanak oluşturur.Microservices architectures often generate a larger volume of logs than traditional monoliths, because there are more services, network calls, and steps in a transaction. Kendi günlük bir performans veya uygulama için kaynak sorunu olabilir anlamına gelir.That means logging itself can be a performance or resource bottleneck for the application.

Kubernetes tabanlı bir mimari için ek bazı zorluklar vardır:There are some additional challenges for a Kubernetes-based architecture:

  • Kapsayıcılar taşıyabilirsiniz ve zamanlanması.Containers can move around and be rescheduled.
  • Kubernetes, sanal IP adresleri ve bağlantı noktası eşlemelerini kullanan bir ağ soyutlama sahiptir.Kubernetes has a networking abstraction that uses virtual IP addresses and port mappings.

Kubernetes'te, stdout ve stderr günlüklerini yazmak bir kapsayıcı günlüğe kaydetme için standart bir yaklaşım içindir.In Kubernetes, the standard approach to logging is for a container to write logs to stdout and stderr. Kapsayıcı altyapısı bu akışları için günlük sürücü yönlendirir.The container engine redirects these streams to a logging driver. Sorgulamak ve bir düğüm kilitlenmesi durumunda günlük veri kaybını önlemek için kolaylaştırmak için her zamanki her düğümden günlükleri toplayabilir ve bunları merkezi bir depolama konumuna göndermek için yaklaşımdır.For ease of querying, and to prevent possible loss of log data if a node crashes, the usual approach is to collect the logs from each node and send them to a central storage location.

Azure İzleyici, bu yaklaşım desteklemek için AKS ile tümleştirebilirsiniz.Azure Monitor integrates with AKS to support this approach. Azure İzleyici, kapsayıcı günlüklerini toplar ve bunları bir Log Analytics çalışma alanınıza gönderir.Azure Monitor collects container logs and sends them to a Log Analytics workspace. Burada, kullandığınız Kusto sorgu dili toplanan günlükleri arasında sorguları yazma.From there, you can use the Kusto query language to write queries across the aggregated logs. Örneğin, bir Kusto sorgusu için belirtilen bir pod kapsayıcı günlüklerini görüntülemek için şu şekildedir:For example, here is a Kusto query to show the container logs for a specified pod:

let ContainerIdList = KubePodInventory
| where ClusterName =~ '<cluster-name>'
| where Name =~ '<pod-name>'
| distinct ContainerID;
ContainerLog
| where ContainerID in (ContainerIdList)

Azure İzleyici yönetilen bir hizmet ve Azure İzleyici, bir AKS kümesi yapılandırma CLI veya Resource Manager şablonunda bir basit yapılandırma anahtarı.Azure Monitor is a managed service, and configuring an AKS cluster to use Azure Monitor is a simple configuration switch in the CLI or Resource Manager template. (Daha fazla bilgi için kapsayıcılar için Azure İzleyici etkinleştirme.) Azure izleme kullanarak başka bir avantajı, birleşik bir izleme deneyimi sağlama çalışmaları diğer Azure platformu günlükleri ile AKS günlüklerinizi birleştirir olmasıdır.(For more information, see How to enable Azure Monitor for containers.) Another advantage of using Azure Monitoring is that it consolidates your AKS logs with other Azure platform logs, providing a unified monitoring experience.

Azure İzleyici, veri hizmetine alınan gigabayt (GB) başına faturalandırılır (bkz Azure İzleyici fiyatlandırma).Azure Monitor is billed per gigabyte (GB) of data ingested into the service (see Azure Monitor pricing). Çok yüksek hacimlerinde maliyet önemli bir unsur hale gelebilir.At very high volumes, cost may become a consideration. Kubernetes ekosistemi için kullanılabilen birçok açık kaynak seçenekleri vardır.There are many open-source alternatives available for the Kubernetes ecosystem. Örneğin, çoğu kuruluş kullanır Fluentd ile Elasticsearch.For example, many organizations use Fluentd with Elasticsearch. Fluentd bir açık kaynak veri toplayıcısı olan ve Elasticsearch için arama, bir belge veritabanıdır.Fluentd is an open-source data collector, and Elasticsearch is a document database that is for search. Bu seçenekler ile ek yapılandırma ve yönetim kümesinin gerektiğini zordur.A challenge with these options is that they require additional configuration and management of the cluster. Bir üretim iş yükü için yapılandırma ayarları ile denemeler yapmanız gerekebilir.For a production workload, you may need to experiment with configuration settings. Günlük altyapısının performansını izlemek gerekir.You'll also need to monitor the performance of the logging infrastructure.

Application InsightsApplication Insights

Daha zengin günlük verileri için kodunuzu Application Insights ile işaretleyerek öneririz.For richer log data, we recommend instrumenting your code with Application Insights. Bu, kodunuza Application Insights paketini ekleme ve günlük kaydı deyimleri Application Insights'a gönderme için kodunuzu yapılandırma gerektirir.This requires adding an Application Insights package to your code and configuring your code to send logging statements to Application Insights. .NET, Java ve Node.js gibi bir platform üzerinde ayrıntılarına bağlıdır.The details depend on the platform, such as .NET, Java, or Node.js. Application Insights paketini telemetri verilerini Azure İzleyicisi'ne gönderir.The Application Insights package sends telemetry data to Azure Monitor.

.NET Core kullanıyorsanız, aynı zamanda kullanmanızı öneririz Kubernetes için Application Insights kitaplığı.If you are using .NET Core, we recommend also using the Application Insights for Kubernetes library. Application Insights izlemelerini kapsayıcı ve düğüm, pod, etiketler ve çoğaltma kümesi gibi ek bilgilerle Bu kitaplık zenginleştirir.This library enriches Application Insights traces with additional information such as the container, node, pod, labels, and replica set.

Bu yaklaşımın avantajları şunlardır:Advantages of this approach include:

  • Application Insights, gecikme süresi ve sonuç kod dahil olmak üzere, HTTP isteklerini günlüğe kaydeder.Application Insights logs HTTP requests, including latency and result code.
  • Dağıtılmış izleme varsayılan olarak etkindir.Distributed tracing is enabled by default.
  • Belirli bir işlem için tüm izlemeler eşleşebilir için bir işlem kimliği izlemeleri içerir.Traces include an operation ID, so you can match all traces for a particular operation.
  • İzlemelerini sık Application Insights tarafından oluşturulan ek bağlamsal bilgiler vardır.Traces generated by Application Insights often have additional contextual information. Örneğin, ASP.NET izlemeleri eylem adı ve kategori ile gibi decorated ControllerActionInvoker, bu size ASP.NET istek ardışık düzenini Öngörüler.For example, ASP.NET traces are decorated with the action name and a category such as ControllerActionInvoker, which give you insights into the ASP.NET request pipeline.
  • Application Insights performansıyla ilgili sorunları giderme ve en iyi duruma getirme için performans ölçümleri toplar.Application Insights collects performance metrics for performance troubleshooting and optimization.

Dikkat edilmesi gerekenler:Considerations:

  • Application Insights telemetri veri hızı üst sınırı aşarsa kısıtlar; Ayrıntılar için bkz Application Insights sınırlar.Application Insights throttles the telemetry if the data rate exceeds a maximum limit; for details, see Application Insights limits. Birkaç telemetri olaylarını tek bir işlem oluşturmak için kullanabileceğiniz uygulama trafiği yüksek hacimli karşılaşırsa, kısıtlanan olasılığınız olacak şekilde.A single operation may generate several telemetry events, so if the application experiences a high volume of traffic, it is likely to get throttled.
  • Application Insights veri portalde işlenmeyen bir özel durum ile bir işlem kilitlenmesi durumunda bir toplu iş kaybı mümkündür.Because Application Insights batches data, it's possible to lose a batch if a process crashes with an unhandled exception.
  • Application Insights veri hacmine göre faturalandırılır.Application Insights is billed based on data volume. Daha fazla bilgi için Application ınsights fiyatlandırma ve veri hacmini yönetme.For more information, see Manage pricing and data volume in Application Insights.

Yapılandırılmış günlük kaydıStructured logging

Ayrıştırılacak günlükleri kolaylaştırmak için mümkün olduğunca yapılandırılmış günlük kullanın.To make logs easier to parse, use structured logging where possible. Yapılandırılmış günlük kaydı günlükleri uygulama çıktısı yapılandırılmamış metin dizelerinin yerine JSON gibi yapılandırılmış biçimde nereye yazdığını yaklaşımdır.Structured logging is approach where the application writes logs in a structured format, such as JSON, rather than outputting unstructured text strings. Birçok yapılandırılmış günlük kaydı kitaplıkları kullanılabilir.There are many structured logging libraries available. Örneğin, kullanan bir günlük deyimi işte Serilog Kitaplığı .NET Core için:For example, here is a logging statement that uses the Serilog library for .NET Core:

public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
{
    logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());

    ...
}

Burada, çağrı LogInformation içeren bir Id parametresi ve DeliveryInfo parametresi.Here, the call to LogInformation includes an Id parameter and DeliveryInfo parameter. Yapılandırılmış günlük kaydı ile bu değerleri ileti dizeye ilişkilendirilmiş değil.With structured logging, these values are not interpolated into the message string. Bunun yerine, günlük çıktısı aşağıdakine benzer görünecektir:Instead, the log output will look something like this:

{"@t":"2019-06-13T00:57:09.9932697Z","@mt":"In Put action with delivery {Id}: {@DeliveryInfo}","Id":"36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef","DeliveryInfo":{...

Bir JSON dizesi budur burada "@t"alanı olan bir zaman damgası"@mt" ileti dizesi ve parametreleri kalan anahtar/değer çiftleridir.This is a JSON string, where the "@t" field is a timestamp, "@mt" is the message string, and the remaining key/value pairs are the parameters. JSON çıktısını biçimi yapılandırılmış bir biçimde sorgulamak kolaylaştırır.Outputting JSON format makes it easier to query the data in a structured way. Yazılan Örneğin, aşağıdaki Log Analytics sorgusu, Kusto sorgu dili, arar adlı tüm kapsayıcıları belirli bu ileti örneklerini fabrikam-delivery:For example, the following Log Analytics query, written in the Kusto query language, searches for instances of this particular message from all containers named fabrikam-delivery:

traces
| where customDimensions.["Kubernetes.Container.Name"] == "fabrikam-delivery"
| where customDimensions.["{OriginalFormat}"] == "In Put action with delivery {Id}: {@DeliveryInfo}"
| project message, customDimensions["Id"], customDimensions["@DeliveryInfo"]

Gösteren Azure Portalı'nda sonucu görüntüleme DeliveryInfo serileştirilmiş bir gösterimi içeren yapılandırılmış bir kayıttır DeliveryInfo modeli:Viewing the result in the Azure portal shows that DeliveryInfo is a structured record that contains the serialized representation of the DeliveryInfo model:

Ekran görüntüsü, Log Analytics çalışma alanı

Bu örnekte JSON şu şekildedir:Here is the JSON from this example:

{
    "Id": "36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef",
    "Owner": {
        "UserId": "user id for logging",
        "AccountId": "52dadf0c-0067-43e7-af76-86e32b48bc5e"
    },
    "Pickup": {
        "Altitude": 0.29295161612934972,
        "Latitude": 0.26815900219052985,
        "Longitude": 0.79841844309047727
    },
    "Dropoff": {
        "Altitude": 0.31507750848078986,
        "Latitude": 0.753494655598651,
        "Longitude": 0.89352830773849423
    },
    "Deadline": "string",
    "Expedited": true,
    "ConfirmationRequired": 0,
    "DroneId": "AssignedDroneId01ba4d0b-c01a-4369-ba75-51bde0e76cc9"
}

Önceki kod parçacığında kullanılan Serilog kitaplığı, ancak yapılandırılmış günlük kaydı kitaplıklar, diğer diller için kullanılabilir.The previous code snippet used the Serilog library, but structured logging libraries are available for other languages as well. Örneğin, bir örnek aşağıdadır kullanarak SLF4J Java için kitaplığı:For example, here's an example using the SLF4J library for Java:

MDC.put("DeliveryId", deliveryId);

log.info("In schedule delivery action with delivery request {}", externalDelivery.toString());

Dağıtılmış izlemeDistributed tracing

Önemli mikro hizmetler arasında olay akışını anlamak zordur.A significant challenge of microservices is to understand the flow of events across services. Tek bir işlem birden çok hizmet çağrıları gerektirebilir.A single transaction may involve calls to multiple services. Her hizmet yayılması tüm adımlar dizisini yeniden oluşturmak için bir bağıntı kimliği , bu işlem için benzersiz bir tanımlayıcı olarak görev yapar.To reconstruct the entire sequence of steps, each service should propagate a correlation ID that acts as a unique identifier for that operation. Bağıntı kimliği etkinleştirir izleme dağıtılmış hizmetlerinde.The correlation ID enables distributed tracing across services.

Bir istemci isteği aldığında ilk hizmet bağıntı kimliği oluşturmakThe first service that receives a client request should generate the correlation ID. Hizmet başka bir hizmete HTTP çağrısı yaparsa, bağıntı kimliği istek üst bilgisinde koyar.If the service makes an HTTP call to another service, it puts the correlation ID in a request header. Hizmet zaman uyumsuz ileti gönderdiğinde, bağıntı kimliği ileti koyar.If the service sends an asynchronous message, it puts the correlation ID into the message. Tüm sistem üzerinden akmasını aşağı akış hizmetleriyle bağıntı kimliği yaymak devam edin.Downstream services continue to propagate the correlation ID, so that it flows through the entire system. Ayrıca, uygulama ölçüm veya günlük olayları yazar tüm kod bağıntı kimliği içermelidirIn addition, all code that writes application metrics or log events should include the correlation ID.

Hizmet çağrıları bağıntılı olan, bir işlemin, saniye başına başarılı işlem sayısı ve yüzdesi, başarısız işlemleri için uçtan uca gecikme süresi gibi işletimsel ölçümleri hesaplayabilirsiniz.When service calls are correlated, you can calculate operational metrics such as the end-to-end latency for a complete transaction, the number of successful transactions per second, and the percentage of failed transactions. Bağıntı kimlikleri uygulama günlüklerine dahil olmak üzere, kök neden analizi gerçekleştirmek mümkün kılar.Including correlation IDs in application logs makes it possible to perform root cause analysis. Bir işlem başarısız olursa, tüm aynı işlemin bir parçası olan hizmet çağrıları için log deyimleri bulabilirsiniz.If an operation fails, you can find the log statements for all of the service calls that were part of the same operation.

Dağıtılmış izleme için Application Insights'ı kullanmanızı öneririz.We recommend using Application Insights for distributed tracing. Application Insights SDK'sını otomatik olarak HTTP üst bilgileri düzeyine bağıntı bağlam ekler ve Application Insights günlüklerine bağıntı Kimliğini içerir.The Application Insights SDK automatically injects correlation context into HTTP headers, and includes the correlation ID in Application Insights logs. Bazı hizmetler devam bağıntı üstbilgileri, çerçeveler ve kitaplıklar kullanılan bağlı olarak açıkça yaymak gerekebilir.Some services may still need to explicitly propagate the correlation headers, depending on the frameworks and libraries being used. Daha fazla bilgi için Application ınsights Telemetri bağıntısı.For more information, see Telemetry correlation in Application Insights.

Dağıtılmış izleme uygularken bazı ek hususlar:Some additional considerations when implementing distributed tracing:

  • Şu anda standart bir HTTP üstbilgisi için bağıntı kimlikleri, ancak bir W3C önerisi bulunmaktadır.There is currently no standard HTTP header for correlation IDs, although a W3C proposal exists. Takımınız, bir özel üst bilgi değeri standart hale getirmek.Your team should standardize on a custom header value. Application Insights ya da hizmet kafes, tercih ettiğiniz gibi günlüğe kaydetme çerçevesi tarafından seçimi karar.The choice may be decided by your logging framework, such as Application Insights, or choice of service mesh.

  • Zaman uyumsuz ileti için ileti altyapınızın iletileri ekleyerek meta verileri destekleyip desteklemediğini olarak meta veriler bağıntı kimliği içermelidir.For asynchronous messages, if your messaging infrastructure supports adding metadata to messages, you should include the correlation ID as metadata. Aksi takdirde, bu ileti şeması bir parçası olarak ekleyin.Otherwise, include it as part of the message schema. Örneğin, dağıtılmış izleme ve Service Bus mesajlaşması ile bağıntı.For example, see Distributed tracing and correlation through Service Bus messaging.

  • Tek bir etkinliğin genel olmayan tanımlayıcısı yerine, gönderebilir bir bağıntı bağlam , çağıran-çağrılan ilişkileri gibi daha zengin bilgi içerir.Rather than a single opaque identifier, you might send a correlation context that includes richer information, such as caller-callee relationships.

  • Hizmet kafes Istio veya linkerd kullanıyorsanız, HTTP çağrıları hizmeti kafes proxy yönlendirileceğini olduğunda, bu teknolojiler otomatik olarak bağıntı üst bilgileri oluşturur.If you are using Istio or linkerd as a service mesh, these technologies automatically generate correlation headers when HTTP calls are routed through the service mesh proxies. Hizmetleri, ilgili üst bilgiler iletmek.Services should forward the relevant headers.

Dağıtılmış izleme örneğiExample of distributed tracing

Bu örnek, mikro hizmetler kümesi üzerinden dağıtılmış işlemler aşağıda verilmiştir.This example follows a distributed transaction through a set of microservices. Örnekte açıklandığı bir başvuru uygulamadan alınır burada.The example is taken from a reference implementation described here.

İnsansız hava aracı ile teslimat uygulaması

Bu senaryoda, dağıtılmış işlem aşağıdaki adımları vardır:In this scenario, the distributed transaction has the following steps:

  1. Alma hizmeti, bir Service Bus kuyruğuna bir ileti koyar.The Ingestion service puts a message on a Service Bus queue.
  2. İş akışı hizmetinin ileti kuyruğundan çeker.The Workflow service pulls the message from the queue.
  3. İş akışı hizmeti (insansız hava aracı ile Zamanlayıcı, paket ve teslim) isteği işlemek için üç arka uç hizmeti çağırır.The Workflow service calls three backend services to process the request (Drone Scheduler, Package, and Delivery).

Aşağıdaki ekran görüntüsü gösterildiği Uygulama Haritası insansız hava aracı ile teslimat uygulaması için.The following screenshot shows the application map for the Drone Delivery application. Bu harita beş mikro hizmetler içeren bir iş akışında neden genel API uç noktası çağrıları gösterir.This map shows calls to the public API endpoint that result in a workflow that involves five microservices.

Uygulama eşlemesi

Oklarla fabrikam-workflow ve fabrikam-ingestion iletileri burada gönderilen ve alınan bir Service Bus kuyruğu gösterilecek.The arrows from fabrikam-workflow and fabrikam-ingestion to a Service Bus queue show where the messages are sent and received. Hangi hizmet gönderme ve alma, diyagramdan bildiremez — yalnızca her iki hizmet Service Bus aradığınız oklar — ancak bu bilgiler ayrıntılar kullanılabilir:You can't tell from the diagram which service is sending messages and which is receiving — the arrows just show that both services are calling Service Bus — but this information is available in the details:

Uygulama eşlemesi

Her çağrı bir işlem kimliği içerdiğinden, zamanlama bilgileri ve her bir adımı HTTP çağrıları dahil olmak üzere tek bir işlemde uçtan uca adımları da görüntüleyebilirsiniz.Because every call includes an operation ID, you can also view the end-to-end steps in a single transaction, including timing information and the HTTP calls at each step. Bu tür bir işlemin görselleştirme aşağıda verilmiştir:Here is the visualization of one such transaction:

Uçtan uca işlem

Bu görselleştirme iş akışı hizmeti sıraya ve diğer arka uç Hizmetleri için iş akışı hizmeti, sıraya alma hizmetidir yer alan adımları gösterir.This visualization shows the steps from the ingestion service to the queue, from the queue to the workflow service, and from the workflow service to the other backend services. Son adım, Service Bus iletisi tamamlandı olarak işaretlemek iş akışı hizmetidir.The last step is the Workflow service marking the Service Bus message as completed.

Artık bir arka uç hizmetine çağrı başarısız olduğu durumlarda bir örnek aşağıdadır:Now here is an example when calls to a backend service were failing:

Uygulama Haritası gösteren hataları

Bu, büyük bir bölümü (%36) gösterir Dönem durdurulmasını sırasında başarısız insansız hava aracı ile Zamanlayıcı hizmeti yapılan çağrıların sorgulandı.This shows that a large fraction (36%) of calls to the Drone Scheduler service failed during the period being queried. Uçtan uca işlem görünümünde bir özel durum hizmetine bir HTTP PUT İsteği gönderirken oluştuğunu gösterir.In the end-to-end transaction view, it shows that an exception occurs when sending an HTTP PUT request to the service.

Uçtan uca işlem

Daha ayrıntılı olarak incelediğinizde özel durum "Böyle cihaz veya adres." Yuva özel durum ortaya çıkmıştırFurther drilling in, the exception turns out to be a socket exception, "No such device or address."

Fabrikam.Workflow.Service.Services.BackendServiceCallFailedException: Böyle cihaz veya adres---u003e System.Net.Http.HttpRequestException: Cihaz veya adres---u003e System.Net.Sockets.SocketException böyle: Böyle bir cihaz veya adresFabrikam.Workflow.Service.Services.BackendServiceCallFailedException: No such device or address ---u003e System.Net.Http.HttpRequestException: No such device or address ---u003e System.Net.Sockets.SocketException: No such device or address

Bu, arka uç hizmetine erişilemiyor bir ipucu verir.This is a hint that the backend service is not reachable. Bu noktada, kubectl dağıtım yapılandırmasını görüntülemek için kullanabilirsiniz.At this point, you might use kubectl to view the deployment configuration. Bu örnekte, hizmetin ölçeğini açık ana bilgisayar adı değil çözümleniyor, Kubernetes yapılandırma dosyaları bir hata nedeniyle.In this example, it turned out the service hostname was not resolving, due to an error in the Kubernetes configuration files. Makaleyi hata ayıklama Hizmetleri Kubernetes'te belgelerde bu tür bir hata tanılamaya yönelik ipuçları bulunur.The article Debug Services in the Kubernetes documentation has tips for diagnosing this sort of error.

Hataların bazı yaygın nedenleri şunlardır:Here are some common causes of errors:

  • Kod hataları.Code bugs. Bu bildirim olarak:These might manifest as:
    • Özel durumlar.Exceptions. Uygulama anlayışları'nda özel durum ayrıntıları görüntülemek için günlükleri arayın.Look in the Application Insights logs to view the exception details.
    • Kilitlenen işlemi.Process crashing. Kapsayıcı ve pod durumu ve kapsayıcı günlüklerini görüntüleme veya Application Insights izlemelerini arayın.Look at container and pod status, and view container logs or Application Insights traces.
    • HTTP 5xx hatalarıHTTP 5xx errors
  • Kaynak Tükenmesi:Resource exhaustion:
    • (HTTP 429) azaltma için bakın veya zaman aşımları isteyin.Look for throttling (HTTP 429) or request timeouts.
    • Kapsayıcı ölçümleri CPU, bellek ve disk için inceleyinExamine container metrics for CPU, memory, and disk
    • Kapsayıcı ve pod kaynak sınırları için yapılandırmaları bakın.Look at the configurations for container and pod resource limits.
  • Hizmet bulma.Service discovery. Kubernetes hizmeti yapılandırma ve bağlantı noktası eşlemelerini inceleyin.Examine the Kubernetes service configuration and port mappings.
  • API uyuşmazlığı.API mismatch. HTTP 400 hataları arayın.Look for HTTP 400 errors. API sürümü ise hangi sürümün göz çağrılıyor.If APIs are versioned, look at which version is being called.
  • Bir kapsayıcı görüntüyü çekmeyi bir hata oluştu.Error pulling a container image. Pod belirtimi, bakın.Look at the pod specification. Kümeyi kapsayıcı kayıt defterinden çektiğiniz yetkili emin olun.Also make sure the cluster is authorized to pull from the container registry.
  • RBAC sorunları.RBAC issues.

Sonraki adımlarNext steps

AKS uygulamaları izlemeyi destekleyen Azure İzleyici özellikleri hakkında daha fazla bilgi:Learn more about features in Azure Monitor that support monitoring of applications on AKS: