The only possible initialization of array is like

monitornodes[1] = "system-1";
monitornodes[2] = "system-2";
monitornodes[2] = "system-3";

I like the idea of having array initializers, I will add it to NXSL. Also, your script has an error if for loop condition - it should be monitornodes[i] != NULL, not monitornodes != NULL. So, correct version of the script should looks like this:

array monitornodes;

monitornodes[1] = "system-1";
monitornodes[2] = "system-2";
monitornodes[2] = "system-3";

summary=0;
for (i=1; monitornodes[i] != NULL ; i++)
{
  inode = FindNodeObject($node, monitornodes[i]);
  ivalue = GetDCIValue(inode, FindDCIByDescription(inode, "TotalAuth"));
  summary += ivalue;
}

return summary;

Best regards,
Victor

I see array initialization is not been supported as above syntax. However I get success with below syntax
array monitornodes;
monitornodes[1] = "system-1";
monitornodes[2] = "system-2";
monitornodes[2] = "system-3";

My point of asking is primary about array initialization syntax.

Yes, it must be named "Dummy". This is what I wrote in my previous message:

@victor said in Clustering with SNMP Proxy:

You can create additional DCI with source "Internal" and name "Dummy" (of course description can be any).

My mistake to overlook that "Quotation"  though "Quotation" is my practice as well.

@victor said in Clustering with SNMP Proxy:

So it is not a "workaround", it's just correct system configuration

I'm indded sorry for that unusual term. However I's not only pointing about this "Dummy" problem. I've co-related all my experience with NetXMS, like Cluster node disapper, OS hang without n/w, etc. For this "Dummy", if you cannot allow any other name then can't it make some select-only/drop-down type input there?

Finally Yes, this thread can be closed but this has something to go into Mantis

@victor said in Clustering with SNMP Proxy:

You can create additional DCI with source "Internal" and name "Dummy" (of course description can be any).

You can change description of the DCI, but not the name. Description is a free form text intended to be read and understand by humans, but name is a parameter's identifier understandable by server and/or agents. "Internal" origin means that values for these parameters generated by NetXMS serer itself, without asking any external entities. One of supported internal parameters is named "Dummy", and it always returns 0 when polled for value. It was added specifically for providing "ticks" for calculated DCIs.

So it is not a "workaround", it's just correct system configuration

Best regards,
Victor

After posting, I let "Parameter" name to be remained "Dummy". Now I see I can get proper values automatically by schedule. Cheers.

On another nodes: I followed your instruction about "Cluster node disapper" with patch. Now my nodes remains after restart.

I hope you have enough BUG registrar generate. Though all of my problems got resolved by workarounds

Best regards,
Victor

About all other problems I think that databases changes takes very long time to get reflected into other modules/components. I request you to check commit type of activity at some configuration change activity. I suspect same could be causing database curruption while shutdown!!!

Dear Victor, The script you shared did not worked. I tried to "Test" above transformation with Test value = 2(random), I get error "Error 14 in line 2: Left argument of -> must be a reference to object". I further added a check
 if (node2 == null)
      return 0;   // No such node or access denied

and surprisingly I get this "0" returned. Please note that my nodes are part of cluster. Is that could be limitation?

Did you set trusted nodes as described here: https://www.netxms.org/forum/configuration/nxsl-and-dci/msg4633/#msg4633? Most likely it's an access control issue.

@sumit-pandya said in Clustering with SNMP Proxy:

Using the approach you suggest, I may loose information of my one node. I just wonder if you can have some push method from scripting. Can I create a dummy node, define data collection with origion "Push Agent". Then define a schedule to run every minute "1 * * * *". Finally do something like below into Transformation?

node1 = FindNodeObject($node, "system-1");
value1 = GetDCIValue(node1, FindDCIByDescription(node1, "Auth-Req"));
node2 = FindNodeObject($node, "system-2");
value2 = GetDCIValue(node2, FindDCIByDescription(node2, "Auth-Req"));
return value1 + value2;

I'd even fine if database triger level of twick can be done as some very advance level.

