Überwachen und Behandeln von Problemen mit der DCR-Datensammlung in Azure Monitor

  • Artikel

Dieser Artikel enthält detaillierte Metriken und Protokolle, mit denen Sie die Leistung überwachen und Probleme im Zusammenhang mit der Datensammlung in Azure Monitor beheben können. Diese Telemetrie ist derzeit für Datensammlungsszenarien verfügbar, die durch eine Datensammlungsregeln (Data Collection Rules, DCR) definiert sind, z. B. Azure Monitor-Agent und Protokollaufnahme-API.

Wichtig

Dieser Artikel bezieht sich nur auf Datensammlungsszenarien, die DCRs verwenden, einschließlich der folgenden:

Weitere Informationen zu Überwachung und Problembehandlung finden Sie in der Dokumentation zu anderen Szenarien, die möglicherweise verfügbar sind.

DCR-Diagnosefeatures umfassen Metriken und Fehlerprotokolle, die während der Protokollverarbeitung ausgegeben werden. DCR-Metriken liefern Informationen über die Menge der erfassten Daten, die Anzahl und Art von Verarbeitungsfehlern sowie Statistiken im Zusammenhang mit der Datentransformation. DCR-Fehlerprotokolle werden generiert, wenn die Datenverarbeitung nicht erfolgreich ist und die Daten nicht an ihr Ziel gelangen.

DCR-Fehlerprotokolle

Fehlerprotokolle werden generiert, wenn Daten die Azure Monitor-Aufnahmepipeline erreichen, aber nicht das Ziel. Beispiele für Fehlerbedingungen sind:

  • Fehler bei der Protokollübermittlung
  • Transformationsfehler, bei denen die Struktur der Protokolle die Transformations-KQL ungültig macht
  • API-Aufrufe für Protokollerfassung:
    • mit einer anderen HTTP-Antwort als 200/202
    • mit Nutzlast mit falsch formatierten Daten
    • mit Nutzlast überhalb aller Aufnahmegrenzwerte
    • Drosselung aufgrund von Überlastungsgrenzen für API-Aufrufe

Um eine übermäßige Protokollierung dauerhafter Fehler im Zusammenhang mit demselben Datenflow zu vermeiden, werden einige Fehler nur eine begrenzte Anzahl von Stunden protokolliert, gefolgt von einer zusammenfassenden Fehlermeldung. Der Fehler wird dann bis zum Ende der Stunde stummgeschaltet. Die Häufigkeit, mit der ein bestimmter Fehler protokolliert wird, kann je nach Region variieren, in der DCR bereitgestellt wird.

Einige Protokollaufnahmefehler werden nicht protokolliert, da sie keinem DCR zugeordnet werden können. Die folgenden Fehler werden möglicherweise nicht protokolliert:

  • Fehler durch falsch formatierten Aufruf-URI (HTTP-Antwortcode 404)
  • Bestimmte interne Serverfehler (HTTP-Antwortcode 500)

Aktivieren von DCR-Fehlerprotokollen

DCR-Fehlerprotokolle werden als Ressourcenprotokolle in Azure Monitor implementiert. Aktivieren Sie die Protokollsammlung, indem Sie eine Diagnoseeinstellung für den DCR erstellen. Jeder DCR erfordert eine eigene Diagnoseeinstellung. Informationen zum detaillierten Prozess finden Sie unter Erstellen von Diagnoseeinstellungen in Azure Monitor. Wählen Sie die Kategorie Protokollfehler und An den Log Analytics-Arbeitsbereich senden aus. Möglicherweise möchten Sie den gleichen Arbeitsbereich auswählen, der vom DCR verwendet wird, oder Sie möchten alle Fehlerprotokolle in einem einzigen Arbeitsbereich konsolidieren.

Abrufen von DCR-Fehlerprotokollen

Fehlerprotokolle werden in die Tabelle DCRLogErrors in dem Log Analytics-Arbeitsbereich geschrieben, den Sie in der Diagnoseeinstellung angegeben haben. Im Folgenden finden Sie Beispielabfragen, die Sie in Log Analytics verwenden können, um diese Protokolle abzurufen.

Abrufen aller Fehlerprotokolle für einen bestimmten DCR

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

Abrufen aller Fehlerprotokolle für einen bestimmten Eingabedatenstrom in einem bestimmten 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-Metriken

DCR-Metriken werden automatisch für alle DCRs gesammelt, und Sie können sie mithilfe des Metrik-Explorers wie die Plattformmetriken für andere Azure-Ressourcen analysieren. Der Eingabedatenstrom wird als Dimension enthalten. Wenn Sie also über einen DCR mit mehreren Eingabedatenströmen verfügen, können Sie die einzelnen Daten analysieren, indem Sie sie filtern oder teilen. Einige Metriken enthalten andere Dimensionen, wie in der folgenden Tabelle dargestellt.

