NetXMS Support Forum

Proveril - k sozaleniju nikakoj trassirovki tam net. A na kakoj sisteme agent? Ja sdelaju patch s debug soobschenijami chtobi mozno bilo ponjat' v chem problema.

Ja vilozil obnovlennij logwatch dlja testov - https://www.netxms.org/forum/index.php/topic,670.0.html. Teper' dolzen korrektno rabotat' na 2008.

Please try updated version attached here: https://www.netxms.org/forum/index.php/topic,670.0.html

Best regards,
Victor

Hi all!

Attached is updated logwatch subagent (for 32 bit Windows). All outstanding issues with Windows event log monitoring should be fixed - it should work with Security log and custom application logs, and Windows 2008 related problems should be fixed as well. I'll be very appreciated if someone test it on different platforms and logs. You can simply replace old logwatch.nsm in 0.2.26 agent with attached one.

Best regards,
Victor

Hi!

Probably it's currently better solution, but a bit inaccurate - status can change not only because node is down, but also if one of the interfaces goes down, or if you have active alarm for that node (as a result of threshold violation, for example). You at least should set threshold to "equals 4" instead of "greater than 0", because 4 is status code for CRITICAL status, so at least you will not send notification if node, for example, go to MINOR status due to an alarm.

You can also avoid false positives when node's status is CRITICAL, but it is not down, but in a quite complicated way. You can create situation (in View -> Situations), and update it on each NODE_DOWN and NODE_UP. For example, on NODE_DOWN set "down" attribute to 1, and on NODE_UP, set it to 0. Then, add additional check using script to notification rule, to check stat situation's attribute "down" is set to 1.

Best regards,
Victor

Hello!

It depends on log file and platform.

On UNIX, size of monitored file checked once per second. If size was changed, log parser reads and processes new data. If new size is less than previous, parser assumes that file was cleared, and reads it from the beginning.

On Windows, processing is different for text files and Windows event log. For text files, parser subscribes to file system change notifications (using FindFirstChangeNotification/FindNextChangeNotification API), and when change is detected, processes file in the same manner as on UNIX. For Windows event logs, parser opens them via Windows event log API and waits for changes. When new records added to the log, parser gets notified and processes new records. And starting from 0.2.27 release, parser uses different API for Windows Vista and Windows 2008 - this should solve various event log parsing problems on these systems.

Best regards,
Victor

Is there any error messages in NetXMS server log when it starts? It is possible that some other process already listen on UDP port 162, and in that case NetXMS server is unable to bind to socket and receive traps.

Best regards,
Victor

Hi!

It's a console crash, not server crash. I'll take a look at it.

Best regards,
Victor

Hello!

It's almost possible - all required components are in place, I just need to fix few bugs. You can create nodes without IP addresses (by entering address 0.0.0.0  in node creation dialog). You can create "proxied" DCIs - i.e. you can define SNMP DCI on node without IP address and specify that real SNMP request will go to some different node. The only problem is that due to a bug in status poller nodes without IP address considered as "unreachable", which disables data collection for them. I'll fix that till next release.

Best regards,
Victor

Hi!

Looks like server bug. What nodes as duplicated? For example, node with IP 40.16.1.2 - what it is, how it's interface list looks like? (You can send this info to [email protected] if you don't wish to disclose this information on forum).

Best regards,
Victor

Lines started with * character defines a new config section (usually subagent configuration) - and parameters allowed in each section are specific to this section. Core agent parameters should be defined in "default" section - unnamed section in the beginning of the file. Order within section is not important.

Best regards,
Victor

Thank you for excellent howto! I'll probably never manage to write so long text

Some comments and corrections:

Quote from: jdl on June 19, 2009, 05:17:54 PM
which by the way you will not find in the available list

You will, but only after next configuration poll for that node. To prevent sending request for supported parameters to agent each time you press "Select" button in console, server reads list of supported parameters during configuration poll (each hour by default) and caches it. You should either wait for next configuration poll or force immediate configuration poll from console using Poll -> Configuration menu.

Quote from: jdl on June 19, 2009, 05:17:54 PM
I did not try but I would suggest not to use any existing data collection name... Possible conflict or simply possible problem easy to avoid - play it safe and simple ;-)

In fact, you can use names of existing parameters - if you do, built-in parameter's handler will be replaced by your script. Normally, this should be avoided, but sometimes it may help - for example, if built-in implementation of certain parameter is buggy, and you are able to provide replacement script as workaround.

Best regards,
Victor

Hello!

In fact, we need completely different log readers for Windows Vista and 2008 - Microsoft changes event log API (see http://msdn.microsoft.com/en-us/library/aa964766(vs.85).aspx), and old API used by logwatch.nsm is not always compatible with new logs. I'll add support for new event log API in upcoming release.

Best regards,
Victor

Yes, it's a bug. Added it to bug tracker (#256).

Best regards,
Victor

Hello!

In theory, it should work. What you get - errors in agent's log, or just no events when records appear in log? What Windows version you are using? I have a lot of problem reports for Windows Server 2003, and there are known problems with Vista and Server 2008.

Best regards,
Victor