Product SiteDocumentation Site

12.4. 監視

監視は一般的な用語で、さまざまな目的で行われるさまざまな活動を意味します。すなわち一方では、マシンの提供するリソースが使い切られ、更新が必要になることを予測することが可能です。さらに他方では、サービスが利用できなくなったり適切に動作していないことを可能な限り早く管理者に警告することにより、発生した問題の早急な修正を可能にすることを意味します。
Munin は最初の範囲をカバーします。すなわち Munin はいくつかのパラメータの経時変化をグラフィカルに図示します (使用された RAM、専有されたディスク領域、プロセッサの負荷、ネットワークトラフィック、Apache/MySQL の負荷などを図示します)。Nagios は 2 番目の範囲をカバーします。すなわち Nagios はサービスの稼働状態と利用可能状態を定期的に確認し、適切な経路 (電子メール、テキストメッセージなど) を通じて警告を送信します。Munin と Nagios はモジュール式に設計されているので、特定のパラメータやサービスを監視する新しいプラグインを簡単に作成できます。

ALTERNATIVE Zabbix、統合監視ツール

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.
→ https://zabbix.com/

ALTERNATIVE Icinga、Nagios のフォーク

Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.
→ https://icinga.com/

12.4.1. Munin のセットアップ

Munin の目的は多くのマシンを監視することです。そしてこのため、Munin は当然クライアント/サーバアーキテクチャを採用しています。グラフ化を担当している中央ホストがすべての監視されているホストからデータを収集し、データの履歴グラフを生成します。

12.4.1.1. 監視対象ホストの設定

最初に munin-node パッケージをインストールします。munin-node パッケージによってインストールされるデーモンはポート 4949 番をリッスンし、すべての動作しているプラグインによって収集されたデータを送り返します。それぞれのプラグインは収集されたデータの説明および最新の計測値を返す簡単なプログラムです。プラグインは /usr/share/munin/plugins/ に保存されますが、実際に使われるのは /etc/munin/plugins/ 内からシンボリックリンクを張られたプラグインだけです。
When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this auto-configuration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery can be interesting even though not all plugins have comprehensive documentation.
→ https://gallery.munin-monitoring.org
However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.
Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves allow directives in the /etc/munin/munin-node.conf file. The default configuration is allow ^127\.0\.0\.1$, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with systemctl restart munin-node.

GOING FURTHER ローカルプラグインの作成

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.
→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html
プラグインを検査するには、プラグインが munin-node から実行されたのと同じ状況下で実行するのが最良の方法です。この状況を模倣するには root で munin-run plugin を実行します。このコマンドに与えられた 2 番目のパラメータ (config など) はパラメータとしてプラグインに渡されます。
プラグインに config パラメータを付けて実行した場合、プラグイン自身を説明する一連のフィールドが返されます。 
# munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average
The various available fields are described by the “Plugin reference” available as part of the “Munin guide”.
→ https://munin.readthedocs.org/en/latest/reference/plugin.html
パラメータを付けずにプラグインを実行した場合、プラグインは最新の計測値を返却します。従って、たとえば sudo munin-run load を実行すると load.value 0.12 が返されます。
最後に、プラグインに autoconf パラメータを付けて実行した場合、プラグインは自分が対象のホストで有効化されているか否かに基づいて「yes」(終了ステータス 0) または「no」(終了ステータス 1) を返すべきです。

12.4.1.2. グラフ化担当マシンの設定

