Övervaka dina Node.js program och tjänster med Application Insights (klassiskt API)

Application Insights övervakar dina komponenter efter distributionen för att identifiera prestanda och andra problem. Du kan använda Application Insights för Node.js tjänster som finns i ditt datacenter, virtuella Azure-datorer och webbappar, och även i andra offentliga moln.

Om du vill ta emot, lagra och utforska dina övervakningsdata inkluderar du SDK:et i koden. Konfigurera sedan en motsvarande Application Insights-resurs i Azure. SDK:t skickar data till den resursen för ytterligare analys och undersökning.

Node.js-klientbiblioteket kan automatiskt övervaka inkommande och utgående HTTP-begäranden, undantag och vissa systemmått. Från och med version 0.20 kan klientbiblioteket även övervaka några vanliga tredjepartspaket, till exempel MongoDB, MySQL och Redis.

Alla händelser som relaterar till en inkommande HTTP-begäran korreleras för snabbare felsökning.

Du kan använda TelemetryClient-API:et för att manuellt instrumentera och övervaka fler aspekter av din app och ditt system. Vi beskriver TelemetryClient-API:n mer ingående senare i den här artikeln.

Kom igång

Utför följande uppgifter för att konfigurera övervakning för en app eller tjänst.

Förutsättningar

Innan du börjar ska du se till att ha en Azure-prenumeration eller så skaffar du en kostnadsfritt. Om din organisation redan har en Azure-prenumeration kan en administratör följa de här instruktionerna för att lägga till dig.

Konfigurera en Application Insights-resurs

1. Logga in på Azure-portalen.
2. Skapa en Application Insights-resurs.

Konfigurera klientbiblioteket för Node.js

Inkludera SDK:et i din app så att den kan samla in data.

1. Kopiera resursens anslutningssträng från den nya resursen. Application Insights använder anslutningssträng för att mappa data till din Azure-resurs. Innan SDK:t kan använda din anslutningssträng måste du ange anslutningssträng i en miljövariabel eller i koden.

   

2. Lägg till Node.js-klientbiblioteket i appens beroenden via package.json. Från appens rotmapp kör du:

   npm install applicationinsights --save
   

   Anteckning

   Om du använder TypeScript ska du inte installera separata "typskript"-paket. Det här NPM-paketet innehåller inbyggda typdefinitioner.

3. Ladda uttryckligen in biblioteket i din kod. Eftersom SDK:n lägger in instrumentationen i många andra bibliotek ska du läsa in biblioteket så tidigt som möjligt, till och med före andra require-uttryck.

   let appInsights = require('applicationinsights');
   

4. Du kan också ange en anslutningssträng via miljövariabeln APPLICATIONINSIGHTS_CONNECTION_STRINGi stället för att skicka den manuellt till setup() eller new appInsights.TelemetryClient(). Med den här metoden kan du hålla anslutningssträng borta från den incheckade källkoden och du kan ange olika anslutningssträng för olika miljöer. Om du vill konfigurera manuellt anropar du appInsights.setup('[your connection string]');.

   Fler konfigurationsalternativ finns i följande avsnitt.

   Du kan testa SDK:n utan att skicka telemetri genom att ställa in appInsights.defaultClient.config.disableAppInsights = true.

5. Börja samla in och skicka data automatiskt genom att anropa appInsights.start();.

Övervaka din app

SDK samlar automatiskt in telemetri om Node.js-körning och några vanliga moduler från tredje part. Använd ditt program för att skapa vissa av dessa data.

På Azure Portal går du sedan till Application Insights och öppnar den resurs som du skapade tidigare. I Översiktstidslinje letar du efter dina första datapunkter. Välj olika komponenter i schemana för att se mer detaljerade data.

Om du vill visa topologin som har identifierats för din app kan du använda Programkarta.

Inga data

Eftersom SDK batchar data för sändning kan det uppstå en fördröjning innan objekt visas i portalen. Om du inte ser några data i resursen kan du prova något av följande:

• Fortsätta att använda programmet. Vidta fler åtgärder för att generera mer telemetri.
• Välj Uppdatera i portalresursvyn. Diagram uppdaterar sig själva regelbundet, men när du trycker på uppdateringsknappen manuellt tvingas de att uppdatera genast.
• Verifiera att nödvändiga utgående portar är öppna.
• Använd Sök för att söka efter specifika händelser.
• Se Vanliga frågor.

Grundläggande användning

För direkt tillgänglig insamling av HTTP-begäranden, händelser från populära tredjepartsbibliotek, ohanterade undantag och systemmetrik:

let appInsights = require("applicationinsights");
appInsights.setup("[your connection string]").start();

Läs in Application Insights-biblioteket require("applicationinsights") så tidigt som möjligt i skripten innan du läser in andra paket. Det här steget behövs så att Application Insights-biblioteket kan förbereda senare paket för spårning. Om du stöter på konflikter med andra bibliotek som utför liknande förberedelser kan du prova att läsa in Application Insights-biblioteket efteråt.

På grund av hur JavaScript hanterar återanrop krävs mer arbete för att spåra en begäran över externa beroenden och senare återanrop. Som standard är den här extra spårningen aktiverad. Inaktivera det genom att anropa setAutoDependencyCorrelation(false) enligt beskrivningen i avsnittet SDK-konfiguration .

Migrera från versioner före 0.22

Det finns icke-bakåtkompatibla ändringar mellan releaseversioner före version 0.22 och senare. Dessa ändringar är utformade för att ge konsekvens med andra Application Insights-SDK:er och tillåta framtida utökningsbarhet.

I allmänhet kan du migrera med följande åtgärder:

• Ersätt referenser till appInsights.client med appInsights.defaultClient.
• Ersätt referenser till appInsights.getClient() med new appInsights.TelemetryClient().
• Ersätt alla argument med client.track*-metoder med ett enda objekt som innehåller namngivna egenskaper som argument. Se IDE:s inbyggda typtips eller TelemetryTypes för det undantagna objektet för varje typ av telemetri.

Om du kommer åt SDK-konfigurationsfunktioner utan att länka dem till appInsights.setup()kan du nu hitta dessa funktioner på appInsights.Configurations. Ett exempel är appInsights.Configuration.setAutoCollectDependencies(true). Granska ändringarna i standardkonfigurationen i nästa avsnitt.

SDK-konfiguration

Objektet appInsights innehåller många konfigurationsmetoder. De visas i följande kodfragment med sina standardvärden.

let appInsights = require("applicationinsights");
appInsights.setup("<connection_string>")
    .setAutoDependencyCorrelation(true)
    .setAutoCollectRequests(true)
    .setAutoCollectPerformance(true, true)
    .setAutoCollectExceptions(true)
    .setAutoCollectDependencies(true)
    .setAutoCollectConsole(true)
    .setUseDiskRetryCaching(true)
    .setSendLiveMetrics(false)
    .setDistributedTracingMode(appInsights.DistributedTracingModes.AI)
    .start();

