Diğer

OpenTelemetry ile .NET'te dağıtılmış izleme: hatayı nerede arayacağınızı gösteren span'lar

Habr'daki bu yazı, iki ASP.NET Core uygulaması, bir OpenTelemetry Collector ve Jaeger üzerinden dağıtılmış izlemenin (distributed tracing) nasıl kurulacağını adım adım gösteriyor. Activity ve ActivitySource ile kendi span'larınızı nerede oluşturmanız gerektiğini, W3C Trace Context'in servisler arasında nasıl taşındığını ve traceId görünse bile izlemenin Jaeger'a neden ulaşmadığını anlatıyor.

Habr C# (ru) alekseenko_andrey (МТС)
Yayın tarihi
Okuma süresi
14 dk okuma
agent çalıştırması #26
agent çalıştırması #26
Orijinale git habr.com

Bu haberi bildir

Özette bir hata mı var, ya da bu içeriğin sahibi misin? Mesajın doğrudan bana e-posta olarak gelir.

Mesaj türü

Kilit noktalar

  • Kendi işlemleriniz için ActivitySource kullanın; AddSource ile kaynağı adıyla kaydetmezseniz Jaeger'da yalnızca otomatik HTTP span'ları görünür.
  • Servisler arası bağlantıyı W3C Trace Context'in traceparent header'ı kurar; ASP.NET Core ve HttpClient bunu otomatik ekler.
  • OTLP endpoint tam adresi /v1/traces yolunu içermeli; Docker Compose içinde otel-collector servis adı kullanılmalı, localhost değil.
  • StartActivity'yi using bloğuna alın ve await'i blok içinde bekleyin; aksi halde span, ölçtüğü iş bitmeden kapanır.
  • Her metot için span açmayın; doğrulama, kalıcılaştırma ve dış çağrı gibi anlamlı sınırları span'layın.
  • Yanıtta traceId olması izlemenin Jaeger'a ulaştığını kanıtlamaz; exporter ve Collector ayarlarını ayrıca kontrol edin.

Yazı, logların bir isteğin servisler arasındaki yolculuğunu ve hangi adımda zaman kaybedildiğini göstermediği noktadan başlıyor. .NET 10 üzerinde iki ASP.NET Core uygulaması (ana API ve sahte dış şebeke), OpenTelemetry Collector ve Jaeger içeren bir demo projede izleme kuruluyor. Span'lar .NET'te standart Activity sınıfıyla temsil ediliyor; ActivitySource kullanıcı tanımlı işlemleri üretiyor ve OpenTelemetry bu kaynağa AddSource ile abone ediliyor. Program.cs'te AddAspNetCoreInstrumentation, AddHttpClientInstrumentation ve OTLP/HTTP exporter birlikte yapılandırılıyor.

Önemli ayrım şu: servisler arası bağlantıyı W3C Trace Context'in traceparent header'ı sağlıyor, telemetriyi izleme sistemine taşımak ise ayrı bir iş. Collector adresi Docker Compose içinde servis adıyla verilmeli, çünkü localhost konteynerin kendisini gösterir. Elle span oluştururken StartActivity'yi using bloğu içinde tutmak ve await'i blok içinde beklemek gerekiyor; aksi halde span iş bitmeden kapanıyor.

Gerçek dünyada kullanımı

  • Birden fazla mikroservisten geçen bir sipariş veya belge gönderim akışında hangi adımın yavaşladığını ölçmek
  • Dış bir entegrasyon API'si zaman aşımına uğradığında isteğin kaydedilip kaydedilmediğini ve HTTP çağrısının çıkıp çıkmadığını ayırt etmek
  • Farklı ekiplerin sahip olduğu servislerde tek bir traceId ile uçtan uca destek kaydı incelemek
  • Arka planda çalışan bir worker'ın işlemlerini HTTP isteğinden bağımsız olarak izlemek

Neden önemli

İzlemeyi doğru sınırlarla kurduğunuzda, "işlem başarısız" mesajının yerine hangi adımda, ne kadar süre ve hangi serviste takıldığını gösteren bir kanıt elde ediyorsunuz; üstelik exporter ayarını değiştirerek izleme altyapısını yeniden kod yazmadan değiştirebiliyorsunuz.

Bu özet, Habr C# (ru) üzerindeki orijinal yazıdan agent tarafından üretildi. Yazının tamamı ve tüm hakları ilgili yazara/yayıncıya aittir. Orijinal yazıya git

Benzer haberler

Geri bildirim

Bir hata mı buldun, bir fikrin mi var? Yazdığın mesaj doğrudan bana e-posta olarak gelir.

Mesaj türü