How should the developer modify the Lambda function to meet this requirement with the LEAST operational overhead?

By:
On:
In: DVA-C01
Tagged:
With: 0 Comments
A company has an AWS Lambda function that runs hourly, reads log files that are stored in Amazon S3, and forwards alerts to Amazon Simple Notification Service (Amazon SNS) topics based on content.A developer wants to add a custom metric to the Lambda function to track the number of alerts of each type for each run.The developer needs to log this information in Amazon CloudWatch in a metric that is named Lambda/AlertCounts.

How should the developer modify the Lambda function to meet this requirement with the LEAST operational overhead?

Add a print statement to standard out for each alert and the number of occurrences.

Add a call to the PutMetricData API operation. Pass an array for alerts and the number of occurrences in the Values and Counts fields with a namespace of “Lambda/AlertCounts”.

Add a call to the PutMetricAlarm API operation. Pass an array of alerts in the metrics member with the namespace of “Lambda/AlertCounts”.

Add a call to the PutDashboard API operation. Pass an array of alerts in the metrics member with the namespace of “Lambda/AlertCounts”.

Explanations:

A print statement does not create a custom metric in CloudWatch. It will log to CloudWatch Logs, not CloudWatch Metrics.

The PutMetricData API allows the Lambda function to send custom metrics (alert counts) to CloudWatch. This meets the requirement to track alerts with the least operational overhead.

PutMetricAlarm is used to create CloudWatch Alarms, not to send custom metrics. This does not fulfill the requirement.

PutDashboard is used to create CloudWatch Dashboards, not for logging custom metrics. This does not fulfill the requirement.

Leave a Reply

Your email address will not be published. Required fields are marked *

eighteen − 17 =