Datainsamling, kvarhållning och lagring i Application Insights

När du installerar Azure Application Insights SDK i din app skickar den telemetri om din app till molnet. Naturligtvis vill ansvariga utvecklare veta exakt vilka data som skickas, vad som händer med data och hur de kan behålla kontrollen över dem. I synnerhet kan känsliga data skickas, var lagras de och hur säkert är det?

Först det korta svaret:

  • Standardtelemetrimodulerna som körs "out of the box" kommer sannolikt inte att skicka känsliga data till tjänsten. Telemetrin handlar om belastnings-, prestanda- och användningsstatistik, undantagsrapporter och andra diagnostikdata. De viktigaste användardata som visas i diagnostikrapporterna är URL:er. men din app bör i alla fall inte placera känsliga data i oformaterad text i en URL.
  • Du kan skriva kod som skickar mer anpassad telemetri för att hjälpa dig med diagnostik och övervakningsanvändning. (Den här utökningsbarheten är en bra funktion i Application Insights.) Av misstag skulle det vara möjligt att skriva den här koden så att den innehåller personliga och andra känsliga data. Om ditt program fungerar med sådana data bör du tillämpa en grundlig granskningsprocess på all kod du skriver.
  • När du utvecklar och testar din app är det enkelt att kontrollera vad som skickas av SDK:et. Data visas i felsökningsutdatafönstren i IDE och webbläsaren.
  • Du kan välja plats när du skapar en ny Application Insights-resurs. Läs mer om Tillgänglighet för Application Insights per region här.
  • Granska insamlade data eftersom den här samlingen kan innehålla data som tillåts under vissa omständigheter men inte andra. Ett bra exempel på den här situationen är Enhetsnamn. Enhetsnamnet från en server påverkar inte sekretessen och är användbart, men ett enhetsnamn från en telefon eller bärbar dator kan ha sekretesskonsekvenser och vara mindre användbart. Ett SDK som främst utvecklats för målservrar skulle samla in enhetsnamn som standard och detta kan behöva skrivas över i både normala händelser och undantag.

Resten av den här artikeln beskriver mer utförligt dessa svar. Det är utformat för att vara självständigt, så att du kan visa det för kollegor som inte ingår i ditt närmaste team.

Vad är Application Insights?

Azure Application Insights är en tjänst från Microsoft som hjälper dig att förbättra prestanda och användbarhet för ditt liveprogram. Det övervakar ditt program hela tiden det körs, både under testningen och efter att du har publicerat eller distribuerat det. Application Insights skapar diagram och tabeller som till exempel visar vilka tider på dagen du får de flesta användare, hur dynamisk appen är och hur väl den hanteras av externa tjänster som den är beroende av. Om det uppstår krascher, fel eller prestandaproblem kan du söka igenom telemetridata i detalj för att diagnostisera orsaken. Och tjänsten skickar e-postmeddelanden till dig om det finns några ändringar i appens tillgänglighet och prestanda.

För att få den här funktionen installerar du en Application Insights SDK i ditt program, som blir en del av dess kod. När appen körs övervakar SDK sin åtgärd och skickar telemetri till Application Insights-tjänsten. Det här är en molntjänst som hanteras av Microsoft Azure. (Men Application Insights fungerar för alla program, inte bara program som finns i Azure.)

Application Insights-tjänsten lagrar och analyserar telemetrin. Om du vill se analysen eller sökningen via den lagrade telemetrin loggar du in på ditt Azure-konto och öppnar Application Insights-resursen för ditt program. Du kan också dela åtkomst till data med andra medlemmar i ditt team eller med angivna Azure-prenumeranter.

Du kan få data exporterade från Application Insights-tjänsten, till exempel till en databas eller till externa verktyg. Du ger varje verktyg en särskild nyckel som du får från tjänsten. Nyckeln kan återkallas om det behövs.

