Application Insights – Gyakori kérdések

Az Azure Monitor Application Insights hivatalos gyakori kérdései. Válaszokat találhat az Application Insights azure monitorral való használatával kapcsolatos kérdésekre.

Áttekintés

Hogyan instrumentálok egy alkalmazást?

Az Application Insights engedélyezését lehetővé tevő alkalmazások rendszerezésével kapcsolatos részletes információkért tekintse meg az adatgyűjtés alapjait.

Hogyan használható az Application Insights?

Miután engedélyezte az Application Insightst egy alkalmazás rendszerezésével, javasoljuk, hogy először tekintse át az élő metrikákat és az alkalmazástérképet.

Milyen telemetriát gyűjt az Application Insights?

Kiszolgálói webalkalmazásokból:

• HTTP-kérések.
• Függőségek. Hívások SQL-adatbázisokhoz, HTTP-hívások külső szolgáltatásokhoz, Azure Cosmos DB-hez, Azure Table Storage-hoz, Azure Blob Storage-hoz és Azure Queue Storage-hoz.
• Kivételek és veremkövetések.
• Teljesítményszámlálók: A teljesítményszámlálók a következők használatakor érhetők el:
  • Azure Monitor Application Insights-ügynök
  • Azure-monitorozás virtuális gépekhez vagy virtuális gép méretezési csoportokhoz
  • Application Insights-írócollectd.
• Az egyéni események és metrikák, amiket kódolsz.
• Nyomkövetési naplók , ha a megfelelő gyűjtőt konfigurálja.

Ügyféloldalakról:

• Nem kezelt kivételek az alkalmazásban, valamint az ezekre vonatkozó információk:

  • Verem nyomkövetése
  • A hibát kísérő kivétel részletei és üzenete
  • A hiba sor- és oszlopszáma
  • URL-cím, ahol hiba lépett fel
  • Az alkalmazás által létrehozott hálózati függőségi kérelmek XML Http-kérések (XHR) és Fetch-kérések (a Fetch gyűjtemény alapértelmezés szerint le van tiltva) révén a következőkre vonatkozó információkat tartalmazzák:
    • Függőségi forrás URL-címe
    • A függőség kéréséhez használt Command &metódus
    • A kérelem időtartama
    • A kérelem eredménykódja és sikerességi állapota
    • A kérést küldő felhasználó azonosítója (ha van ilyen)
    • Korrelációs környezet (ha van ilyen), ahol a kérés történik

• Felhasználói adatok (például hely, hálózat, IP- cím)

• Eszközadatok (például böngésző, operációs rendszer, verzió, nyelv, modell)

• Munkamenet adatai

  Megjegyzés:

  Egyes alkalmazások, például az egyoldalas alkalmazások (SLA-k) esetében a rendszer nem rögzíti mindig az időtartamot, és ezekben az esetekben az alapértelmezett érték 0.

  További információ: Adatgyűjtés, megőrzés és tárolás az Application Insights szolgáltatásban.

Ha beállítja őket más forrásokból:

• Azure-diagnosztika
• Importálás a Log Analyticsbe
• Log Analytics
• Logstash

Hány Application Insights-erőforrást telepítsek?

Ahhoz, hogy megértse, hány Application Insights-erőforrásra van szükség az alkalmazásának vagy komponenseinek különböző környezetekben való lefedéséhez, tekintse meg az Application Insights üzembe helyezési tervezési útmutatóját.

Hogyan kezelhetem az Application Insights-erőforrásokat a PowerShell-lel?

PowerShell-szkripteket az Azure Resource Monitor használatával a következőre írhat:

• Application Insights-erőforrások létrehozása és frissítése.
• Állítsa be a tarifacsomagot.
• Kérje le az instrumentációs kulcsot.
• Adj hozzá metrikariasztást.
• Rendelkezésre állási teszt hozzáadása.

Nem állíthat be metrikakezelő jelentést, és nem állíthat be folyamatos exportálást.

Hogyan kérdezhetem le az Application Insights telemetriáját?

Log Analytics-lekérdezések futtatásához használja a REST API-t.

Küldhetek telemetriát az Application Insights portálra?

Javasoljuk az Azure Monitor OpenTelemetry Distro használatát.

A betöltési séma és a végpontprotokoll nyilvánosan elérhető.

Mennyi ideig tart a telemetriai adatok gyűjtése?

A legtöbb Application Insights-adat késése 5 perc alatt van. Egyes adatok hosszabb időt is igénybe vehetnek, ami a nagyobb naplófájlokra jellemző. Tekintse meg az Application Insights szolgáltatásszintű szerződését.

Hogyan kezeli az Application Insights az adatgyűjtést, az adatmegőrzést, a tárolást és az adatvédelmet?

Gyűjtemény

Az Application Insights telemetriát gyűjt az alkalmazásról, beleértve a webkiszolgáló telemetriáját, a weblap telemetriáját és a teljesítményszámlálókat. Ezek az adatok az alkalmazás teljesítményének, állapotának és használatának monitorozására használhatók. Új Application Insights-erőforrás létrehozásakor kiválaszthatja a helyet.

Megőrzés és tárolás

Az adatok egy Application Insights Log Analytics-munkaterületre kerülnek. A nyers adatok megőrzési idejét 30 és 730 nap között választhatja ki. Az összesített adatok 90 napig maradnak meg, a hibakeresési pillanatképek pedig 15 napig maradnak meg.

Adatvédelem

Az Application Insights alapértelmezés szerint nem kezeli a bizalmas adatokat. Javasoljuk, hogy ne helyezzen el bizalmas adatokat az URL-címekben egyszerű szövegként, és győződjön meg arról, hogy az egyéni kód nem gyűjt személyes vagy egyéb bizalmas adatokat. A fejlesztés és tesztelés során ellenőrizze az elküldött adatokat az IDE-ben és a böngésző hibakeresési kimeneti ablakaiban.

Archivált információkért tekintse meg az Application Insights adatgyűjtési, adatmegőrzési és tárolási adatait.

Mi az Application Insights díjszabási modellje?

Az Application Insights számlázása a Log Analytics-munkaterületen keresztül történik, amelybe a naplóadatokat betölti. Az alapértelmezett használatalapú Log Analytics tarifacsomag havi 5 GB ingyenes adatkeretet tartalmaz számlázási fiókonként. További információ az Azure Monitor-naplók díjszabási lehetőségeiről.

Vannak adatátviteli díjak egy Azure-webalkalmazás és az Application Insights között?

• Ha az Azure-webalkalmazást olyan adatközpontban üzemelteti, ahol egy Application Insights-gyűjteményvégpont található, díjmentesen.
• Ha nincs gyűjtési végpont a gazdagép adatközpontjában, az alkalmazás telemetriája kimenő Azure-díjakat von maga után.

Ez a válasz a végpontok eloszlásától függ, nem attól, hogy hol található az Application Insights-erőforrás.

Hálózati költségek merülnek fel, ha az Application Insights-erőforrásom egy másik régióban figyel egy Azure-erőforrást (vagyis telemetria-előállítót)?

Igen, további hálózati költségek merülhetnek fel, amelyek attól függően változnak, hogy a telemetria melyik régióból származik, és hogy hová tart. Részletekért tekintse meg az Azure sávszélesség-díjszabását .

Ha váratlan díjakat vagy magas költségeket lát az Application Insightsban, ez az útmutató segíthet. Olyan gyakori okokra terjed ki, mint a magas telemetriai mennyiség, az adatbetöltési csúcsok és a helytelenül konfigurált mintavételezés. Különösen hasznos, ha a költségnövekedéssel, a telemetriai forgalommal, a nem működő mintavételezéssel, az adatkorlátokkal, a magas adatbevitelnél vagy a váratlan számlázással kapcsolatos problémákat hárítja el. Első lépésként tekintse meg az Application Insights magas adatbetöltésének hibaelhárításával foglalkozó témakört.

Milyen TLS-verziók támogatottak?

Az Application Insights a Transport Layer Security (TLS) 1.2- és 1.3-at használja.

Fontos

2025. március 1-jén az Azure minden szolgáltatásból kivonja a TLS régi verzióit. Az Application Insights ekkor már nem támogatja a TLS 1.0-t, a TLS 1.1-et és a felsorolt régi TLS 1.2/1.3 titkosítási csomagokat és háromliptikus görbéket.

Az örökölt TLS-problémával kapcsolatos általános kérdésekért tekintse meg a TLS-problémák megoldását és az Azure Resource Manager TLS-támogatását.

Hol kaphatok további információt az Application Insightsról?

További információ: Bevezetés az Application Insights használatába.

Application Insights API egyéni eseményekhez és metrikákhoz

Miért hiányoznak a telemetriai adatok?

Mindkét telemetriacsatornák elveszítik a pufferelt telemetriát, ha az alkalmazás leállítása előtt nincs kiürítve.

Az adatvesztés elkerülése érdekében öblítse ki a TelemetryClientet, amikor egy alkalmazás leáll.

További információ: Adatok ürítése.

Milyen kivételek Track_() hívásokat?

Nincs. Ezeket nem kell becsomagolnia a try-catch záradékba. Ha az SDK problémákat tapasztal, naplózza az üzeneteket a hibakeresési konzol kimenetében, és ha az üzenetek átjutnak, a Diagnosztikai keresésben.

Van REST API, amely adatokat szeretne lekérni a portálról?

Igen, az adatelérési API. Az adatok kinyerésének egyéb módjai közé tartozik a Power BI a munkaterület-alapú erőforráson.

Miért nem veszik figyelembe az egyéni eseményekre és metrikákra vonatkozó API-k hívásait?

Az Application Insights SDK nem kompatibilis az autoinstrumentációval. Ha az autoinstrumentáció engedélyezve van, a rendszer figyelmen kívül hagyja a Track() és más egyéni eseményekre és metrikákra vonatkozó API-hívásokat.

Kapcsolja ki az autoinstrumentációt az Azure portálon az App Service oldalon található Application Insights lapon, vagy állítsa be ApplicationInsightsAgent_EXTENSION_VERSION értékét disabled-re.

Miért egyenlőtlenek a keresési és metrikadiagramok számai?

A mintavételezés csökkenti az alkalmazásból a portálra küldött telemetriai elemek (például kérések és egyéni események) számát. A Keresés nézetben láthatja a fogadott elemek számát. Az események számát megjelenítő metrikadiagramokon az eredeti események száma látható.

Minden továbbított elem egy tulajdonságot itemCount hordoz, amely azt mutatja, hogy hány eredeti eseményt jelöl az elem. A mintavételezés működés közbeni megfigyeléséhez futtassa ezt a lekérdezést a Log Analyticsben:

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Hogyan állíthatok be riasztást egy eseményen?

Az Azure-riasztások csak a metrikákra vonatkoznak. Hozzon létre egy egyéni metrikát, amely túllép egy értékküszöböt, amikor az esemény bekövetkezik. Ezután állítson be egy riasztást a metrikára. Értesítést kap, ha a metrika mindkét irányban átlépi a küszöbértéket. Az első kereszteződésig nem kap értesítést, függetlenül attól, hogy a kezdeti érték magas vagy alacsony. Mindig van néhány perc késés.

Hol kaphatok további információt az Application Insights API-ról az egyéni eseményekhez és metrikákhoz?

További információ: Application Insights API egyéni eseményekhez és metrikákhoz.

Application Insights-ügynök üzembe helyezése helyszíni kiszolgálókhoz

Támogatja az Application Insights-ügynök a proxytelepítéseket?

Igen. Az Application Insights-ügynök letöltésének több módja is van:

• Ha a számítógép rendelkezik internet-hozzáféréssel, a -Proxy paraméterek használatával csatlakozhat a PowerShell-galériához.
• A modult manuálisan is letöltheti, és telepítheti a számítógépre, vagy közvetlenül használhatja.

Ezeket a lehetőségeket a részletes utasítások ismertetik.

Támogatja az Application Insights-ügynök ASP.NET Core-alkalmazásokat?

Igen. Az Application Insights Agent 2.0.0-s és újabb verzióiban az IIS-ben üzemeltetett ASP.NET Core-alkalmazások támogatottak.

Hogyan ellenőrizze, hogy az engedélyezés sikeres volt-e?

• A Get-ApplicationInsightsMonitoringStatus parancsmaggal ellenőrizheti, hogy az engedélyezés sikeres volt-e.

• Az élő metrikák használatával gyorsan megállapíthatja, hogy az alkalmazás telemetriát küld-e.

• A Log Analytics használatával listázhatja az összes jelenleg telemetriát küldő felhőszerepkört:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

Hogyan elérni a proxyátadást?

A proxyátengedés eléréséhez konfiguráljon egy gépszintű proxyt vagy egy alkalmazásszintű proxyt. Lásd: DefaultProxy.

Web.config példa:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

Hol kaphatok további információt az Application Insights-ügynök helyszíni kiszolgálókhoz való üzembe helyezéséről?

További információ: Application Insights-ügynök üzembe helyezése helyszíni kiszolgálókhoz.

TLS-támogatás

Annak megállapítása, hogy a TLS-kivonás hatással van-e Önre

Az Application Insights és az Azure Monitor nem szabályozza a HTTPS-kapcsolatokhoz használt TLS-verziót. A TLS-verzió az operációs rendszertől és a futtatókörnyezettől függ, ahol az alkalmazás fut.

A használt TLS-verzió megerősítése:

• Tekintse át az operációs rendszer, a futtatókörnyezet vagy a keretrendszer dokumentációját.
• Ha további segítségre van szüksége, forduljon a megfelelő támogatási csoporthoz. Ne nyisson meg támogatási kérelmet az Application Insights használatával.

Példanyelv és futtatókörnyezet támogatása a TLS 1.2+-hez

A következő verziók tartalmazzák a TLS 1.2 vagy újabb verziójának integrált támogatását:

• .NET/ .NET Core: .NET Framework 4.6.2 vagy újabb, és a .NET Core összes verziója
• Java: Java 8 update 161 (8u161) vagy újabb
• Python: Az OpenSSL 1.0.1 vagy újabb verziójával készült Python-disztribúciók
• Node.js: Node.js 10-es vagy újabb verzió

Példa operációsrendszer-támogatás a TLS 1.2+-hez

A következő operációs rendszerek integrált támogatást nyújtanak a TLS 1.2 vagy újabb verziójához:

• Windows: Windows 8, Windows Server 2012 és újabb
• Linux: Az OpenSSL 1.0.1 vagy újabb verzióját használó modern Linux-disztribúciók többsége

Hogyan biztosíthatom, hogy az erőforrásaim ne legyenek hatással?

A szolgáltatáskimaradások elkerülése érdekében az erőforrás minden távoli végpontjának (beleértve a függő kéréseket is) támogatnia kell a korábban említett protokollverzió, titkosítási csomag és elliptikus görbe legalább egy kombinációját. Ha a távoli végpont nem támogatja a szükséges TLS-konfigurációt, frissíteni kell az elavulás utáni TLS-konfiguráció bizonyos kombinációjának támogatásával.

2025. május 1. után mi a viselkedés az érintett erőforrások esetében?

Az érintett Application Insights-erőforrások leállják az adatok betöltését, és nem férnek hozzá a szükséges alkalmazásösszetevőkhöz. Emiatt egyes funkciók leállnak.

Mely összetevőkre van hatással az elavulás?

A jelen dokumentumban részletezett Transport Layer Security (TLS) elavulása csak 2025. május 1. után befolyásolhatja a viselkedést. A CRUD-műveletekről további információt az Azure Resource Manager TLS-támogatásában talál. Ez az erőforrás további részleteket nyújt a TLS támogatásáról és az elavulás idővonaláról.

Hol szerezhetem be a Transport Layer Security (TLS) támogatását?

Az örökölt TLS-problémával kapcsolatos általános kérdésekért tekintse meg a TLS-problémák megoldását.

Hol kaphatok további információt az Application Insights TLS-támogatásáról?

További információ: TLS-támogatás.

ASP.NET

Hogyan távolíthatom el az SDK-t?

Az Application Insights eltávolításához el kell távolítania a NuGet-csomagokat és -hivatkozásokat az alkalmazás API-jából. A NuGet-csomagokat a Visual Studióban a NuGet Csomagkezelő használatával távolíthatja el.

1. Ha a nyomkövetési gyűjtemény engedélyezve van, először távolítsa el a Microsoft.ApplicationInsights.TraceListener csomagot a NuGet Csomagkezelő használatával, de ne távolítsa el a függőségeket.
2. Távolítsa el a Microsoft.ApplicationInsights.Web csomagot, és távolítsa el a függőségeit a NuGet Csomagkezelő és eltávolítási beállításaival a NuGet Csomagkezelő Beállítások vezérlőelemben.
3. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat a projektben hozzáadott API-hívásokkal együtt. További információ: Mi jön létre automatikusan az Application Insights SDK hozzáadásakor?

Mi jön létre automatikusan az Application Insights SDK hozzáadásakor?

Amikor hozzáadja az Application Insightst a projekthez, az automatikusan létrehozza a fájlokat, és kódot ad hozzá néhány fájlhoz. A NuGet-csomagok eltávolítása nem mindig veti el a fájlokat és a kódot. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat, valamint a projektben hozzáadott API-hívásokat.

Amikor Hozzáadja az Application Insights telemetriát egy Visual Studio ASP.NET-projekthez, a következő fájlokat adja hozzá:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

A rendszer automatikusan hozzáadja a következő kódrészleteket:

• [A projekted neve].csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  Ha a projekt rendelkezik Layout.cshtml fájllal, a program a következő kódot adja hozzá.

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

Hogyan tilthatom le a telemetriai korrelációt?

Ha le szeretné tiltani a telemetria-korrelációt a konfigurációban, tekintse meg <ExcludeComponentCorrelationHttpHeadersOnDomains> az Application Insights konzolalkalmazásokhoz készült témakörét.

Hol kaphatok további információt az Application Insights ASP.NET használatával kapcsolatban?

További információ: Az Application Insights konfigurálása a ASP.NET webhelyhez.

ASP.NET Core-alkalmazások

Támogatja az Application Insights a ASP.NET Core 3.1-et?

ASP.NET Core 3.1-et a Microsoft már nem támogatja.

Az Application Insights SDK ASP.NET Core 2.8.0-s és Visual Studio 2019-es vagy újabb verziójához használható ASP.NET Core 3.1-alkalmazásokhoz.

Hogyan követhetem nyomon a nem automatikusan gyűjtött telemetriát?

Hozzon létre egy TelemetryClient példányt konstruktorinjektálással, és hívja meg a szükséges TrackXXX() metódust rajta. Nem javasoljuk, hogy új TelemetryClient vagy TelemetryConfiguration példányokat hozzon létre egy ASP.NET Core-alkalmazásban. A TelemetryClient singleton példánya már regisztrálva van a DependencyInjection tárolóban, amely a többi telemetriával osztozik TelemetryConfiguration. Csak akkor hozzon létre új TelemetryClient példányt, ha a többi telemetriától eltérő konfigurációra van szüksége.

Az alábbi példa bemutatja, hogyan követhet nyomon több telemetriát egy vezérlőből.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Az Application Insights egyéni adatjelentéseiről további információt az Application Insights egyéni metrikák API-referenciájában talál. Hasonló megközelítéssel egyéni metrikákat küldhet az Application Insightsnak a GetMetric API használatával.

Hogyan rögzíthetem a kérés és a válasz tartalmát a telemetriámban?

ASP.NET Core beépített támogatást nyújt a HTTP-kérések/válaszok adatainak (beleértve a törzset) naplózásához.ILogger Javasoljuk, hogy használja ezt a megoldást. Ez potenciálisan személyes azonosításra alkalmas adatokat (PII) tehet közzé a telemetriában, és a költségek (teljesítményköltségek és Az Application Insights számlázása) jelentősen növekedhet, ezért a használat előtt gondosan értékelje ki a kockázatokat.

Hogyan testre szabni az ILogger-naplók gyűjteményét?

Az Application Insights alapértelmezett beállítása az, hogy csak a Figyelmeztetés szintű és annál súlyosabb naplókat rögzítse.

Az Application Insights-szolgáltató naplózási konfigurációjának az alábbiak szerint történő módosításával rögzítheti az információkat és a kevésbé súlyos naplókat.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

Fontos megjegyezni, hogy az alábbi példa nem eredményezi, hogy az Application Insights-szolgáltató rögzítse a naplókat Information. Nem rögzíti, mert az SDK hozzáad egy alapértelmezett naplózási szűrőt, amely arra utasítja ApplicationInsights , hogy csak Warning a naplókat és a súlyosabb naplókat rögzítse. Az Application Insights kifejezett felülbírálást igényel.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

További információ: ILogger-konfiguráció.

Egyes Visual Studio-sablonok az IWebHostBuilder UseApplicationInsights() bővítménymetódusát használták az Application Insights engedélyezéséhez. Ez a használat továbbra is érvényes?

A bővítménymetódus UseApplicationInsights() továbbra is támogatott, de elavultként van megjelölve az Application Insights SDK 2.8.0-s és újabb verzióiban. A következő SDK főverzióban eltávolítják. Az Application Insights telemetriai adatainak engedélyezéséhez használja AddApplicationInsightsTelemetry() , mert túlterheléseket biztosít bizonyos konfigurációk szabályozásához. Emellett ASP.NET Core 3.X-alkalmazásokban services.AddApplicationInsightsTelemetry() csak az Application Insightst lehet engedélyezni.

Üzembe helyezem a ASP.NET Core-alkalmazásomat a Web Appsben. Továbbra is engedélyezni kell az Application Insights bővítményt a Web Appsből?

Ha az SDK a jelen cikkben látható buildelési időpontban van telepítve, nem kell engedélyeznie az Application Insights bővítményt az App Service portálról. Ha a bővítmény telepítve van, a bővítmény kikapcsol, amikor azt észleli, hogy az SDK már hozzá lett adva. Ha engedélyezi az Application Insightst a bővítményből, nem kell telepítenie és frissítenie az SDK-t. Ha azonban a jelen cikkben ismertetett utasításokat követve engedélyezi az Application Insights szolgáltatást, nagyobb rugalmasságot biztosít, mert:

• Az Application Insights telemetria továbbra is működik:
  • Minden operációs rendszer, beleértve a Windowst, a Linuxot és a Macet is.
  • Minden közzétételi mód, beleértve az önálló vagy keretrendszerfüggőt is.
  • Minden cél-keretrendszer, beleértve a teljes .NET-keretrendszer.
  • Minden üzemeltetési lehetőség, beleértve a Web Appst, a virtuális gépeket, a Linuxot, a tárolókat, az AKS-t és a nem Azure-beli üzemeltetést.
  • Minden .NET Core-verzió, beleértve az előzetes verziókat is.
• A telemetriát helyileg láthatja, amikor hibakeresést végez a Visual Studióban.
• Az API használatával TrackXXX() további egyéni telemetriát is nyomon követhet.
• Teljes körűen szabályozhatja a konfigurációt.

Engedélyezhetim az Application Insights monitorozását olyan eszközökkel, mint az Azure Monitor Application Insights Agent (korábbi nevén Status Monitor v2)?

Igen. Az Application Insights Agent 2.0.0-beta1 és újabb verzióiban az IIS-ben üzemeltetett ASP.NET Core-alkalmazások támogatottak.

Minden funkció támogatott, ha az alkalmazást Linuxon futtatom?

Igen. Az SDK szolgáltatástámogatása minden platformon azonos, az alábbi kivételekkel:

• Az SDK eseményszámlálókat gyűjt Linux rendszeren, mert a teljesítményszámlálók csak a Windowsban támogatottak. A legtöbb metrika ugyanaz.

Ez az SDK támogatott a Worker Services esetében?

Nem. Ehelyett használja az Application Insights for Worker Service-alkalmazásokat (nem HTTP-alkalmazásokat) a feldolgozói szolgáltatásokhoz.

Hogyan távolíthatom el az SDK-t?

Az Application Insights eltávolításához el kell távolítania a NuGet-csomagokat és -hivatkozásokat az alkalmazás API-jából. A NuGet-csomagokat a Visual Studióban a NuGet Csomagkezelő használatával távolíthatja el.

Megjegyzés:

Ezek az utasítások a ASP.NET Core SDK eltávolítására használhatók. Ha el kell távolítania a ASP.NET SDK-t, olvassa el a Hogyan távolíthatom el a ASP.NET SDK-t?

1. Távolítsa el a Microsoft.ApplicationInsights.AspNetCore csomagot a NuGet Csomagkezelő használatával.
2. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat a projektben hozzáadott API-hívásokkal együtt. További információ: Mi jön létre az Application Insights SDK hozzáadásakor?

Mi jön létre az Application Insights SDK hozzáadásakor?

Amikor hozzáadja az Application Insightst a projekthez, az fájlokat hoz létre, és kódot ad hozzá néhány fájlhoz. A NuGet-csomagok eltávolítása nem mindig veti el a fájlokat és a kódot. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat, valamint a projektben hozzáadott API-hívásokat.

Amikor Hozzáadja az Application Insights telemetriát egy Visual Studio ASP.NET Core-sablonprojekthez, a következő kódot adja hozzá:

• [A projekted neve].csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

Hogyan tilthatom le a telemetriai korrelációt?

Ha le szeretné tiltani a telemetriai korrelációt a kódban, nézze meg <ExcludeComponentCorrelationHttpHeadersOnDomains> az Application Insights konzolalkalmazásokhoz vonatkozó témakörét.

Hol kaphatok további információt az Application Insights ASP.NET Core-alkalmazásokhoz való használatáról?

További információ: Application Insights for ASP.NET Core.

ASP.NET teljesítményszámlálók

Mi a különbség a kivételi arány és a Kivételek metrikák között?

• Exception rate: A kivételi arány egy rendszerteljesítmény-számláló. A CLR megszámolja az összes olyan kezelt és kezeletlen kivételt, amely ki van dobva, és a mintavételi intervallumban lévő összesítést az intervallum hosszával osztja el. Az Application Insights SDK összegyűjti ezt az eredményt, és elküldi a portálnak.
• Exceptions: A Kivételek metrika megszámolja a TrackException portál által a diagram mintavételezési időközében fogadott jelentéseket. Csak azokat a kezelt kivételeket tartalmazza, ahol TrackException hívásokat ír a kódjába. Nem tartalmazza az összes kezeletlen kivételt.

Hol kaphatok további információt ASP.NET teljesítményszámlálókról?

További információ: .NET számlálók az Application Insightsban.

ASP.NET eseményszámlálók

Láthatom az EventCounterst az élő metrikákban?

Az élő metrikák nem jelenítik meg az EventCounterst. A telemetriai adatok megtekintéséhez használja a Metric Explorert vagy az Analyticset.

Miután engedélyeztem az Application Insights szolgáltatást az Azure Web App Portalon, miért nem látom az eseményszámlálókat?

