А как приличные люди делятся наработками?
-
Насчет приличных не знаю, а мы в соответствующих темах. Или на Zabbix Share, если уже готовое и оттестированное. -
Наверное, так. Но что-то моя идея забуксовала уже на начальном этапе.
А можно в item prototype как-то нарисовать Calculated item по группировке? Пример (я без JSON-а) - от discovery приходят пары "Volume1:Count1", "Volume2:Count2", "Volume1:Count3", "Volume2:Count4". Надо чтобы появились item1=Count1+Count3 и item2=Count2+Count4
Или выполнить какой-то вложенный дискавери? Типа сначала получили перечень Volume, а потом по каждому запустили второй дискавери с фильтром по имени Volume?Comment
-
Думаю, что нет. Каждый входящий набор данных полученных при исследовании, рассматривается без учета ранее обработанных данных.
Вы можете создать вручную вычисляемый элементы данных, использующие названия предполагаемых ключей (по-моему выражение не проверяется на предмет существования таковых в момент сохранения). До того момента, пока из прототипов не будут созданы элементы данных, вычисляемый элемент будет находится в состоянии unsupported, затем должен активироваться.Comment
-
Думаю, не сработает. Количество элементов данных для суммирования-то неизвестно.
Хотя... Почему бы не формировать содержимое key для item-ов прямо в скрипте, который делает дискавери, сделав предварительно все нужные группировки? И в прототипе задавать только имя и тип, а в поле key писать просто {#KEYVALUE}, к примеру? Не очень красиво, но, возможно, сработает... Пошел думать дальше...Comment
-
Наверняка сработает, но будет две точки администрирования - Zabbix и скрипт, который нужно будет править под индивидуальный набор данных на всех серверах при изменившихся именах ресурсов (или на что там завязывается). Ну или писать генерализованное решение, которое будет проводить внутренний дискаверинг, почти что формировать элемент данных в зависимости от версии WinServer (есть же и русскоязычные сервера и испаноязычные), если элемент будет связан с Perfmon.Comment
-
Не очень понятно, что имеется в виду под двойным администрированием. Если у нас есть дискавери-скрипт, выполняющийся на винде, и темплейт, живущий на заббикс-сервере (как, к примеру, в вашем решении), то оно всегда двойное. Т.е. если хочется добыть и обработать какие-то новые элементы данных, то надо править решение в двух местах.
Или речь идет о том, что надо поправленный дискавери-скрипт раскопировать на все сервера кластера? Ну, это терпимое неудобство. Кому нетерпимое - пусть делает dfs с репликацией. Темплейт для мониторинга репликации готов дать
"Синьоро, ё но тенго динаро!" Это я к тому, что пусть испанцы о себе сами заботятся
Comment
-
Я, конечно, не знаю ваш замысел, но допускаю, что могут быть полезны следующие конструкции:
1. Прототип айтема типа Calculated item для вычислений над прототипами айтемов. Правда, если один из операндов станет unsupported, то и Calculated item будет unsupported.
2. Calculated item для вычислений над Aggregate checks. Думаю, должен быть устойчив к появлению unsupported айтемов.Comment
-
Ну, например, передается из скрипта {#KEYVALUE} = "Volume1.WriteSpeed.last(0)+Volume1.ReadSpeed.last (0)". Переименовали вы в кластере Volume1 в Volume1onNASX - и пошли менять по всем нодам скрипты + на Zabbix'е править.
Сейчас вы, конечно, напишете, что у вас не так, но проблема в том, что вы знаете, что делаете, а я (и все остальные) только догадываюсь, что вы выпиливаете. Учитывайте это. Скрипты я такие видел и заранее предупреждаю.
Новая функциональность требует изменения - безусловно. Но замена скрипта только при изменившихся идентификаторах... Я таких решений избегаю.Если у нас есть дискавери-скрипт, выполняющийся на винде, и темплейт, живущий на заббикс-сервере (как, к примеру, в вашем решении), то оно всегда двойное. Т.е. если хочется добыть и обработать какие-то новые элементы данных, то надо править решение в двух местах.
И, если уж вы вспомнили мое решение, то вы можете в большинстве случаев на уровне Zabbix указать любой properties класса, из экземпляров (объектов) которого будет состоять коллекция (выборка). Далее применить к нему соответствующее действие - суммировать или считать кол-во. Переименовывать ресурсы можно хоть каждый интервал дискаверинга.Comment
-
Собственно, речь и идет про то, как правильно написать дискавери-скрипт, который будет формировать этот {#keyvalue} исходя из реальной конфигурации кластера. Чтобы ни в скрипте, ни в темплейте(ах) не было завязок на какую-то мою конкретику с количеством и именами серверов, томов, виртуалок, распределением vhd по томам и пр. Именно про это. Иначе действительно получится "закат Солнца вручную". Оно такое мне даром не нужно.Comment
Comment