NetXMS Support Forum

Премного благодарен =)
Буду помогать чем смогу.

Могу предоставить исходник нашего мониторинга, возможно это будет полезно в плане реализации нового протокола.

последний вопрос по шаблонам: как сделать так, чтобы любая перенастройка в шаблоне не вызывала перезапись кастомных настроек на подчинённых шаблону нодах?

поясню: ЕСЛИ есть шаблон А, который содержит DCI № 1, 2 и 3 и применён к нодам Б и В, и если я на ноде Б отключу DCI № 2 (мне на этой ноде Б именно ЭТОТ единичный DCI не нужен, вместо него я использую похожий, но немного изменённый, назначенный напрямую ноде), ТО ЕСЛИ я поменяю ЛЮБУЮ настройку в шаблоне А, этот Шаблон опять автоматически применится ко всем подчинённым нодам и ВКЛЮЧИТ отключенный мной DCI № 2 (чего мне совсем не нужно).

можно это как-то предотвратить?

ой.. да-да-да... точно.
моя невнимательность.

Возник такой вопрос: а как вывести отслеживаемую ноду из под действия Шаблона? Можно просто удалить ноду в контейнере Шаблона?

Я не вполне уверен что данный вопрос не поднимался уже ранее, однако поиск ничего не дал...

Предложение: я предлагаю ввести в NXMS наряду с возможностью мониторинга базовых служебных протоколов типа telnet, smtp, http, etc также и возможность мониторинга игровых серверов.

Суть: требуется уметь только одну вещь - стандартно как и для других протоколов (например, определение доступности веб или telnet-серверов) определять, жив ли игровой сервер.

Всё что для это нужно - уметь запрашивать сервер по заданному порту и разбираться, откликается ли сервер. Идеальный вариант - использование технологии, аналогичной определению живости веб-сервера (и наличия на полученной запрошенной странице нужных или нежелательных слов) и простого сравнения получаемого результата с эталоном.

Попытаюсь привести пример: (к сожалению, тут только поверхностный)

Игровой движок- Valve "Source"

инфо: http://developer.valvesoftware.com/wiki/Main_Page
SDK: http://developer.valvesoftware.com/wiki/SDK_Docs

Сервер (игра)- Team Fortress 2 (но данное решение подойдёт и для любой другой игры на данном движке)

DCI может выглядеть так:

Origin: NetXMS Agent
Data type: String

Data Parameter: в целом, как мне кажется, можно использовать схожую с HTTP но несколько видоизменённую схему

было: (ServiceCheck.HTTP(server_ip_address,port,uri,host_header,response))
стало: (ServiceCheck.SRCDS(server_ip_address,port,server_variable))
новый запрос: ServiceCheck.SRCDS(10.100.0.1,27015,hostname)

SRCDS - Source Dedicated Server
10.100.0.1,27015 - адрес и порт сервера
hostname - мы хотим получить от сервера содержание его переменной "hostname" (название сервера)

Соответственно, если сервер возвращает содержание переменной (нужно использовать трэшолды, содержащие имя сервера)- он жив и здоров.

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

ПС: ровно такой же подход можно практиковать при мониторинге абсолютно любого игрового сервера. Я ещё не видел на рынке систем мониторинга ВАШЕГО уровня таких систем, которые бы предоставляли возможность мониторинга игровых серверов "из коробки". Не хотите стать первыми? 

Готов предоставить информацию, разъяснения, полигон и всё прочее, нужное для тестов (www.megatron.ws).

да вроде всё стабилизировалось... а я сильно опасался что разрушится структура базы...
уфф... пронесло.

с грехом пополам машина с мониторингом и базой перезагрузилась.. сервис Core теперь после этого сбоя (я не стал откатываться) запускается минут 5-7. при этом все остальные сервисы системы (2008) курят.

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

всё. мой  мониторинг сдох.

придётся очевидно всё из бэкапов поднимать  .

мда. получается, что отказоустойчивости и проверки на целостность во время операций, связанных с перемещением объектов внутри базы NXMS (и если при этом происходит сбой) нет практически никакой... или я не прав?

может есть какая утилита для проверки целостности базы?

блин. после нескольких таких ошибок применения шаблонов закрыл консоль. запустил её заново и уже минут 10 вишу с сообщением "Synchronizing objects".

это не дело =(

update: вишу уже 1 час...

OMG Виктор, что делать?

мда. есть мысли как такой проблемы избежать?
только ставить мониторинг на более мощное железо?

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

Ситуация: если сервер нагружен, то возникают проблемы с применением шаблонов на объекты (нет уверенности что в таблицы вносятся все данные из шаблона).

В моём случае шаблон предельно прост - только одна простая запись (1 DCI).

После применения шаблона на объект (любую из нод) после минутного ожидания с окном "Applying template ..." получаем "Error applying template: request timed out."

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

Хотя всё пока выглядит вроде рабочим я не уверен что всё на самом деле хорошо... Вдруг где-то какое-то из полей в базе не перенеслось или не заполнилось нужными данными...?

Вот беда.. 

Not found =(

мда. вообще выяснилось что довольно непросто подобрать "правильные" мибы для NXMS...
90% им считаются (я думаю не безосновательно) ошибочными...

вот только жизни это никак не помогает.

может кто знает хороший онлайновый парсер-чекер-исправитель для мибов?

прошу простить за назойливость (вызвано производственной необходимостью), но ...

UP-UP

=)

вот спасибо! =)