Exercise 2: What $upstream_addr Revealed — Possible Solution
====================================================================

WHAT IT REVEALED
------------------------------
Per this chapter (Step 4), $upstream_addr showed "requests alternate
between two backend servers, and only one of them is actually serving
new prices" - specifically, one request was handled by backend-1
(10.0.0.11, showing the old price) and another by backend-2 (10.0.0.12,
showing the new price). This directly exposed that the price update
deployment had reached backend-2 but never completed on backend-1 -
the actual root cause of the ticket.

WHY THIS REQUIRED A SPECIFIC LOG CONFIGURATION CHOICE
------------------------------
Per this chapter, this information came from "an Nginx log format that
includes $upstream_addr, the actual backend server that handled each
request" - implying this field is not part of Nginx's own default
access log format and had to be deliberately added to the log_format
configuration in order to appear in the logs at all.

WHY THIS ECHOES A THEME FROM EARLIER IN THE COURSE
------------------------------
Per Chapter 4's own material on response-time logging, some genuinely
useful diagnostic fields (there, %D/$request_time; here, $upstream_addr)
are not present in a server's default log configuration and must be
explicitly configured before they can ever be used to diagnose a
problem - the same underlying lesson applied to a second, different
field.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains what $upstream_addr showed (which backend served
each request, exposing the partial deployment), and correctly
identifies that this field required deliberate log configuration
rather than being available by default.