Hi,
I've tryied also (before opening the question) with an already assigned service on a hostname (the NNA hostname in XI) named like NNAAlerts, exactly the service destination name and host configured in NNA as target destination for the alerts and it did not work either.
(I remember vaguely at some point in the beginning the automatic creation of service/hostname worked from NNA to XI, but now nothing seems to be sent automatically by NNA on nrdp channel anymore)
I've used the curl command as you suggested(https) and it replied well and fully (very verbose) acknowledging there is no issue in communication between the two hosts when doing it manually.
Are there any logs NNA side I could watch to see if/why the nrdp call is triggered correctly? I double checked the NagioxXI setting NNA side to make sure they are correct?
PS. hands-on example:
1. NAgioxXI side defined a service called NNAAlerts on a hostname named WGOSS02, as a passive check. NRDP is listening on https with the right token set-up
2. NNA side defined the NagiosXI link (https://...nrdp/, correct token, etc)
3. NNA side defined the NNAAlerts/WGOSS02 association for the NagiosXI link
nnasetup.JPG
4. on NNA side, CLI mode, created a test.txt with the service name and hostname previously defined in XI
Code: Select all
<?xml version='1.0'?>
<checkresults>
<checkresult type='host'>
<hostname>WGOSS02</hostname>
<state>0</state>
<output>Everything looks okay! | perfdata=1;</output>
</checkresult>
<checkresult type='service'>
<hostname>WGOSS02</hostname>
<servicename>NNAAlerts</servicename>
<state>1</state>
<output>WARNING: Danger Will Robinson! | perfdata=1;</output>
</checkresult>
</checkresults>
5. Sent the test.txt towards the XI with curl, from cli:
Code: Select all
curl -XPOST https://wgoss01.ot.local/nrdp/ -d token=removed_token_content -d cmd=submitcheck --data-urlencode [email protected] -k -v
6. Data arrives correctly into NagiosXI GUI
nnaresulttest.JPG
So all seems fine communication wise. But when a check that I write breaches a threshold, NNA does not seem to be sending that check's output to the XI, by itself.
Help?
PS. I've put also a local command, on the NNA, a script to spit out in a log the given arguments to it (/usr/local/nagiosna/bin/cmd1.sh) and put that as trigger of the check. It does not fire on WARNING or CRITICAL either, so my bet would be a malfunction in the triggering mechanism of the NNA.
PS2. I think I'm getting somewhere. I didn't know this was logged in var/backend.log:
Code: Select all
2021-05-05 17:15:00 DEBUG : URL: https://wgoss01.ot.local/nrdp/
2021-05-05 17:15:00 DEBUG : Data: token=token_removed&cmd=submitcheck&XMLDATA=%3Ccheckresults%3E%3Ccheckresult+type%3D%22service%22%3E%3Chostname%3EWGOSS02%3C%2Fhostname%3E%3Cservicename%3ENNAAlerts%3C%2Fservicename%3E%3Cstate%3E2%3C%2Fstate%3E%3Coutput%3Ebytes+on+WG-Z4+with+filter+%5Bnot+dst+port+22%5D+is+133688961540+%7C+bytes%3D133688961540%3B1%3B1%3B0%3C%2Foutput%3E%3C%2Fcheckresult%3E%3C%2Fcheckresults%3E
2021-05-05 17:15:00 ERROR : Could not send to NRDP server: WGOSS02
Traceback (most recent call last):
File "/usr/local/nagiosna/bin/notify.py", line 195, in send_nrdp_notifications
post_xml_to_nrdp(nrdp, xml, token)
File "/usr/local/nagiosna/bin/notify.py", line 186, in post_xml_to_nrdp
response = urlopen(req)
File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib64/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/usr/lib64/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/usr/lib64/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/lib64/python2.7/urllib2.py", line 1258, in https_open
context=self._context, check_hostname=self._check_hostname)
File "/usr/lib64/python2.7/urllib2.py", line 1214, in do_open
raise URLError(err)
URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)>
If that fails, the the whole notify.py fails without having a chance to reach the command section also.
Back to it, it seems is the verification of the XI certificate is the culprit here. The certificate is a valid one, properly generated (not self-signed), and it work without issue otherwise..
Both systems are off Internet access, not sure if that plays into this