Freigeben über

Leistungsbenchmark mit dem Azure Monitor-Agent

  • Artikel

Der Agent kann mehrere Tausend Ereignisse pro Sekunde im Gatewayereignis-Weiterleitungsszenario verarbeiten. Die genaue Durchsatzrate hängt von verschiedenen Faktoren ab, z. B. der Größe der einzelnen Ereignisse, dem spezifischen Datentyp und den physischen Hardwareressourcen. In diesem Artikel wird der interne Microsoft-Benchmark beschrieben, der zum Testen des Agentdurchsatzes von 10.000 Syslog-Ereignissen im Weiterleitungsszenario verwendet wird. Die Benchmarkergebnisse sollten einen Anhaltspunkt für die Größe der Ressourcen liefern, die Sie in Ihrer Umgebung benötigen.

Hinweis

Die Ergebnisse in diesem Artikel sind rein informativ hinsichtlich der Leistung des AMA im Weiterleitungsszenario und stellen keinen Servicevertrag seitens Microsoft dar.

Best Practices für die Weiterleitung mit dem Agent

  • Der Linux AMA sollte auf 10k EPS abzielen. Es gibt eine 20k EPS-Warnung, was nicht bedeutet, dass Daten verloren gegangen sind. AMA garantiert keine verlustfreie Verbindung. Der Verlust ist jedoch wahrscheinlicher, wenn EPS über 10k liegt.
  • Die Weiterleitung sollte auf einem dedizierten System erfolgen, um potenzielle Störungen durch andere Workloads zu vermeiden.
  • Das Weiterleitungssystem sollte hinsichtlich CPU-, Arbeitsspeicher- und Datenträgerauslastung überwacht werden, um zu verhindern, dass Überlastungen zu Datenverlusten führen.
  • Nach Möglichkeit sollten ein Lastenausgleich und redundante Weiterleitungssysteme verwendet werden, um die Zuverlässigkeit und Skalierbarkeit zu verbessern. Weitere Überlegungen zu Weiterleitungen finden Sie in der Dokumentation zum Log Analytics-Gateway.

Agent-Leistung

Der Benchmark wird in einer kontrollierten Umgebung ausgeführt, um wiederholbare, genaue und statistisch signifikante Ergebnisse zu erhalten. Die vom Agent verbrauchten Ressourcen werden unter einer Last von 10.000 simulierten Syslog-Ereignissen pro Sekunde gemessen. Die simulierte Last wird auf derselben physischen Hardware ausgeführt, auf der sich der zu testende Agent befindet. Testläufe werden sieben Tage lang ausgeführt. Bei jedem Testlauf werden Leistungsmetriken pro Sekunde abgefragt, um die CPU- und Arbeitsspeicherauslastung sowie die maximale und durchschnittliche Netzwerkauslastung zu erfassen. Dieser Ansatz liefert die richtigen Informationen, damit Sie die für Ihre Umgebung benötigten Ressourcen schätzen können.

Hinweis

Die Ergebnisse messen nicht den End-to-End-Durchsatz, der von einem Log Analytics-Arbeitsbereich (oder anderen Telemetriesenken) erfasst wird, da aufgrund der Netzwerk- und Back-End-Pipelineleistung eine End-to-End-Variabilität auftreten kann.

Die Benchmarks werden auf einem Azure VM Standard_F8s_v2-System mit AMA Linux Version 1.25.2 und 10 GB Speicherplatz für den Ereigniscache ausgeführt.

  • vCPUs: 8 mit HyperThreading (800 % CPU ist möglich)
  • Arbeitsspeicher: 16 GiB
  • Temporärer Speicher: 64 GiB
  • Max. Datenträger-IOPS: 6.400
  • Netzwerk: max. 12500 MBit/s auf allen 4 physischen NICs

Ergebnisse

Leistungsmetrik Durchschn. (Max.) Medium
CPU % 51 (262)
Arbeitsspeicher-RSS MB 276 (1.017)
Netzwerk-KBit/s 338 (18.033)

Häufig gestellte Fragen

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen.

Wie viele Daten werden pro Agent gesendet?

Die pro Agent gesendete Datenmenge hängt von Folgendem ab:

  • Den Lösungen, die Sie aktiviert haben.
  • Der Anzahl der Protokolle und Leistungsindikatoren, die gesammelt werden.
  • Der Menge der Daten in den Protokollen.

Siehe Analysieren der Nutzung im Log Analytics-Arbeitsbereich.

Für Computer, die den WireData-Agent ausführen können, zeigen Sie mithilfe der folgenden Abfrage an, wie viele Daten gesendet werden:

WireData
| where ProcessName == "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe"
| where Direction == "Outbound"
| summarize sum(TotalBytes) by Computer

Wie viel Netzwerkbandbreite nutzt der Microsoft Monitoring Agent beim Senden von Daten an Azure Monitor?

Die Bandbreite hängt von der gesendeten Datenmenge ab. Daten werden komprimiert, bevor sie über das Netzwerk gesendet werden.

Nächste Schritte