Vanliga frågor och svar om Application Insights – Vanliga frågor och svar

Vanliga frågor och svar om Azure Monitor Application Insights. Hitta svar på frågor om hur du använder Application Insights med Azure Monitor.

Översikt

Hur gör jag för att instrumentera ett program?

Detaljerad information om instrumentering av program för att aktivera Application Insights finns i grunderna för datainsamling.

Hur använder jag Application Insights?

När du har aktiverat Application Insights genom att instrumentera ett program rekommenderar vi att du först tittar på Live-metrik och Programkartan.

Vilken telemetri samlar Application Insights in?

Från serverbaserade webbappar:

• HTTP-begäranden.
• Beroenden. Anrop till SQL-databaser, HTTP-anrop till externa tjänster, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage och Azure Queue Storage.
• Undantag och stackspårningar.
• Prestandaräknare: Prestandaräknare är tillgängliga när du använder:
  • Azure Monitor Application Insights-agent
  • Azure-övervakning för virtuella datorer eller VM-skalningsuppsättningar
  • Application Insights-författarecollectd.
• Anpassade händelser och mått som du kodar .
• Loggar kan spåras om du konfigurerar rätt insamlare.

Från klientwebbsidor:

• Ohanterade undantag i din app, inklusive information om

  • Stackspårning
  • Undantagsinformation och meddelande som medföljer felet
  • Rad- och kolumnnummer för fel
  • URL där felet uppstod
  • Begäranden för nätverksberoende som görs av din app via XML Http Request (XHR) och Fetch (hämtning är inaktiverad som standard) innehåller information om:
    • Url för beroendekälla
    • Kommando & metod som används för att begära beroendet
    • Varaktighet för begäran
    • Resultatkod och status för lyckad begäran
    • ID (om något) för användare som gör begäran
    • Korrelationskontext (om någon) där begäran görs

• Användarinformation (till exempel Plats, nätverk, IP)

• Enhetsinformation (till exempel webbläsare, operativsystem, version, språk, modell)

• Sessionsinformation

  Anmärkning

  För vissa program, till exempel ensidesprogram (SPA) registreras inte alltid varaktigheten och i dessa fall är standardvärdet 0.

  Mer information finns i Datainsamling, kvarhållning och lagring i Application Insights.

Från andra källor, om du konfigurerar dem:

• Azure-diagnostik
• Importera till Log Analytics
• Log Analytics
• Logstash

Hur många Application Insights-resurser ska jag distribuera?

Information om hur många Application Insights-resurser som krävs för att täcka ditt program eller komponenter i olika miljöer finns i planeringsguiden för Application Insights-distribution.

Hur hanterar jag Application Insights-resurser med PowerShell?

Du kan skriva PowerShell-skript med hjälp av Azure Resource Monitor för att:

• Skapa och uppdatera Application Insights-resurser.
• Ange prisplanen.
• Hämta instrumentationsnyckeln.
• Lägg till en måttavisering.
• Lägg till ett tillgänglighetstest.

Du kan inte konfigurera en metrics explorer-rapport eller konfigurera kontinuerlig export.

Hur ställer jag frågor till Application Insights-telemetri?

Använd REST-API:et för att köra Log Analytics-frågor.

Kan jag skicka telemetri till Application Insights-portalen?

Vi rekommenderar Azure Monitor OpenTelemetry Distro.

Inmatningsschemat och slutpunktsprotokollet är tillgängliga offentligt.

Hur lång tid tar det innan telemetri samlas in?

De flesta Application Insights-data har en svarstid på under 5 minuter. Vissa data kan ta längre tid, vilket är typiskt för större loggfiler. Se Servicenivåavtalet för Application Insights.

Hur hanterar Application Insights datainsamling, kvarhållning, lagring och sekretess?

Samling

Application Insights samlar in telemetri om din app, inklusive webbservertelemetri, webbsidestelemetri och prestandaräknare. Dessa data kan användas för att övervaka appens prestanda, hälsa och användning. Du kan välja plats när du skapar en ny Application Insights-resurs.

Kvarhållning och lagring

Data skickas till en Application Insights Log Analytics-arbetsyta. Du kan välja kvarhållningsperioden för rådata från 30 till 730 dagar. Aggregerade data bevaras i 90 dagar och ögonblicksbilder för felsökning behålls i 15 dagar.

Privatliv

Application Insights hanterar inte känsliga data som standard. Vi rekommenderar att du inte placerar känsliga data i URL:er som oformaterad text och ser till att din anpassade kod inte samlar in personlig eller annan känslig information. Under utveckling och testning kontrollerar du skickade data i din IDE och webbläsarens felsökningsutdatafönster.

Arkiverad information finns i Datainsamling, kvarhållning och lagring i Application Insights.

Vad är prissättningsmodellen för Application Insights?

Application Insights faktureras via Log Analytics-arbetsytan där loggdata matas in. Standardprisnivån Betala per användning i Log Analytics innehåller 5 GB per månad med kostnadsfri dataersättning per faktureringskonto. Läs mer om prisalternativ för Azure Monitor-loggar.

Finns det avgifter för dataöverföring mellan en Azure-webbapp och Application Insights?

• Om din Azure-webbapp finns i ett datacenter där det finns en Application Insights-samlingsslutpunkt debiteras ingen kostnad.
• Om det inte finns någon samlingsslutpunkt i värdcentret medför appens telemetri utgående avgifter för Azure.

Det här svaret beror på fördelningen av våra slutpunkter, inte på var Application Insights-resursen finns.

Medför jag nätverkskostnader om min Application Insights-resurs övervakar en Azure-resurs (dvs. telemetriproducent) i en annan region?

Ja, du kan medföra fler nätverkskostnader, som varierar beroende på vilken region telemetrin kommer från och vart den är på väg. Mer information finns i Prissättning för Azure-bandbredd .

Om du ser oväntade avgifter eller höga kostnader i Application Insights kan den här guiden hjälpa dig. Den omfattar vanliga orsaker som hög telemetrivolym, datainmatningstoppar och felkonfigurerad sampling. Det är särskilt användbart om du felsöker problem som rör kostnadstoppar, telemetrivolym, sampling som inte fungerar, datatak, hög inmatning eller oväntad fakturering. Information om hur du kommer igång finns i Felsöka hög datainmatning i Application Insights.

Vilka TLS-versioner stöds?

Application Insights använder TLS (Transport Layer Security) 1.2 och 1.3.

Viktigt!

Den 1 mars 2025 drar Azure tillbaka äldre versioner av TLS i alla tjänster. Då stöder Application Insights inte längre TLS 1.0, TLS 1.1 och de angivna äldre TLS 1.2/1.3-chiffersviterna och elliptiska kurvorna.

Allmänna frågor om det äldre TLS-problemet finns i Lösa TLS-problem och Azure Resource Manager TLS-support.

Var kan jag få mer information om Application Insights?

Mer information finns i Introduktion till Application Insights.

Application Insights-API för anpassade händelser och mått

Varför saknar jag telemetridata?

Båda TelemetryChannels förlorar buffrad telemetri om den inte töms innan ett program stängs av.

För att undvika dataförlust rensar du TelemetryClient när ett program stängs av.

Mer information finns i Rensa data.

Vilka undantag kan Track_() anrop utlöser?

Ingen. Du behöver inte omsluta dem i try-catch-satser. Om SDK:et stöter på problem loggar det meddelanden i felsökningskonsolens utdata och, om meddelandena kommer igenom, i Diagnostiksökning.

Finns det ett REST-API för att hämta data från portalen?

Ja, API:et för dataåtkomst. Andra sätt att extrahera data är Power BI på arbetsytebaserade resurser.

Varför ignoreras mina anrop till anpassade händelser och mått-API:er?

Application Insights SDK är inte kompatibelt med autoinstrumentation. Om autoinstrumentering är aktiverad kommer anrop till Track() och andra anpassade händelser och metrik-API:er att ignoreras.

Inaktivera automatisk instrumentering i Azure Portal på fliken Application Insights på App Service-sidan eller ange ApplicationInsightsAgent_EXTENSION_VERSION till disabled.

Varför är antalet i sök- och måttdiagram olika?

Sampling minskar antalet telemetriobjekt (till exempel begäranden och anpassade händelser) som skickas från din app till portalen. I Sök ser du antalet mottagna objekt. I måttdiagram som visar antalet händelser ser du antalet ursprungliga händelser som har inträffat.

Varje objekt som överförs har en itemCount egenskap som visar hur många ursprungliga händelser som objektet representerar. Om du vill observera sampling i drift kan du köra den här frågan i Log Analytics:

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

Hur ställer jag in en avisering för en händelse?

Azure-aviseringar gäller endast mått. Skapa ett anpassat mått som överskrider ett värdetröskelvärde när händelsen inträffar. Ange sedan en avisering för måttet. Du får ett meddelande när måttet överskrider tröskelvärdet i båda riktningarna. Du får inget meddelande förrän den första korsningen, oavsett om det ursprungliga värdet är högt eller lågt. Det finns alltid en svarstid på några minuter.

Var kan jag få mer information om Application Insights API för anpassade händelser och mått?

Mer information finns i Application Insights API för anpassade händelser och mått.

Distribuera Application Insights Agent för lokala servrar

Stöder Application Insights Agent proxyinstallationer?

Ja. Det finns flera sätt att ladda ned Application Insights Agent:

• Om datorn har internetåtkomst kan du registrera dig för PowerShell-galleriet med hjälp -Proxy av parametrar.
• Du kan också ladda ned modulen manuellt och antingen installera den på datorn eller använda den direkt.

Vart och ett av dessa alternativ beskrivs i de detaljerade anvisningarna.

Stöder Application Insights Agent ASP.NET Core-program?

Ja. I Application Insights Agent 2.0.0 och senare stöds ASP.NET Core-program som finns i IIS.

Hur gör jag för att kontrollera att aktiveringen lyckades?

• Du kan använda cmdleten Get-ApplicationInsightsMonitoringStatus för att kontrollera att aktiveringen lyckades.

• Använd Live Metrics för att snabbt avgöra om din app skickar telemetri.

• Du kan också använda Log Analytics för att lista alla molnroller som för närvarande skickar telemetri:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

Hur gör jag för att uppnå proxy genomströmning?

För att uppnå proxygenomströmning konfigurerar du en proxy på datornivå eller en proxy på programnivå. Se DefaultProxy.

Exempel på Web.config:

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

Var kan jag få mer information om att distribuera Application Insights Agent för lokala servrar?

Mer information finns i Distribuera Application Insights Agent för lokala servrar.

TLS-stöd

Avgöra om TLS-pensionering påverkar dig

Application Insights och Azure Monitor styr inte den TLS-version som används för HTTPS-anslutningar. TLS-versionen är beroende av operativsystemet och körningsmiljön där programmet körs.

Så här bekräftar du den TLS-version som används:

• Läs dokumentationen för ditt operativsystem och din körmiljö eller ditt ramverk.
• Kontakta lämpligt supportteam om du behöver ytterligare hjälp. Öppna inte en supportbegäran med Application Insights.

Exempel på språk- och körningsstöd för TLS 1.2+

Följande versioner innehåller integrerat stöd för TLS 1.2 eller senare:

• .NET/.NET Core: .NET Framework 4.6.2 eller senare och alla versioner av .NET Core
• Java: Java 8 update 161 (8u161) eller senare
• Python: Python-distributioner som skapats med OpenSSL 1.0.1 eller senare
• Node.js: Node.js version 10 eller senare

Exempel på operativsystemstöd för TLS 1.2+

Följande operativsystem innehåller integrerat stöd för TLS 1.2 eller senare:

• Windows: Windows 8, Windows Server 2012 och senare
• Linux: De flesta moderna Linux-distributioner som använder OpenSSL 1.0.1 eller senare

Hur ser jag till att mina resurser inte påverkas?

För att undvika avbrott i tjänsten bör varje fjärrslutpunkt, inklusive beroende begäranden, som din resurs interagerar med stödja minst en kombination av samma protokollversion, chiffersvit och elliptisk kurva som nämndes tidigare. Om fjärrslutpunkten inte stöder den nödvändiga TLS-konfigurationen måste den uppdateras med stöd för någon kombination av TLS-konfigurationen efter utfasningen.

Vad är beteendet för berörda resurser efter den 1 maj 2025?

Berörda Application Insights-resurser slutar mata in data och kan inte komma åt nödvändiga programkomponenter. Därför slutar vissa funktioner att fungera.

Vilka komponenter påverkar utfasningen?

TLS-utfasningen (Transport Layer Security) som beskrivs i det här dokumentet bör endast påverka beteendet efter den 1 maj 2025. Mer information om CRUD-åtgärder finns i Azure Resource Manager TLS-support. Den här resursen ger mer information om TLS-stöd och avvecklingstidslinjer.

Var kan jag få stöd för Transport Layer Security (TLS) ?

För generella frågor om problemen med det äldre TLS, se Lösa TLS-problem.

Var kan jag få mer information om TLS-stöd i Application Insights?

Mer information finns i TLS-stöd.

ASP.NET

Hur avinstallerar jag SDK:t?

Om du vill ta bort Application Insights måste du ta bort NuGet-paketen och referenserna från API:et i ditt program. Du kan avinstallera NuGet-paket med hjälp av NuGet Package Manager i Visual Studio.

1. Om spårningssamlingen är aktiverad avinstallerar du först paketet Microsoft.ApplicationInsights.TraceListener med hjälp av NuGet Package Manager men tar inte bort några beroenden.
2. Avinstallera Microsoft.ApplicationInsights.Web-paketet och ta bort dess beroenden med hjälp av NuGet Package Manager och dess avinstallationsalternativ i kontrollen Alternativ för NuGet Package Manager.
3. Om du vill ta bort Application Insights helt kontrollerar och tar du bort den tillagda koden eller filerna manuellt tillsammans med eventuella API-anrop som du har lagt till i projektet. Mer information finns i Vad skapas automatiskt när du lägger till Application Insights SDK?.

Vad skapas automatiskt när du lägger till Application Insights SDK?

När du lägger till Application Insights i projektet skapas automatiskt filer och kod läggs till i några av dina filer. Att bara avinstallera NuGet-paketen tar inte alltid bort filerna och koden. Om du vill ta bort Application Insights helt bör du kontrollera och manuellt ta bort den tillagda koden eller filerna tillsammans med eventuella API-anrop som du har lagt till i projektet.

När du lägger till Application Insights-telemetri i ett Visual Studio-ASP.NET projekt lägger det till följande filer:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

Följande kodstycken läggs automatiskt till:

• [Projektets namn].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

  Om projektet har en Layout.cshtml-fil läggs följande kod till.

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

• ConnectedService.json

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

• FilterConfig.cs

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

Hur inaktiverar jag telemetrikorrelation?

Information om hur du inaktiverar telemetrikorrelation i konfigurationen <ExcludeComponentCorrelationHttpHeadersOnDomains> finns i Application Insights för konsolprogram.

Var kan jag få mer information om hur du använder Application Insights med ASP.NET?

Mer information finns i Konfigurera Application Insights för din ASP.NET webbplats.

ASP.NET Core-applikationer

Stöder Application Insights ASP.NET Core 3.1?

ASP.NET Core 3.1 stöds inte längre av Microsoft.

Application Insights SDK för ASP.NET Core version 2.8.0 och Visual Studio 2019 eller senare kan användas med ASP.NET Core 3.1-program.

Hur kan jag spåra telemetri som inte samlas in automatiskt?

Hämta en instans av med hjälp av TelemetryClient konstruktorinmatning och anropa den metod som krävs TrackXXX() för den. Vi rekommenderar inte att du skapar nya TelemetryClient eller TelemetryConfiguration instanser i ett ASP.NET Core-program. En singleton-instans av TelemetryClient är redan registrerad i containern DependencyInjection , som delar TelemetryConfiguration med resten av telemetrin. Skapa bara en ny TelemetryClient instans om den behöver en konfiguration som är separat från resten av telemetrin.

I följande exempel visas hur du spårar mer telemetri från en styrenhet.

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();
    }
}

Mer information om anpassad datarapportering i Application Insights finns i API-referens för anpassade mått för Application Insights. En liknande metod kan användas för att skicka anpassade mått till Application Insights med hjälp av GetMetric API.

Hur gör jag för att avbilda begärande- och svarstexten i min telemetri?

ASP.NET Core har inbyggt stöd för loggning av HTTP-begäran/svarsinformation (inklusive brödtext) via ILogger. Vi rekommenderar att du använder detta. Detta kan potentiellt exponera personligt identifierbar information (PII) i telemetri och kan leda till att kostnaderna (prestandakostnader och Application Insights-fakturering) ökar avsevärt, så utvärdera riskerna noggrant innan du använder detta.

Hur gör jag för att anpassa ILogger-loggsamlingen?

Standardinställningen för Application Insights är att endast samla in varningsloggar och allvarligare loggar.

Samla in information och mindre allvarliga loggar genom att ändra loggningskonfigurationen för Application Insights-providern på följande sätt.

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

Observera att följande exempel inte gör att Application Insights-providern samlar in Information loggar. Den samlar inte in den eftersom SDK lägger till ett standardfilter för loggning som instruerar ApplicationInsights att endast samla Warning loggar och mer allvarliga loggar. Application Insights kräver en explicit åsidosättning.

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

Mer information finns i ILogger-konfiguration.

Vissa Visual Studio-mallar använde tilläggsmetoden UseApplicationInsights() på IWebHostBuilder för att aktivera Application Insights. Är den här användningen fortfarande giltig?

Tilläggsmetoden UseApplicationInsights() stöds fortfarande, men den är markerad som föråldrad i Application Insights SDK version 2.8.0 och senare. Den tas bort i nästa huvudversion av SDK: et. Om du vill aktivera Application Insights-telemetri använder du AddApplicationInsightsTelemetry() eftersom det ger överlagringar för att styra viss konfiguration. I ASP.NET Core 3.X-appar services.AddApplicationInsightsTelemetry() är det också det enda sättet att aktivera Application Insights.

Jag distribuerar mitt ASP.NET Core-program till Web Apps. Ska jag fortfarande aktivera Application Insights-tillägget från Web Apps?

Om SDK:t installeras vid byggtiden enligt den här artikeln behöver du inte aktivera Application Insights-tillägget från App Service-portalen. Om tillägget är installerat säkerhetskopieras det när det identifierar att SDK redan har lagts till. Om du aktiverar Application Insights från tillägget behöver du inte installera och uppdatera SDK:t. Men om du aktiverar Application Insights genom att följa anvisningarna i den här artikeln har du större flexibilitet eftersom:

• Application Insights-telemetrin fortsätter att fungera i:
  • Alla operativsystem, inklusive Windows, Linux och Mac.
  • Alla publiceringslägen, inklusive fristående lägen eller ramverksberoende.
  • Alla målramverk, inklusive hela .NET Framework.
  • Alla värdalternativ, inklusive webbappar, virtuella datorer, Linux, containrar, AKS och icke-Azure-värdtjänster.
  • Alla .NET Core-versioner, inklusive förhandsversioner.
• Du kan se telemetri lokalt när du felsöker från Visual Studio.
• Du kan spåra mer anpassad telemetri med hjälp av API:et TrackXXX() .
• Du har fullständig kontroll över konfigurationen.

Kan jag aktivera Application Insights-övervakning med hjälp av verktyg som Azure Monitor Application Insights Agent (tidigare Status Monitor v2)?

Ja. I Application Insights Agent 2.0.0-beta1 och senare stöds ASP.NET Core-program som finns i IIS.

Stöds alla funktioner om jag kör mitt program i Linux?

Ja. Funktionsstöd för SDK är detsamma på alla plattformar, med följande undantag:

• SDK:et samlar in händelseräknare i Linux eftersom prestandaräknare endast stöds i Windows. De flesta mått är desamma.

Stöds det här SDK:t för Worker Services?

Nej. Använd i stället Application Insights för Worker Service-program (icke-HTTP-program) för arbetstjänster.

Hur avinstallerar jag SDK:t?

Om du vill ta bort Application Insights måste du ta bort NuGet-paketen och referenserna från API:et i ditt program. Du kan avinstallera NuGet-paket med hjälp av NuGet Package Manager i Visual Studio.

Anmärkning

De här anvisningarna är till för att avinstallera ASP.NET Core SDK. Om du behöver avinstallera ASP.NET SDK läser du Hur kan jag avinstallera ASP.NET SDK?.

1. Avinstallera Paketet Microsoft.ApplicationInsights.AspNetCore med hjälp av NuGet Package Manager.
2. Om du vill ta bort Application Insights helt kontrollerar och tar du bort den tillagda koden eller filerna manuellt tillsammans med eventuella API-anrop som du har lagt till i projektet. Mer information finns i Vad skapas när du lägger till Application Insights SDK?.

Vad skapas när du lägger till Application Insights SDK?

När du lägger till Application Insights i projektet skapas filer och kod läggs till i några av dina filer. Att bara avinstallera NuGet-paketen tar inte alltid bort filerna och koden. Om du vill ta bort Application Insights helt bör du kontrollera och manuellt ta bort den tillagda koden eller filerna tillsammans med eventuella API-anrop som du har lagt till i projektet.

När du lägger till Application Insights-telemetri i ett Visual Studio ASP.NET Core-mallprojekt lägger det till följande kod:

• [Projektets namn].csproj

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

• Appsettings.json

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

• ConnectedService.json

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

• Startup.cs

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

Hur inaktiverar jag telemetrikorrelation?

Information om hur du inaktiverar telemetrikorrelation i kod <ExcludeComponentCorrelationHttpHeadersOnDomains> finns i Application Insights för konsolprogram.

Var kan jag få mer information om hur du använder Application Insights för ASP.NET Core-program?

Mer information finns i Application Insights för ASP.NET Core.

ASP.NET prestandaräknare

Vad är skillnaden mellan undantagsfrekvens och undantagsmått?

• Exception rate: Undantagsfrekvensen är en systemprestandaräknare. CLR räknar alla hanterade och ohanterade undantag som kastas och delar sedan summan av undantagen i ett samplingsintervall med intervallets längd. Application Insights SDK samlar in det här resultatet och skickar det till portalen.
• Exceptions: Metriken 'Undantag' räknar de TrackException rapporter som tas emot av portalen under diagrammets samplingsintervall. Den innehåller endast hanterade undantag där du skriver TrackException anrop i koden. Den innehåller inte alla ohanterade undantag.

Var kan jag få mer information om ASP.NET prestandaräknare?

