check mk documentation documentation
TRANSCRIPT
1 What is Monitoring all about? 3
2 Why monitor things? 5 2.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 What is a monitoring system? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 What is a check? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Active vs. Passive Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Check_MK Architecture 7 3.1 Check_MK Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Configuration & Check Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Livestatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Multisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 WATO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6 Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.8 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.9 Event Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Check_MK Quickstart 11 4.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 SMTP for outgoing emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 Time services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.7 Downloading Check_MK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.8 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.9 Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Create a Site 15 5.1 OMD command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 OMD config command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 Creating the site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Contacts 19 6.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 Contact Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i
7 Adding a Linux host 23 7.1 Agent bakery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2 Prebuilt package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3 Xinetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4 Adding host to OMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8 Adding a Windows host 25 8.1 Agent bakery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2 Prebuilt package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.3 Windows installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.4 Adding host to OMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9 Multisite 27 9.1 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2 Distributed monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ii
Welcome to our Check_MK documentation.
The documentation provided here is meant as a quick introduction to the Checkmk Enterprise Editi (CEE). The ma- jority of the information here should apply to the open source (RAW) versions as well.
If you find mistakes or feel you could contribute in helping us provide better documentation please dive in by visiting this github page.
The official Check_MK documentation is available at the following link https://checkmk.com/cms.html.
Contents:
What is Monitoring all about?
There are many definitions of what monitoring is and where it might be useful. For [https://spearhead.systems](our) purposes, as an IT service provider, the following defition fits well:
“Monitoring is a process by which we obtain information that we use to determine availbility and perfor- mance of systems”.
Systems are a bit harder to define and generally mean anything that has an IP address but it gets blurry as we start to look at services, processes, etc. Suffice it to say we monitor all aspects of modern IT infrastructures and all that they entail (containers, functions, clouds, physica/virtual servers, cooling units, storages, routers, etc.).
3
CHAPTER 2
Why monitor things?
Keeping an eye on IT systems provides many benefits for the entire business.
Availability, or the time the system is available and functional within normal parameters, is of interest to everyeone: any deviation from normal functionality could have impact to more than just computer systems, it could mean loss of money, damages or other negative results.
Through monitoring we obtain useful information about what these systems are doing and we use information that to help us better optimize and plan for the future (we call this future planning “capacity planning”).
An immediate effect of monitoring is that we get almost instant alerts when something is not functioning or is allto- gether missing. Longer term however we get insight into the systems and applications via trends, historical information and graphics that quickly identify patterns that may have otherwise never been observed.
With relevant and timely information you can move to a more ordered and predictable state. For some this means a shift in methodology from a “putting out the fires” mentality to a keeping them from happening in the first place.
So what can monitoring do for us? Lets take a look at it from the checkmk perspective and define some standard terminology to help us along.
2.1 States
States are determined by a measurement or a check. This verification or polling needs to be carried out regularly.
States give us information such as: is the system running, how much memory is being used?
2.2 Events
Events are more dynamic in their nature and therefore are not easily identified by a regular polling interval. Events may also be errors which only occur once making them that much more difficult to identify by regular checks. Examples of events are: disk I/O errors or hot-plug/add of a device.
2.3 What is a monitoring system?
A monitoring system is a piece of hardware or software that offers monitoring facilities. Usually such a system is state based that retrieves information from the monitored hosts via some mechanism. This information often called the check result is then processed, stored and possibly archived. The system will also provide methods to retrieve and display the check results.
2.4 What is a check?
A check is usually a piece of software running on a computer that does the measurement of a service. An example of a check is: opening a TCP connection to a web server and verifying the result. The check determines the state of a service.
2.5 Active vs. Passive Checks
In monitoring there is the concept of active and passive checks. An active check is triggered by the monitoring server usually through a poll or request.
A passive check is sent directly by the monitored server and the server has no influence on when this result is sent. Furthermore a passive check may not send a result during a specified time-frame and the monitoring server can raise an alarm at that point.
Now that we’ve got that out of the way let’s take a look at the checkmk architecture.
6 Chapter 2. Why monitor things?
CHAPTER 3
Check_MK Architecture
You should always know the architecture of your systems, networks, applications, etc. The more you know about the moving parts the easier it is to debug or troubleshoot something. Having detailed information about the inner workings of anything is extremely useful in identifying potential issues before or after an incident.
Below we will take a look at the Checkmk architecture so that you may know all of the components involved. This information will help you in scaling or identifying eventual performance issues as you should be able to spot the symptoms and associate them with functional components.
3.1 Check_MK Components
There are many components that make up the Checkmk monitoring system. Below you will find information about each of the major components.
7
Check_MK Documentation Documentation, Release
3.2 Configuration & Check Engine
The Checkmk CCE provides an elegant method for configuring your monitoring platform independently of the mon- itoring core you are using. You do not have to deal directly with typical configuration files since Checkmk takes care of automatic service discovery and the actual configuration. Checkmk provides a highly efficient method for doing checks: your hosts are contacted only once per Check Interval. The results are then sent to the monitoring core as passive checks. This results in a substantial reduction in resource usage.
Compare the above to how typical nagios (and most monitoring platforms) function: For every Check Interval (usually once per minute) you poll your hosts for every metric that you are interested in. So if you have one CPU and one Hard Disk you would have two checks every minute (one for the CPU and one for Hard Disk). Checkmk obtains both metrics in one efficient check. Imagine now that you have thousands of hosts and up to hundreds of thousands of checks, check_mk would save you considerable resources.
The Checkmk CCE takes care of creating complete configuration data necessary for your monitoring system. You can focus on gathering the information that is important to you and less on configuration files.
Official Checkmk CCE documentation is available here https://checkmk.com/cms.html
3.3 Livestatus
Livestatus provides a direct connection to Status Data on Hosts and Services via a UNIX-Socket. This enables Addons such as NagVis to have quick and efficient access to Status Data. The access is provided via a simple protocol and is accesible from all programming languages with no need for a special library - even from the Shell.
Official Livestatus documentation is available here https://checkmk.com/cms_livestatus.html
3.4 Multisite
The Web-GUI Multisite is usable without Check_MK’s Configuration & Check Engine. It is a modern-looking web interface with rapid page loading that offers user-definable configurations, distributed monitoring by integrating mul- tiple Monitoring-entities via Livestatus, integration of NagVis and PNP4Nagios, an integrated LDAP-connection, an access to Status Data via Web-services and much more. Multisite utilizes Livestatus for access to the Status Data.
Official Multisite documentation is available here https://checkmk.com/cms_user_interface.html
3.5 WATO
Check_MK’s Web Administration Tool makes the complete administration of a Check_MK-based system possible over a Browser. This is not restricted to the management of Hosts and Services and the typical Check_MK-rules, but also includes the management of users, roles, groups, time periods, classical Nagios-Checks and much more. With a modern roles concept authorizations can be assigned so that tasks can be reliably given to colleagues.
WATO is accessible from within Multisite via many of the contextual menu’s and buttons but also from the Sidebar snap-in named WATO.
8 Chapter 3. Check_MK Architecture
3.6 Notify
Check_MK’s new Notifications System makes the configuration of notifications simple and flexible. Multiple channels can be defined and differently configured per user. In this way for example, a full day’s emails, but SMS only for serious problems during on-call hours can be generated - without needing to define multiple artificial users. The users can additionally configure their notifications themselves.
Official Notify documentation is available here https://checkmk.com/cms_notifications.html
3.7 Business Intelligence
The BI-Module is integrated in the Multisite-GUI. It aggregates Status Data from numerous hosts and services to provide a complete status of complex applications and similar processes. This provides a quick overview for managers and users. Likewise questions about how concrete problems are affecting applications can be quickly answered. The integrated “What if?” - Analysis simplifies the downtime planning.
Official Business Intelligence documentation is available here https://checkmk.com/cms_bi.html
3.8 Mobile
The Mobile-Version of the Multisite-GUI is optimized for Smartphones and enables access to all Status Data. Com- mands such as Acknowledge and Set for Downtimes can be executed. The Mobile-GUI is automatically available when Multisite is installed. Mobile devices are automatically recognized.
3.6. Notify 9
3.9 Event Console
The Check_MK Event Console integrates the processing of log messages and SNMP-Traps into the monitoring. Its own Daemon - the mkeventd - is configured through a flexible Rule Set and determines which and how incoming messages are classified. In this way messages can be counted, correlated, anticipated, transcribed and much more. The Event Console even utilizes an inbuilt Syslog-Daemon that receives messages directly from Port 514.
Official Event Console documentation is available here https://checkmk.com/cms_ec.html
10 Chapter 3. Check_MK Architecture
CHAPTER 4
Check_MK Quickstart
The Check_MK monitoring system is designed to be quick to set-up so there is really only one way to go about this and it is quick by nature. Below we detail the steps necessary to get a Check_MK instance running.
4.1 Prerequisites
4.2 Operating System
You will need a preinstalled linux server running in a virtual machine, cloud or a physical server. Check_MK can be installed on the following linux server platforms:
• SuSE LINUX Enterprise Server (SLES) from version 11
• Red Hat Enterprise Linux (RHEL) from version 5.5
• CentOS from version 5.5
• Debian from version 6.0
• Ubuntu from version 10.04
4.3 Disk Space
Depending on the size of your install you will need to allocate the necessary disk space. Check_MK will store all of its files in the /opt/omd directory. While it is not a requirement for /opt/omd to be on a separate partition it could be advantageous for performance reasons to do so.
The necessary disk space will vary depending on the size of your installation which in turn depends on the number of hosts and services you will be monitoring. We have a site with about 40 hosts and 1000 services that takes up roughly 5GB. We usually recommend no less than 50GB for /opt for a site with up to 50 hosts. Your mileage will vary.
4.4 SMTP for outgoing emails
In order to send emails your SMTP service has to be configured correctly. Look at your distributions documentation for the proper configuration steps if you would like to use email notifications.
11
4.5 Time services
Monitoring is a time sensitive operation. You should make sure your server provides the right time. We recommend configuring the NTP time service to grab the right time from your local NTP servers. Once you set-up your monitoring instance it will automatically monitor time services.
Time is also important for geographically distributed sites. We recommend you set-up your hardware clock to UTC.
4.6 Repository
In order to install check_mk on a CentOS/Red Hat based server you need to have extra packages that are not available with the default system. To get your system ready you must set-up the EPEL Repository. This is easily accomplished with the installation of an RPM package for your specific distribution.
If for example you were running CentOS 6 or RHEL 6 the following command would set-up the EPEL repository.
root@linux# yum install https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
Debian and Ubuntu systems have all the necessary packages.
SuSE Linux needs some special attention which we will not cover here. You can get more details about what needs to be done for SuSE set-ups at the following link.
https://checkmk.com/cms_install_packages.html#SLES%2011
4.7 Downloading Check_MK
In your subscription area you can download the package for your operating environment.
Take note of the following selecting the package to download:
• First, select a version of Check_MK. If there are no reasons to the contrary, we recommend using the latest stable version.
• Name and version of your distribution must match exactly
• The architecture (32 or 64 bit) must match
• We always recommend the minimal packages. Full packages contain alternative software components such as Icinga or Thruk, which we offer but don’t support.
Copy the package to the Linux system where Check_MK is to be installed.
4.8 Installation
Debian and Ubuntu
On Debian, install the package gdebi (with Ubuntu, this is installed by default):
root@linux# apt-get install gdebi-core
Then install the Check_MK package using gdebi (with Ubuntu, not of course wheezy , but the appropriate package):
root@linux# gdebi omd-<version-arch>.deb
Finally, ensure that the Apache modules mod_proxy and mod_proxy_http are active using the following command:
12 Chapter 4. Check_MK Quickstart
With SLES, use the zypper tool with the install command:
root@linux# zypper install omd-<version-arch>.rpm
Red Hat and CentOS
root@linux# yum localinstall omd-<version-arch>.rpm
4.9 Confirmation
After you have successfully installed Check_MK and all of the necessary dependencies you will have access to the omd command.
The omd command allows you to set-up and manage monitoring instances. For a quick confirmation thatyour system is ready try the following command:
omd version
OMD - Open Monitoring Distribution Version 1.2.6b1.mmk
4.9. Confirmation 13
CHAPTER 5
Create a Site
Now that you have set-up your Check_MK server it is time to create a monitoring site. We last left off by confirming that we have access to the omd command. In the following steps we will use the omd command to create and manage our monitoring system.
5.1 OMD command
The omd command is used to create, update, delete, configure, start, stop and provides many other options for your monitoring sistes. omd can be used as the root user and thus it will have access to all of the monitoring sites or as the respective user of any one monitoring site in which case it will have access to only that particular site.
Here is example output from the omd command called as a site user:
[siteuser@omd ~]$ omd
Usage (called as site user): omd help Show general help omd version [SITE] Show version of OMD omd versions List installed OMD versions omd sites Show list of sites omd update Update site to other version of OMD omd start [SERVICE] Start services of one or all sites omd stop [SERVICE] Stop services of site(s) omd restart [SERVICE] Restart services of site(s) omd reload [SERVICE] Reload services of site(s) omd status [SERVICE] Show status of services of site(s) omd config ... Show and set site configuration parameters omd diff ([RELBASE]) Shows differences compared to the original version files omd umount Umount ramdisk volumes of site(s) omd backup SITE [-|ARCHIVE_PATH] Create a backup tarball of a site, writing it to a file or stdout
General Options: -V <version> set specific version, useful in combination with update/create omd COMMAND -h, --help show available options of COMMAND
Here is example out from the omd command called as the root user:
omd [root@cmk mariusp]# omd Usage (called as root):
omd help Show general help omd setup Prepare operating system for OMD (installs packages)
15
Check_MK Documentation Documentation, Release
omd uninstall Remove OMD and all sites! omd setversion VERSION Sets the default version of OMD which will be used by new sites omd version [SITE] Show version of OMD omd versions List installed OMD versions omd sites Show list of sites omd create SITE Create a new site (-u UID, -g GID) omd init SITE Populate site directory with default files and enable the site omd rm SITE Remove a site (and its data) omd disable SITE Disable a site (stop it, unmount tmpfs, remove Apache hook) omd enable SITE Enable a site (reenable a formerly disabled site) omd mv SITE NEWNAME Rename a site omd cp SITE NEWNAME Make a copy of a site omd update SITE Update site to other version of OMD omd start [SITE] [SERVICE] Start services of one or all sites omd stop [SITE] [SERVICE] Stop services of site(s) omd restart [SITE] [SERVICE] Restart services of site(s) omd reload [SITE] [SERVICE] Reload services of site(s) omd status [SITE] [SERVICE] Show status of services of site(s) omd config SITE ... Show and set site configuration parameters omd diff SITE ([RELBASE]) Shows differences compared to the original version files omd su SITE Run a shell as a site-user omd umount [SITE] Umount ramdisk volumes of site(s) omd backup SITE SITE [-|ARCHIVE_PATH] Create a backup tarball of a site, writing it to a file or stdout omd restore [SITE] [-|ARCHIVE_PATH] Restores the backup of a site to an existing site or creates a new site
General Options: -V <version> set specific version, useful in combination with update/create omd COMMAND -h, --help show available options of COMMAND
5.2 OMD config command
To configure your site as a user you issue the following
omd config
To configure your site as the root user you must also specify the site name as follows
omd config siteone
In either case you will get a graphical interface to aid you in configuration.
16 Chapter 5. Create a Site
Check_MK Documentation Documentation, Release
We recommend that for your first site you do not make any modifications since these options are for advanced usage.
Basic
• Autostart: Lets you choose if your site is started automatically during reboot of your server
• Core: Allows you to use the traditional nagios core or the microcore
• Crontab: Disables or enables site specific crontabs at boot time
• tmpfs: Disables or enables the use of a ramdisk for temporary files
Web GUI
• Apache Mode: Lets you choose to run a dedicated apache webserver for this site, or use the system webserver process directly
• Apache TCP_ADDR: Lets you choose the ip address of your apache webserver
• Apache TCP_PORT: Lets you choose the tcp port apache uses
• Default_GUI: Lets you choose other GUIs besides Check_MKs multisite GUI
• DOKUWIKI_AUTH: Enables the use of the dokuwiki user database for authentication instead of ~/etc/passwd
• MULTISITE_AUTHORISATION: Lets multisite manage the permissions of the addon users
• MULTISITE_COOKIE_AUTH: Enable or disable cookie based authentication
• NAGIOS_THEME: Switch between installed Nagios themes
Addons
• MKEVENTD: This option enables mkeventd - the event correlation and classification daemon of Check_MK
• MKNOTIFYD: Enables of disables Check_MKs notification spooler
5.2. OMD config command 17
Check_MK Documentation Documentation, Release
• NAGVIS_URLS: Lets you choose which GUI is used when clicking on the NagVis map icons
• PNP4NAGIOS: Lets you enable or disable PNP4Nagios, a great addon to store nagios performance data to round robin databases
Distributed Monitoring
• LIVEPROXYD: This option enables the livestatus proxy daemon
• LIVESTATUS_TCP: Make the livestatus proxy daemon listen on a tcp port in addition to the unix socket
5.3 Creating the site
To create a site you just run the following command.
omd create sitename
Replace sitename from the above command with the name of the site you would like to have, for example prod.
Once your site is created you will be presented with the following output:
root@linux# omd create prod Adding /opt/omd/sites/prod/tmp to /etc/fstab. Restarting Apache...OK Creating temporary filesystem /omd/sites/prod/tmp...OK Created new site prod with version 1.2.6b1.mmk.
The site can be started with omd start prod. The default web UI is available at http://<yourhost>/prod/ The admin user for the web applications is omdadmin with password omd. Please do a su - prod for administration of this site.
Take note of the information provided to you. You now have the following:
• a local site user named prod (the name of the site)
• an admin user for the web applications (named omdadmin with password omd)
• the link for your site (http://<yourhost>/prod)
Make sure you change the omdadmin password.
18 Chapter 5. Create a Site
Contacts
Check_MK has the concept of Contacts, Contact Groups and Roles. With OMD you will have one admin user created automatically with the initial site creation. The default admin username is omd and the default password is omdadmin (change these after your initial login).
Contacts are managed via WATO. Before you create a new user you should first think about how your users and hosts are organized and how they will use the site.
19
Check_MK Documentation Documentation, Release
Contacts are usually people you want to notify when something happens within your infrastructure. There are however many different ways to use a Contact such as a Multisite only users that does not receive notifications.
6.1 Roles
OMD has 3 default Roles. These are Admin, Guest and User.
• Admins have complete administrative control
• Users have some control over the objects they are assigned
• Guests users are usually limited only viewing data
Permissions can be assigned on very granular level so new Roles can be created to provide more complex permissions. By default only the admin role can configure permissions.
The best way to ge the hang of roles is to take a look at the Matrix within Roles & Permissions. The “X” means that functionality is “enabled” for that Role.
6.2 Contact Groups
Think of Contact Groups as your any other group: a container for holding something. Contact groups allow users to view and/or edit their hosts and services within Multisite but also to receive alerts and notifications via email, sms, etc.
Between Users, Contact Groups and Roles you can configure and assign many complex permissions but there is yet one more feature to help and it is called Rules. You can configure rules that automatically assign hosts and/or services to Contact Groups. This is a very elegant way of providing even more control over what your users and see within the monitoring site.
20 Chapter 6. Contacts
Check_MK Documentation Documentation, Release
To use Rules to configure automatic assignment of hosts and services to contact groups access WATO, Contact Groups and click on the Rules button.
6.2. Contact Groups 21
Check_MK Documentation Documentation, Release
22 Chapter 6. Contacts
Adding a Linux host
In order to monitor your Linux hosts you must install the check_mk agent and provide a way for the check_mk server to communicate with the agents.
Installation of the check_mk agent can be performed a couple of different ways. Below we cover the most common options:
• Use the agent bakery and “bake” your own agent
• Grab one directly from your existing OMD site(s)
7.1 Agent bakery
The agent bakery allows you to use the same powerful rules based engine from WATO to create agents for you monitored servers. From WATO, access the Monitoring Agents section, click on the Rules button and configure your agents accordingly.
Once you have created the rules to your specifications go back to the Monitoring Agents main page and click on the Bake Agents button.
Depending on your rules you will have one or more agents for one or more operating environments (rpm, deb, msi). You can click on the DEB/RPM/MSI link and download your agent.
Copy that agent over to your monitored server(s) and install according to your operating environment requirements.
7.2 Prebuilt package
All OMD site instances have prebuilt agents available in ~share/check_mk/agents. You will find there the MSI, RPM and DEB agent as well as the pure (script) agents (check_mk_agent.linux).
The RPM/DEB packages will place the check_mk_agent script (for linux/unix) environments in its proper place (/usr/bin). If you download the check_mk_agent.(linux|unix|*) script then you must make this file executable (chmod +x) and also place it in its proper place. You may also want to create the MK_LIBDIR (/usr/lib/check_mk_agent) and MK_CONFDIR (/etc/check_mk) for configuration variables or custom/local plugins (more on these later).
These prebuilt agents are also available via the OMD site URL: http://hostname_or_ip/<omd site name>/check_mk/agents/. At this URL you will also find additional plugins as well as the xinetd.conf config- uration file.
7.3 Xinetd
The easiest and quickest way to get up and running is to setup xinetd to ease communications between the check_mk server and the agent. In the prebuilt agents directory you also have an xinetd.conf file. Copy this file over to /etc/xinet.d/check_mk and edit accordingly. Usually you want to configure the only_from variable to allow con- nections only from your monitoring server.
After copying the xinetd configuration file restart the xinetd server and proceed to testing connectivity by telnetting from your monitoring server to your monitoring client on tcp port 6556.
user@host> telnet xyzhost123 6556 Trying 10.0.21.47... Connected to xyzhost123. Escape character is '^]'. <<<check_mk>>> Version: 1.1.8 AgentOS: linux <<<df>>> /dev/sda1 ext3 1008888 223832 733808 24% / /dev/sdc1 ext3 1032088 284648 695012 30% /lib/modules <<<ps>>> init [3] /sbin/syslogd /sbin/klogd -x /usr/sbin/cron /sbin/getty 38400 tty2
7.4 Adding host to OMD
After confirming that the agent is accessible you can access WATO, Hosts and click on New host. For our example you can fill out just the hostname and click on Save & go to Services button.
If the hostname is resolvable via DNS you do not need to also specify the IP address however if it is not then the IP address is a required field.
After this step you will be taken to the Services page where you can select and configure the services that check_mk has discovered on your server.
For every service discovered you can choose to:
1. View and edit parameters
2. Edit and analyze check parameters
3. Create a rule to permanently disable discovery of said service
4. Temporarily ignore the service
• Additional details can be found at the check_mk site [https://checkmk.com/cms_agent_linux.html](https://checkmk.com/cms_agent_linux.html)
24 Chapter 7. Adding a Linux host
Adding a Windows host
In order to monitor your Windows hosts you must install the check_mk agent and provide a way for the check_mk server to communicate with the agents.
Installation of the check_mk agent can be performed a couple of different ways. Below we cover the most common options:
• Use the agent bakery and “bake” your own agent
• Grab one directly from your existing OMD site(s)
8.1 Agent bakery
The agent bakery allows you to use the same powerful rules based engine from WATO to create agents for you monitored servers. From WATO, access the Monitoring Agents section, click on the Rules button and configure your agents accordingly.
Once you have created the rules to your specifications go back to the Monitoring Agents main page and click on the Bake Agents button.
Depending on your rules you will have one or more agents for one or more operating environments (rpm, deb, msi). You can click on the DEB/RPM/MSI link and download your agent.
Copy that agent over to your monitored server(s) and install according to your operating environment requirements.
8.2 Prebuilt package
All OMD site instances have prebuilt agents available in ~share/check_mk/agents. You will find there the MSI, RPM and DEB agent as well as the pure (script) agents (check_mk_agent.linux).
These prebuilt agents are also available via the OMD site URL: http://hostname_or_ip/<omd site name>/check_mk/agents/. At this URL you will also find additional plugins as well as the xinetd.conf config- uration file.
8.3 Windows installer
Check_MK Documentation Documentation, Release
/S - runs the installer silently /D= - sets the default installation directory
After installation the check_mk_agent service should have started automatically. You can confirm this by telnetting from your OMD site to the monitored server on tcp port 6556:
user@host> telnet xyzhost123 6556 <<<check_mk>>> Version: 1.2.5i5p3 BuildDate: Jul 28 2014 Architecture: 32bit AgentOS: windows Hostname: xyzhost123 WorkingDirectory: C:\Windows\system32 ConfigFile: C:\Program Files (x86)\check_mk\check_mk.ini AgentDirectory: C:\Program Files (x86)\check_mk PluginsDirectory: C:\Program Files (x86)\check_mk\plugins SpoolDirectory: C:\Program Files (x86)\check_mk\spool LocalDirectory: C:\Program Files (x86)\check_mk\local ScriptStatistics: Plugin C:0 E:0 T:0 Local C:0 E:0 T:0 OnlyFrom: 0.0.0.0/0 <<<uptime>>> 1929017 <<<df>>> C:\ NTFS 83991548 49014400 34977148 59% C:\ Share&ExchangeBackup NTFS 251658236 222849392 28808844 89% D:\ Exchange NTFS 150674428 73825484 76848944 49% E:\
8.4 Adding host to OMD
After confirming that the agent is accessible you can access WATO, Hosts and click on New host. For our example you can fill out just the hostname and click on Save & go to Services button.
If the hostname is resolvable via DNS you do not need to also specify the IP address however if it is not then the IP address is a required field.
After this step you will be taken to the Services page where you can select and configure the services that check_mk has discovered on your server.
For every service discovered you can choose to:
1. View and edit parameters
2. Edit and analyze check parameters
3. Create a rule to permanently disable discovery of said service
4. Temporarily ignore the service
• Additional details can be found at the check_mk site https://checkmk.de/cms_legacy_windows.html
26 Chapter 8. Adding a Windows host
Multisite
Check_MK utilises the intuitive Multisite web GUI for displaying monitoring status information. Multisite is based on Livestatus therefore it is extremely fast and responsive in large installations.
Multisite brings many features such as:
• User definable Views
• Customizable sidebar with dynamic content
• Automation and Webservice (API)
9.1 Views
Multisite allows each user to customize the builtin views or create completely new views. This is done in the GUI by flexibly combining datasources, layouts, filters, sortings, groupings, column-painters and inter-view-links. The idea behind is, that the administrators of the monitoring system should be able to create custom views for their users or customers, while those are presented a GUI as simple as possible.
The elements of views - like layouts, filters and so on - can be extended via Python using a plugin concept.
9.2 Distributed monitoring
Distributed monitoring is extremely useful in many situations. Check_MK allows for the centralized viewing of data as well as replication of data to remote sites.
There are many other functionalities that Multisite can offer. Your best option is to dive in and test out the functional- ities.
More details are available at the official documentation [https://checkmk.com/cms.html](https://checkmk.com/cms.html).
27
Why monitor things?
What is a check?
Active vs. Passive Checks
2 Why monitor things? 5 2.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 What is a monitoring system? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 What is a check? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Active vs. Passive Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Check_MK Architecture 7 3.1 Check_MK Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Configuration & Check Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Livestatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Multisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 WATO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6 Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.8 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.9 Event Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Check_MK Quickstart 11 4.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 SMTP for outgoing emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 Time services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.7 Downloading Check_MK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.8 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.9 Confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Create a Site 15 5.1 OMD command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 OMD config command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 Creating the site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Contacts 19 6.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2 Contact Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i
7 Adding a Linux host 23 7.1 Agent bakery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2 Prebuilt package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3 Xinetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4 Adding host to OMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8 Adding a Windows host 25 8.1 Agent bakery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2 Prebuilt package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.3 Windows installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.4 Adding host to OMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9 Multisite 27 9.1 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2 Distributed monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ii
Welcome to our Check_MK documentation.
The documentation provided here is meant as a quick introduction to the Checkmk Enterprise Editi (CEE). The ma- jority of the information here should apply to the open source (RAW) versions as well.
If you find mistakes or feel you could contribute in helping us provide better documentation please dive in by visiting this github page.
The official Check_MK documentation is available at the following link https://checkmk.com/cms.html.
Contents:
What is Monitoring all about?
There are many definitions of what monitoring is and where it might be useful. For [https://spearhead.systems](our) purposes, as an IT service provider, the following defition fits well:
“Monitoring is a process by which we obtain information that we use to determine availbility and perfor- mance of systems”.
Systems are a bit harder to define and generally mean anything that has an IP address but it gets blurry as we start to look at services, processes, etc. Suffice it to say we monitor all aspects of modern IT infrastructures and all that they entail (containers, functions, clouds, physica/virtual servers, cooling units, storages, routers, etc.).
3
CHAPTER 2
Why monitor things?
Keeping an eye on IT systems provides many benefits for the entire business.
Availability, or the time the system is available and functional within normal parameters, is of interest to everyeone: any deviation from normal functionality could have impact to more than just computer systems, it could mean loss of money, damages or other negative results.
Through monitoring we obtain useful information about what these systems are doing and we use information that to help us better optimize and plan for the future (we call this future planning “capacity planning”).
An immediate effect of monitoring is that we get almost instant alerts when something is not functioning or is allto- gether missing. Longer term however we get insight into the systems and applications via trends, historical information and graphics that quickly identify patterns that may have otherwise never been observed.
With relevant and timely information you can move to a more ordered and predictable state. For some this means a shift in methodology from a “putting out the fires” mentality to a keeping them from happening in the first place.
So what can monitoring do for us? Lets take a look at it from the checkmk perspective and define some standard terminology to help us along.
2.1 States
States are determined by a measurement or a check. This verification or polling needs to be carried out regularly.
States give us information such as: is the system running, how much memory is being used?
2.2 Events
Events are more dynamic in their nature and therefore are not easily identified by a regular polling interval. Events may also be errors which only occur once making them that much more difficult to identify by regular checks. Examples of events are: disk I/O errors or hot-plug/add of a device.
2.3 What is a monitoring system?
A monitoring system is a piece of hardware or software that offers monitoring facilities. Usually such a system is state based that retrieves information from the monitored hosts via some mechanism. This information often called the check result is then processed, stored and possibly archived. The system will also provide methods to retrieve and display the check results.
2.4 What is a check?
A check is usually a piece of software running on a computer that does the measurement of a service. An example of a check is: opening a TCP connection to a web server and verifying the result. The check determines the state of a service.
2.5 Active vs. Passive Checks
In monitoring there is the concept of active and passive checks. An active check is triggered by the monitoring server usually through a poll or request.
A passive check is sent directly by the monitored server and the server has no influence on when this result is sent. Furthermore a passive check may not send a result during a specified time-frame and the monitoring server can raise an alarm at that point.
Now that we’ve got that out of the way let’s take a look at the checkmk architecture.
6 Chapter 2. Why monitor things?
CHAPTER 3
Check_MK Architecture
You should always know the architecture of your systems, networks, applications, etc. The more you know about the moving parts the easier it is to debug or troubleshoot something. Having detailed information about the inner workings of anything is extremely useful in identifying potential issues before or after an incident.
Below we will take a look at the Checkmk architecture so that you may know all of the components involved. This information will help you in scaling or identifying eventual performance issues as you should be able to spot the symptoms and associate them with functional components.
3.1 Check_MK Components
There are many components that make up the Checkmk monitoring system. Below you will find information about each of the major components.
7
Check_MK Documentation Documentation, Release
3.2 Configuration & Check Engine
The Checkmk CCE provides an elegant method for configuring your monitoring platform independently of the mon- itoring core you are using. You do not have to deal directly with typical configuration files since Checkmk takes care of automatic service discovery and the actual configuration. Checkmk provides a highly efficient method for doing checks: your hosts are contacted only once per Check Interval. The results are then sent to the monitoring core as passive checks. This results in a substantial reduction in resource usage.
Compare the above to how typical nagios (and most monitoring platforms) function: For every Check Interval (usually once per minute) you poll your hosts for every metric that you are interested in. So if you have one CPU and one Hard Disk you would have two checks every minute (one for the CPU and one for Hard Disk). Checkmk obtains both metrics in one efficient check. Imagine now that you have thousands of hosts and up to hundreds of thousands of checks, check_mk would save you considerable resources.
The Checkmk CCE takes care of creating complete configuration data necessary for your monitoring system. You can focus on gathering the information that is important to you and less on configuration files.
Official Checkmk CCE documentation is available here https://checkmk.com/cms.html
3.3 Livestatus
Livestatus provides a direct connection to Status Data on Hosts and Services via a UNIX-Socket. This enables Addons such as NagVis to have quick and efficient access to Status Data. The access is provided via a simple protocol and is accesible from all programming languages with no need for a special library - even from the Shell.
Official Livestatus documentation is available here https://checkmk.com/cms_livestatus.html
3.4 Multisite
The Web-GUI Multisite is usable without Check_MK’s Configuration & Check Engine. It is a modern-looking web interface with rapid page loading that offers user-definable configurations, distributed monitoring by integrating mul- tiple Monitoring-entities via Livestatus, integration of NagVis and PNP4Nagios, an integrated LDAP-connection, an access to Status Data via Web-services and much more. Multisite utilizes Livestatus for access to the Status Data.
Official Multisite documentation is available here https://checkmk.com/cms_user_interface.html
3.5 WATO
Check_MK’s Web Administration Tool makes the complete administration of a Check_MK-based system possible over a Browser. This is not restricted to the management of Hosts and Services and the typical Check_MK-rules, but also includes the management of users, roles, groups, time periods, classical Nagios-Checks and much more. With a modern roles concept authorizations can be assigned so that tasks can be reliably given to colleagues.
WATO is accessible from within Multisite via many of the contextual menu’s and buttons but also from the Sidebar snap-in named WATO.
8 Chapter 3. Check_MK Architecture
3.6 Notify
Check_MK’s new Notifications System makes the configuration of notifications simple and flexible. Multiple channels can be defined and differently configured per user. In this way for example, a full day’s emails, but SMS only for serious problems during on-call hours can be generated - without needing to define multiple artificial users. The users can additionally configure their notifications themselves.
Official Notify documentation is available here https://checkmk.com/cms_notifications.html
3.7 Business Intelligence
The BI-Module is integrated in the Multisite-GUI. It aggregates Status Data from numerous hosts and services to provide a complete status of complex applications and similar processes. This provides a quick overview for managers and users. Likewise questions about how concrete problems are affecting applications can be quickly answered. The integrated “What if?” - Analysis simplifies the downtime planning.
Official Business Intelligence documentation is available here https://checkmk.com/cms_bi.html
3.8 Mobile
The Mobile-Version of the Multisite-GUI is optimized for Smartphones and enables access to all Status Data. Com- mands such as Acknowledge and Set for Downtimes can be executed. The Mobile-GUI is automatically available when Multisite is installed. Mobile devices are automatically recognized.
3.6. Notify 9
3.9 Event Console
The Check_MK Event Console integrates the processing of log messages and SNMP-Traps into the monitoring. Its own Daemon - the mkeventd - is configured through a flexible Rule Set and determines which and how incoming messages are classified. In this way messages can be counted, correlated, anticipated, transcribed and much more. The Event Console even utilizes an inbuilt Syslog-Daemon that receives messages directly from Port 514.
Official Event Console documentation is available here https://checkmk.com/cms_ec.html
10 Chapter 3. Check_MK Architecture
CHAPTER 4
Check_MK Quickstart
The Check_MK monitoring system is designed to be quick to set-up so there is really only one way to go about this and it is quick by nature. Below we detail the steps necessary to get a Check_MK instance running.
4.1 Prerequisites
4.2 Operating System
You will need a preinstalled linux server running in a virtual machine, cloud or a physical server. Check_MK can be installed on the following linux server platforms:
• SuSE LINUX Enterprise Server (SLES) from version 11
• Red Hat Enterprise Linux (RHEL) from version 5.5
• CentOS from version 5.5
• Debian from version 6.0
• Ubuntu from version 10.04
4.3 Disk Space
Depending on the size of your install you will need to allocate the necessary disk space. Check_MK will store all of its files in the /opt/omd directory. While it is not a requirement for /opt/omd to be on a separate partition it could be advantageous for performance reasons to do so.
The necessary disk space will vary depending on the size of your installation which in turn depends on the number of hosts and services you will be monitoring. We have a site with about 40 hosts and 1000 services that takes up roughly 5GB. We usually recommend no less than 50GB for /opt for a site with up to 50 hosts. Your mileage will vary.
4.4 SMTP for outgoing emails
In order to send emails your SMTP service has to be configured correctly. Look at your distributions documentation for the proper configuration steps if you would like to use email notifications.
11
4.5 Time services
Monitoring is a time sensitive operation. You should make sure your server provides the right time. We recommend configuring the NTP time service to grab the right time from your local NTP servers. Once you set-up your monitoring instance it will automatically monitor time services.
Time is also important for geographically distributed sites. We recommend you set-up your hardware clock to UTC.
4.6 Repository
In order to install check_mk on a CentOS/Red Hat based server you need to have extra packages that are not available with the default system. To get your system ready you must set-up the EPEL Repository. This is easily accomplished with the installation of an RPM package for your specific distribution.
If for example you were running CentOS 6 or RHEL 6 the following command would set-up the EPEL repository.
root@linux# yum install https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
Debian and Ubuntu systems have all the necessary packages.
SuSE Linux needs some special attention which we will not cover here. You can get more details about what needs to be done for SuSE set-ups at the following link.
https://checkmk.com/cms_install_packages.html#SLES%2011
4.7 Downloading Check_MK
In your subscription area you can download the package for your operating environment.
Take note of the following selecting the package to download:
• First, select a version of Check_MK. If there are no reasons to the contrary, we recommend using the latest stable version.
• Name and version of your distribution must match exactly
• The architecture (32 or 64 bit) must match
• We always recommend the minimal packages. Full packages contain alternative software components such as Icinga or Thruk, which we offer but don’t support.
Copy the package to the Linux system where Check_MK is to be installed.
4.8 Installation
Debian and Ubuntu
On Debian, install the package gdebi (with Ubuntu, this is installed by default):
root@linux# apt-get install gdebi-core
Then install the Check_MK package using gdebi (with Ubuntu, not of course wheezy , but the appropriate package):
root@linux# gdebi omd-<version-arch>.deb
Finally, ensure that the Apache modules mod_proxy and mod_proxy_http are active using the following command:
12 Chapter 4. Check_MK Quickstart
With SLES, use the zypper tool with the install command:
root@linux# zypper install omd-<version-arch>.rpm
Red Hat and CentOS
root@linux# yum localinstall omd-<version-arch>.rpm
4.9 Confirmation
After you have successfully installed Check_MK and all of the necessary dependencies you will have access to the omd command.
The omd command allows you to set-up and manage monitoring instances. For a quick confirmation thatyour system is ready try the following command:
omd version
OMD - Open Monitoring Distribution Version 1.2.6b1.mmk
4.9. Confirmation 13
CHAPTER 5
Create a Site
Now that you have set-up your Check_MK server it is time to create a monitoring site. We last left off by confirming that we have access to the omd command. In the following steps we will use the omd command to create and manage our monitoring system.
5.1 OMD command
The omd command is used to create, update, delete, configure, start, stop and provides many other options for your monitoring sistes. omd can be used as the root user and thus it will have access to all of the monitoring sites or as the respective user of any one monitoring site in which case it will have access to only that particular site.
Here is example output from the omd command called as a site user:
[siteuser@omd ~]$ omd
Usage (called as site user): omd help Show general help omd version [SITE] Show version of OMD omd versions List installed OMD versions omd sites Show list of sites omd update Update site to other version of OMD omd start [SERVICE] Start services of one or all sites omd stop [SERVICE] Stop services of site(s) omd restart [SERVICE] Restart services of site(s) omd reload [SERVICE] Reload services of site(s) omd status [SERVICE] Show status of services of site(s) omd config ... Show and set site configuration parameters omd diff ([RELBASE]) Shows differences compared to the original version files omd umount Umount ramdisk volumes of site(s) omd backup SITE [-|ARCHIVE_PATH] Create a backup tarball of a site, writing it to a file or stdout
General Options: -V <version> set specific version, useful in combination with update/create omd COMMAND -h, --help show available options of COMMAND
Here is example out from the omd command called as the root user:
omd [root@cmk mariusp]# omd Usage (called as root):
omd help Show general help omd setup Prepare operating system for OMD (installs packages)
15
Check_MK Documentation Documentation, Release
omd uninstall Remove OMD and all sites! omd setversion VERSION Sets the default version of OMD which will be used by new sites omd version [SITE] Show version of OMD omd versions List installed OMD versions omd sites Show list of sites omd create SITE Create a new site (-u UID, -g GID) omd init SITE Populate site directory with default files and enable the site omd rm SITE Remove a site (and its data) omd disable SITE Disable a site (stop it, unmount tmpfs, remove Apache hook) omd enable SITE Enable a site (reenable a formerly disabled site) omd mv SITE NEWNAME Rename a site omd cp SITE NEWNAME Make a copy of a site omd update SITE Update site to other version of OMD omd start [SITE] [SERVICE] Start services of one or all sites omd stop [SITE] [SERVICE] Stop services of site(s) omd restart [SITE] [SERVICE] Restart services of site(s) omd reload [SITE] [SERVICE] Reload services of site(s) omd status [SITE] [SERVICE] Show status of services of site(s) omd config SITE ... Show and set site configuration parameters omd diff SITE ([RELBASE]) Shows differences compared to the original version files omd su SITE Run a shell as a site-user omd umount [SITE] Umount ramdisk volumes of site(s) omd backup SITE SITE [-|ARCHIVE_PATH] Create a backup tarball of a site, writing it to a file or stdout omd restore [SITE] [-|ARCHIVE_PATH] Restores the backup of a site to an existing site or creates a new site
General Options: -V <version> set specific version, useful in combination with update/create omd COMMAND -h, --help show available options of COMMAND
5.2 OMD config command
To configure your site as a user you issue the following
omd config
To configure your site as the root user you must also specify the site name as follows
omd config siteone
In either case you will get a graphical interface to aid you in configuration.
16 Chapter 5. Create a Site
Check_MK Documentation Documentation, Release
We recommend that for your first site you do not make any modifications since these options are for advanced usage.
Basic
• Autostart: Lets you choose if your site is started automatically during reboot of your server
• Core: Allows you to use the traditional nagios core or the microcore
• Crontab: Disables or enables site specific crontabs at boot time
• tmpfs: Disables or enables the use of a ramdisk for temporary files
Web GUI
• Apache Mode: Lets you choose to run a dedicated apache webserver for this site, or use the system webserver process directly
• Apache TCP_ADDR: Lets you choose the ip address of your apache webserver
• Apache TCP_PORT: Lets you choose the tcp port apache uses
• Default_GUI: Lets you choose other GUIs besides Check_MKs multisite GUI
• DOKUWIKI_AUTH: Enables the use of the dokuwiki user database for authentication instead of ~/etc/passwd
• MULTISITE_AUTHORISATION: Lets multisite manage the permissions of the addon users
• MULTISITE_COOKIE_AUTH: Enable or disable cookie based authentication
• NAGIOS_THEME: Switch between installed Nagios themes
Addons
• MKEVENTD: This option enables mkeventd - the event correlation and classification daemon of Check_MK
• MKNOTIFYD: Enables of disables Check_MKs notification spooler
5.2. OMD config command 17
Check_MK Documentation Documentation, Release
• NAGVIS_URLS: Lets you choose which GUI is used when clicking on the NagVis map icons
• PNP4NAGIOS: Lets you enable or disable PNP4Nagios, a great addon to store nagios performance data to round robin databases
Distributed Monitoring
• LIVEPROXYD: This option enables the livestatus proxy daemon
• LIVESTATUS_TCP: Make the livestatus proxy daemon listen on a tcp port in addition to the unix socket
5.3 Creating the site
To create a site you just run the following command.
omd create sitename
Replace sitename from the above command with the name of the site you would like to have, for example prod.
Once your site is created you will be presented with the following output:
root@linux# omd create prod Adding /opt/omd/sites/prod/tmp to /etc/fstab. Restarting Apache...OK Creating temporary filesystem /omd/sites/prod/tmp...OK Created new site prod with version 1.2.6b1.mmk.
The site can be started with omd start prod. The default web UI is available at http://<yourhost>/prod/ The admin user for the web applications is omdadmin with password omd. Please do a su - prod for administration of this site.
Take note of the information provided to you. You now have the following:
• a local site user named prod (the name of the site)
• an admin user for the web applications (named omdadmin with password omd)
• the link for your site (http://<yourhost>/prod)
Make sure you change the omdadmin password.
18 Chapter 5. Create a Site
Contacts
Check_MK has the concept of Contacts, Contact Groups and Roles. With OMD you will have one admin user created automatically with the initial site creation. The default admin username is omd and the default password is omdadmin (change these after your initial login).
Contacts are managed via WATO. Before you create a new user you should first think about how your users and hosts are organized and how they will use the site.
19
Check_MK Documentation Documentation, Release
Contacts are usually people you want to notify when something happens within your infrastructure. There are however many different ways to use a Contact such as a Multisite only users that does not receive notifications.
6.1 Roles
OMD has 3 default Roles. These are Admin, Guest and User.
• Admins have complete administrative control
• Users have some control over the objects they are assigned
• Guests users are usually limited only viewing data
Permissions can be assigned on very granular level so new Roles can be created to provide more complex permissions. By default only the admin role can configure permissions.
The best way to ge the hang of roles is to take a look at the Matrix within Roles & Permissions. The “X” means that functionality is “enabled” for that Role.
6.2 Contact Groups
Think of Contact Groups as your any other group: a container for holding something. Contact groups allow users to view and/or edit their hosts and services within Multisite but also to receive alerts and notifications via email, sms, etc.
Between Users, Contact Groups and Roles you can configure and assign many complex permissions but there is yet one more feature to help and it is called Rules. You can configure rules that automatically assign hosts and/or services to Contact Groups. This is a very elegant way of providing even more control over what your users and see within the monitoring site.
20 Chapter 6. Contacts
Check_MK Documentation Documentation, Release
To use Rules to configure automatic assignment of hosts and services to contact groups access WATO, Contact Groups and click on the Rules button.
6.2. Contact Groups 21
Check_MK Documentation Documentation, Release
22 Chapter 6. Contacts
Adding a Linux host
In order to monitor your Linux hosts you must install the check_mk agent and provide a way for the check_mk server to communicate with the agents.
Installation of the check_mk agent can be performed a couple of different ways. Below we cover the most common options:
• Use the agent bakery and “bake” your own agent
• Grab one directly from your existing OMD site(s)
7.1 Agent bakery
The agent bakery allows you to use the same powerful rules based engine from WATO to create agents for you monitored servers. From WATO, access the Monitoring Agents section, click on the Rules button and configure your agents accordingly.
Once you have created the rules to your specifications go back to the Monitoring Agents main page and click on the Bake Agents button.
Depending on your rules you will have one or more agents for one or more operating environments (rpm, deb, msi). You can click on the DEB/RPM/MSI link and download your agent.
Copy that agent over to your monitored server(s) and install according to your operating environment requirements.
7.2 Prebuilt package
All OMD site instances have prebuilt agents available in ~share/check_mk/agents. You will find there the MSI, RPM and DEB agent as well as the pure (script) agents (check_mk_agent.linux).
The RPM/DEB packages will place the check_mk_agent script (for linux/unix) environments in its proper place (/usr/bin). If you download the check_mk_agent.(linux|unix|*) script then you must make this file executable (chmod +x) and also place it in its proper place. You may also want to create the MK_LIBDIR (/usr/lib/check_mk_agent) and MK_CONFDIR (/etc/check_mk) for configuration variables or custom/local plugins (more on these later).
These prebuilt agents are also available via the OMD site URL: http://hostname_or_ip/<omd site name>/check_mk/agents/. At this URL you will also find additional plugins as well as the xinetd.conf config- uration file.
7.3 Xinetd
The easiest and quickest way to get up and running is to setup xinetd to ease communications between the check_mk server and the agent. In the prebuilt agents directory you also have an xinetd.conf file. Copy this file over to /etc/xinet.d/check_mk and edit accordingly. Usually you want to configure the only_from variable to allow con- nections only from your monitoring server.
After copying the xinetd configuration file restart the xinetd server and proceed to testing connectivity by telnetting from your monitoring server to your monitoring client on tcp port 6556.
user@host> telnet xyzhost123 6556 Trying 10.0.21.47... Connected to xyzhost123. Escape character is '^]'. <<<check_mk>>> Version: 1.1.8 AgentOS: linux <<<df>>> /dev/sda1 ext3 1008888 223832 733808 24% / /dev/sdc1 ext3 1032088 284648 695012 30% /lib/modules <<<ps>>> init [3] /sbin/syslogd /sbin/klogd -x /usr/sbin/cron /sbin/getty 38400 tty2
7.4 Adding host to OMD
After confirming that the agent is accessible you can access WATO, Hosts and click on New host. For our example you can fill out just the hostname and click on Save & go to Services button.
If the hostname is resolvable via DNS you do not need to also specify the IP address however if it is not then the IP address is a required field.
After this step you will be taken to the Services page where you can select and configure the services that check_mk has discovered on your server.
For every service discovered you can choose to:
1. View and edit parameters
2. Edit and analyze check parameters
3. Create a rule to permanently disable discovery of said service
4. Temporarily ignore the service
• Additional details can be found at the check_mk site [https://checkmk.com/cms_agent_linux.html](https://checkmk.com/cms_agent_linux.html)
24 Chapter 7. Adding a Linux host
Adding a Windows host
In order to monitor your Windows hosts you must install the check_mk agent and provide a way for the check_mk server to communicate with the agents.
Installation of the check_mk agent can be performed a couple of different ways. Below we cover the most common options:
• Use the agent bakery and “bake” your own agent
• Grab one directly from your existing OMD site(s)
8.1 Agent bakery
The agent bakery allows you to use the same powerful rules based engine from WATO to create agents for you monitored servers. From WATO, access the Monitoring Agents section, click on the Rules button and configure your agents accordingly.
Once you have created the rules to your specifications go back to the Monitoring Agents main page and click on the Bake Agents button.
Depending on your rules you will have one or more agents for one or more operating environments (rpm, deb, msi). You can click on the DEB/RPM/MSI link and download your agent.
Copy that agent over to your monitored server(s) and install according to your operating environment requirements.
8.2 Prebuilt package
All OMD site instances have prebuilt agents available in ~share/check_mk/agents. You will find there the MSI, RPM and DEB agent as well as the pure (script) agents (check_mk_agent.linux).
These prebuilt agents are also available via the OMD site URL: http://hostname_or_ip/<omd site name>/check_mk/agents/. At this URL you will also find additional plugins as well as the xinetd.conf config- uration file.
8.3 Windows installer
Check_MK Documentation Documentation, Release
/S - runs the installer silently /D= - sets the default installation directory
After installation the check_mk_agent service should have started automatically. You can confirm this by telnetting from your OMD site to the monitored server on tcp port 6556:
user@host> telnet xyzhost123 6556 <<<check_mk>>> Version: 1.2.5i5p3 BuildDate: Jul 28 2014 Architecture: 32bit AgentOS: windows Hostname: xyzhost123 WorkingDirectory: C:\Windows\system32 ConfigFile: C:\Program Files (x86)\check_mk\check_mk.ini AgentDirectory: C:\Program Files (x86)\check_mk PluginsDirectory: C:\Program Files (x86)\check_mk\plugins SpoolDirectory: C:\Program Files (x86)\check_mk\spool LocalDirectory: C:\Program Files (x86)\check_mk\local ScriptStatistics: Plugin C:0 E:0 T:0 Local C:0 E:0 T:0 OnlyFrom: 0.0.0.0/0 <<<uptime>>> 1929017 <<<df>>> C:\ NTFS 83991548 49014400 34977148 59% C:\ Share&ExchangeBackup NTFS 251658236 222849392 28808844 89% D:\ Exchange NTFS 150674428 73825484 76848944 49% E:\
8.4 Adding host to OMD
After confirming that the agent is accessible you can access WATO, Hosts and click on New host. For our example you can fill out just the hostname and click on Save & go to Services button.
If the hostname is resolvable via DNS you do not need to also specify the IP address however if it is not then the IP address is a required field.
After this step you will be taken to the Services page where you can select and configure the services that check_mk has discovered on your server.
For every service discovered you can choose to:
1. View and edit parameters
2. Edit and analyze check parameters
3. Create a rule to permanently disable discovery of said service
4. Temporarily ignore the service
• Additional details can be found at the check_mk site https://checkmk.de/cms_legacy_windows.html
26 Chapter 8. Adding a Windows host
Multisite
Check_MK utilises the intuitive Multisite web GUI for displaying monitoring status information. Multisite is based on Livestatus therefore it is extremely fast and responsive in large installations.
Multisite brings many features such as:
• User definable Views
• Customizable sidebar with dynamic content
• Automation and Webservice (API)
9.1 Views
Multisite allows each user to customize the builtin views or create completely new views. This is done in the GUI by flexibly combining datasources, layouts, filters, sortings, groupings, column-painters and inter-view-links. The idea behind is, that the administrators of the monitoring system should be able to create custom views for their users or customers, while those are presented a GUI as simple as possible.
The elements of views - like layouts, filters and so on - can be extended via Python using a plugin concept.
9.2 Distributed monitoring
Distributed monitoring is extremely useful in many situations. Check_MK allows for the centralized viewing of data as well as replication of data to remote sites.
There are many other functionalities that Multisite can offer. Your best option is to dive in and test out the functional- ities.
More details are available at the official documentation [https://checkmk.com/cms.html](https://checkmk.com/cms.html).
27
Why monitor things?
What is a check?
Active vs. Passive Checks