Övervaka och felsöka DCR-datainsamling i Azure Monitor

Den här artikeln innehåller detaljerade mått och loggar som du kan använda för att övervaka prestanda och felsöka eventuella problem som rör datainsamling i Azure Monitor. Den här telemetrin är för närvarande tillgänglig för datainsamlingsscenarier som definieras av en datainsamlingsregler (DCR), till exempel Azure Monitor-agenten och API för logginmatning.

Viktigt!

Den här artikeln refererar bara till datainsamlingsscenarier som använder dcrs, inklusive följande:

Se dokumentationen för andra scenarier för eventuell övervaknings- och felsökningsinformation som kan vara tillgänglig.

DCR-diagnostikfunktioner inkluderar mått och felloggar som genereras under loggbearbetningen. DCR-mått ger information om mängden data som matas in, antalet och typen av bearbetningsfel samt statistik som rör datatransformering. DCR-felloggar genereras när databearbetningen inte lyckas och data inte når målet.

DCR-felloggar

Felloggar genereras när data når Azure Monitor-inmatningspipelinen men inte når målet. Exempel på felvillkor är:

  • Fel vid loggleverans
  • Omvandlingsfel där loggarnas struktur gör omvandlingens KQL ogiltig
  • API-anrop för logginmatning:
    • med något annat HTTP-svar än 200/202
    • med nyttolast som innehåller felaktiga data
    • med nyttolast över eventuella inmatningsgränser
    • begränsning på grund av överförbrukning av API-anropsgränser

För att undvika överdriven loggning av beständiga fel relaterade till samma dataflöde loggas vissa fel endast ett begränsat antal gånger varje timme följt av ett sammanfattningsfelmeddelande. Felet stängs sedan av till slutet av timmen. Hur många gånger ett visst fel loggas kan variera beroende på vilken region DCR distribueras.

Vissa logginmatningsfel loggas inte eftersom de inte kan associeras med en DCR. Följande fel kanske inte loggas:

  • Fel som orsakas av felaktigt anrops-URI (HTTP-svarskod 404)
  • Vissa interna serverfel (HTTP-svarskod 500)

Aktivera DCR-felloggar

DCR-felloggar implementeras som resursloggar i Azure Monitor. Aktivera logginsamling genom att skapa en diagnostikinställning för DCR. Varje DCR kräver en egen diagnostikinställning. Mer information finns i Skapa diagnostikinställningar i Azure Monitor . Välj kategorin Loggfel och Skicka till Log Analytics-arbetsytan. Du kanske vill välja samma arbetsyta som används av DCR, eller så kanske du vill konsolidera alla dina felloggar på en enda arbetsyta.

Hämta DCR-felloggar

Felloggar skrivs till tabellen DCRLogErrors i Log Analytics-arbetsytan som du angav i diagnostikinställningen. Här följer exempelfrågor som du kan använda i Log Analytics för att hämta dessa loggar.

Hämta alla felloggar för en viss DCR

DCRLogErrors
| where _ResourceId == "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"

Hämta alla felloggar för en viss indataström i en viss DCR

DCRLogErrors
| where _ResourceId == "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
| where InputStreamId == "Custom-MyTable_CL"

DCR-mått

DCR-mått samlas in automatiskt för alla domänkontrollanter och du kan analysera dem med hjälp av Metrics Explorer , till exempel plattformsmått för andra Azure-resurser. Indataström ingår som en dimension, så om du har en DCR med flera indataströmmar kan du analysera var och en genom att filtrera eller dela. Vissa mått innehåller andra dimensioner som visas i tabellen nedan.

Metric Dimensioner beskrivning
Loggar inmatningsbyte per min Indataström Totalt antal mottagna byte per minut.
Loggar inmatningsbegäranden per min Indataström
HTTP-svarskod
Antal mottagna samtal per minut
Loggar borttagna rader per min Indataström Antal loggrader som släppts under bearbetningen per minut. Detta inkluderar rader som släppts både på grund av filtreringsvillkor i KQL-transformering och rader som släppts på grund av fel.
Loggar mottagna rader per min Indataström Antal loggrader som tagits emot för bearbetning per minut.
Loggtransformeringens varaktighet per min Indataström Genomsnittlig KQL-transformeringskörning per minut. Representerar KQL-transformeringskodeffektivitet. Dataflöden med längre omvandlingskörningstid kan orsaka fördröjningar i databearbetningen och större datafördröjning.
Loggar transformeringsfel per min Indataström
Typ av fel
Antal bearbetningsfel som påträffas per minut

