Action to return value

[victor]

Hello!

Unfortunatelly, answers to all questions is "no". However, they all looks useful, so I will add them to feature request list.

Best regards,
Victor

[borislavl]

Hi Victor,

Thank you for your dedication to NetXMS - it is really cool and useful.

Please don't underestimate your product  :).
Regarding my question 2 - I really needed to close the cycle in receiving data > event > action > receiving data. So tricking around with the Linux commands and the NetXMS shell commands I had success in case of event -> action > to receive data, using as action (in nxagentd.conf) the following:

ActionShellExec = Check_A1_A2_Agent_Status:/opt/netxms/bin/nxpush 192.168.1.10 -u pushuser -P pushpass  A1.test.com:A1_A2_Agent_Status=`/opt/netxms/bin/nxget 192.168.1.12 Agent.Uptime`

#These are 2 commands in 1 line - checking if the agent on A1 has connection with A2 in case that A3 (192.168.1.10) does not have direct connection with A2 and returns the response to a Push DCI (based on which we can generate other events and actions)

What I'm trying to do is to automate the management between 3 servers depending on different situations.
You will see what a big fan of your work am I when tell you what I did :
I've installed on each of the 3 servers a NetXMS server and an agent (each agent communicates with every one of the 3 servers). In total for the 3 servers - there are 3 NetXMS servers and 3 agents. In this way based on the different situations (network or server issues) the 3 servers can take decisions and actions.

The idea of pushing events between the servers is very good and helpful. Is there a other way to transfer values?
Is the Event processing the only way of setting the Situation attributes?
Can we for example do something like: s->status = "updated" (s - situation)?
Can we see the current Situation attribute state in NetXMS console?
Is there a way to change Custom Atributes?
Can we send parameters to the actions?
Can we write DCI value to a file (using actions)?

Thank you,
Boris

[victor]

Hi!

Your setup is very impressive It was a pleasure to read your post

@borislavl said in Action to return value:

The idea of pushing events between the servers is very good and helpful. Is there a other way to transfer values?

Not yet (except action + push mechanism you already using). I plan to add support for full-scale distributed monitoring, event forwarding is a first step in this direction.

@borislavl said in Action to return value:

Is the Event processing the only way of setting the Situation attributes?

Yes.

@borislavl said in Action to return value:

Can we for example do something like: s->status = "updated" (s - situation)?

Not yet. But it's very easy to implement, so I'll add it until next release.

@borislavl said in Action to return value:

Can we see the current Situation attribute state in NetXMS console?

Yes, via View -> Situation. You should see situations - instances - attributes tree.

@borislavl said in Action to return value:

Is there a way to change Custom Atributes?

Only manually via console, or by writing your own tool via C or Java API.

@borislavl said in Action to return value:

Can we send parameters to the actions?

Yes (I suppose you mean actions on agents). In action definition you can use placeholders $1, $2, etc. - they will be replaced by appropriate parameter. Parameters should be separated by space - like for calling external command. For example, you can define on agent:

Action = Test:echo $1

and on server define remote action like

Test "%n"

Of course, if security is not a concern, you can define "universal" action like this:

Action = Execute:$1 $2 $3 $4 $5 $6 $7 $8 $9

and then just use any command you want without defining additional actions, like

Execute /my_script "%n" "%m"

@borislavl said in Action to return value:

Can we write DCI value to a file (using actions)?

Yes. You can call action with a parameter with macro expansion using NXSL, and access DCI data for current node as usual.

Best regards,
Victor

[borislavl]

Hi Victor,

Thank you for your quick and accurate answers.

In the same configuration (3 NetXMS servers and 3 agents), I need to monitor the 2 way connection/availability with the NetXMS servers and agents:

• I'm checking the connection with the remote Agents, collecting their uptime every 5 seconds.
• For checking the connection availability to the remote NetXMS server, I’m using the shell command nxpush (to the remote server), executed every 5 seconds as a Parameter on the local agent and check the return value - if it is "" (empty string) the server is alive, if it is "Cannot connect..." there is connection/server issue.  At the same time at the receiving server I'm trying to check if I'm receiving properly the pushed values - i.e. if the pushed timestamp is older than 10 seconds - there is issue with the 2 way connectivity.

Few related questions:
1.Is there a better way for monitoring the 2 way connection between the NetXMS servers?
2.Is there performance issue if events (logging unchecked) are generated on short interval (i.e. 5 sec)?
3.What is the code in NXSL to access the last DCI?
4.What is the code to access the last DCI collected timestamp?
5.In DCI Transformation, using NXSL, can we use other other DCI value and based on both to return value (i.e. true or false), which to be used in the thresholds (to generate event).

Thank you,
Boris

[victor]

Hi!

@borislavl said in Action to return value:

1.Is there a better way for monitoring the 2 way connection between the NetXMS servers?

