Felsöka hög datainmatning i Application Insights

2025-10-14

En ökning av faktureringsavgifterna för Application Insights eller Log Analytics sker ofta på grund av hög datainmatning. Den här artikeln hjälper dig att felsöka det här problemet och innehåller metoder för att minska kostnaderna för datainmatning.

Allmänna felsökningssteg

Steg 1: Identifiera resurser som presenterar hög datainmatning

I Azure-portalen går du till din prenumeration och väljerKostnadsanalys för Cost Management>. Det här bladet erbjuder kostnadsanalysvyer för att kartlägga kostnader per resurs, enligt följande:

Skärmbild som visar fliken

Steg 2: Identifiera kostsamma tabeller med hög datainmatning

När du har identifierat en Application Insights-resurs eller en Log Analytics-arbetsyta analyserar du data och avgör var den högsta inmatningen sker. Tänk på den metod som passar bäst för ditt scenario:

Baserat på antalet råposter

Använd följande fråga för att jämföra antal poster mellan tabeller:
```
search *
| where timestamp > ago(7d)
| summarize count() by $table
| sort by count_ desc
```
Den här frågan kan hjälpa dig att identifiera de mest bullriga tabellerna. Därifrån kan du förfina dina frågor för att begränsa undersökningen.

Baserat på använda byte

Fastställ tabeller med den högsta byteinmatningen med hjälp av skalärfunktionen format_bytes():

systemEvents
| where timestamp > ago(7d)
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize TotalBillingTelemetrySize = sum(BillingTelemetrySizeInBytes) by BillingTelemetryType
| extend BillingTelemetrySizeGB = format_bytes(TotalBillingTelemetrySize, 1 ,"GB")
| sort by BillingTelemetrySizeInBytes desc
| project-away BillingTelemetrySizeInBytes

På samma sätt som postantalsfrågorna kan de föregående frågorna hjälpa dig att identifiera de mest aktiva tabellerna, vilket gör att du kan välja ut specifika tabeller för ytterligare undersökning.

Använda arbetsböcker i Log Analytics-arbetsyta

Gå till Din Log Analytics-arbetsyta i Azure-portalen, välj Övervaka>arbetsböcker och välj sedan Användning under Log Analytics Workspace Insights.

Den här arbetsboken ger värdefulla insikter, till exempel procentandelen datainmatning för varje tabell och detaljerad inmatningsstatistik för varje resursrapportering till samma arbetsyta.

Steg 3: Fastställa faktorer som bidrar till hög datainmatning

När du har identifierat tabellerna med hög datainmatning fokuserar du på tabellen med den högsta aktiviteten och fastställer faktorer som bidrar till hög datainmatning. Detta kan vara ett specifikt program som genererar mer data än de andra, ett undantagsmeddelande som loggas för ofta eller en ny loggningskategori som genererar för mycket information.

Här är några exempelfrågor som du kan använda för den här identifieringen:

requests
| where timestamp > ago(7d)
| summarize count() by cloud_RoleInstance
| sort by count_ desc

requests
| where timestamp > ago(7d)
| summarize count() by operation_Name
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by cloud_RoleName
| sort by count_ desc

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

traces
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc

Du kan prova olika telemetrifält. Du kanske först kör följande fråga och observerar att det inte finns någon uppenbar orsak till den överdrivna telemetrin:

dependencies
| where timestamp > ago(7d)
| summarize count() by target
| sort by count_ desc

Du kan dock prova ett annat telemetrifält i stället för target, till exempel type.

dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc

I vissa scenarier kan du behöva undersöka ett specifikt program eller en viss instans ytterligare. Använd följande frågor för att identifiera brusiga meddelanden eller undantagstyper:

traces
| where timestamp > ago(7d)
| where cloud_RoleName == 'Specify a role name'
| summarize count() by type
| sort by count_ desc

exceptions
| where timestamp > ago(7d)
| where cloud_RoleInstance == 'Specify a role instance'
| summarize count() by type
| sort by count_ desc

