Exercise 2: Automatic trace_id vs. Manual request_id — Possible Solution
====================================================================

Explanation:

-- The underlying question both answer --
--
-- Both fields exist to solve exactly the same problem: "given one log
-- line, how do I find every other piece of telemetry -- other log
-- lines, other spans -- that belongs to this same request, across
-- every service it touched." obs1-7's request_id and obs1-9's
-- trace_id are both, functionally, a shared identifier threading
-- through a distributed request.

-- How they differ --
--
-- obs1-7's request_id had to be deliberately designed and manually
-- engineered by the application team: someone had to decide to
-- generate the ID at the edge, decide which header to propagate it
-- in, and write code in every single service to read that header and
-- include the value in every log line it emits. Getting this right
-- required real, ongoing engineering discipline -- and, per obs1-7's
-- own warn-box, was exactly the kind of thing that silently breaks if
-- one service is forgotten.
--
-- trace_id enrichment under OpenTelemetry, by contrast, is automatic:
-- because the log statement and the active span both go through the
-- same OTel SDK, the SDK itself can attach the current span's trace
-- ID to a log line without the application developer writing any
-- correlation logic at all -- it falls out of using the SDK
-- consistently, rather than requiring a bespoke propagation mechanism
-- someone has to build and maintain by hand.

WHY THIS WORKS AS AN ANSWER
------------------------------
This first identifies the shared underlying goal both fields serve,
then explains the real mechanical difference (manually engineered
per-team logic vs. an SDK-level automatic behavior) rather than just
saying "one is automatic and one isn't" without explaining why.