- What Is It?
- How Does It Work?
- What's in It for Me?
- How Do I Get My Hands on It?
This chapter is from the book
This chapter is from the book
This chapter is from the book
How Does It Work?
Figure 9.1 is a rough sketch of the Nagios XI architecture. As you can see, all host and service monitoring, as well as notification, escalation, and so on, relies on an unmodified Nagios Core daemon, so any preexisting plug-ins or customization you might have can be made to work under XI. The NDOUtils plug-in (described in Chapter 7, “Scaling Nagios”) has been enabled and configured to replicate state information from Nagios Core into a MySQL database. Here is the primary information hand-off between Core and XI; Nagios XI reads this database to glean information about the current state of hosts and services, as well as the Core daemon itself. This adds an information layer to Core that can be consumed by third-party UIs as well as your own custom integration scripts.
)
Figure 9.1. The Nagios XI architecture, simplified
The NagiosQL add-on (described in Chapter 5, “Bootstrapping the Nagios Config Files”) provides the hooks necessary to modify the Nagios Core configuration from the XI interface. Every parameter that can be configured in the flat files may be set via the web interface using the customized NagiosQL forms in the “Advanced Configuration” section of the XI interface. Although these forms are well integrated into XI, and retain an XI look and feel, there is a bit of a line in the sand between NagiosQL-driven core configuration, which is referred to as “advanced” in the XI interface, and the configuration parameters that are specific to XI itself.
XI goes beyond presenting a simple web wrapper to the Nagios Core configuration files, providing in addition a litany of semiautomated wizards and autodiscovery tools to ease the burden of initial and ongoing host and service configuration. I talk more about these later, but suffice to say that it is the intention of the XI creators to isolate the majority of XI users from the intricacies of the Nagios core configuration to the extent that they never need to know what a check command is, much less a template. This makes it possible for monitoring configuration, traditionally an operations task, to be delegated to first-level support types, or in some environments, even to normal users. More clueful administrators who need to customize this or that can still do so, without editing the config files by hand, using the NagiosQL-driven advanced configuration tool.
Configuration created by NagiosQL is automatically written to text configuration files in etc/nagios and is read by the Core daemon from these flat files in the usual fashion. Although it’s technically possible to hand edit these configuration files, you will gain nothing because NagiosQL will eventually overwrite any changes you make. If you have your own configuration-generating automation (like Check_MK), or preexisting configuration that you do not want to import into NagiosQL, or even if you’re a curmudgeon who just prefers to manually edit the configuration, you can still maintain static config files in etc/nagios/static, and your files will still be parsed by the Core daemon while being left alone by NagiosQL. That runs both ways; statically configured hosts and services can’t be modified via the UI unless you manually import them into NagiosQL (at which point they cease to be static).
Finally, Nagios XI maintains its own Postgresql database to store various configuration parameters such as user-settings, custom dashboards, authentication info, and the like. Given the shiny new PHP interface, the simplified configuration options, and the open database back-end, Nagios XI should satisfy the complaints I’m used to hearing from corporate administrators who are in the market for a “grown up” commercial monitoring product; however, there’s a lot more functionality than what I’ve encompassed in the architecture diagram.