Нужны советы! Первые хосты в zabbix. Переход с nagios.

[SergeyG2]

Добрый день, Коллеги
Сразу прошу прощения за нубские вопросы, но... спросить больше негде и не у кого.
В нашей небольшой компании решили перейти с nagios на zabbix.
До сих пор пользовался nagios и кроме меня админа, мониторинг вообще никому не нужен был. В nagios меня устраивала именно простота, я получал с серверов windows и linux самое минимально необходимое: загрузку процессора, память, место на дисках, среднюю длину очереди дисков, пинг и состояние пары важных служб как на скриншоте ниже:


Я за! переход, развернул на ubuntu 16.04 версию zabbix 3.2 разобрался все хорошо, установил пару агентов на windows, то же разобрался. И пока разбирался со стандартными шаблонами и триггерами OS Windows получил просто сотню Элементов данных(Items) и триггеров, которых в стандартном шаблоне не было, скриншот ниже:

Правильно я понимаю, что это отработали правила Diacovery(Обнаружения) из стандартного шаблона?
Как мне получать только минимально необходимый набор данных в zabbix, практически свести к тому что было в nagios, как на скриншоте? Написать свой шаблон для Windows с нуля?
Что является Best Practice в Zabbix? Оставлять Diacovery(Обнаружение) включенным и убирать потом не нужные Items(элементы данных) и триггеры, или можно и нужно смело отключать?

[allexpetrov]

Приветствую, SergeyG2!

Zabbix выполняет определенный Discovery исходя из шаблона и добавляет Items для мониторинга.

К каким шаблонам прилинкованы Ваши хосты? Надеюсь Вы уже успели заметить, что в Zabbix некоторые шаблоны могут быть прилинкованы к другим и наследовать Items от них. (По шаблонам сюда: https://www.zabbix.com/documentation...lates/template)

Минимально необходимое конфигурируется руками, создавая свои Discovery и Templates только исходя из Ваших нужд. (Например, мониторят только CPU Load, Diskspace на C: и RAM).

Основной Best Practice - использовать свои шаблоны(именно шаблоны, не стоит увлекаться создаванием Items на хостах.) и мониторить именно то, что нужно дабы не создавать лишнюю нагрузку. Тем не менее, стоит ознакомиться со всем функционалом Zabbix, возможно у Вас появится желание мониторить что-то ещё.

С уважением,
Алексей!

[Kos]

Не знаю насчёт best practice у других, могу сказать за себя.

Я не использую стандартные шаблоны "как есть". Делаю их копию и сначала разбираюсь с этой копией, привязав её к одному-двум хостам. Смотрю, что в этом шаблоне есть вообще, смотрю - что из этого мне точно не нужно (тогда можно сразу удалить это из своего шаблона или, как минимум, отключить - disable), что точно нужно, что под вопросом (тогда временно оставить до прояснения). Например, какие-то элементы данных могут, в принципе, быть полезными (посмотреть потом статистику/графики), но триггеры на них мне совершенно не нужны. Для того, что осталось, корректирую при необходимости: для элементов данных - периодичность опроса (на свой субъективный вкус), для триггеров - пороговые значения и уровни важности. Отдельное внимание - правилам LLD (низкоуровневого обнаружения): обычно там избыток ненужных (для меня) прототипов элементов данных, триггеров и графиков; оставляю только те, которые реально мне нужны.
LLD для мониторинга сетевушек, например, оставляю, но все элементы данных создаются в неактивном состоянии (disabled): мне их мониторить нужно крайне редко, но если нужно - то сразу можно выбрать нужные (уже отдискаверенные) элементы данных и включить их выборочно.
Затем смотрю - остались ли, наоборот, те параметры, которые мне нужны, но в шаблоне отсутствуют; если нет - добавляю.

Отдельно отмечу, что большинство параметров предпочитаю мониторить в активном режиме (меньше нагрузка на сервер, страховка от кратковременных перебоев со связью).

И только "погоняв" шаблон хотя бы пару дней на парочке хостов и убедившись, что он теперь более-менее пригоден, привязываю этот шаблон к другим хостам.

Как-то так.

[SergeyG2]

Спасибо большое за ваши советы.

Сделал копию стандартного шаблона для Windows и за-disable что не нужно, добавил среднюю длину очереди диска. Оставил Discovery на диски, очень удобно оказалось, так как на серверах от 1го до 6-8 дисков может быть, создавать item и triger руками для каждого не удобно, а по месту мониторить их нужно. Добавил пару служб на мониторинг. И разобрался с оповещениями для разных серверов, разным программистам своим.

Понял что разбираться и разбираться ещё, пилить и пилить, но для начала хватит и этого минимума. Главное вник в логику zabbix.
Также понял, что до конца не решил, а нужен ли мне такой большой функционал, но больше не меньше...

[bercut-vermut]

Всем добрый день !
Не стал плодить еще одну тему, смысл схожий
Лет десять в нашей организации работал и процветал Nagios пока мы не захотели попробовать Zabbix. Сравнение очень сложное, т.к. уже правильно мнгие заметили, что Nagios - это скорее мониторинг в реальном времени, а Zabbix - скорее анализ данных в реальном времени. На основной монитор на стене выводится Nagios статус проблемных служб. На данный момент Zabbix у нас в виртуалке тмониторит и собирает данные по паре серверов и отслеживает сервисы, состояние смарта, датчиков ipmi и т.д. И при переходе многим хочется видеть "знакомый" функционал.
У многих пользователей Zabbix иногда возникает проблема с "отсутствием данных" и мы тоже с этим столкнулись. В Nagios отсутствие данных - это проблема, выводится как проблема службы и в статусной строке краткая информация ошибки.
Тут мы увидели такой эффект: данные приходят с ошибкой и item ушел в неподдерживаемое состояние, высылается письмо, которое не сразу заметили. Повесили триггер nodata и повторили эксперимент - на комплексном экране гордо появилась проблема с элементом.
Поэтому хотелось узнать у более опытных "Заббиксоидов":
Можно ли вывести список неподдерживаемых item`s в комплексном экране ?
Можно ли повесить триггер nodata на все элементы хоста простым способом ?
Можно ли выводить информацию схожих видов (1. значения со статусом 2. время следующей проверки элемента) как в аттаче ?
Прошу сильно не ругать, хотим перейти на Zabbix со "схожестью к привыкшим вещам"