PHP From ZeroModern PHP course

deployment and operations

Observability: Logs, Metrics, And Traces

Observability combines logs, metrics, and traces to understand production behaviour. Each signal answers different questions and should share useful identifiers.

Use Each Signal For Its Strength

  • Use logs for detailed events.
  • Use metrics for rates, latency, saturation, and errors.
  • Use traces for request flow across boundaries.

Instrument One Journey

  • Instrument one request path.
  • Verify correlation IDs.
  • Create one actionable alert.

Keep Signals Actionable

  • Collecting data without ownership creates noise.
  • High-cardinality labels increase cost.
  • Sensitive data must be redacted.

Signal Map

logs    -> what happened in one event?
metrics -> is error rate, latency, or saturation changing?
traces  -> where did time go across request boundaries?

Observability is useful when a team can detect and investigate one real failure path. Collecting more data is not automatically better: high-cardinality labels, sensitive fields, and alerts without owners create cost and noise.

Practice

Practice: Instrument A Checkout Path

Describe the logs, metrics, and trace spans needed to investigate a slow checkout request without recording sensitive payment data.

Requirements

  • Use logs for detailed events.
  • Use metrics for rates, latency, saturation, and errors.
  • Use traces for request flow across boundaries.
  • Instrument one request path.
  • Verify correlation IDs.
  • Create one actionable alert.
Show solution

Carry a correlation ID through checkout logs and trace spans. Record request rate, error rate, and latency distributions as metrics. Add spans around database work and the payment-provider call so slow time has a visible owner.

Exclude secrets and payment details. In staging, trigger one controlled slow or failed path, trace it end to end, and create an alert with an explicit owner and useful threshold.