Monitoring Infrastructure

Monitoring turns the behavior of a running service into evidence that operators can inspect. Google’s site reliability engineering guidance distinguishes internal observation, called white-box monitoring, from black-box tests that examine externally visible behavior. A database connection count describes something inside a system; a request made through its public interface asks whether a user-facing operation succeeds. These perspectives answer different questions and are most useful together. s1

The same guidance identifies latency, traffic, errors, and saturation as central signals. Latency measures response time; traffic describes demand; errors identify unsuccessful operations; saturation indicates how close a resource is to its limits. Successful and failed requests should be distinguished when interpreting response times: a fast failure can otherwise make an unhealthy service appear responsive. Alerting then requires judgment about which symptoms warrant immediate human attention. s1

Prometheus provides a concrete example of a metrics architecture. It collects numerical measurements as time series, associating samples with timestamps and labels. Labels distinguish dimensions such as a service or instance, while its query language, PromQL, supports analysis across those dimensions. Collection normally uses HTTP requests to monitored targets, which can be identified through configuration or service discovery. s2

Collection, evaluation, and presentation are separate functions. Prometheus stores collected samples and evaluates rules that can produce additional series or alerts; visualization tools can query the results. This separation helps explain why a dashboard is only one part of monitoring infrastructure. Behind it must be a defined measurement, a working collection path, storage, and an interpretation of what the result means. s2

Iran provides a documented example of why reachability cannot be inferred from server health alone. A multistakeholder technical report examined network measurements collected during the autumn 2022 protests. It documented mobile network outages, regional disruptions, and interference affecting particular services and protocols. Its findings concern the networks and periods studied, rather than a permanent description of every connection in Iran. s3

An editorial implication is that an investigation should record where a test ran, which destination it contacted, and when it ran. An internal probe and a user-side probe can produce different results without either being incorrect. A missing remote measurement also needs interpretation: it may reflect the collection path rather than the monitored application. The historical report supports this distinction; it does not establish the availability of any monitoring vendor at the editorial cutoff. s3

A metrics-based monitoring path

The arrows distinguish collection requests, storage, rule evaluation, and presentation. This is a general Prometheus-based architecture, not a verified deployment in Iran.