Mikro hizmetler tasarlama: Günlüğe kaydetme ve izlemeDesigning microservices: Logging and monitoring

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. Günlüğe kaydetme ve izleme sistemi bütünsel bir görünümünü sağlamak oldukça önemlidir.Logging and monitoring are critically important to give you a holistic view of the system.

Bir mikro hizmet mimarisinde izleme diyagramı

Bir mikro hizmet mimarisinde gerçek nedenine hata veya performans sorunlarını belirlemenize özellikle zor olabilir.In a microservices architecture, it can be especially challenging to pinpoint the exact cause of errors or performance bottlenecks. Tek bir kullanıcı işlemi birden çok hizmet yayılabilir.A single user operation might span multiple services. Hizmetleri kümesi içinde ağ g/ç sınırları karşılaşabilirsiniz.Services may hit network I/O limits inside the cluster. Hizmetler arasında çağrıları zinciri backpressure sistemde yüksek gecikme süresini veya basamaklı hataları neden olabilir.A chain of calls across services may cause backpressure in the system, resulting in high latency or cascading failures. Ayrıca, genellikle belirli bir kapsayıcı içinde çalışacağı hangi düğümün bilmiyorum.Moreover, you generally don't know which node a particular container will run in. Aynı düğümde yerleştirilen kapsayıcıları sınırlı CPU veya bellek için rekabet.Containers placed on the same node may be competing for limited CPU or memory.

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. Azure İzleyici Azure platformu üzerinde hem günlükleri ve ölçümleri toplar.Azure Monitor collects both logs and metrics across the Azure platform.

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. Ölçümler daha fazla gibi subcategorized:Metrics can be further subcategorized as follows:

  • 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ılarda Hizmetleri çalıştırırsanız, kapsayıcı düzeyinde, VM düzeyinde değil yalnızca ölçümleri toplamak gerekir.If services are run inside containers, you need to collect metrics at the container level, not just at the VM level. Kapsayıcı iş yüklerini Azure Kubernetes Service (AKS) izlemek için Azure İzleyici ' ayarlayabilirsiniz.You can set up Azure Monitor to monitor container workloads in Azure Kubernetes Service (AKS). Daha fazla bilgi için kapsayıcılara genel bakış için Azure İzleyici.For more information, see Azure Monitor for containers overview. Diğer kapsayıcı düzenleyiciler için kullanmak kapsayıcı izleme çözümü Log analytics'te.For other container orchestrators, use the Container Monitoring solution in Log Analytics.

  • 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. Kullanım Application Insights uygulama ölçümleri etkinleştirmek üzere.Use Application Insights to enable application metrics.

  • 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.

Dikkat edilmesi gerekenlerConsiderations

Makaleyi izleme ve tanılama bir uygulama izlemek için genel en iyi yöntemleri açıklar.The article Monitoring and diagnostics describes general best practices for monitoring an application. Bir mikro hizmet mimarisi bağlamında dikkat etmeniz gereken belirli bazı işlemler aşağıda verilmiştir.Here are some particular things to think about in the context of a microservices architecture.

Yapılandırma ve Yönetim.Configuration and management. Günlüğe kaydetme ve izleme için yönetilen bir hizmet kullanın veya günlüğe kaydetme ve bileşenleri olarak küme kapsayıcılarda izleme dağıtmak istiyor?Will you use a managed service for logging and monitoring, or deploy logging and monitoring components as containers inside the cluster? Bu seçeneklerin daha fazla bilgi için konudaki teknoloji seçenekleri aşağıda.For more discussion of these options, see the section Technology Options below.

Alma hızı.Ingestion rate. Hangi telemetri olayları sisteminin alabileceği aktarım hızı nedir?What is the throughput at which the system can ingest telemetry events? Bu oranı aşarsa ne olur?What happens if that rate is exceeded? Örneğin, telemetri verileri kaybolur ve bu durumda, sistem istemcileri, kısıtlama ya da alt örnekleyin verileri olabilir.For example, the system may throttle clients, in which case telemetry data is lost, or it may downsample the data. Bazen bu sorun, topladığınız veri miktarını azaltarak azaltabilirsiniz:Sometimes you can mitigate this problem by reducing the amount of data that you collect:

  • Ortalama ve standart sapma gibi istatistikleri hesaplayarak ölçümleri toplamak ve izleme sistemi için istatistiksel bu verileri gönderin.Aggregate metrics by calculating statistics, such as average and standard deviation, and send that statistical data to the monitoring system.
  • Alt örnekleyin veri — diğer bir deyişle, yalnızca bir olaylarının yüzdesini işlem.Downsample the data — that is, process only a percentage of the events.
  • Toplu veri, ağ izleme hizmeti çağrıları sayısını azaltmak için.Batch the data to reduce the number of network calls to the monitoring service.

