Elosztott nyomkövetés System.Net tárakban

Elosztott nyomkövetési egy diagnosztikai módszer, amely segít a mérnököknek az alkalmazások hibáinak és teljesítményproblémáinak honosításában, különösen azokban, amelyek több gépen vagy folyamaton keresztül vannak elosztva. Ez a technika egy alkalmazáson keresztül követi nyomon a kérelmeket úgy, hogy összekapcsolja a különböző összetevők által végzett munkát, és elválasztja azokat az alkalmazás által az egyidejű kérések során végzett más munkától. Előfordulhat például, hogy egy tipikus webszolgáltatáshoz érkező kérést először egy terheléselosztó fogadja, majd továbbítja egy webkiszolgálói folyamatnak, amely ezután több lekérdezést küld egy adatbázisba. Az elosztott nyomkövetés lehetővé teszi a mérnökök számára, hogy különbséget tegyenek a lépések sikertelensége és az egyes lépések hossza között. Emellett naplózhatja az egyes lépések által létrehozott üzeneteket is a futtatás során.

A .NET nyomkövetési rendszere az OpenTelemetria (OTel) használatához készült, és az OTel használatával exportálja az adatokat a figyelési rendszerekbe. A .NET-ben a nyomkövetés a System.Diagnostics API-k használatával valósul meg, ahol a munkaegységet az System.Diagnostics.Activity osztály jelöli, amely egy OTel-. Az OpenTelemetry egy iparági szintű szabványos elnevezési sémát határoz meg a spanok (tevékenységek) és azok attribútumai (címkék) számára, amelyeket szemantikai konvencióknakneveznek. A .NET-telemetria a meglévő szemantikai konvenciókat használja, ahol csak lehetséges.

Jegyzet

Ebben a cikkben a és tevékenység kifejezések szinonimák. A .NET-kód kontextusában egy System.Diagnostics.Activity példányra hivatkoznak. Ne keverje össze az OTel-tartományt System.Span<T>.

Borravaló

Az összes beépített tevékenység és a hozzájuk tartozó címkék/attribútumok átfogó listáját a .NET beépített tevékenységeinekcímű témakörben találja.

Hangszerelés

A nyomkövetések kibocsátásához a System.Net kódtárak beépített forrásokkal ActivitySource, amelyek Activity objektumokat hoznak létre az elvégzett munka nyomon követéséhez. A tevékenységek csak akkor jönnek létre, ha ActivitySource-ra feliratkozott figyelők vannak.

A beépített műszerezés a .NET-verziókkal fejlődött.

• A .NET 8 és korábbi verzióiban a rendszerállapot egy üres HTTP-ügyfélkérési tevékenységlétrehozására korlátozódik. Ez azt jelenti, hogy a felhasználóknak a OpenTelemetry.Instrumentation.Http könyvtárra kell támaszkodniuk ahhoz, hogy a tevékenység hasznos nyomkövetési adatokkal (például címkékkel) legyen feltöltve.
• A .NET 9 kiterjesztette az instrumentációt azáltal, hogy kibocsátja a nevet, az állapotot, a kivételinformációt és a legfontosabb címkéket az OTel HTTP-ügyfél szemantikai konvenciók szerinti HTTP-ügyfélkérési tevékenységnél. Ez azt jelenti, hogy a .NET 9+-on a OpenTelemetry.Instrumentation.Http függőség elhagyható, kivéve, ha speciálisabb funkciókra, például bővítési van szükség.
• A .NET 9 kísérleti kapcsolatkövetésiis bevezetett, új tevékenységeket adva a System.Net kódtárakban a csatlakozási problémák diagnosztizálásához.

System.Net nyomkövetések gyűjtése

A legalacsonyabb szintűa nyomkövetési gyűjtemény a AddActivityListener metódussal támogatott, amely a felhasználó által definiált logikát tartalmazó ActivityListener objektumokat regisztrálja.

Alkalmazásfejlesztőként azonban valószínűleg inkább az OpenTelemetry .NET SDK által biztosított funkciókra épülő gazdag ökoszisztémára támaszkodni a nyomkövetések gyűjtéséhez, exportálásához és monitorozásához.

