The benefits of monitoring critical urls of backends

Everything can be monitored on servers - memory and CPU loading, network and hard disk traffic, some services and the number of requests for these services.

But about a couple of months ago, at work, we began to monitor the response time of the urls of our backend servers. I will say right away that the response time during the day can wildly jump (sometimes even like a wild bull at a rodeo). Because the response time may depend on many factors, for example, whether the result of the request was already in the cache or re-read, from the network load at the time of monitoring monitoring, server load, etc. The reasons are different, but they are all normal and natural, until the time of delivery at peak time jumps above a certain threshold - there are no problems.

This schedule for the day in the normal backend mode looks like a comb (time in milliseconds, the higher the value, the worse): The



problems that can be noticed on the schedule are different (well, now I’ll tell you why it turned out to be useful to monitor the url return time). There were the following cases when monitoring noticed that:

• rolled out the update, and it began to work more slowly (the programmer screwed up somewhere);
• some regular bursts (for example, some other service starts to “sand up” this service at a certain time and pull pages from it, thereby discrediting other users, you need to carefully plan the time or frequency of requests from this third-party “scanner”);
• some external data source has fallen off, from which this service takes the result, and now its schedule already stands out abnormally among others (the problem is not ours, but you need to deal with an external source, inform its administrator about the problem);
• Periodic delays in issuing time of more than a second already indicate that somewhere something is not right, and you need to sit down to poke around with the service and find out exactly where the bottleneck was formed;
• the list goes on ...