Megosztás a következőn keresztül:


Application Insights – Gyakori kérdések

Azure Monitor Application Insights hivatalos gyakori kérdések. Választ találhat az Application Insights Azure Monitorral való használatával kapcsolatos kérdésekre.

Áttekintés

Hogyan állíthatok be monitorozást egy alkalmazáshoz?

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álhatom az Application Insights szolgáltatást?

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ások

Ü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 storage az Application Insightsban.

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

Hová kerülnek a hagyományos naplózási keretrendszerekkel gyűjtött telemetriai adatok?

A naplózási keretrendszerek, például a Serilog használata esetén az Application Insights nyomkövetési telemetriaként betölti a naplóüzeneteket, és a táblában (vagy traces a AppTraces Log Analyticsben) tárolja. Ez terv szerint történik, mivel az olyan táblák, mint requestsa , dependenciesés exceptions a megfelelő telemetriai típusukhoz vannak fenntartva.

További részletekért tekintse meg az Application Insights telemetriai adatmodellt.

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 írhat az Azure Erőforrás-figyelő használatával a következőkre:

  • Application Insights-erőforrások létrehozása és frissítése.
  • Állítsa be a tarifacsomagot.
  • Szerezze be a kapcsolati karakterláncot.
  • 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 a Azure Monitor OpenTelemetry Distro.

