Допустимая задержка
Технически, обычная задержка исполнения индикатора может зависеть от нагрузки сервера, плюс время на передачу/обработку/запись информации (суммарно - несколько секунд).
В редких случаях, когда один из серверов okerr выводится из эксплуатации, некоторое время (период + patience + техническая задержка) требуется на то, чтобы другой из серверов okerr принял на себя отслеживание этого индикатора.
Кроме того, не упускайте из виду, что оповещения задерживаются в okerr на несколько секунд, чтобы отправлять одно оповещение о многих индикаторах. Это нужно в случае, когда случается много событий в короткое время (например, пропала связь с дата-центром и десятки индикаторов одновременно "покраснели", а через некоторое время связь восстановилась и они одновременно "позеленели").
Намеренная задержка отчета (Throttling)
Иногда может показаться, будто бы индикатор обновляется гораздо реже. Например, у индикатора с периодом в 1 секунду, мы можем в логе увидеть, что статус подтверждается раз в 5 минут.
27/11/2017 20:58:22 bravo@gravelanes.fr confirmed OK (35 days left) 27/11/2017 21:03:25 bravo@gravelanes.fr confirmed OK (35 days left) 27/11/2017 21:08:26 bravo@gravelanes.fr confirmed OK (35 days left) 27/11/2017 21:13:28 bravo@gravelanes.fr confirmed OK (35 days left) 27/11/2017 21:18:29 bravo@gravelanes.fr confirmed OK (35 days left)
Это обусловлено специальным "подтормаживанием" (throttling), который снижает нагрузку на центральные сервера, но при этом не понижает оперативность мониторинга.
Проверяющий сервер исполняет индикатор с периодом (по завершении исполнения, планируется новое исполнение через указанный период). Однако, для снижения нагрузки, обновление статуса отсылается только в двух случаях:
- Изменился статус индикатора (Например, OK -> ERR)
- Прошел период throttling'а с момента последнего обновления.
В этой ситуации даже индикатор с периодом в 1 секунду нагружает центральный сервером только 1 раз за период троттлинга (несколько минут). При этом, при возникновении проблем или ее исправлении, не происходит никакой задержки. Статус изменяется и оповещение отправляется незамедлительно.
Как убедиться, что индикатор на самом деле обрабатывается достаточно часто?
Можно самостоятельно убедиться, что индикатор на самом деле исполняется с запрошенной частотой.
Логи сервера
Если наблюдаемый сервис ведет логи (как, например, вебсервер), частоту проверок можно увидеть в лог-файлах:
78.47.38.118 - - [27/Nov/2017:23:29:26 +0100] "GET /asdf HTTP/1.1" 200 3559 "-" "okerr-netprocess/1.0" 78.47.38.118 - - [27/Nov/2017:23:29:28 +0100] "GET /asdf HTTP/1.1" 200 3559 "-" "okerr-netprocess/1.0" 78.47.38.118 - - [27/Nov/2017:23:29:30 +0100] "GET /asdf HTTP/1.1" 200 3559 "-" "okerr-netprocess/1.0" 78.47.38.118 - - [27/Nov/2017:23:29:32 +0100] "GET /asdf HTTP/1.1" 200 3559 "-" "okerr-netprocess/1.0" 78.47.38.118 - - [27/Nov/2017:23:29:34 +0100] "GET /asdf HTTP/1.1" 200 3559 "-" "okerr-netprocess/1.0" 78.47.38.118 - - [27/Nov/2017:23:29:36 +0100] "GET /asdf HTTP/1.1" 200 3559 "-" "okerr-netprocess/1.0" 78.47.38.118 - - [27/Nov/2017:23:29:38 +0100] "GET /asdf HTTP/1.1" 200 3559 "-" "okerr-netprocess/1.0"
Здесь мы видим, что на самом деле индикатор исполняется примерно один раз в 2 секунды. (примерно 1 секунду занимает исполнение индикатора и еще 1 секунда - период)
Анализ трафика (tcpdump)
Если нет логов, можно прослушать трафик на наблюдаемом сервере, чтобы заметить, как часто выполняется проверка.
23:38:43.645713 IP 37.59.102.26 > 78.47.38.118: ICMP echo request, id 24742, seq 0, length 249 23:38:43.645752 IP 78.47.38.118 > 37.59.102.26: ICMP echo reply, id 24742, seq 0, length 249 23:38:44.647364 IP 37.59.102.26 > 78.47.38.118: ICMP echo request, id 24742, seq 1, length 249 23:38:44.647392 IP 78.47.38.118 > 37.59.102.26: ICMP echo reply, id 24742, seq 1, length 249 23:38:45.648722 IP 37.59.102.26 > 78.47.38.118: ICMP echo request, id 24742, seq 2, length 249 23:38:45.648737 IP 78.47.38.118 > 37.59.102.26: ICMP echo reply, id 24742, seq 2, length 249 23:38:47.653453 IP 37.59.102.26 > 78.47.38.118: ICMP echo request, id 24743, seq 0, length 249 23:38:47.653493 IP 78.47.38.118 > 37.59.102.26: ICMP echo reply, id 24743, seq 0, length 249 23:38:48.655008 IP 37.59.102.26 > 78.47.38.118: ICMP echo request, id 24743, seq 1, length 249 23:38:48.655040 IP 78.47.38.118 > 37.59.102.26: ICMP echo reply, id 24743, seq 1, length 249 23:38:49.655536 IP 37.59.102.26 > 78.47.38.118: ICMP echo request, id 24743, seq 2, length 249 23:38:49.655561 IP 78.47.38.118 > 37.59.102.26: ICMP echo reply, id 24743, seq 2, length 249
Аналогично примеру выше, мы видим 3 пинга с интервалом в 1 секунду, затем 1 секунда ожидания (период) и снова повторение.
Провокация ошибки
Еще одним из способов проверки является провокация ошибки. Например, можно ненадолго "положить" собственный веб-сайт, или изменить отслеживаемое содержание странички, чтобы посмотреть время, когда okerr зарегистрирует ошибку. В логе индикатора вы увидите, что проблема зарегистрирована сразу после неудачной проверки, раньше обычного времени обновления через throttling.