Ställ in .setAutoDependencyCorrelation(true) för att korrelera händelser i en tjänst fullständigt. När detta alternativ är aktiverat kan SDK:n spåra kontext över asynkrona återanrop i Node.js.

Granska beskrivningarna i din IDE:s inbyggda typtips eller applicationinsights.ts för detaljerad information och valfria sekundära argument.

Distribuerad spårning

Moderna moln - och mikrotjänstarkitekturer har aktiverat enkla, oberoende distributionsbara tjänster som minskar kostnaderna samtidigt som tillgängligheten och dataflödet ökar. Det har dock gjort det svårare att resonera kring och felsöka övergripande system. Distribuerad spårning löser det här problemet genom att tillhandahålla en prestandaprofilerare som fungerar som anropsstackar för moln- och mikrotjänstarkitekturer.

Azure Monitor tillhandahåller två funktioner för användning av distribuerade spårningsdata: transaktionsdiagnostikvyn för en enskild transaktion/begäran och programkartvyn för att visa hur system interagerar.

Application Insights kan övervaka varje komponent separat och identifiera vilken komponent som är ansvarig för fel eller prestandaförsämring med hjälp av distribuerad telemetrikorrelation. Den här artikeln förklarar datamodellen, tekniker för kontextspridning, protokoll och implementering av korrelationstaktik på olika språk och plattformar som används av Application Insights.

Aktivera distribuerad spårning via Application Insights med autoinstrumentation eller SDK:er

Application Insights-agenter och SDK:er för .NET, .NET Core, Java, Node.jsoch JavaScript stöder alla distribuerad spårning internt.

Med rätt Application Insights SDK installerat och konfigurerat, samlas spårningsinformation automatiskt in för populära ramverk, bibliotek och tekniker genom SDK-beroende automatiska insamlare. Den fullständiga listan över tekniker som stöds finns i dokumentationen för beroendebaserad autokollektion.

Alla teknologier kan också spåras manuellt med ett anrop till TrackDependency på TelemetryClient.

Datamodell för telemetrikorrelation

Application Insights definierar en datamodell för distribuerad telemetrikorrelation. Om du vill associera telemetri med en logisk åtgärd har varje telemetriobjekt ett kontextfält med namnet operation_Id. Varje telemetriobjekt i den distribuerade spårningen delar den här identifieraren. Så även om du förlorar telemetri från ett enda lager kan du fortfarande associera telemetri som rapporterats av andra komponenter.

En distribuerad logisk åtgärd består vanligtvis av en uppsättning mindre åtgärder som är begäranden som bearbetas av en av komponenterna. Telemetri för begäran definierar dessa åtgärder. Varje telemetriobjekt för begäran har ett eget id objekt som identifierar det unikt och globalt. Och alla telemetriobjekt (till exempel spårningar och undantag) som är associerade med begäran bör ange operation_parentId till värdet av begäran id.

Beroendetelemetri representerar varje utgående åtgärd, till exempel ett HTTP-anrop till en annan komponent. Den definierar också sin egen id, som är globalt unik. Telemetri för begäran, initierad av detta beroendekall, utnyttjar detta id som sin operation_parentId.

Du kan skapa en vy över den distribuerade logiska åtgärden med hjälp av operation_Id, operation_parentId och request.id tillsammans med dependency.id. Dessa fält definierar också kausalitetsordningen för telemetrianrop.

I en mikrotjänstmiljö kan spårningar från komponenter gå till olika lagringsobjekt. Varje komponent kan ha en egen anslutningssträng i Application Insights. För att få telemetri för den logiska åtgärden frågar Application Insights data från varje lagringsobjekt.

När antalet lagringsobjekt är stort behöver du en ledtråd om var du ska titta härnäst. Application Insights-datamodellen definierar två fält för att lösa det här problemet: request.source och dependency.target. Det första fältet identifierar komponenten som initierade beroendebegäran. Det andra fältet identifierar vilken komponent som returnerade svaret från beroendeanropet.

För information om hur du frågar från flera olika instanser hänvisas till 'Fråga efter data mellan Log Analytics-arbetsytor, program och resurser i Azure Monitor'.

Example

Nu ska vi titta på ett exempel. Ett program med namnet Aktiekurser visar det aktuella marknadspriset för en aktie med hjälp av ett externt API som heter Stock. Programmet Aktiekurser har en sida med namnet Aktiesida som klientens webbläsare öppnar med hjälp av GET /Home/Stock. Programmet frågar lager-API:et med hjälp av HTTP-anropet GET /api/stock/value.

Du kan analysera den resulterande telemetrin genom att köra en fråga:

(requests | union dependencies | union pageViews)
| where operation_Id == "STYz"
| project timestamp, itemType, name, id, operation_ParentId, operation_Id

I resultatet delar alla telemetriobjekt roten operation_Id. När ett Ajax-anrop görs från sidan tilldelas ett nytt unikt ID (qJSXU) till beroendetelemetrin och ID:t för pageView används som operation_ParentId. Serverbegäran använder sedan Ajax-ID:t som operation_ParentId.

När anropet GET /api/stock/value görs till en extern tjänst måste du känna till serverns identitet så att du kan ange fältet dependency.target på rätt sätt. När den externa tjänsten inte stöder övervakning target ställs den in på tjänstens värdnamn. Ett exempel är stock-prices-api.com. Men om tjänsten identifierar sig genom att returnera ett fördefinierat HTTP-huvud innehåller target den tjänstidentitet som gör att Application Insights kan skapa en distribuerad spårning genom att fråga telemetri från den tjänsten.

Korrelationshuvuden med hjälp av W3C TraceContext

Application Insights övergår till W3C Trace-Context, som definierar:

• traceparent: Bär det globalt unika åtgärds-ID:t och den unika identifieraren för anropet.
• tracestate: Bär systemspecifikt spårningssammanhang.

Den senaste versionen av Application Insights SDK stöder Trace-Context-protokollet, men du kan behöva välja det. (Bakåtkompatibilitet med det tidigare korrelationsprotokollet som stöds av Application Insights SDK upprätthålls.)

HTTP-korrelationsprotokollet, även kallat Request-Id, är inaktuellt. Det här protokollet definierar två huvuden:

• Request-Id: Bär det globalt unika ID:t för anropet.
• Correlation-Context: Innehåller samlingen av namn-värdepar för de distribuerade spårningsegenskaperna.

Application Insights definierar också tillägget för HTTP-korrelationsprotokollet. Den använder Request-Context namn/värde-par för att överföra den samling egenskaper som används av den omedelbara anroparen eller anropade. Application Insights SDK använder headern för att ange fälten dependency.target och request.source.

Datamodellerna W3C Trace-Context och Application Insights mappar på följande sätt:

Mer information finns i Application Insights telemetridatamodell.

Provtagning

Som standard skickar SDK:et alla insamlade data till Application Insights-tjänsten. Om du vill aktivera sampling för att minska mängden data anger du samplingPercentage fältet på objektet för config en klient. Inställningen samplingPercentage till 100 (standardvärdet) innebär att alla data skickas och 0 innebär att ingenting skickas.