A ingestion séma és endpoint protokoll nyilvánosan elérhetők.

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ő. Lásd a Application Insights szolgáltatásiszint-szerződést.

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 van egy Application Insights gyűjteményi végpont, az díjmentes.
  • Ha nincs gyűjtési végpont a gazdagép adatközpontjában, az alkalmazás telemetriája Azure kimenő 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 (azaz 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. A részletekért tekintse meg 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. Ahhoz, hogy elkezdje, tekintse meg az Application Insights magas adatbeviteli hibáinak elhárítása című 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 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 lásd: TLS-problémák megoldása és Azure Resource Manager TLS-támogatás.

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

Adatgyűjtés, adatmegőrzés, storage és adatvédelem

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

Context

Az Application Insights telemetriát gyűjt az alkalmazásból, és egy Log Analytics-munkaterületen tárolja. A bárhol üzemeltetett alkalmazásokhoz működik, nem csak a Azure.

Mit gyűjtünk és honnan?

A telemetriai adatok a következőkből származnak: (1) az alkalmazáshoz hozzáadott SDK, beleértve az ön által küldött egyéni telemetriát, (2) az opcionális kiszolgálóügynököket és (3) a Microsoft által futtatott rendelkezésre állási teszteket. A tipikus adatok közé tartoznak a kérések, függőségek, kivételek és összeomlások, teljesítményszámlálók, ügyfél- és kiszolgálókörnyezet, nyomkövetések, valamint az ön által küldött egyéni események vagy metrikák. Az elküldött üzenetek ellenőrzéséhez futtassa az alkalmazást hibakeresési módban, és ellenőrizze az IDE Output vagy Diagnostics ablakait. Weblapok esetén nyissa meg a böngészőt a fejlesztői eszközökkel, és tekintse meg a Hálózat lapot. Telemetriafeldolgozó implementálásával szűrheti vagy bővítheti a telemetriát, mielőtt elküldené.

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

A nyers adatmegőrzés 30, 60, 90, 120, 180, 270, 365, 550 vagy 730 napra állítható be. A 90 napnál hosszabb megőrzés további díjakat vonhat maga után. Az összesített metrikák 90 napig 1 perces részletességgel maradnak meg. A hibakeresési pillanatképek 15 napig maradnak meg. Az adatok az erőforrás létrehozásakor kiválasztott régióban lesznek tárolva. A telemetriai adatok a betöltés után nem módosíthatók. A telemetriai adatok nem szerkeszthetők. Szükség esetén elérhető a tisztítás az adatok törlésére.

Access, biztonság és titkosítás

Az adatok az Ön és csapattársai számára láthatók azok számára, akik hozzáféréssel rendelkeznek, és exportálhatók. A Microsoft az Ön adatait csak arra használja, hogy korlátozott személyzettel access biztosítsa a szolgáltatást, és összesített statisztikákat használhat a szolgáltatás fejlesztéséhez. A telemetriát HTTPS-en keresztül küldi a rendszer, az adatok pedig inaktív állapotban vannak titkosítva, és az adatközpontok közötti mozgás során.

Adatvédelem és felelősségteljes használat

Az alapértelmezett SDK-modulok a teljesítményre, a használatra és a diagnosztikára összpontosítanak, és általában nem tartalmaznak bizalmas személyes adatokat. Ne helyezzen bizalmas adatokat URL-címekbe. Tekintse át az egyéni telemetriát, hogy ne tartalmazzon személyes adatokat. A rendszer az ügyfél IP-címét használja a földrajzi helymeghatározáshoz, majd a tárolt IP-mező alapértelmezés szerint nulla. Ha maszkolás szükséges, adjon hozzá egy telemetriai inicializálót. Ha az alkalmazásnak lehetőséget kell biztosítania a leiratkozásra, tiltsa le az adatok gyűjtését a kódban. Tekintse át az ártalmatlannak tűnő mezőket is, például az eszköz nevét a személyes eszközökön. A gyűjtemények konfigurációban vagy kódon keresztül szabályozhatók vagy tilthatók le. További információ: Földrajzi hely és IP-cím kezelése.

TLS

Használjon modern TLS-t az átvitt adatokhoz. Ne kódolja a régebbi protokollverziókat. Lehetővé teszi a platform számára az újabb verziók egyeztetését, amint azok elérhetővé válnak. További információért tekintse meg az Azure Monitor üzembe helyezésének biztonságossá tétele című részt.

Helyi pufferelés és kimaradások

Ha az Azure-hoz való kapcsolat megszakad vagy korlátozott, az SDK-k helyileg pufferelik a telemetriát, és újra próbálkoznak. A rendszer elveti az elavult elemeket, például a naplók esetében körülbelül 48 óra, a metrikák esetében pedig 30 perc elteltével. A helyi ideiglenes storage nincs titkosítva, így biztonságossá teheti a konfigurált storage könyvtárat. A böngészőkben a sessionStorage a küldések pufferelésére szolgál.

Nyelvspecifikus helyi tároló: rövid útmutató

  • .NET (ServerTelemetryChannel): Alapértelmezés szerint %LOCALAPPDATA%\Microsoft\ApplicationInsights vagy %TMP%. Konfigurálva vagy kódban is beállíthat egy megőrzött mappát.

    Konfiguráció (ApplicationInsights.config):

    <TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel, Microsoft.AI.ServerTelemetryChannel">
        <StorageFolder>D:\NewTestFolder</StorageFolder>
    </TelemetryChannel>
    

    C# kód:

    var channel = new Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel();
    channel.StorageFolder = @"D:\NewTestFolder";
    channel.Initialize(Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active);
    Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.TelemetryChannel = channel;
    
  • .NET (ASP.NET Core): A fenti alapértelmezett értékek. Linux és macOS rendszeren az SDK automatikusan létrehozhat egy storage mappát. Beállítási sorrend: ${TMPDIR}, majd /var/tmp./tmp A mappát a következőben is beállíthatja Startup.cs: .

    ASP.NET Core indítás:

    using Microsoft.ApplicationInsights.Channel;
    using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
    // inside ConfigureServices
    services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel { StorageFolder = "/tmp/myfolder" });
    
  • Java: Az operációs rendszer ideiglenes mappáját használja, például C:\Users\username\AppData\Local\Temp Windows rendszeren. Ez az elérési út nem konfigurálható a standard konfigurációs fájlon keresztül.

  • Node.js: Alapértelmezés szerint %TEMP%/appInsights-node{CONNECTION STRING}. Futásidőben módosíthatja az ideiglenes könyvtárhoz használt fájlelőtagot.

    Csomópontminta:

    const appInsights = require('applicationinsights');
    appInsights.Sender.TEMPDIR_PREFIX = 'my-app-ai';
    appInsights.setup(process.env.APPLICATIONINSIGHTS_CONNECTION_STRING).start();
    
  • JavaScript (böngésző): A sessionStorage kulcsokat AI_buffer és AI_sent_buffer használja. A sessionStorage pufferelés letiltása:

    import { ApplicationInsights } from '@microsoft/applicationinsights-web';
    const appInsights = new ApplicationInsights({
      config: {
        connectionString: '<YOUR-CONNECTION-STRING>',
        enableSessionStorageBuffer: false
      }
    });
    appInsights.loadAppInsights();
    
  • Python (OpenCensus): Alapértelmezés szerint %USERNAME%/.opencensus/.azure/. Egyéni elérési utat is beállíthat:

    from opencensus.ext.azure.log_exporter import AzureLogHandler
    handler = AzureLogHandler(connection_string='<YOUR-CONNECTION-STRING>',
                              storage_path='/var/tmp/ai-cache')
    

Milyen használati adatokat gyűjt a Microsoft?

Az Application Insights sok esetben automatikusan gyűjt adatokat a Microsoft termékhasználatáról. Ezek az adatok egy Microsoft-adattárban vannak tárolva, és nem befolyásolják az ügyfelek figyelési mennyiségét és költségeit. Az Application Insights alapvető és nem alapvető metrikákat gyűjt a következőkkel kapcsolatban:

Az adatgyűjtés három fő célja:

  • Szolgáltatás állapota és megbízhatósága – A szolgáltatás megfelelő működésének érdekében külső nézőpontból ellenőrzi a betöltési végponttal való kapcsolatot.
  • Diagnosztika támogatása – Önsegítő elemzések nyújtása és az ügyfélszolgálat támogatása a problémák diagnosztizálásához és megoldásához.
  • Termékfejlesztés – Elemzések gyűjtése a Microsoft számára a terméktervezés optimalizálásához és az általános felhasználói élmény javításához.

Megjegyzés:

A használati adatok gyűjtése nem támogatja a Azure Private Link.

Támogatott nyelvek

Mértékek .NET Java JavaScript Node.js Python
Alapvető metrikák
Hálózat
Mellékel ✔️*
Tulajdonság
Nem alapvető metrikák
Lemez I/O-hibája

* Nem támogatott a klasszikus API vagy az autoinstrumentáció (csak OTel)

Támogatott uniós régiók

A használati adatgyűjtés a következő régiókban támogatja az Application Insights-erőforrások uniós adathatárát:

Földrajzi név A régió neve
Európa Észak-Európa
Európa Nyugat-Európa
Franciaország Közép-Franciaország
Franciaország Dél-Franciaország
Németország Középnyugat-Németország
Norvégia Kelet-Norvégia
Norvégia Nyugat-Norvégia
Svédország Közép-Svédország
Svájc Észak-Svájc
Svájc Nyugat-Svájc
Egyesült Királyság Egyesült Királyság – Dél
Egyesült Királyság Egyesült Királyság – Nyugat

Összegyűjtött használati adatok

Hálózati metrikák

A metrika elnevezése Unit Támogatott dimenziók
Sikeres kérelmek száma Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime VersionOperating System, Language, Version, , EndpointHost
Kérések hibaszáma Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating SystemLanguage, Version, Endpoint, , HostStatus Code
Kérelem időtartama Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime VersionOperating System, Language, Version, , EndpointHost
Újrapróbálkozás száma Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating SystemLanguage, Version, Endpoint, , HostStatus Code
Fojtás száma Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating SystemLanguage, Version, Endpoint, , HostStatus Code
Kivételszám Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime Version, Operating SystemLanguage, Version, Endpoint, , HostException Type

Metrikák csatolása

A metrika elnevezése Unit Támogatott dimenziók
Mellékel Számlál Resource Provider, Resource Provider Identifier, Attach Type, Instrumentation KeyRuntime Version, Operating System, LanguageVersion

Funkciómetrikák

A metrika elnevezése Unit Támogatott dimenziók
Tulajdonság Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime VersionFeature, Type, Operating System, , LanguageVersion

Nem alapvető metrikák

Kövesse nyomon a lemez I/O-hibáját, ha a megbízható telemetriához lemezmegőrzést használ.

A metrika elnevezése Unit Támogatott dimenziók
Olvasási hibák száma Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime VersionOperating System, LanguageVersion
Írási hibák száma Számlál Resource Provider, Attach Type, Instrumentation Key, Runtime VersionOperating System, LanguageVersion

Tűzfalkonfiguráció

A metrikákat a rendszer a következő helyekre küldi, amelyekre a kimenő kapcsolatokat tűzfalakban kell megnyitni:

Elhelyezkedés URL
Európa westeurope-5.in.applicationinsights.azure.com
Európán kívül westus-0.in.applicationinsights.azure.com

