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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Server administration using Cockpit
    Cockpit makes it easy to manage Linux servers: Four mouse clicks in the browser restart the crashed web server, and four more interconnect the server's network interfaces. Pilots flying in this cockpit, though, have to cope with a few limitations.
  • Monitoring and service discovery with Consul
    When dozens of new services and VMs emerge and disappear every day in dynamic cloud environments, conventional monitoring provides false alarms, not operational security.
  • Understanding Autodiscovery

    A lack of information about your infrastructure can result in faulty system configuration and other difficulties. Automatic discovery of all hosts and services would seem to be the best solution – but can it also prove itself in practice?

  • Zabbix release 2.2
    Although Nagios gets lots of attention, the popular network monitoring tool Zabbix is free, can configure hosts for direct monitoring in the web interface, and now can also monitor VMware machines in version 2.2.
  • Network monitoring with Icinga and Raspberry Pi
    Icinga on the Raspberry Pi monitors your network, letting you see the good, the bad, and the ugly, so you can address problems proactively.
comments powered by Disqus