Om du använder automatisk korrelation inkluderas eller exkluderas alla data som är associerade med en enskild begäran som en enhet.

Lägg till kod som följande för att aktivera sampling:

const appInsights = require("applicationinsights");
appInsights.setup("<connection_string>");
appInsights.defaultClient.config.samplingPercentage = 33; // 33% of all telemetry will be sent to Application Insights
appInsights.start();

Flera roller för program med flera komponenter

I vissa scenarier kan ditt program bestå av flera komponenter som du vill instrumentera alla med samma anslutningssträng. Du vill fortfarande se dessa komponenter som separata enheter i portalen, som om de använde separata anslutningssträng. Ett exempel är separata noder på programkartan. Du måste konfigurera fältet RoleName manuellt för att skilja en komponents telemetri från andra komponenter som skickar data till din Application Insights-resurs.

Använd följande kod för att ange fältet RoleName :

const appInsights = require("applicationinsights");
appInsights.setup("<connection_string>");
appInsights.defaultClient.context.tags[appInsights.defaultClient.context.keys.cloudRole] = "MyRoleName";
appInsights.start();

Webbläsar-SDK-inläsare

Automatiserad webbinstrumentation kan aktiveras för Node.js-servern via konfiguration genom att införa JavaScript (Web) SDK Loader Script.

let appInsights = require("applicationinsights");
appInsights.setup("<connection_string>")
    .enableWebInstrumentation(true)
    .start();

eller genom att ange miljövariabeln APPLICATIONINSIGHTS_WEB_INSTRUMENTATION_ENABLED = true.

Webbinstrumentation är aktiverat på nodserversvar när alla följande krav uppfylls:

• Svaret har statuskoden 200.
• Svarsmetoden är GET.
• Serversvaret har Content-Type HTML.
• Serversvaret innehåller både <head> och </head> Taggar.
• Om svaret komprimeras måste det bara ha en Content-Encoding typ och kodningstypen måste vara en av gzip, br eller deflate.
• Svaret innehåller inte aktuella /backup web Instrumentation CDN-slutpunkter. (aktuella och säkerhetskopierade CDN-slutpunkter för webbinstrumentation här)

CDN-slutpunkten för webbinstrumentation kan ändras genom att miljövariabeln anges APPLICATIONINSIGHTS_WEB_INSTRUMENTATION_SOURCE = "web Instrumentation CDN endpoints". Anslutningssträng för webbinstrumentation kan ändras genom att miljövariabeln anges APPLICATIONINSIGHTS_WEB_INSTRUMENTATION_CONNECTION_STRING = "web Instrumentation connection string"

Automatisk instrumentering från tredje part

För att spåra kontext över asynkrona anrop krävs vissa ändringar i bibliotek från tredje part, till exempel MongoDB och Redis. Application Insights använder som standard diagnostic-channel-publishers för att "monkey-patcha" några av dessa bibliotek. Den här funktionen kan inaktiveras genom att APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL ange miljövariabeln.

Enskilda apkorrigeringar kan inaktiveras genom att ställa in APPLICATION_INSIGHTS_NO_PATCH_MODULES miljövariabeln på en kommaavgränsad lista över paket som ska inaktiveras. Använd till exempel APPLICATION_INSIGHTS_NO_PATCH_MODULES=console,redis för att undvika att korrigera paketen console och redis .

För närvarande instrumenteras nio paket: bunyan,,,consolemongodb,mongodb-core,mysql,,rediswinston, och pg.pg-pool Information om exakt vilken version av dessa paket som korrigeras finns i README för diagnostic-channel-publishers.

Korrigeringarna bunyan, winstonoch console genererar Application Insights-spårningshändelser baserat på om setAutoCollectConsole är aktiverat. Resten genererar Application Insights-beroendehändelser baserat på om setAutoCollectDependencies är aktiverat.

Livemått

Om du vill aktivera sändning av live-mått från din app till Azure använder du setSendLiveMetrics(true). För närvarande stöds inte filtrering av livemått i portalen.

Utökade mått

Om du vill aktivera sändning av utökade interna mått från din app till Azure installerar du det separata interna måttpaketet. SDK:et läses in automatiskt när det installeras och börjar samla in Node.js interna mått.

npm install applicationinsights-native-metrics

För närvarande utför det inbyggda måttpaketet automatisk insamling av skräpinsamlingens CPU-tid, händelseloop-cykler och heapanvändning.

• Skräpinsamling: Mängden CPU-tid som spenderas på varje typ av skräpinsamling och hur många förekomster av varje typ.
• Event loop: Hur många tickar som inträffade och hur mycket CPU-tid som totalt användes.
• Heap jämfört med icke-heap: Hur mycket av appens minnesanvändning finns i heap respektive icke-heap.

Distribuerade spårningslägen

Som standard skickar SDK:t rubriker som förstås av andra program eller tjänster som instrumenterats med en Application Insights SDK. Du kan aktivera sändning och mottagning av W3C Trace Context-huvuden utöver de befintliga AI-huvudena. På så sätt bryter du inte korrelationen med någon av dina befintliga äldre tjänster. Om du aktiverar W3C-huvuden kan din app korrelera med andra tjänster som inte instrumenterats med Application Insights, men som använder den här W3C-standarden.

const appInsights = require("applicationinsights");
appInsights
  .setup("<your connection string>")
  .setDistributedTracingMode(appInsights.DistributedTracingModes.AI_AND_W3C)
  .start()

TelemetryClient-API

En fullständig beskrivning av TelemetryClient-API:n finns i Application Insights API for custom events and metrics (Application Insights-API för anpassade händelser och mått).

Du kan spåra alla förfrågningar, händelser, mått eller undantag med hjälp av Application Insights-klientbiblioteket för Node.js. I följande kodexempel visas några av de tillgängliga API:erna som du kan använda:

let appInsights = require("applicationinsights");
appInsights.setup().start(); // assuming connection string in env var. start() can be omitted to disable any non-custom data
let client = appInsights.defaultClient;
client.trackEvent({name: "my custom event", properties: {customProperty: "custom property value"}});
client.trackException({exception: new Error("handled exceptions can be logged with this method")});
client.trackMetric({name: "custom metric", value: 3});
client.trackTrace({message: "trace message"});
client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM Customers", duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL"});
client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200, success:true});

let http = require("http");
http.createServer( (req, res) => {
  client.trackNodeHttpRequest({request: req, response: res}); // Place at the beginning of your request handler
});

Spåra dina beroenden

Du kan använda följande kod för att spåra dina beroenden:

let appInsights = require("applicationinsights");
let client = new appInsights.TelemetryClient();

var success = false;
let startTime = Date.now();
// execute dependency call here....
let duration = Date.now() - startTime;
success = true;

client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM Customers", duration:duration, resultCode:0, success: true, dependencyTypeName: "ZSQL"});;

Ett exempelverktyg som använder trackMetric för att mäta hur lång tid det tar att schemalägga händelseloopar:

