Creating A CloudWatch Alarm When A Mount Point Is Created On EC2 Instances

0

Hi,

I am interested in creating alarms to monitor the disk space of my EC2 instances. I have configured the CloudWatch Agent on them and succesfully seeing the metrics in CloudWatch.

What I would like to see is possible is if there is a pattern I can follow so that once a new mount point is created that a corresponding alarm would be created per mount point? and vice versa if a mount point is removed then the corresponding alarm could be deleted?

I was thinking I can have a lambda to do this but I am unclear on what change I should be looking at that could trigger the lambda for it to then create the alarms?

Regards, Jon

jga
asked 3 months ago456 views
1 Answer
1

Hi,

if an aggregated alarm was enough, using an SQL query to match your metrics would be enough. The limitation is that you can only alarm on the aggregate (e.g. the MAX or AVG of selected metrics) with this technique.

If you need an alarm per mount point, so that you get a dedicated notification for each mount point with the name of the mount point in the notification, you need to create individual alarms and therefore detect mount point changes. Using a lambda is a good way to create, update or delete an alarm. There are a few ways you could consider to trigger your lambda:

  • Ideally, post an Eventbridge event or SNS notification when you add or delete a mount point. If you control adding or deleting mount points from a script, you could add a call to the AWS cli to post the event or notification. Then configure your lambda to trigger on that event or notification. Pros: the alarm is created or deleted very fast after the event. Cons: if for some reason your script fails to trigger the event or notification, you may miss an alarm update. To mitigate the risk of missing you an alarm update, you can post the event or notification before altering the mount point, continue your script only after the event or notification has been posted, and delay the SQS message delivery so that the lambda starts only after the mount point change. Another alternative would be to invoke the lambda directly from the script that controls altering mount points.
  • Using a scheduled approach: trigger the lambda periodically (e.g. every hour), list the metrics with the corresponding namespace and name, and check the activity of those metrics. Pros: allows to ensure you don't miss an update. Cons: more complex to setup, requires several of checks (you need to check if a metric is active otherwise you may keep an alarm on a deleted mount point up to 2 weeks after the mount point was deleted) and lacks reactivity
  • Using a combination of both (event for reactivity, and a schedule to do some garbage collection)
profile pictureAWS
Jsc
answered 3 months ago

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