Mer information finns i Räknare för .NET i Application Insights.

ASP.NET händelseräknare

Kan jag se EventCounters i Live Metrics?

Live-mätvärden visar inte EventCounters. Använd Metric Explorer eller Analytics för att se telemetrin.

Varför kan jag inte se händelseräknare när jag har aktiverat Application Insights från Azure Web App Portal?

Application Insights-tillägget för ASP.NET Core har ännu inte stöd för den här funktionen.

Var kan jag få mer information om ASP.NET händelseräknare?

Mer information finns i Räknare för .NET i Application Insights.

Virtuella Azure-datorer och VM-skalningsuppsättningar

Hur inaktiverar jag övervakning på klientsidan för ASP.NET Core-appar?

Övervakning på klientsidan är aktiverat som standard för ASP.NET Core-appar. Om du vill inaktivera den definierar du en miljövariabel på servern med följande information:

• Namn:APPINSIGHTS_JAVASCRIPT_ENABLED
• Värde:false

Var kan jag få mer information om att använda Application Insights för virtuella Azure-datorer och vm-skalningsuppsättningar?

Mer information finns i Application Insights för virtuella Azure-datorer och VM-skalningsuppsättningar.

Beroendespårning

Hur rapporterar den automatiska beroendeinsamlare misslyckade anrop till beroenden?

Misslyckade beroendeanrop har success-fältet inställt på False. Modulen DependencyTrackingTelemetryModule rapporterar inte ExceptionTelemetry. Den fullständiga datamodellen för beroende beskrivs i Application Insights telemetridatamodell.

Hur gör jag för att beräkna svarstid för inmatning för min beroendetelemetri?

Använd den här koden:

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

Hur gör jag för att bestämma när beroendeanropet initierades?

I Log Analytics-frågevyn timestamp representerar det ögonblick då TrackDependency()-anropet initierades, som inträffar omedelbart efter att beroendeanropssvaret har tagits emot. Om du vill beräkna den tid då beroendeanropet började skulle du ta timestamp och subtrahera det registrerade duration beroendeanropet.

Inkluderar beroendespårning i Application Insights loggning av svarskroppar?

Beroendespårning i Application Insights inkluderar inte loggning av svarsdata eftersom det skulle generera för mycket telemetri för de flesta applikationer.

Var kan jag få mer information om beroendespårning i Application Insights?

Mer information finns i Beroendespårning.

Tillgänglighetstester

Kan jag köra tillgänglighetstester på en intranetserver?

Tillgänglighetstester körs på närvaropunkter som är distribuerade över hela världen. Det finns två lösningar:

• Firewall door: Tillåt förfrågningar till din server från den långa och föränderliga listan över webbläsartestagenter.
• Anpassad kod: Skriv din egen kod för att skicka periodiska förfrågningar till din server från insidan av ditt intranät. Du kan köra webbaserade tester med Visual Studio för detta ändamål. Testaren skulle kunna skicka resultaten till Application Insights genom att använda TrackAvailability() API:et.

Vad är användaragentsträngen för tillgänglighetstester?

Strängen för användaragenter är Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Var kan jag få mer information om Application Insights-tillgänglighetstester?

Mer information finns i Tillgänglighetstester.

TLS-stöd för tillgänglighetstester

Hur påverkar utfasningen mitt beteende för webbtest?

Tillgänglighetstester fungerar som en distribuerad klient i varje av de stödda webbtestplatserna. Varje gång ett webbtest körs försöker tillgänglighetstesttjänsten nå den fjärranslutningspunkt som definieras i webbtestkonfigurationen. En TLS Client Hello-meddelande skickas, vilket innehåller alla för närvarande stödda TLS-konfigurationer. Om den fjärranslutna slutpunkten delar en gemensam TLS-konfiguration med tillgänglighetstestklienten, lyckas TLS-handshake. Annars misslyckas webbtestet med ett fel vid TLS-handshake.

Hur validerar jag vilken TLS-konfiguration en fjärrslutpunkt stöder?

Det finns flera tillgängliga verktyg för att testa vilken TLS-konfiguration som en slutpunkt stöder. Ett sätt skulle vara att följa exemplet som beskrivs på den här sidan. Om din fjärranslutningspunkt inte är tillgänglig via det offentliga Internet, behöver du säkerställa att du validerar TLS-konfigurationen som stöds på fjärranslutningspunkten från en dator som har tillgång att ansluta till din anslutningspunkt.

Anmärkning

För att aktivera den nödvändiga TLS-konfigurationen på din webbserver, är det bäst att kontakta teamet som äger den hostingplattform din webbserver kör på, om processen är okänd.

Vad kommer webbtestbeteendet att vara för påverkade tester efter den 1 maj 2025?

Det finns ingen enda undantagstyp som alla TLS-handshakefel som påverkas av denna avveckling skulle presentera sig med. Dock är det vanligaste undantaget som ditt webbtest skulle börja misslyckas med The request was aborted: Couldn't create SSL/TLS secure channel. Du bör också kunna se eventuella TLS-relaterade fel i felsökningssteget för TLS-transport för det webbtestresultat som kan påverkas.

Kan jag se vilken TLS-konfiguration som används av mitt webbtest just nu?

TLS-konfigurationen som förhandlas fram under webbstestkörning kan inte visas. Så länge den fjärranslutna slutpunkten stöder en vanlig TLS-konfiguration med tillgänglighetstester, bör ingen påverkan märkas efter att den har fasats ut.

Vilka komponenter påverkar utfasningen i tillgänglighetstesttjänsten?

TLS-utfasningen som beskrivs i det här dokumentet bör endast påverka körningsbeteendet för webbtillgänglighetstester efter den 1 maj 2025. För mer information om hur man interagerar med tillgänglighetstesttjänsten för CRUD-operationer, se Azure Resource Manager TLS Support. Den här resursen ger mer information om TLS-stöd och avvecklingstidslinjer.

Var kan jag få TLS-stöd?

För generella frågor om problemen med det äldre TLS, se Lösa TLS-problem.

Var kan jag få mer information om TLS-stöd för tillgänglighetstester?

Mer information finns i TLS-konfigurationer som stöds.

Övervakning i Azure App Service för .NET-, Node.js-, Python- och Java-program

Vad ändrar Application Insights i mitt projekt?

Informationen beror på typen av projekt. Följande lista är ett exempel för ett webbprogram.

• Lägger till filer i projektet:

  • ApplicationInsights.config
  • ai.js

• Installerar NuGet-paket:

  • Application Insights API: Kärn-API:et
  • Application Insights API för webbprogram: Används för att skicka telemetri från servern
  • Application Insights API för JavaScript-program: Används för att skicka telemetri från klienten

• Inkluderar samlingar i paket:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Infogar objekt i:

  • Web.config
  • packages.config

• Infogar kodfragment i klient- och serverkoden för att initiera dem med Application Insights-resurs-ID:t. I en MVC-app infogas till exempel kod i huvudsidan Views/Shared/_Layout.cshtml. Endast för nya projekt lägger du till Application Insights i ett befintligt projekt manuellt.

Vad är skillnaden mellan standardmått från Application Insights jämfört med Azure App Service-mått?

Application Insights samlar in telemetri för de begäranden som nådde fram till applikationen. Om felet inträffar i WebApps/WebServer och begäran inte nådde användarprogrammet har Application Insights ingen telemetri om det.

Varaktigheten för serverresponsetime beräknad av Application Insights matchar inte nödvändigtvis serverns svarstid som observeras av Web Apps. Det här beteendet beror på att Application Insights bara räknar varaktigheten när begäran faktiskt når användarprogrammet. Om begäran har fastnat eller placerats i kö i WebServer inkluderas väntetiden i Web Apps-måtten men inte i Application Insights-mått.

Var kan jag få mer information om övervakning i Azure App Service för .NET-, Node.js-, Python- och Java-program?

Mer information finns i Aktivera programövervakning i Azure App Service.

Automatisk instrumentering

Ska termen "autoinstrumentation" bindestreckas?

Vi följer Microsoft Style Guide för produktdokumentation som publicerats till Microsoft Learn-plattformen .

I allmänhet inkluderar vi inte ett bindestreck efter prefixet "auto".

Var kan jag få mer information om autoinstrumentation?

Mer information finns i Vad är autoinstrumentation för Azure Monitor Application Insights?.

Automatisk instrumentering för Azure Kubernetes Service

Har Azure Kubernetes Service (AKS) autoinstrumentation stöd för anpassade mått?

Om du vill ha anpassade mått i Node.jskan du manuellt instrumentera program med Azure Monitor OpenTelemetry Distro.

Java tillåter anpassade mått med autoinstrumentation. Du kan samla in anpassade mått genom att uppdatera koden och aktivera den här funktionen. Om koden redan har anpassade mått flödar de igenom när automatisk instrumentering är aktiverat.

Fungerar AKS-autoinstrumentation med program som instrumenterats med en OpenTelemetry-SDK med öppen källkod (OSS) ?

AKS-autoinstrumentation kan störa telemetrin som skickas till tredje part av en OSS OpenTelemetry SDK.

Kan AKS autoinstrumentation samexistera med manuell instrumentering?

AKS autoinstrumentation är utformad för att samexistera med båda alternativen för manuell instrumentering: den klassiska API SDK:n för Application Insights och OpenTelemetry Distro.

Det förhindrar alltid dubbletter av data och säkerställer att anpassade mått fungerar.

Se det här diagrammet för att avgöra när autoinstrumentation eller manuell instrumentering har företräde.

Språk	Företräde
Node.js	Manuell instrumentering
Java	Automatisk instrumentering

Hur ser jag till att jag använder de senaste och säkraste versionerna av Azure Monitor OpenTelemetry Distro?

Sårbarheter som identifieras i Azure Monitor OpenTelemetry Distro prioriteras, åtgärdas och släpps i nästa version.

AKS autoinstrumentation matar in den senaste versionen av Azure Monitor OpenTelemetry Distro i dina programpoddar varje gång distributionen ändras eller startas om.

OpenTelemetry Distro kan bli sårbar för distributioner som inte ändras eller startas om under längre tidsperioder. Därför rekommenderar vi att du uppdaterar eller startar om distributioner varje vecka för att säkerställa att en ny version av distributionen används.

Hur lär jag mig mer om Azure Monitor OpenTelemetry Distro?

Den här funktionen uppnår autoinstrumentering genom att injicera Azure Monitor OpenTelemetry Distro i programpoddar.

För Java integrerar den här funktionen fristående Azure Monitor OpenTelemetry Distro för Java. Se vår Java-distributionsdokumentation för att lära dig mer om Java-instrumentationsbinärfilen.

För Node.jsinjekterar vi en autoinstrumentering-binär baserad på vår Azure Monitor OpenTelemetry Distro för Node.js. Mer information finns iNode.js distributionsdokumentation. Tänk på att vi inte har någon fristående autoinstrumentation för Node.js så vår distributionsdokumentation är inriktad på manuell instrumentering. Du kan ignorera kodbaserade konfigurationssteg som rör manuell instrumentering. Men allt annat i vår distributionsdokumentation, till exempel standardinställningar, miljövariabelkonfigurationer osv. gäller för den här funktionen.

Var kan jag få mer information om automatisk instrumentering för AKS?

Mer information finns i Autoinstrumentation för AKS.

Anslutningssträngar

Kräver nya Azure-regioner användning av anslutningssträng?

Nya Azure-regioner kräver användning av anslutningssträng i stället för instrumentationsnycklar. Anslutningssträngen identifierar den resurs som du vill associera med dina telemetridata. Du kan också ändra de slutpunkter som din resurs använder som mål för telemetrin. Kopiera anslutningssträng och lägg till den i programmets kod eller i en miljövariabel.

Ska jag använda anslutningssträng eller instrumentationsnycklar?

Vi rekommenderar att du använder anslutningssträng i stället för instrumentationsnycklar.

När behöver jag ange miljövariabeln?

APPLICATIONINSIGHTS_CONNECTION_STRING Ange manuellt i alla scenarier där systemet inte tillhandahåller det automatiskt. Dessa scenarier omfattar, men är inte begränsade till: lokal utveckling och .NET Isolerade funktioner med hjälp av ASP.NET Core-integrering. I dessa fall säkerställer miljövariabeln att OpenTelemetry-pipelinen kan skicka telemetri till Application Insights. Mer information om hur du konfigurerar anslutningssträngar med en miljövariabel finns i Konfigurera OpenTelemetry i Application Insights.

Hur gör jag för att instrumentera ett globalt webbprogram för att uppfylla kraven på regional dataefterlevnad?

Om du vill uppfylla kraven för regional dataefterlevnad använder du regionala Application Insights-slutpunkter i stället för den globala slutpunkten. Den globala slutpunkten garanterar inte att data stannar inom en viss region. Regionala slutpunkter hjälper till att säkerställa att telemetri från användare i reglerade områden endast skickas till datacenter i dessa regioner.

Så här konfigurerar du ditt globala webbprogram för regional efterlevnad:

• Skapa en Application Insights-resurs per region med strikta efterlevnadskrav, till exempel EU eller USA.
• Skapa en annan Application Insights-resurs för användare i alla andra regioner.
• Konfigurera ditt program för att skicka telemetri till lämplig Application Insights-resurs baserat på varje användares region. Fastställ regionen med hjälp av signaler som IP-adress, kontometadata eller platsinställningar.
• Anslut alla Application Insights-resurser till en Log Analytics-arbetsyta om du behöver en enhetlig frågeupplevelse mellan regioner.

Till exempel:

• Skicka data från Region A-användare till resursen Region A Application Insights med hjälp av anslutningssträngen Region A.
• Skicka data från region B-användare till resursen Region B Application Insights med hjälp av anslutningssträngen Region B.
• Skicka alla andra användardata till en application insights-resurs för generell användning med en annan anslutningssträng.

Viktigt!

Att använda den globala slutpunkten säkerställer inte regional efterlevnad. Om du vill uppfylla kraven för datahemvist använder du alltid regionspecifika slutpunkter och dirigerar telemetri baserat på användarens region.

Följande diagram visar ett exempel på en konfiguration för ett globalt webbprogram:

Var kan jag få mer information om anslutningssträngar i Application Insights?

Mer information finns i Anslutningssträngar.

Skapa och konfigurera Application Insights-resurser

Hur gör jag för att flytta en Application Insights-resurs till en ny region?

Överföring av befintliga Application Insights-resurser mellan regioner stöds inte och du kan inte migrera historiska data till en ny region. Lösningen omfattar:

• Skapa en ny Application Insights-resurs i önskad region.
• Återskapa alla unika anpassningar från den ursprungliga resursen i den nya.
• Uppdatera programmet med den nya regionresursens anslutningssträng.
• Testa för att säkerställa att allt fungerar som förväntat med den nya Application Insights-resursen.
• Bestämmer dig för att behålla eller ta bort den ursprungliga Application Insights-resursen. Att ta bort en klassisk resurs innebär att alla historiska data går förlorade. Om resursen är arbetsytebaserad finns data kvar i Log Analytics, vilket ger åtkomst till historiska data tills kvarhållningsperioden upphör att gälla.

Unika anpassningar som vanligtvis behöver återskapas eller uppdateras manuellt för resursen i den nya regionen omfattar, men som inte är begränsade till:

• Återskapa anpassade instrumentpaneler och arbetsböcker.
• Återskapa eller uppdatera omfånget för anpassade logg-/måttaviseringar.
• Återskapa tillgänglighetsaviseringar.
• Återskapa alla anpassade rollbaserade åtkomstkontrollinställningar i Azure som krävs för att användarna ska få åtkomst till den nya resursen.
• Replikera inställningar som omfattar datainmatningssampling, datahållning, daglig begränsning och anpassad metrikaktivering. De här inställningarna styrs via fönstret Användning och uppskattade kostnader .
• Alla integreringar som förlitar sig på API-nycklar, till exempel versionsanteckningar och live-mått, skyddar kontrollkanalen. Du måste generera nya API-nycklar och uppdatera den associerade integreringen.
• Kontinuerlig export i klassiska resurser måste konfigureras igen.
• Diagnostikinställningar i arbetsytebaserade resurser måste konfigureras igen.

Kan jag använda providers('Microsoft.Insights', 'components').apiVersions[0] i mina Azure Resource Manager-distributioner?

Vi rekommenderar inte att du använder den här metoden för att fylla i API-versionen. Den senaste versionen kan representera förhandsversioner, som kan innehålla ändringar som bryter kompatibiliteten. Även med nyare versioner som inte är förhandsversioner är API-versionerna inte alltid bakåtkompatibla med befintliga mallar. I vissa fall kanske API-versionen inte är tillgänglig för alla prenumerationer.

Var kan jag få mer information om att skapa och konfigurera Application Insights-resurser?

Mer information finns i Skapa och konfigurera Application Insights-resurser.

Telemetridatamodell

Hur rapporterar jag datamodell- eller schemaproblem och förslag?

Om du vill rapportera datamodell- eller schemaproblem och förslag använder du vår GitHub-lagringsplats.

Hur mäter jag effekten av en övervakningskampanj?

PageView-telemetri innehåller URL och du kan parsa UTM-parametern med hjälp av en regex-funktion i Kusto.

Ibland kan dessa data saknas eller vara felaktiga om användaren eller företaget inaktiverar sändningen av användaragenten i webbläsarinställningarna. UA Parser-regexes kanske inte innehåller all enhetsinformation. Eller så kanske Application Insights inte har antagit de senaste uppdateringarna.

Varför skulle en anpassad mätning lyckas utan fel, men loggen visas inte?

Detta kan inträffa om du använder strängvärden. Endast numeriska värden fungerar med anpassade mått.

Var kan jag få mer information om telemetridatamodellen?

Mer information finns i Application Insights telemetridatamodell.

Loggning med .NET

Vilken Application Insights-telemetrityp skapas från ILogger-loggar? Var kan jag se ILogger-loggar i Application Insights?

ApplicationInsightsLoggerProvider ILogger registrerar loggar och skapar TraceTelemetry från dem. Om ett Exception-objekt skickas till Log-metoden på ILogger, skapas ExceptionTelemetry i stället för TraceTelemetry.

Visa ILogger-telemetri

På Azure-portalen:

1. Gå till Azure Portal och få åtkomst till application insights-resursen.
2. Välj avsnittet Loggar i Application Insights.
3. Använd Kusto-frågespråk (KQL) för att köra frågor mot ILogger-meddelanden som lagras i traces tabellen. Exempelfråga: traces | where message contains "YourSearchTerm".
4. Förfina dina frågor för att filtrera ILogger-data efter allvarlighetsgrad, tidsintervall eller specifikt meddelandeinnehåll.

I Visual Studio (lokalt felsökningsprogram):

1. Starta programmet i felsökningsläge i Visual Studio.
2. Öppna fönstret Diagnostikverktyg medan programmet körs.
3. På fliken Händelser visas ILogger-loggar tillsammans med andra telemetridata.
4. Om du vill hitta specifika ILogger-meddelanden använder du sök- och filterfunktionerna i fönstret Diagnostikverktyg .

Om du föredrar att alltid skicka TraceTelemetryanvänder du det här kodfragmentet:

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

Varför har vissa ILogger-loggar inte samma egenskaper som andra?

Application Insights samlar in och skickar ILogger loggar med samma TelemetryConfiguration information som används för alla andra telemetrier. Men det finns ett undantag. Som standard TelemetryConfiguration är inte helt konfigurerat när du loggar från Program.cs eller Startup.cs. Loggar från dessa platser har inte standardinställningen, så de kör inte samtliga TelemetryInitializer instanser och TelemetryProcessor instanser.

Jag använder det fristående paketet Microsoft.Extensions.Logging.ApplicationInsights och vill logga mer anpassad telemetri manuellt. Hur ska jag göra det?

När du använder det fristående paketet, injiceras inte TelemetryClient i beroendeinjektionsbehållaren. Du måste skapa en ny instans av TelemetryClient och använda samma konfiguration som loggningsprovidern använder, som följande kod visar. Det här kravet säkerställer att samma konfiguration används för all anpassad telemetri och telemetri från ILogger.

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;
   }  
}

Anmärkning

Om du använder Microsoft.ApplicationInsights.AspNetCore paketet för att aktivera Application Insights ändrar du den här koden för att komma TelemetryClient direkt i konstruktorn.

Jag har inte installerat SDK och använder Azure Web Apps-tillägget för att aktivera Application Insights för mina ASP.NET Core-program. Hur gör jag för att använda den nya providern?

Application Insights-tillägget i Azure Web Apps använder den nya providern. Du kan ändra filtreringsreglerna i appsettings.json-filen för ditt program.

Var kan jag få mer information om loggning med .NET?

Mer information finns i Application Insights-loggning med .NET.

Java Profileringsverktyg

Vad är Azure Monitor Application Insights Java-profilering?

Java Profiler använder Java Flight Recorder (JFR) för att profilera ditt program med hjälp av en anpassad konfiguration.

Vad är Java Flight Recorder?

Java Flight Recorder (JFR) är ett verktyg för att samla in profileringsdata för ett Java-program som körs. JFR är integrerat i JVM (Java Virtual Machine) och används för felsökning av prestandaproblem. Läs mer om Java SE JFR Runtime.

Vad påverkar priset och/eller licensavgifterna för att aktivera App Insights Java-profilering?

Java-profilering är en kostnadsfri funktion med Application Insights. Prissättningen för Azure Monitor Application Insights baseras på inmatningskostnaden.

Vilken Java-profileringsinformation samlas in?

Profileringsdata som samlas in av JFR omfattar: metod- och körningsprofileringsdata, skräpinsamlingsdata och låsprofiler.

Hur kan jag använda App Insights Java-profilering och visualisera data?

JFR-inspelning kan visas och analyseras med önskat verktyg, till exempel Java Mission Control (JMC).

Tillhandahålls prestandadiagnostik och korrigeringsrekommendationer med App Insights Java-profilering?

"Prestandadiagnostik och rekommendationer" är en ny funktion som snart blir tillgänglig som Application Insights Java Diagnostics. Du kan registrera dig för att förhandsgranska den här funktionen. JFR-inspelning kan visas med Java Mission Control (JMC).

Vad är skillnaden mellan på begäran och automatisk Java-profilering i App Insights?

På begäran utlöses profilering av användare i realtid medan automatisk profilering är med förkonfigurerade utlösare.

Använd Profil nu för profileringsalternativet på begäran. Profil nu profilerar omedelbart alla agenter som är kopplade till Application Insights-instansen.

