NetXMS Support Forum

We are working to monitor a number of services that per the manual have cURL support and hence should be using the Service.Check agent command.

We are working to get POP3 working at the moment and have:

Service.Check(pop3://username:[email protected]/,^.*OK Authenticated.*)

If we put in actual values and run this using from the command line using the curl -v command we get valid results.  However, when we run it from a DCI it always comes up with 3.  How can we see the value being returned from the check.  Also, it states the Service.Check.XXXXX are to be considered deprecated in the documentation.  Wondering why since they seem to offer more complete testing of common protocols?

Thanks!

If I actually remove the agent and let it poll directly from the server with the node containing the credentials I seem to be getting the results now.  Will test this on a larger batch of devices, but hoping with that configuration setup it will work.  No agent involved at all.  Thanks for checking into this!

Yes, that was exactly the issue and it just caused of course inconsistent results depending on when each applied themselves.  Thanks!

We seem to be having a strange issue, that likely has been recently introduced.  We are running the latest 4.0.2227 version.

We have a number of Custom Attributes defined on the Infrastructure Services folder with values that we use on nodes to control scripts.  They are all setup to be Inheritable.  Underneath we have a folder called "Telephone Customers" where we setup some custom attributes with the same names but override the values to be specific to that group. 

The issue is that Nodes under that folder seem to at times be getting the values from Infrastructures Services folder and at other times getting them as expected from the Telephone Customers folder.  If we open that folder and edit the attribute followed by Apply & Close it is applied to all nodes.  We just need it to get the attributes from Telephone Customers from the start and then not change.  One of them is where it might post messages into Slack and when they go to the wrong spot confuse the responsible people.

Looking for suggestions what might be happening and how to resolve this.

It is simply: $node->sysDescription

Assuming the GetDCIValue contains the last value until the collection is complete (need to verify this) then a simple Threshold script like the following should work:

// Empty is OK no matter what
if ($1 == 0) return false;

// Non-empty OK only if different
if ($1 != GetDCIValue($node, $dci->id)) return false;

// Not OK, trigger threshold
return true;

Now I understand that this is going to seem like an odd question but can somebody explain exactly what this controls?  My guess is this is how often instance discovery would be run? 

However, the default value is 10 minutes and that seems REALLY short or at least in our environment.  We have a ton of templates and for something like a switch, report on interfaces that we are using and have to run filters to get to this point.  Then we might also monitor 5+ values per port.  This is a LOT of polling on what seems like pretty static information if we are understanding it correctly.

I was thinking about adjusting this to something like 86400 (1 day) but when it defaults to such a low number wonder if I am missing something. 

Appreciate any further details on what this value does.  Thanks!

This appears to still be an open item.  Is there any way we can +1 the need for this in the tracker.  We have performance graphs that combine 5-10 DCI's on a regular basis and are instance driven.  Would be nice if they were not all green

Was hoping this was resolved in 4.0.2157 as I saw this in release notes:

- Improved SSH subagent

The issue still however persists with this release.

The previous posts were all running in 3.9.xxx (I believe 420).  We have upgraded now to 4.0.2157 and we are not having issues any longer with this.

Ran a standard apt upgrade to get the latest over a 3.9.4xx version.  I received the following error during the package installation / database upgrade:

Upgrading from version 40.95 to 40.96
SQL query failed (Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs):
ALTER TABLE items ADD state_flags integer

This was resolved with the following SQL commands being issued against the NetXMS database:

alter table items ROW_FORMAT=DYNAMIC
alter table items DROP COLUMN state_flags
alter table dc_tables ROW_FORMAT=DYNAMIC

Hope this helps somebody and that this error can be resolved for others upgrading.  Thanks!

Following up on my own post, but still hoping for some clarity.  This fails running AgentExecuteAction on the node, but works if I run nxaction from the server command line.  The exact calls are as follows:

Does not work:

AgentExecuteAction($node, "Sql.StatusUpdate","host.com","1.2.3.4","down","YIKES");


---

Works:

nxaction -s NOTTREALKEYHERE -o sql.host.com "Sql.StatusUpdate" "host.com" "1.2.3.4" "down" "YIKES"

Maybe AgentExecuteAction does not handle shared secrets properly? 

The Ubuntu package for the agent does not include mysql.nsm subagent or any of the others, though only interested in mysql at this point.  I also installed the netxms-dbdrv-mariadb package (as the mysql package not available for Ubuntu 20) and it did not provide that either.

I am trying to do a simple update of node status into a MS-SQL server when the status on a node changes.  I have written a really simply .cmd file to handle passing in the hostname, ip address, status and comment.  Can run this from the command prompt on the server and it works as expected.

On the server running the agent we have the following:


ActionShellExec = Sql.StatusUpdate:D:\nodeUpdate.cmd $1 $2 $3 $4

If I enable debugging on the agent can see this is getting fired off:

2022.02.18 13:06:23.802 *D* [comm.cs.232        ] Received message CMD_ACTION (4)
2022.02.18 13:06:23.811 *D* [procexec           ] ProcessExecutor::execute(): process "CMD.EXE /C D:\nodeUpdate.cmd host.com 1.2.3.4 down Yikes" started
2022.02.18 13:06:23.812 *D* [actions            ] Execution of external action Sql.StatusUpdate (D:\nodeUpdate.cmd host.com 1.2.3.4 down Yikes) started
2022.02.18 13:06:23.812 *D* [actions            ] ExecuteAction(Sql.StatusUpdate): requestId=4, RCC=0
2022.02.18 13:06:23.812 *D* [comm.cs.232        ] Sending message CMD_REQUEST_COMPLETED (ID 4; size 32; uncompressed)


One of the first thing the script does is echo the parameters to a temporary file, so we have some history.  That is never getting triggered and definitely the sqlcmd statement in the script is not running.  Have been pulling my hair out for a while and cannot figure out why this is not working.

Ideally, though at this point becoming less of a bid deal that last parameter should allow for a string with spaces.  That at this point is icing on the cake, just want it working.

Thoughts?

Ours is running 6.48.6 which is in the long term channel where we like to be.  We might have one running 6.49.1 and I will look around, but we have not yet ventured into the 7.x.x line.  You are a brave man - though you did say it was at home.  I might upgrade my home one to that and see as well.  Is your server Ubuntu 20.04 as well? 

Could you post the SSH properties setup on the Node and also the General properties for the DCI.  I just keep thinking something is not right on my side.



Appreciate the assistance!