Protokollierungsdaten-Ingestionszeit in Azure Monitor

Azure Monitor ist ein hochskalierter Datendienst, der jeden Monat Terabyte Daten sendet und weiter wächst. Bei normalen Dienstvorgängen dauert es, bis Protokolldaten verfügbar sind, nachdem die Sammlung vorhersagbar und konsistent ist. In diesem Artikel werden die Faktoren erläutert, die sich auf diese Latenz auswirken.

Durchschnittliche Latenz

Die Latenz bezieht sich auf die Zeit zwischen der Erstellung von Daten im überwachten System und wann sie für die Analyse in Azure Monitor verfügbar ist. Die durchschnittliche Latenz für die Erfassung von Protokolldaten beträgt weniger als 10 Sekunden. Die spezifische Latenz für bestimmte Daten variiert je nach verschiedenen Faktoren, die in diesem Artikel erläutert werden.

Faktoren, die die Wartezeit beeinflussen

Die Gesamtaufnahmezeit für eine bestimmte Datenmenge ist die kumulative Zeit vom Client zum Azure Monitordienst.

• Clientzeit: Die Zeit zum Ermitteln eines Ereignisses, sie zu sammeln und sie dann als Protokoll-Datensatz an einen Datensammlungs-Endpunkt zu senden. In den meisten Fällen behandelt ein Agent wie der Azure Monitor Agent (AMA) diesen Prozess. Benutzerdefinierte Anwendungen, die die Protokollaufnahme-API verwenden, sind nicht Teil der Berechnungen dieses Artikels, sie verfügen jedoch möglicherweise über eigene Latenzmerkmale, die der AMA-Clientzeit ähneln.
• Azure Monitor-Zeit: Nachdem der Client die Protokollierung an Azure Monitor übergeben hat, die Zeit, die für die Verarbeitung des Protokolldatensatzes benötigt wird. Dieser Zeitraum umfasst das Analysieren der Ereigniseigenschaften und potenziell das Hinzufügen berechneter Informationen.

In den folgenden Abschnitten wird die in diesem Prozess eingeführte unterschiedliche Latenz beschrieben.

Agent-Sammlungswartezeit

Latenz: Die Zeit variiert.

Agents verwenden verschiedene Strategien zum Sammeln von Daten, die sich auf die Latenz auswirken können. In der folgenden Tabelle sind einige spezifische Beispiele aufgelistet.

Weitere Informationen zur Agentleistung finden Sie unter Azure Überwachen der Agent-Leistung.

Uploadhäufigkeit des Agents

Latenz: Unter 1 Minute

Um die Azure Monitor Agent einfach zu halten, werden Protokolle gepuffert und in regelmäßigen Abständen in Azure Monitor hochgeladen. Die Uploadhäufigkeit schwankt zwischen 30 Sekunden und 2 Minuten, abhängig vom Datentyp. Die meisten Daten werden in unter 1 Minute hochgeladen.

Netzwerk

Latenz: Variiert

Das Netzwerk zwischen einem Client und dem Azure Monitor-Datenabsammlung-Endpunkt kann unerwartete Verzögerungen verursachen. Wenn Sie die Erfassungslatenz messen, wird diese Netzwerklatenz als Teil der Berechnung in den AgentLatency Beispielabfragen im Abschnitt zur Messung der Erfassungslatenz eingeschlossen.

Azure Metriken, Ressourcenprotokolle, Aktivitätsprotokolle

Latenz: 30 Sekunden bis 20 Minuten

Azure-Daten benötigen mehr Zeit, um an einem Datensammel-Endpunkt zur Verarbeitung verfügbar zu sein.

• Azure Plattformmetriken sind in der Metrikdatenbank in weniger als einer Minute verfügbar, es dauert jedoch weitere drei Minuten, bis sie in den Endpunkt für die Datensammlung exportiert werden.
• Ressourcenprotokolle sind in der Regel innerhalb von 3 bis 10 Minuten End-to-End verfügbar, je nach Komplexität des Dienstes und der beteiligten Azure-Dienste. Beispielsweise stellen Azure SQL Database und Azure Virtual Network ihre Protokolle derzeit alle fünf Minuten bereit. Mit der folgenden Abfrage können Sie die Wartezeit in Ihrer Umgebung ermitteln.
• Aktivitätsprotokolle sind nach 3 bis 20 Minuten für die Analyse verfügbar.

Azure Überwachen der Prozesszeit

Latenz: Weniger als 10 Sekunden

Nachdem die Daten den Datensammlungsendpunkt erreicht haben, dauert es weniger als 10 Sekunden, bis Sie sie abfragen können.

Wenn Azure Monitor Protokolleinträge erfasst (wie die _TimeReceived-Eigenschaft anzeigt), schreibt es diese in einen temporären Speicher. Dieser Schritt stellt die Mandantenisolation sicher und verhindert Datenverlust. In diesem Schritt werden in der Regel 5 bis 15 Sekunden hinzugefügt.