function startMeasuringEventLoop() {
  var startTime = process.hrtime();
  var sampleSum = 0;
  var sampleCount = 0;

  // Measure event loop scheduling delay
  setInterval(() => {
    var elapsed = process.hrtime(startTime);
    startTime = process.hrtime();
    sampleSum += elapsed[0] * 1e9 + elapsed[1];
    sampleCount++;
  }, 0);

  // Report custom metric every second
  setInterval(() => {
    var samples = sampleSum;
    var count = sampleCount;
    sampleSum = 0;
    sampleCount = 0;

    if (count > 0) {
      var avgNs = samples / count;
      var avgMs = Math.round(avgNs / 1e6);
      client.trackMetric({name: "Event Loop Delay", value: avgMs});
    }
  }, 1000);
}

Lägga till en anpassad egenskap till alla händelser

Använd följande kod för att lägga till en anpassad egenskap i alla händelser:

appInsights.defaultClient.commonProperties = {
  environment: process.env.SOME_ENV_VARIABLE
};

Spåra HTTP GET-begäranden

Använd följande kod för att manuellt spåra HTTP GET-begäranden:

appInsights.defaultClient.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309, resultCode:200, success:true});

Du kan också spåra begäranden med hjälp trackNodeHttpRequest av metoden:

var server = http.createServer((req, res) => {
  if ( req.method === "GET" ) {
      appInsights.defaultClient.trackNodeHttpRequest({request:req, response:res});
  }
  // other work here....
  res.end();
});

Spåra starttiden för server

Du kan använda följande kod för att spåra starttiden för servern:

let start = Date.now();
server.on("listening", () => {
  let duration = Date.now() - start;
  appInsights.defaultClient.trackMetric({name: "server startup time", value: duration});
});

Spola

Som standard buffrad telemetri i 15 sekunder innan den skickas till inmatningsservern. Om ditt program har en kort livslängd, till exempel ett CLI-verktyg, kan det vara nödvändigt att manuellt spola din buffrade telemetri när programmet avslutas med hjälp av appInsights.defaultClient.flush().

Om SDK:t upptäcker att din applikation kraschar, anropar det tömningsfunktionen åt dig med hjälp av appInsights.defaultClient.flush({ isAppCrashing: true }). Med tömningsalternativet isAppCrashingantas programmet vara i ett onormalt tillstånd och är inte lämpligt att skicka telemetri. I stället sparar SDK:t all buffrad telemetri till beständig lagring och låter programmet avslutas. När programmet startar igen försöker det skicka all telemetri som har sparats till beständig lagring.

Filtrera och förbearbeta telemetri

Du kan skriva kod för att filtrera, ändra eller utöka telemetrin innan den skickas från SDK:t. Bearbetningen innehåller data som skickas från standardtelemetrimodulerna, till exempel INSAMLING av HTTP-begäranden och beroendeinsamling.

• Filtrering kan ändra eller ta bort telemetri innan den skickas från SDK:t genom att implementera ITelemetryProcessor. Du kan till exempel minska mängden telemetri genom att exkludera begäranden från robotar. Till skillnad från sampling har du fullständig kontroll över vad som skickas eller tas bort, men det påverkar alla mått som baseras på aggregerade loggar. Beroende på hur du tar bort objekt kan du också förlora möjligheten att navigera mellan relaterade objekt.

• Lägg till eller ändra egenskaper i telemetri som skickas från din app genom att implementera en ITelemetryInitializer. Du kan till exempel lägga till beräknade värden eller versionsnummer för att filtrera data i portalen.

• Sampling minskar mängden telemetri utan att påverka din statistik. Den håller ihop relaterade datapunkter så att du kan navigera mellan dem när du diagnostiserar ett problem. I portalen multipliceras det totala antalet för att kompensera för samplingen.

Filtering

Den här tekniken ger dig direkt kontroll över vad som ingår eller undantas från telemetriströmmen. Filtrering kan användas för att ta bort telemetriobjekt från att skickas till Application Insights. Du kan använda filtrering med sampling eller separat.

Om du vill filtrera telemetri skriver du en telemetriprocessor och registrerar den med TelemetryConfiguration. All telemetri går igenom din processor. Du kan välja att släppa den från strömmen eller ge den till nästa processor i kedjan. Telemetri från standardmodulerna, till exempel HTTP-begärandeinsamlaren och beroendeinsamlaren, och telemetri som du spårade själv ingår. Du kan till exempel filtrera bort telemetri om begäranden från robotar eller lyckade beroendeanrop.

ITelemetryProcessor och ITelemetryInitializer

Vad är skillnaden mellan telemetriprocessorer och telemetriinitierare?

• Det finns vissa överlappningar i vad du kan göra med dem. Båda kan användas för att lägga till eller ändra egenskaper för telemetri, men vi rekommenderar att du använder initierare för detta ändamål.
• Telemetriinitierare körs alltid före telemetriprocessorer.
• Telemetriinitierare kan anropas mer än en gång. Enligt konventionen anger de inte någon egenskap som redan har angetts.
• Med telemetriprocessorer kan du helt ersätta eller ta bort ett telemetriobjekt.
• Alla registrerade telemetriinitierare anropas för varje telemetriobjekt. För telemetriprocessorer garanterar SDK att den första telemetriprocessorn anropas. Om resten av processorerna anropas eller inte bestäms av de föregående telemetriprocessorerna.
• Använd telemetriinitierare för att utöka telemetri med fler egenskaper eller åsidosätta en befintlig. Använd en telemetriprocessor för att filtrera bort telemetri.

Lägg till/ändra egenskaper

Använd telemetriinitierare för att utöka telemetri med ytterligare information eller för att åsidosätta telemetriegenskaper som anges av standardtelemetrimodulerna.

Application Insights för ett webbpaket samlar till exempel in telemetri om HTTP-begäranden. Som standard flaggas alla begäranden med svarskoden >=400 som misslyckade. Om du i stället vill behandla 400 som en framgång kan du ange en telemetri-initialiserare som ställer in framgångsegenskapen.

Om du anger en telemetriinitierare anropas den när någon av Metoderna Track*() anropas. Den här initiatorn innehåller Track() metoder som anropas av standardtelemetrimodulerna. Enligt konventionen anger dessa moduler inte någon egenskap som redan har angetts av en initiator. Telemetriinitierare anropas innan telemetriprocessorer anropas, så alla berikanden som görs av initiatorer är synliga för processorer.

Förbearbeta data med telemetriprocessorer

Du kan bearbeta och filtrera insamlade data innan de skickas för kvarhållning med hjälp av telemetriprocessorer. Telemetriprocessorer anropas en i taget i den ordning de lades till innan telemetriobjektet skickas till molnet.

public addTelemetryProcessor(telemetryProcessor: (envelope: Contracts.Envelope, context: { http.RequestOptions, http.ClientRequest, http.ClientResponse, correlationContext }) => boolean)

Om en telemetriprocessor returnerar falseskickas inte telemetriobjektet.

Alla telemetriprocessorer tar emot telemetridata och dess kuvert för att inspektera och ändra. De får också ett kontextobjekt. Innehållet i det här objektet definieras av parametern contextObjects när du anropar en spårningsmetod för manuellt spårad telemetri. För automatiskt insamlad telemetri fylls det här objektet med tillgänglig information om begäranden och det beständiga begärandeinnehållet som tillhandahålls av appInsights.getCorrelationContext() (om automatisk beroendekorrelation är aktiverat).

TypeScript-typen för en telemetriprocessor är:

telemetryProcessor: (envelope: ContractsModule.Contracts.Envelope, context: { http.RequestOptions, http.ClientRequest, http.ClientResponse, correlationContext }) => boolean;

Till exempel kan en processor som tar bort stacksspårningsdata från undantag skrivas och läggas till på följande sätt:

function removeStackTraces ( envelope, context ) {
  if (envelope.data.baseType === "Microsoft.ApplicationInsights.ExceptionData") {
    var data = envelope.data.baseData;
    if (data.exceptions && data.exceptions.length > 0) {
      for (var i = 0; i < data.exceptions.length; i++) {
        var exception = data.exceptions[i];
        exception.parsedStack = null;
        exception.hasFullStack = false;
      }
    }
  }
  return true;
}

appInsights.defaultClient.addTelemetryProcessor(removeStackTraces);

Lägga till ett molnrollnamn och en molnrollinstans

Ange namnet på molnrollen via direktkontexttaggar:

var appInsights = require("applicationinsights");
appInsights.setup('INSTRUMENTATION_KEY').start();
appInsights.defaultClient.context.tags["ai.cloud.role"] = "your role name";
appInsights.defaultClient.context.tags["ai.cloud.roleInstance"] = "your role instance";

Ange namnet på molnrollen via telemetriprocessorn:

var appInsights = require("applicationinsights");
appInsights.setup('INSTRUMENTATION_KEY').start();

appInsights.defaultClient.addTelemetryProcessor(envelope => {
    envelope.tags["ai.cloud.role"] = "your role name";
    envelope.tags["ai.cloud.roleInstance"] = "your role instance"
});

Använda flera anslutningssträng

Du kan skapa flera Application Insights-resurser och skicka olika data till var och en med hjälp av respektive anslutningssträng.

Till exempel:

let appInsights = require("applicationinsights");

// configure auto-collection under one connection string
appInsights.setup("Connection String A").start();

// track some events manually under another connection string
let otherClient = new appInsights.TelemetryClient("Connection String B");
otherClient.trackEvent({name: "my custom event"});

Avancerade konfigurationsalternativ

Klientobjektet innehåller en config egenskap med många valfria inställningar för avancerade scenarier. Om du vill ange dem använder du:

client.config.PROPERTYNAME = VALUE;

Dessa egenskaper är klientspecifika, så du kan konfigurera appInsights.defaultClient separat från klienter som skapats med new appInsights.TelemetryClient().

Kärn-API för anpassade händelser och mått

Infoga några rader kod i programmet för att ta reda på vad användarna gör med det eller för att diagnostisera problem. Du kan skicka telemetri från enhets- och skrivbordsappar, webbklienter och webbservrar. Använd Application Insights-kärntelemetri-API:et för att skicka anpassade händelser och mått och dina egna versioner av standardtelemetri. Det här API:et är samma API som standarddatainsamlaren i Application Insights använder.

API-sammanfattning

Kärn-API:et är enhetligt på alla plattformar, förutom några varianter som GetMetric (endast.NET).

Du kan koppla egenskaper och mått till de flesta av dessa telemetrianrop.

Förutsättningar

Om du inte har någon referens för Application Insights SDK ännu:

1. Lägg till Application Insights SDK i projektet.

2. I din enhets- eller webbserverkod inkluderar du:

   • .NET
   • Node.js

   using Microsoft.ApplicationInsights;
   

Hämta en TelemetryClient-instans

Hämta en instans av TelemetryClient:

private TelemetryClient telemetry = new TelemetryClient();

TelemetryClient.Context.User.Id = "...";
TelemetryClient.Context.Device.Id = "...";

var telemetry = applicationInsights.defaultClient;

TrackEvent

I Application Insights är en anpassad händelse en datapunkt som du kan visa i Metrics Explorer som ett aggregerat antal och i Diagnostiksökning som enskilda förekomster. (Det är inte relaterat till MVC eller andra ramverkshändelser.)

Infoga TrackEvent anrop i koden för att räkna olika händelser. Du kanske till exempel vill spåra hur ofta användare väljer en viss funktion. Eller så kanske du vill veta hur ofta de uppnår vissa mål eller gör specifika typer av misstag.

I en spelapp kan du till exempel skicka ett evenemang när en användare vinner spelet:

telemetry.TrackEvent("WinGame");

telemetry.trackEvent({name: "WinGame"});

Anpassade händelser i Log Analytics

Telemetrin är tillgänglig i customEvents tabellen på fliken Application Insights-loggar eller användningsupplevelsen. Händelser kan komma från trackEvent(..) eller plugin-programmet Click Analytics Autocollection.

Om samplingen är i drift visar egenskapen itemCount ett värde som är större än 1. Innebär till exempel itemCount==10 att av 10 anrop till trackEvent()överförde samplingsprocessen bara en av dem. Om du vill få ett korrekt antal anpassade händelser använder du kod som customEvents | summarize sum(itemCount).

GetMetric

Information om hur du effektivt använder anropet GetMetric() för att samla in lokalt föraggregerade mått för .NET- och .NET Core-program finns i Anpassad måttsamling i .NET och .NET Core.

TrackMetric

Application Insights kan kartlägga mått som inte är kopplade till vissa händelser. Du kan till exempel övervaka en kölängd med jämna mellanrum. Med mått är de enskilda mätningarna av mindre intresse än variationerna och trenderna, och därför är statistiska diagram användbara.

Om du vill skicka mått till Application Insights kan du använda API:et TrackMetric(..) . Det finns två sätt att skicka ett mått:

• Enskilt värde. Varje gång du utför en mätning i ditt program skickar du motsvarande värde till Application Insights.

  Anta till exempel att du har ett mått som beskriver antalet objekt i en container. Under en viss tidsperiod placerar du först tre objekt i containern och tar sedan bort två objekt. Därför skulle du ringa TrackMetric två gånger. Först skickar du värdet 3 och skickar sedan värdet -2. Application Insights lagrar båda värdena åt dig.

• Aggregat. När du arbetar med mått är varje enskild mätning sällan av intresse. I stället är en sammanfattning av vad som hände under en viss tidsperiod viktig. En sådan sammanfattning kallas aggregering.

  I föregående exempel är 1 den aggregerade måttsumman för den tidsperioden och antalet måttvärden är 2. När du använder aggregeringsmetoden anropar TrackMetric du bara en gång per tidsperiod och skickar aggregeringsvärdena. Vi rekommenderar den här metoden eftersom den avsevärt kan minska kostnaderna och prestandakostnaderna genom att skicka färre datapunkter till Application Insights, samtidigt som all relevant information samlas in.

