Troubleshooting and Optimization
Application Observability, Structured Telemetry, Alerts, and Health Signals
CoreInstrument application code with safe structured logs, custom metrics, trace context and annotations, notifications, and traffic-relevant health checks.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Monitoring can show that a threshold crossed, but observability requires enough application-produced evidence to explain internal state and distributed behavior. Instrumentation must be designed in code before an incident.
Must Know
- Logging records events, monitoring watches selected signals and conditions, and observability uses emitted evidence to understand system behavior and investigate previously unanticipated questions.
- An effective logging strategy emits consistent timestamps, levels, event or action names, outcomes, safe context, and correlation IDs while redacting sensitive fields.
- Structured logging means stable machine-queryable fields, not merely wrapping an arbitrary message in JSON.
- Custom metrics should represent application or business behavior at the code point where the outcome is known and use bounded dimensions.
- X-Ray annotations are indexed for filtering traces; metadata can carry additional detail but is not indexed in the same way. Keep both non-sensitive.
- Tracing needs context propagation across supported service and custom code boundaries plus segments or subsegments for meaningful work.
- An alarm or service event can route a threshold or state change through an appropriate notification target; a dashboard alone does not notify responders.
- A health check reports health according to its contract. A readiness probe specifically indicates whether a process or container should receive traffic now.
Compare and Distinguish
- Logging vs monitoring vs observability: event capture, selected signal surveillance, and explainable system behavior are related but not synonymous.
- Structured log vs EMF custom metric: structured logs support queries; EMF adds the required metric declaration for CloudWatch extraction.
- Trace annotation vs metadata: annotations are indexed for trace filtering; metadata adds non-indexed detail.
- Alarm vs dashboard: an alarm evaluates a condition and can trigger action; a dashboard presents signals for human review.
- Health vs readiness: general health can describe process or dependency state; readiness determines whether traffic should be sent now.
- Correlation ID vs sensitive identifier: use a safe opaque request value, not a token, secret, or raw classified field.
Scenario examples
- Scenario: Engineers cannot find all work for one request across services. Propagate trace context and a safe correlation ID into structured logs.
- Scenario: Standard service metrics do not show failed checkouts. Emit a bounded-dimension custom metric where the application knows the business outcome.
- Scenario: Responders must know when a quota or deployment condition occurs. Create the alarm/event condition and route it to the intended notification target.
- Scenario: A new container process is running but has not loaded required configuration. Keep it out of traffic until its readiness check succeeds.
Exam traps
- Monitoring one threshold is not complete observability.
- JSON syntax alone does not make fields stable, safe, or queryable.
- Do not use user IDs, request IDs, or arbitrary values as unbounded metric dimensions.
- Trace metadata is not an indexed substitute for annotations.
- A dashboard does not proactively deliver an alert.
- A process that is alive is not necessarily ready to serve traffic.
Key takeaways
- Instrument logs, metrics, and traces as complementary evidence.
- Design stable safe fields and propagate correlation context.
- Emit bounded business metrics where outcomes are known.
- Route actionable conditions to notifications.
- Make readiness reflect real ability to serve without turning the task into cluster administration.
How it works
- Application code emits structured events and custom metrics at meaningful state transitions.
- Trace context follows the request and annotations make bounded business dimensions searchable.
- CloudWatch evaluates signals and alarms, while notification integrations route actionable conditions.
- The runtime or load-balancing surface uses health/readiness results to decide traffic eligibility.
When to use it
- Use structured logs for event detail and investigation.
- Use custom metrics for aggregate application outcomes and alert conditions.
- Use X-Ray annotations when traces must be filtered by a bounded safe business attribute.
- Use alarms and notification routing for conditions that require action.
- Use readiness checks to keep temporarily unready capacity out of service.
Security and governance implications
- Redact before emission; telemetry storage is not a safe place for plaintext secrets or full tokens.
- Keep trace annotations low-cardinality and non-sensitive because they are indexed.
- Scope alarm actions and notification topics to intended publishers and recipients.
- Protect health endpoints from revealing detailed internal or secret state.
Failure signals and diagnosis
- For missing logs, inspect application emission, runtime log configuration, permissions, and destination before adding duplicate logging.
- For missing metrics, validate the namespace, dimensions, value type, and EMF structure or emission call.
- For broken traces, inspect sampling, instrumentation, context propagation, and unsupported dependency boundaries.
- For false readiness, make the check reflect ability to serve and separate it from long-term health diagnostics.
More detail
- Instrumentation creates telemetry; dashboards and queries consume it.
- Effective logs balance diagnostic context with data minimization and consistent schema.
- Trace context must cross supported service and custom dependency boundaries for an end-to-end path.
- Readiness checks should test the minimum dependencies required to serve without becoming a fragile test of every external system.
Ready for the quiz?
- What can observability answer that a fixed dashboard cannot?
- Which fields make an application log useful and safe?
- When should a trace attribute be an annotation?
- What converts a measured threshold into a notification?
- Why can liveness succeed while readiness fails?
Related objectives
- D4.2 — Instrument code for observability
- 4.2.1 — Describe differences between logging, monitoring, and observability
- 4.2.2 — Implement an effective logging strategy to record application behavior and state
- 4.2.3 — Implement code that emits custom metrics
- 4.2.4 — Add annotations for tracing services
- 4.2.5 — Implement notification alerts for specific actions (for example, notifications about quota limits or deployment completions)
- 4.2.6 — Implement tracing by using AWS services and tools
- 4.2.7 — Implement structured logging for application events and user actions
- 4.2.8 — Configure application health checks and readiness probes