DVA-C02 Logs, Metrics, Alerts, and Health Checks Guide

This lesson is about building observability into the application instead of hoping infrastructure will explain everything later. DVA-C02 wants developers to understand logging strategy, custom metrics, alerts, tracing annotations, and the difference between liveness and readiness signals.

Structured logging: Logging approach where fields such as user ID, request ID, action, and status are emitted in a machine-readable format.

Health check: Probe or endpoint used to determine whether an application instance is alive, ready, or safe to receive traffic.

What AWS is really testing here

AWS wants you to know:

• why logging, monitoring, and observability are related but not identical
• when custom metrics are better than only raw log review
• how alerts should point at actionable conditions instead of raw noise
• why readiness and health checks influence traffic flow and diagnosis
• why application-level instrumentation matters even when AWS already gives infrastructure metrics

Choose the right observability output

Logging, metrics, and health checks work together

    flowchart LR
	    A["Application code"] --> B["Structured logs"]
	    A --> C["Custom metrics / EMF"]
	    A --> D["Tracing annotations"]
	    A --> E["Health endpoints"]
	    C --> F["Dashboards and alerts"]
	    E --> G["Traffic decisions and deployment safety"]

Strong answers usually prefer:

• structured logs instead of giant free-form debug blobs
• business or app metrics for things infra metrics cannot express
• alerts that map to a response, not just to any activity
• readiness probes when traffic should wait for dependencies to be ready

Instrument for the question you will ask later

Developers often log too much text and too little structure. DVA-C02 prefers instrumentation that helps future diagnosis:

• request IDs
• tenant IDs where appropriate
• operation names
• status or result fields
• latency or size values that can become metrics

Small Python example:

1import json
2import time
3
4def emit_order_metric(order_id: str, started_at: float) -> None:
5    print(json.dumps({
6        "orderId": order_id,
7        "latencyMs": int((time.time() - started_at) * 1000),
8        "status": "success",
9    }))

The point is not a logging framework choice. The point is that application instrumentation should preserve searchable context and measurable signals.

Common traps

• writing verbose unstructured logs that are hard to search under pressure
• emitting no business or application metrics beyond infrastructure defaults
• alerting on every event instead of actionable thresholds
• assuming a running process is automatically ready to serve traffic correctly

High-confusion pairs

Decision order that usually wins

1. Separate business-specific signals, log structure, traffic-readiness gating, and alert quality.
2. If infrastructure metrics miss the real application behavior, emit custom application metrics.
3. If troubleshooting under pressure is hard, improve structured logging before adding more prose logs.
4. If a service should not receive traffic until dependencies are ready, think readiness checks.
5. If pages are noisy, redesign for actionable thresholds instead of adding more alerts.

Quiz