Application Insights SDK:er är tillgängliga för en rad olika programtyper: webbtjänster som finns i din egen Java EE eller ASP.NET servrar eller i Azure; webbklienter – dvs. koden som körs på en webbsida. skrivbordsappar och -tjänster; enhetsappar som Windows Phone, iOS och Android. Alla skickar telemetri till samma tjänst.

Anteckning

Stödet för inmatning av instrumentationsnycklar upphör den 31 mars 2025. Inmatningen av instrumenteringsnyckeln fortsätter att fungera, men vi kommer inte längre att tillhandahålla uppdateringar eller stöd för funktionen. Övergå till anslutningssträngar för att dra nytta av nya funktioner.

Vilka data samlar den in?

Det finns tre datakällor:

  • SDK:t som du integrerar med din app antingen under utveckling eller vid körning. Det finns olika SDK:er för olika programtyper. Det finns också en SDK för webbsidor som läses in i slutanvändarens webbläsare tillsammans med sidan.

    • Varje SDK har många moduler som använder olika tekniker för att samla in olika typer av telemetri.
    • Om du installerar SDK under utveckling kan du använda dess API för att skicka din egen telemetri, utöver standardmodulerna. Den här anpassade telemetrin kan innehålla alla data som du vill skicka.
  • På vissa webbservrar finns det även agenter som körs tillsammans med appen och skickar telemetri om cpu, minne och nätverksanvändning. Till exempel kan virtuella Azure-datorer, Docker-värdar och Java-programservrar ha sådana agenter.

  • Tillgänglighetstester är processer som körs av Microsoft och som skickar begäranden till din webbapp med jämna mellanrum. Resultaten skickas till Application Insights-tjänsten.

Vilka typer av data samlas in?

Huvudkategorierna är:

  • Webbservertelemetri – HTTP-begäranden. Uri, tiden det tar att bearbeta begäran, svarskoden, klientens IP-adress. Session id.
  • Webbsidor – Antal sidor, användare och sessioner. Sidinläsningstider. Undantag. Ajax anropar.
  • Prestandaräknare – Minne, CPU, I/O, Nätverksanvändning.
  • Klient- och serverkontext – OPERATIVSYSTEM, nationella inställningar, enhetstyp, webbläsare, skärmupplösning.
  • Undantag och krascher – stackdumpar, build id, CPU-typ.
  • Beroenden – anrop till externa tjänster som REST, SQL, AJAX. URI eller anslutningssträng, varaktighet, framgång, kommando.
  • Tillgänglighetstester – varaktighet för test och steg, svar.
  • Spåra loggar och anpassad telemetri - allt du kodar i dina loggar eller telemetri.

Mer information.

Hur kan jag kontrollera vad som samlas in?

Om du utvecklar appen med Hjälp av Visual Studio kör du appen i felsökningsläge (F5). Telemetrin visas i fönstret Utdata. Därifrån kan du kopiera den och formatera den som JSON för enkel inspektion.

Skärmbild som visar körning av appen i felsökningsläge i Visual Studio.

Det finns också en mer läsbar vy i fönstret Diagnostik.

Öppna webbläsarens felsökningsfönster för webbsidor.

Tryck på F12 och öppna fliken Nätverk.

Kan jag skriva kod för att filtrera telemetrin innan den skickas?

Detta skulle vara möjligt genom att skriva ett plugin-program för telemetriprocessor.

Hur länge sparas data?

Rådatapunkter (d.v.s. objekt som du kan fråga i Analytics och inspektera i Sök) sparas i upp till 730 dagar. Du kan välja en kvarhållningstid på 30, 60, 90, 120, 180, 270, 365, 550 eller 730 dagar. Om du behöver lagra data längre än 730 dagar kan du använda Kontinuerlig export för att kopiera dem till ett lagringskonto under datainmatning.

Data som sparas längre än 90 dagar medför tilläggsavgifter. Läs mer om priser för Application Insights på sidan med priser för Azure Monitor.

