Home » Categories » Products » Nagios XI » Documentation » Best Practices

Nagios XI - XI Server Considerations


This guide on Best Practices is about the Nagios XI server and different considerations you can take in relation to it's configuration.


XI Server Considerations

Date and Timezone

Make sure your XI server has its timezone correctly defined.

When using NTP make sure it's synchronized with a trusted time source like pool.ntp.org.

If this is a virtual machine, don't sync its time with the hypervisor (ESXi, HyperV etc.)!

  • Can be the source of confusing problems such as:

    • Apply configuration throwing errors

    • Performance data not being processed



Having the right amount of CPU cores is important but so too is the speed of those cores. Not all plugins and processes are multi-threaded, so a higher speed CPU is going to benefit. A 3.4GHz CPU will do a lot more than a 2.2GHz one.

Refer to the XI Hardware Requirements guide.



How much memory do you need on an XI system? When all the hosts and services in XI are healthy, the amount of memory used is far less compared to a major system outage. When XI fires off event handlers they consume memory, if there is a major outage and a lot of event handlers are being executed, a lot of memory is being consumed. It doesn’t take long for 6GB of memory to be used.

Generally speaking you should have at least 50% more memory than needed.

Refer to the XI Hardware Requirements guide.


RAM Disk

Configuring Nagios XI with a RAM Disk is highly recommended as the number of monitored objects increase. The more things you are monitoring the more disk I/O occurs. By directing this traffic a RAM Disk, the time it takes for that I/O operation to complete is drastically faster.

  • Reduces disk I/O & load

  • Speeds up processing of performance data

  • Speeds up processing of spooled check results

  • Speeds up nagios restarts

Refer to the XI RAM Disk procedure.


Solid State Disk (SSD)

Greatly improves overall performance

  • Compliments RAM Disk

  • Helps read/writes with:

  • Logs

  • Database

  • Performance Graphs

  • Reports



RAID allows for much larger disk capacities than SSD can provide, however it would be very hard for a spinning disk RAID set to beat the performance of SSD.

Keep in mind if you implement SSD you should implement RAID1 sets for redundancy purposes.



rrdcached is a way of accumulating the received performance data and then processing it in a batch job. It helps with larger installations and can reduce I/O, however it can also result with performance graphs lagging behind the realtime results.

Refer to the XI rrdcached procedure.


Offloaded MySQL / MariaDB

On larger installations there can be a lot more data being written to the databases, which in turn can result in a lot of CPU usage directed away from actual monitoring.

Offloading to a separate server will remove this CPU usage from your monitoring server.

Of course, make sure you monitor the offloaded server!

Refer to the XI Offloaded DB procedure.



Mod-Gearman is a way of offloading the plugin execution to separate workers instead of the monitoring engine doing it. A worker can be on the XI server itself OR on external hosts.

On external hosts, it requires all the plugins to be installed that are going to be executed.

Also, be aware of plugins that create temporary files, these don’t work well if the plugins are moving about the workers.

You can also use host groups for directing checks to only be executed by specific workers, this is handy for multi-site setups.

XI 2014 uses Core 4.x which now has its own workers. Using Mod-Gearman on an XI 2014 server just for the purpose of a local worker is not required, however if you need external workers then Mod-Gearman is the solution for you.

Documentation - Integrating Mod-Gearman With Nagios XI

Documentation - Mod-Gearman Queues and Workers


Disaster Recovery

Define is what is import to you in a disaster. Once you have clearly defined goals and outcomes you can plan appropriately and test.

These presentations cover DR options:



Have you scheduled your backups in Nagios XI?

  • Admin > System Backups

  • Schedule backups of XI

    • Location can be local, FTP, SSH

    • Remote location recommended. Storing them on storage that is not local to the XI file system is important - make sure you can get to your backups if your XI server dies.

  • Manual Backups

    • Local Backup Archives via Admin menu

    • /usr/local/nagiosxi/scripts/backup_xi.sh


Restoring Backups

The backup and restore procedure is very straight-forward and allows for a full recovery of your Nagios XI system.

Another good use of it is to migrate XI from one server to another.

Refer to the XI Backup and Restore procedure.



Final Thoughts

For any support related questions please visit the Nagios Support Forums at:


5 (1)
Article Rating (1 Votes)
Rate this article
  • Icon PDFExport to PDF
  • Icon MS-WordExport to MS Word
Attachments Attachments
There are no attachments for this article.
Related Articles RSS Feed
Nagios XI - Groups
Viewed 3646 times since Tue, May 3, 2016
Nagios XI - Monitoring the Nagios XI "localhost"
Viewed 3151 times since Mon, May 2, 2016
Nagios XI - Macros and Custom Object Variables
Viewed 3205 times since Tue, May 3, 2016
Nagios XI - Check Interval Considerations
Viewed 3283 times since Tue, May 3, 2016
Nagios XI - Configuration Wizards and Templates
Viewed 5468 times since Tue, May 3, 2016
Nagios XI - What Is Monitoring XI ?
Viewed 1848 times since Mon, May 2, 2016
Nagios XI - Service Dependencies
Viewed 5184 times since Tue, May 3, 2016
Nagios XI - Best Practices for Managing Configs
Viewed 4299 times since Wed, Jul 19, 2017
Nagios XI - MRTG Clean Configs
Viewed 3950 times since Tue, May 3, 2016