NetXMS Support Forum

Hi!

can you please provide full valgrind log (assuming there are more records then you post already)? Those errors logged looks like consequences of some memory corruption that happened before.

Best regards,
Victor

Yes, actually actions in object tools does not support parameters. Entire string interpreted as action name. I'll register this as a bug.

Best regards,
Victor

Additional subnets can be visible if you have nodes with interfaces in both allowed and disallowed subnets. NetXMS will create subnet object for each interface. It is not related to network discovery - same rules work when you add nodes manually. If you absolutely dislike those subnets, you can create configuration poll hook script that will remove unwanted subnet objects right after creation.

Best regards,
Victor

Чтобы удалить все узлы и собранные данные, надо:

1. Удалить все таблицы с названиями, начинающимися на idata_ и tdata_.

2. Очистить таблицы:

nodes
subnets
interfaces
nsmap
object_custom_attributes
network_services
dct_node_map
trusted_nodes
items
dc_tables
dc_table_columns
dct_column_names
dct_thresholds
dct_threshold_conditions
dci_schedules
raw_dci_values
event_log
thresholds
alarms
alarm_notes
alarm_events
syslog
snmp_trap_log

Возможно еще некоторые таблицы, зависит от того, какие типы объектов использовались. После этого надо запустить проверку базы:

nxdbmgr check

Но самое надежное это пересоздать базу, сделав предварительно экспорт шаблонов и правил, а затем импорт в чистую базу.

Во всех трех дампах исполнялся код, связанный с обновлением списка алармов. Насколько много активных алармов и как часто они меняются?

Maybe idea to match messages based on hostname field was initially wrong and we should just revert to matching by source IP (or at least give IP based matching higher priority)?

Best regards,
Victor

Hi,

can you please show how rule number 37 in event processing policy looks like?

Best regards,
Victor

Hi!

you mean that you've found some specific place in added code which caused this crash?

Best regards,
Victor

Hi,

I've found a problem, although I cannot understand what caused it yet. From the log it looks like there are some alarm(s) with invalid severity code (255), and some UI parts cannot handle it correctly. Could you please post results of the following SQL queries:

SELECT alarm_id,original_severity,current_severity FROM alarms WHERE alarm_state<>3;

SELECT rule_id,alarm_severity FROM event_policy;

Best regards,
Victor

Hi,

can you please run netxmsd under gdb and post backtrace after crash? Here is the instruction: http://wiki.netxms.org/wiki/Running_NetXMS_under_debugger

Best regards,
Victor

Hi,

I cannot reproduce this. Can you please send me console log (usually %HOME%\.nxmc\data\.metadata\.log)? Do you have this problem on all consoles or only on one?

Best regards,
Victor

Currently you cannot change node status directly - if it is down, it will be critical. You can increase value of "poll count for status change" to 10 - then system will consider node as down only after 10 unsuccessful polls. Then you can setup ping to the node and trigger alarm of lesser severity after first ping loss.

Best regards,
Victor

Пока единственный вариант наверное - это делать новый объект (узел) на каждое такое устройство. Кстати в следующем реолизе появится возможность менять статус таких устройств - например выставлять статус неуправляемого коммутатора на основе статуса порта управляемого коммутатора.

Hi,

probably using proxy agents is best solution for you. All you need is to open port 4700 for connection from NetXMS server to just one server with agent. You can turn on encryption and authentication for security. All devices and servers could then be monitored via this single proxy. You may also need to enable zoning and setup separate zone for each remote site - it may simplify proxy configuration (as you can define default proxy settings on zone level) and is required if remote networks have overlapped IP addresses.

Best regards,
Victor

Yes, seems that it was forgotten. I've created issue in bug tracker (https://www.radensolutions.com/chiliproject/issues/641). As for #4, it will be in 2.0 branch, probably close to year end.

Best regards,
Victor