Steg 4: Undersöka utvecklingen av inmatning över tid

Granska utvecklingen av inmatning över tid baserat på de faktorer som identifierades tidigare. På så sätt kan du avgöra om det här beteendet har varit konsekvent eller om ändringar har inträffat vid en viss tidpunkt. Genom att analysera data på det här sättet kan du fastställa när ändringen skedde och ge en tydligare förståelse för orsakerna bakom den höga datainmatningen. Den här insikten är viktig för att lösa problemet och implementera effektiva lösningar.

I följande frågor används skalarfunktionen bin() Kusto Query Language (KQL) för att segmentera data i endagsintervall. Den här metoden underlättar trendanalys eftersom du kan se hur data har ändrats eller inte ändrats över tid.

dependencies
| where timestamp > ago(30d)
| summarize count() by bin(timestamp, 1d), operation_Name
| sort by timestamp desc

min() Använd aggregeringsfunktionen för att identifiera den tidigaste registrerade tidsstämpeln för specifika faktorer. Den här metoden hjälper till att upprätta en baslinje och ger insikter om när händelser eller ändringar först inträffade.

dependencies
| where timestamp > ago(30d)
| where type == 'Specify dependency type being investigated'
| summarize min(timestamp) by type
| sort by min_timestamp desc

Felsökningssteg för specifika scenarier

Scenario 1: Hög datainmatning i Log Analytics

Fråga alla tabeller på en Log Analytics-arbetsyta:

search *
| where TimeGenerated > ago(7d)
| where _IsBillable == true
| summarize TotalBilledSize = sum(_BilledSize) by $table
| extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
| sort by TotalBilledSize desc
| project-away TotalBilledSize

Du kan veta vilken tabell som är den största bidragsgivaren till kostnaderna. Här är ett exempel på AppTraces:

Skärmbild som visar att tabellen AppTraces är den största kostnadsdeltagaren.

Fråga det specifika programmet som driver kostnaderna för spårningar:

AppTraces
| where TimeGenerated > ago(7d)
| where _IsBillable == true
| summarize TotalBilledSize = sum(_BilledSize) by  AppRoleName
| extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
| sort by TotalBilledSize desc
| project-away TotalBilledSize

Skärmbild som visar det specifika programmet som driver kostnaderna för spårningar.

Kör följande fråga som är specifik för programmet och titta närmare på de specifika loggningskategorier som skickar telemetri till AppTraces tabellen:

AppTraces
| where TimeGenerated > ago(7d)
| where _IsBillable == true
| where AppRoleName contains 'transformation'
| extend LoggerCategory = Properties['Category']
| summarize TotalBilledSize = sum(_BilledSize) by tostring(LoggerCategory)
| extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB")
| sort by TotalBilledSize desc
| project-away TotalBilledSize

Resultatet visar två huvudkategorier som ansvarar för kostnaderna:

Skärmbild som visar de specifika loggningskategorier som skickar telemetri till tabellen AppTraces.

Scenario 2: Hög datainmatning i Application Insight

Följ dessa steg för att fastställa vilka faktorer som bidrar till kostnaderna:

Undersök telemetridata i alla tabeller och få fram antalet poster per tabell och SDK-version.
```
search *
| where TimeGenerated > ago(7d)
| summarize count() by $table, SDKVersion
| sort by count_ desc
```
Följande exempel visar att Azure Functions genererar massor av spårnings- och undantagstelemetri:

Kör följande fråga för att hämta den specifika appen som genererar fler spårningar än de andra:

AppTraces
| where TimeGenerated > ago(7d)
| where SDKVersion == 'azurefunctions: 4.34.2.22820'
| summarize count() by AppRoleName
| sort by count_ desc

Skärmbild som visar vilken app som genererar flest spårningar.

