NetXMS Support Forum

V attache fail exec.cpp - im nado zamenit' suschestvujuschij v src/agent/core/ i peresobrat' agenta. Potom zapustit' agenta s kljuchom -D i zaprosit' parametr - dolzen bit' debug po ispolneniju external parametra.

Event object (represented by $event variable) has the following attributes:

code	Event code
id	Event ID
severity	Severity code (0=Normal 1=Warning 2=Minor 3=Major 4=Critical)
timestamp	Timestamp as number of seconds since 1 Jan 1970 00:00:00 UTC
message	Message text
customMessage	Custom message text (added in 0.2.27)
userTag	User tag
parameters	Event parameters (this property is an array with first element started at 1)

Also, starting from version 0.2.27 you can access node's custom attributes directly via object referenced by $node variable, if attribute's name conforms to NXSL identifier naming restrictions (contains only letters, digits, underscore and dollar sign, and not starts with digit). For example, if you define custom attribute terminalId, you can access it in script as following:


$node->terminalId


Best regards,
Victor

Hi!

It's a bug. Fortunately it's easy to fix, I'll do it till release.

Best regards,
Victor

Hello!

You cannot pass parameters to actions directly in event processing policy. However, you can use macros in defined actions - this can cover basic things like host name, event message text, severity, and so on easily. You can also use node's custom attributes (via %{..} macro). And for event more complicated things, you can call NXSL script when expanding macros in actions (via %[..] macro). When called, this script has access to node and event information via $node and $event global variables. You can also set global variable CUSTOM_MESSAGE in event matching script and later insert this value into alarms or actions via %M macro.


Little example of using scripts

Goal: send e-mail to different people depending on node's domain name.

Steps:

1. create e-mail action as usual, in recipient address field enter %[SelectEmail]
2. create script in script library, named SelectEmail:


sub main()
{
   if (right($node->name, 11) == ".domain.com")
      return "[email protected]";
   if (right($node->name, 12) == ".domain2.com")
      return "[email protected]";
   return "[email protected]";
}


3. in event processing policy, use defined action as usual

Best regards,
Victor

Hello!

Could you please post a screenshot of subagents' list output?

Best regards,
Victor

Dolzen risovat'sja kak area, no odin nad drugim. No ne realizovano poka.

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