Implementing Custom Metrics in AWS Applications

Monitoring application-specific behavior is a core requirement for the AWS Certified Developer - Associate (DVA-C02) exam. While AWS provides default metrics (e.g., CPU utilization, disk I/O), custom metrics allow developers to track business-level data like 'Items Sold', 'Cache Misses', or 'User Login Latency'.

Learning Objectives

By the end of this guide, you will be able to:

• Differentiate between standard metrics and custom metrics.
• Implement code using the PutMetricData API.
• Use the CloudWatch Embedded Metric Format (EMF) for high-performance metric emission.
• Define and manage metric dimensions to balance granularity and cost.
• Understand metric resolution and its impact on monitoring.

Key Terms & Glossary

• Namespace: A container for CloudWatch metrics. You must provide a namespace when you create a custom metric (e.g., MyCompany/PaymentService).
• Dimension: A name/value pair that is part of the identity of a metric. Adding dimensions helps you filter results (e.g., Environment=Production).
• Resolution: Defines the granularity of data points. Standard resolution is 1 minute; high resolution is 1 second.
• Embedded Metric Format (EMF): A JSON specification used to instruct CloudWatch Logs to automatically extract metric data from log streams.
• Cardinality: The number of unique combinations of dimensions. High cardinality can lead to increased costs.

The "Big Idea"

The "Big Idea" behind custom metrics is observability beyond infrastructure. Standard metrics tell you if the server is healthy, but custom metrics tell you if the application is healthy. By emitting metrics directly from your code, you close the gap between resource performance and business logic success.

Formula / Concept Box

Hierarchical Outline

1. Metric Definition Elements
   • MetricName: The specific name (e.g., OrderCount).
   • Unit: The type of value (e.g., Seconds, Bytes, Count, Percent).
   • Value: The numeric data point.
2. The SDK Approach (PutMetricData)
   • Best for real-time tracking of specific events.
   • Requires handling retries and batching.
   • Limits: Maximum 20 metrics per call; maximum 150 requests per second.
3. The Log-Based Approach (EMF)
   • Preferred for AWS Lambda to avoid blocking execution.
   • Requires structured JSON in a specific format.
   • Automatically processed by CloudWatch backend.

Visual Anchors

Metric Delivery Architecture

Anatomy of a Metric Structure

Definition-Example Pairs

• Dimension: A label to categorize data. Example: In a billing app, you might use a dimension PaymentType=CreditCard to see if credit card processing is slower than other methods.
• High-Resolution Metric: Metrics stored with 1-second granularity. Example: During a flash sale, you monitor TransactionVolume at high resolution to detect sub-minute spikes that could crash the DB.
• Metric Batching: Sending multiple data points in one API call. Example: Accumulating 20 different success/failure counts in memory and sending them once every minute to reduce PutMetricData costs.

Worked Examples

Example 1: Emitting a Metric with Python (boto3)

This example shows a synchronous call to track the number of processed files.

Example 2: EMF JSON Format (Manual)

If you aren't using the EMF library, you can simply print this JSON to stdout in a Lambda function.

Checkpoint Questions

1. What is the maximum number of metrics you can include in a single PutMetricData call?
2. Why is EMF preferred over PutMetricData for AWS Lambda functions?
3. What happens to the resolution if you omit the StorageResolution parameter in your code?
4. How does CloudWatch distinguish between the same MetricName that has different Dimensions?

[!TIP] Answer Key:

1. 20 metrics.
2. It is asynchronous and doesn't introduce network latency to the function execution.
3. It defaults to standard resolution (60 seconds).
4. It treats them as unique metrics; a metric is defined by its name AND its dimensions.