Advanced Topics

Authentication Subsystem

The authentication subystem, as mentioned in a previous section is responsible for making sure that the credentials that you supply for a remote Nagios XI or Core server don't change. It also ensures that the communication channel between Fusion and the remote servers is open, along with validating the ability to receive the data required for polling.

This subsystem continuously polls the remote servers based on the interval you select (default 300 seconds) to make sure that the communication channels are open. If for whatever reason that server's authentication cannot be validated, it will continue trying, but more importantly: it won't hold up the poller from being able to grab data.

You shouldn't have to change the default value for the authentication subsystem. But there are several use cases where this would be preferrable; perhaps in an environment with unstable DNS, or frequently changing user passwords. You may increase the value if you know for certain your password won't ever change (you should probably change your passwords periodically). In addition, if for whatever reason you do increase this value, and the authentication subsystem is unable to determine whether or not the communication channel is still valid, then your results are undefined.

Polling Subsystem

The polling subsystem is the main driving force behind Nagios Fusion. Data is polled from each of the remote servers, processed via the poll_callbacks, and then stored in the database. You can find out more about the poll callbacks in the developer documentation.

The polling subsystem is limited to the number of Simultaneous Pollers. If it takes longer to poll data from all of your servers than the time you have alloted for the polling interval, then your polling subsystem will become choked. If that is the case, you'll certainly need to increase the amount of pollers. Also, for every user you map, all of that data for that user on that server is polled as well. So if you only have 2 servers, but you have 20 mapped users, you're essentially polling 40 times during each interval, and even more if you decrease the polling interval on one of the servers.

The data that is grabbed from the remote servers is converted into a PHP Array before and during processing. PHP Arrays are not very memory efficient, unfortunately. For this reason, the Polling Subsystem Memory Limit exists. Acceptable values for this field are the same values used for setting the memory limit in the php.ini file. So, for example: 128M, 1G, 2T, or -1 to allow the script to use unlimited memory (probably don't do this).

The data that Fusion grabs from the remote servers is grabbed in chunks. Each chunk is essentially a seperate API call. You can adjust the number of records per API call by adjusting the Poll Record Count value. The Live Data Timeout value is the timeout per chunk (or API call). The Polling Lock Max Age is the amount of time that a polling lock is valid. A polling lock is created whenever a server/user combination is being polled. If it lasts longer than the max age, it is considered stale and that server/user combination will be polled again immediately (depending on the number of available pollers and if they are available for polling).