Snmp: проблема с сетевыми принтерами.

[devi29rus]

Здравствуйте пользователи замечательной системы zabbix.

Возникла нужна мониторить по SNMP сетевые принтера от фирмы Kyocera вычислил что под них подходит MIB файл rfc1759.

Нашел нужный мне параметр OID .1.3.6.1.2.1.43.18.1.1.7 (prtAlertCode). В этом разделе появляются статусные сообщения и главное для меня - ошибки.

Я довольный результатом - симулировал к примеру отсутствие бумаги в принтере. Поймал это:

prtAlertCode.1.3; Value (Integer): inputMediaSupplyEmpty (808)

Добавил в мониторинг, но вскоре увидел, что элемент данных не поддерживается, стал выяснять. Оказывается когда на принтере ошибку устранили и она потом снова появляется, она может содержать уже чуть другой OID, к примеру:

prtAlertCode[B][SIZE="4"].1.13[/SIZE][/B]; Value (Integer): inputMediaSupplyEmpty (808)

Счётчик увеличивается до бесконечности, вплоть до перезапуска принтера. Т.е. если принтер не выключать неделю - то ошибки доходят до prtAlertCode.1.87 (больше 99 не наблюдал).

Прошу помощи помочь - как мне поймать нужный мне OID и сигнализировать об ошибке.

P.S. - zabbix версии 2.2.2 и еще есть версия 1.8.3
P.P.S. - не помогают динамические индексы (или я их не правильно делаю)

Заранее спасибо за любую догадку!

[Jimson]

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

Во вторых, возникает подозрение - а не может ли на принтере быть сразу 2 или более проблемы? И что тогда пуллер должен получать? Проэмулируйте несколько проблем и проверьте.

В третьих, функционально такой счетчик отмониторить SNMP пуллером zabbix не может. Вариант с динамическим индексом не подойдет потому что собственно нет индексного OID, использовать тот же OID как индекс не получится так как строка для сопоставления в index[] требует точного совпадения, а у вас в качестве значения произвольный текст. Опросить такой OID можно через внешнюю проверку - скрипт.

[devi29rus]

Уточнение.

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

Трапы работают, но прилетают тоже разные данные, нужные мне проблемы возникают в виде "Error 1234" и при одинаковой же ошибке номера - разные.

Во вторых, возникает подозрение - а не может ли на принтере быть сразу 2 или более проблемы? И что тогда пуллер должен получать? Проэмулируйте несколько проблем и проверьте.

Да - ошибок может быть много за раз - пулер получает множетсов OID - отличается OID только одной цифрой в конце.

[Jimson]

Вообщем с "лампочками" все как всегда сложно.

1) есть в информации приходящей трапом или в строке отдаваемой по указанному OID какой то уникальный идентификатор ошибки?
2) если принимать трапы, то что конкретно посылает принтер - эвенты или алерты? первые суть журнал, вторые имеют дополнительные OID в трапе указывающие на состояние алерта (активен, очищен), важности и тп

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

В самом просто варианте: скрипт вызываемый как внешняя проверка, который делает две вещи:
1) сбор сообщений
2) возвращает кол-во активных "проблем", суть записей в указанном snmp дереве
Вернуть кол-во проблем не составит, а вот ообщения которые вы выгребете по данному OID нужно во первых проанализировать на тему какие из них вы уже отсылали забиксу (хранить где то индексы), а во вторых отослать через zabbix_sender API вновь появившиеся алармы. В этом случае триггер у вас будет сигнализировать лишь о наличии проблемы, а сами проблемы можно будет посмотреть в элементе данных log[]

[pzabortsev]

Нашел нужный мне параметр oid .1.3.6.1.2.1.43.18.1.1.7 (prtalertcode). В этом разделе появляются статусные сообщения и главное для меня - ошибки.

Скорее всего этот раздел содержит журнал ошибок.
Где-то скорее всего есть параметр, в котором содержится номер последней ошибки (или размер журнала). Можно попробовать использовать этот парамерт для вытягивания последнего сообщения об ошибке. Понятно, что это будет просто последнее случившееся событие, а не то, которое Вы хотите поймать.

На мой взгляд правильнее заняться настройкой трапов.