Exempel med ett enda värde

Så här skickar du ett enda måttvärde:

var sample = new MetricTelemetry();
sample.Name = "queueLength";
sample.Sum = 42.3;
telemetryClient.TrackMetric(sample);

telemetry.trackMetric({name: "queueLength", value: 42.0});

Anpassade mått i Log Analytics

Telemetrin är tillgänglig i customMetrics tabellen i Application Insights Analytics. Varje rad representerar ett anrop till trackMetric(..) i din app.

• valueSum: Summan av mätningarna. Om du vill hämta medelvärdet dividerar du med valueCount.
• valueCount: Antalet mått som aggregerades i det här trackMetric(..) anropet.

Sidvisningar

I en enhets- eller webbsidaapp skickas telemetri för sidvisning som standard när varje skärm eller sida läses in. Men du kan ändra standardvärdet för att spåra sidvisningar vid fler eller olika tidpunkter. I en app som till exempel visar flikar eller fönster kanske du vill spåra en sida när användaren öppnar ett nytt fönster.

Användar- och sessionsdata skickas som egenskaper tillsammans med sidvyer, så användar- och sessionsdiagram kommer till liv när det finns telemetri för sidvisning.

Anpassade sidvyer

telemetry.TrackPageView("GameReviewPage");

Sidtelemetri i Log Analytics

I Log Analytics visar två tabeller data från webbläsaråtgärder:

• pageViews: Innehåller data om URL:en och sidrubriken.
• browserTimings: Innehåller data om klientprestanda som den tid det tar att bearbeta inkommande data.

För att ta reda på hur lång tid det tar för webbläsaren att bearbeta olika sidor:

browserTimings
| summarize avg(networkDuration), avg(processingDuration), avg(totalDuration) by name

Så här upptäcker du populariteten för olika webbläsare:

pageViews
| summarize count() by client_Browser

Koppla sidvisningar till AJAX-anrop genom att ansluta till beroenden:

pageViews
| join (dependencies) on operation_Id

TrackRequest

Server-SDK:t använder TrackRequest för att logga HTTP-begäranden.

Du kan också anropa det själv om du vill simulera begäranden i en kontext där du inte har webbtjänstmodulen igång.

Det rekommenderade sättet att skicka telemetri för begäran är när begäran fungerar som en åtgärdskontext.

Åtgärdskontext

Du kan korrelera telemetriobjekt genom att associera dem med åtgärdskontexten. Standardmodulen för spårning av begäranden gör det för undantag och andra händelser som skickas medan en HTTP-begäran bearbetas. I Sök och Analys kan du enkelt hitta alla händelser som är associerade med begäran med hjälp av dess åtgärds-ID.

När du spårar telemetri manuellt är det enklaste sättet att säkerställa telemetrikorrelation genom att använda det här mönstret:

// Establish an operation context and associated telemetry item:
using (var operation = telemetryClient.StartOperation<RequestTelemetry>("operationName"))
{
    // Telemetry sent in here uses the same operation ID.
    ...
    telemetryClient.TrackTrace(...); // or other Track* calls
    ...

    // Set properties of containing telemetry item--for example:
    operation.Telemetry.ResponseCode = "200";

    // Optional: explicitly send telemetry item:
    telemetryClient.StopOperation(operation);

} // When operation is disposed, telemetry item is sent.

// Establish an operation context and associated telemetry item:
const operation = appInsights.startOperation(client, { name: "operationName" });

appInsights.wrapWithCorrelationContext(() => {
    // Telemetry sent in here uses the same operation ID.
    ...
    client.trackTrace({ message: "..." }); // or other track* calls
    ...

    // Set properties of containing telemetry item—for example:
    operation.telemetry.responseCode = "200";

    // Optional: explicitly send telemetry item:
    client.stopOperation(operation);

}, operation.context)(); // When callback completes, telemetry item is sent.

Tillsammans med att ange en åtgärdskontext StartOperation skapar ett telemetriobjekt av den typ som du anger. Den skickar telemetriobjektet när du tar bort åtgärden eller om du uttryckligen anropar StopOperation. Om du använder RequestTelemetry som telemetrityp är dess varaktighet inställd på det tidsintervall mellan start och stopp.

Telemetriobjekt som rapporteras inom ett driftsområde blir underordnade objekt till en sådan operation. Åtgärdskontexter kan kapslas.

I Sök används åtgärdskontexten för att skapa listan Relaterade objekt .

Mer information om spårning av anpassade åtgärder finns i Spåra anpassade åtgärder med Application Insights .NET SDK.

Begäranden i Log Analytics

I Application Insights Analytics visas begäranden i requests tabellen.

Om samplingen är i drift visar egenskapen itemCount ett värde som är större än 1. Innebär till exempel itemCount==10 att av 10 anrop till trackRequest()överförde samplingsprocessen bara en av dem. Om du vill få ett korrekt antal begäranden och genomsnittlig varaktighet segmenterade efter begärandenamn använder du kod som:

requests
| summarize count = sum(itemCount), avgduration = avg(duration) by name

TrackException

Skicka undantag till Application Insights:

• Att räkna dem, som en indikation på frekvensen för ett problem.
• För att undersöka enskilda förekomster.

Rapporterna innehåller stackspårningsinformation.

try
{
    ...
}
catch (Exception ex)
{
    telemetry.TrackException(ex);
}

try
{
    ...
}
catch (ex)
{
    telemetry.trackException({exception: ex});
}

SDK:erna fångar upp många undantag automatiskt, så du behöver inte alltid anropa TrackException explicit.

Undantag i Log Analytics

I Application Insights Analytics visas undantag i exceptions tabellen.

Om samplingen är i drift visar egenskapen itemCount ett värde som är större än 1. Innebär till exempel itemCount==10 att av 10 anrop till trackException()överförde samplingsprocessen bara en av dem. Om du vill få ett korrekt antal undantag segmenterade efter typ av undantag använder du kod som:

exceptions
| summarize sum(itemCount) by type

Det mesta av den viktiga stackinformationen extraheras redan i separata variabler, men du kan dra isär details strukturen för att få mer. Eftersom den här strukturen är dynamisk bör du omvandla resultatet till den typ du förväntar dig. Till exempel:

exceptions
| extend method2 = tostring(details[0].parsedStack[1].method)

Om du vill associera undantag med deras relaterade begäranden använder du en koppling:

exceptions
| join (requests) on operation_Id

TrackTrace

Använd TrackTrace för att diagnostisera problem genom att skicka en "breadcrumb trail" till Application Insights. Du kan skicka delar av diagnostikdata och inspektera dem i Diagnostiksökning.

telemetry.TrackTrace(message, SeverityLevel.Warning, properties);

telemetry.trackTrace({
    message: message,
    severity: applicationInsights.Contracts.SeverityLevel.Warning,
    properties: properties
});

