19 Aug 2026 · 1 min read
Magento 2 observability: logs, metrics, and traces that catch fires early
How to see a Magento 2 store like an operator — centralize logs, track slow queries and cache hit rate, and trace requests so the audit checklist has real signals.
The audit checklist tells you what to check; observability tells you when it breaks. This post turns the checklist into signals you can watch.
Logs you must centralize
system.log, exception.log, cron.log, and the web server access log. Ship them to one place so a spike in exceptions is visible before customers complain. Don't let them rot on a single node.
Metrics that matter
- TTFB and request rate (edge + app).
- Cache hit rate — Varnish and FPC; a dropping hit rate is the earliest perf signal.
- Slow query count — the database section of the audit, measured continuously.
- Queue depth — if the message queue backs up, cron-driven work stalls.
Tracing requests
A profiler trace (from the debugging post) is a one-off; distributed tracing is continuous. Tag requests by store/route so a regression shows up as a latency bump on one path, not a global outage.
Alert on the audit's Critical/High
Map the checklist's ranking to alerts: security events and downtime are Critical; cache-hit drops and slow-query spikes are High. That's what makes the audit actionable in real time, not just quarterly.
Run it on a real stack
Observability only reflects reality if the local stack matches production. Bring up the matching Nginx/PHP/MariaDB/Redis/Varnish/OpenSearch topology with Govard so the signals you tune locally are the ones you'll see live.
This is the final post in the Magento 2 observability & operations series.