Business stakeholders want a CloudWatch metric for permits submitted, emitted from the application's structured logs, without flooding the API with separate PutMetricData calls. Which approach should developers implement?
Select an answer to reveal the explanation.
Short Explanation
EMF is the packing slip inside the log box: one structured write, CloudWatch lifts the metric out. Spamming PutMetricData on every heartbeat is how request paths drown themselves.
Full Explanation
Business stakeholders wanting a CloudWatch metric for permits submitted—emitted from structured logs without flooding the API with separate PutMetricData calls—should use CloudWatch embedded metric format (EMF). The application writes a structured log event that includes metric declarations; CloudWatch extracts metrics automatically. That keeps the hot path to one structured write while still feeding dashboards for municipal throughput KPIs that council and ops both understand.
Printing unstructured free-text only and hoping CloudWatch invents metrics without EMF or metric filters fails to produce reliable numeric series. Calling PutMetricData once per character of every log line would crush the request path with API overhead. Storing metrics exclusively on instance-store ephemeral disks never reaches CloudWatch for shared civic dashboards.
Exam caveat: EMF and metric filters are both valid paths from logs to metrics; EMF is especially suited when developers control structured log output and want low-overhead metric emission on the request path.
Operational check: emit an EMF log line when a permit is submitted, confirm the metric appears in CloudWatch within the expected delay, graph it on the permitting dashboard, and verify request latency did not regress versus chatty PutMetricData loops.