System.Net kitaplıklarında dağıtılmış izleme

Dağıtılmış izleme, mühendislerin uygulamalardaki hataları ve performans sorunlarını, özellikle de birden çok makineye veya işleme dağıtılmış olanları yerelleştirmelerine yardımcı olan bir tanılama tekniğidir. Bu teknik, farklı bileşenler tarafından yapılan işleri birbirine bağlayarak ve eşzamanlı istekler için uygulamanın yaptığı diğer işlerden ayırarak bir uygulama aracılığıyla istekleri izler. Örneğin, tipik bir web hizmetine yönelik bir istek önce bir yük dengeleyici tarafından alınıp ardından bir web sunucusu işlemine iletilebilir ve bu işlem veritabanına birkaç sorgu yapar. Dağıtılmış izleme, mühendislerin bu adımlardan herhangi birinin başarısız olup olmadığını ve her adımın ne kadar sürdüğünü ayırt etmesini sağlar. Her adım çalıştırıldığında oluşturulan iletileri de günlüğe kaydedebilir.

.NET'teki izleme sistemi OpenTelemetry (OTel) ile çalışacak şekilde tasarlanmıştır ve verileri izleme sistemlerine aktarmak için OTel kullanır. .NET'te izleme, System.Diagnostics API'leri kullanılarak uygulanır ve bir iş birimi System.Diagnostics.Activity sınıfı ile temsil edilir; ayrıca bu, OTel yayılmasına yanikapsamına karşılık gelir. OpenTelemetry, anlam kuralları olarak bilinen öznitelikleriyle (etiketler) birlikte aralıklar (etkinlikler) için sektör genelinde bir standart adlandırma şeması tanımlar. .NET telemetrisi, mümkün olan her yerde mevcut anlamsal kuralları kullanır.

Not

terimleri ve etkinlik bu makalede eş anlamlıdır. .NET kodu bağlamında bir System.Diagnostics.Activity örneğine başvurur. OTel span'ı System.Span<T>ile karıştırmayın.

Bahşiş

Tüm yerleşik etkinliklerin etiketleri/öznitelikleriyle birlikte kapsamlı bir listesi için bkz. .NET'te yerleşik etkinlikler.

Enstrümantasyon

İzlemeleri yaymak için, System.Net kitaplıkları, gerçekleştirilen işi izlemek için nesneler oluşturan yerleşik ActivitySource kaynaklarıyla Activity izlenir. Etkinlikler yalnızca ActivitySourceabonesi olan dinleyiciler varsa oluşturulur.

.NET sürümleriyle birlikte yerleşik araçlar gelişti.

.NET 8 ve önceki sürümlerde araç gereç kullanımı, boş bir HTTP istemci isteği etkinliğinin oluşturulmasıyla sınırlıdır. Kullanıcıların, etkinliği kullanışlı izler yaymak için gereken bilgilerle (örneğin, etiketler) doldurmak amacıyla OpenTelemetry.Instrumentation.Http kitaplığına güvenmeleri gerektiği anlamına gelir.
.NET 9, HTTP istemci isteği etkinliğinde OTel HTTP istemci semantik kurallarına göre adı, durumu, özel durum bilgilerini ve en önemli etiketleri yayarak izlemenin genişletilmesine neden oldu. Bu, OpenTelemetry.Instrumentation.Http gibi daha gelişmiş özellikler gerekmediği sürece .NET 9+ için bağımlılığının atlanabileceği anlamına gelir.
.NET 9 ayrıca bağlantı sorunlarını tanılamayı desteklemek için kitaplıklarına yeni etkinlikler ekleyerek System.Netkullanıma sunulmuştur.

System.Net izlemelerini toplama

en düşük düzeydeizleme koleksiyonu, kullanıcı tanımlı mantık içeren AddActivityListener nesneleri kaydeden ActivityListener yöntemi aracılığıyla desteklenir.

Ancak bir uygulama geliştiricisi olarak, izlemeleri toplamak, dışarı aktarmak ve izlemek için OpenTelemetry .NET SDK tarafından sağlanan özellikleri temel alan zengin ekosisteme güvenmeyi tercih edebilirsiniz.

