Hantera användning och kostnader för Application Insights

Program Insights har utformats för att få allt du behöver för att övervaka tillgänglighet, prestanda och användning av dina webbprogram, oavsett om de finns i Azure eller lokalt. Program Insights stöder populära språk och ramverk, till exempel .NET, Java och Node.js, och integreras med DevOps-processer och verktyg som Azure DevOps, Jira och PagerDuty. Det är viktigt att förstå vad som avgör kostnaderna för att övervaka dina program. I den här artikeln går vi igenom vad som driver dina kostnader för programövervakning och hur du proaktivt kan övervaka och kontrollera dem.

Om du har frågor om hur prissättningen fungerar för Application Insights kan du ställa en fråga på vår Microsoft Q&A question page (En fråga).

Prismodell

Prissättningen för Azure Application Insights är en Betala per användning-modell baserad på datavolym som matats in och eventuellt för längre databevarande. Varje programresurs Insights debiteras som en separat tjänst och bidrar till fakturan för din Azure-prenumeration. Datavolymen mäts som storleken på det okomprimerade JSON-datapaketet som tas emot av Application Insights från ditt program. Datavolymen mäts i GB (10^9 byte). Det debiteras ingen datavolym för att använda Live Metrics Stream. På din Azure-faktura eller i Azure Cost Management + Billingrapporteras din datainmatning och databevarande för en klassisk Application Insights-resurs med mätarkategorin Log Analytics.

Webbtester i flera steg medför en extra avgift. Webbtester i flera steg är webbtester som utför en sekvens med åtgärder. Det finns ingen separat avgift för ping-tester av en enda sida. Telemetri från pingtester och flerstegstester debiteras på samma sätt som annan telemetri från din app.

Alternativet Application Insights enable alerting on custom metric dimensions (Aktivera aviseringar för anpassade måttdimensioner) kan också generera ytterligare kostnader eftersom detta kan leda till att ytterligare föraggregeringsmått skapas. Läs mer om loggbaserade och föraggregeringsmått i Application Insights och om priser för Azure Monitor anpassade mått.

Arbetsytebaserad Insights

För Application Insights-resurser som skickar sina data till en Log Analytics-arbetsyta, som kallas arbetsytebaserade Application Insights-resurser, sker faktureringen för datainmatning och kvarhållning av arbetsytan där Application Insights-datafinns. På så sätt kan du utnyttja alla alternativ i Log Analytics-prismodellen, inklusive åtagandenivåer utöver Betala per användning. Åtagandenivåer erbjuder priser upp till 30 % lägre än Betala per användning. Log Analytics har också fler alternativ för databevarande, inklusive kvarhållning efter datatyp. Program Insights datatyper på arbetsytan får 90 dagars kvarhållning utan avgifter. Användning av webbtester och aktivering av aviseringar för anpassade måttdimensioner rapporteras fortfarande via Application Insights. Lär dig hur du spårar kostnader för datainmatning och kvarhållning i Log Analytics med hjälp av användning och uppskattade kostnader, Azure Cost Management + Billing och Log Analytics-frågor.

Beräkna kostnaderna för att hantera ditt program

Om du inte använder Application Insights än kan du använda priskalkylatorn Azure Monitor för att beräkna kostnaden för att använda Insights. Börja med att Azure Monitor" i sökrutan och klicka på den resulterande Azure Monitor panelen. Rulla ned på sidan för Azure Monitor och expandera avsnittet Program Insights program. Dina uppskattade kostnader beror på mängden loggdata som matas in. Det finns två sätt att beräkna datavolymer:

1. uppskatta din sannolika datainmatning baserat på vad andra liknande program genererar, eller
2. användning av standardövervakning och adaptiv sampling, som är tillgänglig i ASP.NET SDK.

Lär dig av vad liknande program samlar in