Aggregerade data (dvs. antal, medelvärden och andra statistiska data som visas i Metric Explorer) behålls i ett intervall på 1 minut i 90 dagar.

Ögonblicksbilder av felsökning lagras i 15 dagar. Den här kvarhållningsprincipen anges per program. Om du behöver öka det här värdet kan du begära en ökning genom att öppna ett supportärende i Azure Portal.

Vem som kan komma åt data?

Data är synliga för dig och, om du har ett organisationskonto, dina teammedlemmar.

Det kan exporteras av dig och dina teammedlemmar och kan kopieras till andra platser och skickas vidare till andra personer.

Vad gör Microsoft med den information som min app skickar till Application Insights?

Microsoft använder endast data för att tillhandahålla tjänsten till dig.

Var lagras data?

  • Du kan välja plats när du skapar en ny Application Insights-resurs. Läs mer om Tillgänglighet för Application Insights per region här.

Hur säkra är mina data?

Application Insights är en Azure-tjänst. Säkerhetsprinciper beskrivs i vitboken Säkerhet, sekretess och efterlevnad i Azure.

Data lagras på Microsoft Azure-servrar. För konton i Azure Portal beskrivs kontobegränsningar i dokumentet Säkerhet, Sekretess och Efterlevnad i Azure.

Åtkomst till dina data av Microsofts personal är begränsad. Vi kommer endast åt dina data med din behörighet och om det är nödvändigt för att stödja din användning av Application Insights.

Aggregerade data i alla våra kunders program (till exempel datahastigheter och genomsnittlig storlek på spårningar) används för att förbättra Application Insights.

Kan någon annans telemetri störa mina Application Insights-data?

De kan skicka ytterligare telemetri till ditt konto med hjälp av instrumentationsnyckeln, som finns i koden för dina webbsidor. Med tillräckligt med ytterligare data skulle dina mått inte korrekt representera appens prestanda och användning.

Om du delar kod med andra projekt bör du komma ihåg att ta bort instrumentationsnyckeln.

Är data krypterade?

Alla data krypteras i vila och flyttas mellan datacenter.

Krypteras data under överföring från mitt program till Application Insights-servrar?

Ja, vi använder https för att skicka data till portalen från nästan alla SDK:er, inklusive webbservrar, enheter och HTTPS-webbsidor.

Skapar SDK:en tillfällig lokal lagring?

Ja, vissa telemetrikanaler bevarar data lokalt om en slutpunkt inte kan nås. Granska nedan för att se vilka ramverk och telemetrikanaler som påverkas.

Telemetrikanaler som använder lokal lagring skapar temporära filer i TEMP- eller APPDATA-katalogerna, som är begränsade till det specifika konto som kör ditt program. Detta kan inträffa när en slutpunkt är tillfälligt otillgänglig eller om du når begränsningsgränsen. När det här problemet har lösts fortsätter telemetrikanalen att skicka alla nya och bevarade data.

Dessa sparade data krypteras inte lokalt. Om detta är ett problem granskar du data och begränsar insamlingen av privata data. (Mer information finns i Exportera och ta bort privata data.)

Om en kund behöver konfigurera den här katalogen med specifika säkerhetskrav kan den konfigureras per ramverk. Kontrollera att processen som kör programmet har skrivåtkomst till den här katalogen, men se också till att katalogen är skyddad för att undvika att telemetri läse av oavsiktliga användare.

Java

C:\Users\username\AppData\Local\Temp används för att bevara data. Den här platsen kan inte konfigureras från konfigurationskatalogen och behörigheterna för att komma åt den här mappen är begränsade till den specifika användaren med nödvändiga autentiseringsuppgifter. (Mer information finns i implementering.)

.NET

Som standard ServerTelemetryChannel använder den aktuella användarens lokala appdatamapp %localAppData%\Microsoft\ApplicationInsights eller temp-mapp %TMP%. (Se implementering här.)