Automatisk profilering utlöses genom att ett resurströskelvärde nås.

Vilka Java-profileringsutlösare kan jag konfigurera?

Application Insights Java Agent stöder för närvarande övervakning av PROCESSOR- och minnesförbrukning. Cpu-tröskelvärdet konfigureras som en procentandel av alla tillgängliga kärnor på datorn. Minnesuppbyggnad är den aktuella belastningen på Tenured-minnesregionen (OldGen) i förhållande till den maximalt möjliga storleken för regionen.

Vilka är de krav som krävs för att aktivera Java-profilering?

Granska förutsättningarna.

Kan jag använda Java-profilering för ett mikrotjänstprogram?

Ja, du kan profilera en JVM som kör mikrotjänster med hjälp av JFR.

Var kan jag få mer information om Java Profiler?

Mer information finns i Azure Monitor Application Insights Profiler för Java.

Samplings åsidosättningar – Application Insights för Java

Behöver jag använda manuell instrumentering för att aktivera samplings åsidosättningar?

Nej, samplings åsidosättningar är nu allmänt tillgängliga (GA) och kan användas med både autoinstrumentation och manuell instrumentering.

Hur konfigurerar jag åsidosättningar för sampling när jag använder Azure App Service med autoinstrumentation?

Om du använder autoinstrumentation, uppdatera filen applicationinsights.json i Azure-portalen.

Är det nödvändigt att ladda upp Application Insights-agentfilen manuellt för samplings åsidosättningar?

För automatisk instrumentering krävs ingen manuell agentuppladdning. För manuell instrumentering behöver du dock fortfarande inkludera JAR-filen och konfigurationsfilerna för Application Insights-agenten i distributionspaketet.

Vad är skillnaden mellan "lokal utveckling" och "programserver" i samband med manuell instrumentering?

Lokal utveckling avser miljön där appen skapas eller testas, till exempel en utvecklardator eller en Azure Cloud Shell-instans. Programservern refererar till webbservern som kör programmet, till exempel Tomcat 11 i en Azure App Service-miljö. När du använder manuell instrumentering måste du se till att AGENT JAR-filen är korrekt placerad på programservern.

Hur konfigurerar jag samplings åsidosättningar om jag använder en Azure App Service med en Java-körning (till exempel Tomcat 11) ?

För automatisk instrumentering kan du konfigurera samplings åsidosättningar via Azure-portalen. Om du använder manuell instrumentering bör du placera Application Insights-agentens JAR i rätt katalog och inkludera applicationinsights.json-filen med önskade samplingsinställningar.

Var kan jag få mer information om samplings åsidosättningar?

Mer information finns i Samplings åsidosättningar – Azure Monitor Application Insights för Java.

Telemetriprocessorer

Varför bearbetar inte loggprocessorn loggfilerna med TelemetryClient.trackTrace()?

TelemetryClient.trackTrace() är en del av Application Insights klassiska SDK-brygga och loggprocessorerna fungerar bara med den nya OpenTelemetry-baserade instrumentationen.

Var kan jag få mer information om telemetriprocessorer?

Mer information finns i Telemetriprocessorer (förhandsversion) – Azure Monitor Application Insights för Java.

JavaScript SDK

Vad är antalet användare och sessioner?

• JavaScript SDK anger en användarcookie på webbklienten, för att identifiera återkommande användare och en sessionscookie till gruppaktiviteter.
• Om det inte finns något skript på klientsidan kan du ange cookies på servern.
• Om en verklig användare använder din webbplats i olika webbläsare, eller genom att använda privat/inkognitobläddring eller olika datorer, räknas de mer än en gång.
• Om du vill identifiera en inloggad användare mellan datorer och webbläsare lägger du till ett anrop till setAuthenticatedUserContext().

Vad är Prestanda/overhead för JavaScript SDK?

Application Insights JavaScript SDK har minimala kostnader på din webbplats. Med en storlek på bara 36 KB gzipped, och tar bara ~15 ms för att initiera, lägger SDK till en försumbar laddningstid till din webbplats. De minimala komponenterna i biblioteket läses snabbt in när du använder SDK och det fullständiga skriptet laddas ned i bakgrunden.

Även om skriptet laddas ned från CDN placeras dessutom all spårning av sidan i kö, så att du inte förlorar någon telemetri under hela sidans livscykel. Den här konfigurationsprocessen ger din sida ett sömlöst analyssystem som är osynligt för dina användare.

Vilka webbläsare stöds av JavaScript SDK?

Chrome, Senaste Versionen ✔	Firefox senaste ✔	v3.x: IE 9+ & Microsoft Edge ✔ v2.x: IE 8+ Kompatibel och Microsoft Edge ✔	Opera senaste version ✔	Safari, senaste versionen ✔

Var hittar jag kodexempel för JavaScript SDK?

Körbara exempel finns i Application Insights JavaScript SDK-exempel.

Vad är ES3/Internet Explorer 8-kompatibiliteten med JavaScript SDK?

Vi måste vidta nödvändiga åtgärder för att se till att denna SDK fortsätter att "fungera" och inte bryter JavaScript-körningen när den läses in av en äldre webbläsare. Det skulle vara idealiskt att inte stödja äldre webbläsare, men många stora kunder kan inte styra vilken webbläsare användarna väljer att använda.

Detta uttalande innebär inte att vi enbart stödjer den lägsta gemensamma uppsättningen funktioner. Vi måste upprätthålla ES3-kodkompatibilitet. Nya funktioner måste läggas till på ett sätt som inte bryter ES3 JavaScript-parsning och läggs till som en valfri funktion.

Mer information om Stöd för Internet Explorer 8 finns i GitHub.

Är JavaScript SDK öppen källkod?

Ja, Application Insights JavaScript SDK är öppen källkod. Information om hur du visar källkoden eller bidrar till projektet finns i den officiella GitHub-lagringsplatsen.

Var kan jag få mer information om JavaScript SDK?

Mer information finns i Aktivera Azure Monitor Application Insights Verklig användarövervakning.

JavaScript SDK-konfiguration

Hur uppdaterar jag min serverkonfiguration från tredje part för JavaScript SDK?

Serversidan måste kunna acceptera anslutningar med de rubriker som finns. Beroende på konfigurationen Access-Control-Allow-Headers på serversidan är det ofta nödvändigt att utöka listan på serversidan genom att manuellt lägga till Request-Id, Request-Contextoch traceparent (W3C-distribuerat huvud).

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

Hur inaktiverar jag distribuerad spårning för JavaScript SDK?

Distribuerad spårning kan inaktiveras i konfigurationen.

Samlas HTTP 502- och 503-svaren alltid in av Application Insights?

Nej. Felen "502 bad gateway" och "503 service unavailable" registreras inte alltid av Application Insights. Om endast JavaScript på klientsidan används för övervakning skulle det här beteendet förväntas eftersom felsvaret returneras innan sidan som innehåller HTML-huvudet med javascript-övervakningsfragmentet återges.

Om svaret 502 eller 503 skickades från en server med övervakning på serversidan aktiverat samlas felen in av Application Insights SDK.

Även när övervakning på serversidan är aktiverad på ett programs webbserver, registreras ibland inte ett 502- eller 503-fel av Application Insights. Många moderna webbservrar tillåter inte att en klient kommunicerar direkt. I stället använder de lösningar som omvända proxyservrar för att skicka information fram och tillbaka mellan klienten och klientwebbservrarna.

I det här scenariot kan ett 502- eller 503-svar returneras till en klient på grund av ett problem på det omvända proxylagret, så det fångas inte in direkt av Application Insights. För att identifiera problem på det här lagret kan du behöva vidarebefordra loggar från den omvända proxyn till Log Analytics och skapa en anpassad regel för att söka efter 502- eller 503-svar. Mer information om vanliga orsaker till 502- och 503-fel finns i Felsöka HTTP-fel med "502 felaktig gateway" och "503-tjänsten är inte tillgänglig" i Azure App Service.

Var kan jag få mer information om JavaScript SDK-konfiguration?

Mer information finns i Application Insights JavaScript SDK-konfiguration.

JavaScript-ramverkstillägg

Hur genererar Application Insights enhetsinformation som webbläsare, operativsystem, språk och modell?

Webbläsaren skickar användaragentsträngen i HTTP-huvudet för begäran. Application Insights-inmatningstjänsten använder UA Parser för att generera de fält som du ser i datatabellerna och -upplevelserna. Därför kan Application Insights-användare inte ändra dessa fält.

Ibland kan dessa data saknas eller vara felaktiga om användaren eller företaget inaktiverar sändningen av användaragenten i webbläsarinställningarna. UA Parser-regexes kanske inte innehåller all enhetsinformation. Eller så kanske Application Insights inte har antagit de senaste uppdateringarna.

Var kan jag få mer information om JavaScript-ramverkstillägg?

Mer information finns i Aktivera ett ramverkstillägg för Application Insights JavaScript SDK.

Hanterade arbetsytor

Behöver jag uppdatera skript eller automatisering som refererar till klassiska resurser?

Nej. Befintliga ARM-mallar och API-anrop fortsätter att fungera. När du försöker skapa en klassisk resurs skapas i stället en arbetsytebaserad resurs med en hanterad arbetsyta.

Meddelas jag innan min resurs migreras?

Nej. Meddelande för enskilda resursmigreringar är inte tillgängligt. Om du vill styra när och hur dina resurser migreras använder du manuell migrering.

Hur lång tid tar migreringsprocessen?

Enskilda migreringar slutförs vanligtvis på mindre än två minuter. Den fullständiga distributionen sker under flera veckor i alla regioner.

Hur vet jag om en resurs har migrerats?

Efter migreringen länkar resursen till en Log Analytics-arbetsyta på sidan Översikt. Det klassiska meddelandet om tillbakadragning tas bort och arbetsboken för tillbakadragningar visar inte längre resursen.

Kommer min fakturering att ändras efter migreringen?

Kostnaderna förblir vanligtvis likartade. Arbetsytebaserade Application Insights möjliggör kostnadsbesparande funktioner och vi rekommenderar att du granskar prisplaner.

Om du använder en äldre faktureringsmodell kan du läsa prisdokumentationen för mer information.

Förlorar jag aviseringar eller tillgänglighetstester under migreringen?

Nej. Alla aviseringar, instrumentpaneler och tillgänglighetstester förblir intakta och fortsätter att fungera efter migreringen.

Var kan jag få mer information om hanterade arbetsytor?

Mer information finns i Hanterade arbetsytor i Application Insights.

Node.js

Hur inaktiverar jag telemetrikorrelation?

Om du vill inaktivera telemetrikorrelation använder du correlationHeaderExcludedDomains egenskapen i konfigurationen. Mer information finns i ApplicationInsights-node.js.

Hur konfigurerar jag den önskade loggnivån?

Använd miljövariabeln för att konfigurera önskad loggnivå som Application Insights ska använda APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . De värden som stöds är NONE, ERROR, WARN, INFO, DEBUG, VERBOSE och ALL. Mer information finns i ApplicationInsights-node.js.

Var kan jag få mer information om övervakning Node.js tjänster och appar med Application Insights?

Mer information finns i Övervaka dina Node.js tjänster och appar med Application Insights.

Azure Monitor OpenTelemetry

Var hittar jag en lista över Application Insights SDK-versioner och deras namn?

En lista över SDK-versioner och -namn finns på GitHub. Mer information finns i SDK-version.

Var kan jag få mer information om OpenTelemetry?

Mer information finns i Samla in telemetri med OpenTelemetry i Application Insights.

Migrera från .NET Application Insights SDK:er till Azure Monitor OpenTelemetry

Hur mappar SDK-API:erna till OpenTelemetry-begrepp?

OpenTelemetry är ett leverantörsneutralt observerbarhetsramverk. Det finns inga Application Insights-API:er i OpenTelemetry SDK eller bibliotek. Innan du migrerar är det viktigt att förstå några av OpenTelemetrys begrepp.

• I Application Insights hanterades all telemetri genom en enda TelemetryClient och TelemetryConfiguration. I OpenTelemetry har var och en av de tre telemetrisignalerna (spårningar, mått och loggar) sin egen konfiguration. Du kan skapa telemetri manuellt via .NET-körningen utan externa bibliotek. Mer information finns i .NET-guiderna för distribuerad spårning, mått och loggning.

• Application Insights används TelemetryModules för att automatiskt samla in telemetri för ditt program. I stället använder OpenTelemetry Instrumentation-bibliotek för att samla in telemetri från specifika komponenter (till exempel AspNetCore för begäranden och HttpClient för beroenden).

• Application Insights används TelemetryInitializers för att utöka telemetri med ytterligare information eller för att åsidosätta egenskaper. Med OpenTelemetry kan du skriva en processor för att anpassa en specifik signal. Dessutom erbjuder många OpenTelemetry Instrumentation-bibliotek en Enrich metod för att anpassa telemetrin som genereras av den specifika komponenten.

• Application Insights används TelemetryProcessors för att filtrera telemetri. En OpenTelemetry-processor kan också användas för att tillämpa filtreringsregler på en specifik signal.

Hur mappas Application Insights-telemetrityper till OpenTelemetry?

Den här tabellen mappar Application Insights-datatyper till OpenTelemetry-begrepp och deras .NET-implementeringar.

Azure Monitor-tabell	Application Insights Datatyp	OpenTelemetry Datatyp	.NET-implementering
specialanpassade händelser	EventTelemetry	Inte tillgänglig	Inte tillgänglig
customMetrics	MetricTelemetry	Mätvärden	System.Diagnostics.Metrics.Meter
beroenden	BeroendeTelemetri	Intervall (klient, intern, konsument)	System.Diagnostics.Activity
undantag	ExceptionTelemetry	Undantag	System.Exception
begäranden	Begärtelemetri	Spann (Server, Producent)	System.Diagnostics.Activity
spår	Spårtelemetri	Loggfiler	Microsoft.Extensions.Logging.ILogger
spår	Spårtelemetri	Span-händelser	System.Diagnostics.ActivityEvent

Följande dokument innehåller mer information.

• Grunderna för datainsamling i Azure Monitor Application Insights
• Application Insights-telemetridatamodell
• OpenTelemetry-begrepp

Hur mappar Application Insights-samplingsbegrepp till OpenTelemetry?

Application Insights erbjöd flera alternativ för att konfigurera sampling, men Azure Monitor Exporter eller Azure Monitor Distro erbjuder endast sampling med fast hastighet. Endast begäranden och beroenden (OpenTelemetry Traces) kan samplas.

Kodexempel som beskriver hur du konfigurerar sampling finns i vår guide Aktivera sampling

Hur mappas telemetriprocessorer och initierare till OpenTelemetry?

I Application Insights .NET SDK använder du telemetriprocessorer för att filtrera och ändra eller ta bort telemetri. Använd telemetriinitierare för att lägga till eller ändra anpassade egenskaper. Mer information finns i Dokumentation om Azure Monitor. OpenTelemetry ersätter dessa begrepp med aktivitets- eller loggprocessorer som berikar och filtrerar telemetri.

Filtrera spårningar

Om du vill filtrera telemetridata i OpenTelemetry kan du implementera en aktivitetsprocessor. Det här exemplet motsvarar Application Insights-exemplet för filtrering av telemetridata enligt beskrivningen i Azure Monitor-dokumentationen. Exemplet visar var misslyckade beroendeanrop filtreras.

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;
    }
}

Om du vill använda den här processorn måste du skapa en TracerProvider och lägga till processorn före AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

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

Filtrering av loggar

ILogger implementeringar har en inbyggd mekanism för att tillämpa loggfiltrering. Med den här filtreringen kan du styra loggarna som skickas till varje registrerad provider, inklusive OpenTelemetryLoggerProvider. "OpenTelemetry" är aliaset för OpenTelemetryLoggerProvider, som används för att konfigurera filtreringsregler.

I följande exempel definieras "Fel" som standard LogLevel och "Varning" definieras som minimum LogLevel för en användardefinierad kategori. Dessa regler som definieras gäller endast för OpenTelemetryLoggerProvider.

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

Mer information finns i OpenTelemetry .NET-dokumentationen om loggar.

Lägga till anpassade egenskaper i spårningar

I OpenTelemetry kan du använda aktivitetsprocessorer för att utöka telemetridata med fler egenskaper. Det liknar att använda telemetriinitierare i Application Insights, där du kan ändra telemetriegenskaper.

Som standard flaggar Azure Monitor Exporter alla HTTP-begäranden med en svarskod på 400 eller senare som misslyckade. Men om du vill behandla 400 som ett lyckat resultat kan du lägga till en processor för berikande aktiviteter som anger framgång på aktiviteten och lägger till en tagg för att inkludera fler telemetriegenskaper. Det liknar att lägga till eller ändra egenskaper med hjälp av en initierare i Application Insights enligt beskrivningen i Azure Monitor-dokumentationen.

Här är ett exempel på hur du lägger till anpassade egenskaper och åsidosätter standardbeteendet för vissa svarskoder:

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;
    }
}

Om du vill använda den här processorn måste du skapa en TracerProvider och lägga till processorn före AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

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

Hur gör jag för att spåra telemetri manuellt med OpenTelemetry?

Skicka spårningar – manuell

Spårningar i Application Insights lagras som RequestTelemetry och DependencyTelemetry. I OpenTelemetry modelleras spår som Span med hjälp av Activity klassen.

OpenTelemetry .NET använder ActivitySource klasserna och Activity för spårning, som ingår i .NET-körningen. Den här metoden är distinkt eftersom .NET-implementeringen integrerar spårnings-API:et direkt i själva körningen. Paketet System.Diagnostics.DiagnosticSource gör att utvecklare kan använda ActivitySource för att skapa och hantera Activity instanser. Den här metoden ger ett sömlöst sätt att lägga till spårning i .NET-program utan att förlita sig på externa bibliotek, med hjälp av de inbyggda funktionerna i .NET-ekosystemet. Mer detaljerad information finns i genomgången av distribuerade spårningsinstrument.

Så här migrerar du manuell spårning:

Anmärkning

I Application Insights kan rollnamnet och rollinstansen anges på telemetrinivå. Med Azure Monitor Exporter kan vi dock inte anpassa på per telemetrinivå. Rollnamnet och rollinstansen extraheras från OpenTelemetry-resursen och tillämpas på all telemetri. Läs det här dokumentet om du vill ha mer information: Ange namnet på molnrollen och molnrollinstansen.

BeroendeTelemetri

Application Insights DependencyTelemetry används för att modellera utgående begäranden. Så här konverterar du den till OpenTelemetry:

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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));
}

Begärtelemetri

Application Insights modellerar RequestTelemetry inkommande begäranden. Så här migrerar du den till OpenTelemetry:

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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);
}

Spårning av anpassade operationer

I Application Insights spårar du anpassade åtgärder med hjälp av StartOperation och StopOperation metoder. Uppnå det med hjälp av ActivitySource och Activity i OpenTelemetry .NET. För åtgärder med ActivityKind.Server och ActivityKind.Consumergenererar Azure Monitor Exporter RequestTelemetry. För ActivityKind.Client, ActivityKind.Producer och ActivityKind.Internal genererar den DependencyTelemetry. För mer information om spårning av anpassade åtgärder, se Dokumentation om Azure Monitor. Mer information om hur du använder ActivitySource och Activity i .NET finns i genomgångarna för .NET-distribuerade spårningsinstrumentation.

Här är ett exempel på hur du startar och stoppar en aktivitet för anpassade åtgärder:

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

Skicka loggar

Loggar i Application Insights lagras som TraceTelemetry och ExceptionTelemetry.

Spårtelemetri

I OpenTelemetry integreras loggning via ILogger gränssnittet. Så här migrerar TraceTelemetrydu :

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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

Application Insights använder ExceptionTelemetry för att logga undantag. Så här migrerar du till OpenTelemetry:

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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

Skicka statistik

Mått i Application Insights lagras som MetricTelemetry. I OpenTelemetry modelleras Meter från System.Diagnostics.DiagnosticSource-paketet som mått.

Application Insights har både icke-aggreggerande (TrackMetric()) och föraggregerande (GetMetric().TrackValue()) mått-API:er. Till skillnad från OpenTelemetry har Application Insights ingen uppfattning om instrument. Application Insights har samma API för alla måttscenarier.

OpenTelemetry å andra sidan kräver att användarna först väljer rätt måttinstrument baserat på måttets faktiska semantik. Om avsikten till exempel är att räkna något (t.ex. antalet totala serverbegäranden som tagits emot osv.) ska OpenTelemetry Counter användas. Om avsikten är att beräkna olika percentiler (t.ex. P99-värdet för serverfördröjning) bör OpenTelemetry Histogram-instrument användas. På grund av den här grundläggande skillnaden mellan Application Insights och OpenTelemetry görs ingen direkt jämförelse mellan dem.

Till skillnad från Application Insights tillhandahåller OpenTelemetry inte inbyggda mekanismer för att berika eller filtrera mått. I Application Insights kan telemetriprocessorer och initiatorer användas för att ändra eller ta bort mått, men den här funktionen är inte tillgänglig i OpenTelemetry.

Dessutom har OpenTelemetry inte stöd för att skicka råmått direkt, eftersom det inte finns någon motsvarighet till de TrackMetric() funktioner som finns i Application Insights.

Att migrera från Application Insights till OpenTelemetry innebär att ersätta alla Application Insights Metric API-användningar med OpenTelemetry-API:et. Det kräver förståelse för de olika OpenTelemetry-instrumenten och deras semantik.

Tips/Råd

Histogrammet är den mest mångsidiga och närmaste motsvarigheten till API:et för Application Insights GetMetric().TrackValue(). Du kan ersätta Application Insights Metric API:er med Histogram för att uppnå samma syfte.

Andra telemetrityper

Anpassade händelser

Stöds inte i OpenTelemetry.

Application Insights-exempel:

TelemetryClient.TrackEvent()

TillgänglighetTelemetri

Stöds inte i OpenTelemetry.

Application Insights-exempel:

TelemetryClient.TrackAvailability()

PageViewTelemetry

Stöds inte i OpenTelemetry.

Application Insights-exempel:

TelemetryClient.TrackPageView()

Kan jag hämta livemått för konsol- och arbetstjänstprogram?

Vi rekommenderar Azure Monitor OpenTelemetry Exporter för konsol- och arbetstjänstprogram, som inte innehåller livemått.

Var kan jag få mer information om migrering från .NET Application Insights SDK:er till OpenTelemetry?

Mer information finns i Migrera från .NET Application Insights SDK:er till Azure Monitor OpenTelemetry.

