Problemen met hoge gegevensopname in Application Insights oplossen

Een toename van de factureringskosten voor Application Insights of Log Analytics vindt vaak plaats vanwege hoge gegevensopname. Dit artikel helpt u bij het oplossen van dit probleem en biedt methoden om de kosten voor gegevensopname te verlagen.

Algemene stappen voor probleemoplossing

Stap 1: Resources identificeren die hoge gegevensopname presenteren

Navigeer in Azure Portal naar uw abonnement en selecteer Kostenanalyse van Cost Management>. Deze blade biedt weergaven voor kostenanalyse om de kosten per bron in kaart te brengen, als volgt:

Stap 2: dure tabellen identificeren met hoge gegevensopname

Nadat u een Application Insights-resource of een Log Analytics-werkruimte hebt geïdentificeerd, analyseert u de gegevens en bepaalt u waar de hoogste opname plaatsvindt. Houd rekening met de aanpak die het beste bij uw scenario past:

• Op basis van het aantal ruwe gegevens

  Gebruik de volgende query om recordaantallen in verschillende tabellen te vergelijken:

  search *
  | where timestamp > ago(7d)
  | summarize count() by $table
  | sort by count_ desc
  

  Deze query kan helpen bij het identificeren van de meest luidruchtige tabellen. Van daaruit kunt u uw query's verfijnen om het onderzoek te verfijnen.

• Op basis van verbruikte bytes

  Bepaal tabellen met de hoogste byteopname met behulp van de scalaire functie 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
  

  Net als bij de query's voor het aantal records kunnen de voorgaande query's helpen bij het identificeren van de meest actieve tabellen, zodat u specifieke tabellen kunt lokaliseren voor verder onderzoek.

• Het gebruik van werkmappen in Log Analytics-werkruimten

  Navigeer in Azure Portal naar uw Log Analytics-werkruimte, selecteerBewakingswerkmappen> en selecteer vervolgens Gebruik onder Log Analytics Workspace Insights.

  

  Deze werkmap biedt waardevolle inzichten, zoals het percentage gegevensinname voor elke tabel en gedetailleerde statistieken over de inname voor elke resource die rapporteert aan dezelfde werkruimte.

Stap 3: Factoren bepalen die bijdragen aan hoge gegevensopname

Nadat u de tabellen met hoge gegevensopname hebt geïdentificeerd, richt u zich op de tabel met de hoogste activiteit en bepaalt u factoren die bijdragen aan hoge gegevensopname. Dit kan een specifieke toepassing zijn die meer gegevens genereert dan de andere, een uitzonderingsbericht dat te vaak wordt geregistreerd of een nieuwe logboekregistratiecategorie die te veel informatie verzendt.

Hier volgen enkele voorbeeldquery's die u voor deze identificatie kunt gebruiken:

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

U kunt verschillende telemetrievelden proberen. Misschien voert u eerst de volgende query uit en ziet u dat er geen duidelijke oorzaak is voor de overmatige telemetrie:

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

U kunt echter een ander telemetrieveld proberen in plaats van target, zoals type.

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

In sommige scenario's moet u mogelijk een specifieke toepassing of instantie verder onderzoeken. Gebruik de volgende query's om ruisberichten of uitzonderingstypen te identificeren:

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

Stap 4: De evolutie van opname in de loop van de tijd onderzoeken

Bekijk de evolutie van opname in de loop van de tijd op basis van de eerder geïdentificeerde factoren. Op deze manier kunt u bepalen of dit gedrag consistent is of dat er wijzigingen zijn opgetreden op een bepaald punt. Door gegevens op deze manier te analyseren, kunt u vaststellen wanneer de wijziging is aangebracht en een duidelijker inzicht geven in de oorzaken achter de hoge gegevensopname. Dit inzicht is belangrijk voor het oplossen van het probleem en het implementeren van effectieve oplossingen.

In de volgende query's wordt de scalaire functie bin() Kusto Query Language (KQL) gebruikt om gegevens te segmenteren in intervallen van één dag. Deze benadering vereenvoudigt trendanalyse, omdat u kunt zien hoe gegevens in de loop van de tijd zijn gewijzigd of niet zijn gewijzigd.

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

Gebruik de min() aggregatiefunctie om de vroegste geregistreerde tijdstempel voor specifieke factoren te identificeren. Deze benadering helpt bij het vaststellen van een basislijn en biedt inzicht in wanneer gebeurtenissen of wijzigingen voor het eerst zijn opgetreden.

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

Stappen voor probleemoplossing voor specifieke scenario's

Scenario 1: Hoge gegevensopname in Log Analytics

1. Voer een query uit op alle tabellen in een Log Analytics-werkruimte:

   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
   

   U kunt weten welke tabel de grootste bijdrager is aan de kosten. Hier volgt een voorbeeld van AppTraces:

   

2. Voer een query uit op de specifieke toepassing die de kosten voor traceringen aansturen:

   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
   

   

3. Voer de volgende query uit die specifiek is voor die toepassing en kijk verder naar de specifieke logboekregistratiecategorieën die telemetrie naar de AppTraces tabel verzenden:

   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
   

   Het resultaat toont twee hoofdcategorieën die verantwoordelijk zijn voor de kosten:

   

Scenario 2: Hoge gegevensopname in Application Insight

Volg deze stappen om de factoren te bepalen die bijdragen aan de kosten:

1. Voer een query uit op de telemetrie in alle tabellen en haal een recordaantal op per tabel en SDK-versie:

   search *
   | where TimeGenerated > ago(7d)
   | summarize count() by $table, SDKVersion
   | sort by count_ desc
   

   In de volgende exmaple ziet u dat Azure Functions veel tracerings- en uitzonderingstelemetrie genereert:

   

2. Voer de volgende query uit om de specifieke app op te halen die meer traceringen genereert dan de andere:

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

   

3. Verfijn de query om die specifieke app op te nemen en een telling van records per afzonderlijk bericht te genereren:

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

   In het resultaat kunnen de specifieke berichten worden weergegeven die de opnamekosten verhogen:

   

Scenario 3: Dagelijkse limiet onverwacht bereiken

Stel dat u de daglimiet onverwacht hebt bereikt op 4 september. Gebruik de volgende query om een telling van aangepaste gebeurtenissen te verkrijgen en de meest recente tijdstempel te identificeren die aan elke gebeurtenis is gekoppeld:

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

Deze analyse geeft aan dat bepaalde gebeurtenissen op 4 september zijn opgenomen en vervolgens zeer snel luidruchtig werden.

Kosten voor gegevensopname verlagen

Nadat u de factoren in de Azure Monitor-tabellen hebt geïdentificeerd die verantwoordelijk zijn voor onverwachte gegevensopname, verlaagt u de kosten voor gegevensopname met behulp van de volgende methoden in uw scenario's.

Methode 1: De dagelijkse limietconfiguratie bijwerken

Pas de dagelijkse limiet aan om overmatige telemetrieopname te voorkomen.

Methode 2: Het tabelplan wijzigen

Schakel over naar een ander ondersteund tabelplan voor Application Insights. Facturering voor gegevensopname is afhankelijk van het tabelplan en de regio van de Log Analytics-werkruimte. Zie Tabelplannen en -tabellen die ondersteuning bieden voor het Basistabelplan in Azure Monitor-logboeken.

Methode 3: Telemetry SDK-functies gebruiken voor de Java-agent

De standaard aanbevolen oplossing is het gebruik van sampling-overschrijvingen. De Java-agent van Application Insights biedt twee soorten steekproeven. Een veelvoorkomend gebruiksscenario is het onderdrukken van het verzamelen van telemetrie voor gezondheidscontroles.

Er zijn enkele aanvullende methoden voor steekproevenoverschrijvingen:

• Verlaag de kosten uit de traces tabel:

  • Verminder het telemetrielogboekniveau.

  • Verwijder toepassingslogboeken (geen frameworks/bibliotheken) met het MDC-kenmerk en het overschrijven van steekproeven.

  • Schakel logboek instrumentatie uit door het applicationinsights.json-bestand bij te werken:

    {
      "instrumentation": {
        "logging": {
          "enabled": false
        }
      }
    }
    

• Verlaag de kosten uit de dependencies tabel:

  • Het verzamelen van telemetrie voor de Java-methode onderdrukken die de afhankelijkheidstelemetrie produceert.

  • Schakel de instrumentatie uit die de afhankelijkheidstelemetriegegevens produceert.

    Als de afhankelijkheid een databaseaanroep is, ziet u de database niet op het toepassingsoverzicht. Als u de afhankelijkheidsinstrumentatie van een HTTP-aanroep of een bericht (bijvoorbeeld een Kafka-bericht) verwijdert, worden alle downstreamtelemetriegegevens verwijderd.

• Verlaag de kosten uit de customMetrics tabel:

  • Verhoog het interval voor metrische gegevens.
  • Sluit een metrische waarde uit met een telemetrieprocessor.
  • Verhoog het heartbeat-interval.

• Verlaag de kosten van OpenTelemetry-kenmerken:

  OpenTelemetry-kenmerken worden toegevoegd aan de kolom customDimensions . Ze worden weergegeven als eigenschappen in Application Insights. U kunt kenmerken verwijderen met behulp van een kenmerktelemetrieprocessor. Zie voorbeelden van telemetrieprocessor voor meer informatie - Verwijderen.

Methode 4: De toepassingscode bijwerken (logboekniveaus of uitzonderingen)

In sommige scenario's kan het rechtstreeks bijwerken van de toepassingscode helpen de hoeveelheid telemetrie te verminderen die wordt gegenereerd en verbruikt door de Application Insights-back-endservice. Een veelvoorkomend voorbeeld hiervan is een ruisuitzondering die door de toepassing wordt weergegeven.

Referenties

• Prijzen van Azure Monitor
• Prijscategorie voor Log Analytics-werkruimte wijzigen
• Tabelplannen in Azure Monitor
• Kosten en gebruik van Azure Monitor
• Gebruik analyseren in een Log Analytics-werkruimte
• Kostenoptimalisatie in Azure Monitor

Disclaimer voor contact met derden

Microsoft verstrekt contactgegevens van derden om u te helpen aanvullende informatie over dit onderwerp te vinden. Deze contactinformatie kan zonder voorafgaande kennisgeving worden gewijzigd. Microsoft garandeert niet de nauwkeurigheid van contactinformatie van derden.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.