Step-by-Step Setup for the openitcockpit Monitoring System. Installation guide

Transcription

1 Step-by-Step Setup for the openitcockpit Monitoring System Installation guide

2 Version: May 2016 Legal it-novum GmbH Edelzeller Strasse Fulda Germany Tel: Fax:

3 Contents 1 System requirements Basic installation The Monitoring Dashboard Debugging Installing modules User management Creating hosts Services Commands Macros Maps Example: Setting up an MS SQL database monitoring instance Creating a service template Rolling out services using the service template groups and host groups

4 openitcockpit is a modular, open source framework based on the Naemon monitoring suite. openitcockpit not only provides infrastructure monitoring, but also makes it possible to acquire deep insights into IT processes and applications and can be used in conjunction with other tools for ticketing, change management, and/or IT documentation. Github download: 1 System requirements As of version 3.0.6, openitcockpit supports Ubuntu LTS x64. Minimum system requirements are 2 CPU cores, 2GB of RAM and 15GB of storage, which is sufficient for a small test system. Generally speaking, there is no golden rule for system requirements, as this always depends on how many hosts will be monitored and how many services will be assigned to the hosts. To achieve an average IT landscape and to establish a productive system, we recommend at least 32GB RAM, 16 CPU cores and 500GB of disk space. 2 Basic installation In this guide we will install openitcockpit with all front end modules and then briefly introduce these. For installation and operation, we recommend Naemon, but Nagios is also supported. Since openitcockpit can be obtained via the package manager app, we will first go to the repository and obtain the key: # echo 'deb trusty main' >/etc/apt/sources.list.d/openitcockpit.list To get the latest packages you can activate "nightly", but this must be done in addition to the trusty repository: # apt-key adv --recv keyserver hkp://keyserver.ubuntu.com A7D3EAFA You now need to do an apt update to import the new packet sources. Once this has been done we can begin with the actual openitcockpit installation itself: # apt-get update # apt-get install openitcockpit{,-naemon,-statusengine-naemon,-npcd} 4

5 There is no need to choose any options when asked about the configuration as nginx is already installed. We then run the setup script to perform the configuration: # /usr/share/openitcockpit/app/setup.sh During setup, the user(s) permitted to log on locally to openitcockpit will be created. Only one admin user will be created during setup.! Once setup has completed, this information can only be changed using the system front end; access credentials cannot otherwise be changed or viewed by others. The back end installation has now been completed and we can move on to the front end. 3 The Monitoring Dashboard We first need to log in with the user we created earlier during the initial setup. Once logged in, we will be in the Monitoring Dashboard. Figure 1: The openitcockpit Monitoring Dashboard 5

6 By default it provides a quick overview of hosts, services and planned downtimes. By clicking on the "Add Widget" button, additional graphics (e.g. diagrams or complex maps) can be added. By clicking on the plus symbol, new tabs can also be added. 4 Debugging After logging in, the user should have an instant overview of the Debugging page in addition to seeing the Dashboard. Here information regarding the current openitcockpit versions, running processes, the IP address of the openitcockpit server, memory usage, and an overview of the individual worker queues is available. Figure 2: Debugging informatio 6

7 5 Installing modules Figure 3: Overview of available modules In the open source version of openitcockpit, some modules are already activated. If the Enterprise version has been purchased, the license key must be entered via the Registration option. Depending on the scope of the license purchased, the associated modules will be activated once the license key has been entered. These can then be installed via the Package Manager.! It is important that the back end command # openitcockpit-update be executed once all the modules available to the user have been installed. In the complete version of the product, the modules check_nrpe (always available by default), AutoReport, MK (for check_mk), Distribute, Map, i-doit and Event Correlation will be available to use. After the installation and update have completed, the individual modules will be displayed in the menu on the left. 6 User management There are two options for creating new users: either by creating local users or by importing users via LDAP, if you have LDAP set up. This is done via System Settings, where access data and addresses are stored. 7