Logga en diagnostikhändelse som att ange eller lämna en metod.

Du kan söka efter meddelandeinnehåll, men till skillnad från egenskapsvärden kan du inte filtrera på det.

Storleksgränsen på message är mycket högre än gränsen för egenskaper. En fördel TrackTrace med är att du kan placera relativt långa data i meddelandet. Du kan till exempel koda POST-data där.

Du kan också lägga till en allvarlighetsgrad i meddelandet. Och precis som andra telemetrier kan du lägga till egenskapsvärden som hjälper dig att filtrera eller söka efter olika uppsättningar spårningar. Till exempel:

var telemetry = new Microsoft.ApplicationInsights.TelemetryClient();
telemetry.TrackTrace("Slow database response",
                SeverityLevel.Warning,
                new Dictionary<string,string> { {"database", db.ID} });

I Sök kan du sedan enkelt filtrera bort alla meddelanden på en viss allvarlighetsnivå som är relaterade till en viss databas.

Spårningar i Log Analytics

I Application Insights Analytics visas anrop till TrackTrace i traces-tabellen.

Om samplingen är i drift visar egenskapen itemCount ett värde som är större än 1. Innebär till exempel itemCount==10 att av 10 anrop till trackTrace()överförde samplingsprocessen bara en av dem. Om du vill få ett korrekt antal spårningsanrop använder du kod som traces | summarize sum(itemCount).

TrackDependency

Använd anropet TrackDependency för att spåra svarstiderna och framgångsfrekvensen för anrop till en extern kod. Resultaten visas i beroendediagrammen i portalen. Följande kodfragment måste läggas till varhelst ett beroendeanrop görs.

var success = false;
var startTime = DateTime.UtcNow;
var timer = System.Diagnostics.Stopwatch.StartNew();
try
{
    success = dependency.Call();
}
catch(Exception ex)
{
    success = false;
    telemetry.TrackException(ex);
    throw new Exception("Operation went wrong", ex);
}
finally
{
    timer.Stop();
    telemetry.TrackDependency("DependencyType", "myDependency", "myCall", startTime, timer.Elapsed, success);
}

var success = false;
var startTime = new Date().getTime();
try
{
    success = dependency.Call();
}
finally
{
    var elapsed = new Date() - startTime;
    telemetry.trackDependency({
        dependencyTypeName: "myDependency",
        name: "myCall",
        duration: elapsed,
        success: success
    });
}

Kom ihåg att server-SDK:erna innehåller en beroendemodul som identifierar och spårar vissa beroendeanrop automatiskt, till exempel till databaser och REST-API:er. Du måste installera en agent på servern för att modulen ska fungera.

Du använder det här anropet om du vill spåra anrop som den automatiserade spårningen inte fångar upp.

Om du vill inaktivera standardmodulen för beroendespårning i C# redigerar duApplicationInsights.config och tar bort referensen till DependencyCollector.DependencyTrackingTelemetryModule.

Beroenden i Log Analytics

I Application Insights AnalyticstrackDependency visas anrop upp i dependencies tabellen.

Om samplingen är i drift visar egenskapen itemCount ett värde som är större än 1. Innebär till exempel itemCount==10 att av 10 anrop till trackDependency()överförde samplingsprocessen bara en av dem. Om du vill få ett korrekt antal beroenden segmenterade efter målkomponent använder du kod som:

dependencies
| summarize sum(itemCount) by target

Om du vill associera beroenden med deras relaterade begäranden använder du en sammanfogning:

dependencies
| join (requests) on operation_Id

Rensa data

Normalt skickar SDK:t data med fasta intervall, vanligtvis 30 sekunder, eller när bufferten är full, vilket vanligtvis är 500 objekt. I vissa fall kanske du vill tömma bufferten. Ett exempel är om du använder SDK:t i ett program som stängs av.

telemetry.Flush();
// Allow some time for flushing before shutdown.
System.Threading.Thread.Sleep(5000);

await telemetryClient.FlushAsync()
// No need to sleep

telemetry.flush();

Autentiserade användare

I en webbapp identifieras användare som standard med cookies . En användare kan räknas mer än en gång om de kommer åt din app från en annan dator eller webbläsare, eller om de tar bort cookies.

Om användarna loggar in på din app kan du få ett mer exakt antal genom att ange det autentiserade användar-ID:t i webbläsarkoden. Det är inte nödvändigt att använda användarens faktiska inloggningsnamn. Det behöver bara vara ett ID som är unikt för den användaren. Den får inte innehålla mellanslag eller någon av tecknen ,;=|.

Användar-ID:t anges också i en sessionscookie och skickas till servern. Om server-SDK:t är installerat skickas det autentiserade användar-ID:t som en del av kontextegenskaperna för både klient- och servertelemetri. Du kan sedan filtrera och söka på den.

Om appen grupperar användare till konton kan du också skicka en identifierare för kontot. Samma teckenbegränsningar gäller.

I Metrics Explorer kan du skapa ett diagram som räknar användare, autentiserade och användarkonton.

Du kan också söka efter klientdatapunkter med specifika användarnamn och konton.

Filtrera, söka efter och segmentera dina data med hjälp av egenskaper

Du kan koppla egenskaper och mått till dina händelser, mått, sidvisningar, undantag och andra telemetridata.

Egenskaper är strängvärden som du kan använda för att filtrera telemetrin i användningsrapporterna. Om din app till exempel tillhandahåller flera spel kan du koppla namnet på spelet till varje händelse så att du kan se vilka spel som är mer populära.

Det finns en gräns på 8 192 för stränglängden. Om du vill skicka stora datasegment använder du meddelandeparametern TrackTraceför .

Mått är numeriska värden som kan visas grafiskt. Du kanske till exempel vill se om det sker en gradvis ökning av poängen som dina spelare uppnår. Graferna kan segmenteras efter de egenskaper som skickas med händelsen så att du kan få separata eller staplade grafer för olika spel.

Måttvärdena ska vara större än eller lika med 0 för att visas korrekt.

Det finns vissa begränsningar för antalet egenskaper, egenskapsvärden och mått som du kan använda.

// Set up some properties and metrics:
var properties = new Dictionary <string, string>
    {{"game", currentGame.Name}, {"difficulty", currentGame.Difficulty}};
var metrics = new Dictionary <string, double>
    {{"Score", currentGame.Score}, {"Opponents", currentGame.OpponentCount}};

// Send the event:
telemetry.TrackEvent("WinGame", properties, metrics);

// Set up some properties and metrics:
var properties = {"game": currentGame.Name, "difficulty": currentGame.Difficulty};
var metrics = {"Score": currentGame.Score, "Opponents": currentGame.OpponentCount};

// Send the event:
telemetry.trackEvent({name: "WinGame", properties: properties, measurements: metrics});

Alternativt sätt att ange egenskaper och mått

Om det är enklare kan du samla in parametrarna för en händelse i ett separat objekt:

var event = new EventTelemetry();

