Capstone — Triaging Three Real Support Tickets

Logging & Log Analysis

Chapter 10 · Capstone — Triaging Three Real Support Tickets

Nine chapters built the pieces — levels, locations, formats, correlation, layered diagnosis, aggregation, writing your own. This capstone applies all of it to three fresh tickets, worked more briskly than Chapters 6 and 7's own dedicated walkthroughs, since the underlying discipline should already feel familiar by now.

Ticket 1: "I can't log into the admin panel"

An internal support-team member reports being unable to log into the admin panel since this morning, insisting their password is correct.

Applying Chapter 5's layered model

Layer 1 (network): their requests appear in the access log — ruled out
Layer 2 (blocked before the app): fail2ban-client status shows their IP was never banned — ruled out
Layer 3 (application auth): the app's own log shows the real cause — [WARN] Login rejected: account status = inactive (user_id 118)

An overnight account-cleanup job (visible in the same log, timestamped just before midnight) incorrectly flagged this active admin account as inactive during a routine sweep — not a password issue at all. Reactivating the account, and confirming a subsequent login succeeds in the log, closes the ticket.

Ticket 2: "The reporting dashboard is really slow"

Export generation on the reporting dashboard has been taking 20+ seconds since yesterday afternoon.

Applying Chapters 4 and 6's technique

Access log: %D confirms export requests genuinely spiked from ~1s to 20s+, starting right after yesterday's 2pm deployment
Error log: hundreds of individual database query log lines per single export request — a strong signal, not just one slow query
Correlation: yesterday's deployment notes show a code change to the export feature — comparing the before/after query counts confirms the new code queries the database once per row instead of once for the whole export

An N+1 query pattern, introduced by yesterday's own deployment — a code-level cause this time, not an infrastructure one, but found the same way: access log confirms the symptom, error log narrows down where, correlating with a recent change explains why.

Ticket 3: "EU customers are seeing US content"

Customers configured for the EU region occasionally see US-region homepage content instead.

Applying Chapter 7's elimination method — with a different result this time

Checking response headers, exactly as Chapter 7 did:

curl -I https://example.com/ -H "X-Region: EU"
HTTP/1.1 200 OK
X-Cache: HIT

Unlike Chapter 7's own ticket, this time caching genuinely is involved — a CDN edge cache was added in front of this page last month for performance, but its own configuration never included the region header in its cache key. The first request to a given edge location gets cached, and every subsequent request to that same edge — regardless of region — receives the cached response. The fix is a caching-config change (varying the cache key on region), not a code change at all.

The same check, two honestly different outcomes

Chapter 7 ruled caching out by checking headers. This ticket confirms caching is the cause, using the exact same check. Neither result was assumed in advance — the discipline is checking, not guessing which answer is more likely to be right.

Chapter Attribution

Technique used above	Source chapter
Log-first triage, silent failures	Chapter 1
Reading severity levels (WARN in Ticket 1)	Chapter 2
Knowing where fail2ban and application logs live	Chapter 3
`%D` response-time field, access/error log correlation	Chapter 4
The four-layer login diagnostic model	Chapter 5
Correlating access log, error log, and a deployment record	Chapter 6
Checking cache headers rather than assuming either way	Chapter 7
(Not directly used this chapter, but the same skills scale to it)	Chapter 8
(Fixing Ticket 1 relies on the app's own logging conventions from)	Chapter 9

Honest Scope Note

What this course deliberately doesn't cover

No deep dive into commercial log-management platforms (Splunk, Datadog, and similar) — Chapter 8 covers the underlying concepts they're built on, not any specific vendor's own product
No log-based alerting or monitoring setup — this course is about reading and writing logs, not building the systems that watch them automatically
No SIEM/security-specific log analysis in depth — a genuinely separate discipline worth its own course
No custom log-parsing tooling (regex extraction pipelines, structured logging libraries in specific languages) beyond what's needed to read a log by eye

Each is a legitimate, separate topic — not silently assumed solved by what this course actually covers.

Hands-On Exercises

Exercise 1

Explain why Ticket 1 turned out not to be a password problem at all, and which specific layer of Chapter 5's model actually contained the real cause.

📄 View solution

Exercise 2

Explain what an "N+1 query pattern" means based on Ticket 2's own description, and why comparing the timing to yesterday's deployment was the key step in finding it.

📄 View solution

Exercise 3

Explain why this chapter says Ticket 3 and Chapter 7's own ticket used "the exact same check" despite reaching opposite conclusions about caching, and why that isn't a contradiction.

📄 View solution

Chapter 10 Quick Reference — Course Complete

Ticket 1: an apparent password problem was actually an application-level account status flag — Chapter 5's layered model found it directly
Ticket 2: a code-level N+1 query pattern, found by correlating access-log timing with a recent deployment — the same method as Chapter 6, a different kind of cause
Ticket 3: caching genuinely was the cause this time — the same header check from Chapter 7, an honestly different result
The recurring theme across all ten chapters: check, don't guess — whichever specific technique that means in the moment
This closes Logging & Log Analysis, 10/10 chapters — the first course under the new Technical Support subject