• Ha alapvető ismereteket szeretne kapni a nyomkövetési gyűjtésről az OTel használatával, tekintse meg nyomkövetések OpenTelemetria-használatával történő gyűjtéséről szóló útmutatónkat.
• Az éles üzemidő nyomkövetése és monitorozása során használhatja az OpenTelemetry-t a Prometheus-szal, Grafanával és Jaegerrel vagy az Azure Monitorral és az Application Insightsszal. Ezek az eszközök azonban meglehetősen összetettek, és nem feltétlenül használhatók fejlesztési időben.
• A fejlesztési idő szerinti nyomkövetés gyűjtéséhez és monitorozásához az Aspire használatát javasoljuk, amely egyszerű, de bővíthető módot kínál az elosztott nyomkövetés elindításához az alkalmazásban, és a problémák helyi diagnosztizálásához.
• Az Aspire Service Defaults projektet az Aspire vezénylése nélkül is újra felhasználhatja. Ez hasznos módszer az OpenTelemetry nyomkövetés és metrikák ASP.NET projektekben való bevezetésére és konfigurálására.

Nyomkövetések gyűjtése az Aspire használatával

A nyomkövetések és metrikák ASP.NET alkalmazásokban való gyűjtésének egyszerű módja az Aspire használata. Az Aspire a .NET-bővítmények készlete, amelyek megkönnyítik az elosztott alkalmazások létrehozását és használatát. Az Aspire használatának egyik előnye, hogy a telemetria a .NET OpenTelemetry-kódtárainak használatával van beépítve.

Az Aspire alapértelmezett projektsablonjai egy ServiceDefaults projektet tartalmaznak. Az Aspire-megoldás minden szolgáltatása hivatkozik a Service Defaults projektre. A szolgáltatások az OTel beállítására és konfigurálására használják.

A Service Defaults projektsablon tartalmazza az OTel SDK, ASP.NET, HttpClient és Runtime Instrumentation csomagokat. Ezek az instrumentációs összetevők a Extensions.cs fájlban vannak konfigurálva. Az Aspire-irányítópult telemetriai vizualizációjának támogatásához a Service Defaults projekt alapértelmezés szerint az OTLP-exportőrt is tartalmazza.

Az Aspire Irányítópult úgy lett kialakítva, hogy telemetria-megfigyelést biztosítson a helyi hibakeresési ciklushoz, ami lehetővé teszi a fejlesztők számára, hogy az alkalmazások telemetriai adatokat hozzanak létre. A telemetriai vizualizáció segít az alkalmazások helyi diagnosztizálásában is. A szolgáltatások közötti hívások megfigyelése ugyanolyan hasznos a hibakeresés során, mint az éles környezetben is. Az Aspire irányítópult automatikusan elindul, amikor megnyomja az F5 billentyűt a Visual Studio-ban, vagy amikor a AppHost projektet parancssorból indítja el.

További információ az Aspire-ről:

• Aspire áttekintése
• Telemetria az Aspire-ben
• Aspire Irányítópult

A Service Defaults projekt újrafelhasználása Aspire Orchestration nélkül

Az Aspire Service Defaults projekt egyszerű módot kínál az OTel konfigurálására ASP.NET projektekhez, még akkor is, ha nem használja az Aspire többi részét, például az AppHostot vezénylésre. A Service Defaults projekt projektsablonként érhető el a Visual Studióban vagy dotnet new. Konfigurálja az OTelt, és beállítja az OTLP-exportőrt. Ezután a OTel környezeti változók konfigurálhatja az OTLP-végpontot telemetriai adatok küldésére, és megadhatja az alkalmazás erőforrás-tulajdonságait.

A ServiceDefaults Aspire-n kívüli használatának lépései a következők:

1. Adja hozzá a ServiceDefaults projektet a megoldáshoz a Visual Studioban az Új projekt hozzáadása opcióval, vagy használja a dotnet new:

   dotnet new aspire-servicedefaults --output ServiceDefaults
   

2. Hivatkozzon a ServiceDefaults projektre a ASP.NET alkalmazásból. A Visual Studióban válassza >Projekthivatkozás hozzáadása lehetőséget, és válassza ki a ServiceDefaults projektet"

3. Az OpenTelemetry beállítási függvény meghívása ConfigureOpenTelemetry() az alkalmazásszerkesztő inicializálásának részeként.

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

A teljes útmutatóért lásd a Példa: OpenTelemetry használata az OTLP-vel és az önálló Aspire Dashboard.

Kísérleti kapcsolat nyomkövetése

