A parks department app polls Meraki for AP inventory and then parses the JSON locally. Operators need to know whether Meraki is slow or the parser is. Which observability design best answers that question?
Select an answer to reveal the explanation.
Short Explanation
Think of two stopwatches: one for the courier trip to Meraki and one for unpacking the box locally. Rate, errors, and duration on each hop tell you whether the platform or your code is the problem. Host CPU alone cannot make that call.
Full Explanation
Golden-signal observability answers whether Meraki is slow or the local parser is slow by instrumenting rate, errors, and duration separately for the outbound Meraki client hop and for the local parse stage. Rate shows how many inventory polls leave the parks app; errors show client timeouts, HTTP failures, or parse exceptions; duration shows how long each hop takes. With those series split, an operator can see Meraki round-trip latency climbing while parse duration stays flat—or the reverse—without conflating platform delay with local CPU-bound decoding. That separation is the design goal for this civic inventory poller.
Monitoring only host CPU on the app server fails conceptually because a CPU spike does not prove Meraki downtime; it might be garbage collection, another job, or a busy parser, and Meraki can be slow while CPU is idle waiting on the network. A single aggregate latency that mixes Meraki round-trips with parse time erases the hop boundary the operators need, so every slowdown looks the same. Instrumenting AppDynamics or similar APM business transactions only for the UI while skipping API client metrics leaves the Meraki hop invisible even though that hop is exactly where inventory freshness is decided.
Exam caveat: golden signals still need correct labels and bounded cardinality—do not explode series with per-AP labels if you only need hop health. Operational check: force a Meraki client timeout in a non-production poll and confirm the Meraki-client error and duration series move while the parser series stay quiet; then feed a large valid body and confirm parse duration rises independently.