Maliyet.Cost. Telemetri verilerini depolamak ve almak maliyeti yüksek miktarlarda özellikle yüksek olabilir.The cost of ingesting and storing telemetry data may be high, especially at high volumes. Bazı durumlarda bu uygulamayı çalıştırmanın maliyeti bile aşabilir.In some cases it could even exceed the cost of running the application. Bu durumda, telemetri hacmine yukarıda açıklanan şekilde, aşağı örnekleme, toplama veya veri azaltmak gerekebilir.In that case, you may need to reduce the volume of telemetry by aggregating, downsampling, or batching the data, as described above.

Verilerin aslına uygunluğunu.Data fidelity. Ölçümleri ne kadar doğru?How accurate are the metrics? Ortalamalar, özellikle de uygun ölçekte aykırı değerleri gizleyebilirsiniz.Averages can hide outliers, especially at scale. Ayrıca, örnekleme hızını çok düşükse verideki kullanıma pürüzsüz yapabilirsiniz.Also, if the sampling rate is too low, it can smooth out fluctuations in the data. Tüm istekleri isteği önemli bir bölümünü sürmesi aslında, daha uzun aynı uçtan uca gecikme süresi hakkında sahip görünebilir.It may appear that all requests have about the same end-to-end latency, when in fact a significant fraction of requests are taking much longer.

Gecikme süresi.Latency. Gerçek zamanlı izleme ve uyarıları etkinleştirmek için telemetri verileri hızlı bir şekilde kullanılabilir olması gerekir.To enable real-time monitoring and alerts, telemetry data should be available quickly. İzleme panosunda görünen verileri nasıl "gerçek zamanlı" mi?How "real-time" is the data that appears on the monitoring dashboard? Birkaç saniye eski?A few seconds old? Bir dakikadan?More than a minute?

Depolama alanı.Storage. Günlükleri için kümedeki kısa ömürlü depolama günlük olaylarının yazmak ve günlük dosyalarını daha kalıcı depolama için göndermeye aracıyı yapılandırmak için en verimli olabilir.For logs, it may be most efficient to write the log events to ephemeral storage in the cluster, and configure an agent to ship the log files to more persistent storage. Böylece geriye dönük analiz için kullanılabilir veri sonunda uzun vadeli depolama için taşınmasını gerektirir.Data should eventually be moved to long-term storage so that it's available for retrospective analysis. Bu veri depolama maliyeti önemli bir konu, bu nedenle bir mikro hizmet mimarisi yüksek hacimde telemetri verilerini oluşturur.A microservices architecture can generate a large volume of telemetry data, so the cost of storing that data is an important consideration. Ayrıca nasıl veri sorgulanacağı göz önünde bulundurun.Also consider how you will query the data.

Pano ve görselleştirme.Dashboard and visualization. Tüm hizmetleri, hem dış hizmetler ve küme içinde sistem bütünsel bir görünümünü elde ederim?Do you get a holistic view of the system, across all of the services, both within the cluster and external services? Birden fazla konuma telemetri verileri ve günlükleri yazıyorsanız, panoyu tümünün gösterebilir ve ilişkilendirmenize?If you are writing telemetry data and logs to more than one location, can the dashboard show all of them and correlate? En az bir izleme Panosu aşağıdaki bilgileri göstermesi gerekir:The monitoring dashboard should show at least the following information:

  • Kapasite ve büyüme için genel kaynak ayırma.Overall resource allocation for capacity and growth. Bu, kapsayıcılar, dosya sistemi ölçümleri, ağ ve çekirdek ayırma sayısını içerir.This includes the number of containers, file system metrics, network, and core allocation.
  • Kapsayıcı ölçümleri hizmet düzeyinde bağıntılı.Container metrics correlated at the service level.
  • Sistem ölçümlerini kapsayıcıları ile ilişkili.System metrics correlated with containers.
  • Hizmet hataları ve aykırı değerleri.Service errors and outliers.

Dağıtılmış izlemeDistributed tracing

