NetXMS Support Forum

Hi!

It's not necessary to create 4 rules in event processing policy - you could create only one rule for all DCIs, you just need to configure it right.  I suspect that maybe you made some mistake when configuring event processing rules, possibly you have created alarm key which is identical for all DCIs. Typical configuration for alarm generation include setting alarm key in a way that it will be unique for each DCI. For example, I prefer to use alarm key DC_%i_%5 - macro %i will be expanded into node object's id, and %5 into DCI id.

Best regards,
Victor

Very strange. Just try to compile this MIB with all others and got a lot of entries under .1.3.6.1.4.1.789. Attached is a screenshot from my MIB browser.
Just in case - try to find local copy of netxms.mib on your workstation and delete it - may be console due to some problem does not update it.

Best regards,
Victor

Hi!

Did you put resulting netxms.mib into correct place - should be d:\netxms\var\mibs in your case? By default, nxmibc creates output file in current directory. You should either move resulting file to correct location or use -o option for nxmibc. Also, don't forget to restart management console after MIB compilation - MIB tree synchronization with server occurs only at login.

Best regards,
Victor

Hi!

I've put new version of the console on web site. It should work with 1.0.4 server.

Best regards,
Victor

Hi!

Could you please provide more details - configuration of all 4 DCIs, how policy looks like, what actual values for DCIs?

Best regards,
Victor

Hi!

By default, hosts are pinged 4 times per minute (every 15 seconds). You can change this by adding PacketRate parameter to PING section. For example, configuration like this:

*PING
PacketRate = 12
Target = 137.133.31.15:NO_GW

will cause agent to ping targets every 5 seconds.

You can see all ping times by creating separate DCI for Icmp.LastPingTime parameter and collecting it with same intervals as ping rate. Then you will be able to see all ping times as values of this DCI.

Best regards,
Victor

Hi!

It depends on your configuration. For node objects, status calculated based on two sources - statuses of child objects (interfaces and network services), and active alarms for the node. So, if you, for example, have outstanding critical alarm, node status will be critical even if it is reachable by management server. Also, default status calculation algorithm takes most critical status of child objects, so if you have managed device with multiple interfaces, one interface in down state will cause critical status for entire device, although it is still reachable via other interfaces.
You can safely assume that critical status mean "node unreachable or down" only if you have configured system in that way. In default configuration this is not the case.

Best regards,
Victor

Hi all!

NetXMS version 1.0.4 is out. Changes since 1.0.3:

- Built-in syslog server improved
- Windows console improved
- Created separate installation package for Windows console
- Fixed issues: #282, #288, #296

Best regards,
Victor

Just test fresh installation and everything looks fine. I have installed NetXMS into /opt/netxms, run nxhttpd with your config, and got normal login page. Debug output also looks fine:


debian:/# /opt/netxms/bin/nxhttpd -c /etc/nxhttpd.conf -D
[30-Jul-2010 01:09:19] Debug: Session watchdog thread started
[30-Jul-2010 01:09:19] NetXMS Web Interface Server started
NXHTTPD running. Press Ctrl+C to shutdown.
[30-Jul-2010 01:09:19] Listening on socket 0.0.0.0:8080
[30-Jul-2010 01:09:30] Debug: [302] GET /
[30-Jul-2010 01:09:30] Debug: [200] GET /login.app
[30-Jul-2010 01:09:30] Debug: [200] GET /xmlextras.js
[30-Jul-2010 01:09:30] Debug: [200] GET /netxms.css
[30-Jul-2010 01:09:30] Debug: [200] GET /common.js
[30-Jul-2010 01:09:30] Debug: [200] GET /images/login.png
[30-Jul-2010 01:09:30] Debug: [200] GET /images/buttons/normal/login.png
[30-Jul-2010 01:09:30] Debug: [404] GET /favicon.ico


What browser you are using? Could you try to connect with another browser? Also, what you get if you try to access any image file directly, using URL like http://your_server:8080/images/login.png ?

Best regards,
Victor

Hi!

It means that event configured in threshold will be generated as soon as monitored value will be 0 or greater than 0.

Best regards,
Victor

First of all, you have to specify full path, not just Temp. Second, you have syntax errors in recursion and size parameters - you should use only digits here. So, parameter should looks like

File.Count('C:\Temp', 'SAS*.txt', 1, 0, 90)

to count number of files older than 90 seconds.

Then, threshold by itself looks correct, but did you create appropriate rule in event processing policy?

Also, take a look at this step-by-step configuration example: https://www.netxms.org/documentation/confexample/. It's quite old, and screens  will look a bit different, but you should get an idea.

Best regards,
Victor

Вроде разобрался. Источник проблем - именно неправильный парсинг имени хоста. Сервер пытается связать сообщение с объектом узла по имени, и не находит сооответствующий узел, поскольку имя хоста неправильное. На днях выйдет версия 1.0.4, там будут исправления.

Hi!

Database format has not been changed between 1.0.2 and 1.0.3, and so there was no changes in nxdbmgr. It was not supposed to be that way, nxdbmgr just was not rebuilt with new version string. It's inconvenient, but it does not affect operations of NetXMS server in any way.

Best regards,
Victor

Hi!

Most likely there are router/host which was discovered first by NetXMS and it reporting network mask 255.255.255.0. Because NetXMS server cannot really know who has correct netmask and who not, it assumes that first discovered node connected to some subnet has correct netmask for that subnet. There also possibility that you have incorrectly created subnet object for some reason. How object(s) for subnet in question looks like?

Best regards,
Victor

Hi!

It's quite strange. What files do you have under /opt/netxms/share/netxms/nxhttpd?

Best regards,
Victor