Freigeben über


Überwachen 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:

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.

Screenshot: Diagnoseeinstellungen für eine DCR.

Screenshot: Detail einer Diagnoseeinstellung für eine DCR.

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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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

Ü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