OpenTelemetry-provtagning

Är Application Insights anpassade sampler svansbaserad?

Den anpassade provtagaren för Application Insights fattar samplingsbeslut efter att intervallen har skapats, snarare än tidigare, den följer därför inte en traditionell huvudbaserad metod. I stället tillämpas samplingsbeslut i slutet av tidsintervalls-genereringen – efter att tidsintervallet har slutförts men före exporten.

Även om det här beteendet liknar tail-based sampling på vissa sätt, väntar inte samplingssystemet med att samla in flera intervall från samma tråd innan det fattar ett beslut. I stället använder den en hash av spårnings-ID:t för att säkerställa spårningens fullständighet.

Den här metoden balanserar spårningens fullständighet och effektivitet och undviker den högre kostnaden i samband med fullständig tail-baserad sampling.

Om du vill fatta samplingsbeslut baserat på resultatet av en hel spårning (till exempel att avgöra om något intervall inom spårningen misslyckades) krävs fullständig tail-baserad sampling i en nedströmsagent eller insamlare. Den här funktionen stöds inte för närvarande, men du kan begära den som en ny funktion via feedbackhubben.

Hur jämför sig Application Insights anpassade provtagare med huvudbaserad eller svansbaserad sampling i OpenTelemetry?

Urvalsmetod	Beslutspunkt	Styrkor	Svagheter
Huvudbaserad	Innan ett spann börjar	Låg svarstid, minimalt med omkostnader	Kan ta ut önskade spår, inklusive misslyckanden.
Tail-baserad	När intervall buffrats baserat på tröskelvärden för tid eller volym	Tillåter mycket selektiva kriterier för spårsampling	Högre kostnad och extra bearbetningsfördröjning
Anpassad provtagare för App Insights	Slut på spangenerering	Balanserar spårnings fullständighet med effektivitet	Krävs för livemått och klassisk API-kompatibilitet

Kan jag prova beroenden, begäranden eller andra telemetrityper vid olika frekvenser?

Nej, samplern tillämpar en fast frekvens för alla telemetrityper i ett spår. Begäranden, beroenden och andra intervall följer samma samplingsprocent. Om du vill använda olika frekvenser per telemetrityp bör du överväga att använda OpenTelemetry span-processorer eller (inmatningstidstransformeringar)[opentelemetry-overview.md#telemetry-routing].

Hur sprids samplingbeslut i Application Insights anpassade provtagare?

Den anpassade Application Insights-exempeltagaren sprider samplingsbeslut med hjälp av W3C Trace Context-standarden som standard. Med den här standarden kan samplingsbeslut flöda mellan tjänster. Emellertid, eftersom samplaren fattar samplingsbeslut i slutet av spangenereringen – efter att ha anropat underordnade tjänster – innehåller överföringen ofullständig samplingsinformation. Den här begränsningen följer specifikationen för W3C-spårningskontext, men underordnade tjänster kan inte på ett tillförlitligt sätt använda detta beslut om spridd sampling.

Respekterar den anpassade Application Insights-provtagaren samplingsbeslut från överordnade tjänster?

Nej, den anpassade Application Insights-provtagaren fattar alltid ett oberoende samplingsbeslut, även om den överordnade tjänsten använder samma samplingsalgoritm. Samplingsbeslut från överordnade tjänster, inklusive de som använder W3C Trace Context-huvuden, påverkar inte den underordnade tjänstens beslut. Det samplar dock baserat på en hash av Trace ID för att säkerställa att spårningen är komplett. För att förbättra konsekvens och minska risken för brutna spår, konfigurera alla komponenter i systemet så att de använder samma sampler och samplingsfrekvens.

Varför verkar vissa spårningar ofullständiga även när du använder den anpassade Application Insights-exempelappen?

Det finns flera orsaker till att spårningar kan verka ofullständiga:

• Olika noder i ett distribuerat system använder olika samplingsmetoder som inte samordnar beslut. En nod tillämpar till exempel Huvudbaserad sampling i OpenTelemetry, och en annan nod tillämpar sampling via Azure Monitor Custom Sampler.
• Olika noder är inställda på olika samplingsfrekvenser, även om de båda använder samma samplingsmetod.
• Du anger filtrerings-, samplings- eller hastighetsbegränsningar i pipelinen på tjänstsidan, och den här konfigurationen samplar slumpmässigt bort intervall utan att beakta spårens fullständighet.

Om en komponent tillämpar huvudbaserad sampling utan att sprida samplingsbeslutet (via W3C Trace Context-rubriker) provar underordnade tjänster spårningen oberoende av varandra, vilket kan resultera i borttagna intervall. Därför är vissa delar av spårningen inte alltid tillgängliga när de visas i Application Insights.

Var kan jag få mer information om OpenTelemetry-sampling?

Mer information finns i Sampling i Azure Monitor Application Insights med OpenTelemetry.

Support och feedback för OpenTelemetry

Vad är OpenTelemetry?

Det är en standard med öppen källkod för observerbarhet. Läs mer på OpenTelemetry.

Varför investerar Microsoft Azure Monitor i OpenTelemetry?

Microsoft investerar i OpenTelemetry av följande skäl:

• Den är leverantörsneutral och tillhandahåller konsekventa API:er/SDK:er mellan olika språk.
• Med tiden tror vi att OpenTelemetry gör det möjligt för Azure Monitor-kunder att observera program som skrivits på språk utöver våra språk som stöds.
• Den utökar de typer av data som du kan samla in via en omfattande uppsättning instrumentationsbibliotek.
• OpenTelemetry Software Development Kits (SDK:er) tenderar att vara mer högpresterande i stor skala än sina föregångare, Application Insights SDK:er.
• OpenTelemetry överensstämmer med Microsofts strategi att ta till sig öppen källkod.

Vad är statusen för OpenTelemetry?

Se Status för OpenTelemetry.

Vad är Azure Monitor OpenTelemetry Distro?

Du kan se det som en tunn omslutning som buntar ihop alla OpenTelemetry-komponenter för en förstklassig upplevelse i Azure. Den här omslutningen kallas även för en distribution i OpenTelemetry.

Varför ska jag använda Azure Monitor OpenTelemetry Distro?

Det finns flera fördelar med att använda Azure Monitor OpenTelemetry Distro över inbyggd OpenTelemetry från communityn:

• Minskar aktiveringsarbetet
• Stöds av Microsoft
• Innehåller Azure-specifika funktioner som:
  • Sampling som är kompatibel med klassiska Application Insights-SDK:er
  • Microsoft Entra-autentisering
  • Offlinelagring och automatiska återförsök
  • Statistikbeat
  • Application Insights Standard-mått
  • Identifiera resursmetadata för att automatiskt fylla i molnrollnamn och molnrollinstans i olika Azure-miljöer
  • Direktmätningar

I OpenTelemetrys anda utformade vi distributionen så att den var öppen och utökningsbar. Du kan till exempel lägga till:

• En OpenTelemetry Protocol-exportör (OTLP) och skicka till ett andra mål samtidigt
• Andra instrumentationsbibliotek som inte ingår i distributionen

Eftersom Distro tillhandahåller en OpenTelemetry-distribution stöder distributionen allt som stöds av OpenTelemetry. Du kan till exempel lägga till fler telemetriprocessorer, exportörer eller instrumentationsbibliotek om OpenTelemetry stöder dem.

Anmärkning

Distro ställer in samplern till en anpassad, konstant frekvenssamplare för Application Insights. Du kan ändra detta till en annan provtagare, men om du gör det kan du inaktivera några av distributionens inbyggda funktioner. För mer information om den stödda sampler, se avsnittet Aktivera sampling i Konfigurera Azure Monitor OpenTelemetry.

För språk utan en fristående OpenTelemetry-exportör som stöds är Azure Monitor OpenTelemetry Distro det enda sättet att använda OpenTelemetry med Azure Monitor. För språk med en fristående OpenTelemetry-exportör som stöds kan du använda antingen Azure Monitor OpenTelemetry Distro eller lämplig fristående OpenTelemetry-exportör beroende på ditt telemetriscenario. Mer information finns i När ska jag använda Azure Monitor OpenTelemetry-exportören?.

Hur kan jag testa Azure Monitor OpenTelemetry Distro?

Kolla in våra aktiveringsdokument för .NET, Java, JavaScript (Node.js) och Python.

Ska jag använda OpenTelemetry eller Application Insights SDK?

Vi rekommenderar att du använder Azure Monitor OpenTelemetry Distro för nya projekt när dess funktioner överensstämmer med dina övervakningsbehov. OpenTelemetry är ett branschstandardramverk som förbättrar plattformsoberoende observerbarhet och ger en standardiserad metod för telemetrisamling.

Application Insights SDK:er tillhandahåller dock fortfarande vissa funktioner som ännu inte är helt automatiserade i OpenTelemetry, inklusive:

• Automatisk beroendespårning – OpenTelemetry stöder beroendespårning, men vissa beroenden kräver ytterligare konfiguration jämfört med den automatiska spårning som är tillgänglig i Application Insights SDK:er.
• Anpassade telemetrityper, till exempel AvailabilityTelemetry och PageViewTelemetry – OpenTelemetry har inte direkta motsvarigheter. Liknande funktioner kan implementeras via manuell instrumentering.
• Telemetriprocessorer och initierare – OpenTelemetry har processorer och spanprocessorer, men de ersätter inte Application Insights telemetriprocessorer och initierare helt i alla scenarier.
• Utökad måttsamling – Även om OpenTelemetry har ett starkt måttsystem, kräver vissa inbyggda mått från Application Insights SDK:er manuell konfiguration i OpenTelemetry.

OpenTelemetry ger också fördelar jämfört med Application Insights SDK:er, inklusive:

• Bättre standardisering mellan plattformar
• Ett bredare ekosystem av instrumentationsbibliotek
• Större flexibilitet vid insamling och bearbetning av data
• Förbättrad leverantörsneutralitet, även om Azure Monitor OpenTelemetry Distro fortfarande är optimerat för Azure.

Azure Monitors OpenTelemetry-integrering utvecklas kontinuerligt och Microsoft fortsätter att förbättra sina funktioner. Om du överväger en övergång bör du noggrant utvärdera om OpenTelemetry för närvarande uppfyller dina observerbarhetskrav eller om Application Insights SDK fortfarande passar bättre för dina behov.

När ska jag använda Azure Monitor OpenTelemetry-exportören?

För ASP.NET Core, Java, Node.js och Python rekommenderar vi att du använder Azure Monitor OpenTelemetry Distro. En rad kod är allt som behövs för att börja.

För alla andra .NET-scenarier, inklusive klassiska ASP.NET, konsolappar, Windows Forms (WinForms) osv. rekommenderar vi att du använder .NET Azure Monitor OpenTelemetry-exportören: Azure.Monitor.OpenTelemetry.Exporter.

För mer komplexa Python-telemetriscenarier som kräver avancerad konfiguration rekommenderar vi att du använder Python Azure Monitor OpenTelemetry Exporter.

Vad är det aktuella versionstillståndet för funktioner i Azure Monitor OpenTelemetry Distro?

Följande diagram delar upp funktionsstöd för OpenTelemetry för varje språk.

Egenskap	.NÄT	Node.js	python	Java
Distribuerad spårning	✅	✅	✅	✅
Anpassade mått	✅	✅	✅	✅
Standardmått	✅	✅	✅	✅
Sampling med fast frekvens	✅	✅	✅	✅
Offlinelagring och automatiska återförsök	✅	✅	✅	✅
Undantagsrapportering	✅	✅	✅	✅
Loggsamling	✅	⚠️	✅	✅
Anpassade händelser	⚠️	⚠️	⚠️	✅
Microsoft Entra-autentisering	✅	✅	✅	✅
Livemätningar	✅	✅	✅	✅
Filtrering av direkta mått	✅	❌	❌	❌
Identifiera resurskontext för virtuell dator/VMSS och App Service	✅	❌	✅	✅
Identifiera resurskontext för Azure Kubernetes Service (AKS) och Functions	❌	❌	❌	✅
Händelser för tillgänglighetstestning som genereras med hjälp av API:et Spåra tillgänglighet	❌	❌	❌	✅
Filtrera begäranden, beroenden, loggar och undantag efter anonymt användar-ID och syntetisk källa	❌	❌	❌	✅
Filtrera beroenden, loggar och undantag efter åtgärdsnamn	❌	❌	❌	✅
Adaptiv provtagning	❌	❌	❌	✅
.NET Profiler	⚠️	❌	❌	⚠️
Felsökningsprogram för ögonblicksbilder	❌	❌	❌	❌

Nyckel

• ✅ Den här funktionen är tillgänglig för alla kunder med formell support.
• ⚠️ Den här funktionen är tillgänglig som en offentlig förhandsversion. Se Kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.
• ❌ Den här funktionen är inte tillgänglig eller är inte tillämplig.

Kan OpenTelemetry användas för webbläsare?

Ja, men vi rekommenderar det inte och Azure stöder det inte. OpenTelemetry JavaScript är mycket optimerat för Node.js. I stället rekommenderar vi att du använder Application Insights JavaScript SDK.

När kan vi förvänta oss att OpenTelemetry SDK ska vara tillgängligt för användning i webbläsare?

OpenTelemetry-webb-SDK:t har ingen fastställd tillgänglighetstidslinje. Vi är förmodligen flera år från en webbläsar-SDK som är ett genomförbart alternativ till Application Insights JavaScript SDK.

Kan jag testa OpenTelemetry i en webbläsare idag?

OpenTelemetry-webbsandlådan är en förgrening som utformats för att få OpenTelemetry att fungera i en webbläsare. Det går ännu inte att skicka telemetri till Application Insights. SDK:t definierar inte allmänna klienthändelser.

Stöds application insights tillsammans med konkurrerande agenter som AppDynamics, DataDog och NewRelic?

Den här metoden är inte något som vi planerar att testa eller stödja, även om våra distributioner gör att du kan exportera till en OTLP-slutpunkt tillsammans med Azure Monitor samtidigt.

Kan jag använda förhandsversionsfunktioner i produktionsmiljöer?

Vi rekommenderar det inte. Se Kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.

Vad är skillnaden mellan manuell och automatisk instrumentering?

Se Översikt över OpenTelemetry.

Kan jag använda OpenTelemetry Collector?

Vissa kunder använder OpenTelemetry Collector som ett agentalternativ, även om Microsoft inte officiellt stöder en agentbaserad metod för programövervakning ännu. Under tiden bidrog communityn med öppen källkod med en OpenTelemetry Collector Azure Monitor-exportör som vissa kunder använder för att skicka data till Azure Monitor Application Insights. Detta stöds inte av Microsoft.

Vad är skillnaden mellan OpenCensus och OpenTelemetry?

OpenCensus är föregångaren till OpenTelemetry. Microsoft hjälpte till att samla OpenTracing och OpenCensus för att skapa OpenTelemetry, en enda observerbarhetsstandard för världen. Den aktuella produktionsrekommenderade Python SDK för Azure Monitor är baserad på OpenCensus. Microsoft har åtagit sig att göra Azure Monitor baserat på OpenTelemetry.

I Grafana, varför ser jag "Status 500. Kan du inte visualisera spårningshändelser med hjälp av spårningsvisualiseraren?

Du kan försöka visualisera råa textloggar i stället för OpenTelemetry-spårningar.

I Application Insights lagrar tabellen Spårningar råtextloggar för diagnostiska ändamål. De hjälper dig att identifiera och korrelera spårningar som är associerade med användarbegäranden, andra händelser och undantagsrapporter. Tabellen Spårningar bidrar dock inte direkt till transaktionsvyn från slutpunkt till slutpunkt (vattenfallsdiagram) i visualiseringsverktyg som Grafana.

I och med det växande införandet av molnbaserade metoder finns det en utveckling inom insamling och terminologi för telemetri. OpenTelemetry blev en standard för insamling och instrumentering av telemetridata. I det här sammanhanget fick termen "Traces" en ny betydelse. I stället för råloggar refererar "Traces" i OpenTelemetry till en mer omfattande, strukturerad form av telemetri som innehåller intervall, som representerar enskilda arbetsenheter. Dessa intervall är avgörande för att skapa detaljerade transaktionsvyer, vilket möjliggör bättre övervakning och diagnostik av molnbaserade program.

Hur ska jag instrumentera Blazor Apps?

Om du vill instrumentera en Blazor-app identifierar du först värdmodellen. Blazor Server stöder fullständig OpenTelemetry-baserad instrumentation. Blazor WebAssembly körs i webbläsaren och stöder begränsad instrumentering via JavaScript.

Var kan jag få mer information om Support och feedback om OpenTelemetry?

Mer information finns i OpenTelemetry Support och Feedback för Application Insights.

Översiktsinstrumentpanel

Kan jag visa mer än 30 dagars data?

Nej, det finns en gräns på 30 dagars data som visas på en instrumentpanel.

Jag ser felet "resursen hittades inte" på instrumentpanelen.

Ett "resurs hittades inte"-fel kan inträffa om du flyttar eller byter namn på Application Insights-instansen.

Om du vill kringgå det här beteendet tar du bort standardinstrumentpanelen och väljer Programinstrumentpanel igen för att återskapa en ny.

Var kan jag få mer information om instrumentpanelen Översikt?

Mer information finns i Application Insights Översiktsöversiktspanel.

Telemetrikanaler

Garanterar Application Insights-kanalen leverans av telemetri? Om inte, vilka är de scenarier där telemetri kan gå förlorad?

Det korta svaret är att ingen av de inbyggda kanalerna erbjuder en transaktionstypgaranti för telemetrileverans till serverdelen. ServerTelemetryChannel är mer avancerat jämfört med InMemoryChannel för tillförlitlig leverans, men det gör också bara ett bästa försök att skicka telemetri. Telemetri kan fortfarande gå förlorad i flera situationer, inklusive följande vanliga scenarier:

• Objekt i minnet går förlorade när programmet kraschar.
• Telemetri går förlorad under längre perioder av nätverksproblem. Telemetri lagras på lokal disk under nätverksfel eller när problem uppstår med Application Insights-serverdelen. Objekt som är äldre än 48 timmar tas dock bort.
• Standarddiskplatserna för lagring av telemetri i Windows är %LOCALAPPDATA% eller %TEMP%. Dessa platser är vanligtvis lokala för datorn. Om programmet migreras fysiskt från en plats till en annan går all telemetri som lagras på den ursprungliga platsen förlorad.
• I Azure Web Apps i Windows är standardplatsen för disklagring D:\local\LocalAppData. Den här platsen finns inte kvar. Den rensas vid omstarter av appar, skalningsåtgärder och andra liknande åtgärder, vilket leder till förlust av telemetri som förvaras där. Du kan åsidosätta standardinställningen och ange lagring till en bevarad plats som D:\home. Sådana bevarade platser hanteras dock av fjärrlagring och kan därför vara långsamma.

Även om det är mindre troligt är det också möjligt att kanalen kan orsaka dubbletter av telemetridata. Det här beteendet inträffar när ServerTelemetryChannel gör ett nytt försök på grund av nätverksfel eller en timeout, när telemetridata levererades till serverdelen men svaret gick förlorat på grund av nätverksproblem eller tidsgränsen nåddes.

Fungerar ServerTelemetryChannel på andra system än Windows?

Även om namnet på paketet och namnområdet innehåller "WindowsServer" stöds den här kanalen på andra system än Windows, med följande undantag. På andra system än Windows skapar kanalen inte en lokal lagringsmapp som standard. Du måste skapa en lokal lagringsmapp och konfigurera kanalen så att den används. När lokal lagring har konfigurerats fungerar kanalen på samma sätt på alla system.

Anmärkning

Med version 2.15.0-beta3 och senare skapas nu lokal lagring automatiskt för Linux, Mac och Windows. För icke-Windows-system skapar SDK automatiskt en lokal lagringsmapp baserat på följande logik:

• ${TMPDIR}: Om ${TMPDIR} miljövariabeln har angetts används den här platsen.
• /var/tmp: Om den tidigare platsen inte finns försöker vi /var/tmp.
• /tmp: Om de tidigare platserna båda inte finns, försöker vi tmp.
• Om ingen av dessa platser finns skapas inte lokal lagring och manuell konfiguration krävs fortfarande. Fullständig implementeringsinformation finns i den här GitHub-lagringsplatsen.

Skapar SDK:et tillfällig lokal lagring? Krypteras data i lagringen?

SDK lagrar telemetriobjekt i lokal lagring vid nätverksproblem eller vid begränsad bandbredd. Dessa data krypteras inte lokalt.

För Windows-system skapar SDK automatiskt en tillfällig lokal mapp i katalogen %TEMP% eller %LOCALAPPDATA% och begränsar åtkomsten till administratörer och endast den aktuella användaren.

För andra system än Windows skapas ingen lokal lagring automatiskt av SDK:n, så inga data lagras lokalt som standard.

Anmärkning

Med version 2.15.0-beta3 och senare skapas nu lokal lagring automatiskt för Linux, Mac och Windows.

Du kan skapa en lagringskatalog själv och konfigurera kanalen så att den används. I det här fallet ansvarar du för att säkerställa att katalogen skyddas. Läs mer om dataskydd och sekretess.

Var kan jag få mer information om telemetrikanaler?

Mer information finns i Telemetrikanaler i Application Insights.

Transaktionssökning

Hur mycket data behålls?

Se sammanfattningen av gränser.

Hur kan jag se POST-data i mina serverbegäranden?

Vi loggar inte POST-data automatiskt, men du kan använda TrackTrace eller logganrop. Placera POST-data i meddelandeparametern. Du kan inte filtrera meddelandet på samma sätt som du kan filtrera efter egenskaper, men storleksgränsen är längre.

Varför returnerar min Azure-funktionssökning inga resultat?

Azure Functions loggar inte URL-frågesträngar.

Var kan jag få mer information om transaktionssökning?

Mer information finns i Transaktionssökning och diagnostik.

Transaktionsdiagnostik

Varför ser jag en enskild komponent i diagrammet och de andra komponenterna visas bara som externa beroenden utan någon information?

Möjliga orsaker:

• Instrumenteras de andra komponenterna med Application Insights?
• Använder de den senaste stabila Application Insights-SDK:en?
• Om dessa komponenter är separata Application Insights-resurser kontrollerar du att du har åtkomst. Om du har åtkomst och komponenterna är instrumenterade med de senaste Application Insights SDK:erna meddelar du oss via feedbackkanalen i det övre högra hörnet.

Jag ser duplicerade rader för beroendena. Förväntas det här beteendet?

För närvarande visar vi det utgående beroendeanropet separat från den inkommande begäran. Vanligtvis ser de två anropen identiska ut med bara varaktighetsvärdet som skiljer sig på grund av nätverkets tur och retur-resa. Den inledande ikonen och distinkt formatering av varaktighetsstaplarna hjälper till att skilja mellan dem. Är den här presentationen av data förvirrande? Ge oss din feedback!

Hur är det med klockförskjutningar mellan olika komponentinstanser?

Tidslinjer justeras för klocksnedvridningar i transaktionsdiagrammet. Du kan se exakta tidsstämplar i informationsfönstret eller med hjälp av Log Analytics.

Varför saknas de flesta relaterade objektfrågor i den nya upplevelsen?

Det här beteendet är avsiktligt. Alla relaterade objekt, över alla komponenter, är redan tillgängliga på vänster sida i de övre och nedre avsnitten. Den nya upplevelsen har två relaterade objekt som den vänstra sidan inte täcker: all telemetri från fem minuter före och efter den här händelsen och användarens tidslinje.

Finns det något sätt att se färre händelser per transaktion när jag använder Application Insights JavaScript SDK?

Transaktionsdiagnostikupplevelsen visar all telemetri i en enda åtgärd som delar ett åtgärds-ID. Som standard skapar Application Insights SDK för JavaScript en ny åtgärd för varje unik sidvy. I ett ensidesprogram (SPA) genereras endast en sidvisningshändelse och ett enda åtgärds-ID används för all telemetri som genereras. Därför kan många händelser korreleras till samma åtgärd.

I dessa scenarier kan du använda Automatisk routningsspårning för att automatiskt skapa nya åtgärder för navigering i ditt SPA. Du måste aktivera enableAutoRouteTracking så att en sidvy genereras varje gång URL-vägen uppdateras (logisk sidvy inträffar). Om du vill uppdatera åtgärds-ID:t manuellt anropar du appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Om du utlöser en PageView-händelse manuellt återställs även åtgärds-ID:t.

Varför summerar inte varaktigheten för transaktionsinformationen till varaktigheten för den högsta begärandetiden?

Tid som inte förklaras i Gantt-schemat är tid som inte omfattas av ett spårat beroende. Det här problemet kan inträffa eftersom externa anrop inte har instrumenterats, antingen automatiskt eller manuellt. Det kan också inträffa eftersom den tid som användes var en del av processen snarare än på grund av ett externt samtal.

Om alla anrop har instrumenterats är processen den troliga rotorsaken till den tid som spenderas. Ett användbart verktyg för att diagnostisera processen är .NET Profiler.

Vad händer om jag ser meddelandet "Fel vid hämtning av data" när jag navigerar i Application Insights i Azure-portalen?

Det här felet indikerar att webbläsaren inte kunde anropa ett obligatoriskt API, eller att API:et returnerade ett felsvar. Om du vill felsöka beteendet öppnar du ett webbläsarfönster i InPrivate och inaktiverar alla webbläsartillägg som körs och identifierar sedan om du fortfarande kan återskapa portalbeteendet. Om portalfelet fortfarande inträffar kan du testa med andra webbläsare eller andra datorer, undersöka DNS eller andra nätverksrelaterade problem från klientdatorn där API-anropen misslyckas. Om portalfelet fortsätter och behöver undersökas mer samlar du in en nätverksspårning i webbläsaren samtidigt som du återskapar det oväntade portalbeteendet och öppnar sedan ett supportärende från Azure Portal.

Var kan jag få mer information om transaktionsdiagnostik?

Mer information finns i Transaktionssökning och diagnostik.

Användningsanalys

Representerar den första händelsen första gången händelsen visas i en session eller när den visas i en session?

Den första händelsen i visualiseringen representerar bara första gången en användare skickade sidvyn eller den anpassade händelsen under en session. Om användarna kan skicka den första händelsen flera gånger i en session visar kolumnen Steg 1 bara hur användare beter sig efter den första instansen av en första händelse, inte alla instanser.

Vissa av noderna i min visualisering har en nivå som är för hög. Hur får jag mer detaljerade noder?

Använd alternativen Dela upp efter på redigera-menyn:

1. Välj den händelse som du vill dela upp på menyn Händelse .

2. Välj en dimension på menyn Dimension . Om du till exempel har en händelse med namnet Knapp klickad kan du prova en anpassad egenskap med namnet Knappnamn.

Jag definierade en kohort av användare från ett visst land/en viss region. Varför ser jag olika resultat när jag jämför den här kohorten i verktyget Användare med att ange ett filter för det landet/regionen?

Kohorter och filter skiljer sig. Anta att du har en kohort av användare från Storbritannien (definieras som i föregående exempel) och jämför resultatet med att ange filtret Country or region = United Kingdom:

• Kohortversionen visar alla händelser från användare som skickade en eller flera händelser från Storbritannien inom det aktuella tidsintervallet. Om du delar upp efter land eller region ser du förmodligen många länder och regioner.

• Filterversionen visar endast händelser från Storbritannien. Om du delar upp efter land eller region ser du bara Storbritannien.

Hur gör jag för att visa data med olika korn (varje dag, varje månad eller varje vecka)?

Du kan välja filtret Datumintervall för att ändra kornigheten. Filtret är tillgängligt på alla dimensionsflikar.

Hur gör jag för att få åtkomst till insikter från mitt program som inte är tillgängliga i HEART-arbetsböckerna?

Du kan utforska datan som finns i HEART-arbetsboken om de visuella elementen inte svarar på alla dina frågor. För att utföra den här uppgiften går du till avsnittet Övervakning i Application Insights och väljer Loggar och frågar tabellen customEvents . Några av click analytics-attributen finns i fältet customDimensions .

En exempelfråga visas här:

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

Mer information om loggar i Azure Monitor finns i Översikt över Azure Monitor-loggar.

Kan jag redigera visuella objekt i arbetsboken?

Ja. Information om hur du redigerar arbetsboksmallar finns i Mallar för Azure-arbetsböcker.

Var kan jag få mer information om användningsanalys?

Mer information finns i Användningsanalys med Application Insights.

Arbetstjänstprogram

Vilket paket ska jag använda?

.NET Core-appscenario	Paket
Utan värdtjänster	WorkerService
Med HostedServices	AspNetCore (inte WorkerService)
Med HostedServices övervakar du endast HostedServices	WorkerService (sällsynt scenario)

Kan HostedServices i en .NET Core-app med hjälp av AspNetCore-paketet få TelemetryClient inmatat i den?

Ja, konfigurationen delas med resten av webbprogrammet.

Hur kan jag spåra telemetri som inte samlas in automatiskt?

Hämta en instans av med hjälp av TelemetryClient konstruktorinmatning och anropa den metod som krävs TrackXXX() för den. Vi rekommenderar inte att du skapar nya TelemetryClient instanser. En singleton-instans av TelemetryClient är redan registrerad i containern DependencyInjection , som delar TelemetryConfiguration med resten av telemetrin. Att skapa en ny TelemetryClient instans rekommenderas endast om den behöver en konfiguration som är separat från resten av telemetrin.

Kan jag använda Visual Studio IDE för att registrera Application Insights i ett Worker Service-projekt?

Visual Studio IDE-registrering stöds för närvarande endast för ASP.NET/ASP.NET Core-program. Det här dokumentet uppdateras när Visual Studio har stöd för registrering av Worker Service-program.

Kan jag aktivera Application Insights-övervakning med hjälp av verktyg som Azure Monitor Application Insights Agent (tidigare Status Monitor v2)?

Nej. Azure Monitor Application Insights Agent stöder för närvarande endast .NET .

Stöds alla funktioner om jag kör mitt program i Linux?

Ja. Funktionsstöd för denna SDK är detsamma på alla plattformar, med följande undantag:

• Prestandaräknare stöds endast i Windows förutom process-CPU/minne som visas i live-mått.

• Även om ServerTelemetryChannel är aktiverat som standard, om programmet körs i Linux eller macOS, skapar kanalen inte automatiskt en lokal lagringsmapp för att behålla telemetri tillfälligt om det finns nätverksproblem. På grund av den här begränsningen går telemetri förlorad när det finns tillfälliga nätverk eller serverproblem. Du kan undvika det här problemet genom att konfigurera en lokal mapp för kanalen:

  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();
       }
  

