“The app feels slow” is the start of an investigation.
A customer reports that checkout takes too long. You need to know when it started, how many users are affected and which part of the request changed. Infrastructure readings and application observations provide evidence from different angles.
Monitoring watches selected conditions. Observability helps you explore behavior using the signals the system emits. Useful instrumentation connects to real questions: whether requests succeed, how long they take, what resources are constrained and where a failure occurs. A wall of charts is not automatically an explanation.
Look at the same incident through three lenses.
Metrics capture measurements that can be summarized over time. Logs record events and their context. Traces represent the path of work through related operations, helping connect portions of a request across services. Each signal is useful because it answers a different kind of question.
Explore the same fictional slow checkout below. The metric shows a latency rise, the log records a timeout event, and the trace highlights time spent in a database call. None alone proves the root cause. Together they suggest where to investigate next.
Reference: OpenTelemetry: signalsStart with what users need to work.
For the shop, successful checkout matters more directly than whether every CPU reading is low. Track the experience at a useful boundary: success rates, request latency and availability of important paths. Resource metrics then help explain why that experience may be changing.
Compare the same time window across signals. Look at traffic volume alongside error counts, and distributions rather than only averages when latency varies. Mark releases and configuration changes on the timeline so a new symptom can be compared with recent operating events.
| Signal | Helps answer | Example |
|---|---|---|
| Metric | How much, how often, how long? | Request latency over a time window |
| Log | What event was recorded? | A checkout request timed out |
| Trace | Where did this request spend time? | API → database operation |
| Alert | What needs attention now? | Sustained checkout failures |
Make an alert lead to a useful action.
Alerting works best when it is tied to meaningful symptoms and an expected response. Constant notifications for conditions that need no intervention make urgent events harder to notice. An alert should identify the affected service, the condition and where to begin investigating.
For the shop’s checkout, define who receives the alert and what they can do. Link a short runbook and a relevant dashboard. Consider duration and context so a brief harmless fluctuation is not treated like a sustained customer-facing failure. Review noisy alerts after incidents.
Reference: Prometheus: alerting practicesKeep the evidence useful and appropriate.
Logs and traces can accidentally collect personal data or credentials. Decide what context is necessary, remove sensitive fields and control access to the results. Retention and collection volume are operating choices too, especially as traffic grows.
Give each signal a consistent service and environment identity. The person investigating should be able to distinguish production from a preview project and connect an observation to a release. Start with a few reliable questions and improve coverage as the application’s failure modes become clearer.
Common questions.
Do I need metrics, logs and traces on day one?
Start with the signals needed to operate your application confidently. Add instrumentation where it answers a real diagnostic question.
Does high CPU always mean the app is unhealthy?
No. Interpret it alongside capacity, latency, error rates and workload behavior. Useful work can consume CPU without causing a problem.
Can a trace prove the database is the cause?
It can show time spent in a database operation, but the underlying reason still needs investigation. Treat it as evidence, not an automatic diagnosis.
Connect the concept to your work.
DOCKOCK brings infrastructure and workload observations into the same workspace, connecting operational signals with the services and servers you manage.
Explore monitoring in DOCKOCKKeep learning from the source.
Further reading from the teams and documentation behind these technologies.
OpenTelemetry: signalsPrometheus: alerting practices