OTel ile iz toplama hakkında temel bilgi edinmek için OpenTelemetry kullanarak izleri toplama kılavuzumuzabakın.
üretim zamanı izleme toplama ve izleme için OpenTelemetry'yi Prometheus, Grafana ve Jaeger veya Azure İzleyici ve Application Insightsile kullanabilirsiniz. Ancak bu araçlar oldukça karmaşıktır ve geliştirme zamanında kullanılması zor olabilir.
Geliştirme zamanı izleme toplama ve izleme için, uygulamanızda dağıtılmış izlemeyi başlatmak ve sorunları yerel olarak tanılamak için basit ama genişletilebilir bir yol sağlayan Aspire'i kullanmanızı öneririz.
Aspire düzenlemesi olmadan Aspire Service Defaults projesini yeniden kullanmak da mümkündür. Bu, ASP.NET projelerinizde OpenTelemetry izleme ve ölçümlerini tanıtmak ve yapılandırmak için kullanışlı bir yoldur.

Aspire ile izleri topla

ASP.NET uygulamalarında izlemeleri ve ölçümleri toplamanın basit bir yolu Aspire kullanmaktır. Aspire, dağıtılmış uygulamalar oluşturmayı ve bunlarla çalışmayı kolaylaştırmak için .NET'e yönelik bir uzantı kümesidir. Aspire kullanmanın avantajlarından biri, telemetrinin .NET için OpenTelemetry kitaplıkları kullanılarak yerleşik olmasıdır.

Aspire için varsayılan proje şablonları bir ServiceDefaults proje içerir. Aspire çözümündeki her hizmetin Service Defaults projesine bir başvurusu vardır. Hizmetler bunu OTel'i ayarlamak ve yapılandırmak için kullanır.

Service Defaults proje şablonu OTel SDK, ASP.NET, HttpClient ve Runtime Instrumentation paketlerini içerir. Bu enstrümantasyon bileşenleri Extensions.cs dosyasında yapılandırılır. Aspire Panosu'nda telemetri görselleştirmesini desteklemek için, Hizmet Varsayılanları projesi varsayılan olarak OTLP verme işlemini de içerir.

Aspire Panosu, telemetri gözlemini yerel hata ayıklama döngüsüne getirerek geliştiricilerin uygulamaların telemetri ürettiğinden emin olmasını sağlayacak şekilde tasarlanmıştır. Telemetri görselleştirmesi, bu uygulamaları yerel olarak tanılamaya da yardımcı olur. Hizmetler arasındaki çağrıları gözlemleyebilmek, üretimdeki hata ayıklama zamanında olduğu kadar yararlıdır. Project'i Visual Studio'dan veya AppHost projeyi komut satırından dotnet runAppHost aldığınızda Aspire panosu otomatik olarak başlatılır.

Aspire Panosu

Aspire hakkında daha fazla bilgi için bkz:

Aspire'a Genel Bakış
Aspire 'de Telemetri
Aspire Gösterge Paneli

Aspire Orchestration olmadan Hizmet Varsayılanları projesini yeniden kullanma

Aspire Service Defaults projesi, düzenleme için AppHost gibi Aspire'in geri kalanını kullanmasa bile ASP.NET projeler için OTel'i yapılandırmak için kolay bir yol sağlar. Hizmet Varsayılanları projesi Visual Studio veya dotnet newaracılığıyla bir proje şablonu olarak kullanılabilir. OTel'i yapılandırır ve OTLP ihracatçısını kurar. Ardından OTel ortam değişkenlerini kullanarak OTLP uç noktasını telemetri gönderecek şekilde yapılandırabilir ve uygulamanın kaynak özelliklerini sağlayabilirsiniz.

ServiceDefaults'ı Aspire dışında kullanma adımları şunlardır:

Visual Studio'da Yeni Proje Ekle'yi kullanarak çözüme ServiceDefaults projesini ekleyin veya dotnet newkullanın:
```
dotnet new aspire-servicedefaults --output ServiceDefaults
```
ASP.NET uygulamanızdan ServiceDefaults projesine başvurun. Visual Studio'da >Proje Referansı Ekle'ü seçin ve ardından ServiceDefaults projesini seçin.

Uygulama oluşturucu başlatmanızın bir parçası olarak OpenTelemetry kurulum işlevini ConfigureOpenTelemetry() çağırın.

var builder = WebApplication.CreateBuilder(args)
builder.ConfigureOpenTelemetry(); // Extension method from ServiceDefaults.
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();

Ayrıntılı rehber için bkz. Örnek: OTLP ve tek başına Aspire Gösterge Tablosu ile OpenTelemetry kullanma.

Deneysel bağlantı izleme

