« Previous 1 2 3 Next »
Application Monitoring with openITCOCKPIT
Velocity Sensor
Using the Shell, Macros, and Maps
The Basic Monitoring | Commands
item lets you edit the command line and customize it to suit your needs. The commands are divided into four categories: Service, Host, Notification, and Event. Additionally, you can define arguments here and test commands in the integrated shell. The shell gives you direct access to the openITCOCKPIT back end and executes all commands as the Nagios user. Tip: You can edit the macros used in the commands (e.g., $USER$
) under Expert Monitoring | User Defined Macros
.
We recommend using macros in openITCOCKPIT, which can save you a huge amount of time and does not hard code security-relevant data into commands. Because the admin login data on many of the hosts are identical in most IT departments, the values can be stored here and the macros then used for the individual checks. Thus, you do not have to change all the checks or commands manually after a password change.
Maps are a neat approach to visualizing IT environments and services and availability of applications in a clear-cut way. To do this, add a map in the Maps module and then edit the map in the editor. You can upload a background image and add various gadgets, items, or icons by simply dragging and dropping on the map. After positioning, a pop-up window appears, where you can set the host and the service to be monitored. The various visualizations of a system landscape, from single red-green maps to huge graphical landscapes, can be created. A widget also lets you integrate maps into in the dashboard on the homepage.
Monitoring a MS SQL Database
To set up database monitoring, you first need to consider what plugin to use. After all, you have a variety of ways to handle monitoring and therefore many plugins that can accomplish the task.
In our example, we used the check_mssql_ health
plugin by ConSol Labs, because it can read and monitor a large amount of information from a Microsoft SQL database out of the box. For installation instructions, a download link, and information about the use of the plugin, visit the ConSol labs website [3].
If you install the plugin on the openITCOCKPIT system according to the installation instructions, it will be available in the /opt/openitc/nagios/libexec
folder. Now you can remotely monitor a variety of information from the database, as long as the database management system is available at the port you use and you set up a user with the appropriate permissions in the database.
As a first step, you will always want to test a plugin in the openITCOCKPIT shell, so you can make sure it is working correctly, the database is accessible, and you have sufficient access permissions in place. For help, enter
./check_mssql_health --help
to get a detailed description of the plugin and sample queries on the ConSol Labs website.
We used the following query to test whether the database is accessible, whether the user has sufficient permissions to access the database, and how long it takes:
$ ./check_mssql_health --hostname <hostname> --username <username> --password <password> --port <port> --commit --mode connection-time --warning <warning> --critical <critical>
The output for the query relating to the connection time is: OK - 0.96 seconds to connect as user | connection_time=0.96;1;5 .
The query can be made without specifying threshold values for warning
and critical
because the plugin applies default threshold values (in this case 1 for warning and 5 for critical). If the plugin is usable in the openITCOCKPIT shell and you are familiar with its various query and monitoring capabilities, you can adopt the check as a command in the front end of openITCOCKPIT.
In openITCOCKPIT, you create a new command in the Basic monitoring | Commands
section by pressing the +New
button. Depending on the desired query and monitoring, it might make sense to create a number of commands. You can use them flexibly for various databases (hostname, port, user, password, mode, thresholds, etc.) through the use of variable arguments ($ARG1$
, $ARG2$
, etc.). You define what kind of a command it is: service check, host check, notification, or event handler.
In our case, it is a service check, because we want to use the command in services and service templates. The name can be changed freely, but we recommend putting some thought into naming to ensure greater clarity – many commands can be used in large environments, and a carefully considered nomenclature pays dividends.
The Command line
section contains the command that is called later by the service in the openITCOCKPIT server's shell and hands over the appropriate output to the service. To keep things clear-cut and flexible, you should use as many variables (i.e., $USER1$
, $HOSTADDRESS$
, $_HOSTMSSQLINFO$
, $ARG1$
, etc.) as possible or as necessary. $USER1$
is a user-defined macro and contains the path in the shell to the directory that contains the plugins (/opt/openitc/nagios/libexec
). In the openITCOCKPIT front end, the macros are created and defined in the Expert Monitoring | User Defined Macros
section.
$HOSTADDRESS$
is a standard Nagios macro and contains the IP address of each host on which the service will be used later. The $_HOSTMSSQLINFO$
variable is a host macro that can be created and defined in the respective host settings of the expert section. In our case, this variable contains information about the port, username, and password of the database host. In this way, a service created later can be used without adaptation on various database hosts.
Under Description
, enter an appropriate description for the command. In the Argument
section, type an intuitive description of each argument ($ARG1$
, $ARG2$
, etc.) that is available in the service and service template created later, which very much simplifies the task of defining values for each variable. In the Command Shell
at the end of the dialog, you can test the available plugin, without having to connect to the server. After creating the command, you now need to set up a service template for the desired query.
Creating a Service Template
You should create a separate service template for each monitor. A large number of service templates may come together, depending on the capabilities of the plugins and the desired monitoring.
You create new service templates in the Basic Monitoring | Service Templates field by pressing the +New button. To continue, you first define the container that will hold the service template. You can use the container structure to define who has what kind of access to which objects in openITCOCKPIT.
Objects in the root container are available by default to all users, which makes sense for the service templates, because you do not want to create them twice. You can choose the template name, but you determine this in advance, because larger environments use very many templates.
To assign a description, at least the following areas should be filled Notification period , Notification interval , the status message, graphing, and the active checks. For reasons of space, we cannot give a detailed description of the individual items here.
In the Expert settings tab, define the values for the arguments to be passed in to the command as defaults. These values can later be customized for every service that is used on any other host. Here, you also can see the intuitive descriptions of the variables that you defined in the command.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.