I priskalkylatorn för Azure-övervakning för Insights klickar du på för att aktivera Beräkna datavolym baserat på programaktivitet. Här kan du ange indata om ditt program (begäranden per månad och sidvisningar per månad, om du samlar in telemetri på klientsidan) och sedan visar kalkylatorn medianen och den 90:e percentilen av data som samlas in av liknande program. Dessa program sträcker sig över intervallet för Application Insights-konfiguration (vissa har standardsampling, vissa har ingen sampling osv.), så du har fortfarande kontrollen för att minska mängden data som du matar in långt under mediannivån med hjälp av sampling.

Datainsamling vid användning av sampling

Med ASP.NET SDK:ns anpassningsbara sampling justeras datavolymen automatiskt för att hålla inom en angiven högsta trafikhastighet för standardprogramövervakning Insights. Om programmet genererar en låg mängd telemetri, till exempel vid felsökning eller på grund av låg användning, kommer objekt inte att tas bort av samplingsprocessorn så länge volymen är under de konfigurerade händelserna per sekund-nivå. För ett program med hög volym, med standardtröskelvärdet fem händelser per sekund, begränsar anpassningsbar sampling antalet dagliga händelser till 432 000. Med en genomsnittlig händelsestorlek på 1 kB motsvarar detta 13,4 GB telemetri per 31-dagars månad per nod som är värd för ditt program eftersom samplingen görs lokalt för varje nod.

För SDK:er som inte stöder adaptiv sampling kan du använda inmatningssampling ,som exempel när data tas emot av Application Insights baserat på en procentandel data som ska behållas eller sampling med fast hastighet för ASP.NET-, ASP.NET Core- och Java-webbplatser för att minska trafiken som skickas från webbservern och webbläsaren

Visa programanvändning Insights din Azure-faktura

Det enklaste sättet att se den fakturerade användningen för en enda Application Insights-resurs som inte är en arbetsyteresurs är att gå till resursens översiktssida och klicka på Visa kostnad i det övre högra hörnet. Du kan behöva ytterligare åtkomst till Cost Management data(läs mer).

Om du vill veta mer tillhandahåller Azure en mängd användbara funktioner i Azure Cost Management + Billing hubben. Med funktionen "Kostnadsanalys" kan du till exempel visa dina utgifter för Azure-resurser. Genom att lägga till ett filter efter resurstyp (till microsoft.insights/components för Application Insights) kan du spåra dina utgifter. För "Gruppera efter" väljer du sedan "Mätarkategori" eller "Mätare". Observera att application Insights fakturerad användning för datainmatning och databevarande visas som Log Analytics för mätarkategorin sedan Log Analytics-backend för alla Azure Monitor loggar.

Du kan få ännu mer förståelse för din användning genom att ladda ned din användning från Azure Portal. I det nedladdade kalkylbladet kan du se användning per Azure-resurs per dag. I det här Excel-kalkylbladet kan du hitta användning från dina Application Insights-resurser genom att först filtrera på kolumnen "Mätarkategori" för att visa "Application Insights" och "Log Analytics" och sedan lägga till ett filter på kolumnen "Instans-ID" som är "contains microsoft.insights/components". Den Insights programanvändningen rapporteras på mätare med mätarkategorin för Log Analytics, eftersom det finns en enda loggbackend för alla Azure Monitor komponenter. Endast program Insights resurser på äldre prisnivåer och webbtester i flera steg rapporteras med en mätarkategori för Insights. Användningen visas i kolumnen "Förbrukad kvantitet" och enheten för varje post visas i kolumnen "Måttenhet". Mer information som hjälper dig att förstå Microsoft Azure-fakturan.

Förstå din användning och optimera dina kostnader

Program Insights gör det enkelt att förstå vilka kostnader som sannolikt kommer att baseras på de senaste användningsmönstren. Kom igång genom att gå Azure Portal programresursen Insights programresursen på sidan Användning och uppskattade kostnader:

A. Granska din datavolym för månaden. Detta inkluderar alla data som tas emot och bevaras (efter eventuella samplingar)från servern och klientapparna, samt från tillgänglighetstester.
B. En separat avgift debiteras för webbtester med flera steg. (Detta omfattar inte enkla tillgänglighetstester som ingår i datavolymavgiften.)
C. Visa datavolymtrender för den senaste månaden.
D. Aktivera datainmatningssampling . E. Ange det dagliga datavolymtaket.