A ASP.NET Core Application Insights-bővítménye még nem támogatja ezt a funkciót.

Hol kaphatok további információt ASP.NET eseményszámlálókról?

További információ: .NET számlálók az Application Insightsban.

Azure-beli virtuális gépek és virtuálisgép-méretezési csoportok

Hogyan tilthatom le az ügyféloldali monitorozást ASP.NET Core-alkalmazások esetében?

Az ügyféloldali monitorozás alapértelmezés szerint engedélyezve van ASP.NET Core-alkalmazások esetében. Ha le szeretné tiltani, definiáljon egy környezeti változót a kiszolgálón a következő információkkal:

• Név:APPINSIGHTS_JAVASCRIPT_ENABLED
• Érték:false

Hol kaphatok további információt az Application Insights azure-beli virtuális gépekhez és virtuálisgép-méretezési csoportokhoz való használatáról?

További információ: Application Insights azure-beli virtuális gépekhez és virtuálisgép-méretezési csoportokhoz.

Függőség nyomon követése

Hogyan jelenti az automatikus függőséggyűjtő a függőségekre irányuló sikertelen hívásokat?

A sikertelen függőségi hívások success mezője Hamisra (False) van állítva. A modul DependencyTrackingTelemetryModule nem tesz jelentést ExceptionTelemetry. A függőség teljes adatmodelljének leírását az Application Insights telemetriai adatmodellje ismerteti.

Hogyan számolhatom ki a függőségi telemetria betöltési késését?

Használja a következő kódot:

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

Hogyan határozza meg a függőségi hívás indításának időpontját?

A Log Analytics lekérdezési nézetben timestamp a TrackDependency() hívás indításának pillanatát jelöli, amely közvetlenül a függőségi hívás válaszának fogadása után következik be. A függőségi hívás indításának időpontjának kiszámításához vegye figyelembe timestamp és vonja ki a függőségi hívás rögzített duration értékét.

Az Application Insights függőségkövetése tartalmazza a válaszok törzseit?

Az Application Insights függőségkövetése nem tartalmazza a választörzsek naplózását, mivel túl sok telemetriát generálna a legtöbb alkalmazás számára.

Hol kaphatok további információt a függőségek nyomon követéséről az Application Insightsban?

További információ: Függőségek nyomon követése.

Rendelkezésreállási tesztek

Futtathatok rendelkezésreállási teszteket egy intranetes kiszolgálón?

A rendelkezésre állási tesztek a világ különböző pontjain elosztott jelenléti pontokon futnak. Két megoldás létezik:

• Tűzfalajtó: A webtesztelők hosszú és módosítható listájából engedélyezheti a kiszolgálóra irányuló kéréseket.
• Egyéni kód: Írjon saját kódot, hogy rendszeres kéréseket küldjön a kiszolgálónak az intraneten belülről. Erre a célra Visual Studio-webteszteket is futtathat. A tesztelő az API használatával elküldheti az eredményeket az TrackAvailability() Application Insightsnak.

Mi a felhasználói ügynök lánca a rendelkezésre állási tesztekhez?

