Мониторинг Vmware

[Kasha]

Добрый день！
Есть пару вопросов относительно мониторинга Vmware.


Мониторинг DataStore.
Все Datastore находятся с помощью LLD на каждом из хостов Vmware. Имея несколько хостов в кластере и общие Datastore для всех хостов внутри кластера, срабатывания происходят многократные. В настоящий момент мы добавили тэг Datastore={#Datasrore} и с помощью правил корреляции видим только одно первое срабатывание. Насколько это решение оптимальное?

Мониторинг CPU\RAM для хостов.
в рамках одного vcenter несколько кластеров: Продуктовые среды/Среды тестирования/Разработки. Для каждой из типов сред хотелось бы установить свои пороги. Вариант с Макро не подошел, поскольку для хостов, обнаруженных через LLD, нет возможности их добавлять. Был вариант, с использованием констукции {$Cpulimit:"{#Cluster.Name}"}, и определением специфичных макро в основном шаблоне, но он также не годится, поскольку триггеры не являются LLD, третий вариант, это поставить дважды/трижды один и тот же vcenter, отфильтровав по кластерам и реализовав различные пороги, на мой взгляд - конкретный костыль. Подскажите, может кто-то уже что-то подобное делал....


Каким образом можно определить тип ОС у контейнера VM? Хочу делать сверки, что для каждого контейнера, установлен агент и к нему применен базовый шаблон по типу ОС.

P.S. Также хотелось передать большой привет разработчику, кто придумал измерять нагрузку на CPU в ГГц вместо %, при наличии разных CPU, кол-ва RAM, триггеры совершенно бесполезны. Конечно в итоге я создал свои элементы данных, но подход не понятен. Создалось впечатление несколько сырого продукта.

[DRVTiny]

Я пришёл для себя к правильному ответу на все эти вопросы.

Ответ простой, как палка: VMware vSphere Perl API 6.5 и создание/удаление хостов скриптом.

У создаваемых обнаружением хостов даже IP/DNS определить нельзя - о чём здесь ещё говорить, что обсуждать. Сделано на от(стань, пожалуйста), так что без скриптинга - никуда.

И да, я использовал до этого vPoller, потому что штатный функционал zabbix на эту тему - это даже не смешно, а очень грустно.

[DRVTiny]

Создалось впечатление несколько сырого продукта.

Я плакал Это вы наверное недавно zabbix'ом пользуетесь. Я вот давно.

[yukra]

Я плакал Это вы наверное недавно zabbix'ом пользуетесь. Я вот давно.

Минутка философии:
Если сравнивать почти любой инструмент "общего назначения" со "специализированным инструментом узкого назначения" и делать это в той области, для которой изначально предназначен этот специализированный инструмент, то инструмент общего назначения почти всегда проиграет. Не потому что он плохой, а потому что у них разное назначение.

Я почти на 100% уверен что если начать искать систему мониторинга для vmware, то найдется более лучшая система чем заббикс, так же найдется более лучшая система для мониторинга винды, для мониторинга линукса, для мониторинга свичей (скорей всего по несколько штук для разных свичей), найдется даже система, в которой из коробки большая поддержка оборудования, больше шаблонов, лучше комьюнити, дешевле поддержка, удобнее администрирование, меньше потребление ресурсов и проще собрать HA-кластер. Единственная проблема это то, что под каждый из вышеозвученных параметров будет лучше подходить своя система, со своими, как сильными, так и слабыми сторонами.
Заббикс же даем нам 2 простые вещи: во первых поддержку наиболее востребованных вещей на базовом уровне (win, nix, snmp) и дает возможность расширения системы по потребностям (external check, API, подгружаемые модули).
"ныть" на форуме конечно удобно, но что-то мне подсказывает что не особо эффективно, лучше "ныть" путем написания тикетов в ZBXNEXT или патчами.

[DRVTiny]

Минутка философии:

Неуместна.

Zabbix делает неправильно, нелогично и просто криво фундаментальные вещи, к мониторингу какого-то конкретного оборудования или софта претензий на самом деле нет. Есть только недоумение на тему того, что если уж для чего-то функционал мониторинга VMware был включен, то непонятно, почему реализовано он столь убого. Я считаю, что либо делать хорошо, либо не делать. Учитывая гигантские пробелы в логике мониторинга, отсутствие даже встроенной ловушки для SNMP-трапов и прочие подобные таблицам history маразматические вещи - я не понимаю, зачем вообще в Zabbix понадобилось прикручивать VMware-мониторинг, неужели заняться больше было нечем? Или за что заплатили - то и приделали. OpenSource отличается от Accessible Sources - жаль, что "совместная открытая разработка" и "возможность скачать сырцы" для команды zabbix - одно и то же. В OpenSource развитие продукта не может определяться тем, кто сколько и когда забашлял за сиюминутные хотелки.

[Kasha]

На самом деле я не жаловаться пришел, а совета спросить, а все уцепились за P.S. )

Для большинства небольших компаний, в которых 1 vcenter и несколько хостов, до сотни VM, этого будет достаточно.

Конечно в "базу" я бы добавил сходу доступность esxi хоста, такого триггера нет, что конечно сразу показывает зрелость пакета. Версия 3.4.4.

Еще раз, у меня нет претензии, спрашиваю, как сделать правильно.

Хотелось бы, чтобы zabbix шаблон отличал от VM.
У VM был бы признак ОС, возможность делать из VM прототип хоста (но как я понял с этим тоже проблемы), после этого такой нельзя хост в другие группы добавлять, изменять макро и т.д.