Добрый день!
Есть такой базовый шаблон - Chassis by IPMI.
В моем случае полезен для старых систем. Например HP DL360 G7. В нем нет SNMP агента, выдернуть данные через SNMP нельзя.
Но можно что-то выдернуть через IPMI (по 623 порту).
Вот начал изучать этот шаблон, сделал фулл клон, сижу ковыряюсь.
Если кратко этот шаблон глобально сперва получает сырые данные (json) через ipmi.get, потом уже через один LLD создает элементы данных с текстовой информацией и через второй LLD создает элементы данных с числовой информацией.
Чуть подробнее по второму LLD
В рамках выполнения второго LLD (получение цифровых значений) получаются как сами текущие значения (например температура CPU) , так и пределы (threshold) (базово я так понимаю их 6 (по стандарту некому): низкое не критичное, низкое критичное, низкое разрушительное; высокое некритичное, высокое критичное, высокое разрушительное). Для текущих значений создаются элементы данных, для переделов триггеры.
Возник вопрос в части замещений (overrides) второго LLD. Зачем они эти замещения (overrides) там нужны в шаблоне?
Судя по их настройкам они не рабочие.
1. Взять хотя бы тот фактор, что чтобы они выполнялись нужно настроить сперва фильтр. Но он пустой...
2. Также в "операции" (иначе действие/замещение) они тут пытаются применить отмену поиска (discovery) для триггеров в названии которых будет присутствовать макрос - {#SENSOR_HI_WARN}.
макрос - {#SENSOR_HI_WARN} это числовое значение предела (высокое некритичное). Но суть в том, что согласно шаблону триггеры не создаются с именами в которых присутствуют конечные значения! Имена триггеров просто обобщённые, например - IPMI: {#SENSOR_ID} value is above non-critical high
То есть вся секция Overrides какой-то абсурд...
Или я что-то не так понял?!
Другое мое предположение было, что в этот шаблон специально прописали эти нерабочие настройки, чтобы они просто там были. А далее уже их использовать при необходимости и править как необходимо под задачу...
Собственно у меня такая ситуация и получилась. Если кратко один сервер выдает только 2 из 6 пределов, а триггеры при этом создаются на все 6 пределов, как итог 2/3 триггеров не рабочие. С помощью замещения получилось отфильтровать поиск=создание не нужных триггеров.
Собственно правильно ли я рассуждаю или что-то не так понял в этом шаблоне?
Заранее спасибо за ответы.
Есть такой базовый шаблон - Chassis by IPMI.
В моем случае полезен для старых систем. Например HP DL360 G7. В нем нет SNMP агента, выдернуть данные через SNMP нельзя.
Но можно что-то выдернуть через IPMI (по 623 порту).
Вот начал изучать этот шаблон, сделал фулл клон, сижу ковыряюсь.
Если кратко этот шаблон глобально сперва получает сырые данные (json) через ipmi.get, потом уже через один LLD создает элементы данных с текстовой информацией и через второй LLD создает элементы данных с числовой информацией.
Чуть подробнее по второму LLD
В рамках выполнения второго LLD (получение цифровых значений) получаются как сами текущие значения (например температура CPU) , так и пределы (threshold) (базово я так понимаю их 6 (по стандарту некому): низкое не критичное, низкое критичное, низкое разрушительное; высокое некритичное, высокое критичное, высокое разрушительное). Для текущих значений создаются элементы данных, для переделов триггеры.
Возник вопрос в части замещений (overrides) второго LLD. Зачем они эти замещения (overrides) там нужны в шаблоне?
Судя по их настройкам они не рабочие.
1. Взять хотя бы тот фактор, что чтобы они выполнялись нужно настроить сперва фильтр. Но он пустой...
2. Также в "операции" (иначе действие/замещение) они тут пытаются применить отмену поиска (discovery) для триггеров в названии которых будет присутствовать макрос - {#SENSOR_HI_WARN}.
макрос - {#SENSOR_HI_WARN} это числовое значение предела (высокое некритичное). Но суть в том, что согласно шаблону триггеры не создаются с именами в которых присутствуют конечные значения! Имена триггеров просто обобщённые, например - IPMI: {#SENSOR_ID} value is above non-critical high
То есть вся секция Overrides какой-то абсурд...
Или я что-то не так понял?!
Другое мое предположение было, что в этот шаблон специально прописали эти нерабочие настройки, чтобы они просто там были. А далее уже их использовать при необходимости и править как необходимо под задачу...
Собственно у меня такая ситуация и получилась. Если кратко один сервер выдает только 2 из 6 пределов, а триггеры при этом создаются на все 6 пределов, как итог 2/3 триггеров не рабочие. С помощью замещения получилось отфильтровать поиск=создание не нужных триггеров.
Собственно правильно ли я рассуждаю или что-то не так понял в этом шаблоне?
Заранее спасибо за ответы.