NetXMS Support Forum

    Всем привет!
    Помогите разобраться. Навешал на ноды DCI Ping of time {instance} через template, poller interval 5 сек., глобальный параметр сервера StatusPollerInterval = 10. Где то читал что при таймаутах в DCI данного типа возвращается значение 10000, начал замечать что такой ситуации никогда не возникает, хотя ноды с этими DCI не раз уходили в down. При разборе таких ситуаций видно, что в history на периоды down-ов отсутвуют данные, на графиках в это время прямая, которая соединяет последнее значение пинга на момент, когда нода пинговалась и следующее после down-а. Возможно это корректное поведение данного типа DCI, но хотелось бы как то отлавливать такие ситуации, привязать к ним treshold, alarm или что-то вроде этого. Может можно как то в transformation script-е фиксировать отсутвие данных, преобразовывать в те же 10000 или 0, и уже к этим значениям привязывать threshold-ы? Или существуют другие пути?

версия 2.0 M2

А где располагаются эти DCI? на машине, которая уходит в даун? Тогда все логично... Положи оду такую метрику на сервер например.. и пускай она пингует что-то. Вот когда это что-то отвалится - ты поймаешь таймаут.

    DCI располагаются на нодах, ноды мониторятся по snmp, агентов на них нет. А как быть если нод очень много (сотни)? При этом у ноды минимум 2 канала, за резервирование отвечает OSPF, в качестве primary ip ноды используется loopback-интерфейс ноды, который так же анонсируется по OSPF. Вот я и хотел создать template с ping of time {instance}, где instance интерфейсы ноды для каждого канала, а в template потом закинуть все ноды (благо они однотипные).

Ну темплейты ты моешь раскинуть, но если агента на нодах нет, то этот DCI там работать не будет.
Цель данного мероприятия какая? Мониторить доступность ноды?

Прицепил диаграмму сети для лучшего понимания.

У всех маршрутизаторов есть 2 сети, зеленая и оранжевая. На данный момент как я писал netxms цепляется к loopback-интерфейсам маршрутизаторов. Но Loopback-и напрямую зависят от состоянии маршрутизации и работы OSPF, в случае проблем с последней я буду видеть что ноды в дауне, не смотря на то что на самом деле каналы живы. Задача оценивать состояние каналов, мне показалось логичным решить ее именно так, и все бы хорошо, если бы я мог вразумить xms воспринимать временное отсутвие данных в DCI Ping of time. На сколько мне известно DCI отрабатыет в момент опроса статуса ноды?

Прицепил график DCI Ping of Time. Нода ушла в даун в 11:40:27, вернулась в 11:41:06. На графике видно в этот момент ту самую прямую. В history отсутствие данных. Сам по себе DCI работает.

Internal DCI на ping time работает не совсем так, как агентский - если нода недоступна, то возвращается ошибка сбора данных. Можно повесить threshold на data collection error.

Благодарю, Виктор! Навешал threshold-ы на data collection error, теперь хотя бы вижу, когда пропадают пакеты. Осталось непонятным как это отразить на графике? Из него не видно когда были потери пакетов, включал флаг Show thresholds в настройках графика (properties->data sources->modify->show tresholds), но ничего не происходило, если сходить опять в ту настройку флаг show trecholds оказывается отключеным. Я что-то опять не так делаю? Или баг?

UPD. Тоже озадачился этим вопросом, какие Operation и Value используете чтобы мониторить потери на ноде ? На графиках удалось добиться изображения тресхолдов?

У меня указано StatusPollingInterval - 30 на уровне сервера, в шаблоне DCI Polling Interval указываю 1 sec.

Но в Last Values - History всегда показывает каждые 5 сек. и значение 1 (было также 2 и 3) я так понимаю это time=  ?

Соотвественно до ноды потери, но как увидеть это в NetXMS ?

    Пакетов: отправлено = 1074, получено = 853, потеряно = 221
    (20% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 1мсек, Максимальное = 7 мсек, Среднее = 1 мсек

UPD. Нашёл еще не сколько тем с похожим запросами - везде рекомендуют использовать subagent ping, но он только для ноды с агентом, значит мне нужно мониторить packetloss на коммутаторах и других узлах по Internal DCI? Пока оставил Data collection error == equat to 10000. Но на проблемные ноды всё равно как то не понятно срабатывает.

QuoteUPD. Тоже озадачился этим вопросом, какие Operation и Value используете чтобы мониторить потери на ноде ? На графиках удалось добиться изображения тресхолдов?

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

QuoteНо на проблемные ноды всё равно как то не понятно срабатывает.

Настройка threshold-а у меня следующая:

Function: "Data collection error:
Samples: "1"
Operation: "== equal to"
Value: "<<ERROR>>"

Все работает корректно, генерятся event-ы и alarm-ы, но threshold-ы в графиках так и не видно. Может Вам за это время удалось победить?


P.S. Версия netxms 2.0 RC2

Поковырял багтрекер:
https://dev.raden.solutions/issues/54

Если я правильно понял, багу 3 года...

Я тоже больше не разбирался, а Threshold в Perfomance пока видимо не работают. На кратковременные отвалы по пингу коммутаторов нужно либо в конфиге NetXMS время опросов и пуллингов подкручивать, либо через snmp agent not responding event, ну или как то скриптом считать кол-во потерь, например часто бывает такое из-за слабого сигнала или постоянного включения отключения электричества на узле - коммутатор(нода) будет пинговаться с потерями и задержками, но при этом NetXMS не увидит что с ней какие то проблемы, либо увидит но не каждый раз.

Quoteнапример часто бывает такое из-за слабого сигнала или постоянного включения отключения электричества на узле - коммутатор(нода) будет пинговаться с потерями и задержками, но при этом NetXMS не увидит что с ней какие то проблемы, либо увидит но не каждый раз.

   Я повешал на Ping time of {instance} 2 threshold-а, один срабатывает, когда время отклика превышает 1200 мс, второй отслеживает data collection error. Соотв. когда штормит срабатывает threshold при превышении 1200 мс, когда совсем все плохо data collection error. Это работает довольно стопудово, у меня много нодов на 3G, так что у меня это ситуация частая. Печально что ситуация отражается только в эвентлоге и алармах, визуально на графиках у меня не работает нигде, не только в Perfomance Tab.
   Может можно исправить ситуацию созданием скриптового параметра, который при удачном пинге всегда выдаёт некоторое число, напрмер 2000, при неудачном 0, далее накладывать график этого параметра на график Ping time of {instance}. Еще не ковырял в эту сторону, но другого метода обхода бага я не вижу.