Встала как-то перед нами с коллегой простая, в сущности, задача – поставить под мониторинг средствами Zabbix около полутысячи идентичных терминалов под управлением Linux, разбросанных по всей стране. Терминалы принадлежали одной сети – 10.0.0.0/8. Казалось бы, задача совершенно тривиальная. В самом деле – сварганить шаблон, запустить автообнаружение да все найденные хосты автоматом добавлять в группу и накатывать на них этот шаблон. Проще только чаю из пакетика заварить. Засучив рукава, мы взялись за дело…
В общем, ничего у нас (в полном соответствии с законами жанра) не вышло. Мы сделали шаблон, запустили автообнаружение и отправились культурно отдыхать, потому как дело было в пятницу. Вернувшись в понедельник, мы обнаружили, что за выходные наш Zabbix «автообнаружил» всего один хост. Опечалившись сему, мы принялись размышлять о причинах. И тут нас осенила простая мысль – а что такое, собственно, подсеть класса А?
Калькулятор услужливо подказал, что в подсети класса А содержится почти 17 миллионов хостов. Дальше наш электронный счетовод уточнил, что если на разборки с одним адресом Zabbix тратит 3 секунды (лаги в сети, опрос заведомо не наших клиентов и т.д.), то на обход подсети класса А ему понадобится затратить что-то около полутора лет. На один обход, подчёркиваю. Этот процесс можно проводить и параллельно – скажем, проверять адреса пачками по 20 штук. Но даже в этом случае на один обход подсети класса А уйдёт около месяца. При этом очевидно, что одного обхода мало – наш терминал может быть выключен или недоступен в тот самый момент, когда Zabbix пытается его опросить, а значит для верности надо будет пройтись по сети ещё раза три-четыре. В общем, мы внезапно поняли, что штатные средства автообнаружения Zabbix работают в штатном режиме, но совершенно не предназначены для обследования больших сетей.
Добавлять хосты в Zabbix руками? Это означало признать позорную капитуляцию перед лицом простой, в сущности, проблемы.
Интернет нам подсказал, что не мы первые сталкиваемся с такой задачей. На официальном форуме Zabbix подобный вопрос задавали. И получили традиционный, увы, ответ для подобного рода форумов – предложение наиболее сложного и неэффективного способа. Поскольку изучать API Zabbix не было времени, мы решили всё же снова попытать счастья с базой данных.
В базе данных Zabbix имеется таблица, в которой перечислены все контролируемые хосты с их параметрами – таблица hosts. При этом каждому хосту в этой таблице соответствует уникальный идентификатор – целое число. При этом параметров, достаточных для постановки хоста на контроль, не так уж и много – его идентификатор в базе данных, его IP и его имя в Zabbix.
Подход прост – сначала выясняем, какой индекс по базе данный имеет последний добавленный хост:
Здесь и далее запросы приведены для MySQL, что, в принципе, не влияет на суть. Увеличиваем полученное значение на единицу – готов индекс по базе данных для нового хоста. Имя хоста и его IP-адрес мы знаем, соответственно, можем добавить хост в Zabbix:
При этом:
Приведённый выше запрос составлен в предположении, что мы контролируем хосты по их адресу, а не по их DNS-имени. Впрочем, для этого второго варианта запрос принципиально не изменится – только новое поле добавится.
Итак, хост добавлен, но этого мало – каждый хост должен принадлежать какой-нибудь группе. И это тоже можно сделать напрямую в базе данных. Предположим для определённости, что наши терминалы мы хотим загнать в группу Linux servers.
Все группы в базе данных хранятся в таблице groups (тривиально, не правда ли?). Нам понадобится индекс нашей группы, который мы можем выяснить простым запросом:
Для учёта принадлежностей хостов к группам в базе данных есть специальная таблица – hosts_groups. В этой таблице хранятся простые соответствия – хосту с индексом таким-то соответствует группа с индексом таким-то. Для каждого хоста заводится ровно столько соответствий, сколько групп этот хост содержат. И каждому соответствию, как водится, присваивается уникальный индекс – целое число. Выясняем индекс последнего соответствия:
Увеличиваем полученное значение на единицу – вот вам и индекс нового соответствия для нашего свежедобавленного хоста. Индекс хоста знаем, индекс группы выяснили – что нам мешает добавить хост в группу?
При этом:
После всех этих манипуляций мы можем заглянуть в веб-интерфейс Zabbix и обнаружить наш хост в группе Linux servers. Заглянув в его параметры, мы видим, что данному хосту не сопоставлены сенсоры, триггеры и графики – хост есть, Zabbix о нём знает но не контролирует, поскольку не задано ни одного элемента данных. Применяем к этому хосту созданный предварительно шаблон и – дело в шляпе! Zabbix самостоятельно навешивает на наш хост сенсоры и триггеры и приступает к мониторингу.
В итоге наша задача решается комбинированным подходом:
P.S. Кругом в статье под именем хоста подразумевается то самое имя, под которым этот хост фигурирует в Zabbix. И оно не имеет отношения к DNS-имени хоста (хотя никто не мешает им совпадать). Если вы используете агента мониторинга, то имя хоста – это значение переметра hostname в его конфигурационном файле.
Неудача предыдущих поколений в манипуляциях с базой данных, вполне очевидно, заключается в том, что сопоставить шаблон хосту в базе данных – отнюдь не одно и то же, что применить этот шаблон из интерфейса Zabbix. Очевидно, что применение шаблона создаёт сопоставления между хостом и сенсорами, хостом и триггерами и т.д., и структура этих таблиц уже становится слишком сложной.
Я не привожу здесь готовый скрипт. Во-первых, потому чо у меня его нет – практическую часть делал мой коллега на Perl путём парсига текстового файла с именами и IP терминалов и создания из них SQL-скрипта. Я бы сделал всё на Ruby, скорее всего. Другой мой коллега сказал, что здесь с ушами хватит обычного шелл-скрипта. Впрочем, алгоритм прост и его можно реализовать, как вам заблагорассудится.
И напоследок… Когда мы добавляли наши терминалы, мы не учли одного момента – для Zabbix количество контролируемых сенсоров внезапно возросло с 80 до 4000. Бедная зверушка ошалела от такого поворота событий и свалилась в обморок. Поэтому рекомендую перед таким массовым добавлением хостов Zabbix отключать, хотя бы из соображений гуманности. Ну и, конечно, после добавления и применения шаблона Zabbix затратит какое-то время на то, чтобы осознать и переварить свалившуюся на него кучу подконтрольных объектов, так что будьте терпеливы. Впрочем, это время всяко на порядки меньше, чем время, потребное на обход подсети класса А.
Рождение проблемы
В общем, ничего у нас (в полном соответствии с законами жанра) не вышло. Мы сделали шаблон, запустили автообнаружение и отправились культурно отдыхать, потому как дело было в пятницу. Вернувшись в понедельник, мы обнаружили, что за выходные наш Zabbix «автообнаружил» всего один хост. Опечалившись сему, мы принялись размышлять о причинах. И тут нас осенила простая мысль – а что такое, собственно, подсеть класса А?
Калькулятор услужливо подказал, что в подсети класса А содержится почти 17 миллионов хостов. Дальше наш электронный счетовод уточнил, что если на разборки с одним адресом Zabbix тратит 3 секунды (лаги в сети, опрос заведомо не наших клиентов и т.д.), то на обход подсети класса А ему понадобится затратить что-то около полутора лет. На один обход, подчёркиваю. Этот процесс можно проводить и параллельно – скажем, проверять адреса пачками по 20 штук. Но даже в этом случае на один обход подсети класса А уйдёт около месяца. При этом очевидно, что одного обхода мало – наш терминал может быть выключен или недоступен в тот самый момент, когда Zabbix пытается его опросить, а значит для верности надо будет пройтись по сети ещё раза три-четыре. В общем, мы внезапно поняли, что штатные средства автообнаружения Zabbix работают в штатном режиме, но совершенно не предназначены для обследования больших сетей.
Что делать? ©Чернышевский
Добавлять хосты в Zabbix руками? Это означало признать позорную капитуляцию перед лицом простой, в сущности, проблемы.
Интернет нам подсказал, что не мы первые сталкиваемся с такой задачей. На официальном форуме Zabbix подобный вопрос задавали. И получили традиционный, увы, ответ для подобного рода форумов – предложение наиболее сложного и неэффективного способа. Поскольку изучать API Zabbix не было времени, мы решили всё же снова попытать счастья с базой данных.
Алгоритм решения
В базе данных Zabbix имеется таблица, в которой перечислены все контролируемые хосты с их параметрами – таблица hosts. При этом каждому хосту в этой таблице соответствует уникальный идентификатор – целое число. При этом параметров, достаточных для постановки хоста на контроль, не так уж и много – его идентификатор в базе данных, его IP и его имя в Zabbix.
Подход прост – сначала выясняем, какой индекс по базе данный имеет последний добавленный хост:
select hostid from zabbix.hosts order by hostid desc limit 1;Здесь и далее запросы приведены для MySQL, что, в принципе, не влияет на суть. Увеличиваем полученное значение на единицу – готов индекс по базе данных для нового хоста. Имя хоста и его IP-адрес мы знаем, соответственно, можем добавить хост в Zabbix:
insert into zabbix.hosts (hostid,host,useip,ip) values ($hostid,$hostname,1,$IP);При этом:
- $hostid – полученный нами ранее новый индекс по базе данных;
- $hostname – имя хоста;
- $IP – его IP-адрес.
Приведённый выше запрос составлен в предположении, что мы контролируем хосты по их адресу, а не по их DNS-имени. Впрочем, для этого второго варианта запрос принципиально не изменится – только новое поле добавится.
Итак, хост добавлен, но этого мало – каждый хост должен принадлежать какой-нибудь группе. И это тоже можно сделать напрямую в базе данных. Предположим для определённости, что наши терминалы мы хотим загнать в группу Linux servers.
Все группы в базе данных хранятся в таблице groups (тривиально, не правда ли?). Нам понадобится индекс нашей группы, который мы можем выяснить простым запросом:
select groupid from zabbix.groups where name=‘Linux servers’;Для учёта принадлежностей хостов к группам в базе данных есть специальная таблица – hosts_groups. В этой таблице хранятся простые соответствия – хосту с индексом таким-то соответствует группа с индексом таким-то. Для каждого хоста заводится ровно столько соответствий, сколько групп этот хост содержат. И каждому соответствию, как водится, присваивается уникальный индекс – целое число. Выясняем индекс последнего соответствия:
select hostgroupid from zabbix.hosts_groups order by hostgroupid desc limit 1;Увеличиваем полученное значение на единицу – вот вам и индекс нового соответствия для нашего свежедобавленного хоста. Индекс хоста знаем, индекс группы выяснили – что нам мешает добавить хост в группу?
insert into zabbix.hosts_groups (hostgroupid,hostid,groupid) values ($hostgroupid,$hostid,$groupid);При этом:
- $hostgroupid – индекс нового сопоставления;
- $hostid – индекс нашего нового хоста (мы использовали его выше для добавления самого хоста);
- $groupid – индекс нужной нам группы (мы выясняли его выше).
После всех этих манипуляций мы можем заглянуть в веб-интерфейс Zabbix и обнаружить наш хост в группе Linux servers. Заглянув в его параметры, мы видим, что данному хосту не сопоставлены сенсоры, триггеры и графики – хост есть, Zabbix о нём знает но не контролирует, поскольку не задано ни одного элемента данных. Применяем к этому хосту созданный предварительно шаблон и – дело в шляпе! Zabbix самостоятельно навешивает на наш хост сенсоры и триггеры и приступает к мониторингу.
В итоге наша задача решается комбинированным подходом:
- манипуляциями с базой данных добавляем в Zabbix все наши терминалы;
- с помощью функции массового обновления хостов навешиваем на добавленные терминалы соответствующий шаблон.
P.S. Кругом в статье под именем хоста подразумевается то самое имя, под которым этот хост фигурирует в Zabbix. И оно не имеет отношения к DNS-имени хоста (хотя никто не мешает им совпадать). Если вы используете агента мониторинга, то имя хоста – это значение переметра hostname в его конфигурационном файле.
Вместо послесловия
Неудача предыдущих поколений в манипуляциях с базой данных, вполне очевидно, заключается в том, что сопоставить шаблон хосту в базе данных – отнюдь не одно и то же, что применить этот шаблон из интерфейса Zabbix. Очевидно, что применение шаблона создаёт сопоставления между хостом и сенсорами, хостом и триггерами и т.д., и структура этих таблиц уже становится слишком сложной.
Я не привожу здесь готовый скрипт. Во-первых, потому чо у меня его нет – практическую часть делал мой коллега на Perl путём парсига текстового файла с именами и IP терминалов и создания из них SQL-скрипта. Я бы сделал всё на Ruby, скорее всего. Другой мой коллега сказал, что здесь с ушами хватит обычного шелл-скрипта. Впрочем, алгоритм прост и его можно реализовать, как вам заблагорассудится.
И напоследок… Когда мы добавляли наши терминалы, мы не учли одного момента – для Zabbix количество контролируемых сенсоров внезапно возросло с 80 до 4000. Бедная зверушка ошалела от такого поворота событий и свалилась в обморок. Поэтому рекомендую перед таким массовым добавлением хостов Zabbix отключать, хотя бы из соображений гуманности. Ну и, конечно, после добавления и применения шаблона Zabbix затратит какое-то время на то, чтобы осознать и переварить свалившуюся на него кучу подконтрольных объектов, так что будьте терпеливы. Впрочем, это время всяко на порядки меньше, чем время, потребное на обход подсети класса А.