One possible alternative is to check remote port 4701 via portcheck subagent.

@borislavl said in Action to return value:

2.Is there performance issue if events (logging unchecked) are generated on short interval (i.e. 5 sec)?

Should not be. Event processing is usually very fast. Btw, it is one of the reasons why direct data collection not allowed in event processing policy's scripts.

@borislavl said in Action to return value:

3.What is the code in NXSL to access the last DCI?

What you mean by "last DCI"?

@borislavl said in Action to return value:

4.What is the code to access the last DCI collected timestamp?

It's not possible in 0.2.31. However, I have added new function GetDCIObject which returns reference to object containing all DCI's attributes, including last poll timestamp.

@borislavl said in Action to return value:

5.In DCI Transformation, using NXSL, can we use other other DCI value and based on both to return value (i.e. true or false), which to be used in the thresholds (to generate event).

Yes, you can access other DCIs values via FindDCIByName, FindDCIByDescription, and GetDCIValue functions. If you creating computed DCI, sometimes it can be useful to use Internal Dummy parameter as a source and read values of all relevant DCIs in transformation script.

Best regards,
Victor

P.S. Example of calculated DCI: https://www.netxms.org/forum/index.php/topic,289.0.html

[borislavl]

Hi Victor,

Thank you for your answers and eager to make NetXMS better and better. It will be great if we can use the timestamp of collected DCI. I continue in configuring the solution and new questions rise up :).

1. Is it possible when we have multiple Thresholds i.e. for values 1, 2, 3, .. N, to run only one Event in case that the Condition is true and NOT having to run an Event when the Condition is false (i.e. 2, 3, .. N)?
   In other words to have a Threshold with only one Event (true) and not having Event for false (or having None in case of false)?

2. In the FindDCIByDescription($node, "DCI_Desc") can we specify the node (other than the current one)?

3. How the option “Proxy node” in the DCI works? If I select other node on which there is agent and server, the data collection stops. Is the idea to receive values from the NetXMS agent on the proxy node or it is used as proxy but you are receiving the values from the node for which the DCI is set?

4. Is nxget the only way for collecting values from other nodes' agents?

5. When using ExternalParameter which returns a string – it is captured to the first interval “ “. Is there a way the entire string to be captured and to be specified what length to be returned?

Thanks,
Boris

[victor]

Hi!

@borislavl said in Action to return value:

1. Is it possible when we have multiple Thresholds i.e. for values 1, 2, 3, .. N, to run only one Event in case that the Condition is true and NOT having to run an Event when the Condition is false (i.e. 2, 3, .. N)?
   In other words to have a Threshold with only one Event (true) and not having Event for false (or having None in case of false)?

You cannot create threshold without rearm event. However, you can create template for "normal" severity event, call it NONE, uncheck "Write to event log" option, and use it whenever you don't need rearm event. It will not affect server performance, and will not leave any traces, unless you run server with debug level 5 or above - in that case you'll get some debug messages in the log.

@borislavl said in Action to return value:

2. In the FindDCIByDescription($node, "DCI_Desc") can we specify the node (other than the current one)?

3. How the option “Proxy node” in the DCI works? If I select other node on which there is agent and server, the data collection stops. Is the idea to receive values from the NetXMS agent on the proxy node or it is used as proxy but you are receiving the values from the node for which the DCI is set?

Answers to these questions are related, so I will start with answering question 3.
To make proxy node works, you should do one of the following: add node owning DCI with proxy node set to proxy node's "Trusted Nodes" list, or set serevr's configuration variable "CheckTrustedNodes" to 0. Reason for this is security - without trusted nodes check, user with write access to only one node could potentially collect data from all nodes in the system, just by setting them as proxy nodes. Accessing DCIs of other nodes from within transformation script disables for the same reason. However, as I types this answer, I realize that is is possible to add some NXSL function which will search for node and return node object, if current node is listed as trusted for node being searched. So I'll add it

@borislavl said in Action to return value:

4. Is nxget the only way for collecting values from other nodes' agents?

If you mean "the only command line tool" - yes. But you can use libnxsrv library to write your own tools if needed (using nxget's source code as reference). Another way is to get value from agent via server using client API (either C or Java).

@borislavl said in Action to return value:

5. When using ExternalParameter which returns a string – it is captured to the first interval “ “. Is there a way the entire string to be captured and to be specified what length to be returned?

Looks like a bug. I'll check it.

Best regards,
Victor

[victor]

In 1.0.0-rc1 I have added new NXSL function FindNodeObject. It takes two arguments: current node object and ID or name of node of interest. It can be used as following:

sub main()
{
   // Search for node named "gateway"
   gw_node = FindNodeObject($node, "gateway");

   if (gw_node == null)
      return 0;   // No such node or access denied

   // from here, gw_node can be used in a same way as $node, for example:
   status = GetDCIValue(gw_node, FindDCIByDescription(gw_node, "Status"));

   return 1;
}

Best regards,
Victor

[borislavl]

Hi Victor,

These are great news :).

