NetXMS Support Forum

Hi!

Currently there are no other solution then to run nxdbmgr before starting netxmsd. You can simplify it by adding -e command line argument to netxmsd - then netxmsd will call nxdbmgr on startup. I've created a feature request to address this problem more correctly: https://www.radensolutions.com/chiliproject/issues/185. I will add additional command line argument to specify peer IP address - then if database locked by peer, server will check if it's alive, and if not, will automatically remove the lock.

Best regards,
Victor

Hi!

For showing text instead of code in events and alarms, you can use script in script library and macro like %[script_name]. For example, if you have some code as parameter number 5 in trap-generated event, you can create script called CodeToText in library:


switch($5)
{
   case 1: return "CODE 1";
   case 2: return "CODE 2";
   // and so on...
   default: return "Unknown code " . $5;
}


and then use

%[CodeToText]

in event and alarm message template.

Best regards,
Victor

Hi!

In general I agree that action groups could be useful. Added this to bug tracker: https://www.radensolutions.com/chiliproject/issues/184. Currently you can create notification groups by creating one action for e-mail or SMS notification and giving multiple recipients separated by semicolon.

Best regards,
Victor

Yes, exactly.

Alarm severity may or may not be of same severity as originating event. When you create alarm from event in event processing policy, you have an option to set same severity as in event or any other fixed severity.

Best regards,
Victor

Hi!

One possible way to implement MTBF calculation could be following:

1. Assume that you have two events, one for downtime start and one for downtime end.
2. We will use the following custom attributes for each node:

mtbf
mtbfTotalUptime
mtbfNumFailures
mtbfTimeUp

3. On downtime end, run the following script:


SetCustomAttribute($node, "mtbfTimeUp", time());


4. On downtime start, run the following script:


uptime = time() - GetCustomAttribute($node, "mtbfTimeUp");
mtbfNumFailures = GetCustomAttribute($node, "mtbfNumFailures");
if (mtbfNumFailures == null)
   mtbfNumFailures = 0;
mtbfNumFailures++;
mtbfTotalUptime = GetCustomAttribute($node, "mtbfTotalUptime");
if (mtbfTotalUptime == null)
   mtbfTotalUptime = 0;
mtbfTotalUptime += uptime;
mtbf = mtbfTotalUptime / mtbfNumFailures;
SetCustomAttribute($node, "mtbfNumFailures", mtbfNumFailures);
SetCustomAttribute($node, "mtbfTotalUptime", mtbfTotalUptime);
SetCustomAttribute($node, "mtbf", mtbf);


After this script execution, custom attribute "mtbf" will contain MTBF in seconds.

5. If you want to see current MTBF value as DCI for the node, you can create DCI with source "Internal" and name "Dummy", and use the following transformation script:


return GetCustomAttribute($node, "mtbf");


MTTR can be calculated in similar way.

Best regards,
Victor

Hi!

There are few different ways to achieve required functionality. First is to create alarm message texts and keys based on subcomponent. Let's assume that you have mapped subcomponend identifier to parameter number 2 of your event. Then you can create alarms with key like DEVICETRAP_%i_%2 . With such key, events related to different subcomponents will create separate alarms, and events related to subcomponent with already active alarm will replace existing alarm's text, severity, etc. and update repeat count. Creating alarms of different severity is abit more tricky - you will need separate rule for each severity. Rules have to be identical except filtering script which should check severity in the trap. For example, if you have mapped severity to event's parameter number 3, and it is text string like "minor", "major", etc., you can use filtering scripts like this:


return $3 == "minor";


or simply


$3 == "minor"

(note the absence of the semicolon in last case).

Another possible way is to create single rule in event processing policy that will call NXSL script for trap-based event and stop processing, and in that script create different new event based on trap parameters (using PostEvent function).

And the hardcore way is to create server module that will process traps and do whatever needed - generate events, update object attributes, etc.

Best regards,
Victor

Hi!

I try to reproduce this issue, but everything is working on my test system. How do you run agent? Did you try to run it from command line in foreground?

Best regards,
Victor

Hi!

You can achieve this by storing timestamp of node down event and checking it on node up. You can use custom attributes and scripting for this. For example, you can create the following script in script library, named "OnNodeDown" for example:


SetCustomAttribute($node, "nodeDownTimestamp", time());


then create action "execute script" to execute "OnNodeDown" script, and add it in event processing policy to the rule processing SYS_NODE_DOWN event.

Then create separate rule for sending e-mails on SYS_NODE_UP, with additional filtering script like this:


t = GetCustomAttribute($node, "nodeDownTimestamp");
interval = time() - t;   // get interval in seconds between down and up events
return (interval >= 300);


With this filtering script, only SYS_NODE_UP events happens 5 or more minutes later then SYS_NODE_DOWN event will pass the filter.

More information about scripting you can found here: http://wiki.netxms.org/wiki/Scripting_Guide.

Best regards,
Victor

Hi!

Yes, server keep entire object tree in memory, and all status calculations done in memory. Objects with changed statuses are marked as modified, and later saved to database by background sync thread. We also actively use queues for processing, so you can experience a slight delay in trap processing for example, but they will not be lost and will be processed in correct order.

Best regards,
Victor

Hi!

Check that NetXMS Core service is running. If not, check event log for error messages. You can also try to run server in foreground to see why it can't start by running

netxmsd -D 9

from command line.

Best regards,
Victor

Hi!

It all depends on how often you change and access attributes. NetXMS server caches lot of things, including custom attributes. For example, when you cange custom attribute from the driver, it will not change database immediately, but just mark object as modified. Background sync thread writes changes from objects to database periodically (once per minute by default). Reading custom attributes never involve database access - they read from memory. Drawback of this is of course increased memory usage. Custom attributes stored as strings, so it's not very effective when you have numeric data.

I would go with custom attributes. I also see couple of simple changes to allow easier creation of complicated drivers: we can add "driver data" field to Node object (simple pointer to void) where driver will be able to store it's data in any convenient format, and two additional calls in the driver - saveToDatabase and loadFromDatabase - to be called on node object saving and loading to allow save and restore of driver specific data.

Best regards,
Victor

Да, это правильный метод. На Jave я бы использовал instanceof Subnet вместо сравнения getObjectClassName(), не знаю, можно ли в Groovy так делать.

Hi!

I've created an issue in the bug tracker: https://www.radensolutions.com/chiliproject/issues/180.

Best regards,
Victor

Hi!

Status for policy object is irrelevant. It's a bug in the server that it remains unknown, it should be normal. But anyway it doesn't indicate anything.

Best regards,
Victor