NetXMS Support Forum

I have set the key on a bunch of alarms to be %n_%4 which in theory means a trap==>event==>Alarm should increase the count when the same trap from the same node comes in. For one particular message I get, it is not working - I get a new alarm every time. 

The value of %4 is 247 chars as per below.
Warning [21/06/2019 BT2 3, 21/06/2019 BT6 3, 21/06/2019 BT6 12, 21/06/2019 BT7 5] - Failed to retrieve image: 'RISA Harness image /8557', exception: The remote server returned an error: (550) File unavailable (e.g., file not found, no access).

I have tried different variations at the start of the key of which I can see that, every time, the value in the KEY field gets truncated every time to 256 chars - and count does not go up.

It would not be so bad if the truncated field key was compared as that would be enough to match - but for some reason, it is not.

I exported the keys from Alarm Log view into a csv - pasted them into notepad ++ - ran compare - both keys were the same.

We hit that a while ago, but technically just increasing the allowed size of the key wouldn't solve the problem. At some point someone would end up wanting a 1024 character key. Or 65000. So that's probably more of a documentation issue.
Our solution was to create a hash instead of passing a long message along as a key.
So in your case, instead of using %4 as is you would use a script to return the value of sha1(%4).

OK - at least I understood the problem is real..
As for sha1 hash - shame there is no script option for hash like there is for file watching.
https://www.netxms.org/documentation/adminguide/appendix.html

Were you able to do it using straight netxms scripting or did you have to resort to invoking something external to NetXMS?

We use event processing policies to process the event, run the event through the filter script which uses sha1() on the relevant data/variable to get a hash and pass it to the CUSTOM_MESSAGE variable, which can be referenced as %M as part of the alarm key.

I have had one shot at Event Processing Policy filtering scripts but without an example, I syntactically sucked - so decided to look into that later.

Tried something rocket science based as follows - varbind in 3rd parm is severity so do not want alarms created where severity  = 3.
if $2 !=  3 return;

As for this problem,
I concur that this is the logical place to trigger the transform, and using custom_message makes sense, just need to work out the sha1.

Doco pages are all blank for sha1 sha256 and md5.
https://wiki.netxms.org/index.php?title=NXSL_Function_Reference&mobileaction=toggle_view_desktop

The other option if getting this to work takes too much time is to do similar via the left option and set custom message to be left (%4,255)
https://wiki.netxms.org/wiki/NXSL:left

The below example is not related to your specific issue. It is just an example of using Hashes as part of alert keys (in this case related to our StorageCraft ImageManager Windows Event Log monitoring, so not SNMP Traps). The actual processing policy is a bit of a catch-all for a lot of events, so we have logic in there to to identify the event source, etc.

Some notes for this specific example:
parameters[1] is the full path of the backup file
parameters[2] is the event source
parameters[3] is the event ID.
d2x is to convert the decimal node ID into a hex. That's done to build a matching alarm key, as the key is making use of the %i macro (which is the node ID in hex).
The hash function is used to convert the file name into a short hash value. To ensure there's no other random alarm that might reference exactly the same filename, I'm adding a pre-defined text ("ImageManager Consolidation"), so this hash will be unique to those types of alerts with that file name.

// ImageManager Alerts [for 1-parameter event log entries]
if ( $event->parameters[2] == "StorageCraft ImageManager" ) {
// Event Description: ImageManager Successful Consolidation
if ( $event->parameters[3] == "1120" ) {
consolidatedFile = $event->parameters[1];
// Checking if a matching alarm exists.
alarmHash=sha1("ImageManager Consolidation".consolidatedFile);
alarmKey="EVENTLOG_0x".d2x($node->id,8)."_".alarmHash;
if ( FindAlarmByKey(alarmKey) == null ) {
// No standard alarm exists, checking for alarms against SPF Consolidation failures.
consolidatedFile ~= "(.*-b[0-9]+)-i[0-9]+.*.spi";
alarmHashSPF=sha1("ImageManager Consolidation".$1);
alarmKey="EVENTLOG_0x".d2x($node->id,8)."_".alarmHashSPF;
if ( FindAlarmByKey(alarmKey) == null ) {
// No alarm found at all. We'll log this as a standard message and do not trigger any action.
$event->setMessage("ImageManager Consolidation Successful. Filename: ".consolidatedFile);
return false;
} else {
// A Consolidation alert referencing an SPF file was found and should be terminated.
$event->setMessage("\"ImageManager - Consolidation - Status\" is in state \"NORMAL\" - (".eventMessage.")");
CUSTOM_MESSAGE=alarmHashSPF;
return true;
}
The above is taken from a policy that terminates alarms. It is also not the complete code. But it should give you an idea how this can work.
The Alarms terminated have the following key:
EVENTLOG_%i_%M
%M is the macro for the CUSTOM_MESSAGE variable set in the filtering script.

If you return false, the alarm termination/actions won't be triggered.
If you return true, they are.

For the sake of usage of sha1(), it's really that simple: return sha1('string'); will return the sha1 hash of that string. Same with the other two hash functions.

Fantastic reply and explanation. Too late in the day to try today - adding EC2 node fun instead - so will try this Monday.

Got distracted - Event Processing has inspired me to get Create_Help_Desk_Ticket going first - much greater payback !!.

To implement this, in its most rudimentary form, the following looks like it would work:


// Hash the 4th parameter into a less than 256 char size as it is too long for duplicate comparison which fails to match duplicates
// To use, $4 is the parameter that is to be shrunk and the alarm key is %n_%1_%M - the %M is the shortened %4
// This code is added to Actions and the action is added in Event Processing Policy

alarmhash=sha1($4);

CUSTOM_MESSAGE = alarmhash;