NetXMS Support Forum

D-Link использует portIdSubtype 7 (local) - в NetXMS'e нет поддержки такого типа. Я никогда до сих пор не встречал устройств, которые использовали бы этот тип идентификатора порта. Попробую сейчас добавить поддержку. Пришлите еще пожалуйста результат SNMP WALK по .1.0.8802.1.1.2.1.3 .

А можно прислать результат SNMP WALK для .1.0.8802.1.1.2.1.4.1.1? Например такой командой:

nxsnmpwalk -v 2c -c <community> <ip_address> .1.0.8802.1.1.2.1.4.1.1

Hi!

Yes, you are right. When I read GetTimeZoneInformation description, I had thought that Bias field contains current bias, calculated accordingly to DST. I have fixed it already, next build will contain correct code. Thank you for digging it out!

Best regards,
Victor

Quote from: xatteg on August 02, 2012, 09:59:58 AM
One thing I also would like to have is when you change alarm status to "Resolved" the alarm highlights should be removed from devices.

Yes, I agree. Will be done in next release.

Best regards,
Victor

Hi!

You can define external parameter in agent. Add the following line to your nxagentd.conf:

ExternalParameter = Exchange.MessageCount:powershell -Command "& {Get-Queue -Sort-Order:-MessageCount -Result:1 | fl -Property MessageCount}"

Part before : is a name for new parameter, you can set it whatever you want.

Restart agent, do configuration poll on a node, and you should see new parameter in parameters oist and be able to collect it as any other agent's parameter.

Best regards,
Victor

Попробуйте сделать Topology Poll вручную на коммутаторах - что он покажет? Если LLDP включен недавно, то возможно еще не собралась информация.

Da, dolzen byt' s lmsensors.

Quote from: Jmp_3f8h on August 01, 2012, 01:17:39 PM
I forgot to mention that in this scenario the event source for the alarm should be the container and not a specific node. But I don't know if promoting a container to source for alamr has other side effects.

This can cause some side effects. For example, now you have $node variable in filtering scripts in event processing policy. If container and/or cluster objects can be event sources as well, you will have to check with what object class you are dealing with before accessing object properties for example. It will be quite complicated change, mostly because lot of places in the code will need to be checked.

Best regards,
Victor

But do you build agent with encryption enabled? I remember that on some stage of debugging you was rebuilding it without encryption.

Исправленный alarm viewer есть здесь: https://www.netxms.org/forum/general-support/alarm-browser-gt-netxms-console-fatal-error/msg7982/#msg7982. Alarm notifier посмотрю, там скорее всего таже самая проблема.

Can you show me screenshot of authentication properties in console for this node? nxget works fine with authentication, so server should also work.

Best regards,
Victor

Currently cluster objects works like a special kind of templates - DCIs defined on it applied to underlying nodes, exactly as from template. If cluster objects will also have active DCIs collected on it's own, it will somehow break current concept of node objects being only objects where data collection occurs. Also, there are cases when you don't have cluster object, but still need some common values - for example, total number of users connected to farm of terminal servers. Using one of the nodes is not very elegant and intuitive, as such values related to node group, not only one node. One possible solution would be to add data collection capabilities to container objects as well. Or, we can introduce some new object class for such DCIs. Another question is thresholds on such parameters - what object should be event source in case of threshold violation? I like to got to clear and elegant solution. Any thoughts?

Best regards,
Victor

Hi!

Just try to connect to agent via ssh port forwarding - it responds correctly. I see in your config that you turn on authentication on agent - but do you enter correct authentication parameters in node properties? Currently everything is correct in my test:


C:\Source\NetXMS\x64\debug>nxget -e 0 -p 4444 -a sha1 -s <secret> 127.0.0.1 Agent.Version
1.2.1


and on the agent:


[31-Jul-2012 19:16:26] Incoming connection from 127.0.0.1
[31-Jul-2012 19:16:26] Connection from 127.0.0.1 accepted
[31-Jul-2012 19:16:26] [session:0] Received control message CMD_GET_NXCP_CAPS
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_NXCP_CAPS (size 16)
[31-Jul-2012 19:16:26] [session:0] Received message CMD_AUTHENTICATE
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_REQUEST_COMPLETED (size 32)
[31-Jul-2012 19:16:26] [session:0] Received message CMD_KEEPALIVE
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_REQUEST_COMPLETED (size 32)
[31-Jul-2012 19:16:26] [session:0] Received message CMD_GET_PARAMETER
[31-Jul-2012 19:16:26] [session:0] Requesting parameter "Agent.Version"
[31-Jul-2012 19:16:26] [session:0] GetParameterValue(): result is 0 (SUCCESS)
[31-Jul-2012 19:16:26] [session:0] Sending message CMD_REQUEST_COMPLETED (size 56)
[31-Jul-2012 19:16:26] [session:0] Session with 127.0.0.1 closed


Best regards,
Victor

Да, это поле node_flags. Флаг "disable configuration poll" имеет значение 0x20000000. Сам SQL запрос будет зависеть от базы, насколько я понимаю стандарта на битовые операции в SQL нет.

As all previously stored values displayed correctly now, that means a bug on client side - either in client library or in management console itself. Can you check any other string DCIs if you have any?

Best regards,
Victor