- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
When you create a Target Tracking policy, it will automatically create both a High and Low usage alarm based on your target value and the current provisioned capacity. When you have very low usage like this, its expected for the Low alarm to stay in Alarm state.
Being in the ALARM state isn't a bad thing, its just indicating your usage is low, and you can ignore these alarms. Since your provisioned capacity is already at the Min size of 1 that you configured, AutoScaling will ignore the alarm notifications and doesn't need to do anything.
Based on the information from your screenshots, since the maximum provisioned write capacity is 10 units (as per your auto scaling settings), the graph displaying ConsumedWriteCapacityUnits
will always be below the threshold of 30. This means the condition for the alarm ("ConsumedWriteCapacityUnits < 30 for 15 datapoints within 15 minutes") is continuously met, and therefore, the alarm should technically be in an "In alarm" state all the time.
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 9 Monaten
The ConsumedWriteCapacityUnits can be 60x higher than Provisioned Capacity, since the metric is looking at the SUM of the Consumed Capacity over the minute, so the value of <30 here is fine, and it could get passed with the current provisioned capacity. 1 Provisioned Capacity used constantly for the minute would result in a ConsumedCapacity metric of 60, and lead to scaling out
Is this alarm regular or not? Will it always be visible or not? I want to understand what does '30' refer to? Will it remain visible even when using capacity 1?
What @Shahad_C explained it is correct.
Is this alarm regular or not?
The alarm you've described is set to trigger when the
ConsumedWriteCapacityUnits
is less than30
for15
datapoints within a 15-minute period. This is a regular type of alarm in the context of AWS CloudWatch, where you're monitoring a specific metric (in this case,ConsumedWriteCapacityUnits
) and setting conditions for when an alarm should be triggered. @Shahad_C explained well in the comment.Will it always be visible or not?
If the
ConsumedWriteCapacityUnits
metric consistently stays below30
for15
datapoints within a 15-minute period, the alarm will indeed be in the ALARM state. This is because the condition you've set for the alarm isConsumedWriteCapacityUnits < 30
. So, whenever the metric falls below this threshold, the alarm condition is met, and the alarm state will be ALARM.Conversely, if the metric is above or equal to
30
, the alarm will be in the OK state because the condition for triggering the alarm (being below 30) is not met.What does '30' refer to?
The
30
in your alarm condition refers to the threshold value for theConsumedWriteCapacityUnits
metric. If the sum ofConsumedWriteCapacityUnits
is less than30
for15
consecutive data points within a 15-minute window, the alarm condition will be met.