Überwachen und Behandeln von Problemen mit der DCR-Datensammlung in Azure Monitor
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:
- Protokolle, die mit Azure Monitor Agent (AMA) gesammelt wurden
- Protokolle, die mit der Protokollaufnahme-API erfasst wurden
- Von anderen Methoden gesammelte Protokolle, die eine Arbeitsbereichstransformations-DCR verwenden
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
undLogs 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 mitLogs Rows Dropped per Min
sind, werden im Arbeitsbereich keine Daten aufgenommen. Überprüfen SieLogs 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. |