Using Nagios++ Agent for Monitoring Windows Systems (Part 3, managing the client)

In the former post the Nagios++ client’s architecture was shown as well as its installation concepts. In this post i will elaborate some more on the installation of the Nagios++ agent and from there on explain the way the Agent will be managed from installation perspective

To summarize the Nagios++ Agent configuration three components make up a monitoring node:

1. .ini file(s)
2. Nagios Management engine
3. Supporting classes and modules

The management engine is installed with a Microsoft installer file (.MSI) the way installations like this are done is very straight forward. the only prerequisite for an .MSI installation to work  is the availability of Microsoft Installer framework. the actual command line for the installation is as follows:

msiexec /i "NSCP-0.4.2.58-x64.msi" INSTALLLOCATION="C:\Program Files\NSCP" /qn /l* %TEMP%\install_nagios_agent.log

When the engine is installed the supporting .ini file(s) and classes must be installed. this is a very straight forward process of copying files from one central location to the managed node.

The Modules and scripts directory are the places in which all additional modules and scripts respectively have to be placed.

The ini file is the main configuration of the Nagios Agent. The configuration of it is very well covered in many posts, look at them if you will here, here

In short the list of allowed hosts will configure the partners to which the Nagios agent will talk. modules defines the modules which are allowed to do checks on the monitored node, Aliases are checks being done by the Nagios agent with the aid of the allowed modules.

The main challenge

So when all agents are in place on the monitored nodes the main challenge is the maintenance of the set of scripts, plugins and off course the ini file(s) themselves on the nodes. let me clarify this a bit more:

Because of the nature of monitoring (collecting lots of counters from hosts) the monitoring aspect of a large number of hosts can become problematic. Counters will have to be bundled to sets of counters which themselves do represent a function or service of that device. Furthermore with monitoring large clients with, so called, chains. a group of monitored nodes must be configured in such a way the individual node status reflects its place, function and weight in the chain.

In short: the .ini file on a monitored node will reflect its place in the monitoring process of that client. By now i think you can imagine the generation of specific .ini files for specific groups of nodes will require a system that can manage and maintain all these aspects of the generated .ini files.

 

What .ini files will have to be generated

For monitoring of chains and clusters, specific checks will have to be done on the target nodes. for instance: in a SQL cluster of 3 nodes; certain checks targeted at cluster services and SQL processes will have to be added to the .ini file that will be copied to the cluster nodes. Likewise .ini files will have to be generated for Mail servers etc.

How should this management system manage the configuration of all these .ini files?

The system should be able to do configuration management in all its aspects concerning .ini files and supporting modules, classes and scripts.

1. A central Template .ini file should be maintained by the system, in this case it means the system must always have a reference .ini file and leave it untouched
2. All available modules must be catalogued, for each modules its use to what systems or functions must be known
3. All available classes must be catalogued, for each class its use to what systems or functions must be known
4. All available scripts must be catalogued, for each script its use to what systems or functions must be known
5. for each module, class and script its use must be inventoried
6. All monitored nodes must be known in this system
7. For each monitored, node mappings must be available to its used .ini file, modules, classes and scripts
8. The system should be able to generate a new .ini file with a single action based on the reference ini file and its specific modules, classes and scripts
9. The system should have an inventory of each node, its deployed ini files, modules, classes and scripts as well as its individual versions.
10. The system should be multi tenant
11. The system should be able to host multiple sessions simultaneously
12. The system must have redundancy and recovery features
13. The system must have a connector to the used software distribution systems so it can deliver the content directly to the right software distribution collection
14. The system should have a management interface, which supports Role Based Administration, in which administrators can manage the monitoring configuration of their own clients and/or sites.

When all these items are covered you will be able to manage and maintain the monitoring of multiple clients and sites. In this way delegation of administration is also possible.