(Observera att alla priser som visas i skärmbilder i den här artikeln endast är exempel. Aktuella priser i din valuta och region finns i Application Insights pricing.)

Om du vill undersöka din Application Insights-användning mer djupt öppnar du sidan Mått, lägger till måttet "Datapunktvolym" och väljer sedan alternativet Tillämpa delning för att dela data med "Objekttyp för telemetri".

Program Insights avgifter läggs till på Din Azure-faktura. Du kan se information om din Azure-faktura i Cost Management + Billing i Azure Portal eller i Azure-faktureringsportalen. Nedan finns information om hur du använder detta för Application Insights.

Använda mått för datavolym

Om du vill veta mer om dina datavolymer kan du välja Mått för Insights programresursen genom att lägga till ett nytt diagram. För diagrammåttet går du till Loggbaserade mått och väljer Datapunktvolym. Klicka på Tillämpa delning och välj gruppera efter Telemetryitem typ.

Frågor för att förstå information om datavolym

Det finns två sätt att undersöka datavolymer för Application Insights. Den första använder aggregerad information i tabellen och den andra använder egenskapen systemEvents , som är tillgänglig för varje _BilledSize intagen händelse. systemEvents kommer inte att ha information om datastorlek för arbetsytebaserade application-insights.

Använda aggregerad information om datavolym

Du kan till exempel använda tabellen systemEvents för att se datavolymen som matats in under de senaste 24 timmarna med frågan:

systemEvents
| where timestamp >= ago(24h)
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes)

Om du vill se ett diagram över datavolym (i byte) efter datatyp under de senaste 30 dagarna kan du använda:

systemEvents
| where timestamp >= startofday(ago(30d))
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes) by BillingTelemetryType, bin(timestamp, 1d) | render barchart  

Observera att den här frågan kan användas i en Azure-loggavisering för att ställa in aviseringar för datavolymer.

Om du vill veta mer om dina ändringar av telemetridata kan vi hämta antalet händelser efter typ med hjälp av frågan:

systemEvents
| where timestamp >= startofday(ago(30d))
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| summarize count() by BillingTelemetryType, bin(timestamp, 1d)
| render barchart  

Använda datastorlek per händelseinformation

Om du vill veta mer om källan för dina datavolymer kan du använda _BilledSize egenskapen som finns vid varje indatahändelse.

För att till exempel titta på vilka åtgärder som genererar mest datavolym under de senaste 30 dagarna kan vi summera _BilledSize för alla beroendehändelser:

dependencies
| where timestamp >= startofday(ago(30d))
| summarize sum(_BilledSize) by operation_Name
| render barchart  

Datavolym för arbetsytebaserade program Insights resurser

Om du vill titta på datavolymtrenderna för alla arbetsytebaserade Application Insights-resurser på en arbetsyta under den senaste veckan går du till Log Analytics-arbetsytan och kör frågan:

union (AppAvailabilityResults),
      (AppBrowserTimings),
      (AppDependencies),
      (AppExceptions),
      (AppEvents),
      (AppMetrics),
      (AppPageViews),
      (AppPerformanceCounters),
      (AppRequests),
      (AppSystemEvents),
      (AppTraces)
| where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now())
| summarize sum(_BilledSize) by _ResourceId, bin(TimeGenerated, 1d)
| render areachart

Om du vill fråga efter datavolymtrender efter typ för en specifik arbetsytebaserad programresurs Insights i Log Analytics-arbetsytan använder du:

union (AppAvailabilityResults),
      (AppBrowserTimings),
      (AppDependencies),
      (AppExceptions),
      (AppEvents),
      (AppMetrics),
      (AppPageViews),
      (AppPerformanceCounters),
      (AppRequests),
      (AppSystemEvents),
      (AppTraces)