8 Every user can be assigned to a user group. This can be done using different parameters, e.g. whether the user has rights to access certain maps. The Manage User Roles function already contains two predefined standard roles.! It is important that the right permissions are set when a new module is installed so that all modules are visible to the admin. 7 Creating hosts Figure 4: Creating a host Click on the menu item Hosts and then NEW. Using the form that appears we store the data for the container in which the host will reside. It is important to select a template here. A host template is made available by default, but it is possible to create any number yourself. So, for an ESX system, for instance, it may be necessary to choose different settings than you would for an Exchange server. If only information regarding the host itself and the type of notifications is entered under Basic Settings, you can go ahead and select Check Commands under Expert Settings. You decide exactly what should be audited as well as the applicable thresholds and at what point any critical status is achieved. 8

9 This is also where you set how often a check should be attempted before it switches from soft state to hard state: Figure 5: Checks are set under "Expert Settings" 8 Services Under the motto "There's a service for every host", we'll next focus our attention on services. This is where we specify what on the host openitcockpit will be listening to. Much like with our hosts, we also have the opportunity here to generate service templates in advance or to edit the existing templates. This has the advantage that configuring the settings for the notifications and checks does not have to be performed manually. The figure shows a host to which three services have been allocated: 9

10 Figure 6: Host with three allocated services To make monitoring larger IT landscapes more comfortable, openitcockpit offers service template groups. Using template groups, we can easily provide the same types of hosts with the same checks.. To do this we create a new service template group by selecting the container where the previously defined service templates are stored. We can then add as many service templates to this group as we want. In the next step we can instantly add a single host or an entire host group to our group. Because openitcockpit currently only allows for pushing service template groups to hosts or host groups, we recommend that you only perform this step when all hosts have been fully set up. If a new host is added after the fact, the allocate function will have to be executed again. A pull function is on the roadmap for openitcockpit and is already in development. 9 Commands Under Commands the actual command lines can be edited and customized to suit your particular needs. The commands are divided into four categories: service, host, notification and event. In addition, you can also define arguments and immediately test the command in the integrated shell. The shell affords direct "access" to the openitcockpit back end and executes all commands via the Nagios user. Tip: The macros used in the commands (e.g. $USER$) can be edited under "Expert Monitoring" -> "User Defined Macros". 10

11 Figure 7: Editing the command line under "Commands" 10 Macros We recommend you make good use of the macros provided in openitcockpit. Doing so will save you a great deal of time and does not hard embed security-related data in commands. Because admin login data in most IT departments is the same across the majority of hosts, this data can be entered here and then used in the macros to perform the individual checks. In this way, after changing a password you do not have to carry out checks or execute commands manually. Figure 8: Creating macros 11 11

12 11 Maps Maps are a good way to concisely present entire IT landscapes and services or application availability in a graphical form. To do this, we create a map under the "Maps" module and edit it using the Map Editor. Here, we can upload a background image and add various gadgets, items or icons that can then be easily added to the map via drag and drop. After all items have been positioned, a pop-up window will appear in which the host and the services to be monitored can be set. In this way, various system landscape visualizations can be created from individual red-green maps to enormous graphical landscapes. These can then, of course, be integrated into the Dashboard homepage using a widget. Figure 9: Maps graphically display system landscapes in openitcockpit 12

13 12 Example: Setting up an MS SQL database monitoring instance Using openitcockpit, it is possible to monitor entire applications and application landscapes. As an example of the product's capabilities, we'll be setting up a database monitoring instance. First of all, we need to decide which plugin we are going to use for monitoring our system. In our example, we will be using the plugin check_mssql_health by Consol Labs, because outof-the-box it has the ability to read and monitor a great deal of information from an MS SQL database. You can find installation instructions, a download link, and information about the plugin's scope of application on the Consol Labs website: First, the plugin must be installed on the openitcockpit machine (please refer to the plugin installation instructions). After the installation has been completed, it can be found in /opt/openitc/nagios/libexec ready for use. It can then be used to remotely monitor a variety of information contained in the database. To do this, the database system must be accessible via the port used for the plugin and the user must have been assigned the appropriate permissions in the database. Initially, plugins should always be tested in the openitcockpit shell. This is to make sure the plugin functions correctly, that the desired database can be reached, and that sufficient access privileges exist. Help can be called up via #./check_mssql_health help A detailed description of the plugin and example queries can be found on the Consol Labs website. Using the following query we can test whether the database is generally accessible, whether the chosen user has sufficient permissions to access the database, and how much time is required to do this: #./check_mssql_health hostname Hostname --username Username --password Passwort - -port Port --commit --mode connection-time --warning Warning --critical Critical As output for querying the connection time we get: OK seconds to connect as User connection_time=0.96;1;5 The query can also be carried out without including the Warning and Critical threshold values since the plugin supplies its own default threshold values (in this case, 1 for "Warning" and 5 for "Critical"). 13

