Black-box vs white-box monitoring
Black box asks whether the system works from outside; white box reads its internal metrics and logs to explain what is happening.
See it
What it is
Black-box monitoring treats the system as a user would: send a request from outside and check the response without knowing what is inside. White-box monitoring reads the internals the system exposes, such as request rate, error counters, queue depth, memory, logs, and traces. The Google SRE book uses this distinction: black-box checks reveal visible symptoms, while white-box signals help explain their causes.
Use both. An external HTTPS probe can catch broken DNS, an expired certificate, or a dead load balancer that perfect server metrics never see. Internal Prometheus metrics can warn that a connection pool is nearly full before the outside check fails, then show why it failed once it does. Page on the user-visible black-box symptom and use the white-box detail for diagnosis and earlier, lower-urgency warnings.
Gotcha: either view can lie by omission. A green check against /healthz does not prove checkout works, and a red CPU chart does not prove users are suffering. Probe a small set of real critical journeys, keep the probe outside the infrastructure it watches, and make internal signals specific enough to lead a responder toward an action.
Ask AI for it
Add black-box and white-box monitoring to this service. Configure Prometheus Blackbox Exporter to probe the public HTTPS endpoint from outside the service, checking DNS, TLS, status 200, latency, and a response-body marker that proves the page rendered correctly. Expose white-box RED metrics from the app for request rate, error rate, and duration, plus queue depth and database pool saturation. Build one Grafana dashboard that pairs each external symptom with the internal signals most likely to explain it, and page on sustained probe failure while routing approaching saturation to a warning channel.