Monitoring Linux

Last updated: April 23. 2018

1. Introduction

Linux systems can be especially well monitored by Check_MK. This has less
to do with the Check_MK developer team ‘feeling at home’ with Linux –
rather it has more to do with Linux being a very open system, and it
providing numerous very well documented and easily queried interfaces which
enable a comprehensive monitoring operation.

The installation of a monitoring agent is essential, since most of the
interfaces are not in themselves accessible over a network. For this
reason Check_MK has its own agent for the monitoring of Linux. This is easy
to install and is economical in its use of system resources.

... transparent, because is is a shell script, in which you can see which command it is executing.

... secure, since it permits no access from the network whatsoever.

The agent consists of a simple shell script that is installed in
/usr/bin/check_mk_agent, and which invokes available system commands
sequentially in order to seek data for the monitoring. It routes its output
using either xinetd or systemd to TCP-Port 6556, or it is
alternatively called per SSH. Should you like neither of these procedures
you can also implement your own methods for Check_MK to receive data from agents.

Monitoring of information that the standard agent doesn't provide can be added
in the form of agent plug-ins. In the Check_MK Enterprise Edition you can bundle all settings and
plug-ins together with the agent into an RPM or DEB packet using the
Agent bakery, this packet can then be installed
with a single command and/or even be updated fully automatically.

2. Installation

2.1. Various options

Check_MK provides a number of ways to install a Linux agent – from the manual
installation of its separate components, to a fully automated deployment.
Some of these are only available in the Check_MK Enterprise Edition:

Method

Description

CRE

CEE

Included as standard RPM/DEB-Packet

Simple installation of a standard agent with a manual
configuration over configuration files

The packet from the agent bakery is initially installed manually or by using a script,
and subsequently from there updated automatically.

X

Manual installation

The individual files, without a packet, are copied to the target system and then
xinetd, systemd, SSH or a user's own access method are manually installed.

X

X

2.2. Installation using a RPM/DEB-Packet

The agent files are located in the Monitoring agents WATO module. In the Check_MK Enterprise Edition this will lead to the
Agent bakery. From here, with the Unpackaged agents
or Agent files (Version 1.4.0) buttons
the list of the agent files can be opened:

Everything required is in the first section called Packaged Agents.
Finished RPM and DEB packets for the installation of a Linux agent with
standard settings can be found here (the packet for Windows
with the .msi extension is also here):

Whether you require RPM or DEB is dependent on the Linux distribution on which
the packet is to be installed:

Attention: in the Linux/Unix-Agents section can be found the straight agent scripts
for the manual installation to /usr/bin/.
Only use these if the packeted agents do not function on your system, or if you wish to
monitor other Unix derivatives as Linux.

Exotic Linux distributions

Also, if the Check_MK-server only supports Enterprise-Linux distributions
that are still supported by their producer, the Check_MK-agent is
in such a case much less demanding. It supports every Linux distribution –
even ancient ‘dinosaurs’ on which a Version 2.4 core is running!
It is however possible that not all plug-ins will run correctly in the agent,
but the basic monitoring itself will function.

Installation with RPM

The installation of an agent with the RPM packet is very simple:

Download the agent packet with the *.rpm file extension.

With scp, WinSCP or similar, copy it to the target system to be monitored.

Install it there as root using the rpm -U command.

Next install the xinetd packet from your distribution, if it is not already installed.

Here is an example of a packet installation:

root@linux# rpm -U check-mk-agent-1.4.0p4-1.noarch.rpm

By the way, the -U stands for ‘Update’, but it can also perform an
initial installation correctly. This means that the same command can also be
used later for an update to a newer version.

The later installation of xinetd on Red Hat / CentOS is performed with:

root@linux# yum install xinetd

For SUSE Linux use zypper:

root@linux# zypper install xinetd

Following the installation an agent is immediately active and can be queried
through TCP Port 6556.

Installation with DEB

This procedure is the same as for RPM, only the commands are different.
An installation and a later update of the agent are both performed with:

root@linux# dpkg -i check-mk-agent_1.4.0p4-1_all.deb

