Amazon EC2 AutoScaling CPUUtilization Alarm-INSUFFICIENT DATA

Question

So I've been using Boto in Python to try and configure autoscaling based on CPUUtilization, more or less exactly as specified in this example: http://boto.readthedocs.org/en/latest/autoscale_tut.html

However both alarms in CloudWatch just report:

State Details: State changed to 'INSUFFICIENT_DATA' at 2012/11/12 16:30 UTC. Reason: Unchecked: Initial alarm creation

Auto scaling is working fine but the alarms aren't picking up any CPUUtilization data at all. Any ideas for things I can try?

Edit: The instance itself reports CPU utilisation data, just not when I try and create an alarm in CloudWatch, programatically in python or in the interface. Detailed monitoring is also enabled just in case...

Thanks!

Answer 1

The official answer from AWS goes like this:

Hi, There is an inherent delay in transitioning into INSUFFICIENT_DATA state (only) as alarms wait for a period of time to compensate for metric generation latency. For an alarm with a 60 second period, the delay before transition into I_D state will be between 5 and 10 minutes.

John.

Apparently this is a temporary state and will likely resolve itself.

Answer 2

I am not sure what's going on in the backend, but if you compare the alarm history you will see AWS remove the 'unit' column if you just modify the alarm without any change as at7000ft said. So remove the unit column of your script.

Answer 3

Make sure that the alarm's Namespace is 'AWS/EC2'.

I know this is a long time after the original question, but in case others find this via Google, I had the same problem, and it turned out I set alarm's Namespace improperly.

Answer 4

It is needed to publish data with the same unit used to create the alarm. If you didn't specify one, it will be a <None> unit.

Unit can be specified in aws put-metric-data and aws-put-metric-alarm with --unit <value>

Unit <value> can be:

• Seconds
• Bytes
• Bits
• Percent
• Count
• Bytes/Second (bytes per second)
• Bits/Second (bits per second)
• Count/Second (counts per second)
• None (default when no unit is specified)

Units are also case-sensitive, be carefull about that in your scripts.

For CPUUtilization, you can use Percent.

After the first data-set is sent to your alarm (it can take up to 5 minutes for a non-detailed monitored instance), the alarm will switch to the OK or ALARM state instead of the INSUFFICIENT_DATA one.

Answer 5

I am having the same INSUFFICIENT_DATA alarm state show up in CloudWatch for an RDS CPUUtilization > 60 alarm created with CloudFormation. ("Reason: Unchecked: Initial alarm creation" shows up under details). This is a very crude fix but I found that by selecting the alarm, clicking the Modify button, and then the Save button (without changing anything) the alarm goes to the OK state and everything is file.

Answer 6

I had this problem. Make sure the metric name you use to create the alarm matches the actual metric name.

You can list your metrics with:

aws cloudwatch list-metrics --namespace=<NAMESPACE, e.g. System/Linux, etc>

Find the metric and the MetricName. Make sure your alarm is configured for that metric.

Answer 7

As far as I know, default metric resolution is 5 minutes (which can be lowered to 1 minute if you pay up, or something like that), so if your alarm's measurement period is lower than that, then it'll remain permanently in an INSUFFICIENT_DATA state. In my case, I had a 1 minute measurement period on CPU utilization, and changing it to 5 minutes has fixed the state issue.

Answer 8

I had a similar problem, my alarm was constantly in INSUFFICIENT_DATA status although I can see the metric in the GUI.

Come out that this happen, because I specified the wrong Unit for the metric, when I created the Alarm. No error was reported back but it never became GREEN.

Better to avoid to specify it, if you are not sure, and AWS will do the correct match in the background.

Answer 9

There is a directory /var/tmp/aws-mon/ that contains a couple files. One is instance-id. The instance I was on was created from an AMI and this file retained the old instance id. I just edited it and made sure /var/tmp/aws-mon/placement/availability-zone was also correct. The alarms changed to OK almost instantly.

Answer 10

Also ran into this problem but for a different reason: I passed ES cluster ARN instead of domain name in my Cloudformation template. It was pretty frustrating