A HttpClient problémák vagy szűk keresztmetszetek elhárítása során fontos lehet látni, hogy a HTTP-kérések küldésekor hova megy el az idő. A probléma gyakran a HTTP-kapcsolat létrehozása során jelentkezik, amely általában a DNS-keresésre, a TCP-kapcsolatra és a TLS kézfogásra bont.

A .NET 9 kísérleti kapcsolatkövetést vezetett be, amely egy HTTP connection setup-hatókört adott hozzá a kapcsolati létesítmény DNS-, TCP- és TLS-fázisait képviselő három gyermekfedéssel. A kapcsolatkövetés HTTP-része a SocketsHttpHandlerbelül van implementálva, ami azt jelenti, hogy a tevékenységmodellnek tiszteletben kell tartania az alapul szolgáló kapcsolatkészletezési viselkedést.

Jegyzet

A SocketsHttpHandlerkapcsolatok és kérések önálló életciklussal rendelkeznek. A készletezett kapcsolat hosszú ideig élhet, és számos kérést kiszolgálhat. Amikor kérést küld, ha nincs azonnal elérhető kapcsolat a kapcsolatkészletben, a rendszer hozzáadja a kérést egy kérési üzenetsorhoz, hogy megvárja az elérhető kapcsolatot. Nincs közvetlen kapcsolat a várakozási kérelmek és a kapcsolatok között. Előfordulhat, hogy a csatlakozási folyamat akkor kezdődött el, amikor egy másik kapcsolat elérhetővé vált használatra, ebben az esetben a felszabadított kapcsolatot használják. Ennek eredményeképpen a HTTP connection setup span nem a HTTP client request-hatókör gyermekeként van modellezve; helyett a span linkeket használja a rendszer.

A .NET 9 a következő időtartamokat vezette be a részletes kapcsolati információk gyűjtésének engedélyezéséhez:

Név	ActivitySource	Leírás
HTTP wait_for_connection	Experimental.System.Net.Http.Connections	A HTTP client request hatókör gyermektartománya, amely azt az időtartamot jelöli, amikor a kérés elérhető kapcsolatot vár a kérelemsorban.
HTTP connection_setup	Experimental.System.Net.Http.Connections	A HTTP-kapcsolat létrehozását jelöli. Külön nyomkövetési gyökérszakasz saját TraceId-val. HTTP client request spans tartalmazhatnak olyan hivatkozásokat, amelyek HTTP connection_setup-re mutatnak.
DNS lookup	Experimental.System.Net.NameResolution	A Dns osztály által végzett DNS-keresés.
socket connect	Experimental.System.Net.Sockets	Socket kapcsolat létrehozása.
TLS handshake	Experimental.System.Net.Security	A SslStreamáltal végrehajtott TLS-ügyfél- vagy kiszolgálói kézfogás.

Jegyzet

A megfelelő ActivitySource nevek a Experimentalelőtaggal kezdődnek, mivel ezek a tartományok a jövőbeli verziókban változhatnak, ahogy többet megtudunk arról, hogy hogyan teljesítenek éles környezetben.

Ezek a spanok túl részletesek a 24x7-es használathoz a nagy számítási feladatokkal rendelkező éles helyzetekben – zajosak, és általában nincs szükség ilyen szintű kialakításra. Ha azonban csatlakozási problémákat próbál diagnosztizálni, vagy részletesebben szeretné megismerni, hogy a hálózat és a kapcsolat késése milyen hatással van a szolgáltatásokra, akkor ezek olyan megállapításokat nyújtanak, amelyeket más eszközökkel nehéz összegyűjteni.

Ha a Experimental.System.Net.Http.Connections ActivitySource engedélyezve van, HTTP client requestkiszolgáló kapcsolatának megfelelő HTTP connection_setup spanra. Mivel a HTTP-kapcsolat hosszú élettartamú lehet, ez számos hivatkozást eredményezhet a kapcsolati tartományra az egyes kérési tevékenységekből. Egyes APM-monitorozási eszközök agresszíven végigvezetik a hivatkozásokat a spanok között, hogy felépítsék a nézeteiket, és így ez a span is problémákat okozhat, ha az eszközöket nem úgy tervezték, hogy nagy számú hivatkozást számoljanak el.

Az alábbi ábra a spanok viselkedését és kapcsolatát mutatja be:

Útmutató: A kísérleti kapcsolat nyomkövetésének használata a .NET 9-ben

Ez az útmutató egy .NET 9 Aspire Starter App használatával mutatja be a kapcsolatkövetést, de könnyen beállítható más monitorozási eszközökkel is. A legfontosabb lépés az ActivitySources engedélyezése.

1. Aspire 9 Starter-alkalmazás létrehozása a következő használatávaldotnet new:

   dotnet new aspire-starter-9 --output ConnectionTracingDemo
   

   Vagy a Visual Studióban:

   

2. Nyissa meg a Extensions.cs-t a ServiceDefaults projektben, szerkessze a ConfigureOpenTelemetry metódust, hozzáadva az ActivitySources elemeket a kapcsolat nyomkövetési konfiguráció visszahívásához:

   .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.*");
   });
   

3. Indítsa el a megoldást. Ekkor meg kell nyitnia az Aspire irányítópultot.

4. Lépjen a webfrontend alkalmazás Időjárás lapjára, és hozzon létre egy HttpClient kérést apiservicefelé.

5. Térjen vissza az irányítópultra, és lépjen a Nyomkövetések lapra. Nyissa meg a webfrontend: GET /weather nyomvonalat.

   

Amikor a HTTP-kérések a kapcsolati mérnöki eszközök segítségével készülnek, látnod kellene a következő változásokat az ügyfél kérés spanokban:

• Ha létre kell hozni egy kapcsolatot, vagy ha az alkalmazás a kapcsolatkészletből vár egy kapcsolatot, akkor megjelenik egy további HTTP wait_for_connection span, amely a kapcsolatra való várakozás késleltetését jelzi. Ez segít megérteni a HttpClient kérés kódban történő feldolgozása és a kérés tényleges feldolgozása közötti késéseket. Az előző képen:
  • A kijelölt szakasz a HttpClient-kérelem.
  • Az alábbi időtartam azt az időt jelöli, amelyet a kérés a kapcsolat létrejöttére várva tölt.
  • Az utolsó sárga tartomány a kérést feldolgozó célhelytől származik.
• A HttpClient-span a HTTP connection_setup spanra mutató hivatkozással rendelkezik, amely a kérelem által használt HTTP-kapcsolat létrehozásához szükséges tevékenységet jelöli.

Ahogy korábbanemlítettük, a HTTP connection_setup span egy külön, saját TraceIdrendelkező span, mivel élettartama független az egyes ügyfélkérésektől. Ez a span általában gyerek spanokkal rendelkezik: DNS lookup, (TCP) socket connectés TLS client handshake.

Dúsítás

Bizonyos esetekben ki kell bővíteni a meglévő System.Net nyomkövetési funkciót. Ez általában azt jelenti, hogy további címkéket/attribútumokat szúr be a beépített tevékenységekbe. Ezt dúsításnaknevezik.

Enrichment API az OpenTelemetry műszerezési könyvtárban

Ha további címkéket/attribútumokat szeretne hozzáadni a HTTP-ügyfélkérési tevékenységhez, a legegyszerűbb módszer az OpenTelemetry HttpClient és HttpWebRequest eszköztár HttpClient bővítési API-k használata. Ehhez függőséget kell vennie a OpenTelemetry.Instrumentation.Http csomagtól.

Manuális bővítés

A HTTP client request tevékenység bővítését manuálisan is végrehajthatja. Ehhez hozzá kell férnie Activity.Current a kérelemtevékenység hatókörében futó kódban, mielőtt a tevékenység befejeződik. Ezt úgy teheti meg, hogy megvalósít egy IObserver<DiagnosticListener>-t, és feliratkoztatja azt a AllListeners-re, hogy visszahívásokat kapjon, amikor hálózati tevékenység történik. A OpenTelemetry HttpClient és a HttpWebRequest instrumentációs könyvtár implementálása valójában így történik. Példakódért tekintse meg a DiagnosticSourceSubscriber.cs előfizetési kódját és az HttpHandlerDiagnosticListener.cs mögöttes implementációját, ahol az értesítések delegálva vannak.

További nyomkövetésre van szüksége?

Ha más hasznos információkra vonatkozó javaslatokkal rendelkezik, amelyek nyomkövetéssel is közzétehetők, hozzon létre egy dotnet/futtatókörnyezeti problémát.