В
вычислительных сетях с большим количеством устройств (например, сеть
банкоматов или сетевых устройств) часто требуется мониторинг доступности
узлов с возможностью сбора и графического отображения статистической
информации по задержкам и потерям пакетов в канале до данных узлов.
Иногда список устройств для которого требуется мониторинг доступности
бывает динамическим, то есть может периодически меняться как сам список
устройств, так и их ИП-адреса или названия.
В данной статье мы решили описать решение этой задачи при помощи системы мониторинга Zabbix.
В Zabbix-е начиная с версии 2.0 доступна новая функция: низкоуровневое обнаружение.
Низкоуровневое
обнаружение предоставляет возможность автоматического создания
элементов данных, триггеров и графиков для разных ресурсов на
компьютере. Так, в дистрибутив включена возможность автоматического
обнаружения сетевых интерфейсов и дисков на сервере. Рассмотрим, как ещё
можно применять данную возможность.
Есть
задача осуществлять мониторинг доступности серверов - порядка 200-300
единиц. Допустим, что требуется раз в 2 минуты с серверов клиента
проверять их доступность по сети, время отклика и потери пакетов. По
всем параметрам должна собираться и графически отображаться статистика.
При этом список серверов обновляется динамически в текстовом файле
выглядящем следующим образом::
имя_сервера1 192.168.1.11
имя_сервера2 192.168.2.22
и т.д.
Для решения этой задачи удобно использовать низкоуровневое обнаружение.
Создаем
скрипт, который будет запрашиваться с сервера, где работает система
мониторинга Zabbix. Его результатом будет текст в формате json, который
требуется для низкоуровневого обнаружения:
#!/usr/bin/perl
$latest_file=`ip.servers.lst`; # Текстовый файл с динамическим списком узлов
print "{\n";
print "\t\"data\":[\n\n";
for (`cat $latest_file`)
{
($clname, $clip) = m/\S_(\S+) (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/; # $clname - имя сервера, $clip - его IP-адрес
print "\t{\n";
print "\t\t\"{#CLNAME}\":\"$clname\",\n";
print "\t\t\"{#CLIP}\":\"$clip\"\n";
print "\t},\n";
}
print "\t]\n";
print "}\n";
Вывод этого скрипта будет примерно таким:
{
"data":[
{
"{#CLNAME}":"server_name1",
"{#CLIP}":"192.168.1.11"
},
{
"{#CLNAME}":"server_name2",
"{#CLIP}":"192.168.2.22"
},
]
}
Добавляем скрипт в конфигурацию агента Zabbix zabbix_agentd.conf в разделе UserParameter:
UserParameter=cl.discovery,/home/zabbix/cl.discovery.pl
В
web-интерфейсе Zabbix-сервера создаем правило “create discovery rule”
(Рис. 1) для хоста, с которого осуществляется мониторинг серверов и
сети:
- Name discovery clients
- Type zabbix agent
- Key такой же, что указан в UserParameter (cl.discovery)
- Keep lost resources period (in days) 0 (если не хотим хранить информацию о серверах, которые не требуется мониторить)
Рисунок 1. Правило “create discovery rule”
В разделе Item prototypes (Рис. 2) создаем прототипы требуемых элементов данных (create item prototype):
Для времени отклика:
- Name ICMP ping response time to {#CLNAME} {#CLIP}
- Type Zabbix trapper
- Key cl.icmppingsec[{#CLIP}]
- Type of information Numeric(float)
- Units ms
Рисунок 2. Раздел Item prototypes.
Для потерь пакетов:
- ICMP ping percentage of loss packets {#CLNAME} {#CLIP}
- Type Zabbix trapper
- Key cl.icmppingloss[{#CLIP}]
- Type of information Numeric(float)
- Units %
В
разделе Graph prototypes (Рис. 3) создаем (create graph prototype)
прототип графиков привязанные к созданным прототипаv элементов данных.
Рисунок 3. Разделе Graph prototypes.
В разделе Trigger prototypes создаём прототипы тригеров к созданным прототипам элементов данных.
Теперь
при изменении списка с серверами в zabbix-сервере автоматически будут
создаваться и удаляться соответствующие элементы данных и графики (Рис.
4).
Рисунок 4. Графики по задержкам и потерям пакетов в канале до определенного узла.