You can create additional DCI with source "Internal" and name "Dummy" (of course description can be any). It will always have value of 0, and you can schedule it like any other DCI and use transformation script to get values from two "real" DCIs and sum them.

Best regards,
Victor

and surprisingly I get this "0" returned. Please note that my nodes are part of cluster. Is that could be limitation?

Using the approach you suggest, I may loose information of my one node. I just wonder if you can have some push method from scripting. Can I create a dummy node, define data collection with origion "Push Agent". Then define a schedule to run every minute "1 * * * *". Finally do something like below into Transformation?

node1 = FindNodeObject($node, "system-1");
value1 = GetDCIValue(node1, FindDCIByDescription(node1, "Auth-Req"));
node2 = FindNodeObject($node, "system-2");
value2 = GetDCIValue(node2, FindDCIByDescription(node2, "Auth-Req"));
return value1 + value2;

I'd even fine if database triger level of twick can be done as some very advance level.

You can use transformation scripts to get values from different nodes and sum them up to value of current DCI. For example, if you have DCIs named "Param1" on nodes node1 and node2, you can create the following transformation script on node1 to add up value from node2:

node2 = FindNodeObject($node, "node2");
value = GetDCIValue(node2, FindDCIByDescription(node2, "Param1"));
return $1 + value;

See also the following topics:
https://www.netxms.org/forum/configuration/findnodeobject-not-working-(for-me)/
https://www.netxms.org/forum/configuration/nxsl-and-dci/

Please also note that if you are using server older than 1.0.8, you must explicitly define main function in your script, i.e.

sub main()
{
   node2 = FindNodeObject($node, "node2");
   value = GetDCIValue(node2, FindDCIByDescription(node2, "Param1"));
   return $1 + value;
}

Best regards,
Victor

During configuration poll, NetXMS server tries to detect SNMP agent by sending requests for OID .1.3.6.1.2.1.1.2.0. If agent present, but does not respond to this request, it is considered as unavailable. Later during data collection, if node is not marked as SNMP-capable, SNMP DCIs not collected - the only exception is DCIs with custom SNMP ports. If you SNMP agent which does not support standard MIB-2 OIDs, then better way is to disable SNMP for given node and set port number explicitly for each SNMP DCI.

SNMP requests to port 260 generated during configuration poll in attempt to detect Check Point SNMP agent.

Best regards,
Victor

Victor, for your kind attention I'd like to see a graph with combined (sum) value from 2 (or more) similar nodes. As you know I've 2 machines running same software and there is a load-balancer. There is no "official" clustering but it can be seen as server-farm. Please guide me how to achieve that?

I plan 1.0.8 to be mostly a bugfix release (plus custom SNMP port feature), and if everything will go as expected, I'll will release it in a week.

Best regards,
Victor

I'll try to implement it in 1.0.8 release.

Victor, When 1.0.8 will be made available with SNMP port option? Without that I cannot use NextXMS at all. I'm quite eager to monitor our software with NetXMS and I've to prepare my team as end user as well.
Thanks for your kind consideration.

Hi!

Am I understand your correctly - you have one three-node cluster, and each node has two SNMP agents?

Right now the only working solution I could imagine is to configure lot of external parameters on agent which will call nxsnmpget - but this cannot be considered as good solution. I think that easiest way is to allow change of SNMP port on node and DCI basis - this is relatively easy change and will solve this problem. I'll try to implement it in 1.0.8 release.

Best regards,
Victor

Yes you have rightly understtod my setup. Further I'm sure that having each SNMP-OID/DCI basis port is eagerly awaited by many of NetXMS users. Parallelly please look into possible BUG of "not using configured community-name while communicating with SNMP-Proxy".

Am I understand your correctly - you have one three-node cluster, and each node has two SNMP agents?

Right now the only working solution I could imagine is to configure lot of external parameters on agent which will call nxsnmpget - but this cannot be considered as good solution. I think that easiest way is to allow change of SNMP port on node and DCI basis - this is relatively easy change and will solve this problem. I'll try to implement it in 1.0.8 release.

Best regards,
Victor