Var kan jag få mer information om Worker Service-program?

Mer information finns i Application Insights för Worker Service-program (icke-HTTP-program).

Vanliga frågor och svar om Azure Monitor Application Insights. Hitta svar på frågor om hur du använder Application Insights med Azure Monitor.

Detaljerad information om instrumentering av program för att aktivera Application Insights finns i grunderna för datainsamling.

När du har aktiverat Application Insights genom att instrumentera ett program rekommenderar vi att du först tittar på Live-metrik och Programkartan.

Från serverbaserade webbappar:

• HTTP-begäranden.
• Beroenden. Anrop till SQL-databaser, HTTP-anrop till externa tjänster, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage och Azure Queue Storage.
• Undantag och stackspårningar.
• Prestandaräknare: Prestandaräknare är tillgängliga när du använder:
  • Azure Monitor Application Insights-agent
  • Azure-övervakning för virtuella datorer eller VM-skalningsuppsättningar
  • Application Insights-författarecollectd.
• Anpassade händelser och mått som du kodar .
• Loggar kan spåras om du konfigurerar rätt insamlare.

Från klientwebbsidor:

• Ohanterade undantag i din app, inklusive information om

  • Stackspårning
  • Undantagsinformation och meddelande som medföljer felet
  • Rad- och kolumnnummer för fel
  • URL där felet uppstod
  • Begäranden för nätverksberoende som görs av din app via XML Http Request (XHR) och Fetch (hämtning är inaktiverad som standard) innehåller information om:
    • Url för beroendekälla
    • Kommando & metod som används för att begära beroendet
    • Varaktighet för begäran
    • Resultatkod och status för lyckad begäran
    • ID (om något) för användare som gör begäran
    • Korrelationskontext (om någon) där begäran görs

• Användarinformation (till exempel Plats, nätverk, IP)

• Enhetsinformation (till exempel webbläsare, operativsystem, version, språk, modell)

• Sessionsinformation

  Anmärkning

  För vissa program, till exempel ensidesprogram (SPA) registreras inte alltid varaktigheten och i dessa fall är standardvärdet 0.

  Mer information finns i Datainsamling, kvarhållning och lagring i Application Insights.

Från andra källor, om du konfigurerar dem:

• Azure-diagnostik
• Importera till Log Analytics
• Log Analytics
• Logstash

Information om hur många Application Insights-resurser som krävs för att täcka ditt program eller komponenter i olika miljöer finns i planeringsguiden för Application Insights-distribution.

Du kan skriva PowerShell-skript med hjälp av Azure Resource Monitor för att:

• Skapa och uppdatera Application Insights-resurser.
• Ange prisplanen.
• Hämta instrumentationsnyckeln.
• Lägg till en måttavisering.
• Lägg till ett tillgänglighetstest.

Du kan inte konfigurera en metrics explorer-rapport eller konfigurera kontinuerlig export.

Använd REST-API:et för att köra Log Analytics-frågor.

Vi rekommenderar Azure Monitor OpenTelemetry Distro.

Inmatningsschemat och slutpunktsprotokollet är tillgängliga offentligt.

De flesta Application Insights-data har en svarstid på under 5 minuter. Vissa data kan ta längre tid, vilket är typiskt för större loggfiler. Se Servicenivåavtalet för Application Insights.

Samling

Application Insights samlar in telemetri om din app, inklusive webbservertelemetri, webbsidestelemetri och prestandaräknare. Dessa data kan användas för att övervaka appens prestanda, hälsa och användning. Du kan välja plats när du skapar en ny Application Insights-resurs.

Kvarhållning och lagring

Data skickas till en Application Insights Log Analytics-arbetsyta. Du kan välja kvarhållningsperioden för rådata från 30 till 730 dagar. Aggregerade data bevaras i 90 dagar och ögonblicksbilder för felsökning behålls i 15 dagar.

Privatliv

Application Insights hanterar inte känsliga data som standard. Vi rekommenderar att du inte placerar känsliga data i URL:er som oformaterad text och ser till att din anpassade kod inte samlar in personlig eller annan känslig information. Under utveckling och testning kontrollerar du skickade data i din IDE och webbläsarens felsökningsutdatafönster.

Arkiverad information finns i Datainsamling, kvarhållning och lagring i Application Insights.

Application Insights faktureras via Log Analytics-arbetsytan där loggdata matas in. Standardprisnivån Betala per användning i Log Analytics innehåller 5 GB per månad med kostnadsfri dataersättning per faktureringskonto. Läs mer om prisalternativ för Azure Monitor-loggar.

• Om din Azure-webbapp finns i ett datacenter där det finns en Application Insights-samlingsslutpunkt debiteras ingen kostnad.
• Om det inte finns någon samlingsslutpunkt i värdcentret medför appens telemetri utgående avgifter för Azure.

Det här svaret beror på fördelningen av våra slutpunkter, inte på var Application Insights-resursen finns.

Ja, du kan medföra fler nätverkskostnader, som varierar beroende på vilken region telemetrin kommer från och vart den är på väg. Mer information finns i Prissättning för Azure-bandbredd .

Om du ser oväntade avgifter eller höga kostnader i Application Insights kan den här guiden hjälpa dig. Den omfattar vanliga orsaker som hög telemetrivolym, datainmatningstoppar och felkonfigurerad sampling. Det är särskilt användbart om du felsöker problem som rör kostnadstoppar, telemetrivolym, sampling som inte fungerar, datatak, hög inmatning eller oväntad fakturering. Information om hur du kommer igång finns i Felsöka hög datainmatning i Application Insights.

Application Insights använder TLS (Transport Layer Security) 1.2 och 1.3.

Viktigt!

Den 1 mars 2025 drar Azure tillbaka äldre versioner av TLS i alla tjänster. Då stöder Application Insights inte längre TLS 1.0, TLS 1.1 och de angivna äldre TLS 1.2/1.3-chiffersviterna och elliptiska kurvorna.

Allmänna frågor om det äldre TLS-problemet finns i Lösa TLS-problem och Azure Resource Manager TLS-support.

Mer information finns i Introduktion till Application Insights.

Båda TelemetryChannels förlorar buffrad telemetri om den inte töms innan ett program stängs av.

För att undvika dataförlust rensar du TelemetryClient när ett program stängs av.

Mer information finns i Rensa data.

Ingen. Du behöver inte omsluta dem i try-catch-satser. Om SDK:et stöter på problem loggar det meddelanden i felsökningskonsolens utdata och, om meddelandena kommer igenom, i Diagnostiksökning.

Ja, API:et för dataåtkomst. Andra sätt att extrahera data är Power BI på arbetsytebaserade resurser.

Application Insights SDK är inte kompatibelt med autoinstrumentation. Om autoinstrumentering är aktiverad kommer anrop till Track() och andra anpassade händelser och metrik-API:er att ignoreras.

Inaktivera automatisk instrumentering i Azure Portal på fliken Application Insights på App Service-sidan eller ange ApplicationInsightsAgent_EXTENSION_VERSION till disabled.

Sampling minskar antalet telemetriobjekt (till exempel begäranden och anpassade händelser) som skickas från din app till portalen. I Sök ser du antalet mottagna objekt. I måttdiagram som visar antalet händelser ser du antalet ursprungliga händelser som har inträffat.

Varje objekt som överförs har en itemCount egenskap som visar hur många ursprungliga händelser som objektet representerar. Om du vill observera sampling i drift kan du köra den här frågan i Log Analytics:

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

Azure-aviseringar gäller endast mått. Skapa ett anpassat mått som överskrider ett värdetröskelvärde när händelsen inträffar. Ange sedan en avisering för måttet. Du får ett meddelande när måttet överskrider tröskelvärdet i båda riktningarna. Du får inget meddelande förrän den första korsningen, oavsett om det ursprungliga värdet är högt eller lågt. Det finns alltid en svarstid på några minuter.

Mer information finns i Application Insights API för anpassade händelser och mått.

Ja. Det finns flera sätt att ladda ned Application Insights Agent:

• Om datorn har internetåtkomst kan du registrera dig för PowerShell-galleriet med hjälp -Proxy av parametrar.
• Du kan också ladda ned modulen manuellt och antingen installera den på datorn eller använda den direkt.

Vart och ett av dessa alternativ beskrivs i de detaljerade anvisningarna.

Ja. I Application Insights Agent 2.0.0 och senare stöds ASP.NET Core-program som finns i IIS.

• Du kan använda cmdleten Get-ApplicationInsightsMonitoringStatus för att kontrollera att aktiveringen lyckades.

• Använd Live Metrics för att snabbt avgöra om din app skickar telemetri.

• Du kan också använda Log Analytics för att lista alla molnroller som för närvarande skickar telemetri:

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

För att uppnå proxygenomströmning konfigurerar du en proxy på datornivå eller en proxy på programnivå. Se DefaultProxy.

Exempel på Web.config:

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

Mer information finns i Distribuera Application Insights Agent för lokala servrar.

Application Insights och Azure Monitor styr inte den TLS-version som används för HTTPS-anslutningar. TLS-versionen är beroende av operativsystemet och körningsmiljön där programmet körs.

Så här bekräftar du den TLS-version som används:

• Läs dokumentationen för ditt operativsystem och din körmiljö eller ditt ramverk.
• Kontakta lämpligt supportteam om du behöver ytterligare hjälp. Öppna inte en supportbegäran med Application Insights.

Exempel på språk- och körningsstöd för TLS 1.2+

Följande versioner innehåller integrerat stöd för TLS 1.2 eller senare:

• .NET/.NET Core: .NET Framework 4.6.2 eller senare och alla versioner av .NET Core
• Java: Java 8 update 161 (8u161) eller senare
• Python: Python-distributioner som skapats med OpenSSL 1.0.1 eller senare
• Node.js: Node.js version 10 eller senare

Exempel på operativsystemstöd för TLS 1.2+

Följande operativsystem innehåller integrerat stöd för TLS 1.2 eller senare:

• Windows: Windows 8, Windows Server 2012 och senare
• Linux: De flesta moderna Linux-distributioner som använder OpenSSL 1.0.1 eller senare

För att undvika avbrott i tjänsten bör varje fjärrslutpunkt, inklusive beroende begäranden, som din resurs interagerar med stödja minst en kombination av samma protokollversion, chiffersvit och elliptisk kurva som nämndes tidigare. Om fjärrslutpunkten inte stöder den nödvändiga TLS-konfigurationen måste den uppdateras med stöd för någon kombination av TLS-konfigurationen efter utfasningen.

Berörda Application Insights-resurser slutar mata in data och kan inte komma åt nödvändiga programkomponenter. Därför slutar vissa funktioner att fungera.

TLS-utfasningen (Transport Layer Security) som beskrivs i det här dokumentet bör endast påverka beteendet efter den 1 maj 2025. Mer information om CRUD-åtgärder finns i Azure Resource Manager TLS-support. Den här resursen ger mer information om TLS-stöd och avvecklingstidslinjer.

För generella frågor om problemen med det äldre TLS, se Lösa TLS-problem.

Mer information finns i TLS-stöd.

Om du vill ta bort Application Insights måste du ta bort NuGet-paketen och referenserna från API:et i ditt program. Du kan avinstallera NuGet-paket med hjälp av NuGet Package Manager i Visual Studio.

1. Om spårningssamlingen är aktiverad avinstallerar du först paketet Microsoft.ApplicationInsights.TraceListener med hjälp av NuGet Package Manager men tar inte bort några beroenden.
2. Avinstallera Microsoft.ApplicationInsights.Web-paketet och ta bort dess beroenden med hjälp av NuGet Package Manager och dess avinstallationsalternativ i kontrollen Alternativ för NuGet Package Manager.
3. Om du vill ta bort Application Insights helt kontrollerar och tar du bort den tillagda koden eller filerna manuellt tillsammans med eventuella API-anrop som du har lagt till i projektet. Mer information finns i Vad skapas automatiskt när du lägger till Application Insights SDK?.

När du lägger till Application Insights i projektet skapas automatiskt filer och kod läggs till i några av dina filer. Att bara avinstallera NuGet-paketen tar inte alltid bort filerna och koden. Om du vill ta bort Application Insights helt bör du kontrollera och manuellt ta bort den tillagda koden eller filerna tillsammans med eventuella API-anrop som du har lagt till i projektet.

När du lägger till Application Insights-telemetri i ett Visual Studio-ASP.NET projekt lägger det till följande filer:

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

Följande kodstycken läggs automatiskt till:

• [Projektets namn].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

  Om projektet har en Layout.cshtml-fil läggs följande kod till.

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

• ConnectedService.json

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

• FilterConfig.cs

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

Information om hur du inaktiverar telemetrikorrelation i konfigurationen <ExcludeComponentCorrelationHttpHeadersOnDomains> finns i Application Insights för konsolprogram.

Mer information finns i Konfigurera Application Insights för din ASP.NET webbplats.

ASP.NET Core 3.1 stöds inte längre av Microsoft.

Application Insights SDK för ASP.NET Core version 2.8.0 och Visual Studio 2019 eller senare kan användas med ASP.NET Core 3.1-program.

Hämta en instans av med hjälp av TelemetryClient konstruktorinmatning och anropa den metod som krävs TrackXXX() för den. Vi rekommenderar inte att du skapar nya TelemetryClient eller TelemetryConfiguration instanser i ett ASP.NET Core-program. En singleton-instans av TelemetryClient är redan registrerad i containern DependencyInjection , som delar TelemetryConfiguration med resten av telemetrin. Skapa bara en ny TelemetryClient instans om den behöver en konfiguration som är separat från resten av telemetrin.

I följande exempel visas hur du spårar mer telemetri från en styrenhet.

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();
    }
}

Mer information om anpassad datarapportering i Application Insights finns i API-referens för anpassade mått för Application Insights. En liknande metod kan användas för att skicka anpassade mått till Application Insights med hjälp av GetMetric API.

ASP.NET Core har inbyggt stöd för loggning av HTTP-begäran/svarsinformation (inklusive brödtext) via ILogger. Vi rekommenderar att du använder detta. Detta kan potentiellt exponera personligt identifierbar information (PII) i telemetri och kan leda till att kostnaderna (prestandakostnader och Application Insights-fakturering) ökar avsevärt, så utvärdera riskerna noggrant innan du använder detta.