Einige Lösungen verwenden komplexere Algorithmen, um Daten zu aggregieren und Erkenntnisse abzuleiten, während die Datenströme eintreffen. Beispielsweise berechnet Application Insights Daten zur Anwendungszuordnung. Azure Netzwerkleistungsüberwachung aggregiert eingehende Daten über dreiMinütige Intervalle, wodurch in diesem Fall effektiv drei Minuten Latenz hinzugefügt werden.

Wenn die Datensammlung eine Ingestion-Time-Transformation enthält, fügt diese Transformation der Prozesszeit von Azure Monitor einige Latenz hinzu. Verwenden Sie die Metrik Protokolltransformationsdauer pro Min, um die Effizienz der Transformationsabfrage zu überwachen.

Ein anderer Prozess, durch den die Latenz erhöht wird, ist der Prozess, der benutzerdefinierte Protokolle verarbeitet. In einigen Fällen kann dieser Vorgang ein paar Minuten Latenz zu Protokollen hinzufügen, die ein Agent aus Dateien sammelt.

Bereitstellung von neuen, benutzerdefinierten Datentypen

Wenn ein neuer Typ von benutzerdefinierten Daten aus einem Custom-Log oder der Logs-Eingabe-API erstellt wird, erstellt das System einen dedizierten Speichercontainer. Dieser einmalige Mehraufwand tritt nur beim ersten Vorkommen dieses Datentyps auf.

Überprüfen der Erfassungszeit

Die Erfassungszeit kann für verschiedene Ressourcen unter verschiedenen Umständen variieren. Verwenden Sie Protokollabfragen, um bestimmte Verhaltensweisen Ihrer Umgebung zu identifizieren. In der folgenden Tabelle wird angegeben, wie Sie die verschiedenen Zeiten für einen Datensatz bestimmen, während er erstellt und an Azure Monitor gesendet wird. Weitere Informationen zu Protokollabfragen finden Sie unter "Übersicht über Log Analytics".

Messen der Aufnahmelatenz

Messen Sie die Latenz eines bestimmten Datensatzes, wenn Sie das Ergebnis der ingestion_time()-Funktion mit der eigenschaft TimeGenerated vergleichen. Erfahren Sie, wie sich die Aufnahmelatenz verhält, wenn Sie verschiedene Aggregationen dieser Daten verwenden. Untersuchen Sie ein Perzentil der Erfassungszeit, um Erkenntnisse zu großen Datenmengen zu erhalten.

Zum Beispiel zeigt die folgende Abfrage, welche Computer in den letzten acht Stunden die höchste Verarbeitungszeit hatten:

Heartbeat
| where TimeGenerated > ago(8h)
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer
| top 20 by percentile_E2EIngestionLatency_95 desc

Die vorausgehenden Perzentilüberprüfungen empfehlen sich für eine Suche nach allgemeinen Trends bei der Wartezeit. Um eine kurzfristige Spitze bei der Wartezeit zu ermitteln, ist die Verwendung des maximalen Werts (max()) möglicherweise effektiver.

Wenn Sie ausführliche Informationen zur Erfassungszeit für einen bestimmten Computer über einen Zeitraum anzeigen möchten, verwenden Sie die folgende Abfrage, mit der auch die Daten des letzten Tages in einem Diagramm visualisiert werden:

Heartbeat
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m)
| render timechart

Mit der folgenden Abfrage können Sie die Erfassungszeit von Computern nach dem Land oder der Region anzeigen, in dem bzw. der sich diese basierend auf der IP-Adresse befinden:

Heartbeat
| where TimeGenerated > ago(8h)
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry

Verschiedene Datentypen, die vom Agent stammen, weisen möglicherweise unterschiedliche Erfassungswartezeiten auf. Daher können die vorherigen Abfragen mit anderen Typen verwendet werden. Verwenden Sie die folgende Abfrage, um die Aufnahmezeit verschiedener Azure Dienste zu untersuchen:

AzureDiagnostics
| where TimeGenerated > ago(8h)
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

Verwenden Sie dieselbe Abfragelogik, um Latenzbedingungen für logbasierte Metriken von Application Insights zu diagnostizieren:

// Workspace-based Application Insights schema
// This query can be paired with any other Application Insights table other than "requests"
let start=datetime("2026-01-21 05:00:00");
let end=datetime("2026-01-23 05:00:00");
AppRequests
| where TimeGenerated > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure , ingestion_time(), TimeRequiredtoIngest, EndtoEndTime
| sort by EndtoEndTime desc

Ressourcen, die nicht mehr reagieren

In einigen Fällen beendet eine Ressource das Senden von Daten. Um zu verstehen, ob eine Ressource Daten sendet, überprüfen Sie den neuesten Datensatz, den das Standardfeld TimeGenerated identifiziert.

Verwenden Sie die Heartbeat-Tabelle, um die Verfügbarkeit einer VM zu überprüfen, da der Agent einmal pro Minute ein Heartbeat-Signal sendet. Verwenden Sie die folgende Abfrage, um die aktiven Computer aufzulisten, die in letzter Zeit kein Heartbeat-Signal gemeldet haben:

Heartbeat
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer
| top 20 by NoHeartbeatPeriod desc 

Nächste Schritte

Lesen Sie die Dienstgütevereinbarung für Azure Monitor.