Zabbix + ICMP Ping Latency ( Делаем шаблон для отслеживания истории временных задержек при проверке доступности посредством ICMP. )
Задача: обеспечить техническую возможность отслеживать историю временных задержек при проверке доступности удалённого сетевого узла посредством ICMP.
Весьма часто при мониторинге географически разнесённой инфраструктуры важно знать, как сильно замедляется прохождение данных по узким или некачественным каналам (например, спутниковые терминалы где-нибудь в тундре или мелкие «бизнес-центры» в Санкт-Петербурге). На практике мало получать уведомления о сбоях — весьма полезно при этом иметь наглядный график, на котором отображается история показаний длительности ожидания получения ICMP-ответа. Сделать необходимые доработки легко, и они выразятся в прилагаемом шаблоне:
Пробежимся по процедуре подготовки и применения шаблона.
За основу возмём дистрибутивный шаблон «Template Module ICMP Ping», увеличим срок хранения данных дополним его графиком визуализации задержки ответа и потерь пактов.
Прежде всего поднимем предустановленный порог реакции на задержку ответа, учитывая реалии дальнего размещения объектов наблюдения:
Template -> Macros:
Template macros:
{$ICMP_RESPONSE_TIME_WARN} => 0.30
Увеличим время хранения данных мониторинга, чтобы иметь возможность просматривать историю изменения характеристик линии передачи данных:
Template -> Items:
ICMP loss, ICMP ping, ICMP response time:
History storage period: 90d
Trend storage period: 365d
Создадим график, отображающий две кривые, характеризующие отзывчивость линии передачи данных:
Template -> Graphs -> Create graph:
Name: ICMP latency
Graph type: Normal
Show legend: yes
Show working time: yes
Show triggers: yes
Y axis MIN value: Calculated
Y axis MAX value: Calculated
Items:
1: Template Module ICMP Ping Latency: ICMP loss
Y axis side: Left
Colour: Red
2: Template Module ICMP Ping Latency: ICMP response time
Y axis side: Right
Colour: Blue
При эксплуатации стоит учитывать, что встроенный шаблон «Template Module ICMP Ping», на основе которого мы создали наш «Template Module ICMP Ping Lantency» используется как связанный в шаблонах «Template Module Generic SNMPv1» и «Template Module Generic SNMPv2», а потому при попытке подключить наш новый шаблон для мониторинга устройств, которые уже отслеживаются посредством SNMP, случится конфликт дублирования ключей «icmpping», «icmppingloss» и «icmppingsec».
Проще всего заменить в шаблонах «Template Module Generic SNMPv1» и «Template Module Generic SNMPv2» привязку к «Template Module ICMP Ping» на наш новый «Template Module ICMP Ping Lantency»:
Template -> Linked templates:
Template Module ICMP Ping -> Unlink and clear
Template Module ICMP Ping Lantency -> Add
[ уже посетило: 2473 ] [ интересно! / нет ]
Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )
Заметки и комментарии к публикации:
Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )
5 Простые проверки
Простые проверки в основном используются для удаленных безагентных проверок сервисов.
Обратите внимание, что для простых проверок Zabbix агент не требуется. За обработку (созданием внешних подключений и т.д.) простых проверок отвечает Zabbix сервер/прокси.
Примеры использования простых проверок:
net.tcp.service[ftp,,155] net.tcp.service[http] net.tcp.service.perf[http,,8080] net.udp.service.perf[ntp]Поля Имя пользователя и пароль в конфигурации простых элементов данных используются для элементов данных мониторинга VMware; иначе игнорируются.
Поддерживаемые простые проверки
Список поддерживаемых простых проверок:
| Ключ | ||||
|---|---|---|---|---|
| ▲ | Описание | Возвращаемое значение | Параметры | Комментарии |
| icmpping[,,,,] | ||||
| Доступность хоста через пинг по ICMP. | 0 — ошибка при пинге по ICMP 1 — успешный пинг по ICMP |
цель — IP хоста или DNS имя пакеты — количество пакетов интервал — время между успешными пакетами в миллисекундах размер — размер пакета в байтах время ожидания — время ожидания в миллисекундах |
Пример: => icmpping[,4] → если по крайней мере один пакет из четырех вернется, элемент данных возвратит 1. | |
0.000000 — сервис недоступен
0.000000 — сервис недоступен
Обработка времени ожидания
Zabbix не будет обрабатывать простую проверку дольше Timeout (времени ожидания) секунд, заданных в файле конфигурации Zabbix сервера/прокси.
ICMP пинг
Для обработки ICMP пинг Zabbix использует внешнюю утилиту fping.
Эта утилита не является частью дистрибутива Zabbix и должна быть установлена дополнительно. Если утилиты нет, у нее выставлены неверные разрешения и её размещение не совпадает с размещением заданным в файле конфигурации Zabbix сервера/прокси (параметры ‘FpingLocation’), ICMP пинг (icmpping, icmppingloss, icmppingsec) не будет обрабатываться.
fping должен быть выполняемым под пользователем Zabbix демонов и должен иметь setuid root. Выполните эти команды из под root для выставления корректных разрешений:
shell> chown root:zabbix /usr/sbin/fping shell> chmod 4710 /usr/sbin/fpingПосле выполнения этих двух команд выше проверьте владельца исполняемого файла fping. В некоторых случаях владелец может сброситься при выполнении chmod команды.
Также проверьте, принадлежит ли пользователь zabbix к группе zabbix, запустив команду:
shell> groups zabbixи если нет добавьте следующей командой:
shell> usermod -a -G zabbix zabbixЗначения по умолчанию, ограничения и описания значений для параметров ICMP проверок:
| Параметр | Ед. изм | Описание | Флаг у fping | Значения по умолчанию у | Разрешенные ограничения в Zabbix |
||
|---|---|---|---|---|---|---|---|
Предупреждение: Значения по умолчанию для fping могут различаться в зависимости от платформы и версии — если сомневаетесь, проверьте документацию по fping.
Zabbix записывает проверяемые IP адреса во временный файл по всем трем icmpping* ключам, который затем передается утилите fping. Если элементы данных имеют различные параметры ключа, то только элементы данных с идентичными параметрами ключа записываются в один файл.
Все записанные в один файл IP адреса проверяются fping утилитой в параллельном режиме, таким образом процесс Zabbix icmp pinger тратит фиксированное время вне зависимости от количества IP адресов в файле.
Заметки админа
Столкнулся с интересной проблемой, до сути которой докопался как-то не сразу, хотя решение в итоге вышло простым. После настройки мониторинга резервных каналов связи на объектах Zabbix стал регулярно ругаться, что на этих элементах большие потери пакетов, хотя по факту их не было. Зато были задержки: по 900 и более мс. Попытавшись как-то потюнить сам Zabbix, начал копать глубже, в результате чего выяснилось, что простые проверки, реализованные в частности в дефолтном шаблоне системы Template ICMP Ping, опираются на fping с параметрами по-умолчанию, что описано в данной статье . То есть если ответ на ICMP запрос не получен в установленное время, пинг считается потерянным. В моем случае zabbix 3.0 и fping 3.8 значение таймаута по умолчанию составляет 500 мс, что явно меньше того, что требуется. Увеличить это можно в самих настройках шаблона, указав в элементе ICMP loss ключ icmppingloss[. 3000], где 3000 — искомый таймаут (тут каждому свой, я установил 3000 для компенсации роста зад
Поделиться
- Получить ссылку
- Электронная почта
- Другие приложения
Как разобраться с простой проверкой в Zabbix с агентом и без?
Есть веб сервер, на котором стоит Debian, крутится несколько сайтов и установлен агент Zabbix, сам сервер стоит в дата центре.
На сервере Zabbix, который стоит в офисе подключил шаблон ICMP Ping и понаблюдал сутки, выходит картина не очень красивая, в среднем 0,72% потерянных.
Прописал как узел сети один из сайтов, что крутиться на этом веб сервере и подключил шаблон ICMP Ping за час 0% ICMP loss, а если смотреть за тот же час по графику для веб сервера с агентом, то 0,56%
Как это понимать?
- Вопрос задан более трёх лет назад
- 1359 просмотров
Комментировать
Решения вопроса 1
Сетевой инженер, системный администратор
Совершенно не удивлюсь, если просто глючит агент. У меня была точно такая же ситуация с серверами. По факту выяснилось, что никто ничего не заметил и всё отлично работало. «Ок» подумал я и просто забил. Средние потери примерно такие-же и были. Плюс бывает вполне нормальная ситуация, когда пакет просто потерялся по дороге (перестройка глобальных маршрутов и пакет попал на недействующий узел). Да много всего может быть. Доступность 99,28% — это хорошая доступность. Даже очень. Пресловутые 99.99% почти никто не может даже в теории обеспечить, т.к. оч.дорого. Очень-Очень дорого.
Например, берем 2-3 датацентра, покупаем ID для BGP сети, настраиваем кластерную ФС между этими датацентрами, настраиваем BGP в сетях 2-5 провайдеров для каждого из дата-центров. Все это обходится нам в несколько миллионов, если не десятков миллионов рублей, но зато доступность будет примерно 99,98%. Потому что может оборудование глюкануть или словить перегруз, а переключение между нодами кластера хоть и занимает милисекунды, но все равно велики шансы потери некоторых пакетов. А может опять же тупануть на этапе перестройки глобальных маршрутов, а может тупануть DNS сервер клиента и вовремя не отрезолвить адрес, у клиента не откроется сайт, а он будет винить вас. Вариантов — 100500 штук.
У вас всё совершенно нормально с доступностью. Не обращайте даже внимание на подобные потери. В крайнем случае, попробуйте отследить момент провала и зайти на сервер в этот момент. Если не заходит, а потом сразу заходит, значит скорее всего вопрос в маршрутизации, который вы никак не решите. Да и вряд-ли вообще кто-то решит. Если долго не заходит (секунд 20-30-60), значит скорее всего проблема с сервером и пусть разбираются хостеры. Ещё могут быть у них проблемы с провайдером и т.д.
Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать
Ответы на вопрос 0
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Windows
- +3 ещё
Установка Zabbix Agent на большое количество машин Windows без домена?
- 1 подписчик
- 45 минут назад
- 10 просмотров