Dead man's switch with CloudWatch

Andreas Wittig – 17 Jul 2018

While writing this article, I’m traveling from Frankfurt to Stuttgart by high-speed train (ICE) with a top speed of 280 km/h. It is reassuring to know that a dead man’s switch stops the train immediately if the train driver becomes incapacitated, such as through death, loss of consciousness, or being bodily removed from control.

Dead man's switch with CloudWatch

Even though you are typically using CloudWatch alarms to make sure a metric does not exceed a threshold, it is also possible to build a dead man’s switch with CloudWatch. Doing so allows you to monitor the health of processes and jobs. A few examples for typical failures to monitor with a dead man’s switch often called heartbeat monitoring as well:

  • A daily backup did not complete.
  • It was not possible to generate a daily report.
  • An recurring import job failed.

The following example guides you through how to monitor a job backing up the home directory of an EC2 instance to S3 every 4 hours. You will learn how to create a dead man’s switch consisting of the following building blocks:

  1. A CloudWatch custom metric collecting heartbeats from the backup job.
  2. A CloudWatch alarm is monitoring the metric for missing heartbeats.

Collecting heartbeats

An EC2 instance publishes CloudWatch metrics like the CPU utilization, the number of read operations on disk, or the number of bytes sent out. Almost every other AWS service is publishing metrics as well. On top of that, you can publish a heartbeat to a custom metric as well.

The following snippet shows a backup script triggered by a cronjob every four hours.

  1. Synchronize the folder /home to S3.
  2. Send a heartbeat to a custom metric.
#!/bin/bash -e
aws s3 sync /home s3://my-company-backup/home
aws cloudwatch put-metric-data --namespace custom/backup --metric-data 'MetricName=heartbeat,Dimensions=[{Name=source,Value=home}],Value=1'

How does publish a heartbeat to CloudWatch work?

  1. aws cloudwatch put-metric-data sends data to a custom metric.
  2. custom/backup is the namespace used for this example.
  3. The name of the custom metric is set to MetricName=heartbeat.
  4. The backup source (the home directory) is used as dimension: Dimensions=[{Name=source,Value=home}]

Learn more about custom metrics. Of course, it is also possible to publish heartbeats by using one of the AWS SDKs directly from within your application.

Next, to get notified whenever the backup job does not succeed anymore you only need to create a CloudWatch alarm.

Monitoring heartbeats

A CloudWatch alarm monitors a metric and triggers actions. For example, you can use a CloudWatch alarm to notify you whenever the CPU utilization of an EC2 instance is above 80% for more than 60 minutes. However, it is also possible to implement a dead man’s switch with the help of a CloudWatch alarm as described next.


Looking for a new challenge?

  • tecRacer

    Cloud Consultant

    tecRacer • Premier AWS Consulting Partner • Germany, Austria, Portugal, and Switzerland
    AWS only Infrastructure as Code EC2 Containers Serverless
  • tecRacer

    Cloud Migration Specialist

    tecRacer • Premier AWS Consulting Partner • Germany, Austria, Portugal, and Switzerland
    Lift&Shift Transformation EC2 RDS VPC

As illustrated in the following figure the following steps are necessary to start creating a new CloudWatch alarm:

  1. Open the CloudWatch service within the AWS Management Console.
  2. Select Alarms from the sub-navigation.
  3. Click the Create Alarm button.

Dead man's switch with CloudWatch (1/3)

The following figure shows how to select the custom metric.

  1. Choose the namespace custom/backup.
  2. Select the metric with the metric name heartbeat and source home.
  3. Click the Next button.

Dead man's switch with CloudWatch (2/3)

The last step is to configure the alarm as illustrated in the following figure.

  1. Type in deadmanswitch-backup-home as the Name and a Description for the alarm.
  2. Select < 0 as the threshold for the alarm …
  3. … for 1 out of 1 data points.
  4. Most importantly, set treat missing data as to bad.
  5. Select a timeframe of 6 hours.
  6. Select the statistic method Sum.
  7. Define an ALARM action.
  8. Create a new list and enter your email address.
  9. Don’t forget to press the Create Alarm button.

Dead man's switch with CloudWatch (3/3)

By default, a CloudWatch alarm is entering the state INSUFFICIENT_DATA when there are no data points within the specified timeframe, which is 6 hours in our example. As we are configuring the alarm to treat missing data as bad, the alarm will enter the state ALARM instead of INSUFFICIENT_DATA. Learn more about how alarms treat missing data.

Summary

Creating a dead man’s switch with the help of CloudWatch allows you to monitor if jobs are working as expected. I’ve used this approach to monitor an agent responsible for synchronizing data from an on-premises database to DynamoDB, for example.

Thanks a lot, Josh. Your feedback improved the bash script and dead man’s switch.

Become a cloudonaut supporter

Andreas Wittig

Andreas Wittig ( Email, Twitter, or LinkedIn )

We launched the cloudonaut blog in 2015. Since then, we have published 350 articles, 45 podcast episodes, and 38 videos. It's all free and means a lot of work in our spare time. We enjoy sharing our AWS knowledge with you.

Please support us

Have you learned something new by reading, listening, or watching our content? With your help, we can spend enough time to keep publishing great content in the future. Learn more

$
Amount must be a multriply of 5. E.g, 5, 10, 15.

Thanks to Alan Leech, Alex DeBrie, ANTHONY RAITI, Christopher Hipwell, Jaap-Jan Frans, Jason Yorty, Jeff Finley, Jens Gehring, jhoadley, Johannes Grumböck, John Culkin, Jonas Mellquist, Juraj Martinka, Kamil Oboril, Ken Snyder, Ross Mohan, Ross Mohan, sam onaga, Satyendra Sharma, Shawn Tolidano, Thorsten Hoeger, Todd Valentine, Victor Grenu, and all anonymous supporters for your help! We also want to thank all supporters who purchased a cloudonaut t-shirt.