Standardinställningen för Application Insights är att endast samla in varningsloggar och allvarligare loggar.

Samla in information och mindre allvarliga loggar genom att ändra loggningskonfigurationen för Application Insights-providern på följande sätt.

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

Observera att följande exempel inte gör att Application Insights-providern samlar in Information loggar. Den samlar inte in den eftersom SDK lägger till ett standardfilter för loggning som instruerar ApplicationInsights att endast samla Warning loggar och mer allvarliga loggar. Application Insights kräver en explicit åsidosättning.

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

Mer information finns i ILogger-konfiguration.

Tilläggsmetoden UseApplicationInsights() stöds fortfarande, men den är markerad som föråldrad i Application Insights SDK version 2.8.0 och senare. Den tas bort i nästa huvudversion av SDK: et. Om du vill aktivera Application Insights-telemetri använder du AddApplicationInsightsTelemetry() eftersom det ger överlagringar för att styra viss konfiguration. I ASP.NET Core 3.X-appar services.AddApplicationInsightsTelemetry() är det också det enda sättet att aktivera Application Insights.

Om SDK:t installeras vid byggtiden enligt den här artikeln behöver du inte aktivera Application Insights-tillägget från App Service-portalen. Om tillägget är installerat säkerhetskopieras det när det identifierar att SDK redan har lagts till. Om du aktiverar Application Insights från tillägget behöver du inte installera och uppdatera SDK:t. Men om du aktiverar Application Insights genom att följa anvisningarna i den här artikeln har du större flexibilitet eftersom:

• Application Insights-telemetrin fortsätter att fungera i:
  • Alla operativsystem, inklusive Windows, Linux och Mac.
  • Alla publiceringslägen, inklusive fristående lägen eller ramverksberoende.
  • Alla målramverk, inklusive hela .NET Framework.
  • Alla värdalternativ, inklusive webbappar, virtuella datorer, Linux, containrar, AKS och icke-Azure-värdtjänster.
  • Alla .NET Core-versioner, inklusive förhandsversioner.
• Du kan se telemetri lokalt när du felsöker från Visual Studio.
• Du kan spåra mer anpassad telemetri med hjälp av API:et TrackXXX() .
• Du har fullständig kontroll över konfigurationen.

Ja. I Application Insights Agent 2.0.0-beta1 och senare stöds ASP.NET Core-program som finns i IIS.

Ja. Funktionsstöd för SDK är detsamma på alla plattformar, med följande undantag:

• SDK:et samlar in händelseräknare i Linux eftersom prestandaräknare endast stöds i Windows. De flesta mått är desamma.

Nej. Använd i stället Application Insights för Worker Service-program (icke-HTTP-program) för arbetstjänster.

Om du vill ta bort Application Insights måste du ta bort NuGet-paketen och referenserna från API:et i ditt program. Du kan avinstallera NuGet-paket med hjälp av NuGet Package Manager i Visual Studio.

Anmärkning

De här anvisningarna är till för att avinstallera ASP.NET Core SDK. Om du behöver avinstallera ASP.NET SDK läser du Hur kan jag avinstallera ASP.NET SDK?.

1. Avinstallera Paketet Microsoft.ApplicationInsights.AspNetCore med hjälp av NuGet Package Manager.
2. Om du vill ta bort Application Insights helt kontrollerar och tar du bort den tillagda koden eller filerna manuellt tillsammans med eventuella API-anrop som du har lagt till i projektet. Mer information finns i Vad skapas när du lägger till Application Insights SDK?.

När du lägger till Application Insights i projektet skapas filer och kod läggs till i några av dina filer. Att bara avinstallera NuGet-paketen tar inte alltid bort filerna och koden. Om du vill ta bort Application Insights helt bör du kontrollera och manuellt ta bort den tillagda koden eller filerna tillsammans med eventuella API-anrop som du har lagt till i projektet.

När du lägger till Application Insights-telemetri i ett Visual Studio ASP.NET Core-mallprojekt lägger det till följande kod:

• [Projektets namn].csproj

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

• Appsettings.json

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

• ConnectedService.json

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

• Startup.cs

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

Information om hur du inaktiverar telemetrikorrelation i kod <ExcludeComponentCorrelationHttpHeadersOnDomains> finns i Application Insights för konsolprogram.

Mer information finns i Application Insights för ASP.NET Core.

• Exception rate: Undantagsfrekvensen är en systemprestandaräknare. CLR räknar alla hanterade och ohanterade undantag som kastas och delar sedan summan av undantagen i ett samplingsintervall med intervallets längd. Application Insights SDK samlar in det här resultatet och skickar det till portalen.
• Exceptions: Metriken 'Undantag' räknar de TrackException rapporter som tas emot av portalen under diagrammets samplingsintervall. Den innehåller endast hanterade undantag där du skriver TrackException anrop i koden. Den innehåller inte alla ohanterade undantag.

Mer information finns i Räknare för .NET i Application Insights.

Live-mätvärden visar inte EventCounters. Använd Metric Explorer eller Analytics för att se telemetrin.

Application Insights-tillägget för ASP.NET Core har ännu inte stöd för den här funktionen.

Mer information finns i Räknare för .NET i Application Insights.

Övervakning på klientsidan är aktiverat som standard för ASP.NET Core-appar. Om du vill inaktivera den definierar du en miljövariabel på servern med följande information:

• Namn:APPINSIGHTS_JAVASCRIPT_ENABLED
• Värde:false

Mer information finns i Application Insights för virtuella Azure-datorer och VM-skalningsuppsättningar.

Misslyckade beroendeanrop har success-fältet inställt på False. Modulen DependencyTrackingTelemetryModule rapporterar inte ExceptionTelemetry. Den fullständiga datamodellen för beroende beskrivs i Application Insights telemetridatamodell.

Använd den här koden:

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

I Log Analytics-frågevyn timestamp representerar det ögonblick då TrackDependency()-anropet initierades, som inträffar omedelbart efter att beroendeanropssvaret har tagits emot. Om du vill beräkna den tid då beroendeanropet började skulle du ta timestamp och subtrahera det registrerade duration beroendeanropet.

Beroendespårning i Application Insights inkluderar inte loggning av svarsdata eftersom det skulle generera för mycket telemetri för de flesta applikationer.

Mer information finns i Beroendespårning.

Tillgänglighetstester körs på närvaropunkter som är distribuerade över hela världen. Det finns två lösningar:

• Firewall door: Tillåt förfrågningar till din server från den långa och föränderliga listan över webbläsartestagenter.
• Anpassad kod: Skriv din egen kod för att skicka periodiska förfrågningar till din server från insidan av ditt intranät. Du kan köra webbaserade tester med Visual Studio för detta ändamål. Testaren skulle kunna skicka resultaten till Application Insights genom att använda TrackAvailability() API:et.

Strängen för användaragenter är Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Mer information finns i Tillgänglighetstester.

Tillgänglighetstester fungerar som en distribuerad klient i varje av de stödda webbtestplatserna. Varje gång ett webbtest körs försöker tillgänglighetstesttjänsten nå den fjärranslutningspunkt som definieras i webbtestkonfigurationen. En TLS Client Hello-meddelande skickas, vilket innehåller alla för närvarande stödda TLS-konfigurationer. Om den fjärranslutna slutpunkten delar en gemensam TLS-konfiguration med tillgänglighetstestklienten, lyckas TLS-handshake. Annars misslyckas webbtestet med ett fel vid TLS-handshake.

Det finns flera tillgängliga verktyg för att testa vilken TLS-konfiguration som en slutpunkt stöder. Ett sätt skulle vara att följa exemplet som beskrivs på den här sidan. Om din fjärranslutningspunkt inte är tillgänglig via det offentliga Internet, behöver du säkerställa att du validerar TLS-konfigurationen som stöds på fjärranslutningspunkten från en dator som har tillgång att ansluta till din anslutningspunkt.

Anmärkning

För att aktivera den nödvändiga TLS-konfigurationen på din webbserver, är det bäst att kontakta teamet som äger den hostingplattform din webbserver kör på, om processen är okänd.

Det finns ingen enda undantagstyp som alla TLS-handshakefel som påverkas av denna avveckling skulle presentera sig med. Dock är det vanligaste undantaget som ditt webbtest skulle börja misslyckas med The request was aborted: Couldn't create SSL/TLS secure channel. Du bör också kunna se eventuella TLS-relaterade fel i felsökningssteget för TLS-transport för det webbtestresultat som kan påverkas.

TLS-konfigurationen som förhandlas fram under webbstestkörning kan inte visas. Så länge den fjärranslutna slutpunkten stöder en vanlig TLS-konfiguration med tillgänglighetstester, bör ingen påverkan märkas efter att den har fasats ut.

TLS-utfasningen som beskrivs i det här dokumentet bör endast påverka körningsbeteendet för webbtillgänglighetstester efter den 1 maj 2025. För mer information om hur man interagerar med tillgänglighetstesttjänsten för CRUD-operationer, se Azure Resource Manager TLS Support. Den här resursen ger mer information om TLS-stöd och avvecklingstidslinjer.

För generella frågor om problemen med det äldre TLS, se Lösa TLS-problem.

Mer information finns i TLS-konfigurationer som stöds.

Informationen beror på typen av projekt. Följande lista är ett exempel för ett webbprogram.

• Lägger till filer i projektet:

  • ApplicationInsights.config
  • ai.js

• Installerar NuGet-paket:

  • Application Insights API: Kärn-API:et
  • Application Insights API för webbprogram: Används för att skicka telemetri från servern
  • Application Insights API för JavaScript-program: Används för att skicka telemetri från klienten

• Inkluderar samlingar i paket:

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• Infogar objekt i:

  • Web.config
  • packages.config

• Infogar kodfragment i klient- och serverkoden för att initiera dem med Application Insights-resurs-ID:t. I en MVC-app infogas till exempel kod i huvudsidan Views/Shared/_Layout.cshtml. Endast för nya projekt lägger du till Application Insights i ett befintligt projekt manuellt.

Application Insights samlar in telemetri för de begäranden som nådde fram till applikationen. Om felet inträffar i WebApps/WebServer och begäran inte nådde användarprogrammet har Application Insights ingen telemetri om det.

Varaktigheten för serverresponsetime beräknad av Application Insights matchar inte nödvändigtvis serverns svarstid som observeras av Web Apps. Det här beteendet beror på att Application Insights bara räknar varaktigheten när begäran faktiskt når användarprogrammet. Om begäran har fastnat eller placerats i kö i WebServer inkluderas väntetiden i Web Apps-måtten men inte i Application Insights-mått.

Mer information finns i Aktivera programövervakning i Azure App Service.

Vi följer Microsoft Style Guide för produktdokumentation som publicerats till Microsoft Learn-plattformen .

I allmänhet inkluderar vi inte ett bindestreck efter prefixet "auto".

Mer information finns i Vad är autoinstrumentation för Azure Monitor Application Insights?.

Om du vill ha anpassade mått i Node.jskan du manuellt instrumentera program med Azure Monitor OpenTelemetry Distro.

Java tillåter anpassade mått med autoinstrumentation. Du kan samla in anpassade mått genom att uppdatera koden och aktivera den här funktionen. Om koden redan har anpassade mått flödar de igenom när automatisk instrumentering är aktiverat.

AKS-autoinstrumentation kan störa telemetrin som skickas till tredje part av en OSS OpenTelemetry SDK.

AKS autoinstrumentation är utformad för att samexistera med båda alternativen för manuell instrumentering: den klassiska API SDK:n för Application Insights och OpenTelemetry Distro.

Det förhindrar alltid dubbletter av data och säkerställer att anpassade mått fungerar.

Se det här diagrammet för att avgöra när autoinstrumentation eller manuell instrumentering har företräde.

Språk	Företräde
Node.js	Manuell instrumentering
Java	Automatisk instrumentering

Sårbarheter som identifieras i Azure Monitor OpenTelemetry Distro prioriteras, åtgärdas och släpps i nästa version.

AKS autoinstrumentation matar in den senaste versionen av Azure Monitor OpenTelemetry Distro i dina programpoddar varje gång distributionen ändras eller startas om.

OpenTelemetry Distro kan bli sårbar för distributioner som inte ändras eller startas om under längre tidsperioder. Därför rekommenderar vi att du uppdaterar eller startar om distributioner varje vecka för att säkerställa att en ny version av distributionen används.

Den här funktionen uppnår autoinstrumentering genom att injicera Azure Monitor OpenTelemetry Distro i programpoddar.

För Java integrerar den här funktionen fristående Azure Monitor OpenTelemetry Distro för Java. Se vår Java-distributionsdokumentation för att lära dig mer om Java-instrumentationsbinärfilen.

För Node.jsinjekterar vi en autoinstrumentering-binär baserad på vår Azure Monitor OpenTelemetry Distro för Node.js. Mer information finns iNode.js distributionsdokumentation. Tänk på att vi inte har någon fristående autoinstrumentation för Node.js så vår distributionsdokumentation är inriktad på manuell instrumentering. Du kan ignorera kodbaserade konfigurationssteg som rör manuell instrumentering. Men allt annat i vår distributionsdokumentation, till exempel standardinställningar, miljövariabelkonfigurationer osv. gäller för den här funktionen.

Mer information finns i Autoinstrumentation för AKS.

Nya Azure-regioner kräver användning av anslutningssträng i stället för instrumentationsnycklar. Anslutningssträngen identifierar den resurs som du vill associera med dina telemetridata. Du kan också ändra de slutpunkter som din resurs använder som mål för telemetrin. Kopiera anslutningssträng och lägg till den i programmets kod eller i en miljövariabel.

Vi rekommenderar att du använder anslutningssträng i stället för instrumentationsnycklar.

APPLICATIONINSIGHTS_CONNECTION_STRING Ange manuellt i alla scenarier där systemet inte tillhandahåller det automatiskt. Dessa scenarier omfattar, men är inte begränsade till: lokal utveckling och .NET Isolerade funktioner med hjälp av ASP.NET Core-integrering. I dessa fall säkerställer miljövariabeln att OpenTelemetry-pipelinen kan skicka telemetri till Application Insights. Mer information om hur du konfigurerar anslutningssträngar med en miljövariabel finns i Konfigurera OpenTelemetry i Application Insights.

Om du vill uppfylla kraven för regional dataefterlevnad använder du regionala Application Insights-slutpunkter i stället för den globala slutpunkten. Den globala slutpunkten garanterar inte att data stannar inom en viss region. Regionala slutpunkter hjälper till att säkerställa att telemetri från användare i reglerade områden endast skickas till datacenter i dessa regioner.

Så här konfigurerar du ditt globala webbprogram för regional efterlevnad:

• Skapa en Application Insights-resurs per region med strikta efterlevnadskrav, till exempel EU eller USA.
• Skapa en annan Application Insights-resurs för användare i alla andra regioner.
• Konfigurera ditt program för att skicka telemetri till lämplig Application Insights-resurs baserat på varje användares region. Fastställ regionen med hjälp av signaler som IP-adress, kontometadata eller platsinställningar.
• Anslut alla Application Insights-resurser till en Log Analytics-arbetsyta om du behöver en enhetlig frågeupplevelse mellan regioner.

Till exempel:

• Skicka data från Region A-användare till resursen Region A Application Insights med hjälp av anslutningssträngen Region A.
• Skicka data från region B-användare till resursen Region B Application Insights med hjälp av anslutningssträngen Region B.
• Skicka alla andra användardata till en application insights-resurs för generell användning med en annan anslutningssträng.

Viktigt!

Att använda den globala slutpunkten säkerställer inte regional efterlevnad. Om du vill uppfylla kraven för datahemvist använder du alltid regionspecifika slutpunkter och dirigerar telemetri baserat på användarens region.

Följande diagram visar ett exempel på en konfiguration för ett globalt webbprogram:

Mer information finns i Anslutningssträngar.

Överföring av befintliga Application Insights-resurser mellan regioner stöds inte och du kan inte migrera historiska data till en ny region. Lösningen omfattar:

• Skapa en ny Application Insights-resurs i önskad region.
• Återskapa alla unika anpassningar från den ursprungliga resursen i den nya.
• Uppdatera programmet med den nya regionresursens anslutningssträng.
• Testa för att säkerställa att allt fungerar som förväntat med den nya Application Insights-resursen.
• Bestämmer dig för att behålla eller ta bort den ursprungliga Application Insights-resursen. Att ta bort en klassisk resurs innebär att alla historiska data går förlorade. Om resursen är arbetsytebaserad finns data kvar i Log Analytics, vilket ger åtkomst till historiska data tills kvarhållningsperioden upphör att gälla.

Unika anpassningar som vanligtvis behöver återskapas eller uppdateras manuellt för resursen i den nya regionen omfattar, men som inte är begränsade till:

• Återskapa anpassade instrumentpaneler och arbetsböcker.
• Återskapa eller uppdatera omfånget för anpassade logg-/måttaviseringar.
• Återskapa tillgänglighetsaviseringar.
• Återskapa alla anpassade rollbaserade åtkomstkontrollinställningar i Azure som krävs för att användarna ska få åtkomst till den nya resursen.
• Replikera inställningar som omfattar datainmatningssampling, datahållning, daglig begränsning och anpassad metrikaktivering. De här inställningarna styrs via fönstret Användning och uppskattade kostnader .
• Alla integreringar som förlitar sig på API-nycklar, till exempel versionsanteckningar och live-mått, skyddar kontrollkanalen. Du måste generera nya API-nycklar och uppdatera den associerade integreringen.
• Kontinuerlig export i klassiska resurser måste konfigureras igen.
• Diagnostikinställningar i arbetsytebaserade resurser måste konfigureras igen.

Vi rekommenderar inte att du använder den här metoden för att fylla i API-versionen. Den senaste versionen kan representera förhandsversioner, som kan innehålla ändringar som bryter kompatibiliteten. Även med nyare versioner som inte är förhandsversioner är API-versionerna inte alltid bakåtkompatibla med befintliga mallar. I vissa fall kanske API-versionen inte är tillgänglig för alla prenumerationer.

Mer information finns i Skapa och konfigurera Application Insights-resurser.

Om du vill rapportera datamodell- eller schemaproblem och förslag använder du vår GitHub-lagringsplats.

PageView-telemetri innehåller URL och du kan parsa UTM-parametern med hjälp av en regex-funktion i Kusto.

Ibland kan dessa data saknas eller vara felaktiga om användaren eller företaget inaktiverar sändningen av användaragenten i webbläsarinställningarna. UA Parser-regexes kanske inte innehåller all enhetsinformation. Eller så kanske Application Insights inte har antagit de senaste uppdateringarna.

Detta kan inträffa om du använder strängvärden. Endast numeriska värden fungerar med anpassade mått.

Mer information finns i Application Insights telemetridatamodell.

ApplicationInsightsLoggerProvider ILogger registrerar loggar och skapar TraceTelemetry från dem. Om ett Exception-objekt skickas till Log-metoden på ILogger, skapas ExceptionTelemetry i stället för TraceTelemetry.

Visa ILogger-telemetri

På Azure-portalen:

1. Gå till Azure Portal och få åtkomst till application insights-resursen.
2. Välj avsnittet Loggar i Application Insights.
3. Använd Kusto-frågespråk (KQL) för att köra frågor mot ILogger-meddelanden som lagras i traces tabellen. Exempelfråga: traces | where message contains "YourSearchTerm".
4. Förfina dina frågor för att filtrera ILogger-data efter allvarlighetsgrad, tidsintervall eller specifikt meddelandeinnehåll.

I Visual Studio (lokalt felsökningsprogram):

1. Starta programmet i felsökningsläge i Visual Studio.
2. Öppna fönstret Diagnostikverktyg medan programmet körs.
3. På fliken Händelser visas ILogger-loggar tillsammans med andra telemetridata.
4. Om du vill hitta specifika ILogger-meddelanden använder du sök- och filterfunktionerna i fönstret Diagnostikverktyg .

Om du föredrar att alltid skicka TraceTelemetryanvänder du det här kodfragmentet:

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

Application Insights samlar in och skickar ILogger loggar med samma TelemetryConfiguration information som används för alla andra telemetrier. Men det finns ett undantag. Som standard TelemetryConfiguration är inte helt konfigurerat när du loggar från Program.cs eller Startup.cs. Loggar från dessa platser har inte standardinställningen, så de kör inte samtliga TelemetryInitializer instanser och TelemetryProcessor instanser.

När du använder det fristående paketet, injiceras inte TelemetryClient i beroendeinjektionsbehållaren. Du måste skapa en ny instans av TelemetryClient och använda samma konfiguration som loggningsprovidern använder, som följande kod visar. Det här kravet säkerställer att samma konfiguration används för all anpassad telemetri och telemetri från ILogger.

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;
   }  
}

Anmärkning

Om du använder Microsoft.ApplicationInsights.AspNetCore paketet för att aktivera Application Insights ändrar du den här koden för att komma TelemetryClient direkt i konstruktorn.

Application Insights-tillägget i Azure Web Apps använder den nya providern. Du kan ändra filtreringsreglerna i appsettings.json-filen för ditt program.

Mer information finns i Application Insights-loggning med .NET.

Java Profiler använder Java Flight Recorder (JFR) för att profilera ditt program med hjälp av en anpassad konfiguration.

Java Flight Recorder (JFR) är ett verktyg för att samla in profileringsdata för ett Java-program som körs. JFR är integrerat i JVM (Java Virtual Machine) och används för felsökning av prestandaproblem. Läs mer om Java SE JFR Runtime.

Java-profilering är en kostnadsfri funktion med Application Insights. Prissättningen för Azure Monitor Application Insights baseras på inmatningskostnaden.

Profileringsdata som samlas in av JFR omfattar: metod- och körningsprofileringsdata, skräpinsamlingsdata och låsprofiler.

JFR-inspelning kan visas och analyseras med önskat verktyg, till exempel Java Mission Control (JMC).

"Prestandadiagnostik och rekommendationer" är en ny funktion som snart blir tillgänglig som Application Insights Java Diagnostics. Du kan registrera dig för att förhandsgranska den här funktionen. JFR-inspelning kan visas med Java Mission Control (JMC).

På begäran utlöses profilering av användare i realtid medan automatisk profilering är med förkonfigurerade utlösare.

Använd Profil nu för profileringsalternativet på begäran. Profil nu profilerar omedelbart alla agenter som är kopplade till Application Insights-instansen.

Automatisk profilering utlöses genom att ett resurströskelvärde nås.

