Recommended CloudWatch alarms for Amazon MSK Provisioned clusters
Monitor your Amazon MSK Provisioned clusters to detect issues before they affect your applications. CloudWatch alarms perform an action when a CloudWatch metric exceeds a specified value for some amount of time. For example, you might want to get an email notification if your partition count exceeds the recommended value for your broker instance size for longer than 15 minutes. The critical alarms in the following table are recommended, but they are not an exhaustive list of alarms you can create to monitor your cluster.
For more information about configuring alarms, see Creating Amazon CloudWatch alarms in the Amazon CloudWatch User Guide.
The following table lists alarms that apply to both Standard and Express brokers.
| Alarm | Issue |
|---|---|
|
Dimensions: |
One or more brokers have average CPUUser+CPUSystem over the recommended 60%. To learn more, see Monitor CPU usage. |
|
Dimensions: |
One or more brokers have partitions higher than the recommended partition count limit. To learn more, see Right-size your cluster: Number of partitions per Standard broker and Express broker partition quota. |
|
Dimensions: |
The aggregated offset lag for all the partitions in a topic is over
X. For more information about the lag, you can
use the partition-level |
The following table lists alarms that apply to Standard brokers only.
| Alarm | Issue |
|---|---|
|
Dimensions: |
One or more topic partitions are unavailable. When partitions are unavailable, produce and consume operations to those partitions fail. Offline partitions should not occur on a well-balanced, correctly sized, and correctly configured cluster. To learn more, see Build highly available clusters. |
|
Dimensions: |
One or more topics have partitions under the minimum configured in-sync
replica set (ISR). When partitions fall below the minimum ISR, produce
operations fail (with producer |
|
Dimensions: |
One or more brokers have data disk usage of 80% or more. To learn more, see Monitor disk space. |
|
Dimensions: |
One or more brokers have 60% or more of total heap memory in use after garbage collection. To learn more, see Monitor Apache Kafka memory. |
|
(Sum( Dimensions: |
One or more brokers have underlying volume read and write activity using up 80% of its available volume throughput. To learn more, see Provisioned storage throughput. |
|
Dimensions: |
This is only relevant to the t3.small broker type. One or more brokers have depleted their CPU credit balance from a maximum of 576 to less than 100. When the balance reaches 0, the broker cannot exceed the 20% CPU baseline. To avoid CPU credit depletion, upgrade from a t3 broker instance type to an m7g instance type, which doesn't use CPU credits. |
|
Dimensions: |
One or more brokers are seeing activity congestion on the threadpool responsible for serving requests (threadpool is less than 30% idle). Saturation here indicates slow requests, which can cause client-side timeouts. Also, review whether your clients are generating excessive requests. For example, unauthorized clients might be aggressively retrying requests that the brokers are denying. To learn more about optimizing cluster throughput, see Optimize cluster throughput for m5.4xl, m7g.4xl or larger instances. |
|
Dimensions: |
One or more brokers are seeing activity congestion on the network connection threadpool (threadpool is less than 30% idle). Saturation here can cause timeouts. Also, review whether your clients are generating excessive requests. For example, unauthorized clients might be aggressively retrying requests that the brokers are denying. To learn more about optimizing cluster throughput, see Optimize cluster throughput for m5.4xl, m7g.4xl or larger instances. |
|
Dimensions: |
The percentage of file descriptors in use on the broker. At 100%
exhaustion, the Kafka broker might not be able to start. The file
descriptors count increases with the number of partitions, number of log
segments in each partition, and number of client connections. Review
whether you have topics with low |
|
Dimensions: |
The percentage of memory-mapped files in use on the broker. At 100%
exhaustion, the Kafka broker might not be able to start. The memory-mapped
files usage count increases with the number of partitions and number of
log segments in each partition. Review whether you have topics with low
|
IAM access control alarms
In addition to the preceding alarms, we recommend creating alarms for the following metrics specific to IAM access control. These alarms apply to both Standard and Express brokers with IAM authentication enabled. Amazon MSK places logical limits on IAM connections to protect the broker from IAM connection request overload. Breaching any of these limits results in client connection timeouts, which will impact your workload.
| Alarm | Issue |
|---|---|
|
Dimensions: |
One or more brokers have connection count equal to 80% of the connection limit. The default Maximum TCP connections per broker for IAM access control is 3000. This value can be changed. For more information, see Amazon MSK Express broker quota for Express brokers and Amazon MSK Standard broker quota for Standard brokers. |
|
Dimensions: |
One or more brokers have clients creating IAM connections at a rate equal to 80% of its connection creation rate limit. The Maximum TCP connections rate per broker for IAM access control depends on instance size. For more information, see Amazon MSK Express broker quota for Express brokers and Amazon MSK Standard broker quota for Standard brokers. |