| where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now())
| where _ResourceId contains "<myAppInsightsResourceName>"
| summarize sum(_BilledSize) by Type, bin(TimeGenerated, 1d)
| render areachart

Hantera din datavolym

Den mängd data som du skickar kan hanteras med hjälp av följande metoder:

• Sampling: Du kan använda sampling för att minska mängden telemetri som skickas från din server och dina klientappar, med minimal förvrängning av mått. Sampling är det primära verktyget som du kan använda för att justera mängden data som du skickar. Läs mer om samplingsfunktioner.

• Begränsa Ajax-anrop: Du kan begränsa antalet Ajax-anrop som kan rapporteras i varje sidvy eller inaktivera Ajax-rapportering. Observera att om du inaktiverar Ajax-anrop inaktiveras JavaScript-korrelationen.

• Inaktivera moduler som inte behövs: Redigera ApplicationInsights.config att inaktivera samlingsmoduler som du inte behöver. Du kan till exempel bestämma att prestandaräknare eller beroendedata är oberoende.

• Föraggregeringsmått: Om du gör anrop till TrackMetric i din app kan du minska trafiken med hjälp av den överlagring som accepterar beräkningen av medelvärdet och standardavvikelsen för en batch med mått. Eller så kan du använda ett föraggregeringspaket.

• Dagligt tak: När du skapar Insights programresurs i Azure Portal anges det dagliga taket till 100 GB/dag. När du skapar en programresurs Insights i Visual Studio är standardvärdet litet (endast 32,3 MB/dag). Standardvärdet för dagligt tak är inställt för att underlätta testning. Avsikten är att användaren ska höja det dagliga taket innan appen distribueras till produktion.

  Det maximala taket i Insights är 1 000 GB/dag om du inte begär en högre maxnivå för ett program med hög trafik.

  Tips

  Om du har en arbetsytebaserad Application Insights-resurs rekommenderar vi att du använder arbetsytans dagliga tak för att begränsa inmatning och kostnader i stället för taket i Insights.

  Varningsmeddelanden om det dagliga taket skickas till konton som är medlemmar i dessa roller för din Application Insights-resurs: "ServiceAdmin", "AccountAdmin", "CoAdmin", "Owner".

  Var försiktig när du anger den dagliga gränsen. Avsikten bör vara att aldrig komma upp i det dagliga taket. Om du når den dagliga gränsen går data för resten av dagen förlorade och du kan inte övervaka ditt program. Om du vill ändra det dagliga taket använder du alternativet Dagligt volymtak. Du kan komma åt det här alternativet i fönstret Användning och uppskattade kostnader (detta beskrivs i detalj senare i artikeln).

  Vi har tagit bort begränsningen för vissa prenumerationstyper som har krediter som inte kunde användas för Insights. Om prenumerationen tidigare har en utgiftsgräns innehåller dialogrutan för dagligt tak instruktioner för att ta bort utgiftsgränsen och aktivera att det dagliga taket höjs till mer än 32,3 MB/dag.

• Begränsning: Begränsning begränsar datahastigheten till 32 000 händelser per sekund, i genomsnitt över 1 minut per instrumentationsnyckel. Mängden data som appen skickar utvärderas varje minut. Om den överskrider det genomsnittliga priset per sekund under minuten nekar servern vissa begäranden. SDK buffrar data och försöker sedan skicka dem igen. Det sprider ut en ökning över flera minuter. Om din app konsekvent skickar data med högre hastighet än begränsningshastigheten, kommer vissa data att tas bort. (De ASP.NET-, Java- och JavaScript-SDK:erna försöker skicka data på nytt på det här sättet. Andra SDK:er kan helt enkelt ta bort begränsade data.) Om begränsning inträffar får du en aviseringsvarning om att detta har inträffat.

Hantera din maximala dagliga datavolym

Du kan använda det dagliga volymtaket för att begränsa de data som samlas in. Om taket uppfylls går dock all telemetri som skickas från programmet förlorad under resten av dagen. Det är inte lämpligt att se till att programmet nås det dagliga taket. Du kan inte spåra hälsotillstånd och prestanda för ditt program när det når det dagliga taket.