14 it-novum openitcockpit Installation Guide If the plugin is accessible via the openitcockpit shell and your are familiar with the various queries and monitoring capabilities, the check can be integrated into the openitcockpit front end as a command. We create a new command in openitcockpit under the section "Basic Monitoring -> _Commands" by clicking on the "+New" button. Depending on the query and monitoring function you want, it may make sense to create a variety of commands. By using variables ($ARG1$, $ARG2$, etc.), arguments can be flexibly created for various databases (hostname, port, user, password, mode, thresholds, etc.). It is, therefore, best that we determine what sort of command we are working with: service check, host check, notification or event hander. In our case, we are working with a service check command because we want to use the command in Services and Service Templates. You can choose any name you like, but we recommend that you invest some time in choosing your naming convention so that clarity and transparency are assured in large environments many commands may be used, so a well thought-out system will make managing things easier. The Command line area contains the commands that will later be called by the service in the openitcockpit shell and passed to the service. To ensure flexibility and clarity, as many variables as possible/necessary (e.g. $USER1$, $HOSTADDRESS$, $_HOSTMSSQLINFO$, $ARG1$, etc.) should be used. $USER1 is a "user defined macro" and contains the path in the shell to the directory with the plugins /opt/openitc/nagios/libexec. In the openitcockpit front end, macros are created and defined under Expert Monitoring -> User Defined Macros. $HOSTADDRESS$ is a standard Nagios macro and contains the IP address of each host that will later run the service. $_HOSTMSSQLINFO$ is a host macro that can be created and defined in the individual host settings under the expert settings area. In our case, this variable contains the port, username and password information of the individual database hosts. This will enable the service that will be created later to use the various database hosts without the need for any alterations. Under Description you can provide a correspondingly appropriate explanation for the command. Under Arguments we give each argument employed ($ARG1$, $ARG2$, etc.) a corresponding description that will be used in the service and service template we will create later. This greatly simplifies the definition of values for each variable. In the command shell at the bottom of the form the available plugins can be tested without having to connect to the server itself. After we have created the command, we set up a service template for the desired query. 14

15 it-novum openitcockpit Installation Guide 13 Creating a service template An individual service template should be created for each monitoring instance. Depending on the capabilities of the plugin and desired monitoring instance, a whole range of service templates can be put together. New service templates are created under "Basic Monitoring -> Service Templates" by using the "+New" button. To begin with, we need to define the container in which the service template will be created. The structure of the container can be configured to determine who can have what access to which objects in openitcockpit. Objects in the /root container are available to all users by default, which for service templates makes sense as they do not necessarily need to be/should be set up twice. You are free to name your templates whatever you like, but some thought should be given to a naming convention as in larger environments there can be a great many service templates in use. After entering a description, the areas "notification period", "notification interval", the status messages as well as graphing and active checks should be enabled. In the upper section of the Expert Settings tab, we will now define the values for the command arguments that will be passed to the command by default. These values can later be customized for every service used on different hosts. In the following figure you can see the more meaningful descriptions for the variables we defined in the command. Figure 10: Editing the service template 15

16 it-novum openitcockpit Installation Guide 14 Rolling out services using the service template groups and host groups To facilitate subsequent service template rollouts, it makes sense to consolidate all service templates and all hosts for a specific monitoring scenario into service template groups and host groups. To do this we need to add one or more new MS SQL servers just to the host group MSSQL_ALL and assign the service template group to the host group via "Allocate host group" all hosts will now receive all the services contained in the service template group in one go. By clicking on the Refresh monitoring configuration button (at the top right next to the system time), openitcockpit will accept all customizations made to your monitoring configuration and make these active our MS SQL database will now be monitored by openitcockpit. We have now completed the openitcockpit installation and made an initial step in application monitoring. 16