HttpClient sorunlarını veya performans sorunlarını giderirken, HTTP istekleri gönderirken zamanın nereye harcandığını görmek çok önemli olabilir. HTTP bağlantısı kurulumu esnasında sorun genellikle, DNS araması, TCP bağlantısı ve TLS el sıkışmasını içeren işlemler sırasında meydana gelir.

.NET 9, bağlantı kuruluşunun DNS, TCP ve TLS aşamalarını temsil eden üç alt yayılım içeren bir HTTP connection setup span ekleyen deneysel bağlantı izleme özelliğini tanıttı. Bağlantı izlemenin HTTP bölümü SocketsHttpHandleriçinde uygulanır, yani etkinlik modelinin temel alınan bağlantı havuzu davranışına saygı duyması gerekir.

Not

SocketsHttpHandler'de bağlantıların ve isteklerin bağımsız yaşam döngüleri vardır. Kümelenmiş bağlantı uzun süre varlığını sürdürebilir ve birçok isteğe hizmet edebilir. İstekte bulunurken, bağlantı havuzunda hemen kullanılabilir bir bağlantı yoksa, istek kullanılabilir bir bağlantıyı beklemek için istek kuyruğuna eklenir. Bekleyen taleplerle bağlantılar arasında doğrudan bir ilişki yoktur. Başka bir bağlantı kullanıma sunulduğunda bağlantı işlemi başlatılmış olabilir ve bu durumda serbest bağlantı kullanılır. Sonuç olarak, HTTP connection setup yayılma alanı HTTP client request aralığının alt öğesi olarak modellenmez; bunun yerine span bağlantıları kullanılır.

.NET 9, ayrıntılı bağlantı bilgilerinin toplanmasına olanak tanımak için aşağıdaki kapsamları kullanıma sunar:

Ad	ActivitySource	Açıklama
`HTTP wait_for_connection`	`Experimental.System.Net.Http.Connections`	İsteğin istek kuyruğunda kullanılabilir bir bağlantı için beklediği zaman aralığını temsil eden `HTTP client request` aralığının alt yayılma alanı.
`HTTP connection_setup`	`Experimental.System.Net.Http.Connections`	HTTP bağlantısının kurulmasını temsil eder. Kendi `TraceId`sahip ayrı bir izleme kök aralığı. `HTTP client request` yayılma alanları `HTTP connection_setup`bağlantıları içerebilir.
`DNS lookup`	`Experimental.System.Net.NameResolution`	Dns sınıfı tarafından gerçekleştirilen DNS araması.
`socket connect`	`Experimental.System.Net.Sockets`	Socket bağlantısı kurulması.
`TLS handshake`	`Experimental.System.Net.Security`	SslStreamtarafından gerçekleştirilen TLS istemcisi veya sunucu el sıkışması.

Not

Üretimde ne kadar iyi çalıştıkları hakkında daha fazla bilgi edindikçe, ActivitySourceön ekiyle başlayan ilgili Experimental adları gelecekteki sürümlerde değişebilir.

Bu aralıklar, yüksek iş yüklerine sahip üretim senaryolarında 7/24 kullanım için çok ayrıntılıdır; gürültülü olur ve normalde bu izleme düzeyine ihtiyaç duyulmaz. Ancak, bağlantı sorunlarını tanılamaya veya ağ ve bağlantı gecikme süresinin hizmetlerinizi nasıl etkilediğini daha iyi anlamaya çalışıyorsanız, bunlar başka yollarla toplanması zor içgörüler sağlar.

Experimental.System.Net.Http.Connections ActivitySource etkinleştirildiğinde, HTTP client requestHTTP connection_setupistek sunan bağlantıya karşılık gelen yayılma alanının bağlantısını içerir. HTTP bağlantısı uzun ömürlü olabileceğinden, bu durum istek etkinliklerinin her birinden bağlantı aralığına birçok bağlantı yapılmasına neden olabilir. Bazı APM izleme araçları, görünümlerini oluşturmak için aralıklar arasındaki bağlantıları agresif bir şekilde izler ve bu nedenle bu aralığı dahil etmek, araçlar çok sayıda bağlantıyı hesaba katacak şekilde tasarlanmadığında sorunlara sebep olabilir.

Aşağıdaki diyagramda span'ların davranışı ve bunların ilişkisi gösterilmektedir:

İzlenecek yol: .NET 9'da deneysel bağlantı izlemeyi kullanma

Bu kılavuzda bağlantı izlemeyi göstermek için .NET 9 Aspire Starter Uygulaması kullanılır, ancak diğer izleme araçlarıyla da kolayca ayarlanabilir. Önemli adım ActivitySources'un etkinleştirilmesidir.

