Use CloudMonitor to monitor resources and set alert rules - ApsaraMQ for Kafka

Metrics

Note

Metric data is aggregated over a 1-minute period. A value reported per second, such as bytes per second (B/s), represents the average value over the preceding minute.
Metric data has a latency of 1 minute.
These metrics belong to the CloudMonitor namespace acs_kafka (ProductCategory: kafka). You need these identifiers to query metrics by using the CloudMonitor API or SDK.
Metrics with a V2 suffix in the metric ID, such as InstanceCpuUsageV2, are specific to V2 reserved instances.
Consumption-related metrics depend on offset commits. Metrics such as the number of unconsumed messages are calculated based on the consumer offset committed by the client. If the client does not properly commit offsets (for example, if autocommit is not enabled or manual commit is not configured), monitoring data cannot accurately reflect the actual consumption status, which may result in false alerts. Ensure that your client is correctly configured with an offset commit mechanism.
To determine whether server-side throttling has occurred, monitor the Instance Produce Throttle Queue Size (InstanceProduceThrottleQueueSizeV2) or Instance Consume Throttle Queue Size (InstanceFetchThrottleQueueSizeV2) metric. Throttling is considered to have occurred only when this metric reports non-zero values. Minor traffic overages typically have an elastic buffer and do not immediately trigger throttling.
The Production Traffic Ratio (InstanceMessageInputRatioV2) and Consumption Traffic Ratio (InstanceMessageOutputRatioV2) reflect node-level traffic utilization. Because Kafka defaults to 3 replicas with evenly distributed throughput capacity, traffic skew — such as periodic batch sends causing burst traffic — can cause the second-level traffic on a single node to momentarily exceed the limit, even if the instance average rate has not reached the configured threshold. Monitoring charts display minute-level smoothed data, while actual throttling is triggered based on second-level monitoring. These two values may differ significantly during traffic bursts.

ApsaraMQ for Kafka supports the following metrics:

Note

For common monitoring scenarios, start with the following metrics:

Storage alerts: Monitor instance_disk_capacity (disk usage percentage) and set an alert threshold at 85%.
Consumer lag detection: Monitor message_accumulation (consumer group message accumulation) to detect slow or stalled consumers.
Capacity planning: Monitor InstanceMessageInputRatioV2 (inbound traffic as a percentage of instance specification) and PartitionInstanceRatioV2 (partition count as a percentage of instance specification) to plan instance upgrades.

Instance-level metrics

Metric name	Metric ID	Dimensions	Unit
Instance disk usage	instance_disk_capacity	instanceId	%
Instance public inbound bandwidth	instance_internet_rx.rate	instanceId	bit/s
Instance public outbound bandwidth	instance_internet_tx.rate	instanceId	bit/s
Instance inbound traffic	instance_message_input	instanceId	B/s
Messages produced to the instance	instance_message_num_input	instanceId	count/s
Instance outbound traffic	instance_message_output	instanceId	B/s
Message send requests to the instance	instance_reqs_input	instanceId	count/s
Message consumption requests from the instance	instance_reqs_output	instanceId	count/s
Instance batch size TP50 (50th percentile)	InstanceBatchSizeTP50V2	instanceId	Bytes
Instance batch size TP999 (99.9th percentile)	InstanceBatchSizeTP999V2	instanceId	Bytes
Instance CPU usage	InstanceCpuUsageV2	instanceId	%
Instance fetch throttle queue size	InstanceFetchThrottleQueueSizeV2	instanceId	count
Instance high availability (HA) events	InstanceHAEventV2	instanceId	count
Instance public inbound bandwidth (per-node)	InstanceInternetRxRateByNode	instanceId, nodeIp	bit/s
Instance public inbound bandwidth utilization (per-node)	InstanceInternetRxUtilizationByNode	instanceId, nodeIp	%
Instance public outbound bandwidth (per-node)	InstanceInternetTxRateByNode	instanceId, nodeIp	bit/s
Instance public outbound bandwidth utilization (per-node)	InstanceInternetTxUtilizationByNode	instanceId, nodeIp	%
Instance maximum connections	InstanceMaxConnection	instanceId	count
Instance maximum Internet connections	InstanceMaxInternetConnection	instanceId	count
Instance maximum read input/output operations per second (IOPS)	InstanceMaxReadIOPSV2	instanceId	count/s
Instance maximum write IOPS	InstanceMaxWriteIOPSV2	instanceId	count/s
Inbound traffic as a percentage of instance specification	InstanceMessageInputRatioV2	instanceId	%
Outbound traffic as a percentage of instance specification	InstanceMessageOutputRatioV2	instanceId	%
Instance produce throttle queue size	InstanceProduceThrottleQueueSizeV2	instanceId	count
Instance rebalance time	InstanceRebalanceTimeV2	instanceId	ms
Instance total connections	InstanceTotalConnection	instanceId	count
Instance total Internet connections	InstanceTotalInternetConnection	instanceId	count
Partition count as a percentage of instance specification	PartitionInstanceRatioV2	instanceId	%

Consumer group-level metrics