A later installation of xinetd:

root@linux# apt-get install xinetd

Packet load over HTTP

Sometimes scp or WinSCP can be very laborious. The packet can also be
loaded directly from the Check_MK-server to the target system over HTTP.
For this purpose the agent file downloads have been deliberately made possible
without needing a login. The files after all contain no secrets. Anyone can download
and install Check_MK themselves and thus access the files.

The easiest method is to use wget. The URLs can be identified via the browser.
If you know the packet's name you can simply assemble the URL name yourself.
Then simply set /mysite/check_mk/agents/ before the file name:

The Check_MK Enterprise Edition utilises the Agent-Bakery via a
WATO-Modul to packetise individally customised agents. This process will be
described in the general chapter covering the Agents.

Installation of the baked packets is performed exactly as described above.

2.3. Automatic updates

If you use the agent bakery, the agent's automatic updates can set this up.
This process is described in its own article.

2.4. Manual installation

The manual installation of an agent is rarely necessary,
but is not very difficult. As well as the agent files from the site,
you also require the Linux/Unix agents box – here you will find
the Check_MK Agent for Linux file:

Load this file to the target system, and copy it to a directory that is
executable for root. /usr/local/bin/ is very well suited
for this, since it is found in the search path and has been conceived for the
user's own extensions. Here you can also work directly with wget:

Please don't forget the last two commands – these remove the .linux
file extension and make the file executable. If everything has been done
correctly the agent should now simply be a command that can be executed,
and which should generate its expected output. This also works if you are
not in /usr/local/bin. The | head truncates everything
after the 11th line:

In the case of a very old distribution which does not recognise the timeout
command, load the small program waitmax from the agent page and install
it likewise in /usr/local/bin. Both timeout and waitmax perform
the same function – they force a timeout when executing a program:

Waitmax was developed as a Check_MK component at a time when timeout
was not widely used. It has almost the same call syntax:

root@linux# waitmax --help
age: waitmax [-s SIGNUM] MAXTIME PROGRAM [ARGS...]
Execute PROGRAM as a subprocess. If PROGRAM does not exit before MAXTIME
seconds, it will be killed with SIGTERM or an alternative signal.
-s, --signal SIGNUM kill with SIGNUM on timeout
-h, --help this help
-V, --version show version an exit

Should you wish to configure or extend the agent, you will need to create
the required directories yourself. The location for the three required
directories is hard coded in variables that begin with MK_,
and which will also be provided to the plug-ins over the environment:

Here enter the IP-Address of your Check_MK-server that will be permitted to access
the agent under only_from.
Then only an activation is required and the agent will be ready:

root@linux# /etc/init.d/xinetd restart

3. Testing, and error diagnosis

Once the agent has been installed, the obvious question will surely be how
to test whether everything has been done correctly. All of the possibilities
that are available from the Check_MK-server are
described in the general chapter
on the agents. There are of course further diagnostic possibilities when one
is directly logged into the target system itself.

Since the ‘agent’ is basically nothing more than a simple program that obtains
data from your system and outputs it as loosely-formated text, you can also
invoke it as a program, and in fact do so quite easily:

Because the output can be rather long, less can also be very practical
here (you can quit it with the 'Q'-key):

root@linux# check_mk_agent | less

This output does not of course prove whether the agent is also accessible over
the network. But in this way it can be tested whether all of the desired data
is present in the output.

Incidentally – it is not essential to be root to be able to invoke
the agent, however it is possible that the output could be missing some information
which requires root-permissions to obtain
(e.g., multipath information and the output from ethtool).

Debug mode

So that possible erroneus outputs from defective plug-ins or commands do not
'corrupt' the real production data, as a matter of principle the agent suppresses
the standard error channel. If one is looking for a specific problem this can be
reactivated by invoking the agent with a special debug mode. This is done
with the -d option.
In so doing all of the shell commands which the agent executes will be output.

So that you can work with less here, the standard output and error
channels must be combined with 2>&1:

root@linux# check_mk_agent -d 2>&1 | less

4. Inclusion of standard check plug-ins

4.1. Executing plug-ins over MRPE

If you have migrated your monitoring from a Nagios-based solution to Check_MK,
it cannot be ruled out that you have existing check plug-ins of a standard form
for which no counterpart in Check_MK (yet) exists. In most cases these will be
self-written plug-ins in Perl or Shell.

The Check_MK-agent offers a simple mechanism that enables such plug-ins still
to be used: MK's Remote Plugin Executor or MRPE for short.
The name is intentionally an analogy to NRPE in Nagios, for which it
performs the same function.

The MRPE is integral in agents and is configured with a simple text file
which you yourself can save in /etc/check_mk/mrpe.cfg.
In this file enter one plug-in call per line – together with the name that
Check_MK should use for the service that is to be automatically created.
Here is an example:

If the agent is allowed to run locally, for each plug-in a new section will be
found with the title <<<mrpe>>>, containing the name,
exit code and output from the the plug-in. This can be verified with the
following practical grep-command:

The 0 or 2 in the output stand for the plug-in's exit codes
and conform to the standard pattern: 0 = OK, 1 =
WARN, 2 = CRIT and 3 = UNKNOWN.

The rest will be taken care of by Check_MK automatically. Once a service discovery
has been performed for the host, the two new services will be shown as
available. It will look like this (here in the new
display format in version 1.4.0):

Incidentally: due to the file's syntax the name may not contain blank characters.
With the help of the same syntax as used in URLs, a space can be replaced by
%20 – (the ASCII-Code 32 for ‘space’ is Hexadecimal 20):

4.2. Asynchronous execution

Please note that all plug-ins running in mrpe.cfg will be executed
synchronously and sequentially.
The plug-ins should thus not have overly long runtimes. If a plug-in hangs,
all following plug-ins will be delayed. This could lead to the agent's complete
retrievals under Check_MK entering a timeout, meaning that the host can no longer
be reliably monitored.

If you really require longer running plug-ins, these should be converted to
asynchronous processing, thus avoiding the problem described above.
For this, define a time frame in seconds for which a calculated result will be
valid – for example, 300 for five minutes.
To achieve this, set the expression (interval=300) following the service
name in mrpe.cfg:

The plug-in will be executed in a background process and will no longer hinder the agent's processing.

Because the agent no longer waits for the execution, the result will be delivered until the next call of the agent.

The plug-in will not be run before the defined 300 seconds have elapsed. Until that time the old result will be recycled.

With this method tests that require very long processing times,
as well as longer intervals, can also be run without needing to make changes to
the configuration on the Check_MK-server.

4.3. MRPE with the agent bakery

Proud owners of the Check_MK Enterprise Edition can also configure MRPE with the
Agent bakery. The rule set
Monitoring Agents ➳ Generic Options ➳ Execute MRPE Checks is responsible for this.
There you can configure the same things as described above.
The appropriate mrpe.cfg file will then be automatically generated by the bakery.

Baking the plug-ins

Likewise the Check plug-ins themselves can be delivered with the packet.
With these the agent will be complete and will require no manual installation
of additional files. This is all performed as follows:

Create the directory local/share/check_mk/agents/custom on the Check_MK-server

The Check plug-ins will be installed in your agent's standard-bin-directory.
By default this is /usr/bin. Then when configuring the MRPE-checks,
/usr/bin/check_foo will be required instead of /usr/local/bin/check_foo.

5. Agent for extending plug-ins

5.1. What are plug-ins?

The standard agent /usr/bin/check_mk_agent contains a whole series of
sections which provide monitoring data for various checks which will then be
found automatically by a service discovery. These include all of an operating
system's important monitorings.

Additionally, there is also the possibility of augmenting an agent with plug-ins.
These are small scripts or programs which are invoked by an agent to include
further sections with additional monitoring data. The Check_MK-Project delivers
a whole series of such plug-ins, which – when correctly installed and configured –
via a service discovery can provide new checks automatically.

Why are these plug-ins not simply built into the standard agent?
For each plug-in one of the following reasons prevents such an integration:

The plug-in is coded in a programming language other than Shell and thus cannot implemented inline (example: mk_logwatch).

The plug-in in any case requires a configuration without which it will not function (example: mk_oracle).

The plug-in is so specialised that most users will not require it (example: plesk_domains).

5.2. Manual installation of plug-ins

The plug-ins for Linux and UNIX included with the project are all located on the
Check_MK-server in local/share/check_mk/agents/plugins.
Additionally, these are available via the download page for the agents in WATO (as
described at the beginning of this article) in the Linux/Unix Agents - Plugins menu box:

For all of our standard agent plug-ins there are also the matching check plug-ins
which can evaluate the data and create services from these. They are ready to use
and do not require an extra installation.

Before installing a plug-in in an agent, please have a look at its associated file.
Important tips for the correct use of the plug-in can often be found there.

The actual installation is then simple: just save the file to
/usr/lib/check_mk_agent/plugins.
When doing this ensure that the file is executable.
If not, use a chmod 755, otherwise the agent will not run the plug-in.
Especially if the files are not transferred over scp, rather via HTTP
from the download page, the execution permissions will be lost!

Once a plug-in is executable and in the correct directory, it will be invoked
by the agent and a new section will be generated in the agents output.
This usually has the same name as the plug-in. Complex plug-ins (e.g.,
mk_oracle) in fact create a whole series of sections.

5.3. Configuration of plug-ins

Some plug-ins require a configuration file in /etc/check_mk/ to be able
to function. With others a configuration is optional and allows special features or
customisation. Others simply work as is. There are various sources of relevant information:

The documentation for the matching check plug-ins in the Check plugins WATO-module

Comments in the plug-in itself (often very helpful!)

A relevant article in this handbuch (e.g., on the monitoring of Oracle)

5.4. Asynchronous execution

In the same way as with MRPE plug-ins can process asynchronously.
This is very useful if the plug-ins have a very long runtime,
and the acquired status data in any case does not need to be refreshed every minute.

An asynchronous execution is not configured with a file. Instead, create a subdirectory
in plugins whose name is a numeric: representing a count of seconds. Plug-ins in this
directory will not only be executed asynchronously, at the same time with the second
count a minimum waiting time is also specified before the plug-in can be run again.
If the agent is again called before the specified time has elapsed, it will use
cached data from the last run of the plug-in. In this way an interval longer than
the typical one minute can in effect be configured for the plug-in.

The following example shows how the >my_foo_plugin plug-in can be changed from
synchronous to asynchronous execution, with a 5 minute interval.:

Please note that a few plug-ins are set up internally to inherently execute
asynchronously. Among these is mk_oracle.
Always install such plug-ins directly in /usr/lib/check_mk_agent/plugins!

5.5. Installing plug-ins using the bakery

Plug-ins included with Check_MK can be configured using the
Agent Bakery. This not only takes care of the installation
of the plug-ins themselves, but also for the correct generation of the configuration file
should one be required.

Each plug-in is configured with an agent rule. The appropriate rule set can be
found in Monitoring agentes ➳ Agent plugins:

5.6. Manual execution of plug-ins

Since agent plug-ins are executable programs, for testing and diagnosis
they can be manually started. There are however plug-ins which require specific
environment variables to be set by agents – so that they can find their
configuration file, for example. Set these variables manually before execution:

Some plug-ins have special invocation options for debugging. Just have a look in the plug-in!

6. Security

6.1. Considerations

Nowadays everything must be safe – and of course monitoring is no exception.
Because the monitoring agent is installed on every server being monitored,
a security problem here can have serious consequences.

For this reason emphasis is placed on security in the design of Check_MK,
and from the earliest days of Check_MK as been an unshakeable principle:
An agent reads no data from the network – full stop. Consequently it is
quite impossible that an attacker could sneak any type of command or script
element over the monitoring port 6556.

This alone provides such a high level of security that most users do without
additional measures in the LAN.
If the system being monitored is only accessible over an insecure internet connection,
then of course quite different precedures are necessary, and an encryption
with SSH would certainly be the ideal first choice.

From Version 1.4.0 the Check_MK-agent additionally includes an
inbuilt encryption, which represents a good comprise between security and
complexity.
In the following section we will show all of the options for protection in detail.

6.2. Restricting of access over IP-addresses

Even if an attacker is unable to execute commands, the monitoring data could
be useful to it as among other info, the data includes a list of all processes
running on the system. Is is therefore best that the data is accessible to nobody.

Xinetd

If the Check_MK-agents are as usual enabled over the xinetd, it is very
simple and effective to restrict the access to specific IP-addresses – to those
of the monitoring server of course. This is easily done, and was in fact
to be seen in the example above:

An attacker can of course easily falsify their IP-address and thus make a connection
to an agent – but it is very unlikely that it will receive an answer since this goes
to the genuine monitoring server. Or it really does receive an answer, but the
Check_MK-server looks down the pipe and will quickly record an error.

Systemd

Since Systemd is now the new toy that everyone uses, Linux distributors are
working hard to retire the good old Xinetd. The prepackaged Linux-Agent (not
one from the Bakery!) already installs itself with Systemd instruments,
if the target system is based on Systemd and no Xinetd is available.

Systemd however cannot perform such simple tasks as only_from
(Pöttering!!). One will be bluntly referred to iptables.
Should your agent thus, without Xinetd, be invoked purely with Systemd,
there is unfortunately no simpler possibility for restricting the IP-addresses,
other than using a firewall configuration.

If you are not yet one of the Systemd evangelists, there is however a simple
alternative: Even in Systemd-based systems it is (still) possible to use Xinetd.
This can be run as a service under Systemd – and again the method with
only_from as described above also works. To this end install
the xinetd packet, and then reinstall the Check_MK-agent –
this should then find and preferentially install Xinetd.

6.3. Invoking over SSH

The ultimate security for invoking a Check_MK-agent is offered by invoking it
via Secure Shell – in Linux in the form of an implementation of >OpenSSH.
This method is advisable for:

The monitoring of Linux servers that are only accessible over the internet.

The monitoring of computers in a DMZ.

Similar situations in which a TCP-connection from the Check_MK-Server to the agent is at all possible.

The setting-up is performed in the following steps:

Create an SSH-key pair especially for this purpose

Enable an access to the agent on the target system using these keys.

Disconnect the access over Xinetd.

Configure the Check_MK-Server so that SSH Port is used instead of the TCP-Connection.

And now the above procedure, step-by-step with all necessary details:

Creating SSH-key pairs

SSH works with a “Public-Key-Authorization”. For this purpose first create
a pair of complementary keys – one of which is public, and the other private.
This is performed by an instance user with ssh-keygen -t ed25519:

Important: do not enter a passphrase here! Encrypting the file with
the secret key will not achieve anything, because you won't want to have to
enter the passphrase every time you start the Check_MK-server...

Enabling access over SSH

The next step must be carried out on every Linux server that is to be
monitored over SSH. Log in to the server as root, and – if it
does not already exist – create the subdirectory .ssh in
the (/root) home directory:

root@linux# mkdir /root/.ssh

The permissions for this directory must be700 so that it
will be recognised by SSH. If you have created the directory yourself,
you will also require:

root@linux# chmod 700 /root/.ssh

Now open the authorized_keys file with the (console-based) text
editor of your choice. If the file does not already exist, it will be
generated automatically by the editor:

root@linux# vim /root/.ssh/authorized_keys

Now copy the content of the public keys into this file. This can be done,
for example, with the mouse and copy & paste. Be precise! Every blank character
is valid. Be careful to never have two blank characters together,
– AND, all of this is a single line!
If the file already exists, simply add this as a new line at the end of the file.

Restricting access to agent execution

Now for something very important! The SSH-key should be used exclusively
for executing the agent. SSH offers such a function under the name
Command restriction. For this, set the text command="/usr/bin/check_mk_agent"
at the beginning of the line which has just been created – separated from
the rest with one blank character. The result will look like this:

By the way, the request for the key fingerprint is received
only with the initial use. Should this not function, check the following:

Is the SSH-server actually installed on the target system?

Do the specified files and directories have the correct permissions?

Has the syntax in authorized_keys been coded correctly?

Has the correct public key been entered?

Have you logged in as the correct user (root@...)?

Have you thought of the command="...."?

Disconnecting access over Xinetd

The implementation of SSH is not much use if the access over Port 6556
remains possible as before.
To close the port, set Check_MK's Xinetd-service to disabled.
Do not delete the complete configuration file, as this will then
reappear with the next agent update anyway!

Migrating Check_MK's access to SSH

The target system is now ready. Now only the configuration of Check_MK itelf
needs to be done. This is performed via the rule set with {{Datasource programs|Individual
program call instead of agent access}}.
Create a rule here for the affected hosts, and enter the command ssh -T
-oStrictHostKeyChecking=no root@<IP>:

After saving and an Activate changes everything should function as intended!
For diagnostic purposes the commands cmk -D and cmk -d are well
suited, as explained in the Article about the command line.

Details concerning the ‘Datasource programs’ can be viewed in
its own article.

Multiple SSH-keys

It is also possible to work with more than one SSH-key. Save the keys to any chosen
directory. With ‘Datasource program’ the data path to the appropriate private key
must include the -i option. Ideally, use $OMD_ROOT as the substitute
for the path to to the instance directory (/omd/sites/mysite).
The configuration will then also be runnable in an instance with a different name:

Different host groups can use different SSH-keys, if multiple different rules are
used in Datasource programs.

6.4. Inbuilt encryption

From Check_MK Version 1.4.0, Linux – and also the
Windows Agent – can encrypt its own data without additional tools.
Strictly speaking, this is no substitute for an access control. But since an
attacker cannot send commands, and can't work with encrypted output data,
as a solution this is nearly as effective.

The complexity with the use of encryption and the additional CPU-load incurred
are both less than with the SSH method as described above, the method which we
nevertheless still recommend when transferring data over the internet.

The encryption of course requires a suitable configuration, both on the server
and in the agents.
This can be created manually (Check_MK Raw Edition) or with the Agent bakery (Check_MK Enterprise Edition).

Installation without the bakery

Even without the Agent bakery the first step is still performed in WATO:
by creating a Host & Service Parameters ➳ Access to agents ➳ Encryption rule in the rule set.
The rule should apply to all hosts for which an encryption will be implemented.
SNMP-hosts ignore this setting, so it is not necessary to explicitly exclude them.

Important is the Encryption for agent setting. As long as the rule retains
the default Disable, evrything naturally remains as in the old setup.
The choice is thus between:

Enable: Encryption is active, but data from unencrypted agents will continue to be accepted.

Enforce: Encryption is active, and only encrypted data will be accepted.

It makes sense to begin with Enable initially. Once you are satisfied that
all agents have been converted to encryption, switch over to Enforce,
in order to identify hosts which still send data as clear text.

The encryption makes use of a shared password which must be stored on both the
Check_MK-Server and on the agent as simple text (‘Shared secret’),
and which will be entered here. Choose a random password and have it ready for
the second step – the configuration of the agent.

Create the file /etc/check_mk/encryption.cfg with the following contents on the agent:

/etc/check_mk/encryption.cfg

ENCRYPTED=yes
PASSPHRASE='XEwks9fm'

Of course use your own password in PASSPHRASE. This file should definitely
be secured against reading by other users:

An invocation of check_mk_agent on the target system should produce a nonsense jumble of characters.

A telnet myhost123 6556 from the Check_MK-server should produce the same jumble.

A cmk -d myshost123 on the Check_MK-server should show the normal clear text.

Implementing with the bakery

The implementation of the encryption with the agent bakery is very simple.
By creating the rules as just described, one is basically finished. Now only new
agents need to be baked and distributed. The file /etc/check_mk/encryption.cfg
will be automatically generated and added to the agent packet.

7. Monitoring Linux over SNMP

Since an easily installed SNMP-Agenten is available for Linux, the question arises
whether it is possible or even desirable to monitor Linux over SNMP?
The answer is quite simple: possible yes, sensible no. Why is this so?

The monitoring data from the SNMP-agents is very limited, so that in any case Check_MK-agents are required for a halfway adequate monitoring.

The SNMP-agent delivers no useful data that isn't already provided by the Check_MK-Agent.

The SNMP-agent is time-consuming to install.

Last but not least, the SNMP protocol consumes far more CPU and network resources than a normal Check_MK monitoring.

There are however a few situations in which monitoring per SNMP in addition to
the normal agents can be sensible. Such a case would be when either a user's software,
or a hardware monitoring tool supplied by the server's manufacturer only delivers data via SNMP.

For such a situation, at the host's characteristics in the Host tags submenu in WATO,
set the Agent type to Dual: Check_MK Agent + SNMP.
Services that are accessible over SNMP as well as per Check_MK-agent
(e.g. CPU-load, file systems, network cards) will be automatically retrieved by
Check_MK-agent and not over SNMP.
In this way a duplicated data transfer will be automatically prevented.

8. Hardware monitoring

8.1. Fundamentals

To be as comprehensive as possible the monitoring of a Linux-server must of
course include the hardware. This is achieved in part directly with the Check_MK-agents,
and partly also using special plug-ins.
Additionally, there are also cases in which monitoring can be implemented per SNMP,
or even over a separate management board.

8.2. Monitoring the SMART-values

Modern hard drives almost always use S.M.A.R.T. (Self-Monitoring,
Analysis and Reporting Technology). This system continuously logs data on the condition
of the HDD or SSD, and with the smart plug-in Check_MK can retrieve
these values and evaluate the most important of them. In order that the plug-in
functions after an installation, the following preconditions must be met:

The smartmontools packet must be installed. This can be installed on all modern distributions with the appropriate packet manager.

If the drives are connected via a RAID-controller and this allows access to the SMART-values, the appropriate tool must also be installed.

tw_cli (3ware) and megacli (LSI) are supported.

If these prerequisites have been satisfied, and the plug-in has been installed,
the data will be automatically read and appended to the agent's output.
In Check_MK the new services can then also be activated directly:

8.3. Monitoring with the help of IPMI

IPMI (Intelligent Platform Management Interface) is an interface for hardware
management which, among other functions, enables the monitoring of hardware.
Check_MK uses freeipmi for this, in order to access the hardware directly
and without a network. It is installed from the packet source and is ready for
immediate use, so that the data will be transmitted at the next polling by Check_MK.

If freeipmi is not available, or there are other grounds preventing an
installation, ipmitool can also be used. This is often already present
on a system and must only served by an IPMI hardware driver – which can be provided
by the openipmi packet, for example.
Likewise, nothing more needs to be done here subsequently. The data will be
recorded by Check_MK automatically.

For error diagnosis the tools can also be executed manually in a host shell.
If the freeipmi packet has been installed it can be used to control the function:

8.4. Manufacturer-specific Tools

Many server producers offer their own tools for recording hardware
information and delivering this via SNMP.
The following prerequisites apply to be able to retrieve this data and
provide it to Check_MK:

An SNMP-server has been installed on the Linux host.

The manufacturer's tool has been installed – e.g., Dell's OpenManage or Supermicros SuperDoctor.

The host has been configured in Check_MK for an additional monitoring per SNMP, with Agent type set to Dual: Check_MK Agent + SNMP.

The new services for hardware monitoring thereby supported will then be
automatically recognised. No further plug-ins will be required.

8.5. Supplementary monitoring over the Management Board

From Version 1.4.0 a management board can be configured for every
host and additional data collected per SNMP. The services thereby recognised will
likewise be assigned to the host.

Setting up a management board is very easy. In the host's attributes, just enter
the protocol, the IP-address and the access data for SNMP, and save the new settings:

With a service discovery the newly-discovered services will then be activated as usual.

9. Files and directories

9.1. Data paths on the monitored system

Pfad

Function

/usr/bin/check_mk_agent

Installation location of the Check_MK-agents on the target system.

/etc/check_mk

Location of configuration files for the agents.

/etc/check_mk/mrpe.cfg

Configuration file for MRPE – for the execution of
standard, Nagios-compatible check plug-ins