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