Belirtildiği gibi mikro hizmetler konudaki bir güçlük hizmetler genelinde olay akışını anlamaktır.As mentioned, one challenge in microservices is understanding the flow of events across services. Tek bir işlem veya işlem çağrıları birden çok hizmet içerebilir.A single operation or 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, benzer şekilde, bu bağıntı Kimliğini ileti koyar.Similarly, 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 uygularken bazı noktalar şunlardır:Here are some considerations when implementing distributed tracing:

  • Şu anda bağıntı kimlikleri için standart bir HTTP üstbilgisi.There is currently no standard HTTP header for correlation IDs. Takımınız, bir özel üst bilgi değeri standart hale getirmek.Your team should standardize on a custom header value. Seçim, framework günlüğe kaydetme ve izleme ya da hizmet kafes, tercih ettiğiniz tarafından karar.The choice may be decided by your logging/monitoring framework 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.

  • 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.

  • Azure 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 Azure Application Insights SDK automatically injects correlation context into HTTP headers, and includes the correlation ID in Application Insights logs. Application Insights'ta yerleşik olarak bulunan bağıntı özelliklerini kullanmaya karar verirseniz, bazı hizmetler bağıntı üst bilgiler, kullanılmakta olan kitaplıklarını bağlı olarak açıkça yayılması yine de gerekebilir.If you decide to use the correlation features built into Application Insights, some services may still need to explicitly propagate the correlation headers, depending on the libraries being used. Daha fazla bilgi için Application ınsights Telemetri bağıntısı.For more information, see Telemetry correlation in Application Insights.

  • 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.

  • Nasıl günlükleri toplayacak göz önünde bulundurun.Consider how you will aggregate logs. Bağıntı kimlikleri günlüklerde içerecek şekilde nasıl takımlar arasında standart hale getirmek isteyebilirsiniz.You may want to standardize across teams on how to include correlation IDs in logs. JSON gibi yapılandırılmış veya yarı yapılandırılmış bir biçimini kullanın ve bağıntı kimliğini tutmak için ortak bir alan tanımlayınUse a structured or semi-structured format, such as JSON, and define a common field to hold the correlation ID.

Teknoloji seçenekleriTechnology options

Application Insights alır ve telemetri verilerini depolar ve analiz etme ve veri arama için araçlar sağlar azure'da yönetilen bir hizmettir.Application Insights is a managed service in Azure that ingests and stores telemetry data, and provides tools for analyzing and searching the data. Application Insights'ı kullanmak için uygulamanıza bir izleme paketi yükleyin.To use Application Insights, 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. Application Insights, yerleşik bağıntı ve bağımlılık izleme sağlar.Application Insights provides built-in correlation and dependency tracking. Sistem ölçümlerini, uygulama ölçümleri ve Azure hizmet ölçümlerini, tek bir yerden izlemenize olanak tanır.It lets you track system metrics, application metrics, and Azure service metrics, all in one place.

Veri hızı üst sınırı aşarsa, Application Insights kısıtladığını dikkat edin. Ayrıntılar için bkz Application Insights sınırlar.Be aware that Application Insights throttles 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. 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.

Ayrıca, veri hacmi üzerinden ücretlendirilir çünkü Application Insights için fiyatlandırma modeli anladığınızdan emin olun.In addition, make sure that you understand the pricing model for Application Insights, because you are charged 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. Yüksek hacimde telemetri uygulamanızı oluşturur ve örnekleme veya veri toplamayı gerçekleştirmek istemediğiniz, Application Insights uygun seçim olmayabilir.If your application generates a large volume of telemetry, and you don't wish to perform sampling or aggregation of the data, then Application Insights may not be the appropriate choice.

Application Insights gereksinimlerinizi karşılamıyorsa, popüler açık kaynak teknolojilerini kullanan bazı önerilen yaklaşımlar aşağıda verilmiştir.If Application Insights doesn't meet your requirements, here are some suggested approaches that use popular open-source technologies.

Sistem ve kapsayıcı ölçümler için bir zaman serisi veritabanına gibi ölçümleri dışa göz önünde bulundurun Prometheus veya InfluxDB kümede çalıştırılan.For system and container metrics, 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.

  • Bir Pano aracı gibi kullanın Kibana veya Grafana Görselleştirme ve veri izlemek için.Use a dashboard tool such as Kibana or Grafana to visualize and monitor the data. Pano hizmeti, küme içindeki bir kapsayıcı içinde de çalıştırabilirsiniz.The dashboard service can also run inside a container in the cluster.

