Possible to editing alarm name and delete created metrics in Cloudwatch

0

Hi!

I'm trying to do a bit of clean up in CloudWatch, but I run into some problem. I'm still a newbie at Clouwatch so I'm hoping there are some easy answers to my questions. Having said this, I'm quite surprised why what I try to achieve seems to be hard.

1. Is it not possible to edit an alarm name?

When I go into edit mode of an already created alarm, I can edit the Metric name that the alarm is based on, but not the actual alarm name itself (step 3: Add name and description). That input box for the name is greyed out, i.e. readonly. Since all alarms appear in a list and there is no possibility as far as I know to have tree view hierarchy in this list, you do want to group alarm names in order to get some kind of overview and hierachy to find an alarm you are loking for. To me, it seems like the choice has been made under the CloudWatch hood to make the name of the alarm act as the programming identifier, i.e. not editable. Why? So my question boils down to: is it only possible to edit the alarm name by deleting the alarm and recreating it?

2. Some metrics seem impossible to delete

When I was new to CloudWatch I accidentally created several different namespaces for the same namespace (mistyped). So I need to clean up and move some metrics from one namespace to another. To move a metric from one namespace to another does not seem possible, so I recreated the metric with the correct namespace name. But now I find that it is impossible (?) to delete the old metric with the old incorrect namespace. If I use the menu option "Metrics -> All metrics" I'll get an overview of all namespaces under the browse tab. But there is no way I can see to delete neither the metric, nor the faulty namespace they reside in in this view. How do I achieve this? If I go into the main LogGroups view, there is a column "Metric Filters" in the grid that shows a link to the metrics attached to each LogGroup. But the metrics with faulty namespaces do not appear anywhere which may be because the old log group they were based on may have been deleted. If so I guess they were deattached from the parent LogGroup and no longer accessible? So why were they not deleted when the LogGroup was deleted (cascading delete) and why is it not possible (?) to delete a parentless LogGroup if so?

asked 2 years ago2896 views
3 Answers
2
Accepted Answer

Hi, You cannot delete a metric from CloudWatch, you stop emitting it. That means that

  • if you don't need the metric anymore, you dismiss the resource or stop calling the API, the metric will not receive any new data. It will still appear during 2 weeks, and then disappear
  • if you still need the metric but under a different name/namespace, you update the name in your API/agent config, and you will see the metric under both names for 14 days: it will still appear under the old name with past data, and under the new name with new data, until 2 weeks after you made the change. At that time, CloudWatch will stop showing the old name as it won't have received new data for that old name for a continued period of 2 weeks, and only the new name will remain visible in the console from then on

Sorry I'm not sure I understand what you mean with the alarm not triggering. Alarms do not disappear automatically, they keep on evaluating. If you stop emitting a metric or rename it, you should update your alarm's definition (or delete the alarm if you don't need it anymore).

profile pictureAWS
Jsc
answered 2 years ago
2

Hi,

to question 1, the answer is yes, the only way to change the alarm name is to delete it and recreate it.

To question 2, you don't "delete" the metrics from CloudWatch, you stop sending them. They will still appear for 2 weeks in your console (support pages state "A metric is available in the CloudWatch console only if a data point was pushed to the metric in the last 14 days"). After that, they should automatically stop showing in your console.

profile pictureAWS
Jsc
answered 2 years ago
    1. Ok. Thanks

    2. I don't follow. Seems like I am missing something completely here. So the only way to actually "delete" a metric you no longer want and it's namespace, is to change the metric to some filtered value that never gets collected and then it will disappear after 14 days? This seems a bit odd to me considering that you may have an alarm set up based on a metric value that should never occur (e.g. an error). So if the alarm is not triggered due to that the error never occured (which is correct) during 14 days, the metric and the alarm automatically disappears? Why not adding the possibility to clean up your metrics and the created namespaces a bit more active instead of reactive?

0

If you have an alarm based on a metric that should never occur, the alarm will be in an 'insufficient data' state until it receives something. Under additional configuration, you can set the missing data treatment behaviour on the alarm for it to be 'good' if you want to keep it in an OK state when data hasn't been received.

profile picture
answered 2 years ago
  • Yep. That's how I set it up today. I was just wondering what happens to the alarm if the metric that it is based on disappears after 14 days because the metric was disappeared due to that "no data point was pushed" to it.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions