Trace Application Requests to Database Logs

1. Emit useful, safe application events

For each database operation, capture a trace/request ID, timestamp in a consistent format, service/version, environment, operation name, target alias, outcome, and elapsed duration. Separate connection-pool wait, connection establishment, database execution, retry, and response serialization when possible.

{
  "timestamp": "2026-10-04T12:00:00.000Z",
  "level": "ERROR",
  "service": "orders-api",
  "version": "2026.10.04.1",
  "trace_id": "approved-example-id",
  "db_target": "orders-primary",
  "operation": "load_order",
  "pool_wait_ms": 5,
  "db_duration_ms": 1204,
  "error_code": "statement_timeout"
}

Use an approved ID format and avoid logging credentials, full SQL parameters, payment data, or unredacted personal data. Keep structured fields stable so Insights can query them.

2. Search by a trace identifier

Select both application and database log groups in Logs Insights if access and cross-service search are configured. Replace the example identifier with the approved incident trace ID.

fields @timestamp, @log, @logStream, @message
| filter @message like /approved-example-id/
| sort @timestamp asc
| limit 100

If the database engine log cannot emit the application trace ID, correlate by time range, database PID/session identifier when safely present, database/user, and a sanitized operation label. Do not assume two adjacent timestamps are the same request.

3. Interpret the timing boundaries

• High pool-wait duration with low SQL time: inspect pool size, connection leaks, and database connection headroom.
• Low pool wait with high database time: inspect SQL duration logs, active sessions, waits, and query plans.
• Low database time with high endpoint time: inspect retries, downstream services, application CPU, and result processing.
• High connection establishment time: inspect network path, DNS, TLS, connection churn, and failover events.

Developer and DBA hand-off

Include trace ID, exact UTC time range, service/version, database target, sanitized error, pool wait, SQL duration, database wait state, and the relevant log links in the issue. The developer confirms request and retry behavior; the DBA confirms engine, contention, and resource behavior. Agree one testable hypothesis before changing production.