Вы можете отслеживать все на серверах — загрузку памяти и процессора, сетевой трафик и трафик жестких дисков, некоторые сервисы и количество запросов к этим сервисам.
Но где-то пару месяцев назад на работе мы начали следить за временем ответа URL-адресов наших бэкэнд-серверов.
Скажу сразу, время отклика в течение дня может дико скакать (иногда даже как дикий бык на родео).
Потому что время ответа может зависеть от многих факторов, например, от того, был ли результат запроса уже в кеше или был прочитан повторно, от загрузки сети в момент опроса мониторинга, от загрузки сервера и т.д. Причины такие: разные, но все они нормальные и естественные, пока время выдачи в часы пик не скачет выше определенного порога, проблем нет.
Этот график за день в обычном режиме работы бэкенда выглядит как гребенка (время в миллисекундах, чем выше значение, тем хуже): 
Проблемы, которые можно заметить по графику, разные (ну а теперь расскажу, почему мониторинг времени возврата URL оказался полезным).
Были следующие случаи, когда мониторинг заметил, что:
- выкатили обновление, но оно стало работать медленнее (программист где-то накосячил);
- какие-то естественные всплески (например, какой-то другой сервис начинает в определенное время «песать» этот сервис и выдергивать из него страницы, дискредитируя тем самым других пользователей, нужно более тщательно планировать время или частоту запросов от этого стороннего» сканер»);
- отвалился какой-то внешний источник данных, из которого этот сервис берет результат, и теперь его график уже ненормально выделяется среди других (проблема не наша, но нам нужно разобраться с внешним источником, сообщить о проблеме его администратору);
- периодические задержки доставки более секунды уже говорят о том, что где-то что-то не так, и нужно сесть повозиться с сервисом и выяснить, где именно образовалось узкое место;
- список можно продолжить.
-
Сайт Rubix- Новая Революция
19 Oct, 24 -
Новый Поиск По Сайту От Google
19 Oct, 24
