While NCPA has many features, configuring your initial NCPA install can be tricky. This help documentation is here to explain the inner workings of NCPA as well as a reference when configuring and setting up NCPA instances.
This help documentation is geared towards those who have already installed NCPA and are looking at more advanced configuration and setup using this help as a reference. To start off, below is a brief overview of the parts of NCPA and what they are responsible for.
NCPA is actually two separate services that make up a single monitoring agent. This separation allows the ability for the agent to run passive checks without needing to allow connections to the web GUI or allow external calls to the API. It also allows the passive portion of the agent to be disabled if it's not in use to save resources even though the passive portion requires very few resources while running in the background.
By default in NCPA 2, both services run as the nagios user and nagios group. The user and group can be changed in the ncpa.cfg.
The NCPA Listener service does the following:
The NCPA Passive service does the following:
Because NCPA is made up of these two separate services, you will need to restart both of them if you are using both the active and passive capabilities. Below is the naming conventions and the command line way of restarting both services. In the configuration section you'll find that you will need to restart the services each time configuration changes are made.
You can also view the services in the windows services administration panel, but you can also do it easily from the command line.
net stop ncpalistener net start ncpalistener
net stop ncpapassive net stop ncpapassive
This is an example for CentOS 6. However, the services are named the same in all Linux distros we build for.
service ncpa_listener restart
service ncpa_passive restart
Unfortunately there is not a restart command for launchctl
at this time.
sudo launchctl stop com.nagios.ncpa.listener sudo launchctl start com.nagios.ncpa.listener
sudo launchctl stop com.nagios.ncpa.passive sudo launchctl start com.nagios.ncpa.passive
The latest version of NCPA has a lot of major changes that affect users of older versions of NCPA. Since these changes are in multiple sections of NCPA 2, we have created list of the most notable changes that could affect your system when upgrading from an older version. You can also view the full changelog on the NCPA GitHub repository .
check_ncpa.py
(version 1.0) and should be updated. Version 1.0+ is compatible with NCPA 1.x and 2.x so you can update at any time. If you are using Nagios XI, update your NCPA wizard in the Admin > Manage Config Wizards section. If you are using Nagios Core, you can download the new plugin from GitHub .value
. Instead, it's output is just a JSON object, formatted the way it should be returned based on the node that was called and whether or not it is a check. This change is already accounted for in the new check_ncpa.py
plugin (version 1.0+) and is available in both Nagios XI and Nagios Core. See above for instructions.ncpa.cfg.d
folder to be included into the main ncpa.cfg
configuration file.api/agent/plugin
node, we have renamed this node to api/plugins
which fits the current node layout better. This change affects both active and passive checks. The old node is still able to be used, so no immediate changes are necessary, but it is deprecated and will be removed in future versions of NCPA.units
variable also now will only affect the B and b unit types. All other types can only be overridden by unit
, which sets the unit to something other than the default unit used.api/service/<servicename>
and api/process/<processname>
for both the service and process nodes. However, in NCPA 2, the nodes will forward to the new api/services?service=<servicename>
and api/processes?name=<processname>
instead. The old node endpoints will be removed in future versions of NCPA.|<check interval in seconds>
after there service name. If an individual check interval is not defined, the global default sleep value set in your config will be used.Sometimes when setting up NCPA things don't work out the first time. We've compiled a few troubleshooting tips and things that could happen that might give people headaches.
Typically if there is an error you will always see that error logged, no matter what your log level since error is the most filtered log level available. However, sometimes Python errors will occur before logging starts in Windows systems. You can normally find these errors in the log files located in the same directory as the .exe files in the Windows Program Files directory that you installed NCPA into.
That being said, a good habit to get into is setting your loglevel
to debug when you are running into trouble where something is not working correctly. If you do this, and restart your NCPA services, we can get a better idea of what is going on and when it's going in the code. If you can't figure out the issue from reading the debug log, post it in an issue on GitHub and the developers can take a look.
For both passive and active checks, when you are configuring them, do not use the api section when specifying the endpoint to run. Examples below:
./check_ncpa.py -H <ncpa server> -t '<your token>' -M 'disk/logical/C:|' --units G
%HOSTNAME%|<service name> = disk/logical/C:| --units G
Note that the disk/logical/C:|
does not have the api
portion applied. Remember that checks do not need a beginning forward slash. A good way to avoid using the wrong path is by viewing an example check for the endpoint you are making a check for from the API tab.