NetXMS Support Forum

Currently odbcquery subagent uses SQLConnect call which does not support connection strings. I will try to add automatic detection if connection string is given instead of DSN name (probably by checking for presence of = characters) and use SQLDriverConnect in this case.

Best regards,
Victor

Can you please try to run agent in debug mode? To do so, change logging to a file by adding

LogFile = some_log_file

to agent's config, and run agent in foreground as

nxagentd -D 9

Best regards,
Victor

Could you please run server as a service with full debug (-D 9 command line option)?

Best regards,
Victor

Hi!

Sorry, I forgot about it Now I have added this as feature request to bugtracker (issue 309), and hopefully it will be included in 1.0.7 release.

Best regards,
Victor

Выложил релиз 1.0.6, где этот баг должен быть исправлен (в теории). Протестируйте пожалуйста когда будет возможность.

Hi!

There are documentation chapter about scripting language itself, and reference for all functions. However, writing transformation and filtering script are not covered. I'll try to add additional information on this topic to documentation.

Best regards,
Victor

Hi!

It's because all Disk.* parameters was renamed to FileSystem.* (but all agents still understand Disk.* form, although does not report it in a list of available parameters). However, I forget to rebuild x64 agent from new source - this is why it does not understand FileSystem.* parameters. Now Windows x64 agent version 1.1.0 is available for download, which provides same functionality as x86 version 1.0.6.

Best regards,
Victor

Hi all!

NetXMS version 1.0.6 is out. Changes since 1.0.5:

- Implemented adding existing nodes to cluster and removing nodes from cluster
- LogWatch subagent improved
- Fixed issues: #306, #307, #308

Best regards,
Victor

Hi!

It's a syntax error in agent configuration filtering script, for agent configuration record with ID 1. If you could provide your filtering script, I could tell what the error is.

Best regards,
Victor

Spasibo za dump, nashel esche odin deadlock. Budu dumat' kak ispravljat'...

You can create either unmanaged node or disable all polling protocols - it depends on how you wish to see node's status. For unmanaged node, it always be "unmanaged", regardless of active alarms. If you disable polling, node's status will be "unknown" unless there will be active alarms for that node - in that case node's status will change to severity of most critical alarm.

Best regards,
Victor

Hi!

Currently event forwarding has a lot of limitations. In order for incoming event to be processed on recipient server, two conditions must be met:

1. Event template with same event code or event name must exist on recipient server
2. Node object with same IP address as event's source node's address must exist on recipient server

Events not met these conditions are discarded.

You can try to turn on debug with level 5 or more - than you will be able to see if and why incoming events are discarded.

Best regards,
Victor

Этот параметр существует очень давно, просто его очень редко надо менять, только если внешние скрипты не укладываются по времени исполнения в тайм-аут по умолчанию. Он даже перечислен в User Manual'е в списке параметров агента, правда без особых комментариев по использованию

А сервер перезапустили после изменения параметра? Он читается только при старте. Еще я забыл про параметр агента ExecTimeout - время ожидания результата внешней программы. Он тоже по умолчанию 2 секунды. Попробуйте поставить

ExecTimeout = 5000

в nxagentd.conf.

Best regards,
Victor

Quote from: Alex on October 21, 2010, 12:03:40 PM
P.S.> Кстати, можно как-то сделать универсально, чтоб использовать данный вызов из темплейтов, а не прописывать руками на каждый хост? Типа PGW_Act_Calls(%host_ip%)

Можно. Если в темплейте указать макрос %{node_primary_ip}, то при наложении на хост вместо него будет подставлен IP адрес хоста. Все макросы описаны в мануале в разделе 5.3.6.

Best regards,
Victor