Protokolldatenerfassungszeit in Azure Monitor

Azure Monitor ist ein Hochleistungsdatendienst, der Tausende Kunden bedient, die mit zunehmender Tendenz jeden Monat Terabytes von Daten senden. Häufig werden Fragen nach dem Zeitbedarf gestellt, der nach dem Sammeln der Protokolldaten bis zu ihrer Verfügbarkeit zu veranschlagen ist. Dieser Artikel erläutert die verschiedenen Faktoren, die sich auf diese Wartezeit auswirken.

Durchschnittliche Latenz

Wartezeit bezeichnet hier die Zeitspanne zwischen der Erstellung der Daten auf dem überwachten System und dem Zeitpunkt, zu dem sie für die Analyse in Azure Monitor verfügbar werden. Die durchschnittliche Latenzzeit für die Aufnahme von Protokolldaten liegt zwischen 20 Sekunden und 3 Minuten. Die spezifische Wartezeit für bestimmte Daten hängt jedoch von mehreren Faktoren ab, die in diesem Artikel erläutert werden.

Faktoren, die die Wartezeit beeinflussen

Die gesamte Erfassungszeit für ein bestimmtes Dataset kann in die folgenden allgemeinen Bereiche aufgeteilt werden:

• Agentzeit: Zeit für die Erkennung eines Ereignisses, seine Erfassung und die Übermittlung an den Datenerfassungsendpunkt als Protokolldatensatz. In den meisten Fällen wird dieser Prozess von einem Agent behandelt. Weitere Wartezeit kann durch das Netzwerk verursacht werden.
• Pipelinezeit: Die Zeit, die die Erfassungspipeline für die Verarbeitung des Protokolldatensatzes benötigt. Dieser Zeitraum umfasst das Analysieren der Ereigniseigenschaften und potenziell das Hinzufügen berechneter Informationen.
• Indizierungszeit: Die Zeit für die Erfassung eines Protokolldatensatzes in einem Big Data-Speicher von Azure Monitor.

Detailinformationen zu den verschiedenen Wartezeiten in diesem Prozess werden in den folgenden Abschnitten beschrieben.

Agent-Sammlungswartezeit

Die Zeit variiert.

Agents und Managementlösungen verwenden verschiedene Strategien, um Daten eines virtuellen Computers zu erfassen, was sich auf die Wartezeit auswirken kann. In der folgenden Tabelle sind einige spezifische Beispiele aufgelistet.

Uploadhäufigkeit des Agents

Unter 1 Minute

Um einen schlanken Log Analytics-Agent zu gewährleisten, speichert der Agent Protokolle zwischen und lädt sie in regelmäßigen Abständen nach Azure Monitor hoch. Die Uploadhäufigkeit schwankt zwischen 30 Sekunden und 2 Minuten, abhängig vom Datentyp. Die meisten Daten werden in unter 1 Minute hochgeladen.

Netzwerk

Unterschiedlich

Netzwerkbedingungen können sich negativ auf die Latenz auswirken, mit der diese Daten einen Datenerfassungsendpunkt erreichen.

Azure-Metriken, Ressourcenprotokolle, Aktivitätsprotokoll

30 Sekunden bis 15 Minuten

Azure-Daten benötigen mehr Zeit, um an einem Datenerfassungsendpunkt zur Verarbeitung verfügbar gemacht zu werden:

• Azure-Plattformmetriken sind in weniger als einer Minute in der Metrikdatenbank verfügbar, es dauert jedoch weitere drei Minuten, bis sie auf den Datenerfassungsendpunkt exportiert werden.
• Ressourcenprotokolle brauchen je nach Azure-Dienst in der Regel eine zusätzliche Zeit von 30 bis 90 Sekunden. Einige Azure-Dienste (insbesondere Azure SQL-Datenbank und Azure Virtual Network) melden ihre Protokolle derzeit in 5-Minuten-Intervallen. Es wird an einer weiteren Verbesserung dieser Zeit gearbeitet. Mit der folgenden Abfrage können Sie die Wartezeit in Ihrer Umgebung ermitteln.
• Aktivitätsprotokolle sind in 3 bis 20 Minuten für die Analyse verfügbar.

Sammlung von Verwaltungslösungen

Unterschiedlich

Einige Lösungen sammeln ihre Daten nicht mithilfe eines Agents, sondern verwenden möglicherweise eine Erfassungsmethode, die weitere Wartezeit mit sich bringt. Einige Lösungen erfassen Daten in regelmäßigen Intervallen, ohne eine Sammlung nahezu in Echtzeit zu versuchen. Hier einige spezifische Beispiele:

• Die Microsoft 365-Lösung ruft Aktivitätsprotokolle mithilfe der Verwaltungsaktivitäts-API ab, die aktuell keine Garantien für Wartezeiten bietet, die einer Echtzeiterfassung nahekommen.
• Daten aus Windows Analytics-Lösungen (z. B. Updatekonformität) werden von der Lösung täglich erfasst.

Informationen zum Bestimmen der Erfassungshäufigkeit einer Lösung finden Sie in der Dokumentation der jeweiligen Lösung.

Pipeline-Verarbeitungszeit

30 bis 60 Sekunden

Nachdem die Daten an einem Datenerfassungsendpunkt verfügbar sind, dauert es weitere 30 bis 60 Sekunden, bis sie für Abfragen zur Verfügung stehen.