Via konfigurationsfil:

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

Via kod:

  • Ta bort ServerTelemetryChannel från konfigurationsfilen
  • Lägg till det här kodfragmentet i konfigurationen:
    ServerTelemetryChannel channel = new ServerTelemetryChannel();
    channel.StorageFolder = @"D:\NewTestFolder";
    channel.Initialize(TelemetryConfiguration.Active);
    TelemetryConfiguration.Active.TelemetryChannel = channel;
    

NetCore

Som standard ServerTelemetryChannel använder den aktuella användarens lokala appdatamapp %localAppData%\Microsoft\ApplicationInsights eller temp-mapp %TMP%. (Se implementering här.)

I en Linux-miljö inaktiveras lokal lagring om inte en lagringsmapp har angetts.

Anteckning

Med versionen 2.15.0-beta3 och större lokal lagring skapas nu 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 /var/tmpvi .
  • /tmp – om båda de tidigare platserna inte finns provar tmpvi .
  • Om ingen av dessa platser finns skapas inte lokal lagring och manuell konfiguration krävs fortfarande. För fullständig implementeringsinformation.

Följande kodfragment visar hur du anger ServerTelemetryChannel.StorageFolder i -metoden för ConfigureServices() din Startup.cs klass:

services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});

(Mer information finns i Anpassad AspNetCore-konfiguration.)

Node.js

Som standard %TEMP%/appInsights-node{INSTRUMENTATION KEY} används för att bevara data. Behörigheter för att komma åt den här mappen är begränsade till den aktuella användaren och administratörerna. (Se implementering här.)

Mappprefixet appInsights-node kan åsidosättas genom att ändra körningsvärdet för den statiska variabeln Sender.TEMPDIR_PREFIX som finns i Sender.ts.

JavaScript (webbläsare)

HTML5-sessionslagring används för att spara data. Två separata buffertar används: AI_buffer och AI_sent_buffer. Telemetri som batchas och väntar på att skickas lagras i AI_buffer. Telemetri som just skickades placeras i AI_sent_buffer tills inmatningsservern svarar att den har tagits emot. När telemetri tas emot tas den bort från alla buffertar. Vid tillfälliga fel (till exempel om en användare förlorar nätverksanslutningen) finns telemetri kvar AI_buffer tills den har tagits emot eller inmatningsservern svarar att telemetrin är ogiltig (dåligt schema eller för gammalt, till exempel).

Telemetribuffertar kan inaktiveras genom att ange enableSessionStorageBuffer till false. När sessionslagring är inaktiverat används i stället en lokal matris som beständig lagring. Eftersom JavaScript SDK körs på en klientenhet har användaren åtkomst till den här lagringsplatsen via webbläsarens utvecklarverktyg.

OpenCensus Python

Som standard använder OpenCensus Python SDK den aktuella användarmappen %username%/.opencensus/.azure/. Behörigheter för att komma åt den här mappen är begränsade till den aktuella användaren och administratörerna. (Se implementering här.) Mappen med dina sparade data namnges efter Python-filen som genererade telemetrin.

Du kan ändra lagringsfilens plats genom att skicka in parametern storage_path i konstruktorn för den exportör som du använder.

AzureLogHandler(
  connection_string='InstrumentationKey=00000000-0000-0000-0000-000000000000',
  storage_path='<your-path-here>',
)

Hur gör jag för att skicka data till Application Insights med TLS 1.2?

För att säkerställa säkerheten för data som överförs till Application Insights-slutpunkterna rekommenderar vi starkt att kunderna konfigurerar sitt program så att det använder minst TLS (Transport Layer Security) 1.2. Äldre versioner av TLS/Secure Sockets Layer (SSL) har visat sig vara sårbara och även om de fortfarande arbetar för att tillåta bakåtkompatibilitet rekommenderas de inte, och branschen går snabbt över för att överge stödet för dessa äldre protokoll.