I stället för att använda det dagliga volymtaket använder du sampling för att justera datavolymen till den nivå du vill ha. Använd sedan det dagliga taket endast som en "sista utväg" om ditt program oväntat börjar skicka mycket högre volymer telemetri.

Identifiera vilken daglig datagräns som ska definieras

Gå igenom Insights användning och uppskattade kostnader för att förstå datainmatningstrenden och vad som är det dagliga volymtaket att definiera. Det bör övervägas med försiktighet eftersom du inte kan övervaka dina resurser när gränsen har nåtts.

Ange dagligt tak

Om du vill ändra det dagliga taket går du till avsnittet Konfigurera för programresursen Insights programresursen och på sidan Användning och uppskattade kostnader väljer du Dagligt tak.

Om du vill ändra det dagliga taket via Azure Resource Manager, är egenskapen som ska ändras dailyQuota . Via Azure Resource Manager kan du också ange dailyQuotaResetTime och det dagliga takets warningThreshold .

Skapa aviseringar för det dagliga taket

Application Insights Cap skapar en händelse i Azure-aktivitetsloggen när de inkommande datavolymerna når varningsnivån eller den dagliga taknivån. Du kan skapa en avisering baserat på dessa aktivitetslogghändelser. Signalnamnen för dessa händelser är:

• Tröskelvärdet för Insights för programkomponentens dagliga tak har nåtts

• Det dagliga Insights för programkomponenten har nåtts

Samling

sampling är en metod för att minska den frekvens med vilken telemetri skickas till din app, samtidigt som du behåller möjligheten att hitta relaterade händelser under diagnostiksökningar. Du behåller också rätt händelseantal.

Sampling är ett effektivt sätt att minska kostnaderna och hålla dig inom din månadskvot. Samplingsalgoritmen behåller relaterade telemetriobjekt, så när du till exempel använder Sök kan du hitta begäran som rör ett visst undantag. Algoritmen behåller också rätt antal så att du ser rätt värden i Metric Explorer för begärandefrekvenser, undantagsfrekvenser och andra antal.

Det finns flera typer av sampling.

• Adaptiv sampling är standard för ASP.NET SDK. Adaptiv sampling justeras automatiskt efter mängden telemetri som din app skickar. Den fungerar automatiskt i SDK:n i webbappen så att telemetritrafiken i nätverket minskas.
• Inmatningssampling är ett alternativ som fungerar vid den punkt där telemetri från din app kommer Insights programtjänsten. Inmatningssampling påverkar inte mängden telemetri som skickas från din app, men det minskar den volym som behålls av tjänsten. Du kan använda inmatningssampling för att minska kvoten som används av telemetri från webbläsare och andra SDK:er.

Om du vill ange inmatningssampling går du till fönstret Prissättning:

Om du vill identifiera den faktiska samplingsfrekvensen, oavsett var den har tillämpats, använder du en Analytics-fråga. Frågan ser ut så här:

requests | where timestamp > ago(1d)
| summarize 100/avg(itemCount) by bin(timestamp, 1h)
| render areachart

I varje kvarhållen post itemCount anger antalet ursprungliga poster som den representerar. Det är lika med 1 + antalet tidigare bortkastade poster.

Ändra kvarhållningsperioden för data

Standardvärdet för kvarhållning av Insights programresurser är 90 dagar. Olika kvarhållningsperioder kan väljas för varje Program Insights resurs. Den fullständiga uppsättningen tillgängliga kvarhållningsperioder är 30, 60, 90, 120, 180, 270, 365, 550 eller 730 dagar. Läs mer om priser för längre datalagring.

Om du vill ändra kvarhållningen går Insights programresursen till sidan Användning och uppskattade kostnader och väljer alternativet Datalagring:

När kvarhållningen sänks finns det en respitperiod på flera dagar innan de äldsta data tas bort.

