Exercise 1: Rewriting a Rate-Limit Log Line as Structured JSON — Possible Solution
====================================================================

{"timestamp": "2026-07-13T09:15:44Z", "level": "warn", "msg": "rate limit exceeded", "ip": "203.0.113.7", "endpoint": "/api/checkout"}

-- What becomes easier once it's structured --
--
-- In the original unstructured line, finding "every rate-limit
-- warning for IP 203.0.113.7" or "every rate-limit warning on
-- /api/checkout specifically" requires writing a regex pattern
-- against the free-text message and hoping the log format never
-- changes wording -- fragile exactly as the chapter describes. Once
-- structured, ip and endpoint are real, independently queryable
-- fields -- a query can filter directly on ip = "203.0.113.7" or
-- endpoint = "/api/checkout" (or both together) without any text
-- parsing at all, and this keeps working even if the human-readable
-- msg field's wording changes later, since the query never depended
-- on that wording in the first place. It also becomes trivial to,
-- for example, count how many distinct endpoints a given IP has hit
-- rate limits on, or how many distinct IPs have hit the limit on one
-- endpoint -- aggregation questions that would have required
-- painstaking regex extraction across every matching line in the
-- unstructured version.

WHY THIS WORKS AS AN ANSWER
------------------------------
This converts the log line into valid structured JSON with clearly
separated fields (ip, endpoint) rather than leaving them embedded in
a free-text msg string, then explains the querying benefit with a
concrete example rather than a generic "it's easier to search"
claim.