Uygulama günlükleri için kullanmayı Fluentd ve Elasticsearch.For application logs, consider using Fluentd and Elasticsearch. Bir açık kaynak veri toplayıcı Fluentd olduğu ve Elasticsearch bir arama motoru davranacak şekilde optimize edilmiş bir belge veritabanıdır.Fluentd is an open source data collector, and Elasticsearch is a document database that is optimized to act as a search engine. Bu yaklaşımı kullanarak, her hizmet için günlükleri gönderir stdout ve stderr, ve Kubernetes bu akışları yerel dosya sistemine yazma.Using this approach, each service sends logs to stdout and stderr, and Kubernetes writes these streams to the local file system. Fluentd günlükleri toplar, isteğe bağlı olarak bunları ek meta verilerinden Kubernetes ile zenginleştirir ve günlüklerini Elasticsearch'e gönderir.Fluentd collects the logs, optionally enriches them with additional metadata from Kubernetes, and sends the logs to Elasticsearch. Elasticsearch için Pano oluşturma, Kibana, Grafana veya benzer bir araç kullanın.Use Kibana, Grafana, or a similar tool to create a dashboard for Elasticsearch. Bu bir Fluentd pod her düğüme atanır sağlar kümedeki bir daemonset Fluentd çalışır.Fluentd runs as a daemonset in the cluster, which ensures that one Fluentd pod is assigned to each node. Kapsayıcı günlüklerini yanı sıra kubelet günlüklerini toplamak için Fluentd yapılandırabilirsiniz.You can configure Fluentd to collect kubelet logs as well as container logs. Özellikle, birden fazla hizmeti aynı düğümde çalışırken yüksek hacimlerinde günlükleri yerel dosya sistemine yazma bir performans sorununun duruma gelebilir.At high volumes, writing logs to the local file system could become a performance bottleneck, especially when multiple services are running on the same node. Üretimde disk gecikme süresi ve dosya sistemi kullanımını izleyin.Monitor disk latency and file system utilization in production.

Hizmetler ek kitaplık bağımlılıkları gerektirmez Fluentd günlükleri için Elasticsearch ile kullanmanın avantajlarından biri.One advantage of using Fluentd with Elasticsearch for logs is that services do not require any additional library dependencies. Her hizmet için yalnızca Yazar stdout ve stderrve günlükleri dışarı aktarma Elasticsearch Fluentd tutamaçlarını.Each service just writes to stdout and stderr, and Fluentd handles exporting the logs into Elasticsearch. Ayrıca, hizmetleri yazma takımlar günlük altyapının nasıl yapılandırılacağını anlamak gerek yoktur.Also, the teams writing services don't need to understand how to configure the logging infrastructure. Böylece, trafiği işlemeye ölçeklenebilir bir güçlük bir üretim dağıtımı için Elasticsearch kümesi yapılandırmaktır.One challenge is to configure the Elasticsearch cluster for a production deployment, so that it scales to handle your traffic.

Günlükler Operations Management Suite (OMS) Log Analytics'e gönderme başka bir seçenektir.Another option is to send logs to Operations Management Suite (OMS) Log Analytics. [Log Analytics] log-analytics toplanan günlük veri merkezi bir depoya hizmet ve veri, uygulamanızın kullandığı diğer Azure hizmetlerinden gelen da birleştirebilir.The Log Analytics service collects log data into a central repository, and can also consolidate data from other Azure services that your application uses. Daha fazla bilgi için Microsoft Operations Management Suite (OMS) ile bir Azure Container Service kümesini izleme.For more information, see Monitor an Azure Container Service cluster with Microsoft Operations Management Suite (OMS).

Örnek: Bağıntı kimlikleri ile günlüğe kaydetmeExample: Logging with correlation IDs

Bu bölümde açıklanan noktaları bazılarını göstermek için paket hizmet günlüğü nasıl uyguladığını genişletilmiş örneği İşte.To illustrate some of the points discussed in this chapter, here is an extended example of how the Package service implements logging. Paket hizmeti kullanan TypeScript ile yazılmıştır Koa için Node.js web çerçevesi.The Package service was written in TypeScript and uses the Koa web framework for Node.js. Aralarından seçim yapabileceğiniz birkaç Node.js günlük kitaplıkları vardır.There are several Node.js logging libraries to choose from. Biz çekilen Winston, biz test edildiğinde müşterilerimizin performans gereksinimlerini karşılayan bir popüler günlük kitaplığı.We picked Winston, a popular logging library that met our performance requirements when we tested it.

Bir soyut tanımladığımız uygulama ayrıntılarını kapsüllemek için ILogger arabirimi:To encapsulate the implementation details, we defined an abstract ILogger interface:

export interface ILogger {
    log(level: string, msg: string, meta?: any)
    debug(msg: string, meta?: any)
    info(msg: string, meta?: any)
    warn(msg: string, meta?: any)
    error(msg: string, meta?: any)
}

İşte bir ILogger Winston kitaplığı kaydırılan bir uygulama.Here is an ILogger implementation that wraps the Winston library. Bağıntı kimliği bir oluşturucu parametresi olarak alan ve kimliği her bir günlük iletisine ekler.It takes the correlation ID as a constructor parameter, and injects the ID into every log message.

