Distributed monitoring and geographic accessibility

Most of us regularly face the issue of technical availability of sites that we visit daily. Although it seems that reliable access channels and high speed of communication have already solved this problem a long time ago, but the emergence of mobile devices, cloud infrastructure, the spread of the Internet to the regions still makes us wonder: why doesn’t this website open for me (or for my users) or it works incorrectly? And how does my site open (and generally look) for my users?

How to answer these questions?

Technical availability of the website

I'll start a little from afar. Being only in one point of the Network (using one connection to the Internet) we cannot reliably say whether the website we are accessing is working if it does not open with us. There can be many problems here, for example:

• Unavailability (low data exchange rate) of our network segment and the “main network”. This is clearly seen when you go to a site from a mobile in the subway: you can only wait for the discovery in the zone of reliable signal reception, if the signal is weak, then the site is unavailable.
• A more dangerous modification of the previous problem is when the proxy server settings (protection against DDoS, cloud, network infrastructure) change the initial requests from users, which leads to incorrect functioning of the site. The most innocent example: for half of the users, the site opens with www without a redirect, for the rest - with a redirect.
• Low speed of the site (or communication channel to which the server is connected). In this case, for a number of users (who, again, have a slow channel or an unstable connection to the Network), the site will open for a very long time or not at all. In this case, the problems of accessibility of users are imposed on the real problems of site accessibility.
• A new enough (for Runet) problem, when due to the large number of objects / page size on a slow or unstable connection (read mobile or public WiFi), the user simply does not have time to wait for the pages to load / display in the browser.

Behind the scenes, there are still questions of the functional accessibility of the site: when, in general, the site works, but for some reasons (essential) functionality of the site does not work for a number of users. For example, check Captcha when registering new customers.
')

Find Accessibility Issues

Unfortunately, the site development or support team (in the office) can independently track only a small part of the problems described, namely: measure the server response time to key requests and optimize this indicator; eliminate server site errors; diagnose the total opening time of the site pages and eliminate key problems of client accessibility.

But to track the problems of technical accessibility associated with the connectivity and speed of the Network externally, the internal team itself will not be able to. No, you can, of course, ask each employee to check the site from home, but this is not always realistic and there can be no normal solution.

Distributed network connectivity

And again I will leave a little away from the topic. If we have users from different parts of the city / regions of Russia or the world, it is clear to say whether our site is accessible to them or not, we cannot (only if we are not physically sitting next to them). To check the problems of geographic accessibility, we need a network of points (servers), which themselves will be available (they will see each other) - a connected network. Only in this case, by setting the verification point “close” to our users and making sure that the point itself does not have technical availability problems (it sees other points and has sufficient connection speed to the Network), we can say with firmness: “Yes, the site for specified users is available "or" No, the site is not available for these users. "

Example: we have a bank audience from Moscow, St. Petersburg, Yekaterinburg and Kazan. It is clear to say that the site of the bank is accessible to our audience (and the site does not have any problems for the indicated audience) we can only by checking the site from the specified cities. And the check points themselves must always be “on the Web”, otherwise we will not be able to rely on their data: if the channel between Moscow and Kazan “falls”, then all external resources will become inaccessible for Kazan citizens. And the information that our website will become inaccessible to them will not be valuable: there are problems with accessibility, but we cannot solve them, and the problems are global in nature.

But if sometimes, when everything is good with the communication channel, our site becomes inaccessible for Kazan citizens - this is an occasion to think and start looking for a problem in order to improve the quality of the services provided.

Distributed monitoring

Returning to the stated issues. To find out how the site opens or looks for my (distributed, mobile, regional) users, you must use a network of distributed monitoring points that will be as close as possible to the target audience. If for different regions of Russia the situation is more or less clear: we simply check the availability of the site from the necessary cities, but for mobile users it is interesting to check the coverage (speed) of the network from different points around the city - and be happy to find accessibility problems - although this is only relevant for mobile operators network and 3/4 / 5G.

In this case, in the case of a regional availability check, it is important to ensure that the checkpoints themselves are accessible, that the connectivity is not broken in the checkpoint network itself.

Monitoring services

There are only a few services in RuNet that offer site checking from several cities of Russia (i.e., it is distributed geographic monitoring):

• Host Tracker , 4 points in Russia (Moscow - 2, St. Petersburg - 2), availability check.
• Ping Admin , 20 points in Russia (Moscow - 7, St. Petersburg - 2, Nizhny Novgorod, Vladivostok, Novosibirsk, etc.), availability check (several algorithms)
• WEBO Pulsar , 11 points in Russia (Moscow - 4, St. Petersburg - 2, Yekaterinburg, Novosibirsk, Khabarovsk, Samara, Krasnodar, test them at all points ), checking availability, speed, page opening time (several algorithms).