event.Name = "WinGame";
event.Metrics["processingTime"] = stopwatch.Elapsed.TotalMilliseconds;
event.Properties["game"] = currentGame.Name;
event.Properties["difficulty"] = currentGame.Difficulty;
event.Metrics["Score"] = currentGame.Score;
event.Metrics["Opponents"] = currentGame.Opponents.Length;

telemetry.TrackEvent(event);

Anpassade mått och egenskaper i Log Analytics

I Log Analytics visas anpassade mått och egenskaper i attributen customMeasurements och customDimensions för varje telemetripost.

Om du till exempel lägger till en egenskap med namnet "game" i din begärans telemetri räknar frågan förekomsterna av olika värden av "game" och visar medelvärdet av det anpassade måttet "score".

requests
| summarize sum(itemCount), avg(todouble(customMeasurements.score)) by tostring(customDimensions.game)

Observera att:

• När du extraherar ett värde från customDimensions eller customMeasurements JSON har det en dynamisk typ, så du måste omvandla det tostring eller todouble.
• Om du vill ta hänsyn till möjligheten till sampling ska du inte sum(itemCount)använda count() .

Tidshändelser

Ibland vill du visa hur lång tid det tar att utföra en åtgärd. Du kanske till exempel vill veta hur lång tid det tar för användarna att överväga val i ett spel. Använd måttparametern för att hämta den här informationen.

var stopwatch = System.Diagnostics.Stopwatch.StartNew();

// ... perform the timed action ...

stopwatch.Stop();

var metrics = new Dictionary <string, double>
    {{"processingTime", stopwatch.Elapsed.TotalMilliseconds}};

// Set up some properties:
var properties = new Dictionary <string, string>
    {{"signalSource", currentSignalSource.Name}};

// Send the event:
telemetry.TrackEvent("SignalProcessed", properties, metrics);

Standardegenskaper för anpassad telemetri

Om du vill ange standardegenskapsvärden för några av de anpassade händelser som du skriver anger du dem i en TelemetryClient instans. De är kopplade till varje telemetriobjekt som skickas från klienten.

using Microsoft.ApplicationInsights.DataContracts;

var gameTelemetry = new TelemetryClient();
gameTelemetry.Context.GlobalProperties["Game"] = currentGame.Name;
// Now all telemetry is automatically sent with the context property:
gameTelemetry.TrackEvent("WinGame");

var gameTelemetry = new applicationInsights.TelemetryClient();
gameTelemetry.commonProperties["Game"] = currentGame.Name;

gameTelemetry.TrackEvent({name: "WinGame"});

Enskilda telemetrianrop kan åsidosätta standardvärdena i sina egenskapsordlistor.

Om du vill lägga till egenskaper för all telemetri, inklusive data från standardsamlingsmoduler, implementerar du ITelemetryInitializer.

Inaktivera telemetri

För att dynamiskt stoppa och starta insamling och överföring av telemetri:

using  Microsoft.ApplicationInsights.Extensibility;

TelemetryConfiguration.Active.DisableTelemetry = true;

telemetry.config.disableAppInsights = true;

applicationInsights.setup()
    .setAutoCollectRequests(false)
    .setAutoCollectPerformance(false)
    .setAutoCollectExceptions(false)
    .setAutoCollectDependencies(false)
    .setAutoCollectConsole(false)
    .start();

Utvecklarläge

När du felsöker är det fördelaktigt att telemetrin skickas snabbare genom bearbetningskedjan så att du kan se resultaten omedelbart. Du får även andra meddelanden som hjälper dig att spåra eventuella problem med telemetrin. Stäng av den i produktion eftersom den kan göra din app långsammare.

TelemetryConfiguration.Active.TelemetryChannel.DeveloperMode = true;

applicationInsights.setup("ikey")
  .setInternalLogging(true, true)
  .start()
applicationInsights.defaultClient.config.maxBatchSize = 0;

Ange instrumentationsnyckeln för vald anpassad telemetri

var telemetry = new TelemetryClient();
telemetry.InstrumentationKey = "---my key---";
// ...

Dynamisk anslutningssträng

För att undvika att blanda telemetri från utvecklings-, test- och produktionsmiljöer kan du skapa separata Application Insights-resurser och ändra deras nycklar beroende på miljön.

I stället för att hämta instrumentationsnyckeln från konfigurationsfilen kan du ange den i koden. Ange nyckeln i en initieringsmetod, till exempel global.aspx.cs i en ASP.NET tjänst:

protected void Application_Start()
{
    Microsoft.ApplicationInsights.Extensibility.
    TelemetryConfiguration.Active.InstrumentationKey =
        // - for example -
        WebConfigurationManager.Settings["ikey"];
    ...
}

TelemetriContext

TelemetryClient har en kontextegenskap som innehåller värden som skickas tillsammans med alla telemetridata. De anges normalt av standardtelemetrimodulerna, men du kan också ange dem själv. Till exempel:

telemetry.Context.Operation.Name = "MyOperationName";

Om du anger något av dessa värden själv kan du överväga att ta bort relevant rad från ApplicationInsights.config så att dina värden och standardvärdena inte blir förvirrade.

• Komponent: Appen och dess version.
• Enhet: Data om enheten där appen körs. I webbappar är det den server eller klientenhet som telemetrin skickas från.
• InstrumentationKey: Application Insights-resursen i Azure där telemetrin visas. Den hämtas vanligtvis från ApplicationInsights.config.
• Plats: Enhetens geografiska plats.
• Åtgärd: I webbappar, den aktuella HTTP-begäran. I andra apptyper kan du ange det här värdet för att gruppera händelser tillsammans.
  • ID: Ett genererat värde som korrelerar olika händelser så att du kan hitta relaterade objekt när du inspekterar en händelse i Diagnostiksökning.
  • Namn: En identifierare, vanligtvis URL:en för HTTP-begäran.
  • SyntheticSource: Om den inte är null eller tom har en sträng som anger att källan till begäran har identifierats som en robot eller ett webbtest. Som standard undantas den från beräkningar i Metrics Explorer.
• Session: Användarens session. ID:t är inställt på ett genererat värde som ändras när användaren inte har varit aktiv på ett tag.
• Användare: Användarinformation.

Gränser

Det finns vissa gränser för antalet mått och händelser per program, dvs. per instrumentationsnyckel. Gränserna beror på vilken prisplan du väljer.

Mer information om priser och kvoter finns i Application Insights-fakturering.

Om du vill undvika att nå datahastighetsgränsen använder du sampling.

Information om hur länge data sparas finns i Datakvarhållning och sekretess.

Felsökning

Felsökningsinformation, inklusive scenarier utan data och anpassning av loggar, finns i Felsöka Application Insights-övervakning av Node.js appar och tjänster.

Nästa steg

• Mer information om vanliga frågor och svar finns i:
  • Vanliga frågor och svar omNode.js
  • Vanliga frågor och svar om Application Insights API för anpassade händelser och mått
• Övervaka telemetrin i portalen.
• Lär dig hur du använder Log Analytics och skriver analysfrågor via din telemetri.