「グラフ化担当マシン」はデータを集計し対応するグラフを生成するだけのコンピュータです。「グラフ化担当マシン」に必要なソフトウェアは munin パッケージに含まれます。標準的な設定は munin-cron を (5 分ごとに) 実行します。このコマンドは /etc/munin/munin.conf にリストされているすべてのホスト (デフォルトではローカルホストのみがリストされています) からデータを収集し、時系列データを /var/lib/munin/ にある RRD ファイル (Round Robin Database、経時変化するデータを保存するために設計されたファイルフォーマット) に保存し、/var/cache/munin/www/ に含まれるグラフを使って HTML ページを生成します。
すべての監視対象のマシンは /etc/munin/munin.conf 設定ファイルにリストされていなければいけません。各マシンは完全なセクションの形でリストされています。セクションはマシンと同じ名前で、少なくとも対応する IP アドレスを指定する address エントリを持っていなければいけません。 
[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes
セクションをさらに複雑にして、複数のマシンからのデータをまとめて作成されるグラフを追加することも可能です。設定ファイルの中で提供されている見本がカスタマイズの良い足掛かりとなります。
最後の段階は生成されたページを公開することです。そしてこれは、ウェブサイトから /var/cache/munin/www/ の内容を利用できるようにするようウェブサーバを設定することを意味しています。通常このウェブサイトへのアクセスは認証メカニズムか IP に基づくアクセス制御を使って制限されています。アクセス制御の詳細は第 11.2 節「ウェブサーバ (HTTP)」をご覧ください。

12.4.2. Nagios のセットアップ

Munin と異なり、Nagios の場合、必ずしも監視対象のホストに何かをインストールする必要はありません。そしてほとんどの場合、Nagios はネットワークサービスの可用性を確認するために使われます。たとえば Nagios を使うことで、ウェブサーバに接続して特定のウェブページがある時間内に取得できるかを確認することが可能です。

12.4.2.1. インストール

The first step in setting up Nagios is to install the nagios4 and monitoring-plugins packages. Installing the packages configures the web interface and the Apache server. The authz_groupfile and auth_digest Apache modules must be enabled, for that execute: 
# a2enmod authz_groupfile
Considering dependency authz_core for authz_groupfile:
Module authz_core already enabled
Module authz_core already enabled
Enabling module authz_groupfile.
To activate the new configuration, you need to run:
  systemctl restart apache2
# a2enmod auth_digest
Considering dependency authn_core for auth_digest:
Module authn_core already enabled
Enabling module auth_digest.
To activate the new configuration, you need to run:
  systemctl restart apache2
# systemctl restart apache2
Adding other users is a simple matter of inserting them in the /etc/nagios4/hdigest.users file.
Pointing a browser at http://server/nagios4/ displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.
Enabling some features involves editing /etc/nagios4/nagios.cfg. We also need to set up write permissions for the directory used by Nagios, with commands such as the following: 
# systemctl stop nagios4
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4
# systemctl start nagios4

12.4.2.2. 設定

The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, /etc/nagios4/nagios.cfg.
Nagios の概念を理解していない場合、オブジェクト設定ファイルの内容に立ち入るべきではありません。オブジェクト設定ファイルから設定するオブジェクトには以下の種類があります。
  • host は監視対象のマシンです。
  • hostgroup はグループ化して表示されたり、同じ設定要素を持つホスト群です。
  • service はホストやホストグループへの検査項目を定義します。これは多くの場合、あるネットワークサービスに対する検査を定義するものですが、いくつかのパラメータ (たとえば空きディスク領域やプロセッサ負荷) が条件を満たす範囲内にあるかに対する検査を定義することも可能です。
  • servicegroup はグループ化して表示されるサービス群です。
  • contact は警告を受け取る人です。
  • contactgroup は警告を受け取る人のグループです。
  • timeperiod は時間範囲で、この範囲内にいくつかのサービスを確認します。
  • command はサービスを確認するために実行するコマンドラインです。
オブジェクトの種類に応じて、各オブジェクトにはカスタマイズが可能な複数の属性が含まれます。完全なリストはここに挙げるには長すぎますが、最重要の属性はオブジェクト間の関係性を示す属性です。
service は command を使い、timeperiod で定めた時間内に host (または hostgroup) で稼働する特定の機能を確認します。問題が起きた場合、Nagios はそのサービスに関連付けられた contactgroup のメンバーに警告を送信します。各メンバーは対応する contact オブジェクトに書かれたチャンネルを介して警告を受け取ります。
An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in /etc/nagios4/conf.d/ are a good source of information on how they work.
Falcot Corp の管理者は以下の設定を使います。

例 12.5 /etc/nagios4/conf.d/falcot.cfg file

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.12
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generic Falcot service
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Services to check on www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Services to check on ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}
This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a warning is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the ssh-servers hostgroup. The matching standard service is defined in /etc/nagios4/conf.d/services_nagios2.cfg.
継承の使い方に注意してください。具体的に言えば、オブジェクトを継承するには「use parent-name」の形で親オブジェクトの名前を指定します。親オブジェクトは識別可能でなければいけません。つまり、親オブジェクトに「name identifier」属性を与える必要があります。親オブジェクトが真のオブジェクトでなく、属性継承の機能を担うだけの場合、このオブジェクトに「register 0」属性を与えます。こうすることで Nagios はこのオブジェクトを考慮しなくなり、真のオブジェクトならば必須とされるいくつかのパラメータが欠けていてもその問題を無視するようになります。

DOCUMENTATION オブジェクト属性のリスト

A more in-depth understanding of the various ways in which Nagios can be configured can be obtained from the documentation hosted on https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/. It includes a list of all object types, with all the properties they can have. It also explains how to create new plugins.

GOING FURTHER NRPE を使ったリモートマシンの状態検査

Many Nagios plugins allow checking some parameters local to a host; if many machines need these checks while a central installation gathers them, the NRPE (Nagios Remote Plugin Executor) plugin needs to be deployed. The nagios-nrpe-plugin package needs to be installed on the Nagios server, and nagios-nrpe-server on the hosts where local tests need to run. The latter gets its configuration from /etc/nagios/nrpe.cfg. This file should list the tests that can be started remotely, and the IP addresses of the machines allowed to trigger them. On the Nagios side, enabling these remote tests is a simple matter of adding matching services using the new check_nrpe command.