The GroundWork Monitor configuration application, referred to as Monarch (Monitor Architect), is a full-featured, easy-to-use web based system for use with Nagios. Monarch consists of a set of tools that allow a user to easily configure and maintain GroundWork Monitor. Monarch provides a user interface versus a command line text editor to configure the monitoring system for each monitored application, service, device, etc. For current Nagios users, Monarch writes and reads Nagios configuration files, enabling it to be easily integrated into an existing installation. You can simply install the package and import your existing configuration. Experienced Nagios users can edit the Nagios configuration files and use Monarch interchangeably.
Although the configuration tasks may not seem to be a formal part of the ongoing data-collection and processing cycle, they play a crucial part of the overall information flow in GroundWork Monitor. At a bare minimum, resources must be defined before they can be monitored or displayed to the end-user, and as such the configuration process determines everything else that will happen in the system later. However, the configuration process also affects a variety of subordinate components (such as performance graphing and event collation) which are less obvious but just as critical to the long-term satisfactory use of the system.
Architecturally, the basic unit of data in GroundWork Monitor is the measurement reading that is taken at a specific time for a specific resource on a specific host. Before this data can be collected, however, the system administrator must first define the target host, and must also define the services on that host which need to be monitored. Administrators must also specify the data that they want to collect and they must also assign general options such as scheduling intervals and notification contacts. Once a resource and all of its necessary options have been defined, a command scheduler will periodically execute the appropriate monitoring tool for that resource, thereby producing a sample reading for the resource in question. From there, the measurement data is subsequently used to perform additional tasks throughout GroundWork Monitor, according to the options that have been defined.
The process of defining a resource and its options is managed through the Configuration tier, and specifically the open source GroundWork Monarch configuration tool for Nagios. This application presents data-entry screens and forms to the user via a web interface, while reading and storing the configuration settings into an embedded database on the back-end. Once the administrator decides to commit the configuration, additional processing is invoked which generates the configuration files and databases that are needed by the individual software components. In this manner, all of the different software components throughout GroundWork Monitor are guaranteed to always have a consistent view of the hosts and services that are being monitored, without requiring the administrator to configure each component separately.
Once you are finished making modifications, you can execute the Pre Flight Test, equivalent of the Nagios -v command, to provide options for controlling your production configuration. This will verify the configuration and will write the updated Nagios configuration files into a Workspace Directory. At this point your current Nagios configuration has not been affected providing you the opportunity to view and manually manipulate the configuration files.
Monarch also gives you the capability to commit the files into your production configuration (
nagios/etc directory) and also initiates an automatic backup in a separate backup directory. Commit then performs a Nagios restart, activating the Monarch configuration.
Any change made with the Monarch configuration tool is not effective and does not become part of your monitoring system production environment until the change is committed with the Commit option. Other components of the process include Pre Flight Test and Backup.
Before performing a commit operation, your are advised to run a Pre Flight Test which will check the configuration for possible warnings and will not implement any changes into the Nagios configuration. Pre flight test data is stored in the
A Commit operation is used to update configuration changes to the Nagios configuration files which are stored in the
A Backup of the Nagios configuration files (.cfg) and a database dump of the monarch configuration database (.tar) will automatically be initiated every time a successful commit operation takes place. Backup configuration files are stored in a
/usr/local/groundwork/monarch/backup/<timestamp> directory. Note that in addition to the Nagios configuration files and the database file the backup directory also contains the monarch annotation(.annotation) file which holds an optional backup description added at the time of backup.
Host and service templates
Host templates and service templates store common object properties that are used to define multiple hosts and services. Templates are used to reduce the number of repetitive entries when defining objects. For example, when defining a new host you would first create a host template with common properties. Then, to define a specific host, you apply the properties using a host template. You would define a new service in the same way, starting with a service template and applying the template to the service definition.
A service configuration is a combination of a service template and a service definition. A service is generic until it has been applied to a specific host. A host, when fully implemented, has a host template, a unique host definition, and services.
A service profile is a collection of multiple services. Monarch uses device-specific profiles that contain both pre-defined and user-definable monitoring parameter settings. Using profiles administrators can quickly configure GroundWork Monitor to monitor groups of similar devices and benefit from GroundWork deep expertise in monitoring design recommended practices.
Example: You have 50 web servers on which you will want to monitor CPU, memory, disk, http, and apache processes. Instead of creating 50 definitions you would create a service definition for each service including CPU, memory, disk, etc. You can then create a service profile called web monitoring and include all of the services. You would then associate this service profile with each of the 50 web servers. Configuration. Monarch does this with a host profile.
Once you have a service profile defined you can combine it with a host template and create a host profile. These profiles are not associated with a specific host.
And once you have the host profile you can apply this combined definition to each of your 50 specific web servers. This concept will allow you to generically define the different roles of the different devices you are monitoring and easily apply them. If you want to change one of the parameters and apply it to all 50 of your web servers, you can make a change to either the host profile, the service profile, or in the service, which will then be applied to all 50 web servers.
Monarch user interface
When you start the Monarch application you will see the menu items listed and described in the table below. The menu options are listed in a most likely use of left to right, although it depends on your design and management needs at the time as to what item you will start with. Each menu item offers various category options.
|Hosts||The Hosts option is used to define, manage, and delete hosts, a physical server, workstation, device, etc. that resides on your network. Host definitions are used in host groups, and profiles. Add generic services to hosts to create host services; delete host services. Arrange hosts into host groups. Manage other host-related objects.|
|Services||Services is used to define and manage services which run on hosts or some other type of metric associated with a host. Service definitions are used in host and service templates, and profiles.|
|Profiles||The Profiles option is used to define, modify, and import host and service profiles. Profiles are used to aid in the design and management of hosts and services.|
|Commands||The Commands option is used to define commands including service and host checks, service and host notifications, service and host event handlers. Command definitions are used in host and service templates, and profiles.|
|Time Periods||The Time Periods option is used to define a list of times during various days that are considered to be valid times for notifications and service checks. Time Period definitions are used in host and service templates, profiles, and contacts.|
|Contacts||The Contacts option is used to define who is to be contacted in the event of a problem on your network. Contact group definitions group one or more contacts together for the purpose of sending out alert/recovery notifications to all contacts in a contact group. Contact definitions are used in host and service templates, services, profiles, and escalations.|
|Escalations||The Escalations option is used to define host and service escalation trees. Escalations are used to escalate contact notifications for a particular service, host, or host group. An escalation tree is a grouping of multiple escalations which is then assigned to a host, host profile, host group, or a service to escalate notifications.|
|Groups||The Groups option is used to split hosts into different Nagios configuration files. In their most complex implementation they extend the configuration to Multiple Instances of Nagios. Groups can also determine group macro values applied to service checks.|
|Control||The Control option includes options used in Configuration administration, setup, and for controlling implementation.|