Kvarhållningen kan också anges programmatiskt med hjälp av PowerShell med hjälp av retentionInDays parametern . Om du ställer in datalagringen på 30 dagar kan du utlösa en omedelbar rensning av äldre data med hjälp av parametern , vilket kan vara användbart för immediatePurgeDataOn30Days kompatibilitetsrelaterade scenarier. Den här rensningsfunktionen exponeras endast via Azure Resource Manager och bör användas med extrem försiktighet. Den dagliga återställningstiden för datavolymtaket kan konfigureras med hjälp Azure Resource Manager för att ange dailyQuotaResetTime parametern.

Avgifter för dataöverföring med application Insights

Att skicka data till Insights kan medföra avgifter för databandbredd. Enligt beskrivningen på sidan med priser för Azure-bandbreddså debiteras dataöverföring mellan Azure-tjänster i två regioner som utgående dataöverföring enligt normalpris. Inkommande dataöverföring är kostnadsfri. Den här avgiften är dock mycket liten (få %) jämfört med kostnaderna för Insights för inmatning av loggdata. Därför måste du kontrollera kostnaderna för Log Analytics och fokusera på din indatavolym, och vi har vägledning som hjälper dig att förstå det här.

Sammanfattning av gränser

Det finns vissa begränsningar för antalet mått och händelser per program, det vill säga per Instrumentation-nyckel. Gränserna beror på vilken prisplan du väljer.

Mer information finns i Om priser och kvoter i Application Insights.

Inaktivera e-postmeddelanden med dagligt tak

Om du vill inaktivera e-post med det dagliga volymtaket går du till avsnittet Konfigurera för din Application Insights-resurs och väljer Dagligt tak i fönstret Användning och uppskattade kostnader. Det finns inställningar för att skicka e-post när taket har nåtts, samt när en justerbar varningsnivå har nåtts. Avmarkera båda rutorna om du vill inaktivera alla e-postmeddelanden relaterade till det dagliga taket.

Prisnivå för äldre företag (per nod)

För tidiga Azure Application Insights finns det fortfarande två möjliga prisnivåer: Basic och Enterprise. Prisnivån Basic är samma som den som beskrivs ovan och är standardnivån. Den innehåller alla funktioner på Enterprise-nivån utan extra kostnad. Basic-nivån debiterar främst den datavolym som matas in.

Dessa äldre prisnivåer har bytt namn. Enterprise-prisnivån heter nu Per nod och prisnivån Basic heter nu Per GB. Dessa nya namn används nedan och i Azure Portal.

Nivån Per nod (tidigare Enterprise) har en avgift per nod och varje nod får en daglig tillåtna datamängd. På prisnivån Per nod debiteras du för data som matas in ovanför den inkluderade tillåtna. Om du använder Operations Management Suite bör du välja nivån Per nod. I april 2018 introducerade vi en ny prismodell för Azure-övervakning. Den här modellen använder en enkel "betala per du-tjänst"-modell i hela portföljen med övervakningstjänster. Läs mer om den nya prismodellen.

Aktuella priser i din valuta och region finns i Insights priser.

Förstå fakturerad användning på den äldre Enterprise-nivån (per nod)

Enligt beskrivningen nedan i detalj kombinerar den äldre Enterprise-nivån (per nod) användning från alla Application Insights-resurser i en prenumeration för att beräkna antalet noder och dataöverförbrukning. På grund av den här kombinationsprocessen rapporteras användning för alla Application Insights-resurser i en prenumeration mot bara en av resurserna . Detta gör det mycket komplicerat att stämma av din fakturerade användning med den användning som du observerar för Insights programresurser.

Prenumerationsberättiganden per nodnivå och Operations Management Suite

Kunder som köper Operations Management Suite E1 och E2 kan hämta program från Insights per nod som en ytterligare komponent utan extra kostnad enligt tidigare tillkännagivit. Mer specifikt innehåller varje enhet i Operations Management Suite E1 och E2 en rättighet till en nod på application-Insights per nodnivå. Varje Application Insights-nod innehåller upp till 200 MB data som matas in per dag (separat från Log Analytics-datainmatning), med 90 dagars datalagring utan extra kostnad. Nivån beskrivs mer detaljerat längre fram i artikeln.