PCI Security Standards Council har satt en tidsfrist till den 30 juni 2018 för att inaktivera äldre versioner av TLS/SSL och uppgradera till säkrare protokoll. Om ditt program/klienter inte kan kommunicera över minst TLS 1.2 när Azure har tagit bort äldre stöd skulle du inte kunna skicka data till Application Insights. Den metod du använder för att testa och verifiera programmets TLS-stöd varierar beroende på operativsystem/plattform samt det språk/ramverk som ditt program använder.

Vi rekommenderar inte att du uttryckligen anger att ditt program endast ska använda TLS 1.2 om det inte behövs eftersom detta kan bryta säkerhetsfunktioner på plattformsnivå som gör att du automatiskt kan identifiera och dra nytta av nyare säkrare protokoll när de blir tillgängliga, till exempel TLS 1.3. Vi rekommenderar att du utför en grundlig granskning av programmets kod för att söka efter hårdkodning av specifika TLS/SSL-versioner.

Plattforms-/språkspecifik vägledning

Plattform/språk Support Mer information
Azure App Services Konfiguration kan krävas. Support tillkännagavs i april 2018. Läs meddelandet för konfigurationsinformation.
Azure-funktionsappar Konfiguration kan krävas. Support tillkännagavs i april 2018. Läs meddelandet för konfigurationsinformation.
.NET Stöd för långsiktigt stöd (LTS) Detaljerad konfigurationsinformation finns i de här anvisningarna.
Statusövervakare Konfiguration som stöds och krävs Statusövervakaren förlitar sig på OSConfiguration.NET + Configuration för att stödja TLS 1.2.
Node.js I v10.5.0 kan konfiguration krävas. Använd den officiella Node.js TLS/SSL-dokumentationen för alla programspecifika konfigurationer.
Java Stöd för JDK-stöd för TLS 1.2 har lagts till i JDK 6 uppdatering 121 och JDK 7. JDK 8 använder TLS 1.2 som standard.
Linux Linux-distributioner brukar förlita sig på stöd för OpenSSL för TLS 1.2. Kontrollera OpenSSL-ändringsloggen för att bekräfta att din version av OpenSSL stöds.
Windows 8.0 – 10 Stöds och aktiveras som standard. Bekräfta att du fortfarande använder standardinställningarna.
Windows Server 2012 - 2016 Stöds och aktiveras som standard. Bekräfta att du fortfarande använder standardinställningarna
Windows 7 SP1 och Windows Server 2008 R2 SP1 Stöds men är inte aktiverat som standard. Mer information om hur du aktiverar finns på sidan för TLS-registerinställningar (Transport Layer Security ).
Windows Server 2008 SP2 Stöd för TLS 1.2 kräver en uppdatering. Se Uppdatera för att lägga till stöd för TLS 1.2 i Windows Server 2008 SP2.
Windows Vista Stöds inte. Saknas

Kontrollera vilken version av OpenSSL din Linux-distribution kör

Om du vill kontrollera vilken version av OpenSSL du har installerat öppnar du terminalen och kör:

openssl version -a

Köra en TLS 1.2-testtransaktion på Linux

Om du vill köra ett preliminärt test för att se om Linux-systemet kan kommunicera via TLS 1.2 öppnar du terminalen och kör:

openssl s_client -connect bing.com:443 -tls1_2

Personliga data som lagras i Application Insights

I vår artikel om personliga data i Application Insights beskrivs det här problemet ingående.

Kan mina användare stänga av Application Insights?

Inte direkt. Vi tillhandahåller ingen växel som användarna kan använda för att stänga av Application Insights.

Du kan dock implementera en sådan funktion i ditt program. Alla SDK:er innehåller en API-inställning som inaktiverar telemetrisamling.

Data som skickas av Application Insights