Förfina frågan så att den innehåller den specifika appen och beräkna antalet poster per enskilt meddelande.
```
AppTraces
| where TimeGenerated > ago(7d)
| where SDKVersion == 'azurefunctions: 4.34.2.22820'
| where AppRoleName contains 'inbound'
| summarize count() by Message
| sort by count_ desc
```
Resultatet kan visa det specifika meddelandet som ökar inmatningskostnaderna:

Scenario 3: Nå dagligt tak oväntat

Anta att du nådde det dagliga taket oväntat den 4 september. Använd följande fråga för att hämta ett antal anpassade händelser och identifiera den senaste tidsstämpeln som är associerad med varje händelse:

customEvents
| where timestamp between(datetime(8/25/2024) .. 15d)
| summarize count(), min(timestamp) by name

Denna analys indikerar att vissa händelser började matas in den 4 september och därefter blev bullriga mycket snabbt.

Minska kostnaderna för datainmatning

När du har identifierat faktorerna i Azure Monitor-tabellerna som ansvarar för oväntad datainmatning kan du minska kostnaderna för datainmatning med hjälp av följande metoder enligt dina scenarier.

Metod 1: Uppdatera den dagliga gränskonfigurationen

Justera det dagliga taket för att förhindra överdriven telemetriinmatning.

Metod 2: Växla tabellplan

Växla till en annan tabellplan som stöds för Application Insights. Fakturering för datainmatning beror på tabellplanen och regionen för Log Analytics-arbetsytan. Se Tabellplaner och Tabeller som stöder den grundläggande tabellplanen i Azure Monitor-loggar.

Metod 3: Använda telemetri-SDK-funktioner för Java-agenten

Den rekommenderade standardlösningen är att använda samplings åsidosättningar. Application Insights Java-agenten innehåller två typer av samplingar. Ett vanligt användningsfall är att förhindra insamling av telemetri för hälsokontroller.

Det finns några kompletterande metoder för samplings åsidosättningar:

Minska kostnaden från traces tabellen:
- Minska telemetriloggnivån.
- Ta bort programloggar (inte ramverk/libs) med MDC-attributet och samplings åsidosättning.
- Inaktivera logginstrumentation genom att uppdatera applicationinsights.json-filen :
```
{
  "instrumentation": {
    "logging": {
      "enabled": false
    }
  }
}
```
Minska kostnaden från dependencies tabellen:
- Utelämna insamling av telemetri för Java-metoden som producerar beroendetelemetrin.
- Inaktivera instrumentationen som producerar beroendetelemetridata.
  
  Om beroendet är ett databasanrop visas inte databasen på programkartan. Om du tar bort beroendeinstrumentationen för ett HTTP-anrop eller ett meddelande (till exempel ett Kafka-meddelande) tas alla nedströmstelemetridata bort.
Minska kostnaden från customMetrics tabellen:
Minska kostnaden för OpenTelemetry-attribut:

OpenTelemetry-attribut läggs till i kolumnen customDimensions . De representeras som egenskaper i Application Insights. Du kan ta bort attribut med hjälp av en attributtelemetriprocessor. Mer information finns i Exempel på telemetriprocessor – Ta bort.

Metod 4: Uppdatera programkoden (loggnivåer eller undantag)

I vissa scenarier kan uppdatering av programkoden direkt bidra till att minska mängden telemetri som genereras och förbrukas av Application Insights-serverdelstjänsten. Ett vanligt exempel kan vara ett högljutt undantag som visas i applikationen.

Referenser

Ansvarsfriskrivning för tredje part

Microsoft tillhandahåller kontaktinformation från tredje part som hjälper dig att hitta ytterligare information om det här ämnet. Denna kontaktinformation kan ändras utan föregående meddelande. Microsoft garanterar inte att kontaktinformation från tredje part är korrekt.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp, skapa en supportförfrågan, eller fråga Azures community-support. Du kan också lämna produktfeedback till Azure feedback-community.

Feedback

Var den här sidan till hjälp?