/usr/local/nagios/libexec/check_ncpa.py -H <hostname> -t 'token' -P 5693 -M 'services' -q 'service=dfs,status=running'
UNKNOWN: No services found for service names: dfs
I have tried dfssvc.exe, same result.
all other services it sees are just fine
dfs.jpg
You do not have the required permissions to view the files attached to this post.
Try this: re-run the NCPA Wizard against that machine and see what services come up in the XI interface for the Wizard, and if you see NFS in any way, go ahead and configure monitoring for it, and see what the actual command comes out as.
Did that machine update? Did MS change the name and nobody saw the announcement?
We're also taking a look at making sure we know how NCPA is string matching there. I see you are on 2024R1.4.1 so clearly you have updated recently but nothing in that update should have affected checks or NCPA.
It seems you're having a matching issue. By default, NCPA only matches services with an exact match with the service name. To troubleshoot this, you can go into the NCPA web interface (https://my_ncpa_ip:my_port_usually_5693) and go to API and then select services from the dropdown and use the Service Filter(s) section to test out different matches.
Under filter settings, you can also modify whether you want exact match (default), search match (partial matches allowed), or regex matching.
If you're wondering how to construct a Nagios check with this information, get your filters to filter as you desire and then select the "Run as a Nagios check" button. This will show a View in alternate format button on the bottom from which you can select As active check using check_ncpa.py. This will show how to construct a check_ncpa.py CLI query to get the desired result from your NCPA API.
Since you aren't passing any match= options into your check, it's looking for a strict match, so if the name of the service changes (it looks to me like that may have been what happened here. Also, it IS case sensitive when using strict matching (default)), it will no longer find it.
Actively advancing awesome answers with ardent alliteration, aptly addressing all ambiguities. Amplify your acumen and avail our amicable assistance. Eagerly awaiting your astute assessments of our advice.
Try this: re-run the NCPA Wizard against that machine and see what services come up in the XI interface for the Wizard, and if you see NFS in any way, go ahead and configure monitoring for it, and see what the actual command comes out as.
Did that machine update? Did MS change the name and nobody saw the announcement?
We're also taking a look at making sure we know how NCPA is string matching there. I see you are on 2024R1.4.1 so clearly you have updated recently but nothing in that update should have affected checks or NCPA.
Aaron
I did try that....it does not see it doing that either
bbahn wrote: ↑Mon Mar 10, 2025 4:23 pm
Hello @JohnFLi,
It seems you're having a matching issue. By default, NCPA only matches services with an exact match with the service name. To troubleshoot this, you can go into the NCPA web interface (https://my_ncpa_ip:my_port_usually_5693) and go to API and then select services from the dropdown and use the Service Filter(s) section to test out different matches.
Under filter settings, you can also modify whether you want exact match (default), search match (partial matches allowed), or regex matching.
If you're wondering how to construct a Nagios check with this information, get your filters to filter as you desire and then select the "Run as a Nagios check" button. This will show a View in alternate format button on the bottom from which you can select As active check using check_ncpa.py. This will show how to construct a check_ncpa.py CLI query to get the desired result from your NCPA API.
Since you aren't passing any match= options into your check, it's looking for a strict match, so if the name of the service changes (it looks to me like that may have been what happened here. Also, it IS case sensitive when using strict matching (default)), it will no longer find it.