I already install the new version - no issues with the updgrade from the previous version.

The function GetDCIObject looks very helpful.

Could you please tell how to receive the DCI timestamp using it?

I was trying a script like this:

sub main()
{
testobject = GetDCIObject($node, FindDCIByDescription($node, "DCI_Description_1"));
return testobject->timestamp;
}

It was working fine with the object members id, name, description and status, but I was not able to find how to access the DCI timestamp?

Are there other members of the DCI object?

Thank you for the great work,
Boris

[victor]

Hi!

DCI object has the following attributes:

Attribute	Description
dataType	DCI data type (string, integer, etc.) represented as internal numeric code
description	DCI description
id	DCI identifier
lastPollTime	DCI last successful poll time as UNIX timestamp (number of seconds since 01.01.1970 00:00:00 UTC)
name	Parameter's name
origin	DCI origin (NetXMS agent, SNMP, etc.) represented as internal numeric code
status	DCI status (0 = active, 1 = disabled, 2 = not supported)
systemTag	DCI system tag (not available in 1.0.x versions)

So, you need lastPollTime attribute.

Please also note that there are new function called "trace", which can be very useful in debugging scripts. It takes two arguments - debug level (0 .. 9) and text, like this:

trace(1, "some message");

Text passed as second argument will appear in server's log, if given debug level less or equal current server's debug level (set by -D command line option). If debug level in trace() call set to 0, message will always be logged with INFO severity.

Best regards,
Victor

[borislavl]

Hi Victor,

Thank you for the quick response and understanding.

I need to check the availability of 3 agents (on 3 servers) every 5 sec (or less).
Using the Internal->AgentStatus check the values are checked every 60 seconds, doesn't matter of the DCI polling interval (i.e. 5 seconds).
Is this controlled by the Server configuration -> StatusPollingInterval and if I set it from 60 to 5 seconds will this affect the performance?

I was trying a workaround - using Agent.Uptime, every 5 seconds - but in this case when there is no connection with the agent there are no new values (neighter errors) on which I can attach a Threshold that the connection is broken (may be because of configuration).
Then I've created an External parameter with nxget to the agent, so when there is no connection with the agent it returns a string "Cannot establish connection...", but if the local agent stops, there is no error returned and all the External parameters just stop being collected.

What is the easiest way to monitor the agents availability in a short interval (5 seconds or less)?

Best Regards,
Boris

[victor]

Hi!

StatusPollingInterval is a global parameter, and if you reduce it, all nodes will be polled more often. Depending on number of nodes, this may cause performance problems. One possible problem is network traffic increase, other is increased CPU and database usage. But severity of both these problems depends on number of nodes.

It's strange that you don't get data collection errors on Agent.Uptime - looks like a bug, because "data collection error" threshold should fire in that case. I'll check this.

Unfortunately all possible workarounds involves local agent. You can enable watchdog for local agent to restart it automatically in case of agent's crash, but it's workaround for workaround The only good solution I see is to allow status polling interval configuration for each node - it's on my todo list for some time, but I cannot promise exact version where this feature will be implemented.

Best regards,
Victor

[borislavl]

Hi Victor,

In my case I have to manage only 3 nodes, so I've set the StatusPollingInterval to 10 seconds.

Is it difficult to be developed - when there is "data collection error" - this value to be recorded to the DCI table (database)?
I.e. empty string "" or something suitable for all data types. In this case when needed the connection can be checked from the NXSL.

Thank you,
Boris

[victor]

It will require changes in very important part of code, and in turn will require additional tests - and I wouldn't want to do this until 1.0.0 release. However, I have added new attribute to DCI object - errorCount - which you can use to check from NXSL if given DCI had data collection error. This attribute will be 0 if last poll was completed succesfully, or > 0 if there was an error (will hold number of consecutive data collection errors).

Best regards,
Victor

[borislavl]

Hi Victor,

Thanks for the effort for creating such functionality as DCI object – errorCount.
I do appreciate that it is really professional to not make significant changes to the code without the proper testing after that.
Is it possible the DCI object to have – errorFlag which can be 1 or 0, if the last polled DCI Is error, and the next poll is successful the errorFlag to be set back to 0?
This way the DCI value can be trusted or no from the NXSL.

Thank you,
Boris

[victor]

Hi!

In NXSL, you can use any integer value as boolean, where 0 means false and any-non-zero value means true. So, you can use errorCount attribute as boolean flag if you wish, like below:

if (dci->errorCount)
{
    // Processing if error
}
else
{
  // Processing if OK
}

You can also apply boolean logic operations to integer values, for example:

if (!dci->errorCount)
{
  // Processing if there are no errors
}

Best regards,
Victor