... Чё-то начинает у меня не по-детски бомбить и подгорать от Zabbix-а. Не, я конечно понимаю, что это OpenSource продукт. "Не нравится — не ешь" и всё вот это. Но блиииин. Какой же он не admin-friendly, мать-перемать! Обосновываю.
1. Крайне у**ищный веб-интерфейс. Долго не мог понять почему он не дает мне удалить метрики из шаблона. Тыкал-тыкал всюду, ну не догоняю. Коллега посмотрел свежим взглядом: "Дык ты же ж не разлинковал зависимые шаблоны". Как это не разлинковал?!? Я жы ж нажал везде кнопку "Unlink"! А фиг там, надо потом еще и "Update" жмакнуть. Мать-мать-мать! Причём, где-то надо, где-то не надо. В одном месте так, в другом сяк. Никакой унификации и единой логики работы интерфейса. Понятно, что когда уже мышкой мозоли себе натрешь, то там уже "на автомате" всё будешь делать. Но вот так, "с наскока" — это сильно вряд ли.
2. Типичная ситуация. Zabbix-сервер находится в одной локации, а в другой пачка серверов / сервисов и Zabbix-прокси. При этом если прокси отвалился, "зажигать" все остальные триггеры для удалённой площадки смысла нет: и так понятно, что они недоступны. И вот тут первый прикол: не существует однозначного ясного способа прописать такую зависимость. По отдельности можно мониторить timestamp последнего выхода прокси на связь и сравнивать его с текущим временем на "центральном" сервере. Можно мониторить доступность агентов на удалённых машинах. Но, допустим, достаточно надолго падает линк между площадками. Потом восстанавливается. Прокси начинает передавать накопленные данные "в метрополию", коих может оказаться довольно много. Соответственно, процесс может растянуться во времени. И на протяжении данного интервала прокся формально будет доступна, а вот агенты — извиняйте, т.к. данные по ним ещё "не приехали". Триггеры, стало быть, всё равно загорятся, несмотря на прописанные зависимости.
3. Не существует способ привязать срабатывание триггера к (не)доступности хоста, а не другого триггера. Притом, народ просит такую фичу уже очень давно, и она даже вроде и напрашивается сама собой... но нет. Видимо, архитектура не позволяет. Хотя за столько лет, наверное, что-то можно было бы придумать.
4. Из предыдущего пункта следует, что для решения всё той же самой задачи придется держать как минимум два набора "почти" одинаковых шаблонов: для "основной" площадки и для "выносных". Только в выносных прописывать зависимость каждого (!) триггера от доступности прокси. Всё бы и ничего, но вот когда/если вдруг понадобится внести в них какие-нибудь синхронные изменения... слинковать-то их друг на друга уже не получится.
5. Вот ты такой бодрый, насоздавал метрик типа "Zabbix Agent (active)", они даже исправно шлют тебе что-то. Но при этом ключ "zabbix[host,agent,available]" всё равно остается ложным (false), и зелёная плашка "ZBX" напротив имени хоста в веб-интерфейсе, соответственно, тоже не зажигается. Почему? А потому что! Изволь создать для данного хоста метрику типа "Zabbix Agent" (пассивный) с ключом "agent.ping". Иначе хрен тебе, а не индикатор доступности! "Л" — "логика".
6. Несмотря на настройки, активный прокси всегда раз в секунду "пингует" основной Zabbix-сервер. И никак это поведение не изменить.
А так, да, неплохая система. Пока не пытаешся лезть дальше дефолтных настроек и готовых шаблонов. Функции свои вполне выполняет.
И на всякий случай. Чтобы не потерялось. Команды для принудительного обновления конфигурации демонами:
zabbix_server -R config_cache_reload
zabbix_proxy -R config_cache_reload
На сервере и на проксе соответственно.