kullanarak dotnet new oluşturun:

dotnet new aspire-starter-9 --output ConnectionTracingDemo

Veya Visual Studio'da:

Visual Studio'da Aspire 9 Starter Uygulaması oluşturma

Extensions.cs projesinde ServiceDefaults açın ve izleme yapılandırması geri çağırmasında bağlantı için ActivitySources'u ekleyen ConfigureOpenTelemetry yöntemini düzenleyin:

.WithTracing(tracing =>
{
    tracing.AddAspNetCoreInstrumentation()
        // Instead of using .AddHttpClientInstrumentation()
        // .NET 9 allows to add the ActivitySources directly.
        .AddSource("System.Net.Http")
        // Add the experimental connection tracking ActivitySources using a wildcard.
        .AddSource("Experimental.System.Net.*");
});

Çözümü başlatın. Bu, Aspire Panosu'nu açmalıdır.
webfrontend uygulamasının Hava Durumu sayfasına gidin ve HttpClient'ye yönelik bir apiservice isteği oluşturun.
Kontrol Paneline dönün ve İzlemeler sayfasına gidin. webfrontend: GET /weather izini açın.

Aspire Panosunda HttpClient Spans

Bağlantı enstrümantasyonu etkinken HTTP istekleri yapıldığında, istemci istek kapsamlarında aşağıdaki değişiklikleri görmelisiniz.

Bağlantı kurulması gerekiyorsa veya uygulama bağlantı havuzundan bağlantı bekliyorsa, bağlantının yapılmasını bekleme gecikmesini temsil eden ek bir HTTP wait_for_connection aralığı gösterilir. Bu, kodda yapılan HttpClient isteği arasındaki gecikmeleri ve isteğin işlenmesinin gerçekten ne zaman başladığını anlamanıza yardımcı olur. Önceki resimde:
- Seçilen yayılma alanı HttpClient isteğidir.
- Aşağıdaki süre, isteğin bağlantı kurulmasını beklerken harcadığı zamanı temsil eder.
- Sarı renkteki son yayılma alanı, isteği işleyen hedeftendir.
HttpClient aralığı, istek tarafından kullanılan HTTP bağlantısını oluşturma etkinliğini temsil eden HTTP connection_setup aralığına bir bağlantıya sahip olacak.

Aspire Panosu'nda bağlantı kurulumConnection setup spans in Aspire DashboardConnection setup spans in Aspire Dashboard

Daha öncebelirtildiği gibi, HTTP connection_setup span, yaşam süresi her istemci isteğinden bağımsız olan ve kendi TraceId'si bulunan ayrı bir alandır. Bu bölüm genellikle DNS lookup, (TCP) socket connectve TLS client handshakealt bölümlerini içerir.

Zenginleşme

Bazı durumlarda, mevcut System.Net izleme işlevselliğini artırmak gerekir. Bu genellikle yerleşik etkinliklere ek etiketler/öznitelikler eklemek anlamına gelir. Buna zenginleştirmeadı verilir.

OpenTelemetry izleme kitaplığındaki Zenginleştirme API'si

HTTP istemci isteği etkinliğine ek etiketler/öznitelikler eklemek için en basit yaklaşım, OpenTelemetry HttpClient ve HttpWebRequest izleme kitaplığının HttpClient zenginleştirme API'lerini kullanmaktır. Bunun için OpenTelemetry.Instrumentation.Http paketine bağımlılık yapılması gerekir.

El ile zenginleştirme

HTTP client request etkinliğinin zenginleştirilmesini el ile uygulamak mümkündür. Bunun için, etkinlik bitmeden önce talep faaliyetinin kapsamında çalışmakta olan kodda Activity.Current'a erişmeniz gerekir. Bu, IObserver<DiagnosticListener>'ı uygulayarak ve ağ etkinliği yaşandığında bildirim almak için AllListeners'e abone olarak yapılabilir. Aslında, OpenTelemetry HttpClient ve HttpWebRequest izleme kitaplığı bu şekilde uygulanır. Kod örneği için DiagnosticSourceSubscriber.cs abonelik koduna ve bildirimlerin devredildiği HttpHandlerDiagnosticListener.cs temel alınan uygulamaya bakın.

Daha fazla izleme mi gerekiyor?

İzleme yoluyla kullanıma sunulacak diğer yararlı bilgiler için önerileriniz varsa, bir dotnet/runtime sorunu oluşturun.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2025-01-31