Application Insights Java Agent stöder för närvarande övervakning av PROCESSOR- och minnesförbrukning. Cpu-tröskelvärdet konfigureras som en procentandel av alla tillgängliga kärnor på datorn. Minnesuppbyggnad är den aktuella belastningen på Tenured-minnesregionen (OldGen) i förhållande till den maximalt möjliga storleken för regionen.

Granska förutsättningarna.

Ja, du kan profilera en JVM som kör mikrotjänster med hjälp av JFR.

Mer information finns i Azure Monitor Application Insights Profiler för Java.

Nej, samplings åsidosättningar är nu allmänt tillgängliga (GA) och kan användas med både autoinstrumentation och manuell instrumentering.

Om du använder autoinstrumentation, uppdatera filen applicationinsights.json i Azure-portalen.

För automatisk instrumentering krävs ingen manuell agentuppladdning. För manuell instrumentering behöver du dock fortfarande inkludera JAR-filen och konfigurationsfilerna för Application Insights-agenten i distributionspaketet.

Lokal utveckling avser miljön där appen skapas eller testas, till exempel en utvecklardator eller en Azure Cloud Shell-instans. Programservern refererar till webbservern som kör programmet, till exempel Tomcat 11 i en Azure App Service-miljö. När du använder manuell instrumentering måste du se till att AGENT JAR-filen är korrekt placerad på programservern.

För automatisk instrumentering kan du konfigurera samplings åsidosättningar via Azure-portalen. Om du använder manuell instrumentering bör du placera Application Insights-agentens JAR i rätt katalog och inkludera applicationinsights.json-filen med önskade samplingsinställningar.

Mer information finns i Samplings åsidosättningar – Azure Monitor Application Insights för Java.

TelemetryClient.trackTrace() är en del av Application Insights klassiska SDK-brygga och loggprocessorerna fungerar bara med den nya OpenTelemetry-baserade instrumentationen.

Mer information finns i Telemetriprocessorer (förhandsversion) – Azure Monitor Application Insights för Java.

• JavaScript SDK anger en användarcookie på webbklienten, för att identifiera återkommande användare och en sessionscookie till gruppaktiviteter.
• Om det inte finns något skript på klientsidan kan du ange cookies på servern.
• Om en verklig användare använder din webbplats i olika webbläsare, eller genom att använda privat/inkognitobläddring eller olika datorer, räknas de mer än en gång.
• Om du vill identifiera en inloggad användare mellan datorer och webbläsare lägger du till ett anrop till setAuthenticatedUserContext().

Application Insights JavaScript SDK har minimala kostnader på din webbplats. Med en storlek på bara 36 KB gzipped, och tar bara ~15 ms för att initiera, lägger SDK till en försumbar laddningstid till din webbplats. De minimala komponenterna i biblioteket läses snabbt in när du använder SDK och det fullständiga skriptet laddas ned i bakgrunden.

Även om skriptet laddas ned från CDN placeras dessutom all spårning av sidan i kö, så att du inte förlorar någon telemetri under hela sidans livscykel. Den här konfigurationsprocessen ger din sida ett sömlöst analyssystem som är osynligt för dina användare.

Chrome, Senaste Versionen ✔	Firefox senaste ✔	v3.x: IE 9+ & Microsoft Edge ✔ v2.x: IE 8+ Kompatibel och Microsoft Edge ✔	Opera senaste version ✔	Safari, senaste versionen ✔

Körbara exempel finns i Application Insights JavaScript SDK-exempel.

Vi måste vidta nödvändiga åtgärder för att se till att denna SDK fortsätter att "fungera" och inte bryter JavaScript-körningen när den läses in av en äldre webbläsare. Det skulle vara idealiskt att inte stödja äldre webbläsare, men många stora kunder kan inte styra vilken webbläsare användarna väljer att använda.

Detta uttalande innebär inte att vi enbart stödjer den lägsta gemensamma uppsättningen funktioner. Vi måste upprätthålla ES3-kodkompatibilitet. Nya funktioner måste läggas till på ett sätt som inte bryter ES3 JavaScript-parsning och läggs till som en valfri funktion.

Mer information om Stöd för Internet Explorer 8 finns i GitHub.

Ja, Application Insights JavaScript SDK är öppen källkod. Information om hur du visar källkoden eller bidrar till projektet finns i den officiella GitHub-lagringsplatsen.

Mer information finns i Aktivera Azure Monitor Application Insights Verklig användarövervakning.

Serversidan måste kunna acceptera anslutningar med de rubriker som finns. Beroende på konfigurationen Access-Control-Allow-Headers på serversidan är det ofta nödvändigt att utöka listan på serversidan genom att manuellt lägga till Request-Id, Request-Contextoch traceparent (W3C-distribuerat huvud).

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

Distribuerad spårning kan inaktiveras i konfigurationen.

Nej. Felen "502 bad gateway" och "503 service unavailable" registreras inte alltid av Application Insights. Om endast JavaScript på klientsidan används för övervakning skulle det här beteendet förväntas eftersom felsvaret returneras innan sidan som innehåller HTML-huvudet med javascript-övervakningsfragmentet återges.

Om svaret 502 eller 503 skickades från en server med övervakning på serversidan aktiverat samlas felen in av Application Insights SDK.

Även när övervakning på serversidan är aktiverad på ett programs webbserver, registreras ibland inte ett 502- eller 503-fel av Application Insights. Många moderna webbservrar tillåter inte att en klient kommunicerar direkt. I stället använder de lösningar som omvända proxyservrar för att skicka information fram och tillbaka mellan klienten och klientwebbservrarna.

I det här scenariot kan ett 502- eller 503-svar returneras till en klient på grund av ett problem på det omvända proxylagret, så det fångas inte in direkt av Application Insights. För att identifiera problem på det här lagret kan du behöva vidarebefordra loggar från den omvända proxyn till Log Analytics och skapa en anpassad regel för att söka efter 502- eller 503-svar. Mer information om vanliga orsaker till 502- och 503-fel finns i Felsöka HTTP-fel med "502 felaktig gateway" och "503-tjänsten är inte tillgänglig" i Azure App Service.

Mer information finns i Application Insights JavaScript SDK-konfiguration.

Webbläsaren skickar användaragentsträngen i HTTP-huvudet för begäran. Application Insights-inmatningstjänsten använder UA Parser för att generera de fält som du ser i datatabellerna och -upplevelserna. Därför kan Application Insights-användare inte ändra dessa fält.

Ibland kan dessa data saknas eller vara felaktiga om användaren eller företaget inaktiverar sändningen av användaragenten i webbläsarinställningarna. UA Parser-regexes kanske inte innehåller all enhetsinformation. Eller så kanske Application Insights inte har antagit de senaste uppdateringarna.

Mer information finns i Aktivera ett ramverkstillägg för Application Insights JavaScript SDK.

Nej. Befintliga ARM-mallar och API-anrop fortsätter att fungera. När du försöker skapa en klassisk resurs skapas i stället en arbetsytebaserad resurs med en hanterad arbetsyta.

Nej. Meddelande för enskilda resursmigreringar är inte tillgängligt. Om du vill styra när och hur dina resurser migreras använder du manuell migrering.

Enskilda migreringar slutförs vanligtvis på mindre än två minuter. Den fullständiga distributionen sker under flera veckor i alla regioner.

Efter migreringen länkar resursen till en Log Analytics-arbetsyta på sidan Översikt. Det klassiska meddelandet om tillbakadragning tas bort och arbetsboken för tillbakadragningar visar inte längre resursen.

Kostnaderna förblir vanligtvis likartade. Arbetsytebaserade Application Insights möjliggör kostnadsbesparande funktioner och vi rekommenderar att du granskar prisplaner.

Om du använder en äldre faktureringsmodell kan du läsa prisdokumentationen för mer information.

Nej. Alla aviseringar, instrumentpaneler och tillgänglighetstester förblir intakta och fortsätter att fungera efter migreringen.

Mer information finns i Hanterade arbetsytor i Application Insights.

Om du vill inaktivera telemetrikorrelation använder du correlationHeaderExcludedDomains egenskapen i konfigurationen. Mer information finns i ApplicationInsights-node.js.

Använd miljövariabeln för att konfigurera önskad loggnivå som Application Insights ska använda APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL . De värden som stöds är NONE, ERROR, WARN, INFO, DEBUG, VERBOSE och ALL. Mer information finns i ApplicationInsights-node.js.

Mer information finns i Övervaka dina Node.js tjänster och appar med Application Insights.

En lista över SDK-versioner och -namn finns på GitHub. Mer information finns i SDK-version.

Mer information finns i Samla in telemetri med OpenTelemetry i Application Insights.

OpenTelemetry är ett leverantörsneutralt observerbarhetsramverk. Det finns inga Application Insights-API:er i OpenTelemetry SDK eller bibliotek. Innan du migrerar är det viktigt att förstå några av OpenTelemetrys begrepp.

• I Application Insights hanterades all telemetri genom en enda TelemetryClient och TelemetryConfiguration. I OpenTelemetry har var och en av de tre telemetrisignalerna (spårningar, mått och loggar) sin egen konfiguration. Du kan skapa telemetri manuellt via .NET-körningen utan externa bibliotek. Mer information finns i .NET-guiderna för distribuerad spårning, mått och loggning.

• Application Insights används TelemetryModules för att automatiskt samla in telemetri för ditt program. I stället använder OpenTelemetry Instrumentation-bibliotek för att samla in telemetri från specifika komponenter (till exempel AspNetCore för begäranden och HttpClient för beroenden).

• Application Insights används TelemetryInitializers för att utöka telemetri med ytterligare information eller för att åsidosätta egenskaper. Med OpenTelemetry kan du skriva en processor för att anpassa en specifik signal. Dessutom erbjuder många OpenTelemetry Instrumentation-bibliotek en Enrich metod för att anpassa telemetrin som genereras av den specifika komponenten.

• Application Insights används TelemetryProcessors för att filtrera telemetri. En OpenTelemetry-processor kan också användas för att tillämpa filtreringsregler på en specifik signal.

Den här tabellen mappar Application Insights-datatyper till OpenTelemetry-begrepp och deras .NET-implementeringar.

Azure Monitor-tabell	Application Insights Datatyp	OpenTelemetry Datatyp	.NET-implementering
specialanpassade händelser	EventTelemetry	Inte tillgänglig	Inte tillgänglig
customMetrics	MetricTelemetry	Mätvärden	System.Diagnostics.Metrics.Meter
beroenden	BeroendeTelemetri	Intervall (klient, intern, konsument)	System.Diagnostics.Activity
undantag	ExceptionTelemetry	Undantag	System.Exception
begäranden	Begärtelemetri	Spann (Server, Producent)	System.Diagnostics.Activity
spår	Spårtelemetri	Loggfiler	Microsoft.Extensions.Logging.ILogger
spår	Spårtelemetri	Span-händelser	System.Diagnostics.ActivityEvent

Följande dokument innehåller mer information.

• Grunderna för datainsamling i Azure Monitor Application Insights
• Application Insights-telemetridatamodell
• OpenTelemetry-begrepp

Application Insights erbjöd flera alternativ för att konfigurera sampling, men Azure Monitor Exporter eller Azure Monitor Distro erbjuder endast sampling med fast hastighet. Endast begäranden och beroenden (OpenTelemetry Traces) kan samplas.

Kodexempel som beskriver hur du konfigurerar sampling finns i vår guide Aktivera sampling

I Application Insights .NET SDK använder du telemetriprocessorer för att filtrera och ändra eller ta bort telemetri. Använd telemetriinitierare för att lägga till eller ändra anpassade egenskaper. Mer information finns i Dokumentation om Azure Monitor. OpenTelemetry ersätter dessa begrepp med aktivitets- eller loggprocessorer som berikar och filtrerar telemetri.

Filtrera spårningar

Om du vill filtrera telemetridata i OpenTelemetry kan du implementera en aktivitetsprocessor. Det här exemplet motsvarar Application Insights-exemplet för filtrering av telemetridata enligt beskrivningen i Azure Monitor-dokumentationen. Exemplet visar var misslyckade beroendeanrop filtreras.

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;
    }
}

Om du vill använda den här processorn måste du skapa en TracerProvider och lägga till processorn före AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

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

Filtrering av loggar

ILogger implementeringar har en inbyggd mekanism för att tillämpa loggfiltrering. Med den här filtreringen kan du styra loggarna som skickas till varje registrerad provider, inklusive OpenTelemetryLoggerProvider. "OpenTelemetry" är aliaset för OpenTelemetryLoggerProvider, som används för att konfigurera filtreringsregler.

I följande exempel definieras "Fel" som standard LogLevel och "Varning" definieras som minimum LogLevel för en användardefinierad kategori. Dessa regler som definieras gäller endast för OpenTelemetryLoggerProvider.

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

Mer information finns i OpenTelemetry .NET-dokumentationen om loggar.

Lägga till anpassade egenskaper i spårningar

I OpenTelemetry kan du använda aktivitetsprocessorer för att utöka telemetridata med fler egenskaper. Det liknar att använda telemetriinitierare i Application Insights, där du kan ändra telemetriegenskaper.

Som standard flaggar Azure Monitor Exporter alla HTTP-begäranden med en svarskod på 400 eller senare som misslyckade. Men om du vill behandla 400 som ett lyckat resultat kan du lägga till en processor för berikande aktiviteter som anger framgång på aktiviteten och lägger till en tagg för att inkludera fler telemetriegenskaper. Det liknar att lägga till eller ändra egenskaper med hjälp av en initierare i Application Insights enligt beskrivningen i Azure Monitor-dokumentationen.

Här är ett exempel på hur du lägger till anpassade egenskaper och åsidosätter standardbeteendet för vissa svarskoder:

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;
    }
}

Om du vill använda den här processorn måste du skapa en TracerProvider och lägga till processorn före AddAzureMonitorTraceExporter.

using OpenTelemetry.Trace;

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

Skicka spårningar – manuell

Spårningar i Application Insights lagras som RequestTelemetry och DependencyTelemetry. I OpenTelemetry modelleras spår som Span med hjälp av Activity klassen.

OpenTelemetry .NET använder ActivitySource klasserna och Activity för spårning, som ingår i .NET-körningen. Den här metoden är distinkt eftersom .NET-implementeringen integrerar spårnings-API:et direkt i själva körningen. Paketet System.Diagnostics.DiagnosticSource gör att utvecklare kan använda ActivitySource för att skapa och hantera Activity instanser. Den här metoden ger ett sömlöst sätt att lägga till spårning i .NET-program utan att förlita sig på externa bibliotek, med hjälp av de inbyggda funktionerna i .NET-ekosystemet. Mer detaljerad information finns i genomgången av distribuerade spårningsinstrument.

Så här migrerar du manuell spårning:

Anmärkning

I Application Insights kan rollnamnet och rollinstansen anges på telemetrinivå. Med Azure Monitor Exporter kan vi dock inte anpassa på per telemetrinivå. Rollnamnet och rollinstansen extraheras från OpenTelemetry-resursen och tillämpas på all telemetri. Läs det här dokumentet om du vill ha mer information: Ange namnet på molnrollen och molnrollinstansen.

BeroendeTelemetri

Application Insights DependencyTelemetry används för att modellera utgående begäranden. Så här konverterar du den till OpenTelemetry:

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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));
}

Begärtelemetri

Application Insights modellerar RequestTelemetry inkommande begäranden. Så här migrerar du den till OpenTelemetry:

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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);
}

Spårning av anpassade operationer

I Application Insights spårar du anpassade åtgärder med hjälp av StartOperation och StopOperation metoder. Uppnå det med hjälp av ActivitySource och Activity i OpenTelemetry .NET. För åtgärder med ActivityKind.Server och ActivityKind.Consumergenererar Azure Monitor Exporter RequestTelemetry. För ActivityKind.Client, ActivityKind.Producer och ActivityKind.Internal genererar den DependencyTelemetry. För mer information om spårning av anpassade åtgärder, se Dokumentation om Azure Monitor. Mer information om hur du använder ActivitySource och Activity i .NET finns i genomgångarna för .NET-distribuerade spårningsinstrumentation.

Här är ett exempel på hur du startar och stoppar en aktivitet för anpassade åtgärder:

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

Skicka loggar

Loggar i Application Insights lagras som TraceTelemetry och ExceptionTelemetry.

Spårtelemetri

I OpenTelemetry integreras loggning via ILogger gränssnittet. Så här migrerar TraceTelemetrydu :

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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

Application Insights använder ExceptionTelemetry för att logga undantag. Så här migrerar du till OpenTelemetry:

Application Insights-exempel:

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);

OpenTelemetry-exempel:

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

Skicka statistik

Mått i Application Insights lagras som MetricTelemetry. I OpenTelemetry modelleras Meter från System.Diagnostics.DiagnosticSource-paketet som mått.

Application Insights har både icke-aggreggerande (TrackMetric()) och föraggregerande (GetMetric().TrackValue()) mått-API:er. Till skillnad från OpenTelemetry har Application Insights ingen uppfattning om instrument. Application Insights har samma API för alla måttscenarier.

OpenTelemetry å andra sidan kräver att användarna först väljer rätt måttinstrument baserat på måttets faktiska semantik. Om avsikten till exempel är att räkna något (t.ex. antalet totala serverbegäranden som tagits emot osv.) ska OpenTelemetry Counter användas. Om avsikten är att beräkna olika percentiler (t.ex. P99-värdet för serverfördröjning) bör OpenTelemetry Histogram-instrument användas. På grund av den här grundläggande skillnaden mellan Application Insights och OpenTelemetry görs ingen direkt jämförelse mellan dem.

Till skillnad från Application Insights tillhandahåller OpenTelemetry inte inbyggda mekanismer för att berika eller filtrera mått. I Application Insights kan telemetriprocessorer och initiatorer användas för att ändra eller ta bort mått, men den här funktionen är inte tillgänglig i OpenTelemetry.

Dessutom har OpenTelemetry inte stöd för att skicka råmått direkt, eftersom det inte finns någon motsvarighet till de TrackMetric() funktioner som finns i Application Insights.

Att migrera från Application Insights till OpenTelemetry innebär att ersätta alla Application Insights Metric API-användningar med OpenTelemetry-API:et. Det kräver förståelse för de olika OpenTelemetry-instrumenten och deras semantik.

Tips/Råd

Histogrammet är den mest mångsidiga och närmaste motsvarigheten till API:et för Application Insights GetMetric().TrackValue(). Du kan ersätta Application Insights Metric API:er med Histogram för att uppnå samma syfte.

Andra telemetrityper

Anpassade händelser

Stöds inte i OpenTelemetry.

Application Insights-exempel:

TelemetryClient.TrackEvent()

TillgänglighetTelemetri

Stöds inte i OpenTelemetry.

Application Insights-exempel:

TelemetryClient.TrackAvailability()

PageViewTelemetry

Stöds inte i OpenTelemetry.

Application Insights-exempel:

TelemetryClient.TrackPageView()

Vi rekommenderar Azure Monitor OpenTelemetry Exporter för konsol- och arbetstjänstprogram, som inte innehåller livemått.

Mer information finns i Migrera från .NET Application Insights SDK:er till Azure Monitor OpenTelemetry.

Den anpassade provtagaren för Application Insights fattar samplingsbeslut efter att intervallen har skapats, snarare än tidigare, den följer därför inte en traditionell huvudbaserad metod. I stället tillämpas samplingsbeslut i slutet av tidsintervalls-genereringen – efter att tidsintervallet har slutförts men före exporten.

Även om det här beteendet liknar tail-based sampling på vissa sätt, väntar inte samplingssystemet med att samla in flera intervall från samma tråd innan det fattar ett beslut. I stället använder den en hash av spårnings-ID:t för att säkerställa spårningens fullständighet.

Den här metoden balanserar spårningens fullständighet och effektivitet och undviker den högre kostnaden i samband med fullständig tail-baserad sampling.

Om du vill fatta samplingsbeslut baserat på resultatet av en hel spårning (till exempel att avgöra om något intervall inom spårningen misslyckades) krävs fullständig tail-baserad sampling i en nedströmsagent eller insamlare. Den här funktionen stöds inte för närvarande, men du kan begära den som en ny funktion via feedbackhubben.

Urvalsmetod	Beslutspunkt	Styrkor	Svagheter
Huvudbaserad	Innan ett spann börjar	Låg svarstid, minimalt med omkostnader	Kan ta ut önskade spår, inklusive misslyckanden.
Tail-baserad	När intervall buffrats baserat på tröskelvärden för tid eller volym	Tillåter mycket selektiva kriterier för spårsampling	Högre kostnad och extra bearbetningsfördröjning
Anpassad provtagare för App Insights	Slut på spangenerering	Balanserar spårnings fullständighet med effektivitet	Krävs för livemått och klassisk API-kompatibilitet