class WinstonLogger implements ILogger {
    constructor(private correlationId: string) {}
    log(level: string, msg: string, payload?: any) {
        var meta : any = {};
        if (payload) { meta.payload = payload };
        if (this.correlationId) { meta.correlationId = this.correlationId }
        winston.log(level, msg, meta)
    }
  
    info(msg: string, payload?: any) {
        this.log('info', msg, payload);
    }
    debug(msg: string, payload?: any) {
        this.log('debug', msg, payload);
    }
    warn(msg: string, payload?: any) {
        this.log('warn', msg, payload);
    }
    error(msg: string, payload?: any) {
        this.log('error', msg, payload);
    }
}

Paket hizmetinin HTTP isteğinden bağıntı Kimliğinin ayıklanması gerekir.The Package service needs to extract the correlation ID from the HTTP request. Linkerd kullanıyorsanız, örneğin, bağıntı kimliği bulunur l5d-ctx-trace başlığı.For example, if you're using linkerd, the correlation ID is found in the l5d-ctx-trace header. Koa HTTP isteği ardışık düzen işleme isteği aracılığıyla iletilir bir bağlam nesnesi depolanır.In Koa, the HTTP request is stored in a Context object that gets passed through the request processing pipeline. Biz bağlamdan bağıntı Kimliğini alın ve Günlükçü başlatmak için bir ara yazılım işlevi tanımlayabilirsiniz.We can define a middleware function to get the correlation ID from the Context and initialize the logger. (Bir ara yazılım işlevde Koa yürütülen her istek için yalnızca bir işlevdir.)(A middleware function in Koa is simply a function that gets executed for each request.)

export type CorrelationIdFn = (ctx: Context) => string;

export function logger(level: string, getCorrelationId: CorrelationIdFn) {
    winston.configure({
        level: level,
        transports: [new (winston.transports.Console)()]
        });
    return async function(ctx: any, next: any) {
        ctx.state.logger = new WinstonLogger(getCorrelationId(ctx));
        await next();
    }
}

Bu ara yazılım, arayan tarafından tanımlanan bir işlev çağırır getCorrelationId, bağıntı kimliğini almak içinThis middleware invokes a caller-defined function, getCorrelationId, to get the correlation ID. Günlükçünün bir örneğini oluşturur ve içinde stashes ctx.state, içinde Koa ardışık düzeninden bilgi geçirmek için kullanılan bir anahtar-değer sözlük olduğu.Then it creates an instance of the logger and stashes it inside ctx.state, which is a key-value dictionary used in Koa to pass information through the pipeline.

Günlükçü ara yazılım ardışık düzenine başlangıçta eklenir:The logger middleware is added to the pipeline on startup:

app.use(logger(Settings.logLevel(), function (ctx) {
    return ctx.headers[Settings.correlationHeader()];  
}));

Her şeyi yapılandırıldıktan sonra günlük kaydı deyimleri için kod eklemek kolay bir işlemdir.Once everything is configured, it's easy to add logging statements to the code. Örneğin, bir paketi görünen yöntemin aşağıdadır.For example, here is the method that looks up a package. Bu iki çağrılar ILogger.info yöntemi.It makes two calls to the ILogger.info method.

async getById(ctx: any, next: any) {
  var logger : ILogger = ctx.state.logger;
  var packageId = ctx.params.packageId;
  logger.info('Entering getById, packageId = %s', packageId);

  await next();

  let pkg = await this.repository.findPackage(ctx.params.packageId)

  if (pkg == null) {
    logger.info(`getById: %s not found`, packageId);
    ctx.response.status= 404;
    return;
  }

  ctx.response.status = 200;
  ctx.response.body = this.mapPackageDbToApi(pkg);
}

Ara yazılım işlevi tarafından otomatik olarak yapıldığı için bağıntı Kimliğini günlük deyimlerinde eklemek gerekmez.We don't need to include the correlation ID in the logging statements, because that's done automatically by the middleware function. Bu günlüğe kaydetme koduna daha temiz olmasını sağlar ve bir geliştirici, bağıntı kimliği eklemeyi mi unuttunuz olasılığını azaltırThis makes the logging code cleaner, and reduces the chance that a developer will forget to include the correlation ID. Ve tüm günlük kaydı deyimleri Özet kullandığından ILogger arabirimi olacağını Günlükçü uygulama daha sonra değiştirmek kolaydır.And because all of the logging statements use the abstract ILogger interface, it would be easy to replace the logger implementation later.