Eftersom den här nivån endast gäller för kunder med en Operations Management Suite-prenumeration ser inte kunder som inte har en Operations Management Suite-prenumeration något alternativ för att välja den här nivån.

Så här fungerar nivån Per nod

• Du betalar för varje nod som skickar telemetri för alla appar på nivån Per nod.
  • En nod är en fysisk eller virtuell serverdator eller en plattform som en tjänst-rollinstans som är värd för din app.
  • Utvecklingsdatorer, klientwebbläsare och mobila enheter räknas inte som noder.
  • Om din app har flera komponenter som skickar telemetri, till exempel en webbtjänst och en backend-arbetsroll, räknas komponenterna separat.
  • Live Metrics Stream-data räknas inte i prissättningssyfte. I en prenumeration är dina avgifter per nod, inte per app. Om du har fem noder som skickar telemetri för 12 appar är avgiften för fem noder.
• Även om avgifter citeras per månad debiteras du bara för en timme då en nod skickar telemetri från en app. Timavgiften är den angivna månadsavgiften dividerat med 744 (antalet timmar under en 31-dagars månad).
• En datavolymallokering på 200 MB per dag anges för varje nod som identifieras (med timdebititet). Oanvänd dataallokering förs inte över från en dag till nästa.
  • Om du väljer prisnivån Per nod får varje prenumeration en daglig tillåtna datamängd baserat på antalet noder som skickar telemetri till program-Insights i prenumerationen. Så om du har fem noder som skickar data hela dagen har du en pooltillägg på 1 GB som tillämpas på alla Application Insights-resurser i prenumerationen. Det spelar ingen roll om vissa noder skickar mer data än andra noder eftersom inkluderade data delas mellan alla noder. Om Application Insights-resurser tar emot mer data än vad som ingår i den dagliga dataallokeringen för den här prenumerationen gäller avgifter för överanvändning per GB.
  • Den dagliga dataförsedningen beräknas som antalet timmar på dagen (med UTC) som varje nod skickar telemetri dividerat med 24 multiplicerat med 200 MB. Så om du har fyra noder som skickar telemetri under 15 av de 24 timmarna på dagen blir inkluderade data för den dagen ((4 × 15) /24) × 200 MB = 500 MB. Till priset 2,30 USD per GB för övertid av data skulle avgiften vara 1,15 USD om noderna skickar 1 GB data den dagen.
  • Den dagliga tillåtna nivån Per nod delas inte med program som du har valt nivån Per GB för. Oanvänd traktamentet förs inte över från dag till dag.

Exempel på hur du fastställer distinkta nodantal

• Den exakta nodräkningen beror på vilket Application Insights SDK som programmet använder.
  • I SDK-version 2.2 och senare rapporterar både Application Insights Core SDK och Web SDK varje programvärd som en nod. Exempel är datornamnet för fysiska server- och VM-värdar eller instansnamnet för molntjänster. Det enda undantaget är ett program som endast använder .NET Core och Application Insights Core SDK. I så fall rapporteras endast en nod för alla värdar eftersom värdnamnet inte är tillgängligt.
  • För tidigare versioner av SDK fungerar Webb-SDK som de nyare SDK-versionerna, men Core SDK rapporterar endast en nod, oavsett antalet programvärdar.
  • Om ditt program använder SDK för att ange roleInstance till ett anpassat värde används som standard samma värde för att fastställa antalet noder.
  • Om du använder en ny SDK-version med en app som körs från klientdatorer eller mobila enheter kan antalet noder returnera ett stort antal (på grund av det stora antalet klientdatorer eller mobila enheter).

Automation

Du kan skriva ett skript för att ange prisnivån med hjälp av Azure Resource Management. Lär dig hur.

Nästa steg

• Provtagning