Nachdem Protokolldatensätze in der Azure Monitor-Pipeline erfasst wurden (gemäß Angabe in der Eigenschaft _TimeReceived), werden sie in einen temporären Speicher geschrieben, um Mandantenisolation und Schutz vor Datenverlust sicherzustellen. Dieser Vorgang wirkt sich normalerweise mit zusätzlichen 5 bis 15 Sekunden aus.

Einige Lösungen implementieren aufwändigere Algorithmen zum Aggregieren von Daten und Ableiten von Erkenntnissen, während Daten eingehen. Beispiel: Application Insights berechnet Anwendungsübersichtsdaten. Der Azure-Netzwerkleistungsmonitor aggregiert eingehende Daten über 3-Minuten-Intervalle, was effektiv eine Wartezeit von 3 Minuten hinzufügt.

Wenn die Datensammlung eine Erfassungszeittransformation enthält, fügt dies der Pipeline eine gewisse 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 Prozess zu einer zusätzlichen Wartezeit von einigen Minuten bei Protokollen führen, die vom Agent aus Dateien gesammelt werden.

Bereitstellung von neuen, benutzerdefinierten Datentypen

Wenn aus einem benutzerdefinierten Protokoll oder der Datensammler-API ein neuer benutzerdefinierter Datentyp erstellt wird, erstellt das System einen dedizierten Speichercontainer. Dieser einmalige Mehraufwand tritt nur beim ersten Vorkommen dieses Datentyps auf.

Schutz vor Überflutung

Normalerweise weniger als 1 Minute, kann aber auch länger sein

Die oberste Priorität für Azure Monitor besteht darin, sicherzustellen, dass keine Kundendaten verloren gehen, daher weist das System einen integrierten Schutz vor Datenüberflutung auf. Dieser Schutz schließt Puffer ein, um sicherzustellen, dass das System selbst unter extremer Last noch funktioniert. Unter normalen Lastverhältnissen wird durch diese Steuerungsmechanismen weniger als eine Minute hinzugefügt. Unter extremen Bedingungen und bei Ausfällen können sie zu einer erheblichen Verlängerung der Wartezeit führen, während sie die Sicherheit der Daten gewährleisten.

Indizierungszeit

5 Minuten oder weniger

Jede Big Data-Plattform vollzieht einen Kompromiss zwischen dem Bereitstellen von Analysen und erweiterten Suchfunktionen einerseits und sofortigem Zugriff auf die Daten andererseits. Mit Azure Monitor können Sie leistungsstarke Abfragen über Milliarden von Datensätzen ausführen und Ergebnisse innerhalb weniger Sekunden erhalten. Diese Leistung ist möglich, da die Infrastruktur die Daten während ihrer Erfassung erheblich transformiert und sie in einzigartig kompakten Strukturen speichert. Das System puffert die Daten, bis genügend davon vorhanden sind, um diese Strukturen zu erstellen. Dieser Prozess muss abgeschlossen sein, bevor der Protokolldatensatz in den Suchergebnissen angezeigt wird.

Dieser Prozess nimmt derzeit ungefähr fünf Minuten bei geringem Datenaufkommen in Anspruch, kann aber bei hohem Datendurchsatz auch kürzer sein. Dieses Verhalten erscheint zwar widersprüchlich, doch ermöglicht dieser Prozess die Optimierung der Wartezeit für Produktionsworkloads mit großem Datenaufkommen.

Überprüfen der Erfassungszeit

Die Erfassungszeit kann für verschiedene Ressourcen unter verschiedenen Umständen variieren. Mithilfe von Protokollabfragen können Sie das spezifische Verhalten Ihrer Umgebung ermitteln. Die folgende Tabelle gibt Aufschluss darüber, wie Sie die verschiedenen Zeiten für einen Datensatz ermitteln können, wenn er erstellt und an Azure Monitor gesendet wird:

Verzögerungen der Erfassungswartezeit

Sie können die Wartezeit eines bestimmten Datensatzes messen, indem Sie das Ergebnis der Funktion ingestion_time() mit der Eigenschaft TimeGenerated vergleichen. Diese Daten können mit verschiedenen Aggregationen verwendet werden, um das Verhalten der Erfassungswartezeit zu ermitteln. Untersuchen Sie ein Perzentil der Erfassungszeit, um Einblicke für große Datenmengen zu erhalten.

Die folgende Abfrage zeigt beispielsweise, welche Computer in den letzten 8 Stunden die höchste Erfassungszeit aufwiesen:

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. Mit der folgenden Abfrage können Sie die Erfassungszeit verschiedener Azure-Dienste überprüfen:

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 Application Insights-Daten zu diagnostizieren:

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-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

Die beiden obigen Abfragen können mit einer beliebigen anderen Application Insights-Tabelle abgesehen von „Anforderungen“ kombiniert werden.

Ressourcen, die nicht mehr reagieren

In einigen Fällen kann eine Ressource das Senden von Daten beendet. Um festzustellen, ob eine Ressource Daten sendet oder nicht, sehen Sie sich den letzten Datensatz an, der anhand des Standardfelds TimeGenerated ermittelt werden kann.

Prüfen Sie anhand der Tabelle Heartbeat die Verfügbarkeit eines virtuellen Computers, da einmal pro Minute ein Heartbeat vom Agent gesendet wird. Mit der folgenden Abfrage können Sie die aktiven Computer auflisten, die kürzlich keinen Heartbeat 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 Vereinbarung zum Servicelevel für Azure Monitor.