Setting RabbitMQ Alarm Rules
This section describes the alarm rules of some metrics and how to configure the rules. In actual scenarios, you are advised to configure alarm rules for metrics by referring to the following alarm policies.
Metric |
Alarm Policy |
Description |
Solution |
---|---|---|---|
Memory High Watermark |
Alarm threshold: Raw data ≥ 1 Number of consecutive periods: 1 Alarm severity: Critical |
A threshold of 1 indicates that the memory high watermark is reached, blocking message publishing. |
|
Disk High Watermark |
Alarm threshold: Raw data ≥ 1 Number of consecutive periods: 1 Alarm severity: Critical |
A threshold of 1 indicates that the disk high watermark is reached, blocking message publishing. |
|
Memory Usage |
Alarm threshold: Raw data > Expected usage (30% is recommended) Number of consecutive periods: 3–5 Alarm severity: Major |
To prevent high memory watermarks from blocking publishing, configure an alarm for this metric on each node. |
|
CPU Usage |
Alarm threshold: Raw data > Expected usage (70% is recommended) Number of consecutive periods: 3–5 Alarm severity: Major |
A high CPU usage may slow down publishing rate. Configure an alarm for this metric on each node. |
|
Available Messages |
Alarm threshold: Raw data > Expected number of available messages Number of consecutive periods: 1 Alarm severity: Major |
If the number of available messages is too large, messages are accumulated. |
|
Unacked Messages |
Alarm threshold: Raw data > Expected number of unacknowledged messages Number of consecutive periods: 1 Alarm severity: Major |
If the number of unacknowledged messages is too large, messages may be accumulated. |
|
Connections |
Alarm threshold: Raw data > Expected number of connections Number of consecutive periods: 1 Alarm severity: Major |
A sharp increase in the number of connections may be a warning of a traffic increase. |
The services may be abnormal. Check whether other alarms exist. |
Channels |
Alarm threshold: Raw data > Expected number of channels Number of consecutive periods: 1 Alarm severity: Major |
A sharp increase in the number of channels may be a warning of a traffic increase. |
The services may be abnormal. Check whether other alarms exist. |
Erlang Processes |
Alarm threshold: Raw data > Expected number of processes Number of consecutive periods: 1 Alarm severity: Major |
A sharp increase in the number of processes may be a warning of a traffic increase. |
The services may be abnormal. Check whether other alarms exist. |
- Set the alarm threshold based on the service expectations. For example, if the expected usage is 35%, set the alarm threshold to 35%.
- The number of consecutive periods and alarm severity can be adjusted based on the service logic.
Procedure
- Log in to the management console.
- In the upper left corner, click and select a region.
Select the same region as your application service.
- Click and choose Application > Distributed Message Service for RabbitMQ to open the console of DMS for RabbitMQ.
- In the row containing the desired RabbitMQ instance, click View Metric.
- Hover the mouse pointer over a metric and click to create an alarm rule for the metric.
- Specify the alarm rule details.
For more information about creating alarm rules, see the Cloud Eye User Guide.
- Enter the alarm name and description.
- Specify the alarm policy and alarm severity.
For example, an alarm can be triggered and notifications can be sent once every day if the raw value of connections exceeds the preset value for three consecutive periods and no actions are taken to handle the exception.
- Set Alarm Notification configurations. If you enable Alarm Notification, set the validity period, notification object, and trigger condition.
- Click Create.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot