Елемент данных переходит в статус "не под

[bakomchik]

Доброго времени суток!Всё борюсь с мониторингом oracle.
Организовал сбор данных с сервера оракл посредством unixODBC.
Все замечательно!Данные собираются!
Но!
При недоступности сервера oracle , например при отсутсвтии доступа по сети.Элемент данных переходит в состояние "не поддерживаемый" с ошибкой :
"Failed connection [[unixODBC][Oracle][ODBC][Ora]ORA-12571: TNSacket writer failure ] (12571)".

Любезно прошу, подскажите ,как выйти из данной ситуации.
Может быть есть возможность запускать odbc проверку только при удачной проверки по пингу!

[dima_dm]

Есть такая настройка:
Администрирование->Общие параметры->Обновлять неподдерживаемые элементы данных (секунды)
Ну и триггер с функцией nodata создайте.
{Host:item.nodata(3600)}=1
Т.е. нет новых данных по Item более 1 часа.

[bakomchik]

Спасибо за ответ! Но ,к сожалению, не помогло. Когда отваливается сеть...и элемент данных переходит в состояние "не поддерживаемый", триггер {Host:item.nodata(60)}=1 переходит в состояние "НЕИЗВЕСТНО". Складывается впечатление что настройка:
Обновлять неподдерживаемые элементы данных , не отрабатывает , т.к состояние триггера не изменяется.Когда я ручками перевожу статус элемента данных, тогда состояние триггера меняется. Есть какие-нибудь мысли на данный счет.

[dima_dm]

Фукция nodata пересчитывается каждые 30 сек, нужно ставить больший интервал, стандартно выбирается N * Интервал обновления Item, где N>3
Сколько секунд поставили для "Обновлять неподдерживаемые элементы данных"?

[bakomchik]

Спасибо еще раз, за ответ. Но....та же песня.
у итема интервал проставлен в 60 с,
Обновлять неподдерживаемые элементы данных-60с(пробовал меньшие интервалы)
триггер {Host:item.nodata(240)}=1
триггер в статусе неизвестно уже 12 мин.
так же заметил, что при появлении сети, итем в течение установленного времени не переходит в состояние "активен".
В логах можно отследить происходит процесс обновления итема?

[dima_dm]

Обновлять неподдерживаемые элементы данных-60с
Это экстримально. Нужно же все неподдерживаемые элементы опросить, Zabbix просто не успеет. В логах Zabbix_server можно увидить как идёт опрос по Item (смотрите параметр DebugLevel в zabbix_server.conf).

[bakomchik]

Да с этим параметром..натупил....каюсь. поставил 10 минут. итем обновляется, но триггер всеравно в статусе "НЕИЗВЕСТНО".

[bakomchik]

Данная ситуация не меня устраивает. М.б разумнее использовать внешнюю проверку скриптом, который будет возвращать, например "-1", в случае ошибки при подключении по odbc?И отслеживать эту "-1"?

[bakomchik]

попробовал. написал скрипт на perl. при падении сети ... поцесс соединения с бд становится долгим, где-то секунд 30 и только потом возвращается дескриптор. теперь zabbix ругается на элемент, говоря (внешняя проверка) "timeout while executing a shell script". теперь смотрю в сторону cron.

[dotneft]

Для мониторинга Oracle (общее состояние доступности) лучше всего использовать внешний скрипт! nodata и т.п. не катят, уже натыкались на эти грабли. Чтобы снизить таймаут соединения с оракл в Perl выставьте таймаут на попытку соединения. Вроде можно сделать это в tns файле.

[bakomchik]

Спасибо огромное за ответы.Поступил так: в настройках odbc снизил timeout соединения.Внешним скриптом проверяю доступность oracle.А триггеры по остальным проверкам сделал зависимыми.
Кстати, вопрос: Как поведет себя итем "монитор баз данных" если запрос будет выполняться ну скажем минут 10, т.е много больше таймаута обновления елемента?

[RomanB]

А можете поделиться скриптом для проверки доступности Oracle. Борюсь с такой же проблемой. Нужно мониторить доступность БД Oracle, настроил odbc, но если БД не доступна элемент данных становиться не поддерживаемый.
Пробовал использовать предобработку (javascript, проверка ошибок с помощью регулярных выражений) не помогает, использовать в триггере noda() буду только в крайнем случае, из-за ложных срабатываний.

[shkiper]

если отваливается по сети, то наверно логично добавить зависимость в триггер - если не пингуется, то и другой триггер срабатывает

nodata() не работает, когда элемент становится не доступным (переходит в состояние "not enough data"), это стало критичным при переходе на agent2
т.е. при опросе, этот элемент отрабатывает как не поддерживаемый и возвращает ошибку
у меня подобная ситуация когда активный элемент просто некоторое время недоступен (для опрашиваемого элемента это нормально), где-то можно отключить этот "тайм-аут"?

вышел из ситуации предобработкой, проверяю регуляркой (в моем случае ^[\s\S]{1,10}) что возвращаемое значение является строкой, иначе присваиваю ноль