Metrik Dimensionen Beschreibung
Protokollaufnahmebytes pro Min Eingabedatenstrom Gesamtanzahl der empfangenen Bytes pro Minute.
Protokollaufnahmeanforderungen pro Min Eingabestream
HTTP-Antwortcode		 Anzahl der empfangenen Aufrufe pro Minute
Protokollierte Zeilen, die pro Min. verworfen werden Eingabestream Die Anzahl der Protokollzeilen, die während der Verarbeitung pro Minute verworfen werden. Dies schließt Zeilen ein, die sowohl aufgrund von Filterkriterien bei der KQL-Transformation als auch aufgrund von Fehlern verworfen wurden.
Protokollzeilen, die pro Min empfangen werden Eingabestream Die Anzahl der Protokollzeilen, die für die Verarbeitung pro Minute empfangen wurden.
Protokolltransformationsdauer pro Min Eingabestream Durchschnittliche KQL-Transformationslaufzeit pro Minute. Stellt die Effizienz des KQL-Transformationscodes dar. Datenflows mit längerer Transformationslaufzeit können Verzögerungen bei der Datenverarbeitung und größere Datenlatenz haben.
Protokolltransformationsfehler pro Min Eingabestream
Fehlertyp		 Anzahl der aufgetretenen Verarbeitungsfehler pro Minute

Behandeln allgemeiner Probleme

Wenn In Ihrem Log Analytics-Arbeitsbereich erwartete Daten fehlen, führen Sie die folgenden grundlegenden Schritte aus, um das Problem zu beheben. Dabei wird davon ausgegangen, dass Sie die DCR-Protokollierung wie oben beschrieben aktiviert haben.

  • Überprüfen Sie Metriken, z. B. Logs Ingestion Bytes per Min und Logs Rows Received per Min stellen Sie sicher, dass die Daten Azure Monitor erreichen. Wenn nicht, überprüfen Sie Die Datenquelle, um sicherzustellen, dass sie Daten wie erwartet sendet.
  • Überprüfen Sie Logs Rows Dropped per Min, um zu sehen, ob Zeilen gelöscht werden. Dies weist möglicherweise nicht auf einen Fehler hin, da die Zeilen durch eine Transformation verworfen werden können. Wenn die verworfenen Zeilen identisch mit Logs Rows Dropped per Min sind, werden im Arbeitsbereich keine Daten aufgenommen. Überprüfen Sie Logs Transformation Errors per Min, um zu sehen, ob Transformationsfehler auftreten.
  • Überprüfen Sie Logs Transformation Errors per Min, um zu sehen, ob Fehler von Transformationen auf die eingehenden Daten angewendet wurden. Dies kann auf Änderungen der Datenstruktur oder der Transformation selbst zurückzuführen sein.
  • Überprüfen Sie DCRLogErrors auf Aufnahmefehler, die möglicherweise protokolliert wurden. Dies kann zusätzliche Details zur Identifizierung der Ursache des Problems liefern.

Überwachen der Protokollaufnahme

Die folgenden Signale können nützlich sein, um den Status Ihrer Protokollsammlung mit DCRs zu überwachen. Erstellen Sie Warnungsregeln, um diese Bedingungen zu identifizieren.

Signal Mögliche Ursachen und Aktionen
Neue Einträge in DCRErrorLogs oder plötzliche Änderungen in Log Transform Errors. – Probleme bei der Einrichtung der Protokollaufnahme-API, z. B. Authentifizierung, Zugriff auf DCR oder DCE, Aufrufnutzlastprobleme.
– Änderungen in der Datenstruktur, die zu Fehlern bei der KQL-Transformation führen.
– Änderungen an der Datenzielkonfiguration führen zu Fehlern bei der Datenübermittlung.
Plötzliche Änderung in Logs Ingestion Bytes per Min – Änderungen bei der Konfiguration der Protokollaufnahme auf dem Client, einschließlich AMA-Einstellungen.
– Änderungen in der Struktur der gesendeten Protokolle.
Plötzliche Änderung des Verhältnisses zwischen Logs Ingestion Bytes per Min und Logs Rows Received per Min – Änderungen in der Struktur der gesendeten Protokolle. Überprüfen Sie die Änderungen, um sicherzustellen, dass die Daten mit der KQL-Transformation ordnungsgemäß verarbeitet werden.
Plötzliche Änderung in Logs Transformation Duration per Min – Änderungen in der Struktur von Protokollen, die sich auf die Effizienz von Protokollfilterkriterien auswirken, die in der KQL-Transformation festgelegt sind. Überprüfen Sie die Änderungen, um sicherzustellen, dass die Daten mit der KQL-Transformation ordnungsgemäß verarbeitet werden.
Logs Ingestion Requests per Min oder Logs Ingestion Bytes per Min nähern sich den Dienstgrenzwerten für die Protokollaufnahme-APIs. – Überprüfen und optimieren Sie Ihre DCR-Konfiguration, um Drosselung zu vermeiden.

Alerts

Anstatt Probleme reaktiv zu beheben, erstellen Sie Warnungsregeln, um proaktiv benachrichtigt zu werden, wenn eine potenzielle Fehlerbedingung auftritt. Die folgende Tabelle enthält Beispiele für Warnungsregeln, die Sie erstellen können, um ihre Protokollaufnahme zu überwachen.

Bedingung Warnungsdetails
Plötzliche Änderungen der verworfenen Zeilen Metrische Warnungsregel mit einem dynamischen Schwellenwert für Logs Rows Dropped per Min.
Anzahl der API-Aufrufe, die sich den Dienstgrenzwerten nähern Metrische Warnungsregel mit einem statischen Schwellenwert für Logs Ingestion Requests per Min. Legen Sie den Schwellenwert in der Nähe von 12.000 fest. Dies ist der Dienstgrenzwert für maximale Anforderungen/Minute pro DCR.
Fehlerprotokolle Protokollabfragewarnung mit DCRLogErrors. Verwenden Sie ein Tabellenzeilen-Measure und den Schwellenwert von 1, um benachrichtigt zu werden, wenn Fehler protokolliert werden.

Nächste Schritte