Использование Dependent items в Zabbix 4.0 на примере HPE MSA 2040/2050

[Renaissance]

Спасибо за статью, очень познавательно.
Мониторинг оборудования HPE вообще тот еще геморрой: разные продукты (по бОльшей части перекупленные HP) имеют разные реализации мониторинга, так еще и со внешними системами постоянно проблемы.
Кстати, как раз используем этот скрипт для мониторинга P2000G3. Хоть она уже и retired, но живучая, зараза…

[asand3r]

Не могу сказать за всё оборудование НР, у нас от них только пачка DL360/380, да вот СХД. Так-то данный кейс не особо и сложен, благо есть варианты получения метрик, но сделать это как-то быстро и красиво у меня получилось только сейчас. =)
P2000g3 стараюсь поддерживать, но бывали ошибке при парсинге XML, т.к. у меня в парке только 2040 и 2050 и вживую проверить на старом железе не могу.

[lioncub]

Чего хотелось бы от Zabbix, так это возможность использовать один запрос на несколько элементов данных, это бы избавило от использования временных файлов, например как у вас, разгрузило бы в таких случаях сам zabbix, и отсутствовала бы задержка между запросами по таким элементам. И да, зависимые элементы данных — это очень хороший функционал. Сам теперь жду релиза 4.0 для обновления т.к. LTS.

[asand3r]

возможность использовать один запрос на несколько элементов данных

По сути, зависимые элементы, примерно это и реализуют. Мы делаем один запрос, а в итоге разбираем полученные данные на множество метрик. Есть нюансы, конечно, вроде одинакового времени опроса у всех дочерних айтемов и фактического дублирования информации в БД, но всё же это большой шаг.

[Sleuthhound]

Зависимые элементы данных и в 4 версии имеют массу ограничений по использованию, например не поддерживаются массивы, что жутко не удобно.
Поэтому чем мучится с ними и придумывать костыли, то лучше для отправки сразу пачки метрик без зависимых элементов данных — использовать zabbix-sender.

[asand3r]

например не поддерживаются массивы

Я не понял о каких массивах идёт речь.

использовать zabbix-sender

Всё равно это своеобразный «костыль» и придется писать какую-то обвязку.

[Sleuthhound]

Я не понял о каких массивах идёт речь.

О том самом в Json:

Массив — упорядоченная коллекция значений. Массив начинается с [ (открывающей квадратной скобки) и заканчивается ] (закрывающей квадратной скобкой). Значения разделены, (запятой).

Если на пальцах, то к примеру у вас есть такие данные:

	{
		"hostname": "myserver.ru",
		"date": "06.08.2018 11:52:18",
		"msg": [{
				"error_code": "231",
				"error_msg": "Error: XXXX not a president"
			},
			{
				"error_code": "232",
				"error_msg": "Error: XXXX is crab"
			}
		]
	}

Дак вот зависимый элемент данных не может быть массивом, не работает вот так $.msg[*]
Можно максимум извлечь из массива какой-нибудь элемент так: $.msg[0].error_code
Оно и понятно, почему так не будет работать, но хотелось… хотя бы весь массив извлечь, но он не извлекается :(

Всё равно это своеобразный «костыль» и придется писать какую-то обвязку.

Вот как раз zabbix-sender — это не костыль. Когда сбор данных и его обработка занимают более 30 сек., тут и приходит на помощь zabbix-sender, т.к. агент столько ждать не может.

[asand3r]

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

[Sleuthhound]

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