Metric name	Metric ID	Dimensions	Unit
Consumer group message output	group_message_num_output	instanceId, consumerGroup	count/s
Consumer group message output for a topic	group_message_num_output_onetopic	instanceId, consumerGroup, topic	count/s
Consumer group consumption latency	group_topic_accumulation_consume_cost_time	instanceId, consumerGroup	ms
Consumer group message accumulation	message_accumulation	instanceId, consumerGroup	count
Consumer group message accumulation for a topic	message_accumulation_onetopic	instanceId, consumerGroup, topic	count

Topic-level metrics

Metric name	Metric ID	Dimensions	Unit
Topic inbound traffic	topic_message_input	instanceId, topic	B/s
Messages produced to a topic	topic_message_num_input	instanceId, topic	count/s
Topic outbound traffic	topic_message_output	instanceId, topic	B/s
Topic consumption-to-production traffic ratio	topic_message_output_input_ratio	instanceId, topic	%
Topic message send requests	topic_reqs_input	instanceId, topic	count/s
Topic message consumption requests	topic_reqs_output	instanceId, topic	count/s

Billing

The CloudMonitor feature for ApsaraMQ for Kafka is free of charge.

Prerequisites

A service-linked role is required.

Role name: AliyunServiceRoleForAlikafka
Policy name: AliyunServiceRolePolicyForAlikafka
Permissions: Grants ApsaraMQ for Kafka permission to access your other services, such as CloudMonitor and Application Real-Time Monitoring Service (ARMS), for monitoring-related features.
For more information, see Service-linked roles.

View monitoring data

Log on to the ApsaraMQ for Kafka console.
In the Resource Distribution section of the Overview page, select the region where the ApsaraMQ for Kafka instance that you want to manage resides.
On the Instances page, click the name of the instance that you want to manage.
In the left-side navigation pane, choose Observability > CloudMonitor.
On the CloudMonitor page, click the Alert Rule tab. Select the tab for the resource that you want to monitor, find the resource, and then click View CloudMonitor Metrics in the Actions column. Set a time range to view the monitoring data.

Charts for all metrics of the current resource appear automatically.

Set an alert rule

On the CloudMonitor page, click the Alert Rule tab, and then select the Instance, Topic, or Group tab.

This action redirects you to the Create Alert Rule panel in the CloudMonitor console.
In the Create Alert Rule panel, configure the rule and notification information, and then click OK. For more information about the parameters, see Create an alert rule.
After you click OK, the alert rule appears on the Alert Rule tab. Verify that the rule status is Enabled.

Example: Configure a Group message accumulation alert with DingTalk robot notification

Note

Before configuring the alert, log on to the Cloud Monitor console and add a DingTalk robot as an alert contact or contact group. The DingTalk robot's webhook URL must be registered in advance.

Log on to the ApsaraMQ for Kafka console.
In the left-side navigation pane, choose Observability > CloudMonitor.
Click the Alert Rule tab.
Click the Group resource tab.
Find the Group for which you want to configure an alert, and click Create Alert Rule in the Actions column. The page redirects to the Create Alert Rule panel in the Cloud Monitor console.
In the Create Alert Rule panel, configure the following settings:
- Metric: Select the message accumulation metric MessageAccumulationV3 (Group Message Backlog Total).
- Alert conditions: Set the threshold value and the number of consecutive periods that must trigger the condition before an alert is sent.
- Notification method: Under notification contacts, select the DingTalk robot contact group that you configured as a prerequisite.
Click OK to save the alert rule.

After the rule is created, the Alert Rule tab displays the new rule with its status set to Enabled. When the Group message accumulation exceeds the configured threshold, Cloud Monitor sends a notification to the specified DingTalk robot.

View alert information

On the CloudMonitor page, click the Alert Rule tab. Then, select the tab for the resource whose alert information you want to view, such as Instance, Topic, or Group.
Find the resource and click Alert Rule in the Actions column.
In the Associated Alert Rules panel, find the target alert rule and click Details in the Actions column to view the rule configuration and alert history. You can also enable, disable, or delete the rule from this page.

FAQ

Does Cloud Monitor support CPU, memory, and daily write volume statistics?

CPU and memory monitoring: ApsaraMQ for Kafka does not directly expose CPU and memory monitoring metrics through Cloud Monitor. To monitor system resource utilization, refer to the Prometheus monitoring solution described in the Prometheus monitoring topic.
Daily write volume: Cloud Monitor does not provide a dedicated daily write volume view. You can estimate the daily write volume by using the following methods:
- Console: In the instance details page, go to Topic Management and view the write throughput (B/s) in the monitoring information for a target topic. Alternatively, on the Cloud Monitor page, view the Instance Actual Inbound Traffic (instance_message_input, unit: B/s) or Instance Message Production Count (instance_message_num_input, unit: count/s) metric, and multiply by the number of seconds in a day to estimate the daily volume.
- Prometheus monitoring: Query the instance_message_input (bytes/s) and instance_message_num_input (messages/s) instance-level metrics to obtain continuous inbound traffic data.
- API query: Use the QueryMessage API to query offset differences by timestamp, which allows you to calculate the precise number of messages produced within a given time range.

References

For Prometheus monitoring, see Prometheus monitoring.
For monitoring and alerting FAQs, see Monitoring and alerting FAQ.

Note

If metrics are not displayed, verify that the service-linked role AliyunServiceRoleForAlikafka is created and the instance is running.