Felsök vanliga problem

Om du saknar förväntade data på Log Analytics-arbetsytan följer du de här grundläggande stegen för att felsöka problemet. Detta förutsätter att du har aktiverat DCR-loggning enligt beskrivningen ovan.

  • Kontrollera mått som Logs Ingestion Bytes per Min och Logs Rows Received per Min för att säkerställa att data når Azure Monitor. Om inte kontrollerar du datakällan för att se till att den skickar data som förväntat.
  • Kontrollera Logs Rows Dropped per Min om några rader tas bort. Detta kan inte tyda på ett fel eftersom raderna kan tas bort av en transformering. Om de borttagna raderna är samma som Logs Rows Dropped per Min men matas inga data in på arbetsytan. Logs Transformation Errors per Min Granska för att se om det finns några transformeringsfel.
  • Kontrollera Logs Transformation Errors per Min om det finns några fel från transformeringar som tillämpas på inkommande data. Detta kan bero på ändringar i datastrukturen eller själva omvandlingen.
  • Kontrollera DCRLogErrors om det finns inmatningsfel som kan ha loggats. Detta kan ge ytterligare information om hur du identifierar rotorsaken till problemet.

Övervaka logginmatningen

Följande signaler kan vara användbara för att övervaka hälsotillståndet för loggsamlingen med DCR: er. Skapa aviseringsregler för att identifiera dessa villkor.

Signal Möjliga orsaker och åtgärder
Nya poster i DCRErrorLogs eller plötslig ändring i Log Transform Errors. – Problem med konfiguration av API för logginmatning, till exempel autentisering, åtkomst till DCR eller DCE, anrop av nyttolastproblem.
– Ändringar i datastrukturen som orsakar KQL-transformeringsfel.
– Ändringar i datamålkonfigurationen som orsakar dataleveransfel.
Plötslig ändring i Logs Ingestion Bytes per Min – Ändringar i konfigurationen av logginmatning på klienten, inklusive AMA-inställningar.
– Ändringar i strukturen för skickade loggar.
Plötslig förändring i förhållandet mellan Logs Ingestion Bytes per Min och Logs Rows Received per Min – Ändringar i strukturen för skickade loggar. Granska ändringarna för att kontrollera att data bearbetas korrekt med KQL-transformering.
Plötslig ändring i Logs Transformation Duration per Min – Ändringar i loggstrukturen som påverkar effektiviteten för loggfiltreringskriterierna som anges i KQL-transformering. Granska ändringarna för att kontrollera att data bearbetas korrekt med KQL-transformering.
Logs Ingestion Requests per Min eller Logs Ingestion Bytes per Min närmar sig gränserna för Log Ingestion API-tjänsten. – Granska och optimera din DCR-konfiguration för att undvika begränsning.

Aviseringar

I stället för att felsöka problem reaktivt skapar du aviseringsregler som ska meddelas proaktivt när ett potentiellt feltillstånd inträffar. Följande tabell innehåller exempel på aviseringsregler som du kan skapa för att övervaka logginmatningen.

Villkor Aviseringsinformation
Plötsliga ändringar av borttagna rader Måttaviseringsregel med ett dynamiskt tröskelvärde för Logs Rows Dropped per Min.
Antal API-anrop som närmar sig tjänstgränser Måttaviseringsregel med ett statiskt tröskelvärde för Logs Ingestion Requests per Min. Ange tröskelvärde nära 12 000, vilket är tjänstgränsen för maximalt antal begäranden/minut per DCR.
Felloggar Logga frågeavisering med hjälp av DCRLogErrors. Använd ett mått för tabellrader och tröskelvärdet 1 för att aviseras när eventuella fel loggas.

Nästa steg