Használati adatok gyűjtésének letiltása

.NET

A használati adatgyűjtés alapértelmezés szerint engedélyezve van. A környezeti változó APPLICATIONINSIGHTS_STATSBEAT_DISABLEDtruebeállításával letiltható.

Java

Megjegyzés:

Java-ban csak a nem alapvető metrikák tilthatók le.

A nem alapvető metrikák letiltásához adja hozzá a következő konfigurációt a konfigurációs fájlhoz:

{
  "preview": {
    "statsbeat": {
        "disabled": "true"
    }
  }
}

Ezt a funkciót úgy is letilthatja, hogy a környezeti változót APPLICATIONINSIGHTS_STATSBEAT_DISABLED a következőre trueállítja. Ez a beállítás elsőbbséget élvez a JSON-konfigurációban megadott beállítással szemben disabled.

Node.js

A használati adatgyűjtés alapértelmezés szerint engedélyezve van. A környezeti változó APPLICATION_INSIGHTS_NO_STATSBEATtruebeállításával letiltható.

Python

A használati adatgyűjtés alapértelmezés szerint engedélyezve van. A környezeti változó APPLICATIONINSIGHTS_STATSBEAT_DISABLED_ALLtruebeállításával letiltható.

Archivált információk

Archivált információkért tekintse meg az Adatgyűjtés, megőrzés és tárolás az Application Insightsban.

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ételeket dobhat a Track_() hívás?

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 adat-hozzáfé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 lap Application Insights fülén, vagy állítsa ApplicationInsightsAgent_EXTENSION_VERSIONdisabled értékre.

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?

Csak metrikák alapján lehetnek Azure riasztások. 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?

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 internetes hozzáféréssel, -Proxy paraméterekkel bekapcsolódhat a PowerShell Gallerybe.
  • 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. A Application Insights Agent 2.0.0 és újabb verziókban az IIS-ben üzemeltetett ASP.NET Core alkalmazások támogatottak.

Hogyan ellenőrizzem, 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 érhetem el a proxy átengedését?

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?

TLS-támogatás

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

Az Application Insights és 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 verziója, valamint 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 verziók
  • 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ásaimat ne érintse semmi?

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 beszüntetik az adatok betöltését, és nem tudják elérni a szükséges alkalmazásösszetevőket. 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űveletekkel kapcsolatos további információkért lásd: 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 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 NuGet Package Manager használatával távolíthatja el a Visual Studio.

  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 Package Manager 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 annak függőségeit a NuGet Package Manager használatával az Eltávolítási opciók alatt, a NuGet Package Manager Beállítások vezérlőelem használatával.
  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 project 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 Insights-t 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 a project hozzáadott API-hívásokkal együtt.

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 te 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 project Layout.cshtml fájllal rendelkezik, a következő kód lesz hozzáadva.

    <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
             }({
                 connectionString:'<YOUR-CONNECTION-STRING>'
             });
    
             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>konzolalkalmazásokhoz készült Application Insights.

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

További információért tekintse meg a következőt: Az Application Insights konfigurálása az ASP.NET weboldalához.

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.

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-es alkalmazásokkal.

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 válasz törzsének adatait a telemetriámban?

ASP.NET Core built-in támogatással rendelkezik a HTTP-kérések/válaszok adatainak (beleértve a törzset) ILogger keresztül történő naplózásához. 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 szabhatom testre 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": "<YOUR-CONNECTION-STRING>"
    }
}

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 a services.AddApplicationInsightsTelemetry() az egyetlen módja az Application Insights engedélyezésének.

Üzembe helyezem az ASP.NET Core alkalmazásomat a Web Apps szolgáltatásra. Továbbra is engedélyezni kell az Application Insights bővítményt a Web Apps?

Ha az SDK buildeléskor van telepítve, ahogyan az ebben a cikkben látható, nem kell engedélyeznie a Application Insights bővítményt a 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-keretrendszert.
    • Minden üzemeltetési lehetőség, beleértve a Web Apps, a virtuális gépeket, a Linuxot, a tárolókat, az AKS-t és a nem Azure üzemeltetést.
    • Az összes .NET Core-verzió, beleértve az előzetes verziókat is.
  • A telemetria helyben látható, amikor hibakeresést végez a Visual Studio-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 a Azure Monitor Application Insights Agent (korábbi nevén Állapotfigyelő v2)?

