How to query the peak TPS of an instance - ApsaraMQ for RabbitMQ

You can query the peak Transactions Per Second (TPS) of an ApsaraMQ for RabbitMQ instance to monitor traffic and prevent throttling.

Background information

If the peak TPS of your actual traffic exceeds the TPS limit of your instance, the ApsaraMQ for RabbitMQ instance is throttled.

To prevent throttling from disrupting your business, monitor instance peak TPS as a key O&M metric. Tracking peak TPS trends helps you get early warnings before exceeding instance specifications and determine whether the current instance type meets your business needs.

Query methods

ApsaraMQ for RabbitMQ provides the following methods to query instance peak TPS.

Query method	Description	Time granularity	Resource level
(Recommended) Query instance peak TPS and set alerts using Cloud Monitor	Advantages: Query results cover up to 14 days of peak TPS changes, helping you quickly identify abnormalities. Supports alert configuration using instance peak TPS as a monitoring metric. Free to use.	Minute-level peak TPS The value is the maximum TPS per second within a 1-minute window.	Instance-level peak TPS
(Recommended) Query instance peak TPS from the instance details page	Advantages: Supports second-level peak TPS queries, helping you precisely pinpoint abnormalities. Supports viewing the peak TPS of specific API operations. Free to use. Disadvantage: Only data from the last 10 minutes is shown, to avoid displaying excessive data.	Second-level peak TPS	Instance-level peak TPS Peak TPS of a specific API operation within the instance
Query instance peak TPS using log query	Advantage: Supports SLS analytic statements, suitable for complex troubleshooting scenarios. Disadvantages: More complex to operate and less intuitive than the first two methods. You must pay separate fees for Simple Log Service. For more information about billing, see Billing items of Simple Log Service.	Second-level peak TPS	Instance-level peak TPS

Query instance peak TPS and set alerts using Cloud Monitor

Query instance peak TPS

Log on to the ApsaraMQ for RabbitMQ console. In the left-side navigation pane, click Instances.
In the top navigation bar of the Instances page, select the region where the instance that you want to manage resides. Then, in the instance list, click the name of the instance that you want to manage.
In the navigation pane on the left, click Monitoring and Alerting.
On the Monitoring and Alerting page, select Instance from the Group drop-down list and specify a time range for the query.

The following figure shows an example of querying instance peak TPS:

Set alerts for API peak TPS

Log on to the ApsaraMQ for RabbitMQ console. In the left-side navigation pane, click Instances.
In the top navigation bar of the Instances page, select the region where the instance that you want to manage resides. Then, in the instance list, click the name of the instance that you want to manage.
In the navigation pane on the left, click Monitoring and Alerting.
In the upper-right corner of the Monitoring and Alerting page, click Create Alert Rule.

You are redirected to the Create Alert Rule panel in Cloud Monitor.
In the Set Rule Description panel, configure the alert rule. From the Monitoring Metric drop-down list, select Instance > Instance API Request Rate Peak (Max per minute). For more information, see Alert service.

Query instance peak TPS from the instance details page

Log on to the ApsaraMQ for RabbitMQ console. In the left-side navigation pane, click Instances.
In the top navigation bar of the Instances page, select the region where the instance that you want to manage resides. Then, in the instance list, click the name of the instance that you want to manage.
On the Instance Details page, click the Peak TPS Query tab.

Note
You can query peak TPS data for the last 15 days at per-second granularity. To avoid displaying excessive data, only data from the last 10 minutes is shown.

If you find no data or inconsistent data in TPS monitoring during a spike, this is typically caused by differences in monitoring aggregation granularity. Queries over large time ranges (for example, 24 hours) may display averaged values, while queries over smaller time ranges (for example, 3 hours) provide more precise data. To accurately troubleshoot anomalies, narrow the query time range to the period around the spike (for example, select a 10-minute or shorter time window) to obtain accurate per-second peak TPS data.
- To query instance-level peak TPS:
  
  Click the Query by Instance tab, select a time range, and then click Query.
- To query API-level peak TPS:
  
  Click the Query by API tab, select a time range, and then click Query.

Query instance peak TPS using log query

For more information, see Quick start for query and analysis.

The following is an example of an analytic statement:

(Action : ConnectionOpen or Action : ChannelOpen or Action: ExchangeDeclare or Action: QueueBind or Action : QueueDeclare or Action : QueueDelete or Action : ExchangeDelete or Action : QueueUnBind or Action : ExchangeBind or Action : ExchangeUnBind or Action : BasicConsume or Action : BasicReject or Action : BasicRecover or Action : SendMessage or Action : BasicAck or Action : BasicNack or Action : BasicGet ) | select from_unixtime(cast(microtime as bigint)/1000/1000) as time, COUNT(*) as count GROUP by time ORDER by time limit 90000000

FAQ

Why does message consumption latency vary significantly across different time periods (for example, fast in the morning and slow in the afternoon)?

This is typically not caused by system dispatch delays from the platform. During peak hours, if the message sending rate exceeds the processing capacity of your consumer clients, queue backlog builds up. Combined with slow ACK processing on the consumer side, this results in significantly higher consumption latency. Instance peak TPS is an instance-level metric that reflects overall message throughput; it does not directly indicate consumer-side performance issues.

To resolve the issue, consider the following optimizations:

Increase the number of consumer clients to improve parallel consumption capacity.
Optimize ACK processing logic to reduce per-message processing latency.