Мы используем icmp ping для определения состояния хоста из icinga2 в нашей среде AWS EC2. Это работает хорошо, но у нас было несколько проблем, из-за которых хост не пинговал, но его службы по-прежнему в порядке.
У моего коллеги сложилось впечатление, что Amazon иногда ограничивает трафик icmp, и это является причиной наших ложных предупреждений.
Итак, два вопроса:
Это правда? Амазонка иногда ограничивает icmp?
есть ли лучшая альтернатива icmp ping для использования нашей системой мониторинга для определения активности хоста?
Конечно, мы также отслеживаем сервисы, но хост вверх / вниз полезен для мониторинга в тех случаях, когда хост, а не сервис, вышел из строя.
Я не знаю ничего конкретного о реализации Amazon, поэтому мой ответ будет только об общем поведении.
Существуют RFC, которые рекомендуют регулирование пакетов ICMP, генерируемых узлом, но они не применяются к пересылке пакетов ICMP маршрутизаторами. Я не знаю какой-либо веской причины для того, чтобы маршрутизатор подавлял одни пересылаемые пакеты иначе, чем другие.
Отправка пакетов для разных номеров портов по разным каналам с целью балансировки нагрузки, однако, является функцией, имеющейся у многих аппаратных средств, и если такая функция используется, вполне возможно, что ваши ICMP-пакеты будут маршрутизироваться по другому физическому сетевому пути, чем пакеты к вашему сервисному порту. Это возможное объяснение различий.
Обратите внимание, что при правильно настроенной настройке вы должны ожидать, что эхо-запросы ICMP будут более надежными, чем ваша служба, но не менее надежными. И это само по себе является достаточной причиной, чтобы не использовать эхо-запросы ICMP для проверки работоспособности.
Причина того, что эхо-запросы ICMP более надежны, заключается в том, что у них меньше зависимостей. На эхо-запрос ICMP отвечает сетевой стек ядра, и поэтому вы можете иметь машину в очень плохом состоянии и по-прежнему быть способной отвечать на эхо-запросы ICMP.
Обычно существует два типа проверок высокого уровня, используемых для мониторинга службы, работающей на традиционном экземпляре или виртуальной машине: проверки уровня хоста и проверки уровня обслуживания.
Проверки на уровне хоста обычно выполняются с помощью стека мониторинга агента и / или вашего облачного провайдера и отслеживают такие метрики, как загрузка ЦП, загрузка ЦП, свободная память, свободное дисковое пространство и т. Д.
Проверки уровня обслуживания отслеживают саму службу, чаще всего через заранее определенную конечную точку проверки работоспособности, такую как /healthcheck. Вы должны настроить проверку службы для выполнения HTTP GET для этой конечной точки, и, если ответ 200 не предоставлен, выдать предупреждение о плохом состоянии.
Вот еще несколько основных примеров, которые следует учитывать при настройке проверки работоспособности:
В больших распределенных средах обычно собирают статистику в базы данных временных рядов, такие как Graphite или InfluxDB. Ваш сервер мониторинга регулярно проверяет определенные метрики в течение заданного периода на наличие аномалий.
Использование ICMP не является идеальной проверкой, поскольку это самая простая форма проверки на уровне хоста. Он не будет сообщать о состоянии самой службы и должен быть одним из ваших последних вариантов.
Обновить Я увидел, что этот ответ был отмечен как не отвечающий на исходный вопрос, что меня немного удивило. Я буду более прямым. Не используйте ICMP для отслеживания статистики на уровне хоста по причинам, о которых я упоминал выше.