Igen. A Application Insights Agent 2.0.0-beta1 és újabb verziókban 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:

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 NuGet Package Manager használatával távolíthatja el a Visual Studio.

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 az ASP.NET SDK-t, olvassa el Hogyan távolíthatom el az ASP.NET SDK?.

  1. Távolítsa el a Microsoft.ApplicationInsights.AspNetCore csomagot a NuGet Package Manager 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 project 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 a project hozzáadott API-hívásokkal együtt.

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

  • [A te 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": "<YOUR-CONNECTION-STRING>"
    }
    
  • 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?

A kód telemetriai korrelációjának letiltásához tekintse meg <ExcludeComponentCorrelationHttpHeadersOnDomains>Application Insights konzolalkalmazásokhoz című témakört.

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 az ASP.NET teljesítményszámlálókról?

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 Insightst a Azure Web App Portalról, miért nem látom az eseményszámlálókat?

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

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

Azure virtuális gépek és virtuálisgép-skálakészletek

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 Azure virtuális gépek és virtuálisgép-méretezési készletek Application Insights használatáról?

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 lehet kiszámítani a függőségi telemetria feldolgozási késleltetését?

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

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

Hogyan határozzam meg a függőség-hívás kezdeményezésének 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:

  • Firewall door: Engedélyezze a webtesztelők hosszú és módosítható listájának kéréseinek a szerverre irányulását.
  • 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 webes teszteket 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 tudom érvényesíteni, 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, meg kell győződnie arról, hogy a távoli végpont által támogatott TLS-konfiguráció megfelelő-e egy olyan gépről, amelynek hozzáférése van a végpont eléréséhez.

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 kapcsolatos hibákat is látnia kell a TLS Átviteli Hibaelhárítási lépés során, ha az potenciálisan érinti a webes teszteredményt.

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. A CRUD-műveletek rendelkezésre állási tesztszolgáltatásának használatával kapcsolatos további információkért lásd: 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.

Figyelés az Azure App Service-ben .NET, Node.js, Python és Java alkalmazásokhoz

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

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

  • Fájlok hozzáadása 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 projekt esetén adja hozzá az Application Insightst egy meglévő projekthez manuálisan.

Mi a különbség az Application Insights standard metrikái és Azure App Service metrikák 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 serverresponsetime időtartama 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őt a Web Apps metrikák tartalmazzák, az Application Insights-metrikákban azonban nem.

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

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 instrumentációról?

Kapcsolati karakterláncok

Az új Azure régiókhoz szükség van kapcsolati sztringek használatára?

Az új Azure régiók igénylik a kapcsolati sztringek használatát az instrumentációs kulcsok helyett. Connection string 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 connection string, é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, de nem korlátozódnak a következőkre: helyi fejlesztés és .NET izolált függvények 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 tudom egy globális webalkalmazást úgy kialakítani, hogy megfeleljen a regionális adatmegfelelési követelményeknek?

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-egy Application Insights erőforrást szigorú megfelelőségi követelményekkel rendelkező régiókban, mint például az Európai Unió vagy az Egyesült Államok.
  • 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:

  • Adatok küldése az A régió felhasználóitól az A régió Application Insights erőforrásba az A régió csatlakozási karakterláncának használatával.
  • Adatok küldése a B régió felhasználóitól a B régió Application Insights erőforrásához a B régiós kapcsolati karakterlánc használatával.
  • Az összes többi felhasználói adat elküldése egy általános célú Application Insights-erőforrásba egy másik connection string 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:

Az adott App Insights-erőforrásokhoz való régióalapú útválasztást bemutató ábra.

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 helyezhetek át 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ó erőforrásának 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ést tesz lehetővé az adatmegőrzési időtartam lejártáig.

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álhatok szolgáltatókat ('Microsoft.Insights', 'components').apiVersions[0] a Azure Resource Manager üzemelő példányaimban?

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?

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 a 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?

Naplózás .NET

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 portálon:

  1. Lépjen be az Azure portálra, és érje el az Application Insights erőforrását.
  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 Studio (Helyi hibakereső):

  1. Indítsa el az alkalmazást hibakeresési módban a Visual Studio.
  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 a Azure Web Apps bővítményt használva engedélyezem az Application Insightst ASP.NET Core-alkalmazásaimhoz. Hogyan használhatom az új szolgáltatót?

Az Application Insights bővítmény Azure Web Apps 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 naplózásáról?

További információért lásd: Application Insights naplózása .NET-tel.

Java Profilozó

Mi az Azure Monitor Application Insights Java Profiling?

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. 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 Java Mission Control (JMC).

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?

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

Manuális eszközhasználatot kell alkalmaznom a mintavételi felülírá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ülírásokat az Azure App Service használatakor az automatikus instrumentálással?

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

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 készült vagy tesztelt, 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ó, például a Tomcat 11 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 Java-futtatókörnyezettel rendelkező Azure App Service-t használok (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 a Azure portal keresztül 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?

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?

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?

Króm Firefox IE Opera Szafari
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 lásd: Application Insights JavaScript SDK-minták.

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.

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

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

Igen, az Application Insights JavaScript SDK open source. A forráskód megtekintéséhez vagy a project való közreműködéshez tekintse meg a official GitHub adattárat.

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

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 Access-Control-Allow-Headers konfigurációtól függően gyakran szükséges a kiszolgálóoldali lista kiterjesztése a Request-Id, Request-Context és traceparent (W3C elosztott fejléc) manuális hozzáadásával.

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-es és 503-as hibák gyakori okairól lásd az "502 hibás átjáró" és "503 szolgáltatás nem érhető el" HTTP-hibák elhárításáról az Azure App Service című témakört.

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

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 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 a 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?

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 árazá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?

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?

Azure Monitor OpenTelemetria

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

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

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

Migrálás .NET Application Insights SDK-ról Azure Monitor OpenTelemetryre

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 TelemetryConfiguration egy kezelték. Az OpenTelemetria esetében a három telemetriai jel (Traces, Metrics és Logs) mindegyike saját konfigurációval rendelkezik. A telemetriát manuálisan is létrehozhatja a .NET futtatókörnyezeten keresztül külső kódtárak nélkül. További információkért tekintse meg a distributed tracing, metrics és logging .NET guides.

  • Az Application Insights az alkalmazás telemetriai adatainak automatikus gyűjtésére szolgál TelemetryModules . Ehelyett az OpenTelemetry Instrumentation könyvtárakat használ telemetriát gyűjt meghatározott összetevőkből (például AspNetCore a kérésekhez és HttpClient a függőségekhez).

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

  • Az Application Insights TelemetryProcessors elemet használt a telemetria szűrésére. Az OpenTelemetria-feldolgozóval szűrési szabályokat is alkalmazhat egy adott jelre.

A migrálással kapcsolatos útmutatásért tekintse meg Migrate .NET Application Insights SDK-ból Azure Monitor OpenTelemetry.

Hogyan képezik le az Application Insights telemetriai típusait az OpenTelemetryre?

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

Azure Tábla figyelése Application Insights adattípus OpenTelemetry adattípus .NET implementáció
egyedi események Event Telemetria 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
nyomok Nyomkövető Telemetria Naplók Microsoft.Extensions.Logging.ILogger
nyomok Nyomkövető Telemetria Események időtartama System.Diagnostics.ActivityEvent

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

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, Azure Monitor Exportőr vagy Azure Monitor Disztribúció csak rögzített sebességű mintavételezést kínál. Csak kérelmek és függőségek (OpenTelemetry Traces) mintavételezhetők.

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óért lásd az Azure Monitor dokumentáció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 a 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 létre kell hoznia egy TracerProvider, majd hozzá kell adnia a processzort a AddAzureMonitorTraceExporter elé.

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 .

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 az előírt szabályok csak a OpenTelemetryLoggerProvider-re vonatkoznak.

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

További információt a naplók OpenTelemetria .NET dokumentációjában talál.

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. Az Application Insights telemetriai inicializálóinak használatához hasonlóan módosíthatja a telemetriai tulajdonságokat.

Alapértelmezés szerint a Azure Monitor Exportőr 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ó ahhoz, hogy tulajdonságokat adunk hozzá vagy módosítunk az Application Insights inicializáló eszközével, ahogy az az Azure Monitor dokumentációjában le van írva.

Í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 létre kell hoznia egy TracerProvider, majd hozzá kell adnia a processzort a AddAzureMonitorTraceExporter elé.

using OpenTelemetry.Trace;

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

Hogyan lehet 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 .NET futtatókörnyezet részét képező ActivitySource és Activity osztályokat használja a nyomkövetéshez. 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, hogy a ActivitySource segítségével Activity példányokat hozzanak létre és kezeljenek. Ez a módszer zökkenőmentes módot kínál a nyomkövetés hozzáadására .NET alkalmazásokhoz 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. A Azure Monitor Exportőr esetében azonban nem lehet 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 egyéni műveleteket kövesse nyomon a StartOperation és StopOperation metódusok segítségével. Ezt az OpenTelemetry .NET ActivitySource és Activity használatával érheti el. A ActivityKind.Server és ActivityKind.Consumer műveletek esetében a Azure Monitor Exportőr RequestTelemetry hoz létre. ActivityKind.Client, ActivityKind.Producer, és ActivityKind.Internal létrehozza DependencyTelemetry. Az egyéni műveletek nyomon követésével kapcsolatos további információkért tekintse meg a Azure Monitor dokumentációját. A ActivitySource és Activity .NET használatával kapcsolatos további információkat a .NET elosztott nyomkövetési eszközök használati útmutatói tartalmaznak.

Í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. Így migrálhatja TraceTelemetry:

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 a ExceptionTelemetry használja a kivételek naplózására. 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 Insightsnál nincs fogalom az Instrumentsről. 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álogatják meg 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.), OpenTelemetry Counter 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 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-ről az OpenTelemetry-re történő migrálás során az összes Application Insights Metric API használatát az OpenTelemetry API-ra kell lecserélni. 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 Exporter használatát konzol- és munkavégző szolgáltatás alkalmazásokhoz, amely nem tartalmaz élő metrikákat.

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

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 Feedback Hub 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 különböző telemetriatípusokhoz eltérő ráták alkalmazásához fontolja meg az OpenTelemetry span processzorok vagy az (adatbevitel-kor átalakítások)[app-insights-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 a mintavételezést a Azure Monitor Custom Sampler használatával.
  • 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.

Hogyan működik az Application Insights egyéni mintavevője a betöltési mintavételezés mellett?

A betöltési mintavételezés csak azt csökkenti, ami eléri a szolgáltatást, így nem tudja felülírni vagy felülbírálni az Application Insights egyéni mintavevői döntéseit. Ha mindkettő engedélyezve van, a tényleges ráta többszörös. Egy 20 százalékos SDK-sebesség és az 50 százalékos betöltési arány például az adatok nagyjából 10 százalékát teszi ki. A Microsoft a Azure Monitor OpenTelemetry mintavevővel végzett mintavételezést javasolja a forrásnál, hogy a nyomkövetések érintetlenek és kiszámíthatóak maradjanak, és a betöltési mintavételezést csak tartalékként használja.

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

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.
  • Idővel úgy gondoljuk, hogy az OpenTelemetria lehetővé teszi, hogy Azure Monitor-ügyfelek megfigyelhessék a támogatott nyelveken túli nyelveken írt alkalmazásokat.
  • 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 klasszikus API SDK-k.
  • Az OpenTelemetria összhangban van a Microsoft stratégiájával, hogy nyílt forráskódú technológiákat használjon.

Mi az OpenTelemetria állapota?

Mi az Azure Monitor OpenTelemetry Distro?

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

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

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

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.

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

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

Javasoljuk, hogy az Azure Monitor OpenTelemetry Distrot használja új projektekhez.

Az OpenTelemetry a klasszikus Application Insights API SDK-kkal szemben nyújt előnyöket, többek között a következőket:

  • 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
  • Jobb szállítói semlegesség, bár az Azure Monitor OpenTelemetry Distro még mindig az Azure-hoz van optimalizálva.

Ha .NET-et vagy Node.js klasszikus API-SDK-t használ, olvassa el a Migrálás az Application Insights klasszikus API SDK-jaiból az Azure Monitor OpenTelemetria szolgáltatásba című témakört.

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

A ASP.NET Core, a Java, a Node.jsés a Python esetében az Azure Monitor OpenTelemetry Distro használatát javasoljuk. Ez csak egy kódsor az indításhoz.

Minden más .NET forgatókönyv esetében, beleértve a klasszikus ASP.NET, konzolalkalmazások, Windows Forms (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 a Python Azure Monitor OpenTelemetry Exporter használatát javasoljuk.

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

Az Azure Monitor OpenTelemetry Disztribúció a klasszikus Application Insights API SDK-k funkcióparitását érte el.

A code analysis-élményekkel kapcsolatos legfrissebb információkért lásd: .NET Profiler és Snapshot Debugger.

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

Igen, de nem javasoljuk, és 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?

A OpenTelemetry webes tesztkörnyezet egy elágazás, amely az OpenTelemetria böngészőben való működését teszi lehetővé. 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, azonban a Distros lehetővé teszi, hogy egyszerre exportáljon egy OTLP-végpontra és az Azure Monitorra.

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

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 Exporter, amellyel egyes ügyfelek adatokat küldenek Azure Monitor Application Insights szolgáltatásba. Ezt a Microsoft nem támogatja.

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.

Irányítópult áttekintése

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?

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.
  • Azure Web Apps Windows rendszeren az alapértelmezett lemezalapú tárhely helyszíne 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árhelyet egy tartós helyre, például a D:\home mappába. Az ilyen tartósan tárolt 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 storage mappát. Létre kell hoznia egy helyi storage mappát, és konfigurálnia kell a csatornát annak használatára. A helyi storage konfigurálása után a csatorna ugyanúgy működik minden rendszeren.

Megjegyzés:

A 2.15.0-béta3-es és újabb kiadással a helyi storage mostantól automatikusan létrejön Linux, Mac és Windows rendszeren. Nem Windows rendszerű rendszerek esetén az SDK automatikusan létrehoz egy helyi storage 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 helyi storage nem jön létre, és továbbra is manuális konfigurációra van szükség. A megvalósítás részleteiért lásd: this GitHub adattár.

Az SDK ideiglenes helyi storage hoz létre? Az adatok titkosítva vannak tároláskor?

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

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

A Windowstól eltérő rendszerek esetében az SDK nem hoz létre automatikusan helyi storage, í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 storage mostantól automatikusan létrejön Linux, Mac és Windows rendszeren.

Létrehozhat egy storage kö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élet védelméről.

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

Kereső

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ényül az Azure Function keresés?

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

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

További információ: Keresés és diagnosztika.

Tranzakciók diagnosztikája

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 rendelkezik hozzáféréssel és az összetevők fel vannak szerelve a legújabb Application Insights SDK-kkal, kérjük, jelezze a jobb felső sarokban lévő visszajelzési csatornán keresztül.

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 Azure portal való navigálás közben megjelenik az "Adatok beolvasása hiba" ü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űjtse össze a böngésző hálózati nyomkövetését miközben reprodukálja a váratlan portál viselkedését, 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?

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 tekintsem 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ő.

Képernyőkép, amely a munkafüzetben lévő szűrőt mutatja, amellyel a dátumérték változtatható napi, havi vagy heti szintre.

Hogyan férhetek hozzá az alkalmazásomból olyan információkhoz, 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. Ahhoz, hogy ezt a feladatot végrehajtsa, az Monitoring szakaszban az Application Insights-ban válassza a Naplók lehetőséget, és futtassa le a lekérdezést a customEvents táblán. 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

A Azure Monitor naplóiról további információt a Azure Naplók monitorozásának áttekintése című témakörben talál.

Szerkeszthetim a munkafüzet vizualizációit?

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

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

Feldolgozói szolgáltatás alkalmazásai

Melyik csomagot érdemes használni?

.NET Core-alkalmazás forgatókönyve 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)

Egy .NET Core-alkalmazásban található HostedServices-hez be lehet injektálni a TelemetryClientet az AspNetCore-csomag felhasználásával?

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 feldolgozói szolgáltatás projekthez való bevezetéséhez?

Visual Studio IDE-előkészítés jelenleg csak az ASP.NET/ASP.NET Core alkalmazások esetében támogatott. Ez a dokumentum akkor frissül, amikor a Visual Studio támogatást nyújt a Worker Service alkalmazások integrációjához.

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

Nem. Azure Monitor Application Insights Agent jelenleg csak .NET 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, hogy a ServerTelemetryChannel alapértelmezés szerint engedélyezve van, ha az alkalmazás Linux vagy macOS rendszeren fut, a csatorna nem hoz létre automatikusan helyi storage 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?