New private location not available to create ICMP NAM Monitors

[AurelienGravier]

Hello,

I deployed 2 Linux active gates on a private location throught ansible.
The 2 AG was added to a new private location but the Network Availability (ICMP) is missing in monitor Types :  

And I can't select this new private location to create ICMP NAM monitors :

"Not supported" exception with the following message : "Currently the location is not configured to execute this type of monitor."

On AG logs diagnostic results the icmp is clearly not enabled :

"diagnosticResults":{"httpScript":{"operational":true,"cases":{"httpScript":{"available":true}}},"browser":{"operational":true,"cases":{"browser_main":{"available":true},"browser_fallback":{"available":true}}},"http":{"operational":true,"cases":{}},"multi-protocol":{"operational":true,"cases":{"tcp":{"available":true},"dns":{"available":true},"icmp":{"available":false}}}}}.

Did you experiment the same behaviour in version Dynatrace-ActiveGate-Linux-x86-1.299.33.sh ? Is there a way to enable this settings ?

Ticket support created without real progress.

Thank you.

Regards Aurélien.

[p_devulapalli]

Hi @AurelienGravier , that's bit odd, I am using a similar version of AG to run NAM monitors but don't see any issues . There is some additional config needed to run ICMP tests if you are on k8s , but not for a linux server that I am aware of.

[HannahM]

Can you try executing a ping on the machine itself? If the machine doesn't have this enabled/ allowed then the ActiveGate will not enable it. 

[AurelienGravier]

Hello @HannahM 

Effectively the ping command seems to be not available on system. I asked to activate it, I keep you updated !

Thank you.

[AurelienGravier]

Hello @HannahM ,

We deployed "iputils" on AG systems, ping command works locally.
We restarted the dynatracegateway service unfortunately we can't select the private location to host ICMP Nams :

Regards Aurélien.

[HannahM]

Thanks Aurelien. Can you also restart the vuc service, if you haven't already?
If it's still not showing, can you check the vuc-status.log and vuc-multi.log for diagnostics messages relating ICMP? If there's nothing obvious please create a support ticket and provide the support archive. 

[AurelienGravier · Accepted solution]

Hello @HannahM, 

We solved the issue !

We suspect that during the service startup, the ActiveGate checks if the ping to 127.0.0.1 is functional, and if not, after 5 attempts, it assumes that pinging is not possible on this machine related logs below :

Ligne 8: 2024-10-16T18:02:01,599Z INFO [monitoring-modules-4] MultiProtocolRequestExecutorsFactory: Known executors:[icmp, tcp, dns], enabled executors: [icmp, dns, tcp] 

Ligne 27: 2024-10-16T18:02:04,101Z INFO [v=51] [MP-ModuleDiagnosticsService-1] DiagnosticCaseWithRetry: Starting diagnostic, attempt 1 of 5 (icmp)

Ligne 43: 2024-10-16T18:02:06,762Z INFO [v=52] [MP-ModuleDiagnosticsService-1] DiagnosticCaseWithRetry: Starting diagnostic, attempt 2 of 5 (icmp)

Ligne 59: 2024-10-16T18:02:08,750Z INFO [v=53] [MP-ModuleDiagnosticsService-1] DiagnosticCaseWithRetry: Starting diagnostic, attempt 3 of 5 (icmp)

Ligne 71: 2024-10-16T18:02:10,760Z INFO [v=54] [MP-ModuleDiagnosticsService-1] DiagnosticCaseWithRetry: Starting diagnostic, attempt 4 of 5 (icmp)

Ligne 87: 2024-10-16T18:02:12,754Z INFO [v=55] [MP-ModuleDiagnosticsService-1] DiagnosticCaseWithRetry: Starting diagnostic, attempt 5 of 5 (icmp)

Ligne 102: 2024-10-16T18:02:14,771Z ERROR [v=55] [MP-ModuleDiagnosticsService-1]

Ligne 101: 2024-10-16T18:02:14,771Z ERROR [v=55] [MP-ModuleDiagnosticsService-1] DiagnosticCaseWithRetry: Received invalid report of diagnostic test TestCompletionResult{visit=MultiProtocolVisit[visitId: 55, testDefinitionId: 1, externalTestDefinitionId: 1, tenant: VucDiagnosticsTestTenant, bf: BeaconForwarder{endpoint='http://127.0.0.1:7878/multiprotocol/diagnostic', tenant='VucDiagnosticsTestTenant', isSaaS=true}], executionResult=com.ruxit.vuc.monitoring.multiprotocol.results.MultiProtocolExecutionResult@27dd3394, beaconStats=BeaconStats{successNumber=5, failNumber=0, nonResponseNumber=0, endVisitSent=true}, testCompleted=null, testReceived=null, testStarted=null, createTime=2024-10-16T18:02:14.77 DiagnosticCaseWithRetry: Attempt 5 of 5 failed, re-running diagnostic case...

If we tested locally a ping to 127.0.0.1 on the AG, the packets were 100% lost.
However, if we tested a ping to a remote server 10.164.0.100, the packets were 100% successful.

SElinux was not enabled, and there was no local firewall but it appears that not all EC2 instances allow pinging 127.0.0.1.

In fact the following parameter in the /etc/sysctl.conf file prevents responding to ping requests directed at 127.0.0.1 :

net.ipv4.icmp_echo_ignore_all = 1

And This means the instance will not respond to any ping requests, including those directed at 127.0.0.1

After editing the configuration ping 127.0.0.1 locally is allowed :

sudo nano /etc/sysctl.conf

net.ipv4.icmp_echo_ignore_all = 0
sudo sysctl -p


And after the restarting of vuc.service the "not supported" message disappears during nam creation at step "Frequency and locations" :

And ICMP appears as a monitor type : 

Regards Aurélien.
Thank you for your help.

[HannahM]

That's really interesting. Thanks for the update Aurélien.

[Peter_Youssef]

Hello @AurelienGravier 

Can you validate the current setup against the below attached items:

(1)

(2)

• create-a-nam-monitor 
• synth_mod 
• create-a-nam-monitor#script-properties 
• nam-workaround 

Check The AG custom.properties file on Both AGs.

Hoping it adds value,

BR, 

Peter.