Skip to content

Commit 0bebbd3

Browse files
authored
Update azure-monitor-agent-performance.md
Updating syntax issues.
1 parent 7fe4d41 commit 0bebbd3

File tree

1 file changed

+149
-87
lines changed

1 file changed

+149
-87
lines changed

articles/azure-monitor/agents/azure-monitor-agent-performance.md

Lines changed: 149 additions & 87 deletions
Original file line numberDiff line numberDiff line change
@@ -10,90 +10,152 @@ ms.reviewer: jeffwo
1010
# Customer intent: As a deployment engineer, I can scope the resources required to scale my gateway data colletors the use the Azure Monitor Agent.
1111

1212
---
13-
---
14-
title: Performance Benchmark for forwarding Gateway using Azure Monitor Agent
15-
description: Performance data for the AMA running in a gateway scenario
16-
ms.topic: conceptual
17-
author: guywi-ms
18-
ms.author: guywild
19-
ms.date: 4/07/2023
20-
ms.reviewer: jeffwo
21-
22-
# Customer intent: As a deployment engineer, I can scope the resources required to scale my gateway data colletors the use the Azure Monitor Agent.
23-
24-
---
25-
# Azure Monitor Agent Performance Benchmark
26-
27-
The agent can handle many thousands of events per second in the gateway event forwarding scenario. The exact throughput rate depends on various factors such as the size of each event, the specific data type, and physical hardware resources. This article will describe the Microsoft internal benchmark used for testing the agent throughput of 10k Syslog events in the forwarder scenario. The benchmark results should provide a guide to size the resources that you will need in your environment.
28-
29-
> [!NOTE]
30-
> The results in this article are informational about the performance of AMA in the forwarding scenario only and do not constitute any service agreement on the part of Microsoft.
31-
32-
## Best practices for agent as a forwarder.
33-
34-
- Each AMA is limited to ingesting 20k EPS, and will drop any data that exceeds the limits.
35-
36-
- The forwarder should be on a dedicated system to eliminate potential interference from other workloads.
37-
- The forwarder system should be monitored for CPU, memory, and disk utilization to prevent overloads from causing data loss.
38-
- Where possible use a load balancer and redundant forwarder systems to improve reliability and scalability.
39-
- For other considerations for forwarders see the Log Analytics Gateway documentation.
40-
41-
## Agent Performance
42-
43-
The benchmark is run in a controlled environment to get repeatable, accurate, and statistically significant results. The resources consumed by the agent are measured under a load of 10,000 simulated Syslog events per second. The simulated load is run on the same physical hardware that the agent under test is on. Test trials are run for seven days. For each trial, performance metrics are sampled every second to collect CPU, memory, and network maximum and average usage. This approach provides the right information to help you estimate the resources needed for your environment.
44-
45-
> [!NOTE]
46-
> The results do not measure the end-to-end throughput ingested by a Log Analytics Workspace (or other telemetry sinks), as there may be end-to-end variability due to network and backend pipeline performance.
47-
48-
The benchmarks are run on an Azure VM Standard_F8s_v2 system using AMA Linux version 1.25.2 and 10 GB of disk space for the event cache.
49-
50-
- vCPU’s: 8 with HyperThreading (800% CPU is possible)
51-
- Memory: 16 GiB
52-
- Temp Storage: 64 GiB
53-
- Max Disk IOPS: 6400
54-
- Network: 12500 Mbp Max on all 4 physical NICs
55-
56-
57-
58-
## Results
59-
60-
| Perf Metric | Ave (Max) Med |
61-
|:---|:---:|
62-
| CPU % | 51 (262) |
63-
| Mem RSS MB | 276 (1,017) |
64-
| Network KBps | 338 (18,033) |
65-
66-
67-
## Frequently asked questions
68-
69-
This section provides answers to common questions.
70-
71-
### How much data is sent per agent?
72-
73-
The amount of data sent per agent depends on:
74-
75-
* The solutions you've enabled.
76-
* The number of logs and performance counters being collected.
77-
* The volume of data in the logs.
78-
79-
See [Analyze usage in a Log Analytics workspace](../logs/analyze-usage.md).
80-
81-
For computers that are able to run the WireData agent, use the following query to see how much data is being sent:
82-
83-
```kusto
84-
WireData
85-
| where ProcessName == "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe"
86-
| where Direction == "Outbound"
87-
| summarize sum(TotalBytes) by Computer
88-
```
89-
90-
### How much network bandwidth is used by the Microsoft Monitoring Agent when it sends data to Azure Monitor?
91-
92-
Bandwidth is a function of the amount of data sent. Data is compressed as it's sent over the network.
93-
94-
## Next steps
95-
96-
- [Connect computers without internet access by using the Log Analytics gateway in Azure Monitor](gateway.md)
97-
- [Install the Azure Monitor Agent](azure-monitor-agent-manage.md) on Windows and Linux virtual machines.
98-
- [Create a data collection rule](data-collection-rule-azure-monitor-agent.md) to collect data from the agent and send it to Azure Monitor.
99-
13+
14+
# Azure Monitor Agent Performance Benchmark
15+
16+
17+
18+
The agent can handle many thousands of events per second in the gateway event forwarding scenario. The exact throughput rate depends on various factors such as the size of each event, the specific data type, and physical hardware resources. This article will describe the Microsoft internal benchmark used for testing the agent throughput of 10k Syslog events in the forwarder scenario. The benchmark results should provide a guide to size the resources that you will need in your environment.
19+
20+
21+
22+
> [!NOTE]
23+
24+
> The results in this article are informational about the performance of AMA in the forwarding scenario only and do not constitute any service agreement on the part of Microsoft.
25+
26+
27+
28+
## Best practices for agent as a forwarder.
29+
30+
31+
32+
- Each AMA is limited to ingesting 20k EPS, and will drop any data that exceeds the limits.
33+
34+
- The forwarder should be on a dedicated system to eliminate potential interference from other workloads.
35+
36+
- The forwarder system should be monitored for CPU, memory, and disk utilization to prevent overloads from causing data loss.
37+
38+
- Where possible use a load balancer and redundant forwarder systems to improve reliability and scalability.
39+
40+
- For other considerations for forwarders see the Log Analytics Gateway documentation.
41+
42+
43+
44+
## Agent Performance
45+
46+
47+
48+
The benchmark is run in a controlled environment to get repeatable, accurate, and statistically significant results. The resources consumed by the agent are measured under a load of 10,000 simulated Syslog events per second. The simulated load is run on the same physical hardware that the agent under test is on. Test trials are run for seven days. For each trial, performance metrics are sampled every second to collect CPU, memory, and network maximum and average usage. This approach provides the right information to help you estimate the resources needed for your environment.
49+
50+
51+
52+
> [!NOTE]
53+
54+
> The results do not measure the end-to-end throughput ingested by a Log Analytics Workspace (or other telemetry sinks), as there may be end-to-end variability due to network and backend pipeline performance.
55+
56+
57+
58+
The benchmarks are run on an Azure VM Standard_F8s_v2 system using AMA Linux version 1.25.2 and 10 GB of disk space for the event cache.
59+
60+
61+
62+
- vCPU’s: 8 with HyperThreading (800% CPU is possible)
63+
64+
- Memory: 16 GiB
65+
66+
- Temp Storage: 64 GiB
67+
68+
- Max Disk IOPS: 6400
69+
70+
- Network: 12500 Mbp Max on all 4 physical NICs
71+
72+
73+
74+
75+
76+
77+
78+
## Results
79+
80+
81+
82+
| Perf Metric | Ave (Max) Med |
83+
84+
|:---|:---:|
85+
86+
| CPU % | 51 (262) |
87+
88+
| Mem RSS MB | 276 (1,017) |
89+
90+
| Network KBps | 338 (18,033) |
91+
92+
93+
94+
95+
96+
## Frequently asked questions
97+
98+
99+
100+
This section provides answers to common questions.
101+
102+
103+
104+
### How much data is sent per agent?
105+
106+
107+
108+
The amount of data sent per agent depends on:
109+
110+
111+
112+
* The solutions you've enabled.
113+
114+
* The number of logs and performance counters being collected.
115+
116+
* The volume of data in the logs.
117+
118+
119+
120+
See [Analyze usage in a Log Analytics workspace](../logs/analyze-usage.md).
121+
122+
123+
124+
For computers that are able to run the WireData agent, use the following query to see how much data is being sent:
125+
126+
127+
128+
```kusto
129+
130+
WireData
131+
132+
| where ProcessName == "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe"
133+
134+
| where Direction == "Outbound"
135+
136+
| summarize sum(TotalBytes) by Computer
137+
138+
```
139+
140+
141+
142+
### How much network bandwidth is used by the Microsoft Monitoring Agent when it sends data to Azure Monitor?
143+
144+
145+
146+
Bandwidth is a function of the amount of data sent. Data is compressed as it's sent over the network.
147+
148+
149+
150+
## Next steps
151+
152+
153+
154+
- [Connect computers without internet access by using the Log Analytics gateway in Azure Monitor](gateway.md)
155+
156+
- [Install the Azure Monitor Agent](azure-monitor-agent-manage.md) on Windows and Linux virtual machines.
157+
158+
- [Create a data collection rule](data-collection-rule-azure-monitor-agent.md) to collect data from the agent and send it to Azure Monitor.
159+
160+
161+

0 commit comments

Comments
 (0)