Exercise 2: What Each Log Source Proved — Possible Solution
====================================================================

WHAT THE ACCESS LOG PROVED
------------------------------
Per this chapter (Step 2), the access log's %D field confirmed "the
slow requests are genuinely confirmed (not just a user's impression),"
and revealed the pattern that they "cluster into short windows,
roughly an hour apart, then return to normal" - proof that the
slowness was real, quantified, and intermittent rather than constant.

WHAT THE ERROR LOG PROVED
------------------------------
Per this chapter (Step 3), the error log's recurring slow-database-
query warning showed that "the application layer is confirming the
slowness lives somewhere around the database" - narrowing down WHERE
the slowness was occurring, without yet explaining why the database
itself was slow during those specific windows.

WHAT THE SYSTEM/JOURNAL LOG PROVED
------------------------------
Per this chapter (Step 4), journalctl revealed the cron job
(nightly_backup.sh) firing hourly instead of nightly, alongside a
matching CPU load spike - this is what finally explained WHY: an
misconfigured scheduled job driving up system load at the exact
moments the checkout page slowed down.

WHY ALL THREE WERE NEEDED TOGETHER
------------------------------
Per this chapter's own Step 5, "no single log source proved this on
its own - the access log proved THAT it was slow, the error log
hinted at WHERE, and the system log finally explained WHY." Each
source answered a genuinely different question (that/where/why); none
of the three alone would have produced the complete, actionable root
cause the correlated combination did.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly separates what each of the three log sources individually
established, and correctly explains, using this chapter's own
that/where/why framing, why the full diagnosis required combining all
three rather than stopping at any single one.