SDK:erna varierar mellan plattformar och det finns flera komponenter som du kan installera. (Se Application Insights – översikt.) Varje komponent skickar olika data.

Dataklasser som skickas i olika scenarier

Din åtgärd Dataklasser som samlas in (se nästa tabell)
Lägga till Application Insights SDK i ett .NET-webbprojekt ServerContext
Inneburit
Prestandaräknare
Begäranden
Undantag
Session
användare
Installera Statusövervakaren på IIS Beroenden
ServerContext
Inneburit
Prestandaräknare
Lägga till Application Insights SDK i en Java-webbapp ServerContext
Inneburit
Förfrågan
Session
användare
Lägga till JavaScript SDK på webbsidan ClientContext
Inneburit
Sida
ClientPerf
Ajax
Definiera standardegenskaper Egenskaper för alla standardhändelser och anpassade händelser
Call TrackMetric Numeriska värden
Egenskaper
Samtalsspår* Händelsenamn
Egenskaper
Anropa TrackException Undantag
Stackdump
Egenskaper
SDK kan inte samla in data. Ett exempel:
– kan inte komma åt prestandaräknare
– undantag i telemetriinitieraren
SDK-diagnostik

Information om SDK:er för andra plattformar finns i deras dokument.

Klasserna för insamlade data

Insamlad dataklass Innehåller (inte en fullständig lista)
Egenskaper Alla data – bestäms av din kod
DeviceContext Id, IP, nationella inställningar, Enhetsmodell, nätverk, nätverkstyp, OEM-namn, skärmmatchning, Rollinstans, Rollnamn, Enhetstyp
ClientContext OPERATIVSYSTEM, nationella inställningar, språk, nätverk, fönsterupplösning
Session session id
ServerContext Datornamn, nationella inställningar, operativsystem, enhet, användarsession, användarkontext, åtgärd
Inneburit geoplats från IP-adress, tidsstämpel, operativsystem, webbläsare
Mått Måttnamn och -värde
Händelser Händelsenamn och -värde
Sidvisningar URL och sidnamn eller skärmnamn
Klientperf URL/sidnamn, webbläsarens inläsningstid
Ajax HTTP-anrop från webbsida till server
Begäranden URL, varaktighet, svarskod
Beroenden Type(SQL, HTTP, ...), anslutningssträng eller URI, sync/async, duration, success, SQL-instruktion (med Statusövervakaren)
Undantag Typ, meddelande, anropsstackar, källfil, radnummer, thread id
Kraschar Process id, parent process id, crash thread id; programkorrigering, id, build; undantagstyp, adress, orsak; dolda symboler och register, binära start- och slutadresser, binärt namn och sökväg, cpu-typ
Spårning Meddelande- och allvarlighetsgrad
Prestandaräknare Processortid, tillgängligt minne, begärandefrekvens, undantagsfrekvens, bearbeta privata byte, I/O-hastighet, varaktighet för begäran, kölängd för begäran
Tillgänglighet Svarskod för webbtest, varaktighet för varje teststeg, testnamn, tidsstämpel, framgång, svarstid, testplats
SDK-diagnostik Spårningsmeddelande eller undantag

Du kan stänga av vissa data genom att redigera ApplicationInsights.config

Anteckning

Klient-IP används för att härleda geografisk plats, men ip-data lagras som standard inte längre och alla nolla skrivs till det associerade fältet. För att förstå mer om hantering av personuppgifter rekommenderar vi den här artikeln. Om du behöver lagra IP-adressdata går vår artikel om IP-adresssamlingen igenom dina alternativ.

Kan jag ändra eller uppdatera data när de har samlats in?

Nej, data är skrivskyddade och kan bara tas bort via rensningsfunktionen. Mer information finns i Vägledning för personuppgifter som lagras i Log Analytics och Application Insights.

Krediter

Den här produkten innehåller GeoLite2-data som skapats av MaxMind, tillgängliga från https://www.maxmind.com.