A felhasználói ügynök sztringje Mozilla /5.0 (kompatibilis; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Hol kaphatok további információt az Application Insights rendelkezésre állási tesztjeiről?

További információ: Rendelkezésre állási tesztek.

TLS-támogatás rendelkezésre állási tesztekhez

Hogyan befolyásolja az elavulás a webes teszt viselkedését?

A rendelkezésre állási tesztek elosztott ügyfélként működnek minden támogatott webes teszthelyen. Minden alkalommal, amikor egy webes teszt végrehajtása megtörténik, a rendelkezésre állási tesztszolgáltatás megpróbálja elérni a webes tesztkonfigurációban meghatározott távoli végpontot. A rendszer egy TLS-ügyfél hello üzenetet küld, amely tartalmazza az összes jelenleg támogatott TLS-konfigurációt. Ha a távoli végpont közös TLS-konfigurációt oszt meg a rendelkezésre állási tesztügyféllel, a TLS-kézfogás sikeres lesz. Ellenkező esetben a webes teszt TLS-kézfogási hibával meghiúsul.

Hogyan ellenőrizni, hogy a távoli végpont milyen TLS-konfigurációt támogat?

A végpontok által támogatott TLS-konfiguráció teszteléséhez több eszköz is rendelkezésre áll. Ennek egyik módja az ezen az oldalon részletezett példa követése. Ha a távoli végpont nem érhető el a nyilvános interneten keresztül, ellenőriznie kell a távoli végponton támogatott TLS-konfigurációt egy olyan gépről, amely rendelkezik hozzáféréssel a végpont meghívásához.

Megjegyzés:

Ha szeretné engedélyezni a szükséges TLS-konfigurációt a webkiszolgálón, a legjobb, ha megkeresi azt a csapatot, amely a webkiszolgáló által futtatott üzemeltetési platformot birtokolja, ha a folyamat nem ismert.

2025. május 1. után mi lesz a webes teszt viselkedése az érintett tesztekhez?

Nincs olyan kivételtípus, amely az elavulás miatti TLS-kézfogási hibáknál felmerülne. A webes teszt során azonban a leggyakoribb kivétel, amivel a teszt elkezdene meghiúsulni, The request was aborted: Couldn't create SSL/TLS secure channel lenne. A TLS átviteli hibaelhárítási lépésében az esetlegesen érintett webes teszt eredményének TLS-sel kapcsolatos hibáit is látnia kell.

Megtekinthetim, hogy a webes teszt jelenleg milyen TLS-konfigurációt használ?

A webes teszt végrehajtása során egyeztetett TLS-konfiguráció nem tekinthető meg. Mindaddig, amíg a távoli végpont a rendelkezésre állási tesztekkel támogatja a gyakori TLS-konfigurációt, az elavulás utáni hatás nem észlelhető.

Mely összetevőkre van hatással az elavulás a rendelkezésre állási tesztszolgáltatásban?

A jelen dokumentumban részletezett TLS-elavulás csak a rendelkezésre állási teszt webes tesztvégrehajtási viselkedését befolyásolhatja 2025. május 1. után. További információ a CRUD-műveletek rendelkezésre állási tesztszolgáltatásával való interakcióról: Azure Resource Manager TLS-támogatás. Ez az erőforrás további részleteket nyújt a TLS támogatásáról és az elavulás idővonaláról.

Hol szerezhetek be TLS-támogatást?

Az örökölt TLS-problémával kapcsolatos általános kérdésekért tekintse meg a TLS-problémák megoldását.

Hol kaphatok további információt a rendelkezésre állási tesztek TLS-támogatásáról?

További információ: Támogatott TLS-konfigurációk.

Monitorozás az Azure App Service for .NET- és Node.js-, Python- és Java-alkalmazásokban

Mit módosít az Application Insights a projektemben?

A részletek a projekt típusától függenek. Az alábbi lista egy webalkalmazás példája.

• Fájlokat ad hozzá a projekthez:

  • ApplicationInsights.config
  • ai.js

• Telepíti a NuGet-csomagokat:

  • Application Insights API: Az alapvető API
  • Application Insights API webalkalmazásokhoz: Telemetriát küld a kiszolgálóról
  • Application Insights API JavaScript-alkalmazásokhoz: Telemetriai adatok küldésére szolgál az ügyféltől

• Tartalmazza a csomagokban lévő összeszereléseket:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Elemek beszúrása a következőbe:

  • Web.config
  • packages.config

• Kódrészleteket szúr be az ügyfél- és kiszolgálókódba, hogy inicializálja őket az Application Insights erőforrás-azonosítójával. Egy MVC-alkalmazásban például a rendszer kódot szúr be a Nézetek/Megosztott/_Layout.cshtml főlapra. Csak új projektek esetén manuálisan kell hozzáadnia az Application Insightst egy meglévő projekthez.

Mi a különbség az Application Insights standard metrikái és Azure-alkalmazás szolgáltatásmetrikái között?

Az Application Insights telemetriai adatokat gyűjt az alkalmazásnak küldött kérelmekről. Ha a hiba a WebApps/WebServer szolgáltatásban jelentkezik, és a kérés nem érte el a felhasználói alkalmazást, az Application Insights nem rendelkezik telemetriai adatokkal.

Az Application Insights által kiszámított időtartam serverresponsetime nem feltétlenül egyezik meg a Web Apps által megfigyelt kiszolgálói válaszidővel. Ennek a viselkedésnek az az oka, hogy az Application Insights csak azt az időtartamot számolja meg, amikor a kérés ténylegesen eléri a felhasználói alkalmazást. Ha a kérés elakadt vagy várólistára került a WebServerben, a várakozási idő a Web Apps-metrikákban szerepel, az Application Insights-metrikákban azonban nem.

Hol kaphatok további információt az Azure App Service .NET-, Node.js-, Python- és Java-alkalmazások monitorozásáról?

További információ: Alkalmazásfigyelés engedélyezése az Azure App Service-ben.

Autoinstrumentáció

Kötőjellel kell-e elválasztani az "autoinstrumentáció" kifejezést?

A Microsoft Learn platformon közzétett termékdokumentációhoz kövesse a Microsoft Stílus útmutatóját.

Általában nem tartalmaz kötőjelet az "auto" előtag után.

Hol kaphatok további információt az automatikus beléptetésről?

További információ: Mi az Azure Monitor Application Insights automatikus integrációja?

Autoinstrumentation for Azure Kubernetes Service

Támogatja az Azure Kubernetes Service (AKS) autoinstrumentációja az egyéni metrikákat?

Ha egyéni metrikákat szeretne a Node.js-ban, manuálisan konfigurálja az alkalmazásokat az Azure Monitor OpenTelemetry Distro segítségével.

A Java autoinstrumentációval lehetővé teszi az egyéni metrikákat. A kód frissítésével és a funkció engedélyezésével egyéni metrikákat gyűjthet . Ha a kód már rendelkezik egyéni metrikákkal, akkor azok akkor haladnak át, amikor engedélyezve van az autoinstrumentáció.

Működik az AKS autoinstrumentációja nyílt forráskódú szoftverrel (OSS) rendelkező OpenTelemetry SDK-val létrehozott alkalmazásokkal?

Az AKS autoinstrumentáció megzavarhatja az OSS OpenTelemetry SDK által harmadik feleknek küldött telemetriát.

Az AKS autoinstrumentációja egymás mellett létezhet a manuális instrumentációval?

Az AKS autoinstrumentáció úgy lett kialakítva, hogy mindkét manuális instrumentációs lehetőséggel együtt létezzen: az Application Insights klasszikus API SDK-ja és az OpenTelemetry Distro.

Ez mindig megakadályozza a duplikált adatokat, és biztosítja az egyéni metrikák működését.

Ebből a diagramból megtudhatja, hogy mikor élvez elsőbbséget az autoinstrumentáció vagy a manuális rendszerezés.

Nyelv	Elsőbbség
Node.js	Manuális műszerhasználat
Jáva	Autoinstrumentáció

Hogyan győződhetek meg arról, hogy az Azure Monitor OpenTelemetry Distro legújabb és legbiztonságosabb verzióit használom?

Az Azure Monitor OpenTelemetry Disztribúcióban észlelt biztonsági rések rangsorolva, javítva és felszabadítva lesznek a következő verzióban.

Az AKS autoinstrumentation az Azure Monitor OpenTelemetry Distro legújabb verzióját injektálja az alkalmazás podjaiba minden alkalommal, amikor az üzembe helyezést módosítják vagy újraindítják.

Az OpenTelemetria disztribúció sebezhetővé válhat olyan üzemelő példányokon, amelyek hosszabb ideig nem változnak vagy újraindulnak. Ezért javasoljuk, hogy hetente frissítse vagy indítsa újra az üzemelő példányokat a Disztribúció legújabb verziójának használata érdekében.

Hogyan tudhatok meg többet az Azure Monitor OpenTelemetry Distro-ról?

Ez a funkció az Azure Monitor OpenTelemetry Distro alkalmazás podokba történő injektálásával éri el az automatikus instrumentálást.

Java esetén ez a funkció integrálja a Java önálló Azure Monitor OpenTelemetry Disztribúcióját. További információt a Java-disztribúciós dokumentációban talál a Java-rendszerállapot bináris verziójáról.

A Node.jsesetében egy autoinstrumentációs bináris fájlt injektálunk az Azure Monitor OpenTelemetry Distro for Node.jsalapján. További információ: Node.js disztribúció dokumentációja. Ne feledje, hogy nincs önálló automatikus műszerelésünk a Node.js esetében, így a disztribúciós dokumentációnk a manuális beállításra összpontosít. Nem kell foglalkoznia a manuális műszereléssel kapcsolatos kódalapú konfigurációs lépésekkel. A disztribúció dokumentációjában azonban minden más, például az alapértelmezett beállítások és a környezeti változók konfigurációi is vonatkoznak erre a funkcióra.

Hol kaphatok további információt az AKS automatikus beléptetéséről?

További információ: Autoinstrumentation for AKS.

Kapcsolati karakterláncok

Az új Azure-régiók megkövetelik a kapcsolati sztring használatát?

Az új Azure-régiókban műszerkulcsok helyett kapcsolati sztringek használata szükséges. A kapcsolati sztring azonosítja a telemetriai adatokhoz társítani kívánt erőforrást. Azt is lehetővé teszi, hogy módosítsa azokat a végpontokat, amelyet az erőforrás a telemetria célhelyeként használ. Másolja ki a kapcsolati sztring, és adja hozzá az alkalmazás kódjához vagy egy környezeti változóhoz.

Használjak kapcsolati karakterláncokat vagy instrukciós kulcsokat?

Javasoljuk, hogy a kapcsolati sztringek használata helyett instruálási kulcsokat használjon.

Mikor kell beállítanom a környezeti változót?

Állítsa be manuálisan az APPLICATIONINSIGHTS_CONNECTION_STRING összes olyan forgatókönyvben, ahol a rendszer nem biztosítja automatikusan. Ezek a forgatókönyvek magukban foglalják a helyi fejlesztést és a .NET izolált függvényeket ASP.NET Core-integrációval. Ezekben az esetekben a környezeti változó biztosítja, hogy az OpenTelemetry csővezeték továbbíthassa a telemetriát az Application Insights-ra. További információt a kapcsolat karakterláncok környezeti változóval történő konfigurálásáról Az OpenTelemetry konfigurálása az Application Insightsban című dokumentumban találhat.

Hogyan alakíthatok ki globális webalkalmazást a regionális adatmegfelelési követelményeknek való megfelelés érdekében?

A regionális adatmegfelelési követelmények teljesítéséhez használjon regionális Application Insights-végpontokat a globális végpont helyett. A globális végpont nem garantálja, hogy az adatok egy adott régión belül maradnak. A regionális végpontok segítenek biztosítani, hogy a szabályozott területeken lévő felhasználók telemetriai adatai csak az adott régiók adatközpontjaiba legyenek elküldve.

A globális webalkalmazás regionális megfelelőségre való konfigurálásához:

• Hozzon létre régiónként egy Application Insights-erőforrást szigorú megfelelőségi követelményekkel, például az Európai Unióval vagy az Egyesült Államokkal.
• Hozzon létre egy másik Application Insights-erőforrást az összes többi régió felhasználói számára.
• Konfigurálja az alkalmazást úgy, hogy telemetriát küldjön a megfelelő Application Insights-erőforrásnak az egyes felhasználók régiói alapján. Határozza meg a régiót olyan jelek használatával, mint az IP-cím, a fiók metaadatai vagy a helybeállítások.
• Ha régiók közötti egységes lekérdezési felületre van szüksége, csatlakoztassa az Összes Application Insights-erőforrást egy Log Analytics-munkaterülethez.

Például:

• Küldje el az A régió felhasználóinak adatait az A régió Application Insights erőforrásába az A régió kapcsolati sztringjének használatával.
• Adatokat küldjön a B régió felhasználóitól a B régió Application Insights-erőforrásához a B régió kapcsolati sztringje segítségével.
• Az összes többi felhasználói adat elküldése egy általános célú Application Insights-erőforrásba egy másik kapcsolati sztring használatával.

Fontos

A globális végpont használata nem biztosítja a regionális megfelelőséget. Az adattárolási követelmények teljesítéséhez mindig használjon régióspecifikus végpontokat, és a felhasználó régiója alapján irányozza át a telemetriát.

Az alábbi ábra egy globális webalkalmazás példabeállítását mutatja be:

Hol kaphatok további információt a kapcsolati sztringekről az Application Insightsban?

További információ: Kapcsolati karakterláncok.

Application Insights-erőforrások létrehozása és konfigurálása

Hogyan áthelyezni egy Application Insights-erőforrást egy új régióba?

A meglévő Application Insights-erőforrások régiók közötti átvitele nem támogatott, és az előzményadatok nem migrálhatók új régióba. A megoldás magában foglalja:

• Új Application Insights-erőforrás létrehozása a kívánt régióban.
• Az eredeti erőforrás egyedi testreszabásainak újraalkotása az új erőforrásban.
• Az alkalmazás frissítése az új régiós erőforrás kapcsolati karakterláncával.
• Tesztelés, hogy minden a várt módon működjön az új Application Insights-erőforrással.
• Döntse el, hogy megtartja vagy törli az eredeti Application Insights-erőforrást. A klasszikus erőforrás törlése az összes előzményadat elvesztését jelenti. Ha az erőforrás munkaterület-alapú, az adatok a Log Analyticsben maradnak, így az előzményadatokhoz való hozzáférés a megőrzési időszak lejártáig tart.

Az új régióban lévő erőforráshoz gyakran manuálisan újra kell létrehozni vagy frissíteni kívánt egyedi testreszabások közé tartoznak, de nem korlátozódnak a következőkre:

• Egyéni irányítópultok és munkafüzetek újbóli létrehozása.
• Hozza létre vagy frissítse újra az egyéni napló-/metrikariasztások hatókörét.
• Hozza létre újra a rendelkezésre állási riasztásokat.
• Hozza létre újra azokat az egyéni Azure-szerepköralapú hozzáférés-vezérlési beállításokat, amelyek szükségesek ahhoz, hogy a felhasználók hozzáférjenek az új erőforráshoz.
• Replikálja a betöltési mintavételezést, az adatmegőrzést, a napi korlátot és az egyéni metrikák engedélyezését magában foglaló beállításokat. Ezeket a beállításokat a Használat és a becsült költségek panelen lehet szabályozni.
• Az API-kulcsokra támaszkodó összes integráció, például a kibocsátási széljegyzetek és az élő metrikák biztonságos vezérlési csatornája. Új API-kulcsokat kell létrehoznia, és frissítenie kell a társított integrációt.
• A klasszikus erőforrások folyamatos exportálását újra konfigurálni kell.
• A munkaterület-alapú erőforrások diagnosztikai beállításait újra konfigurálni kell.

Használhatom a szolgáltatókat ('Microsoft.Insights', 'components').apiVersions[0] az Azure Resource Manager telepítésekben?

Nem javasoljuk, hogy ezt a módszert használja az API-verzió feltöltéséhez. A legújabb verzió az előzetes verziójú kiadásokat jelölheti, amelyek kompatibilitástörő változásokat tartalmazhatnak. Az API-verziók még az újabb, nem előzetes verziók esetén sem mindig kompatibilisek a meglévő sablonokkal. Bizonyos esetekben előfordulhat, hogy az API-verzió nem minden előfizetés számára érhető el.

Hol kaphatok további információt az Application Insights-erőforrások létrehozásáról és konfigurálásáról?

További információ: Application Insights-erőforrások létrehozása és konfigurálása.

Telemetriai adatmodell

Hogyan jelenthetek adatmodellt vagy sémaproblémákat és javaslatokat?

Adatmodell vagy sémaproblémák és javaslatok jelentéséhez használja a GitHub-adattárat.

Hogyan mérném egy monitorozási kampány hatását?

A PageView Telemetria URL-címet tartalmaz, és a Kusto regex függvényével elemezheti az UTM paramétert.

Előfordulhat, hogy ezek az adatok hiányoznak vagy pontatlanok, ha a felhasználó vagy a vállalat letiltja a felhasználói ügynök küldését a böngésző beállításai között. Előfordulhat, hogy az UA Parser regexes nem tartalmazza az összes eszközinformációt. Vagy előfordulhat, hogy az Application Insights nem fogadta el a legújabb frissítéseket.

Miért lenne sikeres egy egyéni mérés hiba nélkül, de a napló nem jelenik meg?

Ez akkor fordulhat elő, ha sztringértékeket használ. Csak a numerikus értékek működnek egyéni mérésekkel.

Hol kaphatok további információt a telemetriai adatmodellről?

További információ: Application Insights telemetriai adatmodell.

Naplózás .NET-tel

Milyen Application Insights-telemetriatípus jön létre az ILogger-naplókból? Hol láthatók az ILogger-naplók az Application Insightsban?

ApplicationInsightsLoggerProvider rögzíti a naplókat ILogger, és ezekből létrehoz TraceTelemetry. Ha egy Exception objektumot átadnak a Log-on lévő ILogger metódusnak, ExceptionTelemetry jön létre TraceTelemetry helyett.

ILogger Telemetria megtekintése

Az Azure Portalon:

1. Nyissa meg az Azure Portalt, és nyissa meg az Application Insights-erőforrást.
2. Válassza ki az Application Insights Naplók szakaszát.
3. A Kusto lekérdezésnyelv (KQL) használatával kérdezheti le a traces táblában tárolt ILogger-üzeneteket. Példa lekérdezés: traces | where message contains "YourSearchTerm".
4. Pontosítsa a lekérdezéseket, hogy az ILogger-adatokat súlyosság, időtartomány vagy adott üzenettartalom alapján szűrje.

A Visual Studióban (helyi hibakereső):

1. Indítsa el az alkalmazást hibakeresési módban a Visual Studióban.
2. Nyissa meg a Diagnosztikai eszközök ablakot az alkalmazás futtatása közben.
3. Az Események lapon az ILogger-naplók más telemetriai adatokkal együtt jelennek meg.
4. Adott ILogger-üzenetek megkereséséhez használja a diagnosztikai eszközök ablak keresési és szűrési funkcióit.

Ha mindig szeretne küldeni TraceTelemetry, használja ezt a kódrészletet:

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Egyes ILogger-naplók miért nem rendelkeznek ugyanazokkal a tulajdonságokkal, mint mások?

Az Application Insights az ILogger összes többi telemetriához használt adatok használatával rögzíti és küldi TelemetryConfiguration a naplókat. De van egy kivétel. Alapértelmezés szerint TelemetryConfiguration nincs teljesen beállítva, amikor a Program.cs vagy a Startup.cs fájlból történik a naplózás. Az ezekről a helyekről származó naplók nem rendelkeznek az alapértelmezett konfigurációval, így nem futtatják az összes TelemetryInitializer és TelemetryProcessor példányt.

A Microsoft.Extensions.Logging.ApplicationInsights különálló csomagot használom, és manuálisan szeretnék több egyéni telemetriát naplózni. Hogyan csináljam?

Amikor az önálló csomagot használja, TelemetryClient nem kerül be a függőséginjektálási (DI) tartályba. Létre kell hoznia egy új TelemetryClient példányt, és ugyanazt a konfigurációt kell használnia, mint amelyet a naplózó szolgáltató használ, ahogyan az alábbi kód is mutatja. Ez a követelmény biztosítja, hogy ugyanazt a konfigurációt használják az összes egyéni telemetriához és a ILogger telemetriájához.

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Megjegyzés:

Ha az Microsoft.ApplicationInsights.AspNetCore csomagot az Application Insights engedélyezésére használja, módosítsa ezt a kódot úgy, hogy a TelemetryClient közvetlenül a konstruktorban legyen elérhető.

Nincs telepítve az SDK, és az Azure Web Apps bővítmény használatával engedélyezem az Application Insightst a ASP.NET Core-alkalmazásokhoz. Hogyan használni az új szolgáltatót?

Az Azure Web Apps Application Insights bővítménye az új szolgáltatót használja. Az alkalmazás appsettings.json fájljában módosíthatja a szűrési szabályokat.

Hol kaphatok további információt a .NET-alapú naplózásról?

További információ: Application Insights naplózás a .NET-tel.

Java Profilozó

Mi az Azure Monitor Application Insights Java-profiler?

A Java Profiler a Java Flight Recorder (JFR) használatával profilozza az alkalmazást egy testreszabott konfiguráció használatával.

Mi az a Java Flight Recorder?

A Java Flight Recorder (JFR) egy futó Java-alkalmazás profilkészítési adatainak gyűjtésére szolgáló eszköz. A JFR integrálva van a Java virtuális gépbe (JVM), és a teljesítményproblémák elhárítására szolgál. További információ a Java SE JFR-futtatókörnyezetről.

Milyen ár- és/vagy licencdíj-következményekkel jár az App Insights Java Profiling engedélyezése?

A Java Profilkészítés az Application Insights ingyenes funkciója. Az Azure Monitor Application Insights díjszabása a betöltési költségeken alapul.

Milyen Java-profilkészítési adatokat gyűjtünk?

A JFR által gyűjtött profilkészítési adatok a következők: metódus- és végrehajtási profilkészítési adatok, szemétgyűjtési adatok és zárolási profilok.

Hogyan használhatom az App Insights Java-profilkészítést és az adatok vizualizációját?

A JFR-felvétel megtekinthető és elemezhető az előnyben részesített eszközzel, például a Java Mission Control (JMC) használatával.

A teljesítménydiagnosztikát és javítási javaslatokat biztosít az App Insights Java-profilkészítés?

A "Teljesítménydiagnosztikák és javaslatok" egy új funkció, amely hamarosan elérhető az Application Insights Java Diagnostics szolgáltatásában. Regisztrálhat a funkció előzetes verziójára. A JFR-felvétel megtekinthető a Java Mission Control (JMC) használatával.

Mi a különbség az igény szerinti és az automatikus Java-profilkészítés között az App Insightsban?

Az igény szerinti profilkészítés valós időben történik, míg az automatikus profilkészítés előre konfigurált eseményindítókkal történik.

Az igény szerinti profilkészítési lehetőséghez használja a Profil most lehetőséget. A Profile Now azonnal profilt ad az Application Insights-példányhoz csatolt összes ügynöknek.

Az automatikus profilkészítést egy erőforrás küszöbértékének elérése aktiválja.

Mely Java-profilkészítési eseményindítókat konfigurálhatom?

Az Application Insights Java-ügynök jelenleg támogatja a processzor- és memóriahasználat monitorozását. A cpu-küszöbérték a gép összes elérhető magjának százalékos arányaként van konfigurálva. A memória az aktuális tenured memóriaterület (OldGen) foglaltsága a régió maximális lehetséges méretével szemben.

Milyen előfeltételek szükségesek a Java-profilkészítés engedélyezéséhez?

Tekintse át az előfeltételeket.

Használhatom a Java-profilkészítést mikroszolgáltatás-alkalmazásokhoz?

Igen, a JFR használatával profilozhat mikroszolgáltatásokat futtató JVM-et.

Hol kaphatok további információt a Java Profilerről?

További információ: Azure Monitor Application Insights Profiler for Java.

Mintavételezési felülbírálások – Application Insights for Java

Manuális rendszerezést kell használnom a mintavételi felülbírálások engedélyezéséhez?

Nem, a mintavételezési felülbírálások már általánosan elérhetők (GA), és az automatikus és manuális rendszerezéssel is használhatók.

Hogyan konfigurálhatom a mintavételezési felülbírálásokat az Azure App Service automatikus vezérléssel történő használatakor?

Ha autoinstrumentációt használ, frissítse a applicationinsights.json fájlt az Azure Portalon.

Szükséges manuálisan feltölteni az Application Insights-ügynökfájlt a mintavételi felülbírálásokhoz?

Az autoinstrumentációhoz nincs szükség kézi ügynök feltöltésére. Azonban a manuális instrumentáláshoz szükséges, hogy a telepítési csomag tartalmazza az Application Insights ügynök JAR-fájlt és a konfigurációs fájlokat.

Mi a különbség a "helyi fejlesztés" és az "alkalmazáskiszolgáló" között a manuális kialakítás kontextusában?

A helyi fejlesztés azt a környezetet jelenti, amelyben az alkalmazás felépítése vagy tesztelése folyamatban van, például egy fejlesztő gépe vagy egy Azure Cloud Shell-példány. Az alkalmazáskiszolgáló az alkalmazást futtató webkiszolgálóra hivatkozik, például a Tomcat 11-et egy Azure App Service-környezetben. Manuális rendszerezés használatakor gondoskodnia kell arról, hogy az ügynök JAR-fájlja megfelelően legyen elhelyezve az alkalmazáskiszolgálón.

Ha Egy Azure App Service-t használok Java-futtatókörnyezettel (például Tomcat 11), hogyan konfigurálhatom a mintavételezési felülbírálásokat?

Az autoinstrumentációhoz a mintavételezési felülbírálásokat az Azure Portalon konfigurálhatja. Ha manuális műszerezést használ, helyezze az Application Insights-ügynök JAR-t a megfelelő könyvtárba, és vegye fel a applicationinsights.json fájlt a kívánt mintavételezési beállításokkal.

Hol kaphatok további információt a mintavételi felülbírálásokról?

További információ: Mintavételezési felülbírálások – Azure Monitor Application Insights for Java.

Telemetriai feldolgozók

Miért nem dolgozza fel a naplófeldolgozó a naplófájlokat a TelemetryClient.trackTrace() használatával?

A TelemetryClient.trackTrace() az Application Insights klasszikus SDK-hídjának része, és a naplóprocesszorok csak az új OpenTelemetry-alapú kialakítással működnek.

Hol kaphatok további információt a telemetriai processzorokról?

További információ: Telemetriai processzorok (előzetes verzió) – Azure Monitor Application Insights for Java.

JavaScript SDK

Mik a felhasználók és a munkamenetek száma?

• A JavaScript SDK beállít egy felhasználói cookie-t a webes ügyfélen a visszatérő felhasználók azonosításához, valamint egy munkamenet-cookie-t a tevékenységek csoportosításához.
• Ha nincs ügyféloldali szkript, beállíthatja a cookie-kat a kiszolgálón.
• Ha egy valódi felhasználó különböző böngészőkben használja a webhelyet, vagy privát/inkognitó böngészést vagy különböző gépeket használ, a rendszer többször is megszámolja őket.
• Ha egy bejelentkezett felhasználót szeretne azonosítani a gépeken és böngészőkben, adjon hozzá egy hívást a setAuthenticatedUserContext() beállításhoz.

Mi a JavaScript SDK teljesítménye/többletterhelése?

Az Application Insights JavaScript SDK minimális többletterheléssel rendelkezik a webhelyén. Az SDK mindössze 36 KB-os méretű, és csak ~15 ms-ot vesz igénybe az inicializáláshoz, az SDK elhanyagolható mennyiségű betöltési időt ad hozzá a webhelyhez. Az SDK használatakor a kódtár minimális összetevői gyorsan betölthetők, és a teljes szkript a háttérben lesz letöltve.

Emellett, miközben a szkript a CDN-ből tölt le, az oldal minden nyomon követése várólistára kerül, így a lap teljes életciklusa során nem veszít el telemetriát. Ez a beállítási folyamat zökkenőmentes elemzési rendszert biztosít a lapnak, amely láthatatlan a felhasználók számára.

Milyen böngészőket támogat a JavaScript SDK?

Chrome legújabb ✔	Firefox legújabb ✔	v3.x: IE 9+ > Microsoft Edge ✔ v2.x: IE 8+ kompatibilis & Microsoft Edge ✔	Opera legújabb ✔	Safari legújabb ✔

Hol találhatok példakódokat a JavaScript SDK-hoz?

Futtatható példákért tekintse meg az Application Insights JavaScript SDK-mintáit.

Mi az ES3/Internet Explorer 8 kompatibilitása a JavaScript SDK-val?

Meg kell hoznunk a szükséges intézkedéseket annak érdekében, hogy ez az SDK továbbra is "működjön", és ne törje meg a JavaScript végrehajtását, amikor egy régebbi böngésző betölti. Ideális lenne, ha nem támogatná a régebbi böngészőket, de számos nagy ügyfél nem tudja szabályozni, hogy a felhasználók melyik böngészőt használják.

Ez az állítás nem jelenti azt, hogy csak a legalacsonyabb általános funkciókat támogatjuk. Fenn kell tartanunk az ES3-kódkompatibilitást. Az új funkciókat úgy kell hozzáadni, hogy az ne törje meg az ES3 JavaScript-elemzést, és opcionális funkcióként legyen hozzáadva.

Az Internet Explorer 8 támogatásával kapcsolatos részletes információkért tekintse meg a GitHubot.

Nyílt forráskódú a JavaScript SDK?

Igen, az Application Insights JavaScript SDK nyílt forráskód. A forráskód megtekintéséhez vagy a projekthez való hozzájáruláshoz tekintse meg a hivatalos GitHub-adattárat.

Hol kaphatok további információt a JavaScript SDK-ról?

További információ: Az Azure Monitor Application Insights valós felhasználói monitorozásának engedélyezése.

JavaScript SDK-konfiguráció

Hogyan frissíthetem a külső kiszolgáló konfigurációját a JavaScript SDK-hoz?

A kiszolgálóoldalnak képesnek kell lennie a jelen lévő fejlécekkel való kapcsolatok elfogadására. A kiszolgálóoldali konfigurációtól függően gyakran szükséges a kiszolgálóoldali lista kiterjesztése a Access-Control-Allow-Headers, Request-Id, és Request-Context elemek manuális hozzáadásával (W3C elosztott fejléc).

Access-Control-Allow-Headers: Request-Id, traceparent, , Request-Context<your header>

Hogyan tilthatom le az elosztott nyomkövetést a JavaScript SDK-hoz?

Az elosztott nyomkövetés konfigurációban letiltható.

Az Application Insights mindig rögzíti a HTTP 502 és 503 válaszokat?

Nem. Az Application Insights nem mindig rögzíti az "502 hibás átjáró" és az "503 szolgáltatás nem érhető el" hibákat. Ha csak ügyféloldali JavaScriptet használ a monitorozáshoz, ez a viselkedés azért várható, mert a hibaválasz a HTML-fejlécet tartalmazó oldal előtt jelenik meg, és megjelenik a figyelési JavaScript-kódrészlet.

Ha az 502- vagy az 503-at kiszolgálóoldali monitorozással rendelkező kiszolgálóról küldték, a hibákat az Application Insights SDK gyűjti össze.

Még akkor is, ha egy alkalmazás webkiszolgálóján engedélyezve van a kiszolgálóoldali monitorozás, az Application Insights néha nem rögzíti az 502-503-at. Számos modern webkiszolgáló nem teszi lehetővé az ügyfél számára a közvetlen kommunikációt. Ehelyett olyan megoldásokat alkalmaznak, mint a fordított proxyk, hogy az adatokat oda-vissza továbbítják az ügyfél és az előtérbeli webkiszolgálók között.

Ebben az esetben előfordulhat, hogy egy 502-es vagy 503-es választ ad vissza egy ügyfélnek a fordított proxyrétegen jelentkező probléma miatt, így az Application Insights nem rögzíti a rendszerből. A réteg problémáinak észleléséhez előfordulhat, hogy a fordított proxyból a Log Analyticsbe kell továbbítania a naplókat, és létre kell hoznia egy egyéni szabályt, amely 502 vagy 503 választ keres. Az 502-ben és 503-ban előforduló hibák gyakori okairól az "502 hibás átjáró" és az "503 szolgáltatás nem érhető el" HTTP-hibáinak hibaelhárítása Azure-alkalmazás szolgáltatásban című témakörben olvashat.

Hol kaphatok további információt a JavaScript SDK konfigurációjáról?

További információ: Application Insights JavaScript SDK-konfiguráció.

JavaScript-keretrendszerbővítmények

Hogyan hozza létre az Application Insights az eszközadatokat, például a böngészőt, az operációs rendszert, a nyelvet és a modellt?

A böngésző átadja a User Agent karakterláncot a kérés HTTP-fejlécében. Az Application Insights betöltési szolgáltatás az UA Parser használatával hozza létre az adattáblákban és -szolgáltatásokban látható mezőket. Ennek eredményeképpen az Application Insights felhasználói nem tudják módosítani ezeket a mezőket.

Előfordulhat, hogy ezek az adatok hiányoznak vagy pontatlanok, ha a felhasználó vagy a vállalat letiltja a felhasználói ügynök küldését a böngésző beállításai között. Előfordulhat, hogy az UA Parser regexes nem tartalmazza az összes eszközinformációt. Vagy előfordulhat, hogy az Application Insights nem fogadta el a legújabb frissítéseket.

Hol kaphatok további információt a JavaScript-keretrendszer bővítményeiről?

További információ: Keretrendszerbővítmény engedélyezése az Application Insights JavaScript SDK-hoz.

Felügyelt munkaterületek

Frissíteni kell a klasszikus erőforrásokra hivatkozó szkripteket vagy automatizálást?

Nem. A meglévő ARM-sablonok és API-hívások továbbra is működnek. Amikor klasszikus erőforrást próbál létrehozni, a rendszer ehelyett egy felügyelt munkaterületet tartalmazó munkaterület-alapú erőforrást hoz létre.

Értesítést kapok az erőforrás migrálása előtt?

Nem. Az egyes erőforrás-áttelepítésekről szóló értesítés nem érhető el. Az erőforrások migrálásának időpontjának és módjának szabályozásához használja a manuális migrálást.

Mennyi ideig tart a migrálási folyamat?

Az egyes áttelepítések általában kevesebb mint két perc alatt befejeződnek. A teljes bevezetés több héten keresztül zajlik az összes régióban.

Hogyan állapíthatom meg, hogy egy erőforrás migrálva van-e?

A migrálás után az erőforrás egy Log Analytics-munkaterületre mutat az Áttekintés lapon. A rendszer eltávolítja a klasszikus kivonási értesítést, és a kivonási munkafüzet már nem sorolja fel az erőforrást.

Változik a számlázásom a migrálás után?

A költségek általában hasonlóak maradnak. A munkaterület-alapú Application Insights költségmegtakarítási funkciókat tesz lehetővé, és javasoljuk, hogy tekintse át a díjszabási csomagokat.

Ha régi számlázási modellen dolgozik, a részletekért tekintse át a díjszabási dokumentációt .

Elveszíthetem a riasztásokat vagy a rendelkezésre állási teszteket a migrálás során?

Nem. Az összes riasztás, irányítópult és rendelkezésre állási teszt érintetlen marad, és a migrálás után is működik.

Hol kaphatok további információt a felügyelt munkaterületekről?

További információ: Felügyelt munkaterületek az Application Insightsban.

Node.js

Hogyan tilthatom le a telemetriai korrelációt?

A telemetriai korreláció letiltásához használja a tulajdonságot a correlationHeaderExcludedDomains konfigurációban. További információ: ApplicationInsights-node.js.

Hogyan konfigurálhatom a kívánt naplószintet?

Az Application Insights által használni kívánt naplószint konfigurálásához használja a környezeti változót APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . A támogatott értékek: NONE, ERROR, WARN, INFO, DEBUG, VERBOSE és ALL. További információ: ApplicationInsights-node.js.

Hol kaphatok további információt Node.js szolgáltatások és alkalmazások monitorozásáról az Application Insights használatával?

További információ: A Node.js-szolgáltatások és -alkalmazások monitorozása az Application Insights használatával.

Azure Monitor és OpenTelemetry

Hol találhatók az Application Insights SDK-verziók és azok nevei?

Az SDK-verziók és -nevek listája a GitHubon található. További információ: SDK-verzió.

Hol kaphatok további információt az OpenTelemetryről?

További információ: Telemetriai adatok gyűjtése OpenTelemetry használatával az Application Insightsban.

Migrálás .NET Application Insights SDK-kból az Azure Monitor OpenTelemetrybe

Hogyan képezik le az SDK API-k az OpenTelemetry fogalmait?

Az OpenTelemetry egy szállítósemleges megfigyelhetőségi keretrendszer. Az OpenTelemetry SDK-ban vagy tárakban nincsenek Application Insights API-k. A migrálás előtt fontos tisztában lenni az OpenTelemetry néhány alapfogalmaival.

• Az Application Insightsban az összes telemetriát egyetlen TelemetryClient és TelemetryConfigurationegy . Az OpenTelemetria esetében a három telemetriai jel (Traces, Metrics és Logs) mindegyike saját konfigurációval rendelkezik. A .NET-futtatókörnyezeten keresztül manuálisan is létrehozhat telemetriát külső kódtárak nélkül. További információ: .NET-útmutatók az elosztott nyomkövetésről, a metrikákról és a naplózásról.

• Az Application Insights az alkalmazás telemetriai adatainak automatikus gyűjtésére szolgál TelemetryModules . Ehelyett az OpenTelemetry Instrumentation-kódtárak használatával gyűjt telemetriát adott összetevőkből (például AspNetCore for Requests és HttpClient for Dependencies).

• Az Application Insights TelemetryInitializers további információkkal bővíti a telemetriát, vagy felülírja a tulajdonságokat. Az OpenTelemetria segítségével egy processzort írhat egy adott jel testreszabásához. Emellett számos OpenTelemetry Instrumentation-kódtár kínál metódust Enrich az adott összetevő által létrehozott telemetriai adatok testreszabására.

• A telemetriai adatok szűréséhez használt TelemetryProcessors Application Insights. Az OpenTelemetria-feldolgozóval szűrési szabályokat is alkalmazhat egy adott jelre.

Hogyan képezhető le az Application Insights telemetriai típusai az OpenTelemetryre?

Ez a táblázat az Application Insights adattípusait OpenTelemetry-fogalmakra és azok .NET-implementációira képezi le.

Azure Monitor-tábla	Application Insights adattípus	OpenTelemetry adattípus	.NET-implementáció
egyedi események	EventTelemetria	Nincs adat.	Nincs adat.
egyedi metrikák	MetricTelemetry	Mértékek	System.Diagnostics.Metrics.Meter
függőségek	DependencyTelemetria	Spans (ügyfél, belső, fogyasztó)	System.Diagnostics.Activity
Kivételek	ExceptionTelemetry	Kivételek	System.Exception
Kérelmek	RequestTelemetry (Kéréses Telemetria)	Spans (kiszolgáló, gyártó)	System.Diagnostics.Activity
hívásláncok	Nyomkövető Telemetria	Naplók	Microsoft.Extensions.Logging.ILogger
hívásláncok	Nyomkövető Telemetria	Események időtartama	System.Diagnostics.ActivityEvent

Az alábbi dokumentumok további információkat tartalmaznak.

• Az Azure Monitor Application Insights adatgyűjtési alapjai
• Application Insights telemetria adatmodell
• Az OpenTelemetry fogalmai

Hogyan képezi le az Application Insights mintavételezési fogalmait az OpenTelemetry?

Bár az Application Insights több lehetőséget is kínált a mintavételezés konfigurálására, az Azure Monitor Exportőr vagy az Azure Monitor Disztribúció csak rögzített gyakoriságú mintavételezést kínál. Csak a kérelmek és függőségek (OpenTelemetry Traces) mintavétele használható.

A mintavételezés konfigurálásának módját részletező kódmintákért tekintse meg a mintavételezés engedélyezése című útmutatót

Hogyan képezik le a telemetriai processzorok és az inicializálók az OpenTelemetryt?

Az Application Insights .NET SDK-ban telemetriai processzorokkal szűrheti és módosíthatja vagy elvetheti a telemetriát. A telemetriai inicializálókkal egyéni tulajdonságokat adhat hozzá vagy módosíthat. További információkért tekintse meg az Azure Monitor dokumentációját. Az OpenTelemetry ezeket a fogalmakat tevékenység- vagy naplófeldolgozókra cseréli, amelyek bővítik és szűrik a telemetriát.

Nyomkövetések szűrése

Az OpenTelemetry telemetriai adatainak szűréséhez megvalósíthat egy tevékenységfeldolgozót. Ez a példa egyenértékű az Application Insights-példával a telemetriai adatok szűréséhez az Azure Monitor dokumentációjában leírtak szerint. A példa bemutatja, hogy hol szűri a sikertelen függőségi hívásokat.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

A processzor használatához előbb létre kell hoznia egy processzort TracerProvider , majd hozzá kell adnia a processzort AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Naplók szűrése

ILoggeraz implementációk beépített mechanizmussal rendelkeznek a naplószűrés alkalmazásához. Ezzel a szűréssel szabályozhatja az egyes regisztrált szolgáltatóknak küldött naplókat, beleértve a OpenTelemetryLoggerProvider. Az "OpenTelemetry" a szűrési szabályok konfigurálásához használt aliasOpenTelemetryLoggerProvider.

Az alábbi példa a "Hiba" értéket határozza meg alapértelmezettként LogLevel , és a "Figyelmeztetés" értéket is definiálja a felhasználó által definiált kategóriák minimális LogLevel értékeként. Ezek a definiált szabályok csak a OpenTelemetryLoggerProvider.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

További információkért olvassa el az OpenTelemetry .NET dokumentációját a naplókban.

Egyéni tulajdonságok hozzáadása nyomkövetésekhez

Az OpenTelemetryben tevékenységprocesszorokkal bővítheti a telemetriai adatokat további tulajdonságokkal. Hasonló az Application Insights telemetriai inicializálóihoz, ahol módosíthatja a telemetriai tulajdonságokat.

Az Azure Monitor Exporter alapértelmezés szerint megjelöli a sikertelennek minősülő 400-as vagy annál nagyobb válaszkóddal rendelkező HTTP-kéréseket. Ha azonban sikerként szeretné kezelni a 400-ast, hozzáadhat egy bővítő tevékenységfeldolgozót, amely beállítja a tevékenység sikerét, és hozzáad egy címkét, amely további telemetriai tulajdonságokat tartalmaz. Hasonló a tulajdonságok hozzáadásához vagy módosításához az Application Insights inicializálójával az Azure Monitor dokumentációjában leírtak szerint.

Íme egy példa arra, hogyan adhat hozzá egyéni tulajdonságokat, és hogyan bírálhatja felül bizonyos válaszkódok alapértelmezett viselkedését:

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

A processzor használatához előbb létre kell hoznia egy processzort TracerProvider , majd hozzá kell adnia a processzort AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Hogyan manuálisan nyomon követni a telemetriát az OpenTelemetry használatával?

Nyomkövetések küldése – Manuális

Az Application Insights nyomkövetéseit a rendszer a következő formátumban RequestTelemetry tárolja: és DependencyTelemetry. Az OpenTelemetryben a nyomkövetések az Span osztály használatával modellezhetőkActivity.

Az OpenTelemetry .NET a ActivitySource .NET-futtatókörnyezet részét képező nyomkövetési osztályokat és Activity osztályokat használja. Ez a megközelítés azért megkülönböztető, mert a .NET-implementáció közvetlenül a futtatókörnyezetbe integrálja a nyomkövetési API-t. A System.Diagnostics.DiagnosticSource csomag lehetővé teszi a fejlesztők számára a ActivitySource példányok létrehozását és kezelését Activity . Ez a módszer zökkenőmentes módot biztosít a .NET-alkalmazások nyomkövetésének hozzáadására külső kódtárak használata nélkül, a .NET-ökoszisztéma beépített képességeinek alkalmazásával. Részletesebb információkért tekintse meg az elosztott nyomkövetési rendszerállapot útmutatóit.

A manuális nyomkövetés migrálása az alábbiak szerint lehetséges:

Megjegyzés:

Az Application Insightsban a szerepkör neve és szerepkörpéldánya telemetriaszinten állítható be. Az Azure Monitor-exportőr esetében azonban nem tudunk telemetriaszinten testre szabni. A szerepkör nevét és szerepkörpéldányát a rendszer kinyeri az OpenTelemetry erőforrásból, és alkalmazza az összes telemetriára. További információért olvassa el ezt a dokumentumot: Állítsa be a felhőbeli szerepkör nevét és a felhőbeli szerepkörpéldányt.

DependencyTelemetria

Az Application Insights DependencyTelemetry a kimenő kérések modellezésére szolgál. Az alábbiak szerint konvertálhatja OpenTelemetryre:

Példa az Application Insights szolgáltatásra:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

OpenTelemetria- példa:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

RequestTelemetry (Kéréses Telemetria)

Az Application Insights RequestTelemetry modelleli a bejövő kéréseket. Az alábbiak szerint migrálhatja az OpenTelemetrybe:

Példa az Application Insights szolgáltatásra:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

OpenTelemetria- példa:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

Egyéni műveletek nyomon követése

Az Application Insightsban kövesse nyomon az egyéni műveleteket és StartOperationStopOperation metódusokat. Ezt az OpenTelemetry .NET használatával ActivitySource és Activity használatával érheti el. Az Azure Monitor Exportőrrel végzett ActivityKind.ServerActivityKind.Consumerműveletekhez az Azure Monitor Exporter generál RequestTelemetry. A ActivityKind.Client, ActivityKind.Producerés ActivityKind.Internala generált DependencyTelemetry. Az egyéni műveletek nyomon követésével kapcsolatos további információkért tekintse meg az Azure Monitor dokumentációját. A .NET használatával ActivitySource és Activity használatával kapcsolatos további információkért tekintse meg a .NET elosztott nyomkövetési eszközökkel kapcsolatos útmutatókat.

Íme egy példa az egyéni műveletek tevékenységének elindítására és leállítására:

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

Naplók küldése

Az Application Insights naplóit a rendszer a következő formátumban TraceTelemetry tárolja: és ExceptionTelemetry.

Nyomkövető Telemetria

Az OpenTelemetryben a naplózás az ILogger interfészen keresztül integrálva van. Az alábbiak szerint migrálhatja TraceTelemetrya következőt:

Példa az Application Insights szolgáltatásra:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

OpenTelemetria- példa:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

ExceptionTelemetry

Az Application Insights kivételeket naplóz ExceptionTelemetry . Az Alábbiak szerint migrálhat az OpenTelemetrybe:

Példa az Application Insights szolgáltatásra:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

OpenTelemetria- példa:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

Metrikák küldése

Az Application Insights metrikái a következőképpen vannak tárolva MetricTelemetry: . Az OpenTelemetryben a metrikák a Meter csomagból modellezhetőkSystem.Diagnostics.DiagnosticSource.

Az Application Insights nem előre összesítő (TrackMetric()) és preaggregating (GetMetric().TrackValue()) metrika API-kkal is rendelkezik. Az OpenTelemetryvel ellentétben az Application Insights nem rendelkezik eszközökkel. Az Application Insights minden metrikaforgatókönyvhez ugyanazzal az API-val rendelkezik.

Az OpenTelemetria azonban megköveteli, hogy a felhasználók először a metrika tényleges szemantikája alapján válasszák ki a megfelelő metrikaeszközt . Ha például a szándék valami megszámlálása (például a fogadott kiszolgálói kérelmek száma stb.), akkor az OpenTelemetry Számlálót kell használni. Ha a cél különböző percentilisek kiszámítása (például a kiszolgáló késésének P99-értéke), akkor az OpenTelemetria hisztogram eszközt kell használni. Az Application Insights és az OpenTelemetria közötti alapvető különbség miatt nem történik közvetlen összehasonlítás közöttük.

Az Application Insightstól eltérően az OpenTelemetria nem biztosít beépített mechanizmusokat a metrikák bővítéséhez vagy szűréséhez. Az Application Insightsban telemetriai processzorok és inicializálók használhatók metrikák módosítására vagy elvetésére, de ez a képesség nem érhető el az OpenTelemetryben.

Emellett az OpenTelemetria nem támogatja a nyers metrikák közvetlen küldését, mivel nincs egyenértékű az TrackMetric() Application Insightsban található funkcióval.

Az Application Insights-ból az OpenTelemetrybe való migrálás során az Összes Application Insights Metric API-használat lecserélése az OpenTelemetry API-ra. Ehhez ismernie kell a különböző OpenTelemetry-eszközöket és azok szemantikáját.

Jótanács

A hisztogram a legsokoldalúbb és a legközelebbi egyenértékű az Application Insights GetMetric().TrackValue() API-val. Az Application Insights metrika API-jait lecserélheti hisztogramra, hogy ugyanazt a célt elérjék.

Egyéb telemetriai típusok

Egyéni események

Az OpenTelemetria nem támogatott.

Példa az Application Insights szolgáltatásra:

TelemetryClient.TrackEvent()

Elérhetőség Telemetria

Az OpenTelemetria nem támogatott.

Példa az Application Insights szolgáltatásra:

TelemetryClient.TrackAvailability()

Oldalmegtekintés Telemetria

Az OpenTelemetria nem támogatott.

Példa az Application Insights szolgáltatásra:

TelemetryClient.TrackPageView()

Kaphatok élő metrikákat a konzol- és feldolgozószolgáltatás-alkalmazásokhoz?

Javasoljuk az Azure Monitor OpenTelemetry-exportőrt a konzol- és feldolgozószolgáltatás-alkalmazásokhoz, amelyek nem tartalmaznak élő metrikákat.

Hol kaphatok további információt a .NET Application Insights SDK-kból az OpenTelemetrybe való migrálásról?

További információ: Migrálás a .NET Application Insights SDK-ból az Azure Monitor OpenTelemetrybe.

OpenTelemetria-mintavételezés

Az Application Insights egyéni mintavételi folyamata tail-alapú?

Az Application Insights egyéni mintavevője a mintavételezési döntéseket a span létrehozása után hozza meg, nem pedig előtte, így nem követi a hagyományos, fejalapú megközelítést. Ehelyett a mintavételezési döntéseket a kiterjedési szakasz generálása végén alkalmazza – a kiterjedési szakasz befejezése után, de az exportálás előtt.

Bár ez a viselkedés bizonyos szempontból hasonlít a tail-alapú mintavételezésre, a mintavevő nem várja meg, hogy több időtartamot gyűjtsön ugyanabból a nyomból, mielőtt meghozná a mintavételi döntést. Ehelyett a nyomkövetési azonosító kivonatával biztosítja a nyomkövetés teljességét.

Ez a megközelítés kiegyensúlyozza a nyomkövetés teljességét és hatékonyságát, és elkerüli a teljes farokalapú mintavételezéssel járó magasabb költségeket.

Ahhoz, hogy mintavételezési döntéseket hozzon egy teljes nyomkövetés eredménye alapján (például annak meghatározásához, hogy a nyomkövetésen belüli bármely időtartam sikertelen volt-e), teljes, tail-alapú mintavételezésre van szükség egy alsóbb rétegbeli ügynökben vagy gyűjtőben. Ez a funkció jelenleg nem támogatott, de a Visszajelzési központon keresztül kérheti új funkcióként.

Hogyan hasonlítja össze az Application Insights egyéni mintavevője az OpenTelemetry fej- vagy farokalapú mintavételezését?

Mintavételezési módszer	Döntési pont	Erősségek	Gyenge pontok
Fejközpontú	Egy szakasz kezdete előtt	Alacsony késés, minimális többletterhelés	Mintát vehet a kívánt nyomkövetési mintákból, beleértve a hibákat is
Tail-alapú	A szakaszok idő- vagy kötetküszöbök alapján történő pufferelése után	Lehetővé teszi a szigorúan szelektív nyomkövetési mintavételezési kritériumokat	Magasabb költség és hozzáadott feldolgozási késés
Egyéni App Insights-mintavevő	A tartománygenerálás vége	A nyomkövetési teljesség és a hatékonyság egyensúlya	Élő metrikákhoz és klasszikus API-kompatibilitáshoz szükséges

Különböző rátákon mintázhatok függőségeket, kéréseket vagy egyéb telemetriai típusokat?

Nem, a mintavevő rögzített sebességet alkalmaz a nyomkövetés összes telemetriai típusára. A kérelmek, függőségek és egyéb tartományok ugyanazt a mintavételezési százalékot követik. A telemetriai típusonként különböző arányok beállításához fontolja meg az OpenTelemetry span processzorok vagy (adatbevételi időben történő átalakítások)[opentelemetry-overview.md#telemetry-routing] használatát.

Hogyan propagálja az Application Insights egyéni mintavevő a mintavételezési döntéseket?

Az Application Insights egyéni mintavevő alapértelmezés szerint a W3C Trace Context szabvány használatával propagálja a mintavételezési döntéseket. Ez a szabvány lehetővé teszi a mintavételezési döntéseket a szolgáltatások között. Mivel azonban a mintavevő a mintavételezési döntéseket a span generáció végén hozza meg – az alsóbb rétegbeli szolgáltatások hívása után –, a propagálás hiányos mintavételi információkat tartalmaz. Ez a korlátozás megfelel a W3C nyomkövetési környezet specifikációjának, de az alárendelt szolgáltatások nem tudják megbízhatóan használni ezt a propagált mintavételezési döntést.

Az Application Insights egyéni mintavevője tiszteletben tartja a felsőbb rétegbeli szolgáltatások mintavételezési döntéseit?

Nem, az Application Insights egyéni mintavevője mindig független mintavételezési döntést hoz, még akkor is, ha a felsőbb rétegbeli szolgáltatás ugyanazt a mintavételezési algoritmust használja. A felsőbb rétegbeli szolgáltatásokból – beleértve a W3C Trace Context fejléceket használókat is – származó mintavételezési döntések nem befolyásolják az alsóbb rétegbeli szolgáltatás döntését. A nyomkövetési azonosító kivonata alapján azonban mintát is végez a nyomkövetés teljességének biztosítása érdekében. A konzisztencia javítása és a hibás nyomkövetések esélyének csökkentése érdekében konfigurálja a rendszer összes összetevőjét ugyanarra a mintavevőre és mintavételezési sebességre.

Miért jelennek meg egyes nyomkövetések hiányosan az Application Insights egyéni mintavevő használatakor is?

A nyomkövetések több okból is hiányosnak tűnhetnek:

• Az elosztott rendszerek különböző csomópontjai különböző mintavételezési módszereket használnak, amelyek nem koordinálják a döntéseket. Az egyik csomópont például openTelemetria-alapú mintavételezést alkalmaz, egy másik csomópont pedig az Azure Monitor Egyéni mintavevőn keresztüli mintavételezést.
• A különböző csomópontok eltérő mintavételezési sebességre vannak beállítva, még akkor is, ha mindkettő ugyanazt a mintavételezési módszert használja.
• A szolgáltatás oldali adatfolyamban állíthatja be a szűrést, mintavételezést vagy sebességkorlátokat, és ez a konfiguráció véletlenszerűen mintavételezi a szakaszokat anélkül, hogy figyelembe venné a nyomkövetés teljességét.

Ha egy összetevő fejlécalapú mintavételezést alkalmaz a mintavételezési döntés propagálása nélkül (a W3C Trace Context fejlécek révén), a lefelé mutató szolgáltatások függetlenül mintát vesznek a nyomkövetésből, ami eldobott szakaszokat eredményezhet. Ennek eredményeképpen a nyomkövetés egyes részei nem mindig érhetők el az Application Insightsban való megtekintéskor.

Hol kaphatok további információt az OpenTelemetry mintavételezéséről?

További információ: Mintavételezés az Azure Monitor Application Insightsban OpenTelemetry használatával.

OpenTelemetry-támogatás és visszajelzés

Mi az OpenTelemetria?

Ez egy nyílt forráskódú szabvány a megfigyelhetőséghez. További információ az OpenTelemetryről.

Miért fektet be a Microsoft Azure Monitor az OpenTelemetrybe?

A Microsoft az alábbi okokból fektet be az OpenTelemetrybe:

• Szállítósemleges, és egységes API-kat/SDK-kat biztosít a nyelvek között.
• Úgy gondoljuk, hogy az OpenTelemetry idővel lehetővé teszi az Azure Monitor-ügyfelek számára, hogy a támogatott nyelveken kívül más nyelveken írt alkalmazásokat figyeljenek meg.
• Kibővíti az instrumentációs könyvtárak gazdag készletén keresztül gyűjthető adattípusokat.
• Az OpenTelemetry Software Development Kits (SDK-k) általában nagyobb teljesítményűek, mint elődjeik, az Application Insights SDK-k.
• Az OpenTelemetria megfelel a Microsoft stratégiájának, amely nyílt forráskód.

Mi az OpenTelemetria állapota?

Lásd: OpenTelemetry Status.

Mi az Azure Monitor OpenTelemetry Distro?

Úgy tekinthet rá, mint egy vékony burkolóra, amely összecsomagol minden OpenTelemetry-összetevőt egy első osztályú Azure-élmény érdekében. Ezt a burkolót az OpenTelemetryben disztribúciónak is nevezik.

Miért érdemes használni az Azure Monitor OpenTelemetry Distro-t?

Az Azure Monitor OpenTelemetry Distro használatának számos előnye van a közösség natív OpenTelemetry-ével szemben:

• Csökkenti az engedélyezési erőfeszítéseket
• A Microsoft támogatja
• Bevezeti az Azure-specifikus funkciókat, mint például a következők:
  • Klasszikus Application Insights SDK-kkal kompatibilis mintavételezés
  • Microsoft Entra hitelesítés
  • Offline tárolás és automatikus újrapróbálás
  • Statsbeat
  • Application Insights Standard metrikák
  • Erőforrás-metaadatok észlelése a felhőszerepkör nevének és a felhőbeli szerepkörpéldánynak a különböző Azure-környezeteken való automatikus feltöltéséhez
  • Élő metrikák

Az OpenTelemetria szellemében úgy terveztük meg a disztribúciót, hogy nyitott és bővíthető legyen. Hozzáadhatja például a következőt:

• OpenTelemetry Protocol (OTLP) exportőr, és egyidejűleg küldje el egy második célállomásra.
• A disztribúcióban nem szereplő egyéb eszközkönyvtárak

Mivel a Disztribúció OpenTelemetria-disztribúciót biztosít, a Disztribúció az OpenTelemetria által támogatott bármit támogat. Hozzáadhat például több telemetriai processzort, exportőrt vagy rendszerállapot-kódtárat, ha az OpenTelemetria támogatja őket.

Megjegyzés:

A disztribúció testreszabott, rögzített arányú mintavevőre állítja a mintavevőt az Application Insights-hoz. Ezt módosíthatja egy másik mintavevőre, de ezzel letilthatja a Disztribúció egyes funkcióit. A támogatott mintavevőről az Azure Monitor OpenTelemetria konfigurálásának mintavételezés engedélyezése című szakaszában talál további információt.

A támogatott önálló OpenTelemetry-exportőr nélküli nyelvek esetében az Azure Monitor OpenTelemetry Distro az egyetlen jelenleg támogatott módszer az OpenTelemetry és az Azure Monitor használatára. A támogatott önálló OpenTelemetry-exportőrrel rendelkező nyelvek esetében lehetősége van az Azure Monitor OpenTelemetry Distro vagy a megfelelő önálló OpenTelemetry-exportőr használatára a telemetriai forgatókönyvtől függően. További információ: Mikor érdemes használni az Azure Monitor OpenTelemetry-exportőrt?.

Hogyan tesztelhetem az Azure Monitor OpenTelemetry disztribúciót?

Tekintse meg a .NET, a Java, a JavaScript (Node.js) és a Python engedélyezési dokumentációját.

Használjam az OpenTelemetryt vagy az Application Insights SDK-t?

Az Azure Monitor OpenTelemetry Distro használatát javasoljuk új projektekhez, ha képességei megfelelnek a monitorozási igényeknek. Az OpenTelemetry egy iparági szabványnak megfelelő keretrendszer, amely javítja a platformfüggetlen megfigyelhetőséget, és szabványosított megközelítést biztosít a telemetriai adatgyűjtéshez.

Az Application Insights SDK-k azonban továbbra is biztosítanak bizonyos képességeket, amelyek még nem teljesen automatizáltak az OpenTelemetryben, beleértve a következőket:

• Automatikus függőségkövetés – Az OpenTelemetria támogatja a függőségek nyomon követését, de egyes függőségek további konfigurációt igényelnek az Application Insights SDK-kban elérhető automatikus nyomkövetéshez képest.
• Egyéni telemetriai típusok, például AvailabilityTelemetry és PageViewTelemetry – Az OpenTelemetria nem rendelkezik közvetlen egyenértékűségekkel. Hasonló funkciók manuális rendszerezéssel valósíthatók meg.
• Telemetriai processzorok és inicializálók – Az OpenTelemetry processzorokkal és span processzorokkal rendelkezik, de nem helyettesítik teljesen az Application Insights telemetriai processzorait és inicializálóit minden forgatókönyvben.
• Kiterjesztett metrikák gyűjteménye – Bár az OpenTelemetria erős metrikarendszerrel rendelkezik, az Application Insights SDK-k beépített metrikáinak egy része manuális beállítást igényel az OpenTelemetryben.

Az OpenTelemetria az Application Insights SDK-kkal szemben is kínál előnyöket, például:

• Jobb szabványosítás a platformok között
• Az instrumentumkönyvtárak szélesebb ökoszisztémája
• Nagyobb rugalmasság az adatgyűjtés és -feldolgozás terén
• Továbbfejlesztett szállítósemlegesség, bár az Azure Monitor OpenTelemetry Distro továbbra is az Azure-ra van optimalizálva.

Az Azure Monitor OpenTelemetry-integrációja folyamatosan fejlődik, és a Microsoft továbbra is fejleszti képességeit. Ha áttűnést fontolgat, gondosan értékelje ki, hogy az OpenTelemetria jelenleg megfelel-e a megfigyelhetőségi követelményeknek, vagy az Application Insights SDK továbbra is megfelel az igényeinek.

Mikor érdemes használni az Azure Monitor OpenTelemetry-exportőrt?

ASP.NET Core, Java, Node.js és Python esetén az Azure Monitor OpenTelemetry Distro használatát javasoljuk. Ez egy kódsor az első lépésekhez.

Minden más .NET-forgatókönyv esetében, beleértve a klasszikus ASP.NET, a konzolalkalmazásokat, a Windows Formst (WinForms) stb., javasoljuk, hogy használja a .NET Azure Monitor OpenTelemetry exportőrt: Azure.Monitor.OpenTelemetry.Exporter.

Összetettebb, speciális konfigurációt igénylő Python-telemetriai forgatókönyvek esetén javasoljuk a Python Azure Monitor OpenTelemetry-exportőr használatát.

Mi az Azure Monitor OpenTelemetry Distro funkcióinak aktuális kiadási állapota?

Az alábbi diagram az Egyes nyelvek OpenTelemetry funkciójának támogatását mutatja be.

Tulajdonság	.HÁLÓ	Node.js	Piton	Jáva
Elosztott nyomkövetés	✅	✅	✅	✅
Egyéni metrikák	✅	✅	✅	✅
Standard metrikák	✅	✅	✅	✅
Rögzített gyakoriságú mintavételezés	✅	✅	✅	✅
Offline tárolás és automatikus újrapróbálás	✅	✅	✅	✅
Kivételjelentés	✅	✅	✅	✅
Naplók gyűjteménye	✅	⚠️	✅	✅
Egyéni események	⚠️	⚠️	⚠️	✅
Microsoft Entra hitelesítés	✅	✅	✅	✅
Élő metrikák	✅	✅	✅	✅
Élő metrikák szűrése	✅	❌	❌	❌
Erőforrás-környezet észlelése virtuális géphez/VMSS-hez és App Service-hez	✅	❌	✅	✅
Az Azure Kubernetes Service (AKS) és a Functions erőforrás-környezetének észlelése	❌	❌	❌	✅
A Rendelkezésre állás nyomon követése API használatával létrehozott rendelkezésre állási tesztelési események	❌	❌	❌	✅
Kérelmek, függőségek, naplók és kivételek szűrése névtelen felhasználói azonosító és szintetikus forrás alapján	❌	❌	❌	✅
Függőségek, naplók és kivételek szűrése műveletnév alapján	❌	❌	❌	✅
Adaptív mintavételezés	❌	❌	❌	✅
.NET Profiler	⚠️	❌	❌	⚠️
Képernyőkép-hibakereső	❌	❌	❌	❌

Kulcs

• ✅ Ez a funkció minden hivatalos támogatással rendelkező ügyfél számára elérhető.
• ⚠️ Ez a funkció nyilvános előzetes verzióként érhető el. Lásd a Microsoft Azure előzetes verziójának használati feltételeit.
• ❌ Ez a funkció nem érhető el, vagy nem alkalmazható.

Használható az OpenTelemetria webböngészőkhöz?

Igen, de nem javasoljuk, és az Azure nem támogatja. Az OpenTelemetry JavaScript nagymértékben optimalizálva van Node.js-ra. Ehelyett az Application Insights JavaScript SDK használatát javasoljuk.

Mikor várható, hogy az OpenTelemetry SDK elérhető lesz a webböngészőkben?

Az OpenTelemetry webes SDK nem rendelkezik meghatározott rendelkezésre állási ütemtervvel. Valószínűleg több évnyire vagyunk a böngésző SDK-tól, amely az Application Insights JavaScript SDK életképes alternatívája.

Tesztelhetem az OpenTelemetryt egy webböngészőben?

Az OpenTelemetry webes tesztkörnyezete egy elágazás, amely arra szolgál, hogy az OpenTelemetria működjön egy böngészőben. Még nem lehet telemetriát küldeni az Application Insightsnak. Az SDK nem definiál általános ügyféleseményeket.

Támogatott az Application Insights futtatása olyan versenytársakkal, mint az AppDynamics, a DataDog és a NewRelic?

Ezt a gyakorlatot nem tervezzük tesztelni vagy támogatni, bár distribúcióink lehetővé teszik, hogy egyszerre exportáljon egy OTLP-végpontra az Azure Monitor mellett.

Használhatok előzetes verziójú funkciókat éles környezetekben?

Nem javasoljuk. Lásd a Microsoft Azure előzetes verziójának használati feltételeit.

Mi a különbség a manuális és az automatikus rendszerállapot között?

Tekintse meg az OpenTelemetry áttekintését.

Használhatom az OpenTelemetry Collectort?

Egyes ügyfelek az OpenTelemetry Collectort használják ügynök alternatívaként, annak ellenére, hogy a Microsoft hivatalosan még nem támogatja az alkalmazásfigyelés ügynökalapú megközelítését. Addig is a nyílt forráskódú közösség hozzájárult egy OpenTelemetry Collector Azure Monitor-exportőrhöz , amellyel egyes ügyfelek adatokat küldenek az Azure Monitor Application Insightsnak. Ezt a Microsoft nem támogatja.

Mi a különbség az OpenCensus és az OpenTelemetria között?

Az OpenCensus az OpenTelemetria előfutára. A Microsoft segített összehozni az OpenTracinget és az OpenCensust az OpenTelemetria létrehozásához, amely a világ egyetlen megfigyelhetőségi szabványa. Az Azure Monitorhoz készült, jelenleg ajánlott éles használatra szánt Python SDK az OpenCensuson alapul. A Microsoft elkötelezett az Azure Monitor OpenTelemetria-alapúvá tétele mellett.

Grafana, miért látom a "Status 500. A nyomkövetési események nem jeleníthetők meg a nyomkövetési vizualizációval?

Az OpenTelemetry-nyomkövetések helyett nyers szöveges naplókat is megpróbálhat vizualizálni.

Az Application Insightsban a "Traces" tábla diagnosztikai célokra tárolja a nyers szöveges naplókat. Segítséget nyújt a felhasználói kérésekhez, egyéb eseményekhez és kivételjelentésekhez kapcsolódó nyomkövetések azonosításához és korrelálásához. A "Traces" tábla azonban nem járul hozzá közvetlenül a végpontok közötti tranzakciós nézethez (vízesésdiagram) olyan vizualizációs eszközökben, mint a Grafana.

A felhőalapú gyakorlatok egyre elterjedtebbé válása miatt a telemetria gyűjtése és terminológia is folyamatosan fejlődik. Az OpenTelemetria a telemetriai adatok gyűjtésének és rendszerezésének szabványává vált. Ebben az összefüggésben a "Traces" kifejezés új értelmet kapott. A nyers naplók helyett az OpenTelemetryben a "Traces" a telemetriai adatok gazdagabb, strukturált formájára utal, amely kiterjedéseket is tartalmaz, amelyek az egyes munkaegységeket jelölik. Ezek az időtartamok kulcsfontosságúak a részletes tranzakciónézetek létrehozásához, ami jobb monitorozást és diagnosztikát tesz lehetővé a natív felhőbeli alkalmazások számára.

Hogyan kell a Blazor Apps eszközt használni?

Egy Blazor-alkalmazás instrumentálásához először azonosítsa az üzemeltetési modellt. A Blazor Server támogatja a teljes OpenTelemetria-alapú rendszerezést. A Blazor WebAssembly a böngészőben fut, és JavaScript-en keresztül támogatja a korlátozott műszeres támogatást.

Hol kaphatok további információt az OpenTelemetry támogatásáról és visszajelzéséről?

További információ: OpenTelemetry Support and Feedback for Application Insights.

Áttekintés irányítópult

Megjeleníthetek több mint 30 napnyi adatot?

Nem, egy irányítópulton legfeljebb 30 napnyi adat jelenik meg.

"Erőforrás nem található" hibaüzenet jelenik meg az irányítópulton.

Ha áthelyezi vagy átnevezi az Application Insights-példányt, "nem található erőforrás" hibaüzenet jelenhet meg.

Ennek a viselkedésnek a megkerüléséhez törölje az alapértelmezett irányítópultot, és válassza újra az Alkalmazás irányítópultot egy új létrehozásához.

Hol kaphatok további információt az Áttekintés irányítópultról?

További információt az Application Insights áttekintési irányítópultján talál.

Telemetriai csatornák

Az Application Insights-csatorna garantálja a telemetria kézbesítését? Ha nem, mik azok a forgatókönyvek, amelyekben a telemetriai adatok elveszhetnek?

A rövid válasz az, hogy egyik beépített csatorna sem biztosít tranzakciótípusú garanciát a telemetria háttérbe történő kézbesítésére. ServerTelemetryChannel a megbízható kézbesítéshez képest InMemoryChannel fejlettebb, de a telemetriai adatok küldésére is csak a legjobb erőfeszítést teszi. A telemetriai adatok több esetben is elveszhetnek, beleértve az alábbi gyakori forgatókönyveket:

• A memóriában lévő elemek elvesznek, amikor az alkalmazás összeomlik.
• A telemetriai adatok a hálózati problémák hosszabb időszakában elvesznek. A rendszer a helyi lemezen tárolja a telemetriát a hálózatkimaradások vagy az Application Insights háttérrendszerével kapcsolatos problémák esetén. A rendszer azonban elveti a 48 óránál régebbi elemeket.
• A telemetriai adatok Windows rendszerben való tárolásának alapértelmezett lemezhelyei a következő: %LOCALAPPDATA% vagy %TEMP%. Ezek a helyek általában a géphez tartoznak. Ha az alkalmazás fizikailag egyik helyről a másikra migrál, az eredeti helyen tárolt telemetriai adatok elvesznek.
• A Windows Azure Web Appsben az alapértelmezett lemeztárolási hely a D:\local\LocalAppData. Ez a hely nem marad meg. Az alkalmazás újraindítása, a vertikális felskálázás és más ilyen műveletek során törlődik, ami az ott tárolt telemetriai adatok elvesztéséhez vezet. Felülbírálhatja az alapértelmezett értéket, és megadhatja a tárterületet egy olyan tartós helyre, mint a D:\home. Az ilyen fenntartott helyeket azonban távoli tárolók szolgálják ki, így lassúak is lehetnek.

Bár kevésbé valószínű, lehetséges, hogy a csatorna ismétlődő telemetriai elemeket okoz. Ez a viselkedés akkor fordul elő, ha ServerTelemetryChannel hálózati hiba vagy időtúllépés miatt újrapróbálkozik, amikor a telemetria a háttérrendszernek lett kézbesítve, de a válasz hálózati problémák vagy időtúllépés miatt elveszett.

Működik a ServerTelemetryChannel a Windowstól eltérő rendszereken?

Bár a csomag és a névtér neve tartalmazza a "WindowsServer" nevet, ez a csatorna a Windowstól eltérő rendszereken is támogatott, az alábbi kivétellel. A Windowstól eltérő rendszereken a csatorna alapértelmezés szerint nem hoz létre helyi tárolómappát. Létre kell hoznia egy helyi tárolómappát, és konfigurálnia kell a csatornát a használatára. A helyi tároló konfigurálása után a csatorna ugyanúgy működik az összes rendszeren.

Megjegyzés:

A 2.15.0-béta3-es és újabb kiadással a helyi tároló automatikusan létrejön Linux, Mac és Windows rendszeren. Nem Windows rendszerű rendszerek esetén az SDK automatikusan létrehoz egy helyi tárolómappát a következő logika alapján:

• ${TMPDIR}: Ha a ${TMPDIR} környezeti változó be van állítva, a rendszer ezt a helyet használja.
• /var/tmp: Ha az előző hely nem létezik, megpróbáljuk./var/tmp
• /tmp: Ha mindkét előző hely nem létezik, megpróbáljuk tmp.
• Ha egyik hely sem létezik, a rendszer nem hoz létre helyi tárolót, és továbbra is szükség van manuális konfigurálásra. A megvalósítás részleteiért tekintse meg ezt a GitHub-adattárat.

Az SDK ideiglenes helyi tárolót hoz létre? Az adatok titkosítva lesznek a tárolóban?

Az SDK hálózati problémák vagy szabályozás során helyi tárolóban tárolja a telemetriai elemeket. Ezek az adatok nincsenek helyileg titkosítva.

Windows-rendszerek esetén az SDK automatikusan létrehoz egy ideiglenes helyi mappát a %TEMP% vagy a %LOCALAPPDATA% könyvtárban, és csak a rendszergazdák és az aktuális felhasználó hozzáférését korlátozza.

A Windowstól eltérő rendszerek esetében az SDK nem hoz létre automatikusan helyi tárolót, így alapértelmezés szerint nem tárol adatokat helyileg.

Megjegyzés:

A 2.15.0-béta3-es és újabb kiadással a helyi tároló automatikusan létrejön Linux, Mac és Windows rendszeren.

Saját maga hozhat létre tárkönyvtárat, és konfigurálhatja a csatornát annak használatára. Ebben az esetben Ön a felelős a címtár biztonságának biztosításáért. További információ az adatvédelemről és a magánéletről.

Hol kaphatok további információt a telemetriai csatornákról?

További információ: Telemetriai csatornák az Application Insightsban.

Tranzakciókeresés

Mennyi adat van megőrzve?

Tekintse meg a Korlátok összegzését.

Hogyan tekinthetem meg a POST-adatokat a kiszolgálókérésekben?

Nem naplózzuk automatikusan a POST-adatokat, de használhatja a TrackTrace-et vagy a naplóhívásokat. Helyezze a POST-adatokat az üzenetparaméterbe. Az üzenetre nem lehet ugyanúgy szűrni, mint a tulajdonságokra, de a méretkorlát hosszabb.

Miért nem ad eredményt az Azure-függvényem keresése?

Az Azure Functions nem naplózza az URL-lekérdezési sztringeket.

Hol kaphatok további információt a Tranzakciókeresés szolgáltatásról?

További információ: Tranzakciókeresés és diagnosztika.

Tranzakciódiagnosztika

Miért látok egyetlen összetevőt a diagramon, a többi összetevő pedig csak külső függőségként jelenik meg részletek nélkül?

Lehetséges okok:

• Az összetevők instrumentálva vannak az Application Insights-szal?
• A legújabb stabil Application Insights SDK-t használják?
• Ha ezek az összetevők különálló Application Insights-erőforrások, ellenőrizze, hogy rendelkezik-e hozzáféréssel. Ha hozzáféréssel rendelkezik, és az összetevők a legújabb Application Insights SDK-kkal vannak integrálva, a jobb felső sarokban található visszajelzési csatornán keresztül tájékoztasson minket.

Ismétlődő sorokat látok a függőségekhez. Ez a viselkedés várható?

Jelenleg a kimenő függőségi hívást a bejövő kéréstől elkülönítve jelenítjük meg. A két hívás általában azonos, azzal az eltéréssel, hogy csak az időtartam értéke különbözik a hálózati késleltetés miatt. A kezdő ikon és az időtartamsávok eltérő stílusa segít megkülönböztetni őket. Az adatok bemutatása zavaros? Visszajelzést ad nekünk!

Mi a helyzet a különböző összetevők példányai közötti óraeltérésekkel?

Az ütemtervek a tranzakciódiagramon szereplő óraeltérésekhez igazodnak. A pontos időbélyegeket a részletek panelen vagy a Log Analytics használatával tekintheti meg.

Miért hiányzik az új élményből a kapcsolódó tételek lekérdezéseinek többsége?

Ez a viselkedés terv szerint történik. Az összes kapcsolódó elem az összes összetevőben már elérhető a bal oldalon a felső és az alsó szakaszokban. Az új felület két kapcsolódó elemet tartalmaz, amelyeket a bal oldal nem fed le: az esemény előtti és utáni öt perc összes telemetriáját, valamint a felhasználói ütemtervet.

Van mód arra, hogy tranzakciónként kevesebb eseményt láthassak az Application Insights JavaScript SDK használatakor?

A tranzakciódiagnosztikai élmény egyetlen művelet összes telemetriáját megjeleníti, amely egy műveletazonosítóval rendelkezik. Alapértelmezés szerint a JavaScripthez készült Application Insights SDK új műveletet hoz létre minden egyes egyedi oldalnézethez. Egyoldalas alkalmazásban (SPA) a rendszer csak egy oldalnézeti eseményt hoz létre, és egyetlen műveletazonosítót használ az összes létrehozott telemetriához. Ennek eredményeképpen számos esemény összefügghet ugyanahhoz a művelethez.

Ezekben a forgatókönyvekben az Automatikus útvonalkövetés funkcióval automatikusan létrehozhat új műveleteket a navigáláshoz az SPA-ban. Be kell kapcsolnia aAutoRouteTracking engedélyezését , hogy a rendszer minden alkalommal létrehozhasson lapnézetet, amikor az URL-útvonal frissül (logikai oldalnézet). Ha manuálisan szeretné frissíteni a műveletazonosítót, hívja fel a következőt appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(): A PageView-események manuális aktiválása a műveletazonosítót is alaphelyzetbe állítja.

Miért nem adnak hozzá a tranzakció részleteinek időtartamai a legfelső kérelem időtartamához?

A Gantt-diagramban nem ismertetett idő az az idő, amelyet nem fed le nyomon követett függőség. Ez a probléma azért fordulhat elő, mert a külső hívások nem lettek rendszerezettek automatikusan vagy manuálisan. Az is előfordulhat, hogy a folyamat során eltelt idő nem külső hívás miatt történt.

Ha minden hívás monitorozásra került, a folyamatban lévő tevékenység az idő eltöltésének valószínű oka. A folyamat diagnosztizálásában hasznos eszköz a .NET Profiler.

Mi történik, ha az Application Insights az Azure Portalon való navigálás közben megjelenik a "Hiba az adatok beolvasása közben" üzenet?

Ez a hiba azt jelzi, hogy a böngésző nem tudott meghívni egy szükséges API-t, vagy az API hibaválaszt adott vissza. A viselkedés hibaelhárításához nyisson meg egy böngésző InPrivate-ablakot , és tiltsa le a futó böngészőbővítményeket, majd állapítsa meg, hogy továbbra is képes-e reprodukálni a portál viselkedését. Ha a portál hibája továbbra is fennáll, próbálkozzon más böngészőkkel vagy más gépekkel való teszteléssel, vizsgálja meg a DNS-sel vagy más hálózattal kapcsolatos problémákat azon az ügyfélszámítógépen, ahol az API-hívások sikertelenek. Ha a portálhiba továbbra is fennáll, és további vizsgálatot igényel, gyűjtsön be egy böngészőhálózati nyomkövetést a váratlan portál viselkedésének reprodukálása közben, majd nyisson meg egy támogatási esetet az Azure Portalról.

Hol kaphatok további információt a Tranzakciódiagnosztika szolgáltatásról?

További információ: Tranzakciókeresés és diagnosztika.

Használatelemzés

A kezdeti esemény azt jelzi, amikor az esemény először jelenik meg egy munkamenetben, vagy amikor megjelenik egy munkamenetben?

A vizualizáció kezdeti eseménye csak akkor látható, amikor a felhasználó először küldte el ezt az oldalnézetet vagy egyéni eseményt egy munkamenet során. Ha a felhasználók többször is elküldhetik a kezdeti eseményt egy munkamenetben, akkor az 1. lépés oszlop csak a kezdeti esemény első példánya után mutatja be a felhasználók viselkedését, nem pedig az összes példányt.

A vizualizációm egyes csomópontjainak szintje túl magas. Hogyan kaphatok részletesebb csomópontokat?

A Szerkesztés menü Felosztás opcióinak használata:

1. Válassza ki azt az eseményt, amelyet fel szeretne bontani az Esemény menüben.

2. Válasszon ki egy dimenziót a Dimenzió menüben. Ha például van egy Button Clicked nevű esemény, próbáljon meg egy Gombnév nevű egyéni tulajdonságot használni.

Egy adott országból/régióból származó felhasználók kohorszát definiáltam. Ha összehasonlítom ezt a kohorsztot a Felhasználók eszközben az adott országra/régióra vonatkozó szűrő beállításához, miért jelennek meg különböző eredmények?

A kohorszok és a szűrők eltérőek. Tegyük fel, hogy az Egyesült Királyságból származó felhasználók kohorszával rendelkezik (az előző példához hasonlóan definiálva), és összehasonlítja annak eredményeit a szűrő Country or region = United Kingdombeállításával:

• A kohorszverzió azokat az eseményeket mutatja, amelyeket olyan felhasználók küldtek, akik egy vagy több eseményt indítottak az Egyesült Királyságból a jelenlegi időtartományban. Ha ország vagy régió szerint oszlik meg, valószínűleg sok ország és régió jelenik meg.

• A szűrők verziója csak az Egyesült Királyságból származó eseményeket jeleníti meg. Ha ország vagy régió szerint oszlik meg, akkor csak az Egyesült Királyság jelenik meg.

Hogyan tekinthetem meg az adatokat különböző szinteken (naponta, havonta vagy hetente)?

A szemcse módosításához válassza a Dátumfelbontás szűrőt. A szűrő az összes dimenziólapon elérhető.

Hogyan olyan megállapításokat elérni az alkalmazásomból, amelyek nem érhetők el a HEART-munkafüzetekben?

Ha a vizualizációk nem válaszolnak az összes kérdésére, a HEART-munkafüzetet tápláló adatokat is feltárhatja. A feladat elvégzéséhez az Application Insights Figyelés szakaszában válassza a Naplók lehetőséget, és kérdezze le a táblát customEvents . A Click Analytics-attribútumok némelyike a customDimensions mezőben található.

Itt látható egy példa lekérdezés:

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Ha többet szeretne megtudni az Azure Monitor naplóiról, tekintse meg az Azure Monitor naplóinak áttekintését.

Szerkeszthetim a munkafüzet vizualizációit?

Igen. A munkafüzetsablonok szerkesztéséről az Azure-munkafüzetsablonok című témakörben olvashat.

Hol kaphatok további információt a használati elemzésről?

További információ: Használati elemzés az Application Insights használatával.

Feldolgozói szolgáltatás alkalmazásai

Melyik csomagot érdemes használni?

.NET Core-alkalmazásforgatókönyv	Csomag
HostedServices nélkül	WorkerService
HostedServices szolgáltatásokkal	AspNetCore (nem a WorkerService)
A HostedServices szolgáltatásokkal kizárólag a HostedServices figyelése történik.	WorkerService (ritka forgatókönyv)

A .NET Core-alkalmazásokban az AspNetCore-csomaggal rendelkező HostedServicesbe a TelemetryClient injektálható?

Igen, a konfiguráció meg van osztva a webalkalmazás többi részével.

Hogyan követhetem nyomon a nem automatikusan gyűjtött telemetriát?

Hozzon létre egy TelemetryClient példányt konstruktorinjektálással, és hívja meg a szükséges TrackXXX() metódust rajta. Nem javasoljuk új TelemetryClient példányok létrehozását. A TelemetryClient singleton példánya már regisztrálva van a DependencyInjection tárolóban, amely a többi telemetriával osztozik TelemetryConfiguration. Új TelemetryClient példány létrehozása csak akkor javasolt, ha olyan konfigurációra van szüksége, amely eltér a többi telemetriától.

Használhatom a Visual Studio IDE-t az Application Insights szolgáltatás Worker Service projektbe való integrálásához?

A Visual Studio IDE előkészítés jelenleg csak ASP.NET/ASP.NET Core-alkalmazások esetében támogatott. Ez a dokumentum akkor frissül, ha a Visual Studio támogatja a Worker Service-alkalmazások előkészítését.

Engedélyezhetim az Application Insights monitorozását olyan eszközökkel, mint az Azure Monitor Application Insights Agent (korábbi nevén Status Monitor v2)?

Nem. Az Azure Monitor Application Insights Agent jelenleg csak a .NET-et támogatja.

Minden funkció támogatott, ha az alkalmazást Linuxon futtatom?

Igen. Az SDK szolgáltatástámogatása minden platformon azonos, az alábbi kivételekkel:

• A teljesítményszámlálók csak a Windowsban támogatottak, kivéve az élő metrikákban megjelenített processzor-/memóriafolyamatokat.

• Annak ellenére ServerTelemetryChannel , hogy alapértelmezés szerint engedélyezve van, ha az alkalmazás Linuxon vagy macOS rendszeren fut, a csatorna nem hoz létre automatikusan helyi tárolómappát a telemetriai adatok ideiglenes megőrzéséhez hálózati problémák esetén. A korlátozás miatt a telemetriai adatok elvesznek, ha ideiglenes hálózati vagy kiszolgálói problémák merülnek fel. A probléma megoldásához konfiguráljon egy helyi mappát a csatornához:

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

Hol kaphatok további információt a Worker Service-alkalmazásokról?

További információ: Application Insights for Worker Service-alkalmazások (nem HTTP-alkalmazások).

Az Azure Monitor Application Insights hivatalos gyakori kérdései. Válaszokat találhat az Application Insights azure monitorral való használatával kapcsolatos kérdésekre.

Az Application Insights engedélyezését lehetővé tevő alkalmazások rendszerezésével kapcsolatos részletes információkért tekintse meg az adatgyűjtés alapjait.

Miután engedélyezte az Application Insightst egy alkalmazás rendszerezésével, javasoljuk, hogy először tekintse át az élő metrikákat és az alkalmazástérképet.

Kiszolgálói webalkalmazásokból:

• HTTP-kérések.
• Függőségek. Hívások SQL-adatbázisokhoz, HTTP-hívások külső szolgáltatásokhoz, Azure Cosmos DB-hez, Azure Table Storage-hoz, Azure Blob Storage-hoz és Azure Queue Storage-hoz.
• Kivételek és veremkövetések.
• Teljesítményszámlálók: A teljesítményszámlálók a következők használatakor érhetők el:
  • Azure Monitor Application Insights-ügynök
  • Azure-monitorozás virtuális gépekhez vagy virtuális gép méretezési csoportokhoz
  • Application Insights-írócollectd.
• Az egyéni események és metrikák, amiket kódolsz.
• Nyomkövetési naplók , ha a megfelelő gyűjtőt konfigurálja.

Ügyféloldalakról:

• Nem kezelt kivételek az alkalmazásban, valamint az ezekre vonatkozó információk:

  • Verem nyomkövetése
  • A hibát kísérő kivétel részletei és üzenete
  • A hiba sor- és oszlopszáma
  • URL-cím, ahol hiba lépett fel
  • Az alkalmazás által létrehozott hálózati függőségi kérelmek XML Http-kérések (XHR) és Fetch-kérések (a Fetch gyűjtemény alapértelmezés szerint le van tiltva) révén a következőkre vonatkozó információkat tartalmazzák:
    • Függőségi forrás URL-címe
    • A függőség kéréséhez használt Command &metódus
    • A kérelem időtartama
    • A kérelem eredménykódja és sikerességi állapota
    • A kérést küldő felhasználó azonosítója (ha van ilyen)
    • Korrelációs környezet (ha van ilyen), ahol a kérés történik

• Felhasználói adatok (például hely, hálózat, IP- cím)

• Eszközadatok (például böngésző, operációs rendszer, verzió, nyelv, modell)

• Munkamenet adatai

  Megjegyzés:

  Egyes alkalmazások, például az egyoldalas alkalmazások (SLA-k) esetében a rendszer nem rögzíti mindig az időtartamot, és ezekben az esetekben az alapértelmezett érték 0.

  További információ: Adatgyűjtés, megőrzés és tárolás az Application Insights szolgáltatásban.

Ha beállítja őket más forrásokból:

• Azure-diagnosztika
• Importálás a Log Analyticsbe
• Log Analytics
• Logstash

Ahhoz, hogy megértse, hány Application Insights-erőforrásra van szükség az alkalmazásának vagy komponenseinek különböző környezetekben való lefedéséhez, tekintse meg az Application Insights üzembe helyezési tervezési útmutatóját.

PowerShell-szkripteket az Azure Resource Monitor használatával a következőre írhat:

• Application Insights-erőforrások létrehozása és frissítése.
• Állítsa be a tarifacsomagot.
• Kérje le az instrumentációs kulcsot.
• Adj hozzá metrikariasztást.
• Rendelkezésre állási teszt hozzáadása.

Nem állíthat be metrikakezelő jelentést, és nem állíthat be folyamatos exportálást.

Log Analytics-lekérdezések futtatásához használja a REST API-t.

Javasoljuk az Azure Monitor OpenTelemetry Distro használatát.

A betöltési séma és a végpontprotokoll nyilvánosan elérhető.

A legtöbb Application Insights-adat késése 5 perc alatt van. Egyes adatok hosszabb időt is igénybe vehetnek, ami a nagyobb naplófájlokra jellemző. Tekintse meg az Application Insights szolgáltatásszintű szerződését.

Gyűjtemény

Az Application Insights telemetriát gyűjt az alkalmazásról, beleértve a webkiszolgáló telemetriáját, a weblap telemetriáját és a teljesítményszámlálókat. Ezek az adatok az alkalmazás teljesítményének, állapotának és használatának monitorozására használhatók. Új Application Insights-erőforrás létrehozásakor kiválaszthatja a helyet.

Megőrzés és tárolás

Az adatok egy Application Insights Log Analytics-munkaterületre kerülnek. A nyers adatok megőrzési idejét 30 és 730 nap között választhatja ki. Az összesített adatok 90 napig maradnak meg, a hibakeresési pillanatképek pedig 15 napig maradnak meg.

Adatvédelem

Az Application Insights alapértelmezés szerint nem kezeli a bizalmas adatokat. Javasoljuk, hogy ne helyezzen el bizalmas adatokat az URL-címekben egyszerű szövegként, és győződjön meg arról, hogy az egyéni kód nem gyűjt személyes vagy egyéb bizalmas adatokat. A fejlesztés és tesztelés során ellenőrizze az elküldött adatokat az IDE-ben és a böngésző hibakeresési kimeneti ablakaiban.

Archivált információkért tekintse meg az Application Insights adatgyűjtési, adatmegőrzési és tárolási adatait.

Az Application Insights számlázása a Log Analytics-munkaterületen keresztül történik, amelybe a naplóadatokat betölti. Az alapértelmezett használatalapú Log Analytics tarifacsomag havi 5 GB ingyenes adatkeretet tartalmaz számlázási fiókonként. További információ az Azure Monitor-naplók díjszabási lehetőségeiről.

• Ha az Azure-webalkalmazást olyan adatközpontban üzemelteti, ahol egy Application Insights-gyűjteményvégpont található, díjmentesen.
• Ha nincs gyűjtési végpont a gazdagép adatközpontjában, az alkalmazás telemetriája kimenő Azure-díjakat von maga után.

Ez a válasz a végpontok eloszlásától függ, nem attól, hogy hol található az Application Insights-erőforrás.

Igen, további hálózati költségek merülhetnek fel, amelyek attól függően változnak, hogy a telemetria melyik régióból származik, és hogy hová tart. Részletekért tekintse meg az Azure sávszélesség-díjszabását .

Ha váratlan díjakat vagy magas költségeket lát az Application Insightsban, ez az útmutató segíthet. Olyan gyakori okokra terjed ki, mint a magas telemetriai mennyiség, az adatbetöltési csúcsok és a helytelenül konfigurált mintavételezés. Különösen hasznos, ha a költségnövekedéssel, a telemetriai forgalommal, a nem működő mintavételezéssel, az adatkorlátokkal, a magas adatbevitelnél vagy a váratlan számlázással kapcsolatos problémákat hárítja el. Első lépésként tekintse meg az Application Insights magas adatbetöltésének hibaelhárításával foglalkozó témakört.

Az Application Insights a Transport Layer Security (TLS) 1.2- és 1.3-at használja.

Fontos

2025. március 1-jén az Azure minden szolgáltatásból kivonja a TLS régi verzióit. Az Application Insights ekkor már nem támogatja a TLS 1.0-t, a TLS 1.1-et és a felsorolt régi TLS 1.2/1.3 titkosítási csomagokat és háromliptikus görbéket.

Az örökölt TLS-problémával kapcsolatos általános kérdésekért tekintse meg a TLS-problémák megoldását és az Azure Resource Manager TLS-támogatását.

További információ: Bevezetés az Application Insights használatába.

Mindkét telemetriacsatornák elveszítik a pufferelt telemetriát, ha az alkalmazás leállítása előtt nincs kiürítve.

Az adatvesztés elkerülése érdekében öblítse ki a TelemetryClientet, amikor egy alkalmazás leáll.

További információ: Adatok ürítése.

Nincs. Ezeket nem kell becsomagolnia a try-catch záradékba. Ha az SDK problémákat tapasztal, naplózza az üzeneteket a hibakeresési konzol kimenetében, és ha az üzenetek átjutnak, a Diagnosztikai keresésben.

Igen, az adatelérési API. Az adatok kinyerésének egyéb módjai közé tartozik a Power BI a munkaterület-alapú erőforráson.

Az Application Insights SDK nem kompatibilis az autoinstrumentációval. Ha az autoinstrumentáció engedélyezve van, a rendszer figyelmen kívül hagyja a Track() és más egyéni eseményekre és metrikákra vonatkozó API-hívásokat.

Kapcsolja ki az autoinstrumentációt az Azure portálon az App Service oldalon található Application Insights lapon, vagy állítsa be ApplicationInsightsAgent_EXTENSION_VERSION értékét disabled-re.

A mintavételezés csökkenti az alkalmazásból a portálra küldött telemetriai elemek (például kérések és egyéni események) számát. A Keresés nézetben láthatja a fogadott elemek számát. Az események számát megjelenítő metrikadiagramokon az eredeti események száma látható.

Minden továbbított elem egy tulajdonságot itemCount hordoz, amely azt mutatja, hogy hány eredeti eseményt jelöl az elem. A mintavételezés működés közbeni megfigyeléséhez futtassa ezt a lekérdezést a Log Analyticsben:

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Az Azure-riasztások csak a metrikákra vonatkoznak. Hozzon létre egy egyéni metrikát, amely túllép egy értékküszöböt, amikor az esemény bekövetkezik. Ezután állítson be egy riasztást a metrikára. Értesítést kap, ha a metrika mindkét irányban átlépi a küszöbértéket. Az első kereszteződésig nem kap értesítést, függetlenül attól, hogy a kezdeti érték magas vagy alacsony. Mindig van néhány perc késés.

További információ: Application Insights API egyéni eseményekhez és metrikákhoz.

Igen. Az Application Insights-ügynök letöltésének több módja is van:

• Ha a számítógép rendelkezik internet-hozzáféréssel, a -Proxy paraméterek használatával csatlakozhat a PowerShell-galériához.
• A modult manuálisan is letöltheti, és telepítheti a számítógépre, vagy közvetlenül használhatja.

Ezeket a lehetőségeket a részletes utasítások ismertetik.

Igen. Az Application Insights Agent 2.0.0-s és újabb verzióiban az IIS-ben üzemeltetett ASP.NET Core-alkalmazások támogatottak.

• A Get-ApplicationInsightsMonitoringStatus parancsmaggal ellenőrizheti, hogy az engedélyezés sikeres volt-e.

• Az élő metrikák használatával gyorsan megállapíthatja, hogy az alkalmazás telemetriát küld-e.

• A Log Analytics használatával listázhatja az összes jelenleg telemetriát küldő felhőszerepkört:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

A proxyátengedés eléréséhez konfiguráljon egy gépszintű proxyt vagy egy alkalmazásszintű proxyt. Lásd: DefaultProxy.

Web.config példa:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

További információ: Application Insights-ügynök üzembe helyezése helyszíni kiszolgálókhoz.

Az Application Insights és az Azure Monitor nem szabályozza a HTTPS-kapcsolatokhoz használt TLS-verziót. A TLS-verzió az operációs rendszertől és a futtatókörnyezettől függ, ahol az alkalmazás fut.

A használt TLS-verzió megerősítése:

• Tekintse át az operációs rendszer, a futtatókörnyezet vagy a keretrendszer dokumentációját.
• Ha további segítségre van szüksége, forduljon a megfelelő támogatási csoporthoz. Ne nyisson meg támogatási kérelmet az Application Insights használatával.

Példanyelv és futtatókörnyezet támogatása a TLS 1.2+-hez

A következő verziók tartalmazzák a TLS 1.2 vagy újabb verziójának integrált támogatását:

• .NET/ .NET Core: .NET Framework 4.6.2 vagy újabb, és a .NET Core összes verziója
• Java: Java 8 update 161 (8u161) vagy újabb
• Python: Az OpenSSL 1.0.1 vagy újabb verziójával készült Python-disztribúciók
• Node.js: Node.js 10-es vagy újabb verzió

Példa operációsrendszer-támogatás a TLS 1.2+-hez

A következő operációs rendszerek integrált támogatást nyújtanak a TLS 1.2 vagy újabb verziójához:

• Windows: Windows 8, Windows Server 2012 és újabb
• Linux: Az OpenSSL 1.0.1 vagy újabb verzióját használó modern Linux-disztribúciók többsége

A szolgáltatáskimaradások elkerülése érdekében az erőforrás minden távoli végpontjának (beleértve a függő kéréseket is) támogatnia kell a korábban említett protokollverzió, titkosítási csomag és elliptikus görbe legalább egy kombinációját. Ha a távoli végpont nem támogatja a szükséges TLS-konfigurációt, frissíteni kell az elavulás utáni TLS-konfiguráció bizonyos kombinációjának támogatásával.

Az érintett Application Insights-erőforrások leállják az adatok betöltését, és nem férnek hozzá a szükséges alkalmazásösszetevőkhöz. Emiatt egyes funkciók leállnak.

A jelen dokumentumban részletezett Transport Layer Security (TLS) elavulása csak 2025. május 1. után befolyásolhatja a viselkedést. A CRUD-műveletekről további információt az Azure Resource Manager TLS-támogatásában talál. Ez az erőforrás további részleteket nyújt a TLS támogatásáról és az elavulás idővonaláról.

Az örökölt TLS-problémával kapcsolatos általános kérdésekért tekintse meg a TLS-problémák megoldását.

További információ: TLS-támogatás.

Az Application Insights eltávolításához el kell távolítania a NuGet-csomagokat és -hivatkozásokat az alkalmazás API-jából. A NuGet-csomagokat a Visual Studióban a NuGet Csomagkezelő használatával távolíthatja el.

1. Ha a nyomkövetési gyűjtemény engedélyezve van, először távolítsa el a Microsoft.ApplicationInsights.TraceListener csomagot a NuGet Csomagkezelő használatával, de ne távolítsa el a függőségeket.
2. Távolítsa el a Microsoft.ApplicationInsights.Web csomagot, és távolítsa el a függőségeit a NuGet Csomagkezelő és eltávolítási beállításaival a NuGet Csomagkezelő Beállítások vezérlőelemben.
3. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat a projektben hozzáadott API-hívásokkal együtt. További információ: Mi jön létre automatikusan az Application Insights SDK hozzáadásakor?

Amikor hozzáadja az Application Insightst a projekthez, az automatikusan létrehozza a fájlokat, és kódot ad hozzá néhány fájlhoz. A NuGet-csomagok eltávolítása nem mindig veti el a fájlokat és a kódot. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat, valamint a projektben hozzáadott API-hívásokat.

Amikor Hozzáadja az Application Insights telemetriát egy Visual Studio ASP.NET-projekthez, a következő fájlokat adja hozzá:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

A rendszer automatikusan hozzáadja a következő kódrészleteket:

• [A projekted neve].csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  Ha a projekt rendelkezik Layout.cshtml fájllal, a program a következő kódot adja hozzá.

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

Ha le szeretné tiltani a telemetria-korrelációt a konfigurációban, tekintse meg <ExcludeComponentCorrelationHttpHeadersOnDomains> az Application Insights konzolalkalmazásokhoz készült témakörét.

További információ: Az Application Insights konfigurálása a ASP.NET webhelyhez.

ASP.NET Core 3.1-et a Microsoft már nem támogatja.

Az Application Insights SDK ASP.NET Core 2.8.0-s és Visual Studio 2019-es vagy újabb verziójához használható ASP.NET Core 3.1-alkalmazásokhoz.

Hozzon létre egy TelemetryClient példányt konstruktorinjektálással, és hívja meg a szükséges TrackXXX() metódust rajta. Nem javasoljuk, hogy új TelemetryClient vagy TelemetryConfiguration példányokat hozzon létre egy ASP.NET Core-alkalmazásban. A TelemetryClient singleton példánya már regisztrálva van a DependencyInjection tárolóban, amely a többi telemetriával osztozik TelemetryConfiguration. Csak akkor hozzon létre új TelemetryClient példányt, ha a többi telemetriától eltérő konfigurációra van szüksége.

Az alábbi példa bemutatja, hogyan követhet nyomon több telemetriát egy vezérlőből.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Az Application Insights egyéni adatjelentéseiről további információt az Application Insights egyéni metrikák API-referenciájában talál. Hasonló megközelítéssel egyéni metrikákat küldhet az Application Insightsnak a GetMetric API használatával.

ASP.NET Core beépített támogatást nyújt a HTTP-kérések/válaszok adatainak (beleértve a törzset) naplózásához.ILogger Javasoljuk, hogy használja ezt a megoldást. Ez potenciálisan személyes azonosításra alkalmas adatokat (PII) tehet közzé a telemetriában, és a költségek (teljesítményköltségek és Az Application Insights számlázása) jelentősen növekedhet, ezért a használat előtt gondosan értékelje ki a kockázatokat.

Az Application Insights alapértelmezett beállítása az, hogy csak a Figyelmeztetés szintű és annál súlyosabb naplókat rögzítse.

Az Application Insights-szolgáltató naplózási konfigurációjának az alábbiak szerint történő módosításával rögzítheti az információkat és a kevésbé súlyos naplókat.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

Fontos megjegyezni, hogy az alábbi példa nem eredményezi, hogy az Application Insights-szolgáltató rögzítse a naplókat Information. Nem rögzíti, mert az SDK hozzáad egy alapértelmezett naplózási szűrőt, amely arra utasítja ApplicationInsights , hogy csak Warning a naplókat és a súlyosabb naplókat rögzítse. Az Application Insights kifejezett felülbírálást igényel.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

További információ: ILogger-konfiguráció.

A bővítménymetódus UseApplicationInsights() továbbra is támogatott, de elavultként van megjelölve az Application Insights SDK 2.8.0-s és újabb verzióiban. A következő SDK főverzióban eltávolítják. Az Application Insights telemetriai adatainak engedélyezéséhez használja AddApplicationInsightsTelemetry() , mert túlterheléseket biztosít bizonyos konfigurációk szabályozásához. Emellett ASP.NET Core 3.X-alkalmazásokban services.AddApplicationInsightsTelemetry() csak az Application Insightst lehet engedélyezni.

Ha az SDK a jelen cikkben látható buildelési időpontban van telepítve, nem kell engedélyeznie az Application Insights bővítményt az App Service portálról. Ha a bővítmény telepítve van, a bővítmény kikapcsol, amikor azt észleli, hogy az SDK már hozzá lett adva. Ha engedélyezi az Application Insightst a bővítményből, nem kell telepítenie és frissítenie az SDK-t. Ha azonban a jelen cikkben ismertetett utasításokat követve engedélyezi az Application Insights szolgáltatást, nagyobb rugalmasságot biztosít, mert:

• Az Application Insights telemetria továbbra is működik:
  • Minden operációs rendszer, beleértve a Windowst, a Linuxot és a Macet is.
  • Minden közzétételi mód, beleértve az önálló vagy keretrendszerfüggőt is.
  • Minden cél-keretrendszer, beleértve a teljes .NET-keretrendszer.
  • Minden üzemeltetési lehetőség, beleértve a Web Appst, a virtuális gépeket, a Linuxot, a tárolókat, az AKS-t és a nem Azure-beli üzemeltetést.
  • Minden .NET Core-verzió, beleértve az előzetes verziókat is.
• A telemetriát helyileg láthatja, amikor hibakeresést végez a Visual Studióban.
• Az API használatával TrackXXX() további egyéni telemetriát is nyomon követhet.
• Teljes körűen szabályozhatja a konfigurációt.

Igen. Az Application Insights Agent 2.0.0-beta1 és újabb verzióiban az IIS-ben üzemeltetett ASP.NET Core-alkalmazások támogatottak.

Igen. Az SDK szolgáltatástámogatása minden platformon azonos, az alábbi kivételekkel:

• Az SDK eseményszámlálókat gyűjt Linux rendszeren, mert a teljesítményszámlálók csak a Windowsban támogatottak. A legtöbb metrika ugyanaz.

Nem. Ehelyett használja az Application Insights for Worker Service-alkalmazásokat (nem HTTP-alkalmazásokat) a feldolgozói szolgáltatásokhoz.

Az Application Insights eltávolításához el kell távolítania a NuGet-csomagokat és -hivatkozásokat az alkalmazás API-jából. A NuGet-csomagokat a Visual Studióban a NuGet Csomagkezelő használatával távolíthatja el.

Megjegyzés:

Ezek az utasítások a ASP.NET Core SDK eltávolítására használhatók. Ha el kell távolítania a ASP.NET SDK-t, olvassa el a Hogyan távolíthatom el a ASP.NET SDK-t?

1. Távolítsa el a Microsoft.ApplicationInsights.AspNetCore csomagot a NuGet Csomagkezelő használatával.
2. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat a projektben hozzáadott API-hívásokkal együtt. További információ: Mi jön létre az Application Insights SDK hozzáadásakor?

Amikor hozzáadja az Application Insightst a projekthez, az fájlokat hoz létre, és kódot ad hozzá néhány fájlhoz. A NuGet-csomagok eltávolítása nem mindig veti el a fájlokat és a kódot. Az Application Insights teljes eltávolításához ellenőrizze és manuálisan törölje a hozzáadott kódot vagy fájlokat, valamint a projektben hozzáadott API-hívásokat.

Amikor Hozzáadja az Application Insights telemetriát egy Visual Studio ASP.NET Core-sablonprojekthez, a következő kódot adja hozzá:

• [A projekted neve].csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

Ha le szeretné tiltani a telemetriai korrelációt a kódban, nézze meg <ExcludeComponentCorrelationHttpHeadersOnDomains> az Application Insights konzolalkalmazásokhoz vonatkozó témakörét.

További információ: Application Insights for ASP.NET Core.

• Exception rate: A kivételi arány egy rendszerteljesítmény-számláló. A CLR megszámolja az összes olyan kezelt és kezeletlen kivételt, amely ki van dobva, és a mintavételi intervallumban lévő összesítést az intervallum hosszával osztja el. Az Application Insights SDK összegyűjti ezt az eredményt, és elküldi a portálnak.
• Exceptions: A Kivételek metrika megszámolja a TrackException portál által a diagram mintavételezési időközében fogadott jelentéseket. Csak azokat a kezelt kivételeket tartalmazza, ahol TrackException hívásokat ír a kódjába. Nem tartalmazza az összes kezeletlen kivételt.

További információ: .NET számlálók az Application Insightsban.

Az élő metrikák nem jelenítik meg az EventCounterst. A telemetriai adatok megtekintéséhez használja a Metric Explorert vagy az Analyticset.

A ASP.NET Core Application Insights-bővítménye még nem támogatja ezt a funkciót.

További információ: .NET számlálók az Application Insightsban.

Az ügyféloldali monitorozás alapértelmezés szerint engedélyezve van ASP.NET Core-alkalmazások esetében. Ha le szeretné tiltani, definiáljon egy környezeti változót a kiszolgálón a következő információkkal:

• Név:APPINSIGHTS_JAVASCRIPT_ENABLED
• Érték:false

További információ: Application Insights azure-beli virtuális gépekhez és virtuálisgép-méretezési csoportokhoz.

A sikertelen függőségi hívások success mezője Hamisra (False) van állítva. A modul DependencyTrackingTelemetryModule nem tesz jelentést ExceptionTelemetry. A függőség teljes adatmodelljének leírását az Application Insights telemetriai adatmodellje ismerteti.

Használja a következő kódot:

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

A Log Analytics lekérdezési nézetben timestamp a TrackDependency() hívás indításának pillanatát jelöli, amely közvetlenül a függőségi hívás válaszának fogadása után következik be. A függőségi hívás indításának időpontjának kiszámításához vegye figyelembe timestamp és vonja ki a függőségi hívás rögzített duration értékét.

Az Application Insights függőségkövetése nem tartalmazza a választörzsek naplózását, mivel túl sok telemetriát generálna a legtöbb alkalmazás számára.

További információ: Függőségek nyomon követése.

A rendelkezésre állási tesztek a világ különböző pontjain elosztott jelenléti pontokon futnak. Két megoldás létezik:

• Tűzfalajtó: A webtesztelők hosszú és módosítható listájából engedélyezheti a kiszolgálóra irányuló kéréseket.
• Egyéni kód: Írjon saját kódot, hogy rendszeres kéréseket küldjön a kiszolgálónak az intraneten belülről. Erre a célra Visual Studio-webteszteket is futtathat. A tesztelő az API használatával elküldheti az eredményeket az TrackAvailability() Application Insightsnak.

A felhasználói ügynök sztringje Mozilla /5.0 (kompatibilis; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

További információ: Rendelkezésre állási tesztek.

A rendelkezésre állási tesztek elosztott ügyfélként működnek minden támogatott webes teszthelyen. Minden alkalommal, amikor egy webes teszt végrehajtása megtörténik, a rendelkezésre állási tesztszolgáltatás megpróbálja elérni a webes tesztkonfigurációban meghatározott távoli végpontot. A rendszer egy TLS-ügyfél hello üzenetet küld, amely tartalmazza az összes jelenleg támogatott TLS-konfigurációt. Ha a távoli végpont közös TLS-konfigurációt oszt meg a rendelkezésre állási tesztügyféllel, a TLS-kézfogás sikeres lesz. Ellenkező esetben a webes teszt TLS-kézfogási hibával meghiúsul.

A végpontok által támogatott TLS-konfiguráció teszteléséhez több eszköz is rendelkezésre áll. Ennek egyik módja az ezen az oldalon részletezett példa követése. Ha a távoli végpont nem érhető el a nyilvános interneten keresztül, ellenőriznie kell a távoli végponton támogatott TLS-konfigurációt egy olyan gépről, amely rendelkezik hozzáféréssel a végpont meghívásához.

Megjegyzés:

Ha szeretné engedélyezni a szükséges TLS-konfigurációt a webkiszolgálón, a legjobb, ha megkeresi azt a csapatot, amely a webkiszolgáló által futtatott üzemeltetési platformot birtokolja, ha a folyamat nem ismert.

Nincs olyan kivételtípus, amely az elavulás miatti TLS-kézfogási hibáknál felmerülne. A webes teszt során azonban a leggyakoribb kivétel, amivel a teszt elkezdene meghiúsulni, The request was aborted: Couldn't create SSL/TLS secure channel lenne. A TLS átviteli hibaelhárítási lépésében az esetlegesen érintett webes teszt eredményének TLS-sel kapcsolatos hibáit is látnia kell.

A webes teszt végrehajtása során egyeztetett TLS-konfiguráció nem tekinthető meg. Mindaddig, amíg a távoli végpont a rendelkezésre állási tesztekkel támogatja a gyakori TLS-konfigurációt, az elavulás utáni hatás nem észlelhető.

A jelen dokumentumban részletezett TLS-elavulás csak a rendelkezésre állási teszt webes tesztvégrehajtási viselkedését befolyásolhatja 2025. május 1. után. További információ a CRUD-műveletek rendelkezésre állási tesztszolgáltatásával való interakcióról: Azure Resource Manager TLS-támogatás. Ez az erőforrás további részleteket nyújt a TLS támogatásáról és az elavulás idővonaláról.

Az örökölt TLS-problémával kapcsolatos általános kérdésekért tekintse meg a TLS-problémák megoldását.

További információ: Támogatott TLS-konfigurációk.

A részletek a projekt típusától függenek. Az alábbi lista egy webalkalmazás példája.

• Fájlokat ad hozzá a projekthez:

  • ApplicationInsights.config
  • ai.js

• Telepíti a NuGet-csomagokat:

  • Application Insights API: Az alapvető API
  • Application Insights API webalkalmazásokhoz: Telemetriát küld a kiszolgálóról
  • Application Insights API JavaScript-alkalmazásokhoz: Telemetriai adatok küldésére szolgál az ügyféltől

• Tartalmazza a csomagokban lévő összeszereléseket:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Elemek beszúrása a következőbe:

  • Web.config
  • packages.config

• Kódrészleteket szúr be az ügyfél- és kiszolgálókódba, hogy inicializálja őket az Application Insights erőforrás-azonosítójával. Egy MVC-alkalmazásban például a rendszer kódot szúr be a Nézetek/Megosztott/_Layout.cshtml főlapra. Csak új projektek esetén manuálisan kell hozzáadnia az Application Insightst egy meglévő projekthez.

Az Application Insights telemetriai adatokat gyűjt az alkalmazásnak küldött kérelmekről. Ha a hiba a WebApps/WebServer szolgáltatásban jelentkezik, és a kérés nem érte el a felhasználói alkalmazást, az Application Insights nem rendelkezik telemetriai adatokkal.

Az Application Insights által kiszámított időtartam serverresponsetime nem feltétlenül egyezik meg a Web Apps által megfigyelt kiszolgálói válaszidővel. Ennek a viselkedésnek az az oka, hogy az Application Insights csak azt az időtartamot számolja meg, amikor a kérés ténylegesen eléri a felhasználói alkalmazást. Ha a kérés elakadt vagy várólistára került a WebServerben, a várakozási idő a Web Apps-metrikákban szerepel, az Application Insights-metrikákban azonban nem.

További információ: Alkalmazásfigyelés engedélyezése az Azure App Service-ben.

A Microsoft Learn platformon közzétett termékdokumentációhoz kövesse a Microsoft Stílus útmutatóját.

Általában nem tartalmaz kötőjelet az "auto" előtag után.

További információ: Mi az Azure Monitor Application Insights automatikus integrációja?

Ha egyéni metrikákat szeretne a Node.js-ban, manuálisan konfigurálja az alkalmazásokat az Azure Monitor OpenTelemetry Distro segítségével.

A Java autoinstrumentációval lehetővé teszi az egyéni metrikákat. A kód frissítésével és a funkció engedélyezésével egyéni metrikákat gyűjthet . Ha a kód már rendelkezik egyéni metrikákkal, akkor azok akkor haladnak át, amikor engedélyezve van az autoinstrumentáció.

Az AKS autoinstrumentáció megzavarhatja az OSS OpenTelemetry SDK által harmadik feleknek küldött telemetriát.

Az AKS autoinstrumentáció úgy lett kialakítva, hogy mindkét manuális instrumentációs lehetőséggel együtt létezzen: az Application Insights klasszikus API SDK-ja és az OpenTelemetry Distro.

Ez mindig megakadályozza a duplikált adatokat, és biztosítja az egyéni metrikák működését.

Ebből a diagramból megtudhatja, hogy mikor élvez elsőbbséget az autoinstrumentáció vagy a manuális rendszerezés.

Nyelv	Elsőbbség
Node.js	Manuális műszerhasználat
Jáva	Autoinstrumentáció

Az Azure Monitor OpenTelemetry Disztribúcióban észlelt biztonsági rések rangsorolva, javítva és felszabadítva lesznek a következő verzióban.

Az AKS autoinstrumentation az Azure Monitor OpenTelemetry Distro legújabb verzióját injektálja az alkalmazás podjaiba minden alkalommal, amikor az üzembe helyezést módosítják vagy újraindítják.

Az OpenTelemetria disztribúció sebezhetővé válhat olyan üzemelő példányokon, amelyek hosszabb ideig nem változnak vagy újraindulnak. Ezért javasoljuk, hogy hetente frissítse vagy indítsa újra az üzemelő példányokat a Disztribúció legújabb verziójának használata érdekében.

Ez a funkció az Azure Monitor OpenTelemetry Distro alkalmazás podokba történő injektálásával éri el az automatikus instrumentálást.

Java esetén ez a funkció integrálja a Java önálló Azure Monitor OpenTelemetry Disztribúcióját. További információt a Java-disztribúciós dokumentációban talál a Java-rendszerállapot bináris verziójáról.

A Node.jsesetében egy autoinstrumentációs bináris fájlt injektálunk az Azure Monitor OpenTelemetry Distro for Node.jsalapján. További információ: Node.js disztribúció dokumentációja. Ne feledje, hogy nincs önálló automatikus műszerelésünk a Node.js esetében, így a disztribúciós dokumentációnk a manuális beállításra összpontosít. Nem kell foglalkoznia a manuális műszereléssel kapcsolatos kódalapú konfigurációs lépésekkel. A disztribúció dokumentációjában azonban minden más, például az alapértelmezett beállítások és a környezeti változók konfigurációi is vonatkoznak erre a funkcióra.

További információ: Autoinstrumentation for AKS.

Az új Azure-régiókban műszerkulcsok helyett kapcsolati sztringek használata szükséges. A kapcsolati sztring azonosítja a telemetriai adatokhoz társítani kívánt erőforrást. Azt is lehetővé teszi, hogy módosítsa azokat a végpontokat, amelyet az erőforrás a telemetria célhelyeként használ. Másolja ki a kapcsolati sztring, és adja hozzá az alkalmazás kódjához vagy egy környezeti változóhoz.

Javasoljuk, hogy a kapcsolati sztringek használata helyett instruálási kulcsokat használjon.

Állítsa be manuálisan az APPLICATIONINSIGHTS_CONNECTION_STRING összes olyan forgatókönyvben, ahol a rendszer nem biztosítja automatikusan. Ezek a forgatókönyvek magukban foglalják a helyi fejlesztést és a .NET izolált függvényeket ASP.NET Core-integrációval. Ezekben az esetekben a környezeti változó biztosítja, hogy az OpenTelemetry csővezeték továbbíthassa a telemetriát az Application Insights-ra. További információt a kapcsolat karakterláncok környezeti változóval történő konfigurálásáról Az OpenTelemetry konfigurálása az Application Insightsban című dokumentumban találhat.

A regionális adatmegfelelési követelmények teljesítéséhez használjon regionális Application Insights-végpontokat a globális végpont helyett. A globális végpont nem garantálja, hogy az adatok egy adott régión belül maradnak. A regionális végpontok segítenek biztosítani, hogy a szabályozott területeken lévő felhasználók telemetriai adatai csak az adott régiók adatközpontjaiba legyenek elküldve.

A globális webalkalmazás regionális megfelelőségre való konfigurálásához:

• Hozzon létre régiónként egy Application Insights-erőforrást szigorú megfelelőségi követelményekkel, például az Európai Unióval vagy az Egyesült Államokkal.
• Hozzon létre egy másik Application Insights-erőforrást az összes többi régió felhasználói számára.
• Konfigurálja az alkalmazást úgy, hogy telemetriát küldjön a megfelelő Application Insights-erőforrásnak az egyes felhasználók régiói alapján. Határozza meg a régiót olyan jelek használatával, mint az IP-cím, a fiók metaadatai vagy a helybeállítások.
• Ha régiók közötti egységes lekérdezési felületre van szüksége, csatlakoztassa az Összes Application Insights-erőforrást egy Log Analytics-munkaterülethez.

Például:

• Küldje el az A régió felhasználóinak adatait az A régió Application Insights erőforrásába az A régió kapcsolati sztringjének használatával.
• Adatokat küldjön a B régió felhasználóitól a B régió Application Insights-erőforrásához a B régió kapcsolati sztringje segítségével.
• Az összes többi felhasználói adat elküldése egy általános célú Application Insights-erőforrásba egy másik kapcsolati sztring használatával.

Fontos

A globális végpont használata nem biztosítja a regionális megfelelőséget. Az adattárolási követelmények teljesítéséhez mindig használjon régióspecifikus végpontokat, és a felhasználó régiója alapján irányozza át a telemetriát.

Az alábbi ábra egy globális webalkalmazás példabeállítását mutatja be:

További információ: Kapcsolati karakterláncok.

A meglévő Application Insights-erőforrások régiók közötti átvitele nem támogatott, és az előzményadatok nem migrálhatók új régióba. A megoldás magában foglalja:

• Új Application Insights-erőforrás létrehozása a kívánt régióban.
• Az eredeti erőforrás egyedi testreszabásainak újraalkotása az új erőforrásban.
• Az alkalmazás frissítése az új régiós erőforrás kapcsolati karakterláncával.
• Tesztelés, hogy minden a várt módon működjön az új Application Insights-erőforrással.
• Döntse el, hogy megtartja vagy törli az eredeti Application Insights-erőforrást. A klasszikus erőforrás törlése az összes előzményadat elvesztését jelenti. Ha az erőforrás munkaterület-alapú, az adatok a Log Analyticsben maradnak, így az előzményadatokhoz való hozzáférés a megőrzési időszak lejártáig tart.

Az új régióban lévő erőforráshoz gyakran manuálisan újra kell létrehozni vagy frissíteni kívánt egyedi testreszabások közé tartoznak, de nem korlátozódnak a következőkre:

• Egyéni irányítópultok és munkafüzetek újbóli létrehozása.
• Hozza létre vagy frissítse újra az egyéni napló-/metrikariasztások hatókörét.
• Hozza létre újra a rendelkezésre állási riasztásokat.
• Hozza létre újra azokat az egyéni Azure-szerepköralapú hozzáférés-vezérlési beállításokat, amelyek szükségesek ahhoz, hogy a felhasználók hozzáférjenek az új erőforráshoz.
• Replikálja a betöltési mintavételezést, az adatmegőrzést, a napi korlátot és az egyéni metrikák engedélyezését magában foglaló beállításokat. Ezeket a beállításokat a Használat és a becsült költségek panelen lehet szabályozni.
• Az API-kulcsokra támaszkodó összes integráció, például a kibocsátási széljegyzetek és az élő metrikák biztonságos vezérlési csatornája. Új API-kulcsokat kell létrehoznia, és frissítenie kell a társított integrációt.
• A klasszikus erőforrások folyamatos exportálását újra konfigurálni kell.
• A munkaterület-alapú erőforrások diagnosztikai beállításait újra konfigurálni kell.

Nem javasoljuk, hogy ezt a módszert használja az API-verzió feltöltéséhez. A legújabb verzió az előzetes verziójú kiadásokat jelölheti, amelyek kompatibilitástörő változásokat tartalmazhatnak. Az API-verziók még az újabb, nem előzetes verziók esetén sem mindig kompatibilisek a meglévő sablonokkal. Bizonyos esetekben előfordulhat, hogy az API-verzió nem minden előfizetés számára érhető el.

További információ: Application Insights-erőforrások létrehozása és konfigurálása.

Adatmodell vagy sémaproblémák és javaslatok jelentéséhez használja a GitHub-adattárat.

A PageView Telemetria URL-címet tartalmaz, és a Kusto regex függvényével elemezheti az UTM paramétert.

Előfordulhat, hogy ezek az adatok hiányoznak vagy pontatlanok, ha a felhasználó vagy a vállalat letiltja a felhasználói ügynök küldését a böngésző beállításai között. Előfordulhat, hogy az UA Parser regexes nem tartalmazza az összes eszközinformációt. Vagy előfordulhat, hogy az Application Insights nem fogadta el a legújabb frissítéseket.

Ez akkor fordulhat elő, ha sztringértékeket használ. Csak a numerikus értékek működnek egyéni mérésekkel.

További információ: Application Insights telemetriai adatmodell.

ApplicationInsightsLoggerProvider rögzíti a naplókat ILogger, és ezekből létrehoz TraceTelemetry. Ha egy Exception objektumot átadnak a Log-on lévő ILogger metódusnak, ExceptionTelemetry jön létre TraceTelemetry helyett.

ILogger Telemetria megtekintése

Az Azure Portalon:

1. Nyissa meg az Azure Portalt, és nyissa meg az Application Insights-erőforrást.
2. Válassza ki az Application Insights Naplók szakaszát.
3. A Kusto lekérdezésnyelv (KQL) használatával kérdezheti le a traces táblában tárolt ILogger-üzeneteket. Példa lekérdezés: traces | where message contains "YourSearchTerm".
4. Pontosítsa a lekérdezéseket, hogy az ILogger-adatokat súlyosság, időtartomány vagy adott üzenettartalom alapján szűrje.

A Visual Studióban (helyi hibakereső):

1. Indítsa el az alkalmazást hibakeresési módban a Visual Studióban.
2. Nyissa meg a Diagnosztikai eszközök ablakot az alkalmazás futtatása közben.
3. Az Események lapon az ILogger-naplók más telemetriai adatokkal együtt jelennek meg.
4. Adott ILogger-üzenetek megkereséséhez használja a diagnosztikai eszközök ablak keresési és szűrési funkcióit.

Ha mindig szeretne küldeni TraceTelemetry, használja ezt a kódrészletet:

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Az Application Insights az ILogger összes többi telemetriához használt adatok használatával rögzíti és küldi TelemetryConfiguration a naplókat. De van egy kivétel. Alapértelmezés szerint TelemetryConfiguration nincs teljesen beállítva, amikor a Program.cs vagy a Startup.cs fájlból történik a naplózás. Az ezekről a helyekről származó naplók nem rendelkeznek az alapértelmezett konfigurációval, így nem futtatják az összes TelemetryInitializer és TelemetryProcessor példányt.

Amikor az önálló csomagot használja, TelemetryClient nem kerül be a függőséginjektálási (DI) tartályba. Létre kell hoznia egy új TelemetryClient példányt, és ugyanazt a konfigurációt kell használnia, mint amelyet a naplózó szolgáltató használ, ahogyan az alábbi kód is mutatja. Ez a követelmény biztosítja, hogy ugyanazt a konfigurációt használják az összes egyéni telemetriához és a ILogger telemetriájához.

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Megjegyzés:

Ha az Microsoft.ApplicationInsights.AspNetCore csomagot az Application Insights engedélyezésére használja, módosítsa ezt a kódot úgy, hogy a TelemetryClient közvetlenül a konstruktorban legyen elérhető.

Az Azure Web Apps Application Insights bővítménye az új szolgáltatót használja. Az alkalmazás appsettings.json fájljában módosíthatja a szűrési szabályokat.

További információ: Application Insights naplózás a .NET-tel.

A Java Profiler a Java Flight Recorder (JFR) használatával profilozza az alkalmazást egy testreszabott konfiguráció használatával.

A Java Flight Recorder (JFR) egy futó Java-alkalmazás profilkészítési adatainak gyűjtésére szolgáló eszköz. A JFR integrálva van a Java virtuális gépbe (JVM), és a teljesítményproblémák elhárítására szolgál. További információ a Java SE JFR-futtatókörnyezetről.

A Java Profilkészítés az Application Insights ingyenes funkciója. Az Azure Monitor Application Insights díjszabása a betöltési költségeken alapul.

A JFR által gyűjtött profilkészítési adatok a következők: metódus- és végrehajtási profilkészítési adatok, szemétgyűjtési adatok és zárolási profilok.

A JFR-felvétel megtekinthető és elemezhető az előnyben részesített eszközzel, például a Java Mission Control (JMC) használatával.

A "Teljesítménydiagnosztikák és javaslatok" egy új funkció, amely hamarosan elérhető az Application Insights Java Diagnostics szolgáltatásában. Regisztrálhat a funkció előzetes verziójára. A JFR-felvétel megtekinthető a Java Mission Control (JMC) használatával.

Az igény szerinti profilkészítés valós időben történik, míg az automatikus profilkészítés előre konfigurált eseményindítókkal történik.

Az igény szerinti profilkészítési lehetőséghez használja a Profil most lehetőséget. A Profile Now azonnal profilt ad az Application Insights-példányhoz csatolt összes ügynöknek.

Az automatikus profilkészítést egy erőforrás küszöbértékének elérése aktiválja.

Az Application Insights Java-ügynök jelenleg támogatja a processzor- és memóriahasználat monitorozását. A cpu-küszöbérték a gép összes elérhető magjának százalékos arányaként van konfigurálva. A memória az aktuális tenured memóriaterület (OldGen) foglaltsága a régió maximális lehetséges méretével szemben.

Tekintse át az előfeltételeket.

Igen, a JFR használatával profilozhat mikroszolgáltatásokat futtató JVM-et.

További információ: Azure Monitor Application Insights Profiler for Java.

Nem, a mintavételezési felülbírálások már általánosan elérhetők (GA), és az automatikus és manuális rendszerezéssel is használhatók.

Ha autoinstrumentációt használ, frissítse a applicationinsights.json fájlt az Azure Portalon.

Az autoinstrumentációhoz nincs szükség kézi ügynök feltöltésére. Azonban a manuális instrumentáláshoz szükséges, hogy a telepítési csomag tartalmazza az Application Insights ügynök JAR-fájlt és a konfigurációs fájlokat.

A helyi fejlesztés azt a környezetet jelenti, amelyben az alkalmazás felépítése vagy tesztelése folyamatban van, például egy fejlesztő gépe vagy egy Azure Cloud Shell-példány. Az alkalmazáskiszolgáló az alkalmazást futtató webkiszolgálóra hivatkozik, például a Tomcat 11-et egy Azure App Service-környezetben. Manuális rendszerezés használatakor gondoskodnia kell arról, hogy az ügynök JAR-fájlja megfelelően legyen elhelyezve az alkalmazáskiszolgálón.

Az autoinstrumentációhoz a mintavételezési felülbírálásokat az Azure Portalon konfigurálhatja. Ha manuális műszerezést használ, helyezze az Application Insights-ügynök JAR-t a megfelelő könyvtárba, és vegye fel a applicationinsights.json fájlt a kívánt mintavételezési beállításokkal.

További információ: Mintavételezési felülbírálások – Azure Monitor Application Insights for Java.

A TelemetryClient.trackTrace() az Application Insights klasszikus SDK-hídjának része, és a naplóprocesszorok csak az új OpenTelemetry-alapú kialakítással működnek.

További információ: Telemetriai processzorok (előzetes verzió) – Azure Monitor Application Insights for Java.

• A JavaScript SDK beállít egy felhasználói cookie-t a webes ügyfélen a visszatérő felhasználók azonosításához, valamint egy munkamenet-cookie-t a tevékenységek csoportosításához.
• Ha nincs ügyféloldali szkript, beállíthatja a cookie-kat a kiszolgálón.
• Ha egy valódi felhasználó különböző böngészőkben használja a webhelyet, vagy privát/inkognitó böngészést vagy különböző gépeket használ, a rendszer többször is megszámolja őket.
• Ha egy bejelentkezett felhasználót szeretne azonosítani a gépeken és böngészőkben, adjon hozzá egy hívást a setAuthenticatedUserContext() beállításhoz.

Az Application Insights JavaScript SDK minimális többletterheléssel rendelkezik a webhelyén. Az SDK mindössze 36 KB-os méretű, és csak ~15 ms-ot vesz igénybe az inicializáláshoz, az SDK elhanyagolható mennyiségű betöltési időt ad hozzá a webhelyhez. Az SDK használatakor a kódtár minimális összetevői gyorsan betölthetők, és a teljes szkript a háttérben lesz letöltve.

Emellett, miközben a szkript a CDN-ből tölt le, az oldal minden nyomon követése várólistára kerül, így a lap teljes életciklusa során nem veszít el telemetriát. Ez a beállítási folyamat zökkenőmentes elemzési rendszert biztosít a lapnak, amely láthatatlan a felhasználók számára.

Chrome legújabb ✔	Firefox legújabb ✔	v3.x: IE 9+ > Microsoft Edge ✔ v2.x: IE 8+ kompatibilis & Microsoft Edge ✔	Opera legújabb ✔	Safari legújabb ✔

Futtatható példákért tekintse meg az Application Insights JavaScript SDK-mintáit.

Meg kell hoznunk a szükséges intézkedéseket annak érdekében, hogy ez az SDK továbbra is "működjön", és ne törje meg a JavaScript végrehajtását, amikor egy régebbi böngésző betölti. Ideális lenne, ha nem támogatná a régebbi böngészőket, de számos nagy ügyfél nem tudja szabályozni, hogy a felhasználók melyik böngészőt használják.

Ez az állítás nem jelenti azt, hogy csak a legalacsonyabb általános funkciókat támogatjuk. Fenn kell tartanunk az ES3-kódkompatibilitást. Az új funkciókat úgy kell hozzáadni, hogy az ne törje meg az ES3 JavaScript-elemzést, és opcionális funkcióként legyen hozzáadva.

Az Internet Explorer 8 támogatásával kapcsolatos részletes információkért tekintse meg a GitHubot.

Igen, az Application Insights JavaScript SDK nyílt forráskód. A forráskód megtekintéséhez vagy a projekthez való hozzájáruláshoz tekintse meg a hivatalos GitHub-adattárat.

További információ: Az Azure Monitor Application Insights valós felhasználói monitorozásának engedélyezése.

A kiszolgálóoldalnak képesnek kell lennie a jelen lévő fejlécekkel való kapcsolatok elfogadására. A kiszolgálóoldali konfigurációtól függően gyakran szükséges a kiszolgálóoldali lista kiterjesztése a Access-Control-Allow-Headers, Request-Id, és Request-Context elemek manuális hozzáadásával (W3C elosztott fejléc).

Access-Control-Allow-Headers: Request-Id, traceparent, , Request-Context<your header>

Az elosztott nyomkövetés konfigurációban letiltható.

Nem. Az Application Insights nem mindig rögzíti az "502 hibás átjáró" és az "503 szolgáltatás nem érhető el" hibákat. Ha csak ügyféloldali JavaScriptet használ a monitorozáshoz, ez a viselkedés azért várható, mert a hibaválasz a HTML-fejlécet tartalmazó oldal előtt jelenik meg, és megjelenik a figyelési JavaScript-kódrészlet.

Ha az 502- vagy az 503-at kiszolgálóoldali monitorozással rendelkező kiszolgálóról küldték, a hibákat az Application Insights SDK gyűjti össze.

Még akkor is, ha egy alkalmazás webkiszolgálóján engedélyezve van a kiszolgálóoldali monitorozás, az Application Insights néha nem rögzíti az 502-503-at. Számos modern webkiszolgáló nem teszi lehetővé az ügyfél számára a közvetlen kommunikációt. Ehelyett olyan megoldásokat alkalmaznak, mint a fordított proxyk, hogy az adatokat oda-vissza továbbítják az ügyfél és az előtérbeli webkiszolgálók között.

Ebben az esetben előfordulhat, hogy egy 502-es vagy 503-es választ ad vissza egy ügyfélnek a fordított proxyrétegen jelentkező probléma miatt, így az Application Insights nem rögzíti a rendszerből. A réteg problémáinak észleléséhez előfordulhat, hogy a fordított proxyból a Log Analyticsbe kell továbbítania a naplókat, és létre kell hoznia egy egyéni szabályt, amely 502 vagy 503 választ keres. Az 502-ben és 503-ban előforduló hibák gyakori okairól az "502 hibás átjáró" és az "503 szolgáltatás nem érhető el" HTTP-hibáinak hibaelhárítása Azure-alkalmazás szolgáltatásban című témakörben olvashat.

További információ: Application Insights JavaScript SDK-konfiguráció.

A böngésző átadja a User Agent karakterláncot a kérés HTTP-fejlécében. Az Application Insights betöltési szolgáltatás az UA Parser használatával hozza létre az adattáblákban és -szolgáltatásokban látható mezőket. Ennek eredményeképpen az Application Insights felhasználói nem tudják módosítani ezeket a mezőket.

Előfordulhat, hogy ezek az adatok hiányoznak vagy pontatlanok, ha a felhasználó vagy a vállalat letiltja a felhasználói ügynök küldését a böngésző beállításai között. Előfordulhat, hogy az UA Parser regexes nem tartalmazza az összes eszközinformációt. Vagy előfordulhat, hogy az Application Insights nem fogadta el a legújabb frissítéseket.

További információ: Keretrendszerbővítmény engedélyezése az Application Insights JavaScript SDK-hoz.

Nem. A meglévő ARM-sablonok és API-hívások továbbra is működnek. Amikor klasszikus erőforrást próbál létrehozni, a rendszer ehelyett egy felügyelt munkaterületet tartalmazó munkaterület-alapú erőforrást hoz létre.

Nem. Az egyes erőforrás-áttelepítésekről szóló értesítés nem érhető el. Az erőforrások migrálásának időpontjának és módjának szabályozásához használja a manuális migrálást.

Az egyes áttelepítések általában kevesebb mint két perc alatt befejeződnek. A teljes bevezetés több héten keresztül zajlik az összes régióban.

A migrálás után az erőforrás egy Log Analytics-munkaterületre mutat az Áttekintés lapon. A rendszer eltávolítja a klasszikus kivonási értesítést, és a kivonási munkafüzet már nem sorolja fel az erőforrást.

A költségek általában hasonlóak maradnak. A munkaterület-alapú Application Insights költségmegtakarítási funkciókat tesz lehetővé, és javasoljuk, hogy tekintse át a díjszabási csomagokat.

Ha régi számlázási modellen dolgozik, a részletekért tekintse át a díjszabási dokumentációt .

Nem. Az összes riasztás, irányítópult és rendelkezésre állási teszt érintetlen marad, és a migrálás után is működik.

További információ: Felügyelt munkaterületek az Application Insightsban.

A telemetriai korreláció letiltásához használja a tulajdonságot a correlationHeaderExcludedDomains konfigurációban. További információ: ApplicationInsights-node.js.

Az Application Insights által használni kívánt naplószint konfigurálásához használja a környezeti változót APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . A támogatott értékek: NONE, ERROR, WARN, INFO, DEBUG, VERBOSE és ALL. További információ: ApplicationInsights-node.js.

További információ: A Node.js-szolgáltatások és -alkalmazások monitorozása az Application Insights használatával.

Az SDK-verziók és -nevek listája a GitHubon található. További információ: SDK-verzió.

További információ: Telemetriai adatok gyűjtése OpenTelemetry használatával az Application Insightsban.

Az OpenTelemetry egy szállítósemleges megfigyelhetőségi keretrendszer. Az OpenTelemetry SDK-ban vagy tárakban nincsenek Application Insights API-k. A migrálás előtt fontos tisztában lenni az OpenTelemetry néhány alapfogalmaival.

• Az Application Insightsban az összes telemetriát egyetlen TelemetryClient és TelemetryConfigurationegy . Az OpenTelemetria esetében a három telemetriai jel (Traces, Metrics és Logs) mindegyike saját konfigurációval rendelkezik. A .NET-futtatókörnyezeten keresztül manuálisan is létrehozhat telemetriát külső kódtárak nélkül. További információ: .NET-útmutatók az elosztott nyomkövetésről, a metrikákról és a naplózásról.

• Az Application Insights az alkalmazás telemetriai adatainak automatikus gyűjtésére szolgál TelemetryModules . Ehelyett az OpenTelemetry Instrumentation-kódtárak használatával gyűjt telemetriát adott összetevőkből (például AspNetCore for Requests és HttpClient for Dependencies).

• Az Application Insights TelemetryInitializers további információkkal bővíti a telemetriát, vagy felülírja a tulajdonságokat. Az OpenTelemetria segítségével egy processzort írhat egy adott jel testreszabásához. Emellett számos OpenTelemetry Instrumentation-kódtár kínál metódust Enrich az adott összetevő által létrehozott telemetriai adatok testreszabására.

• A telemetriai adatok szűréséhez használt TelemetryProcessors Application Insights. Az OpenTelemetria-feldolgozóval szűrési szabályokat is alkalmazhat egy adott jelre.

Ez a táblázat az Application Insights adattípusait OpenTelemetry-fogalmakra és azok .NET-implementációira képezi le.

Azure Monitor-tábla	Application Insights adattípus	OpenTelemetry adattípus	.NET-implementáció
egyedi események	EventTelemetria	Nincs adat.	Nincs adat.
egyedi metrikák	MetricTelemetry	Mértékek	System.Diagnostics.Metrics.Meter
függőségek	DependencyTelemetria	Spans (ügyfél, belső, fogyasztó)	System.Diagnostics.Activity
Kivételek	ExceptionTelemetry	Kivételek	System.Exception
Kérelmek	RequestTelemetry (Kéréses Telemetria)	Spans (kiszolgáló, gyártó)	System.Diagnostics.Activity
hívásláncok	Nyomkövető Telemetria	Naplók	Microsoft.Extensions.Logging.ILogger
hívásláncok	Nyomkövető Telemetria	Események időtartama	System.Diagnostics.ActivityEvent

Az alábbi dokumentumok további információkat tartalmaznak.

• Az Azure Monitor Application Insights adatgyűjtési alapjai
• Application Insights telemetria adatmodell
• Az OpenTelemetry fogalmai

Bár az Application Insights több lehetőséget is kínált a mintavételezés konfigurálására, az Azure Monitor Exportőr vagy az Azure Monitor Disztribúció csak rögzített gyakoriságú mintavételezést kínál. Csak a kérelmek és függőségek (OpenTelemetry Traces) mintavétele használható.

A mintavételezés konfigurálásának módját részletező kódmintákért tekintse meg a mintavételezés engedélyezése című útmutatót

Az Application Insights .NET SDK-ban telemetriai processzorokkal szűrheti és módosíthatja vagy elvetheti a telemetriát. A telemetriai inicializálókkal egyéni tulajdonságokat adhat hozzá vagy módosíthat. További információkért tekintse meg az Azure Monitor dokumentációját. Az OpenTelemetry ezeket a fogalmakat tevékenység- vagy naplófeldolgozókra cseréli, amelyek bővítik és szűrik a telemetriát.

Nyomkövetések szűrése

Az OpenTelemetry telemetriai adatainak szűréséhez megvalósíthat egy tevékenységfeldolgozót. Ez a példa egyenértékű az Application Insights-példával a telemetriai adatok szűréséhez az Azure Monitor dokumentációjában leírtak szerint. A példa bemutatja, hogy hol szűri a sikertelen függőségi hívásokat.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

A processzor használatához előbb létre kell hoznia egy processzort TracerProvider , majd hozzá kell adnia a processzort AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Naplók szűrése

ILoggeraz implementációk beépített mechanizmussal rendelkeznek a naplószűrés alkalmazásához. Ezzel a szűréssel szabályozhatja az egyes regisztrált szolgáltatóknak küldött naplókat, beleértve a OpenTelemetryLoggerProvider. Az "OpenTelemetry" a szűrési szabályok konfigurálásához használt aliasOpenTelemetryLoggerProvider.

Az alábbi példa a "Hiba" értéket határozza meg alapértelmezettként LogLevel , és a "Figyelmeztetés" értéket is definiálja a felhasználó által definiált kategóriák minimális LogLevel értékeként. Ezek a definiált szabályok csak a OpenTelemetryLoggerProvider.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

További információkért olvassa el az OpenTelemetry .NET dokumentációját a naplókban.

Egyéni tulajdonságok hozzáadása nyomkövetésekhez

Az OpenTelemetryben tevékenységprocesszorokkal bővítheti a telemetriai adatokat további tulajdonságokkal. Hasonló az Application Insights telemetriai inicializálóihoz, ahol módosíthatja a telemetriai tulajdonságokat.

Az Azure Monitor Exporter alapértelmezés szerint megjelöli a sikertelennek minősülő 400-as vagy annál nagyobb válaszkóddal rendelkező HTTP-kéréseket. Ha azonban sikerként szeretné kezelni a 400-ast, hozzáadhat egy bővítő tevékenységfeldolgozót, amely beállítja a tevékenység sikerét, és hozzáad egy címkét, amely további telemetriai tulajdonságokat tartalmaz. Hasonló a tulajdonságok hozzáadásához vagy módosításához az Application Insights inicializálójával az Azure Monitor dokumentációjában leírtak szerint.

Íme egy példa arra, hogyan adhat hozzá egyéni tulajdonságokat, és hogyan bírálhatja felül bizonyos válaszkódok alapértelmezett viselkedését:

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

A processzor használatához előbb létre kell hoznia egy processzort TracerProvider , majd hozzá kell adnia a processzort AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

Nyomkövetések küldése – Manuális

Az Application Insights nyomkövetéseit a rendszer a következő formátumban RequestTelemetry tárolja: és DependencyTelemetry. Az OpenTelemetryben a nyomkövetések az Span osztály használatával modellezhetőkActivity.

Az OpenTelemetry .NET a ActivitySource .NET-futtatókörnyezet részét képező nyomkövetési osztályokat és Activity osztályokat használja. Ez a megközelítés azért megkülönböztető, mert a .NET-implementáció közvetlenül a futtatókörnyezetbe integrálja a nyomkövetési API-t. A System.Diagnostics.DiagnosticSource csomag lehetővé teszi a fejlesztők számára a ActivitySource példányok létrehozását és kezelését Activity . Ez a módszer zökkenőmentes módot biztosít a .NET-alkalmazások nyomkövetésének hozzáadására külső kódtárak használata nélkül, a .NET-ökoszisztéma beépített képességeinek alkalmazásával. Részletesebb információkért tekintse meg az elosztott nyomkövetési rendszerállapot útmutatóit.

A manuális nyomkövetés migrálása az alábbiak szerint lehetséges:

Megjegyzés:

Az Application Insightsban a szerepkör neve és szerepkörpéldánya telemetriaszinten állítható be. Az Azure Monitor-exportőr esetében azonban nem tudunk telemetriaszinten testre szabni. A szerepkör nevét és szerepkörpéldányát a rendszer kinyeri az OpenTelemetry erőforrásból, és alkalmazza az összes telemetriára. További információért olvassa el ezt a dokumentumot: Állítsa be a felhőbeli szerepkör nevét és a felhőbeli szerepkörpéldányt.

DependencyTelemetria

Az Application Insights DependencyTelemetry a kimenő kérések modellezésére szolgál. Az alábbiak szerint konvertálhatja OpenTelemetryre:

Példa az Application Insights szolgáltatásra:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

OpenTelemetria- példa:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

RequestTelemetry (Kéréses Telemetria)

Az Application Insights RequestTelemetry modelleli a bejövő kéréseket. Az alábbiak szerint migrálhatja az OpenTelemetrybe:

Példa az Application Insights szolgáltatásra:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

OpenTelemetria- példa:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

Egyéni műveletek nyomon követése

Az Application Insightsban kövesse nyomon az egyéni műveleteket és StartOperationStopOperation metódusokat. Ezt az OpenTelemetry .NET használatával ActivitySource és Activity használatával érheti el. Az Azure Monitor Exportőrrel végzett ActivityKind.ServerActivityKind.Consumerműveletekhez az Azure Monitor Exporter generál RequestTelemetry. A ActivityKind.Client, ActivityKind.Producerés ActivityKind.Internala generált DependencyTelemetry. Az egyéni műveletek nyomon követésével kapcsolatos további információkért tekintse meg az Azure Monitor dokumentációját. A .NET használatával ActivitySource és Activity használatával kapcsolatos további információkért tekintse meg a .NET elosztott nyomkövetési eszközökkel kapcsolatos útmutatókat.

Íme egy példa az egyéni műveletek tevékenységének elindítására és leállítására:

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

Naplók küldése

Az Application Insights naplóit a rendszer a következő formátumban TraceTelemetry tárolja: és ExceptionTelemetry.

Nyomkövető Telemetria

Az OpenTelemetryben a naplózás az ILogger interfészen keresztül integrálva van. Az alábbiak szerint migrálhatja TraceTelemetrya következőt:

Példa az Application Insights szolgáltatásra:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

OpenTelemetria- példa:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

ExceptionTelemetry

Az Application Insights kivételeket naplóz ExceptionTelemetry . Az Alábbiak szerint migrálhat az OpenTelemetrybe:

Példa az Application Insights szolgáltatásra:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

OpenTelemetria- példa:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

Metrikák küldése

Az Application Insights metrikái a következőképpen vannak tárolva MetricTelemetry: . Az OpenTelemetryben a metrikák a Meter csomagból modellezhetőkSystem.Diagnostics.DiagnosticSource.

Az Application Insights nem előre összesítő (TrackMetric()) és preaggregating (GetMetric().TrackValue()) metrika API-kkal is rendelkezik. Az OpenTelemetryvel ellentétben az Application Insights nem rendelkezik eszközökkel. Az Application Insights minden metrikaforgatókönyvhez ugyanazzal az API-val rendelkezik.

Az OpenTelemetria azonban megköveteli, hogy a felhasználók először a metrika tényleges szemantikája alapján válasszák ki a megfelelő metrikaeszközt . Ha például a szándék valami megszámlálása (például a fogadott kiszolgálói kérelmek száma stb.), akkor az OpenTelemetry Számlálót kell használni. Ha a cél különböző percentilisek kiszámítása (például a kiszolgáló késésének P99-értéke), akkor az OpenTelemetria hisztogram eszközt kell használni. Az Application Insights és az OpenTelemetria közötti alapvető különbség miatt nem történik közvetlen összehasonlítás közöttük.

Az Application Insightstól eltérően az OpenTelemetria nem biztosít beépített mechanizmusokat a metrikák bővítéséhez vagy szűréséhez. Az Application Insightsban telemetriai processzorok és inicializálók használhatók metrikák módosítására vagy elvetésére, de ez a képesség nem érhető el az OpenTelemetryben.

Emellett az OpenTelemetria nem támogatja a nyers metrikák közvetlen küldését, mivel nincs egyenértékű az TrackMetric() Application Insightsban található funkcióval.

Az Application Insights-ból az OpenTelemetrybe való migrálás során az Összes Application Insights Metric API-használat lecserélése az OpenTelemetry API-ra. Ehhez ismernie kell a különböző OpenTelemetry-eszközöket és azok szemantikáját.

Jótanács

A hisztogram a legsokoldalúbb és a legközelebbi egyenértékű az Application Insights GetMetric().TrackValue() API-val. Az Application Insights metrika API-jait lecserélheti hisztogramra, hogy ugyanazt a célt elérjék.

Egyéb telemetriai típusok

Egyéni események

Az OpenTelemetria nem támogatott.

Példa az Application Insights szolgáltatásra:

TelemetryClient.TrackEvent()

Elérhetőség Telemetria

Az OpenTelemetria nem támogatott.

Példa az Application Insights szolgáltatásra:

TelemetryClient.TrackAvailability()

Oldalmegtekintés Telemetria

Az OpenTelemetria nem támogatott.

Példa az Application Insights szolgáltatásra:

TelemetryClient.TrackPageView()

Javasoljuk az Azure Monitor OpenTelemetry-exportőrt a konzol- és feldolgozószolgáltatás-alkalmazásokhoz, amelyek nem tartalmaznak élő metrikákat.

További információ: Migrálás a .NET Application Insights SDK-ból az Azure Monitor OpenTelemetrybe.

Az Application Insights egyéni mintavevője a mintavételezési döntéseket a span létrehozása után hozza meg, nem pedig előtte, így nem követi a hagyományos, fejalapú megközelítést. Ehelyett a mintavételezési döntéseket a kiterjedési szakasz generálása végén alkalmazza – a kiterjedési szakasz befejezése után, de az exportálás előtt.

Bár ez a viselkedés bizonyos szempontból hasonlít a tail-alapú mintavételezésre, a mintavevő nem várja meg, hogy több időtartamot gyűjtsön ugyanabból a nyomból, mielőtt meghozná a mintavételi döntést. Ehelyett a nyomkövetési azonosító kivonatával biztosítja a nyomkövetés teljességét.

Ez a megközelítés kiegyensúlyozza a nyomkövetés teljességét és hatékonyságát, és elkerüli a teljes farokalapú mintavételezéssel járó magasabb költségeket.

Ahhoz, hogy mintavételezési döntéseket hozzon egy teljes nyomkövetés eredménye alapján (például annak meghatározásához, hogy a nyomkövetésen belüli bármely időtartam sikertelen volt-e), teljes, tail-alapú mintavételezésre van szükség egy alsóbb rétegbeli ügynökben vagy gyűjtőben. Ez a funkció jelenleg nem támogatott, de a Visszajelzési központon keresztül kérheti új funkcióként.

Mintavételezési módszer	Döntési pont	Erősségek	Gyenge pontok
Fejközpontú	Egy szakasz kezdete előtt	Alacsony késés, minimális többletterhelés	Mintát vehet a kívánt nyomkövetési mintákból, beleértve a hibákat is
Tail-alapú	A szakaszok idő- vagy kötetküszöbök alapján történő pufferelése után	Lehetővé teszi a szigorúan szelektív nyomkövetési mintavételezési kritériumokat	Magasabb költség és hozzáadott feldolgozási késés
Egyéni App Insights-mintavevő	A tartománygenerálás vége	A nyomkövetési teljesség és a hatékonyság egyensúlya	Élő metrikákhoz és klasszikus API-kompatibilitáshoz szükséges

Nem, a mintavevő rögzített sebességet alkalmaz a nyomkövetés összes telemetriai típusára. A kérelmek, függőségek és egyéb tartományok ugyanazt a mintavételezési százalékot követik. A telemetriai típusonként különböző arányok beállításához fontolja meg az OpenTelemetry span processzorok vagy (adatbevételi időben történő átalakítások)[opentelemetry-overview.md#telemetry-routing] használatát.

Az Application Insights egyéni mintavevő alapértelmezés szerint a W3C Trace Context szabvány használatával propagálja a mintavételezési döntéseket. Ez a szabvány lehetővé teszi a mintavételezési döntéseket a szolgáltatások között. Mivel azonban a mintavevő a mintavételezési döntéseket a span generáció végén hozza meg – az alsóbb rétegbeli szolgáltatások hívása után –, a propagálás hiányos mintavételi információkat tartalmaz. Ez a korlátozás megfelel a W3C nyomkövetési környezet specifikációjának, de az alárendelt szolgáltatások nem tudják megbízhatóan használni ezt a propagált mintavételezési döntést.

Nem, az Application Insights egyéni mintavevője mindig független mintavételezési döntést hoz, még akkor is, ha a felsőbb rétegbeli szolgáltatás ugyanazt a mintavételezési algoritmust használja. A felsőbb rétegbeli szolgáltatásokból – beleértve a W3C Trace Context fejléceket használókat is – származó mintavételezési döntések nem befolyásolják az alsóbb rétegbeli szolgáltatás döntését. A nyomkövetési azonosító kivonata alapján azonban mintát is végez a nyomkövetés teljességének biztosítása érdekében. A konzisztencia javítása és a hibás nyomkövetések esélyének csökkentése érdekében konfigurálja a rendszer összes összetevőjét ugyanarra a mintavevőre és mintavételezési sebességre.

A nyomkövetések több okból is hiányosnak tűnhetnek:

• Az elosztott rendszerek különböző csomópontjai különböző mintavételezési módszereket használnak, amelyek nem koordinálják a döntéseket. Az egyik csomópont például openTelemetria-alapú mintavételezést alkalmaz, egy másik csomópont pedig az Azure Monitor Egyéni mintavevőn keresztüli mintavételezést.
• A különböző csomópontok eltérő mintavételezési sebességre vannak beállítva, még akkor is, ha mindkettő ugyanazt a mintavételezési módszert használja.
• A szolgáltatás oldali adatfolyamban állíthatja be a szűrést, mintavételezést vagy sebességkorlátokat, és ez a konfiguráció véletlenszerűen mintavételezi a szakaszokat anélkül, hogy figyelembe venné a nyomkövetés teljességét.

Ha egy összetevő fejlécalapú mintavételezést alkalmaz a mintavételezési döntés propagálása nélkül (a W3C Trace Context fejlécek révén), a lefelé mutató szolgáltatások függetlenül mintát vesznek a nyomkövetésből, ami eldobott szakaszokat eredményezhet. Ennek eredményeképpen a nyomkövetés egyes részei nem mindig érhetők el az Application Insightsban való megtekintéskor.

További információ: Mintavételezés az Azure Monitor Application Insightsban OpenTelemetry használatával.

Ez egy nyílt forráskódú szabvány a megfigyelhetőséghez. További információ az OpenTelemetryről.

A Microsoft az alábbi okokból fektet be az OpenTelemetrybe:

• Szállítósemleges, és egységes API-kat/SDK-kat biztosít a nyelvek között.
• Úgy gondoljuk, hogy az OpenTelemetry idővel lehetővé teszi az Azure Monitor-ügyfelek számára, hogy a támogatott nyelveken kívül más nyelveken írt alkalmazásokat figyeljenek meg.
• Kibővíti az instrumentációs könyvtárak gazdag készletén keresztül gyűjthető adattípusokat.
• Az OpenTelemetry Software Development Kits (SDK-k) általában nagyobb teljesítményűek, mint elődjeik, az Application Insights SDK-k.
• Az OpenTelemetria megfelel a Microsoft stratégiájának, amely nyílt forráskód.

Lásd: OpenTelemetry Status.

Úgy tekinthet rá, mint egy vékony burkolóra, amely összecsomagol minden OpenTelemetry-összetevőt egy első osztályú Azure-élmény érdekében. Ezt a burkolót az OpenTelemetryben disztribúciónak is nevezik.

Az Azure Monitor OpenTelemetry Distro használatának számos előnye van a közösség natív OpenTelemetry-ével szemben:

• Csökkenti az engedélyezési erőfeszítéseket
• A Microsoft támogatja
• Bevezeti az Azure-specifikus funkciókat, mint például a következők:
  • Klasszikus Application Insights SDK-kkal kompatibilis mintavételezés
  • Microsoft Entra hitelesítés
  • Offline tárolás és automatikus újrapróbálás
  • Statsbeat
  • Application Insights Standard metrikák
  • Erőforrás-metaadatok észlelése a felhőszerepkör nevének és a felhőbeli szerepkörpéldánynak a különböző Azure-környezeteken való automatikus feltöltéséhez
  • Élő metrikák

Az OpenTelemetria szellemében úgy terveztük meg a disztribúciót, hogy nyitott és bővíthető legyen. Hozzáadhatja például a következőt:

• OpenTelemetry Protocol (OTLP) exportőr, és egyidejűleg küldje el egy második célállomásra.
• A disztribúcióban nem szereplő egyéb eszközkönyvtárak

Mivel a Disztribúció OpenTelemetria-disztribúciót biztosít, a Disztribúció az OpenTelemetria által támogatott bármit támogat. Hozzáadhat például több telemetriai processzort, exportőrt vagy rendszerállapot-kódtárat, ha az OpenTelemetria támogatja őket.

Megjegyzés:

A disztribúció testreszabott, rögzített arányú mintavevőre állítja a mintavevőt az Application Insights-hoz. Ezt módosíthatja egy másik mintavevőre, de ezzel letilthatja a Disztribúció egyes funkcióit. A támogatott mintavevőről az Azure Monitor OpenTelemetria konfigurálásának mintavételezés engedélyezése című szakaszában talál további információt.

A támogatott önálló OpenTelemetry-exportőr nélküli nyelvek esetében az Azure Monitor OpenTelemetry Distro az egyetlen jelenleg támogatott módszer az OpenTelemetry és az Azure Monitor használatára. A támogatott önálló OpenTelemetry-exportőrrel rendelkező nyelvek esetében lehetősége van az Azure Monitor OpenTelemetry Distro vagy a megfelelő önálló OpenTelemetry-exportőr használatára a telemetriai forgatókönyvtől függően. További információ: Mikor érdemes használni az Azure Monitor OpenTelemetry-exportőrt?.

Tekintse meg a .NET, a Java, a JavaScript (Node.js) és a Python engedélyezési dokumentációját.

Az Azure Monitor OpenTelemetry Distro használatát javasoljuk új projektekhez, ha képességei megfelelnek a monitorozási igényeknek. Az OpenTelemetry egy iparági szabványnak megfelelő keretrendszer, amely javítja a platformfüggetlen megfigyelhetőséget, és szabványosított megközelítést biztosít a telemetriai adatgyűjtéshez.

Az Application Insights SDK-k azonban továbbra is biztosítanak bizonyos képességeket, amelyek még nem teljesen automatizáltak az OpenTelemetryben, beleértve a következőket:

• Automatikus függőségkövetés – Az OpenTelemetria támogatja a függőségek nyomon követését, de egyes függőségek további konfigurációt igényelnek az Application Insights SDK-kban elérhető automatikus nyomkövetéshez képest.
• Egyéni telemetriai típusok, például AvailabilityTelemetry és PageViewTelemetry – Az OpenTelemetria nem rendelkezik közvetlen egyenértékűségekkel. Hasonló funkciók manuális rendszerezéssel valósíthatók meg.
• Telemetriai processzorok és inicializálók – Az OpenTelemetry processzorokkal és span processzorokkal rendelkezik, de nem helyettesítik teljesen az Application Insights telemetriai processzorait és inicializálóit minden forgatókönyvben.
• Kiterjesztett metrikák gyűjteménye – Bár az OpenTelemetria erős metrikarendszerrel rendelkezik, az Application Insights SDK-k beépített metrikáinak egy része manuális beállítást igényel az OpenTelemetryben.

Az OpenTelemetria az Application Insights SDK-kkal szemben is kínál előnyöket, például:

• Jobb szabványosítás a platformok között
• Az instrumentumkönyvtárak szélesebb ökoszisztémája
• Nagyobb rugalmasság az adatgyűjtés és -feldolgozás terén
• Továbbfejlesztett szállítósemlegesség, bár az Azure Monitor OpenTelemetry Distro továbbra is az Azure-ra van optimalizálva.

Az Azure Monitor OpenTelemetry-integrációja folyamatosan fejlődik, és a Microsoft továbbra is fejleszti képességeit. Ha áttűnést fontolgat, gondosan értékelje ki, hogy az OpenTelemetria jelenleg megfelel-e a megfigyelhetőségi követelményeknek, vagy az Application Insights SDK továbbra is megfelel az igényeinek.

ASP.NET Core, Java, Node.js és Python esetén az Azure Monitor OpenTelemetry Distro használatát javasoljuk. Ez egy kódsor az első lépésekhez.

Minden más .NET-forgatókönyv esetében, beleértve a klasszikus ASP.NET, a konzolalkalmazásokat, a Windows Formst (WinForms) stb., javasoljuk, hogy használja a .NET Azure Monitor OpenTelemetry exportőrt: Azure.Monitor.OpenTelemetry.Exporter.

Összetettebb, speciális konfigurációt igénylő Python-telemetriai forgatókönyvek esetén javasoljuk a Python Azure Monitor OpenTelemetry-exportőr használatát.

Az alábbi diagram az Egyes nyelvek OpenTelemetry funkciójának támogatását mutatja be.

Tulajdonság	.HÁLÓ	Node.js	Piton	Jáva
Elosztott nyomkövetés	✅	✅	✅	✅
Egyéni metrikák	✅	✅	✅	✅
Standard metrikák	✅	✅	✅	✅
Rögzített gyakoriságú mintavételezés	✅	✅	✅	✅
Offline tárolás és automatikus újrapróbálás	✅	✅	✅	✅
Kivételjelentés	✅	✅	✅	✅
Naplók gyűjteménye	✅	⚠️	✅	✅
Egyéni események	⚠️	⚠️	⚠️	✅
Microsoft Entra hitelesítés	✅	✅	✅	✅
Élő metrikák	✅	✅	✅	✅
Élő metrikák szűrése	✅	❌	❌	❌
Erőforrás-környezet észlelése virtuális géphez/VMSS-hez és App Service-hez	✅	❌	✅	✅
Az Azure Kubernetes Service (AKS) és a Functions erőforrás-környezetének észlelése	❌	❌	❌	✅
A Rendelkezésre állás nyomon követése API használatával létrehozott rendelkezésre állási tesztelési események	❌	❌	❌	✅
Kérelmek, függőségek, naplók és kivételek szűrése névtelen felhasználói azonosító és szintetikus forrás alapján	❌	❌	❌	✅
Függőségek, naplók és kivételek szűrése műveletnév alapján	❌	❌	❌	✅
Adaptív mintavételezés	❌	❌	❌	✅
.NET Profiler	⚠️	❌	❌	⚠️
Képernyőkép-hibakereső	❌	❌	❌	❌

Kulcs

• ✅ Ez a funkció minden hivatalos támogatással rendelkező ügyfél számára elérhető.
• ⚠️ Ez a funkció nyilvános előzetes verzióként érhető el. Lásd a Microsoft Azure előzetes verziójának használati feltételeit.
• ❌ Ez a funkció nem érhető el, vagy nem alkalmazható.

Igen, de nem javasoljuk, és az Azure nem támogatja. Az OpenTelemetry JavaScript nagymértékben optimalizálva van Node.js-ra. Ehelyett az Application Insights JavaScript SDK használatát javasoljuk.

Az OpenTelemetry webes SDK nem rendelkezik meghatározott rendelkezésre állási ütemtervvel. Valószínűleg több évnyire vagyunk a böngésző SDK-tól, amely az Application Insights JavaScript SDK életképes alternatívája.

Az OpenTelemetry webes tesztkörnyezete egy elágazás, amely arra szolgál, hogy az OpenTelemetria működjön egy böngészőben. Még nem lehet telemetriát küldeni az Application Insightsnak. Az SDK nem definiál általános ügyféleseményeket.

Ezt a gyakorlatot nem tervezzük tesztelni vagy támogatni, bár distribúcióink lehetővé teszik, hogy egyszerre exportáljon egy OTLP-végpontra az Azure Monitor mellett.

Nem javasoljuk. Lásd a Microsoft Azure előzetes verziójának használati feltételeit.

Tekintse meg az OpenTelemetry áttekintését.

Egyes ügyfelek az OpenTelemetry Collectort használják ügynök alternatívaként, annak ellenére, hogy a Microsoft hivatalosan még nem támogatja az alkalmazásfigyelés ügynökalapú megközelítését. Addig is a nyílt forráskódú közösség hozzájárult egy OpenTelemetry Collector Azure Monitor-exportőrhöz , amellyel egyes ügyfelek adatokat küldenek az Azure Monitor Application Insightsnak. Ezt a Microsoft nem támogatja.

Az OpenCensus az OpenTelemetria előfutára. A Microsoft segített összehozni az OpenTracinget és az OpenCensust az OpenTelemetria létrehozásához, amely a világ egyetlen megfigyelhetőségi szabványa. Az Azure Monitorhoz készült, jelenleg ajánlott éles használatra szánt Python SDK az OpenCensuson alapul. A Microsoft elkötelezett az Azure Monitor OpenTelemetria-alapúvá tétele mellett.

Az OpenTelemetry-nyomkövetések helyett nyers szöveges naplókat is megpróbálhat vizualizálni.

Az Application Insightsban a "Traces" tábla diagnosztikai célokra tárolja a nyers szöveges naplókat. Segítséget nyújt a felhasználói kérésekhez, egyéb eseményekhez és kivételjelentésekhez kapcsolódó nyomkövetések azonosításához és korrelálásához. A "Traces" tábla azonban nem járul hozzá közvetlenül a végpontok közötti tranzakciós nézethez (vízesésdiagram) olyan vizualizációs eszközökben, mint a Grafana.

A felhőalapú gyakorlatok egyre elterjedtebbé válása miatt a telemetria gyűjtése és terminológia is folyamatosan fejlődik. Az OpenTelemetria a telemetriai adatok gyűjtésének és rendszerezésének szabványává vált. Ebben az összefüggésben a "Traces" kifejezés új értelmet kapott. A nyers naplók helyett az OpenTelemetryben a "Traces" a telemetriai adatok gazdagabb, strukturált formájára utal, amely kiterjedéseket is tartalmaz, amelyek az egyes munkaegységeket jelölik. Ezek az időtartamok kulcsfontosságúak a részletes tranzakciónézetek létrehozásához, ami jobb monitorozást és diagnosztikát tesz lehetővé a natív felhőbeli alkalmazások számára.

Egy Blazor-alkalmazás instrumentálásához először azonosítsa az üzemeltetési modellt. A Blazor Server támogatja a teljes OpenTelemetria-alapú rendszerezést. A Blazor WebAssembly a böngészőben fut, és JavaScript-en keresztül támogatja a korlátozott műszeres támogatást.

További információ: OpenTelemetry Support and Feedback for Application Insights.

Nem, egy irányítópulton legfeljebb 30 napnyi adat jelenik meg.

Ha áthelyezi vagy átnevezi az Application Insights-példányt, "nem található erőforrás" hibaüzenet jelenhet meg.

Ennek a viselkedésnek a megkerüléséhez törölje az alapértelmezett irányítópultot, és válassza újra az Alkalmazás irányítópultot egy új létrehozásához.

További információt az Application Insights áttekintési irányítópultján talál.

A rövid válasz az, hogy egyik beépített csatorna sem biztosít tranzakciótípusú garanciát a telemetria háttérbe történő kézbesítésére. ServerTelemetryChannel a megbízható kézbesítéshez képest InMemoryChannel fejlettebb, de a telemetriai adatok küldésére is csak a legjobb erőfeszítést teszi. A telemetriai adatok több esetben is elveszhetnek, beleértve az alábbi gyakori forgatókönyveket:

• A memóriában lévő elemek elvesznek, amikor az alkalmazás összeomlik.
• A telemetriai adatok a hálózati problémák hosszabb időszakában elvesznek. A rendszer a helyi lemezen tárolja a telemetriát a hálózatkimaradások vagy az Application Insights háttérrendszerével kapcsolatos problémák esetén. A rendszer azonban elveti a 48 óránál régebbi elemeket.
• A telemetriai adatok Windows rendszerben való tárolásának alapértelmezett lemezhelyei a következő: %LOCALAPPDATA% vagy %TEMP%. Ezek a helyek általában a géphez tartoznak. Ha az alkalmazás fizikailag egyik helyről a másikra migrál, az eredeti helyen tárolt telemetriai adatok elvesznek.
• A Windows Azure Web Appsben az alapértelmezett lemeztárolási hely a D:\local\LocalAppData. Ez a hely nem marad meg. Az alkalmazás újraindítása, a vertikális felskálázás és más ilyen műveletek során törlődik, ami az ott tárolt telemetriai adatok elvesztéséhez vezet. Felülbírálhatja az alapértelmezett értéket, és megadhatja a tárterületet egy olyan tartós helyre, mint a D:\home. Az ilyen fenntartott helyeket azonban távoli tárolók szolgálják ki, így lassúak is lehetnek.

Bár kevésbé valószínű, lehetséges, hogy a csatorna ismétlődő telemetriai elemeket okoz. Ez a viselkedés akkor fordul elő, ha ServerTelemetryChannel hálózati hiba vagy időtúllépés miatt újrapróbálkozik, amikor a telemetria a háttérrendszernek lett kézbesítve, de a válasz hálózati problémák vagy időtúllépés miatt elveszett.

Bár a csomag és a névtér neve tartalmazza a "WindowsServer" nevet, ez a csatorna a Windowstól eltérő rendszereken is támogatott, az alábbi kivétellel. A Windowstól eltérő rendszereken a csatorna alapértelmezés szerint nem hoz létre helyi tárolómappát. Létre kell hoznia egy helyi tárolómappát, és konfigurálnia kell a csatornát a használatára. A helyi tároló konfigurálása után a csatorna ugyanúgy működik az összes rendszeren.

Megjegyzés:

A 2.15.0-béta3-es és újabb kiadással a helyi tároló automatikusan létrejön Linux, Mac és Windows rendszeren. Nem Windows rendszerű rendszerek esetén az SDK automatikusan létrehoz egy helyi tárolómappát a következő logika alapján:

• ${TMPDIR}: Ha a ${TMPDIR} környezeti változó be van állítva, a rendszer ezt a helyet használja.
• /var/tmp: Ha az előző hely nem létezik, megpróbáljuk./var/tmp
• /tmp: Ha mindkét előző hely nem létezik, megpróbáljuk tmp.
• Ha egyik hely sem létezik, a rendszer nem hoz létre helyi tárolót, és továbbra is szükség van manuális konfigurálásra. A megvalósítás részleteiért tekintse meg ezt a GitHub-adattárat.

Az SDK hálózati problémák vagy szabályozás során helyi tárolóban tárolja a telemetriai elemeket. Ezek az adatok nincsenek helyileg titkosítva.

Windows-rendszerek esetén az SDK automatikusan létrehoz egy ideiglenes helyi mappát a %TEMP% vagy a %LOCALAPPDATA% könyvtárban, és csak a rendszergazdák és az aktuális felhasználó hozzáférését korlátozza.

A Windowstól eltérő rendszerek esetében az SDK nem hoz létre automatikusan helyi tárolót, így alapértelmezés szerint nem tárol adatokat helyileg.

Megjegyzés:

A 2.15.0-béta3-es és újabb kiadással a helyi tároló automatikusan létrejön Linux, Mac és Windows rendszeren.

Saját maga hozhat létre tárkönyvtárat, és konfigurálhatja a csatornát annak használatára. Ebben az esetben Ön a felelős a címtár biztonságának biztosításáért. További információ az adatvédelemről és a magánéletről.

További információ: Telemetriai csatornák az Application Insightsban.

Tekintse meg a Korlátok összegzését.

Nem naplózzuk automatikusan a POST-adatokat, de használhatja a TrackTrace-et vagy a naplóhívásokat. Helyezze a POST-adatokat az üzenetparaméterbe. Az üzenetre nem lehet ugyanúgy szűrni, mint a tulajdonságokra, de a méretkorlát hosszabb.

Az Azure Functions nem naplózza az URL-lekérdezési sztringeket.

További információ: Tranzakciókeresés és diagnosztika.

Lehetséges okok:

• Az összetevők instrumentálva vannak az Application Insights-szal?
• A legújabb stabil Application Insights SDK-t használják?
• Ha ezek az összetevők különálló Application Insights-erőforrások, ellenőrizze, hogy rendelkezik-e hozzáféréssel. Ha hozzáféréssel rendelkezik, és az összetevők a legújabb Application Insights SDK-kkal vannak integrálva, a jobb felső sarokban található visszajelzési csatornán keresztül tájékoztasson minket.

Jelenleg a kimenő függőségi hívást a bejövő kéréstől elkülönítve jelenítjük meg. A két hívás általában azonos, azzal az eltéréssel, hogy csak az időtartam értéke különbözik a hálózati késleltetés miatt. A kezdő ikon és az időtartamsávok eltérő stílusa segít megkülönböztetni őket. Az adatok bemutatása zavaros? Visszajelzést ad nekünk!

Az ütemtervek a tranzakciódiagramon szereplő óraeltérésekhez igazodnak. A pontos időbélyegeket a részletek panelen vagy a Log Analytics használatával tekintheti meg.

Ez a viselkedés terv szerint történik. Az összes kapcsolódó elem az összes összetevőben már elérhető a bal oldalon a felső és az alsó szakaszokban. Az új felület két kapcsolódó elemet tartalmaz, amelyeket a bal oldal nem fed le: az esemény előtti és utáni öt perc összes telemetriáját, valamint a felhasználói ütemtervet.

A tranzakciódiagnosztikai élmény egyetlen művelet összes telemetriáját megjeleníti, amely egy műveletazonosítóval rendelkezik. Alapértelmezés szerint a JavaScripthez készült Application Insights SDK új műveletet hoz létre minden egyes egyedi oldalnézethez. Egyoldalas alkalmazásban (SPA) a rendszer csak egy oldalnézeti eseményt hoz létre, és egyetlen műveletazonosítót használ az összes létrehozott telemetriához. Ennek eredményeképpen számos esemény összefügghet ugyanahhoz a művelethez.

Ezekben a forgatókönyvekben az Automatikus útvonalkövetés funkcióval automatikusan létrehozhat új műveleteket a navigáláshoz az SPA-ban. Be kell kapcsolnia aAutoRouteTracking engedélyezését , hogy a rendszer minden alkalommal létrehozhasson lapnézetet, amikor az URL-útvonal frissül (logikai oldalnézet). Ha manuálisan szeretné frissíteni a műveletazonosítót, hívja fel a következőt appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(): A PageView-események manuális aktiválása a műveletazonosítót is alaphelyzetbe állítja.

A Gantt-diagramban nem ismertetett idő az az idő, amelyet nem fed le nyomon követett függőség. Ez a probléma azért fordulhat elő, mert a külső hívások nem lettek rendszerezettek automatikusan vagy manuálisan. Az is előfordulhat, hogy a folyamat során eltelt idő nem külső hívás miatt történt.

Ha minden hívás monitorozásra került, a folyamatban lévő tevékenység az idő eltöltésének valószínű oka. A folyamat diagnosztizálásában hasznos eszköz a .NET Profiler.

Ez a hiba azt jelzi, hogy a böngésző nem tudott meghívni egy szükséges API-t, vagy az API hibaválaszt adott vissza. A viselkedés hibaelhárításához nyisson meg egy böngésző InPrivate-ablakot , és tiltsa le a futó böngészőbővítményeket, majd állapítsa meg, hogy továbbra is képes-e reprodukálni a portál viselkedését. Ha a portál hibája továbbra is fennáll, próbálkozzon más böngészőkkel vagy más gépekkel való teszteléssel, vizsgálja meg a DNS-sel vagy más hálózattal kapcsolatos problémákat azon az ügyfélszámítógépen, ahol az API-hívások sikertelenek. Ha a portálhiba továbbra is fennáll, és további vizsgálatot igényel, gyűjtsön be egy böngészőhálózati nyomkövetést a váratlan portál viselkedésének reprodukálása közben, majd nyisson meg egy támogatási esetet az Azure Portalról.

További információ: Tranzakciókeresés és diagnosztika.

A vizualizáció kezdeti eseménye csak akkor látható, amikor a felhasználó először küldte el ezt az oldalnézetet vagy egyéni eseményt egy munkamenet során. Ha a felhasználók többször is elküldhetik a kezdeti eseményt egy munkamenetben, akkor az 1. lépés oszlop csak a kezdeti esemény első példánya után mutatja be a felhasználók viselkedését, nem pedig az összes példányt.

A Szerkesztés menü Felosztás opcióinak használata:

1. Válassza ki azt az eseményt, amelyet fel szeretne bontani az Esemény menüben.

2. Válasszon ki egy dimenziót a Dimenzió menüben. Ha például van egy Button Clicked nevű esemény, próbáljon meg egy Gombnév nevű egyéni tulajdonságot használni.

A kohorszok és a szűrők eltérőek. Tegyük fel, hogy az Egyesült Királyságból származó felhasználók kohorszával rendelkezik (az előző példához hasonlóan definiálva), és összehasonlítja annak eredményeit a szűrő Country or region = United Kingdombeállításával:

• A kohorszverzió azokat az eseményeket mutatja, amelyeket olyan felhasználók küldtek, akik egy vagy több eseményt indítottak az Egyesült Királyságból a jelenlegi időtartományban. Ha ország vagy régió szerint oszlik meg, valószínűleg sok ország és régió jelenik meg.

• A szűrők verziója csak az Egyesült Királyságból származó eseményeket jeleníti meg. Ha ország vagy régió szerint oszlik meg, akkor csak az Egyesült Királyság jelenik meg.

A szemcse módosításához válassza a Dátumfelbontás szűrőt. A szűrő az összes dimenziólapon elérhető.

Ha a vizualizációk nem válaszolnak az összes kérdésére, a HEART-munkafüzetet tápláló adatokat is feltárhatja. A feladat elvégzéséhez az Application Insights Figyelés szakaszában válassza a Naplók lehetőséget, és kérdezze le a táblát customEvents . A Click Analytics-attribútumok némelyike a customDimensions mezőben található.

Itt látható egy példa lekérdezés:

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Ha többet szeretne megtudni az Azure Monitor naplóiról, tekintse meg az Azure Monitor naplóinak áttekintését.

Igen. A munkafüzetsablonok szerkesztéséről az Azure-munkafüzetsablonok című témakörben olvashat.

További információ: Használati elemzés az Application Insights használatával.

.NET Core-alkalmazásforgatókönyv	Csomag
HostedServices nélkül	WorkerService
HostedServices szolgáltatásokkal	AspNetCore (nem a WorkerService)
A HostedServices szolgáltatásokkal kizárólag a HostedServices figyelése történik.	WorkerService (ritka forgatókönyv)

Igen, a konfiguráció meg van osztva a webalkalmazás többi részével.

Hozzon létre egy TelemetryClient példányt konstruktorinjektálással, és hívja meg a szükséges TrackXXX() metódust rajta. Nem javasoljuk új TelemetryClient példányok létrehozását. A TelemetryClient singleton példánya már regisztrálva van a DependencyInjection tárolóban, amely a többi telemetriával osztozik TelemetryConfiguration. Új TelemetryClient példány létrehozása csak akkor javasolt, ha olyan konfigurációra van szüksége, amely eltér a többi telemetriától.

A Visual Studio IDE előkészítés jelenleg csak ASP.NET/ASP.NET Core-alkalmazások esetében támogatott. Ez a dokumentum akkor frissül, ha a Visual Studio támogatja a Worker Service-alkalmazások előkészítését.

Nem. Az Azure Monitor Application Insights Agent jelenleg csak a .NET-et támogatja.

Igen. Az SDK szolgáltatástámogatása minden platformon azonos, az alábbi kivételekkel:

• A teljesítményszámlálók csak a Windowsban támogatottak, kivéve az élő metrikákban megjelenített processzor-/memóriafolyamatokat.

• Annak ellenére ServerTelemetryChannel , hogy alapértelmezés szerint engedélyezve van, ha az alkalmazás Linuxon vagy macOS rendszeren fut, a csatorna nem hoz létre automatikusan helyi tárolómappát a telemetriai adatok ideiglenes megőrzéséhez hálózati problémák esetén. A korlátozás miatt a telemetriai adatok elvesznek, ha ideiglenes hálózati vagy kiszolgálói problémák merülnek fel. A probléma megoldásához konfiguráljon egy helyi mappát a csatornához:

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

További információ: Application Insights for Worker Service-alkalmazások (nem HTTP-alkalmazások).