Nej, samplern tillämpar en fast frekvens för alla telemetrityper i ett spår. Begäranden, beroenden och andra intervall följer samma samplingsprocent. Om du vill använda olika frekvenser per telemetrityp bör du överväga att använda OpenTelemetry span-processorer eller (inmatningstidstransformeringar)[opentelemetry-overview.md#telemetry-routing].

Den anpassade Application Insights-exempeltagaren sprider samplingsbeslut med hjälp av W3C Trace Context-standarden som standard. Med den här standarden kan samplingsbeslut flöda mellan tjänster. Emellertid, eftersom samplaren fattar samplingsbeslut i slutet av spangenereringen – efter att ha anropat underordnade tjänster – innehåller överföringen ofullständig samplingsinformation. Den här begränsningen följer specifikationen för W3C-spårningskontext, men underordnade tjänster kan inte på ett tillförlitligt sätt använda detta beslut om spridd sampling.

Nej, den anpassade Application Insights-provtagaren fattar alltid ett oberoende samplingsbeslut, även om den överordnade tjänsten använder samma samplingsalgoritm. Samplingsbeslut från överordnade tjänster, inklusive de som använder W3C Trace Context-huvuden, påverkar inte den underordnade tjänstens beslut. Det samplar dock baserat på en hash av Trace ID för att säkerställa att spårningen är komplett. För att förbättra konsekvens och minska risken för brutna spår, konfigurera alla komponenter i systemet så att de använder samma sampler och samplingsfrekvens.

Det finns flera orsaker till att spårningar kan verka ofullständiga:

• Olika noder i ett distribuerat system använder olika samplingsmetoder som inte samordnar beslut. En nod tillämpar till exempel Huvudbaserad sampling i OpenTelemetry, och en annan nod tillämpar sampling via Azure Monitor Custom Sampler.
• Olika noder är inställda på olika samplingsfrekvenser, även om de båda använder samma samplingsmetod.
• Du anger filtrerings-, samplings- eller hastighetsbegränsningar i pipelinen på tjänstsidan, och den här konfigurationen samplar slumpmässigt bort intervall utan att beakta spårens fullständighet.

Om en komponent tillämpar huvudbaserad sampling utan att sprida samplingsbeslutet (via W3C Trace Context-rubriker) provar underordnade tjänster spårningen oberoende av varandra, vilket kan resultera i borttagna intervall. Därför är vissa delar av spårningen inte alltid tillgängliga när de visas i Application Insights.

Mer information finns i Sampling i Azure Monitor Application Insights med OpenTelemetry.

Det är en standard med öppen källkod för observerbarhet. Läs mer på OpenTelemetry.

Microsoft investerar i OpenTelemetry av följande skäl:

• Den är leverantörsneutral och tillhandahåller konsekventa API:er/SDK:er mellan olika språk.
• Med tiden tror vi att OpenTelemetry gör det möjligt för Azure Monitor-kunder att observera program som skrivits på språk utöver våra språk som stöds.
• Den utökar de typer av data som du kan samla in via en omfattande uppsättning instrumentationsbibliotek.
• OpenTelemetry Software Development Kits (SDK:er) tenderar att vara mer högpresterande i stor skala än sina föregångare, Application Insights SDK:er.
• OpenTelemetry överensstämmer med Microsofts strategi att ta till sig öppen källkod.

Se Status för OpenTelemetry.

Du kan se det som en tunn omslutning som buntar ihop alla OpenTelemetry-komponenter för en förstklassig upplevelse i Azure. Den här omslutningen kallas även för en distribution i OpenTelemetry.

Det finns flera fördelar med att använda Azure Monitor OpenTelemetry Distro över inbyggd OpenTelemetry från communityn:

• Minskar aktiveringsarbetet
• Stöds av Microsoft
• Innehåller Azure-specifika funktioner som:
  • Sampling som är kompatibel med klassiska Application Insights-SDK:er
  • Microsoft Entra-autentisering
  • Offlinelagring och automatiska återförsök
  • Statistikbeat
  • Application Insights Standard-mått
  • Identifiera resursmetadata för att automatiskt fylla i molnrollnamn och molnrollinstans i olika Azure-miljöer
  • Direktmätningar

I OpenTelemetrys anda utformade vi distributionen så att den var öppen och utökningsbar. Du kan till exempel lägga till:

• En OpenTelemetry Protocol-exportör (OTLP) och skicka till ett andra mål samtidigt
• Andra instrumentationsbibliotek som inte ingår i distributionen

Eftersom Distro tillhandahåller en OpenTelemetry-distribution stöder distributionen allt som stöds av OpenTelemetry. Du kan till exempel lägga till fler telemetriprocessorer, exportörer eller instrumentationsbibliotek om OpenTelemetry stöder dem.

Anmärkning

Distro ställer in samplern till en anpassad, konstant frekvenssamplare för Application Insights. Du kan ändra detta till en annan provtagare, men om du gör det kan du inaktivera några av distributionens inbyggda funktioner. För mer information om den stödda sampler, se avsnittet Aktivera sampling i Konfigurera Azure Monitor OpenTelemetry.

För språk utan en fristående OpenTelemetry-exportör som stöds är Azure Monitor OpenTelemetry Distro det enda sättet att använda OpenTelemetry med Azure Monitor. För språk med en fristående OpenTelemetry-exportör som stöds kan du använda antingen Azure Monitor OpenTelemetry Distro eller lämplig fristående OpenTelemetry-exportör beroende på ditt telemetriscenario. Mer information finns i När ska jag använda Azure Monitor OpenTelemetry-exportören?.

Kolla in våra aktiveringsdokument för .NET, Java, JavaScript (Node.js) och Python.

Vi rekommenderar att du använder Azure Monitor OpenTelemetry Distro för nya projekt när dess funktioner överensstämmer med dina övervakningsbehov. OpenTelemetry är ett branschstandardramverk som förbättrar plattformsoberoende observerbarhet och ger en standardiserad metod för telemetrisamling.

Application Insights SDK:er tillhandahåller dock fortfarande vissa funktioner som ännu inte är helt automatiserade i OpenTelemetry, inklusive:

• Automatisk beroendespårning – OpenTelemetry stöder beroendespårning, men vissa beroenden kräver ytterligare konfiguration jämfört med den automatiska spårning som är tillgänglig i Application Insights SDK:er.
• Anpassade telemetrityper, till exempel AvailabilityTelemetry och PageViewTelemetry – OpenTelemetry har inte direkta motsvarigheter. Liknande funktioner kan implementeras via manuell instrumentering.
• Telemetriprocessorer och initierare – OpenTelemetry har processorer och spanprocessorer, men de ersätter inte Application Insights telemetriprocessorer och initierare helt i alla scenarier.
• Utökad måttsamling – Även om OpenTelemetry har ett starkt måttsystem, kräver vissa inbyggda mått från Application Insights SDK:er manuell konfiguration i OpenTelemetry.

OpenTelemetry ger också fördelar jämfört med Application Insights SDK:er, inklusive:

• Bättre standardisering mellan plattformar
• Ett bredare ekosystem av instrumentationsbibliotek
• Större flexibilitet vid insamling och bearbetning av data
• Förbättrad leverantörsneutralitet, även om Azure Monitor OpenTelemetry Distro fortfarande är optimerat för Azure.

Azure Monitors OpenTelemetry-integrering utvecklas kontinuerligt och Microsoft fortsätter att förbättra sina funktioner. Om du överväger en övergång bör du noggrant utvärdera om OpenTelemetry för närvarande uppfyller dina observerbarhetskrav eller om Application Insights SDK fortfarande passar bättre för dina behov.

För ASP.NET Core, Java, Node.js och Python rekommenderar vi att du använder Azure Monitor OpenTelemetry Distro. En rad kod är allt som behövs för att börja.

För alla andra .NET-scenarier, inklusive klassiska ASP.NET, konsolappar, Windows Forms (WinForms) osv. rekommenderar vi att du använder .NET Azure Monitor OpenTelemetry-exportören: Azure.Monitor.OpenTelemetry.Exporter.

För mer komplexa Python-telemetriscenarier som kräver avancerad konfiguration rekommenderar vi att du använder Python Azure Monitor OpenTelemetry Exporter.

Följande diagram delar upp funktionsstöd för OpenTelemetry för varje språk.

Egenskap	.NÄT	Node.js	python	Java
Distribuerad spårning	✅	✅	✅	✅
Anpassade mått	✅	✅	✅	✅
Standardmått	✅	✅	✅	✅
Sampling med fast frekvens	✅	✅	✅	✅
Offlinelagring och automatiska återförsök	✅	✅	✅	✅
Undantagsrapportering	✅	✅	✅	✅
Loggsamling	✅	⚠️	✅	✅
Anpassade händelser	⚠️	⚠️	⚠️	✅
Microsoft Entra-autentisering	✅	✅	✅	✅
Livemätningar	✅	✅	✅	✅
Filtrering av direkta mått	✅	❌	❌	❌
Identifiera resurskontext för virtuell dator/VMSS och App Service	✅	❌	✅	✅
Identifiera resurskontext för Azure Kubernetes Service (AKS) och Functions	❌	❌	❌	✅
Händelser för tillgänglighetstestning som genereras med hjälp av API:et Spåra tillgänglighet	❌	❌	❌	✅
Filtrera begäranden, beroenden, loggar och undantag efter anonymt användar-ID och syntetisk källa	❌	❌	❌	✅
Filtrera beroenden, loggar och undantag efter åtgärdsnamn	❌	❌	❌	✅
Adaptiv provtagning	❌	❌	❌	✅
.NET Profiler	⚠️	❌	❌	⚠️
Felsökningsprogram för ögonblicksbilder	❌	❌	❌	❌

Nyckel

• ✅ Den här funktionen är tillgänglig för alla kunder med formell support.
• ⚠️ Den här funktionen är tillgänglig som en offentlig förhandsversion. Se Kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.
• ❌ Den här funktionen är inte tillgänglig eller är inte tillämplig.

Ja, men vi rekommenderar det inte och Azure stöder det inte. OpenTelemetry JavaScript är mycket optimerat för Node.js. I stället rekommenderar vi att du använder Application Insights JavaScript SDK.

OpenTelemetry-webb-SDK:t har ingen fastställd tillgänglighetstidslinje. Vi är förmodligen flera år från en webbläsar-SDK som är ett genomförbart alternativ till Application Insights JavaScript SDK.

OpenTelemetry-webbsandlådan är en förgrening som utformats för att få OpenTelemetry att fungera i en webbläsare. Det går ännu inte att skicka telemetri till Application Insights. SDK:t definierar inte allmänna klienthändelser.

Den här metoden är inte något som vi planerar att testa eller stödja, även om våra distributioner gör att du kan exportera till en OTLP-slutpunkt tillsammans med Azure Monitor samtidigt.

Vi rekommenderar det inte. Se Kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.

Se Översikt över OpenTelemetry.

Vissa kunder använder OpenTelemetry Collector som ett agentalternativ, även om Microsoft inte officiellt stöder en agentbaserad metod för programövervakning ännu. Under tiden bidrog communityn med öppen källkod med en OpenTelemetry Collector Azure Monitor-exportör som vissa kunder använder för att skicka data till Azure Monitor Application Insights. Detta stöds inte av Microsoft.

OpenCensus är föregångaren till OpenTelemetry. Microsoft hjälpte till att samla OpenTracing och OpenCensus för att skapa OpenTelemetry, en enda observerbarhetsstandard för världen. Den aktuella produktionsrekommenderade Python SDK för Azure Monitor är baserad på OpenCensus. Microsoft har åtagit sig att göra Azure Monitor baserat på OpenTelemetry.

Du kan försöka visualisera råa textloggar i stället för OpenTelemetry-spårningar.

I Application Insights lagrar tabellen Spårningar råtextloggar för diagnostiska ändamål. De hjälper dig att identifiera och korrelera spårningar som är associerade med användarbegäranden, andra händelser och undantagsrapporter. Tabellen Spårningar bidrar dock inte direkt till transaktionsvyn från slutpunkt till slutpunkt (vattenfallsdiagram) i visualiseringsverktyg som Grafana.

I och med det växande införandet av molnbaserade metoder finns det en utveckling inom insamling och terminologi för telemetri. OpenTelemetry blev en standard för insamling och instrumentering av telemetridata. I det här sammanhanget fick termen "Traces" en ny betydelse. I stället för råloggar refererar "Traces" i OpenTelemetry till en mer omfattande, strukturerad form av telemetri som innehåller intervall, som representerar enskilda arbetsenheter. Dessa intervall är avgörande för att skapa detaljerade transaktionsvyer, vilket möjliggör bättre övervakning och diagnostik av molnbaserade program.

Om du vill instrumentera en Blazor-app identifierar du först värdmodellen. Blazor Server stöder fullständig OpenTelemetry-baserad instrumentation. Blazor WebAssembly körs i webbläsaren och stöder begränsad instrumentering via JavaScript.

Mer information finns i OpenTelemetry Support och Feedback för Application Insights.

Nej, det finns en gräns på 30 dagars data som visas på en instrumentpanel.

Ett "resurs hittades inte"-fel kan inträffa om du flyttar eller byter namn på Application Insights-instansen.

Om du vill kringgå det här beteendet tar du bort standardinstrumentpanelen och väljer Programinstrumentpanel igen för att återskapa en ny.

Mer information finns i Application Insights Översiktsöversiktspanel.

Det korta svaret är att ingen av de inbyggda kanalerna erbjuder en transaktionstypgaranti för telemetrileverans till serverdelen. ServerTelemetryChannel är mer avancerat jämfört med InMemoryChannel för tillförlitlig leverans, men det gör också bara ett bästa försök att skicka telemetri. Telemetri kan fortfarande gå förlorad i flera situationer, inklusive följande vanliga scenarier:

• Objekt i minnet går förlorade när programmet kraschar.
• Telemetri går förlorad under längre perioder av nätverksproblem. Telemetri lagras på lokal disk under nätverksfel eller när problem uppstår med Application Insights-serverdelen. Objekt som är äldre än 48 timmar tas dock bort.
• Standarddiskplatserna för lagring av telemetri i Windows är %LOCALAPPDATA% eller %TEMP%. Dessa platser är vanligtvis lokala för datorn. Om programmet migreras fysiskt från en plats till en annan går all telemetri som lagras på den ursprungliga platsen förlorad.
• I Azure Web Apps i Windows är standardplatsen för disklagring D:\local\LocalAppData. Den här platsen finns inte kvar. Den rensas vid omstarter av appar, skalningsåtgärder och andra liknande åtgärder, vilket leder till förlust av telemetri som förvaras där. Du kan åsidosätta standardinställningen och ange lagring till en bevarad plats som D:\home. Sådana bevarade platser hanteras dock av fjärrlagring och kan därför vara långsamma.

Även om det är mindre troligt är det också möjligt att kanalen kan orsaka dubbletter av telemetridata. Det här beteendet inträffar när ServerTelemetryChannel gör ett nytt försök på grund av nätverksfel eller en timeout, när telemetridata levererades till serverdelen men svaret gick förlorat på grund av nätverksproblem eller tidsgränsen nåddes.

Även om namnet på paketet och namnområdet innehåller "WindowsServer" stöds den här kanalen på andra system än Windows, med följande undantag. På andra system än Windows skapar kanalen inte en lokal lagringsmapp som standard. Du måste skapa en lokal lagringsmapp och konfigurera kanalen så att den används. När lokal lagring har konfigurerats fungerar kanalen på samma sätt på alla system.

Anmärkning

Med version 2.15.0-beta3 och senare skapas nu lokal lagring automatiskt för Linux, Mac och Windows. För icke-Windows-system skapar SDK automatiskt en lokal lagringsmapp baserat på följande logik:

• ${TMPDIR}: Om ${TMPDIR} miljövariabeln har angetts används den här platsen.
• /var/tmp: Om den tidigare platsen inte finns försöker vi /var/tmp.
• /tmp: Om de tidigare platserna båda inte finns, försöker vi tmp.
• Om ingen av dessa platser finns skapas inte lokal lagring och manuell konfiguration krävs fortfarande. Fullständig implementeringsinformation finns i den här GitHub-lagringsplatsen.

SDK lagrar telemetriobjekt i lokal lagring vid nätverksproblem eller vid begränsad bandbredd. Dessa data krypteras inte lokalt.

För Windows-system skapar SDK automatiskt en tillfällig lokal mapp i katalogen %TEMP% eller %LOCALAPPDATA% och begränsar åtkomsten till administratörer och endast den aktuella användaren.

För andra system än Windows skapas ingen lokal lagring automatiskt av SDK:n, så inga data lagras lokalt som standard.

Anmärkning

Med version 2.15.0-beta3 och senare skapas nu lokal lagring automatiskt för Linux, Mac och Windows.

Du kan skapa en lagringskatalog själv och konfigurera kanalen så att den används. I det här fallet ansvarar du för att säkerställa att katalogen skyddas. Läs mer om dataskydd och sekretess.

Mer information finns i Telemetrikanaler i Application Insights.

Se sammanfattningen av gränser.

Vi loggar inte POST-data automatiskt, men du kan använda TrackTrace eller logganrop. Placera POST-data i meddelandeparametern. Du kan inte filtrera meddelandet på samma sätt som du kan filtrera efter egenskaper, men storleksgränsen är längre.

Azure Functions loggar inte URL-frågesträngar.

Mer information finns i Transaktionssökning och diagnostik.

Möjliga orsaker:

• Instrumenteras de andra komponenterna med Application Insights?
• Använder de den senaste stabila Application Insights-SDK:en?
• Om dessa komponenter är separata Application Insights-resurser kontrollerar du att du har åtkomst. Om du har åtkomst och komponenterna är instrumenterade med de senaste Application Insights SDK:erna meddelar du oss via feedbackkanalen i det övre högra hörnet.

För närvarande visar vi det utgående beroendeanropet separat från den inkommande begäran. Vanligtvis ser de två anropen identiska ut med bara varaktighetsvärdet som skiljer sig på grund av nätverkets tur och retur-resa. Den inledande ikonen och distinkt formatering av varaktighetsstaplarna hjälper till att skilja mellan dem. Är den här presentationen av data förvirrande? Ge oss din feedback!

Tidslinjer justeras för klocksnedvridningar i transaktionsdiagrammet. Du kan se exakta tidsstämplar i informationsfönstret eller med hjälp av Log Analytics.

Det här beteendet är avsiktligt. Alla relaterade objekt, över alla komponenter, är redan tillgängliga på vänster sida i de övre och nedre avsnitten. Den nya upplevelsen har två relaterade objekt som den vänstra sidan inte täcker: all telemetri från fem minuter före och efter den här händelsen och användarens tidslinje.

Transaktionsdiagnostikupplevelsen visar all telemetri i en enda åtgärd som delar ett åtgärds-ID. Som standard skapar Application Insights SDK för JavaScript en ny åtgärd för varje unik sidvy. I ett ensidesprogram (SPA) genereras endast en sidvisningshändelse och ett enda åtgärds-ID används för all telemetri som genereras. Därför kan många händelser korreleras till samma åtgärd.

I dessa scenarier kan du använda Automatisk routningsspårning för att automatiskt skapa nya åtgärder för navigering i ditt SPA. Du måste aktivera enableAutoRouteTracking så att en sidvy genereras varje gång URL-vägen uppdateras (logisk sidvy inträffar). Om du vill uppdatera åtgärds-ID:t manuellt anropar du appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId(). Om du utlöser en PageView-händelse manuellt återställs även åtgärds-ID:t.

Tid som inte förklaras i Gantt-schemat är tid som inte omfattas av ett spårat beroende. Det här problemet kan inträffa eftersom externa anrop inte har instrumenterats, antingen automatiskt eller manuellt. Det kan också inträffa eftersom den tid som användes var en del av processen snarare än på grund av ett externt samtal.

Om alla anrop har instrumenterats är processen den troliga rotorsaken till den tid som spenderas. Ett användbart verktyg för att diagnostisera processen är .NET Profiler.

Det här felet indikerar att webbläsaren inte kunde anropa ett obligatoriskt API, eller att API:et returnerade ett felsvar. Om du vill felsöka beteendet öppnar du ett webbläsarfönster i InPrivate och inaktiverar alla webbläsartillägg som körs och identifierar sedan om du fortfarande kan återskapa portalbeteendet. Om portalfelet fortfarande inträffar kan du testa med andra webbläsare eller andra datorer, undersöka DNS eller andra nätverksrelaterade problem från klientdatorn där API-anropen misslyckas. Om portalfelet fortsätter och behöver undersökas mer samlar du in en nätverksspårning i webbläsaren samtidigt som du återskapar det oväntade portalbeteendet och öppnar sedan ett supportärende från Azure Portal.

Mer information finns i Transaktionssökning och diagnostik.

Den första händelsen i visualiseringen representerar bara första gången en användare skickade sidvyn eller den anpassade händelsen under en session. Om användarna kan skicka den första händelsen flera gånger i en session visar kolumnen Steg 1 bara hur användare beter sig efter den första instansen av en första händelse, inte alla instanser.

Använd alternativen Dela upp efter på redigera-menyn:

1. Välj den händelse som du vill dela upp på menyn Händelse .

2. Välj en dimension på menyn Dimension . Om du till exempel har en händelse med namnet Knapp klickad kan du prova en anpassad egenskap med namnet Knappnamn.

Kohorter och filter skiljer sig. Anta att du har en kohort av användare från Storbritannien (definieras som i föregående exempel) och jämför resultatet med att ange filtret Country or region = United Kingdom:

• Kohortversionen visar alla händelser från användare som skickade en eller flera händelser från Storbritannien inom det aktuella tidsintervallet. Om du delar upp efter land eller region ser du förmodligen många länder och regioner.

• Filterversionen visar endast händelser från Storbritannien. Om du delar upp efter land eller region ser du bara Storbritannien.

Du kan välja filtret Datumintervall för att ändra kornigheten. Filtret är tillgängligt på alla dimensionsflikar.

Du kan utforska datan som finns i HEART-arbetsboken om de visuella elementen inte svarar på alla dina frågor. För att utföra den här uppgiften går du till avsnittet Övervakning i Application Insights och väljer Loggar och frågar tabellen customEvents . Några av click analytics-attributen finns i fältet customDimensions .

En exempelfråga visas här:

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

Mer information om loggar i Azure Monitor finns i Översikt över Azure Monitor-loggar.

Ja. Information om hur du redigerar arbetsboksmallar finns i Mallar för Azure-arbetsböcker.

Mer information finns i Användningsanalys med Application Insights.

.NET Core-appscenario	Paket
Utan värdtjänster	WorkerService
Med HostedServices	AspNetCore (inte WorkerService)
Med HostedServices övervakar du endast HostedServices	WorkerService (sällsynt scenario)

Ja, konfigurationen delas med resten av webbprogrammet.

Hämta en instans av med hjälp av TelemetryClient konstruktorinmatning och anropa den metod som krävs TrackXXX() för den. Vi rekommenderar inte att du skapar nya TelemetryClient instanser. En singleton-instans av TelemetryClient är redan registrerad i containern DependencyInjection , som delar TelemetryConfiguration med resten av telemetrin. Att skapa en ny TelemetryClient instans rekommenderas endast om den behöver en konfiguration som är separat från resten av telemetrin.

Visual Studio IDE-registrering stöds för närvarande endast för ASP.NET/ASP.NET Core-program. Det här dokumentet uppdateras när Visual Studio har stöd för registrering av Worker Service-program.

Nej. Azure Monitor Application Insights Agent stöder för närvarande endast .NET .

Ja. Funktionsstöd för denna SDK är detsamma på alla plattformar, med följande undantag:

• Prestandaräknare stöds endast i Windows förutom process-CPU/minne som visas i live-mått.

• Även om ServerTelemetryChannel är aktiverat som standard, om programmet körs i Linux eller macOS, skapar kanalen inte automatiskt en lokal lagringsmapp för att behålla telemetri tillfälligt om det finns nätverksproblem. På grund av den här begränsningen går telemetri förlorad när det finns tillfälliga nätverk eller serverproblem. Du kan undvika det här problemet genom att konfigurera en lokal mapp för kanalen:

  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();
       }
  

Mer information finns i Application Insights för Worker Service-program (icke-HTTP-program).