One CloudWatch alarm watches a heartbeat metric that the application publishes every minute. Another watches a sparse error metric that is published only when an error happens. How should missing data be treated?
Select an answer to reveal the explanation.
Short Explanation
A heartbeat that goes silent is the patient missing, so you treat missing data as bad. A sparse error metric is quiet when nothing is wrong, so missing data is good. You do not page all night because nobody made a mistake.
Full Explanation
CloudWatch can treat missing data as breaching, not breaching, ignore, or missing. A heartbeat that stops is a failure, so missing datapoints should breach. An error metric that is only published on failure should not breach when it is absent, or every quiet hour pages. Treating both as breaching pages on the quiet error metric. Treating the heartbeat as not breaching hides a dead publisher. Ignoring the heartbeat and deleting the error alarm drops both signals. Caveat: a heartbeat that is published on a longer period than the alarm's evaluation looks missing even when the publisher is fine, so match the periods. Operational check: stop the heartbeat publisher and confirm that alarm enters ALARM, and confirm the error alarm stays OK while no errors are published. Set the heartbeat alarm's missing-data treatment to breaching and the error alarm's to not breaching. Do not use ignore on the heartbeat or a dead publisher looks like a gap you chose to skip. Match the heartbeat period to how often the application publishes, or a healthy publisher looks missing. Stop the publisher in a test and watch only the heartbeat alarm change.