The three pillars
METRICS
Aggregated numeric measurements over time — request count, error rate, p95 latency, memory usage, queue depth. Cheap to store, fast to query, great for alerts and dashboards. Lossy: you see the aggregate, not individual events.
LOGS
Timestamped text events. Maximum fidelity: every log line is a discrete record. Expensive to store at scale, slow to query without indexing, unstructured by default. Use for forensic analysis: "what happened to this specific request?"
TRACES
A trace follows a request through every service it touches, recording per-span timing. A request that fans out to 5 microservices produces one trace with 5+ spans. Critical for distributed systems, useful-but-less-so for a monolithic Laravel app.
Monitoring vs observability
Monitoring is a subset of observability. Monitoring asks questions you anticipated and wrote dashboards for. Observability is having enough data emitted that you can ask new questions without changing your code.
If a customer reports "your signup form was broken between 14:00 and 15:30 yesterday" and you can answer which users were affected, what request path they hit, and what exception fingerprint correlates — you're observable. If you can only say "we had an error spike at that time" — you're monitored but not observable.
What observability means for a Laravel team
You probably don't need a full OpenTelemetry pipeline with distributed tracing. You do need:
- Application-layer visibility: every request, exception, query, job, scheduled task recorded with enough context to reconstruct "what happened" (a Laravel APM)
- Log aggregation with search — Papertrail, Loki, CloudWatch Logs, Datadog Logs
- Infrastructure metrics — CPU, memory, disk, whichever your host gives you by default
- A way to correlate: trace IDs or request IDs shared across layers so you can pivot from a slow request to its logs
Where NightOwl fits
NightOwl covers the application pillar: every HTTP request, SQL query, exception, queued job, scheduled task, cache operation, outgoing HTTP call, and log line — captured and correlated by trace ID. Combine it with your existing infrastructure metrics and log aggregation for full-stack observability without the OpenTelemetry operational burden.