NetXMS Support Forum

Hi!

It's a known bug - parameters LogWatch.Parser.* are not working. However, you don't need them to do log monitoring - it's just a parser statistics.

What about PING subagent - do you still have problems mentioned in your previous post?

Best regards,
Victor

Hi all!

Nearly six years ago I started NetXMS as my hobby open-source project. Then I found that quite a few people actualy use it and like it. This gave me a good reason not to stop. Few other guys have joined me and we continued development with increased efforts and passion - because we knew we do something really cool. Few years later I found myself having two fulltime jobs - my day job, and NetXMS. Couple months ago I realized that one of the jobs must go, so now NetXMS is my day job. I've set up a company - Raden Solutions - which is supposed (among few other things) to handle NetXMS commercial support and training activities. I hope that this will allow me to spent more time and resources on NetXMS development, resulting in better product with faster development cycle. And if by any chance you need "official" NetXMS support or training - you know where to look  

Company web site: http://www.radensolutions.com

Best regards,
Victor

Yes, you right - alarm message is unavailable within script. For the next version, I add new global variable $alarmMessage which will hold alarm's text. It's not part of event object (it's only created based on event data), so it will be incorrect and technically slightly harder to put it as $event attribute.

Currently you able to pass alarm message to action via %A macro - this can help if you don't need it in script.

Quote from: jdl on June 30, 2009, 04:28:15 PM
In the script, the $event->message refers to the text message defined in the event not in the alarm which can be more specific as we get additional macro's at that level, right?

You have only two additional macros at alarm definition level - %m (event's message text) and %M (custom message, if set in matching script). All other macros are the same (including scripts and custom node attributes).

Best regards,
Victor

Server should not crash - it's a bug. But anyway, when script returns something to be used as macro expansion result, it should be string.

Best regards,
Victor

Hello!

Quote from: jdl on June 30, 2009, 11:21:04 AM
- Any possible way to insert comments? Using for example # as in Perl...

Yes. Comments is like in C or Java - i.e. you can have multiline comments enclosed in /* */, and comments till end of line started from //.

Quote from: jdl on June 30, 2009, 11:21:04 AM
- Is the operator ~= similar to the one in Perl? I.e. calling for regular expression?

Yes, it's calling regular expression specified at right on left operand, and result is true (1) if operand matches regexp, and false (0) otherwise. But unlike perl, you should specify regular expression as string, not inside // characters.

Quote from: jdl on June 30, 2009, 11:21:04 AM
As far as reg.ex. are concerned, is the syntax the same?
If for example, I need a script parsing a message text to return different elements and use them to defined return argument(s)...
Message test is "TCP Socket is open on host xyz.domain.com (172.16.0.1) using port 3333" and my regular expression is:
$event->message ~= "^TCP Socket is (.*) on host (.*) \((.*)\) using port (\d)$"

Syntax is not completely the same - NXSL uses POSIX extended regular expressions (http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions), and as far as I know Perl, there are some differences. Your example expression for NXSL should looks like

$event->message ~= "^TCP Socket is (.*) on host (.*) \((.*)\) using port ([0-9]+)$"

Quote from: jdl on June 30, 2009, 11:21:04 AM
How can I put the matched info in different variables: $status, $host, $ipaddr and $port?
How do you define those variables?

Similar to Perl, NXSL places matched parts enclosed in brackets into variables $1, $2, and so on. If you wish to place these results into your own variables, you have to assign them after match. Please note that  variable should not start with $ sign, it's often used as indicator of system/special variable. You may or may not use $ sign in your variables. Variables declared implicitly on first use. For example, to assign status, host, ipaddr and port variables on successful match, code can looks like this:


if ($event->message ~= "^TCP Socket is (.*) on host (.*) \((.*)\) using port ([0-9]+)$")
{
   status = $1;
   host = $2;
   ipaddr = $3;
   port = $4;
}


Quote from: jdl on June 30, 2009, 11:21:04 AM
What about functions in script?

You can define as many functions as you wish. Functions defined with sub keyword. For example:


/* script entry point */
sub main()
{
   // Call functions
   result = my_function_1();
   result2 = my_function_2(1, 2);
   println "result1=" . result . " result2=" . result2;
}

/* additional function */
sub my_function()
{
   return 1;
}

/* function with parameters */
sub my_function_2(param1, param2)
{
   return param1 + param2;
}


Function order within script is not important.

Quote from: jdl on June 30, 2009, 11:21:04 AM
How do we return an array as argument?
Is syntax return ($val_1, $val_2); correct?
Will this array be returned as an array?

To return an array, you should explicitly create it with array operator, assign array's elements, and return it. For example:


sub fx()
{
   array a;  // Create empty array and store reference to it in variable a
   a[1] = "value1";
   a[2] = "value2";
   return a;   // return reference to array
}

sub main()
{
   x = fx();  // get array result from function
   println "second element is " . x[2];
}


Quote from: jdl on June 30, 2009, 11:21:04 AM
Would you have a complex example to post that would illustrate as many things as possible about defining NXSL script?

We don't have one, but looks like it worth creating one I'll do this later.

Best regards,
Victor

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