 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. なぜコマンドラインなのか？
Checkmk システムがインストールされると、そのシステムは 100% web インターフェイスを使用して設定および 操作することができます。しかし、それでもコマンドラインの詳細を確認した方が良い状況もあります。 例えば、 次のような場合です。
問題の原因を特定する際
Checkmk の管理を自動化するとき
独自の拡張機能をプログラミングおよびテストするとき
Checkmk の内部の仕組みを理解したい場合
単にコマンドラインでの作業が好きである場合この記事では、Checkmk のコマンドラインで最も重要なコマンド、ファイル、およびディレクトリについて紹介します。
この記事では、Checkmk のコマンドラインで最も重要なコマンド、ファイル、ディレクトリについて 紹介します。
2. サイトユーザー
2.1. サイトユーザーとしてログイン
Checkmk を管理する場合、いくつかの例外を除き、root ユーザーとして作業する必要はありません。この記事では、
サイトユーザーとしてログインしていることを前提としています。ログインは、たとえば次のように行います。
root@linux# su - mysiteroot を経由せずに、サイトに直接 SSH ログインすることも可能です。
サイトユーザーは「ごく普通の」Linux ユーザーであるため、
このユーザーにパスワードを割り当てる必要があります（
設定には、root の許可が 1 回だけ必要です）。
root@linux# passwd mysite
Enter new Unix password: **********
Retype new Unix password: **********
passwd: password updated successfullyその後、別のコンピュータから直接 SSH ログインが可能になります
(Windows ユーザーは、このために PuTTY を使用することをお勧めします)。Linux からこのログインを行うには
、コマンドラインでssh コマンドを使用します。
user@otherhost> ssh mysite@myserver123
mysite@localhost's password: **********最初のログイン時には、不明なホストキーに関する「警告」が表示されます。
この瞬間、攻撃者がオペレーティングシステムの IP アドレスを乗っ取っていないことが確実であれば、yes で確認してください。
また、Checkmk アプライアンスのコマンドラインでも作業を行うことができます。
Checkmk アプライアンスでもコマンドラインを使用することができます。 その方法については、別の記事で説明しています。
2.2. プロファイルおよび環境変数
特に個々のディストリビューションやオペレーティングシステムの構成の違いによって 問題が発生することをできるだけ防ぐため、Checkmk システムは サイトユーザー、および同様にすべての監視プロセスが 常に明確に定義された環境にあることを保証します。ホームディレクトリ および許可とともに、環境変数も重要な役割を果たします。
とりわけ、サイトユーザーとしてログインすると、以下の変数が 設定または変更されます。これらの変数は、サイト内で実行されているすべてのプロセス で使用できます。これは、これらのプロセスによって間接的に 呼び出されるスクリプト（たとえば、ユーザー独自の通知スクリプト）にも適用されます。
|
サイトの名前 ( |
|
サイトディレクトリ ( |
|
実行可能プログラムが検索されるディレクトリ。たとえば、Checkmk はサイトの |
|
実行可能プログラムが検索されるディレクトリ。この変数を使用することで、Checkmk は、Checkmk とともに提供されるライブラリが、通常のオペレーティングシステムにインストールされているライブラリよりも優先されるようにします。 |
|
Perl モジュールの検索パス。ここでも、不明な場合は Checkmk によって提供されるモジュールバリアントが優先されます。 |
|
コマンドラインコマンドの言語設定。この設定は、Linux インストールから採用されています。この変数は、サイトのプロセスで自動的に削除され、設定はデフォルトの英語に戻ります。これは、他の地域設定にも影響します。 |
env コマンドを使用すると、すべての環境変数を出力できます
。このコマンドに| sort を追加すると、リストがもう少しわかりやすく整理されます。
OMD[mysite]:~$ env | sort
HOME=/omd/sites/mysite
LANG=de_DE.UTF-8
LD_LIBRARY_PATH=/omd/sites/mysite/local/lib:/omd/sites/mysite/lib
LOGNAME=mysite
MAILRC=/omd/sites/mysite/etc/mail.rc
MAIL=/var/mail/mysite
MANPATH=/omd/sites/mysite/share/man:
MODULEBUILDRC=/omd/sites/mysite/.modulebuildrc
MP_STATE_DIRECTORY=/omd/sites/mysite/var/monitoring-plugins
NAGIOS_PLUGIN_STATE_DIRECTORY=/omd/sites/mysite/var/monitoring-plugins
OMD_ROOT=/omd/sites/mysite
OMD_SITE=mysite
PATH=/omd/sites/mysite/lib/perl5/bin:/omd/sites/mysite/local/bin:/omd/sites/mysite/bin:/omd/sites/mysite/local/lib/perl5/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PERL5LIB=/omd/sites/mysite/local/lib/perl5/lib/perl5:/omd/sites/mysite/lib/perl5/lib/perl5:
PERL_MM_OPT=INSTALL_BASE=/omd/sites/mysite/local/lib/perl5/
PWD=/omd/sites/mysite
REQUESTS_CA_BUNDLE=/omd/sites/mysite/var/ssl/ca-certificates.crt
SHELL=/bin/bash
SHLVL=1
TERM=xterm
USER=mysite
_=/usr/bin/envLinux では、環境はプロセスの属性です。すべてのプロセスには 独自の変数があり、その変数はサブプロセスに自動的に渡されます。 サブプロセスは、最初は継承した変数と同じ変数で開始しますが、その変数を変更することもできます。
env コマンドでは、現在のシェル環境のみを常にビューできます
。特定のプロセスの環境にエラーがあると思われる場合
、ちょっとしたトリックを使えば、その環境のリストを出力することができます。
これには、プロセス ID (PID) が必要です。
これは、たとえば、ps ax 、pstree -p 、またはtop で確認できます。
これにより、プロセスのenviron ファイルに、/proc ファイルシステムから直接アクセスできます。ここでは、例として
PID13222 に適したコマンドを以下に示します。
OMD[mysite]:~$ tr \\0 \\n < /proc/13222/environ | sortサイト内で実行する独自の スクリプトやその他のソフトウェア用にカスタム変数が必要な場合は
、この目的のために特別に作成されたetc/environment ファイルに保存してください。
ここで定義した変数はすべて
サイト内のどこでも使用できます。
# Custom environment variables
#
# Here you can set environment variables. These will
# be set in interactive mode when logging in as site
# user and also when starting the OMD processes with
# omd start.
#
# This file has shell syntax, but without 'export'.
# Better use quotes if your values contain spaces.
#
# Example:
#
# FOO="bar"
# FOO2="With some spaces"
#
MY_SUPER_VAR=blabla123
MY_OTHER_VAR=10.88.112.172.3. シェルをカスタマイズする
シェル（プロンプトなど）をカスタマイズしたい場合は、.bashrc ファイルで通常どおり実行できます。ただし、環境変数はetc/environment に属するため、すべてのプロセスで確実に利用できます。
VIM で作業したい場合は、独自の.vimrc ファイルを作成することも可能です。
3. ディレクトリ構造
3.1. ソフトウェアとデータの分離
次の図は、mysite というサイトと、2.0.0p8.cee という<version> を持つ Checkmk インストールにおける最も重要なディレクトリを示しています。
この構造の基本は、/omd ディレクトリによって提供されています。
Checkmk に関するすべてのファイルは、例外なくこのディレクトリ内にあります。/omd は、実際には/opt/omd へのシンボリックリンクであり、実際の物理的な
データは/opt にありますが、Checkmk 内のすべてのデータパスは常に/omd を使用します。
重要なのは、データ（黄色で強調表示）とソフトウェア（青色）の分離です。
サイトのデータは/omd/sites にあり、インストールされたソフトウェアは/omd/versions にあります。
3.2. サイトディレクトリ
他の Linux ユーザーと同様、サイトユーザーにもホームディレクトリがあります。
これをサイトディレクトリと呼びます。サイトの名前がmysite の場合、このディレクトリは/omd/sites/mysite にあります。
Linux では通常、シェルは自身のホームディレクトリを
チルダ (~) (またはスイングダッシュ) で省略します。ログインすると、
このディレクトリが実際に表示されるため、入力プロンプトにはチルダが自動的に表示されます。
OMD[mysite]:~$サイトディレクトリのサブディレクトリは、チルダを基準として相対的に表示されます。
OMD[mysite]:~$ cd var/log
OMD[mysite]:~/var/log$サイトディレクトリ内には、いくつかのサブディレクトリがあります。
これらは、ll でリストできます。
OMD[mysite]:~$ ll
total 16
lrwxrwxrwx 1 mysite mysite 11 Jan 24 11:56 bin -> version/bin/
drwxr-xr-x 19 mysite mysite 4096 Jan 24 11:56 etc/
lrwxrwxrwx 1 mysite mysite 15 Jan 24 11:56 include -> version/include/
lrwxrwxrwx 1 mysite mysite 11 Jan 24 11:56 lib -> version/lib/
drwxr-xr-x 5 mysite mysite 4096 Jan 24 11:56 local/
lrwxrwxrwx 1 mysite mysite 13 Jan 24 11:56 share -> version/share/
drwxr-xr-x 2 mysite mysite 4096 Jan 24 09:57 tmp/
drwxr-xr-x 12 mysite mysite 4096 Jan 24 11:56 var/
lrwxrwxrwx 1 mysite mysite 29 Jan 24 11:56 version -> ../../versions/2.0.0p8.cee/ご覧のとおり、ディレクトリbin 、include 、lib 、share 、version はシンボリックリンクです。
その他は「通常の」ディレクトリです。これは、前述のようにソフトウェアと
データを分離していることを反映しています。ソフトウェアディレクトリは、
サイトのサブディレクトリとしてアクセス可能ですが、物理的には/omd/versions にあり
、他のサイトでも使用することができます。
| ソフトウェア | データ | |
|---|---|---|
ディレクトリ |
|
|
所有者 |
|
サイトユーザー ( |
作成者 |
Checkmk のインストール |
サイトの作成、設定、監視 |
物理的な場所 |
|
|
ファイルタイプ |
シンボリックリンク |
通常のディレクトリ |
3.3. ソフトウェア
Linux では通常、ソフトウェアディレクトリはrootに属しており、サイトユーザーは変更できません。以下のサブディレクトリ
が存在します。例では、これらは物理的には/omd/versions/2.0.0p8.cee 内にあり、サイトディレクトリからシンボリックリンク
によってアクセスできます。
|
実行可能プログラムのディレクトリ。 ここには、たとえば |
|
C ディレクトリ、Apache および Python 用のプラグイン、そして |
|
インストールされたソフトウェアの主要部分です。 |
|
C プログラム用のインクルードファイルが含まれています。これらは、 |
version/ シンボリックリンクは「中間停止」であり、サイトで使用されるバージョンのリレー
ポイントとして機能します。ソフトウェアのアップデート時には、
これは古いバージョンから新しいバージョンに切り替わります。ただし、リンクを変更して手動でアップデートを試みないでください。
アップデートには
他にもいくつかの手順が必要であり、失敗します。
3.4. データ
サイトの実際のデータは、サイトディレクトリ内の残りのサブディレクトリにあります。 これらは例外なく、サイトユーザーに属しています。 サイトディレクトリ自体も含まれます。Checkmk は、そこにリストされているディレクトリ以外のものは何も保存しません。 ここでは、テスト、ダウンロードしたデータ、ログファイルのコピーなど、 必要に応じて自由にファイルやディレクトリを作成することができます。
以下のディレクトリが事前定義されています。
|
設定ファイル。これらは、手動または Checkmkのセットアップを使用して編集できます。 注： |
|
ランタイムデータ。監視によって生成されたすべてのデータは、ここに保存されます。ホストおよびサービスの数に応じて、膨大な量のデータが蓄積される可能性があります。その大部分は、RRD に記録されたパフォーマンスデータです。 |
|
揮発性データ。Checkmk およびその他のコンポーネントは、一時的なデータ（保持する必要のないデータ）をここに保存します。そのため、 |
|
独自の拡張機能。ソフトウェアディレクトリ |
3.5. Checkmk の変更および拡張 – ローカルファイル
上記の表で示したとおり、local ディレクトリとその多数の
サブディレクトリは、お客様独自の拡張用です。
新しいサイトでは、local/ 内のすべてのディレクトリは最初は空です。
実用的なtree コマンドを使用すると、local の構造の概要をすばやく確認できます。-L 3 オプションを使用すると、深さを 3 に制限できます。
最下位のディレクトリはすべて、ソフトウェアに積極的に統合されています。
OMD[mysite]:~$ tree -L 3 local
local
├── bin
├── lib
│ ├── apache
│ ├── check_mk -> python3/cmk
│ ├── nagios
│ │ └── plugins
│ ├── python
│ └── python3
│ └── cmk
└── share
├── check_mk
│ ├── agents
│ ├── alert_handlers
│ ├── checkman
│ ├── checks
│ ├── inventory
│ ├── locale
│ ├── mibs
│ ├── notifications
│ ├── pnp-rraconf
│ ├── pnp-templates
│ ├── reporting
│ └── web
├── diskspace
├── doc
│ └── check_mk
├── nagios
│ └── htdocs
├── nagvis
│ └── htdocs
└── snmp
└── mibs最下位のレベルのディレクトリはすべて、ソフトウェアに積極的に統合されます。
ここに保存されたファイルは、/omd/versions/… 内の同じ名前のディレクトリ（または、bin 、lib 、share 内のサイトからの論理パス）にあるファイルと同じように扱われます。
例：サイトでは、実行可能プログラムはbin
およびlocal/bin で検索されます。
ここでは、同じ名前のファイルがある場合、local
のファイルが常に優先されます。これにより、/omd/versions/ のインストールファイルを変更することなく、ソフトウェアを変更することができます。
手順は簡単です。必要なファイルを
目的のファイルを
localの適切なディレクトリにコピーします。このファイルを編集します。
変更を有効にするために、該当するサービスを再起動します。
上記の 3 について、変更がどのサービスに適用されるかが正確にわからない場合は
、omd restart を使用してサイト全体を再起動してください。
3.6. ログファイル
Checkmk では、前述のように、ログファイルはvar/ディレクトリに保存されます。
関連するコンポーネントのすべてのログファイルは、このディレクトリにあります。
OMD[mysite]:~$ ll -R var/log/
var/log/:
total 48
-rw-r--r-- 1 mysite mysite 759 Sep 21 16:54 alerts.log
drwxr-xr-x 2 mysite mysite 4096 Sep 21 16:52 apache/
-rw-r--r-- 1 mysite mysite 8603 Sep 21 16:54 cmc.log
-rw-r--r-- 1 mysite mysite 3175 Sep 21 11:38 dcd.log
-rw-rw---- 1 mysite mysite 0 Oct 27 11:05 diskspace.log
-rw-r--r-- 1 mysite mysite 313 Sep 21 16:54 liveproxyd.log
-rw-r--r-- 1 mysite mysite 62 Sep 21 16:54 liveproxyd.state
drwxr-xr-x 2 mysite mysite 4096 Sep 20 13:44 mkeventd/
-rw-r--r-- 1 mysite mysite 676 Sep 21 16:54 mkeventd.log
-rw-r--r-- 1 mysite mysite 310 Sep 21 16:54 mknotifyd.log
-rw-r--r-- 1 mysite mysite 327 Sep 21 16:54 notify.log
-rw-r--r-- 1 mysite mysite 458 Sep 21 16:54 rrdcached.log
-rw-r--r-- 1 mysite mysite 0 Sep 21 16:52 web.log
var/log/apache:
total 32
-rw-r--r-- 1 mysite mysite 26116 Sep 21 16:54 access_log
-rw-r--r-- 1 mysite mysite 841 Sep 21 16:54 error_log
-rw-r--r-- 1 mysite mysite 0 Sep 22 10:21 stats
var/log/mkeventd:
total 0web インターフェイスでは、Setup > General > Global settings で「logging 」を含むすべてのエントリを検索することで、ログファイルに書き込むデータの範囲を簡単に設定できます。
または、コマンドラインの設定ファイルでログレベルをカスタマイズすることもできます。
ファイル名はそれぞれglobal.mk ですが、保存場所はディレクトリが異なります。Factory setting がまだ変更されていない場合は、エントリを指定してください。
notification_logging = 15
alert_logging = 10
cmc_log_levels = {
'cmk.alert' : 5,
'cmk.carbon' : 5,
'cmk.core' : 5,
'cmk.downtime' : 5,
'cmk.helper' : 5,
'cmk.livestatus' : 5,
'cmk.notification' : 5,
'cmk.rrd' : 5,
'cmk.smartping' : 5,
}
cmc_log_rrdcreation = Noneこのファイルでは、Monitoring Core 、Notifications 、Alert Handlers のエントリが設定されます：
notification_loggingには、Full dump of all variables and command に対して 10、Normal logging に対して 15、Minimal logging に対して 20 の値を選択できます。alert_loggingは、Full dump of all variables に 10、Normal logging に 20 を設定できます。cmc_log_levelsの値を大きくすると、ログに記録されるデータ量が増加します。 ここでは、Emergency の 0 からDebug の 7 までの 8 段階の段階があります。cmc_log_rrdcreationに対して、None、'terse'、'full'の3つの値を設定することで、RRDの作成をログに記録するかどうか、およびその方法を決定できます。
log_levels = {
'cmk.web' : 50,
'cmk.web.auth' : 10,
'cmk.web.automations' : 15,
'cmk.web.background-job' : 10,
'cmk.web.bi.compilation' : 20,
'cmk.web.ldap' : 30,
}このファイルでは、User Interface のログ設定を行うことができます。
カウントが減少するにつれて、ログに記録されるデータの量は反比例して減少します。 最低のログレベルは 50 (Critical) で、最も多くのデータが記録されるのは 10 で、これは最高レベル (Debug) に対応します。
liveproxyd_log_levels = {'cmk.liveproxyd': 20}このファイルは、Livestatus Proxy logging に使用されます。 ここで指定できる値は、User Interface のログ記録に対応しています。
重要：高いレベルが設定されている場合、ログファイルはすぐに非常に大きくなります。 通常、このような設定は、問題の特定などの「一時的な」カスタマイズのために使用することをお勧めします。
4. cmk コマンド
サイトを開始および停止し、コンポーネントの基本設定を行い、ソフトウェアのアップデートを開始するためのomd コマンドと並んで、cmk は最も重要なコマンドです。
このコマンドを使用すると、監視コアの設定を作成したり、手動でチェックを実行したり、
サービスディスカバリーを実行したり、その他さまざまな操作を行うことができます。
4.1. コマンドオプション
コマンド「cmk 」は、実際には「check_mk 」の略で、コマンドの入力時間を短縮するために導入されました。
このコマンドには、非常に詳細なオンラインヘルプがビルトインされており、--help オプションで呼び出すことができます。
OMD[mysite]:~$ cmk -h
WAYS TO CALL:
cmk --automation [COMMAND...] Internal helper to invoke Check_MK actions
cmk --backup BACKUPFILE.tar.gz make backup of configuration and data
cmk --cap [pack|unpack|list FILE.cap] Pack/unpack agent packages (Enterprise only)
cmk --check [HOST [IPADDRESS]] Check all services on the given HOST
...上記のコマンドでわかるように、--help ではなく、-h オプションを使用してヘルプを呼び出しています。
コマンド自体について当てはまることは、そのオプションについても当てはまるからです。入力する文字が少ないほど、処理が速くなります。
すべてのオプションに当てはまるわけではありませんが、よく使うオプションについては、長い形式の他に短い形式も用意されています。
長い形式 (check_mk --list-hosts) は、短い形式 (cmk -l) よりも、特に初心者にとっては直感的に理解しやすいですが、このユーザーガイドでは短い形式を使用します。疑問がある場合は、いつでもコマンドのヘルプを参照してください。
ユーザーガイドではすべてのオプションを紹介しているわけではないため、コマンドのヘルプを詳しく確認しておくことをお勧めします。
オプションを入力すると、cmk コマンドが特定のモードで開始されます。
この章およびマニュアルの他の部分で説明するオプションの概要は、次のとおりです。
| オプション | 機能 |
|---|---|
監視コア | |
|
|
|
|
|
|
|
|
チェック | |
|
ホストのチェックの実行 |
サービス | |
|
|
|
ホストのディスカバリーチェックを実行し、新しいサービスや消失したサービス、新しいホストラベルをチェックします。変更が発生すると、 |
エージェント | |
|
|
|
|
診断 | |
|
|
|
|
|
|
情報 | |
|
サイトにインストールされている Checkmk のバージョンを表示します。 |
|
|
|
|
|
チェックプラグインのマニュアルページを表示します(ここではプラグイン |
特別なトピックス | |
|
DNS キャッシュを削除して再作成します。DNS キャッシュの詳細については、ホストに関する記事をご覧ください。デフォルトでは、このコマンドは Checkmk サイトにおいて 1 日 1 回、クーロンジョブによって実行されます。 |
|
|
|
|
|
|
|
ホストからSNMP ウォークを取得します。 |
|
|
|
|
一部のモードでは、さらに特定のオプションを使用できます。
たとえば、サービスディスカバリーを特定のチェック（df など）に制限することができます。この場合は、コマンドcmk -I --detect-plugins=df myserver123 を使用します。
コマンドの実行モードに関係なく、常に機能するオプションがいくつかあります。
| オプション | 機能 |
|---|---|
|
|
|
上記と同じですが、さらに詳細な情報を表示します: ‘very verbose’ |
|
キャッシュファイルが古い場合でも、そのファイルから情報を読み込みます。キャッシュファイルが存在しない場合にのみ、エージェントに連絡します。ホストのキャッシュされたエージェントデータは、 |
|
|
|
情報は常に最新情報が取得されます。つまり、キャッシュファイルは使用されません。 |
|
SNMP ホストの場合：SNMP エージェントにアクセスする代わりに、 |
|
エラーが発生した場合、このオプションを有効にすると、エラーはインターセプトされず、元の Python 例外が完全に表示されます。これは、エラーが発生したプログラムの正確な位置を示すため、開発者にとって重要な情報となります。また、自作のチェックプラグインのエラーの位置を特定する場合にも非常に役立ちます。 |
次のセクションでは、コマンドの使用方法を説明します。 例は、ほとんど省略したフォームで表示しています。
4.2. 監視コアのコマンド
商業版では、監視コアとしてCheckmk マイクロコア(CMC) を使用しています。Checkmk Raw はNagios を使用しています。
cmk の重要なタスクは、コアが読み込める
構成ファイルを生成することです。このファイルには、
構成済みのホスト、サービス、連絡先、連絡先グループ、期間などがすべて含まれます。
この情報に基づいて、コアは、実行すべきチェックと
GUI のライブステータスで提供するオブジェクトを把握します。
Nagios および CMC では、ホスト、 サービス、その他のオブジェクトの数は、動作中は常に静的であり、 この数は、新しい構成を生成し、 コアを再ロードすることによってのみ変更できることが基本です。Nagios では、コアの再起動も 必要です。CMC には、アクティブな処理中に 構成を再ロードするための非常に効率的な機能があります。
以下の表は、2 つのコアの構成の重要な相違点をまとめたものです。
| Nagios | CMC | |
|---|---|---|
構成ファイル |
|
|
ファイルタイプ |
|
圧縮および最適化されたバイナリファイル |
アクティベーション |
コアの再起動 |
設定を再ロードするためのコアコマンド |
コマンド |
|
|
etc/check_mk/conf.d にある設定ファイル、またはvar/check_mk/autochecks にある自動的に検出されたサービスの設定が変更された場合は、必ず設定を再生成する必要があります。
セットアップは、このような変更を記録し、変更をアクティブにするために GUI で強調表示します。
設定を手動またはスクリプトで変更して「セットアップをバイパス」した場合、
アクティブ化も手動で行う必要があります。
この機能には、次のコマンドを使用します。
| オプション | 機能 |
|---|---|
|
コアの新しい設定を生成し、コアを再起動します ( |
|
コアの設定を生成し、アクティブなプロセスを再起動せずにロードします ( 注意:Nagios をコアとして使用している場合、このオプションは引き続き機能しますが、メモリの穴やその他の不安定な状態が生じる可能性があります。それとは別に、このオプションは、実際には再ロードを実行するのではなく、内部でプロセスを停止して再起動するだけです。 |
|
コアの設定を生成しますが、アクティブ化はしません。 |
|
診断のために、実際の設定ファイルを変更せずに、生成される設定を標準出力に出力します。ここでは、ホストの設定を表示するためだけにホスト名を簡単に入力することができます (例: |
要約すると、Checkmk 設定をカスタマイズして変更をアクティブにするには 、Nagios で次の操作を行う必要があります。
OMD[mysite]:~$ cmk -RCMC では:
OMD[mysite]:~$ cmk -O4.3. チェックの実行
Checkmk の 2 つめのモードは、ホストの Checkmk ベースのチェックの実行です。 これを使用すると、自動的に検出されたサービスと手動で設定されたサービスの すべてを、監視コアや GUI を操作することなく、すぐにチェックすることができます。 これを行うには、xml-ph-0000@deepl.internal と、監視で設定されているホストの名前を入力します。
これを行うには、cmk --check の後に、監視で設定されているホストの名前を入力します。--check オプションはcmk のデフォルトオプションであるため、省略することもできます。
さらに、-n （結果をコアに送信しない）と-v （すべての結果を出力する）の2つのオプションを必ず追加してください。
詳細については、以下のオプションの説明をご覧ください。
OMD[mysite]:~$ cmk -nv myserver123
Checkmk version 2.0.0p8
CPU load 15 min load 0.22 at 8 Cores (0.03 per Core)
CPU utilization Total CPU: 8.20%
Disk IO SUMMARY Read: 14.0 kB/s, Write: 316 kB/s, Latency: 442 microseconds
Filesystem / 82.0% used (177.01 of 215.81 GB), (warn/crit at 80.00/90.00%),
Interface 2 [wlo1], (up), MAC: 5C:80:B6:3E:38:7F, Speed: unknown, In: 1.02 kB/s, Out: 902 B/s
Kernel Performance Process Creations: 67.82/s, Context Switches: 4183.41/s, Major Page Faults: 1.71/s, Page Swap in: 0.00/s, Page Swap Out: 0.00/s
Memory Total virtual memory: 37.07% - 6.08 GB of 16.41 GB
Mount options of / Mount options exactly as expected
NTP Time sys.peer - stratum 2, offset 16.62 ms, jitter 5.19 ms, last reac
Number of threads Count: 1501 threads, Usage: 1.19%
TCP Connections Established: 11
Temperature Zone 0 25.0 °C
Uptime Up since Jul 29 2021 08:38:32, Uptime: 4 hours 43 minutes
[agent] Version: 2.0.0b5, OS: linux, execution time 0.9 sec | execution_time=0.850 user_time=0.050 system_time=0.010 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=0.800追加のヒント:
ログファイル監視を使用している監視対象の本番ホストでは、このコマンドを使用しないでください。ログメッセージはエージェントによって 1 回だけ送信されます。手動で
cmk -nvを実行すると、これらのメッセージが「キャッチ」され、監視から失われる場合があります。このような場合は、--no-tcpオプションを使用してください。Nagios をコアに使用しており、
-nを省略した場合、コアおよび GUI でチェック結果が即座に更新されます。このコマンドは、独自のチェックプラグインを開発する場合に、GUI を使用する場合よりも迅速にテストを行うことができるため、便利です。チェックが失敗してUNKNOWN が返された場合、
--debugオプションを使用すると、コード内の問題のある場所を見つけることができます。
次のオプションは、コマンドに影響を与えます。
| オプション | 機能 |
|---|---|
|
チェック結果の出力：このオプションを指定しない場合、サービスCheck_MK 自体の出力のみが表示され、他のサービスの結果は表示されません。 |
|
ドライラン: 結果はコアに渡されず、パフォーマンスカウンタは更新されません。 |
|
チェックプラグイン |
4.4. エージェントの出力の取得
コマンドcmk -d は、ホストの Checkmk エージェントからの出力を取得して表示します。cmk -d を使用すると、監視と同じ方法でエージェントデータが取得されます。
データは検証も処理もされません。
したがって、表示されるデータは、エージェントコントローラー（TLS 暗号化が有効になっている場合）またはデータソースプログラムが設定されている場合はトンネリングプログラムに渡されるデータと完全に一致します。
OMD[mysite]:~$ cmk -d myserver123
<<<check_mk>>>
Version: 2.1.0b5
AgentOS: linux
Hostname: myserver123
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
OnlyFrom:
<<<df>>>
udev devtmpfs 8155492 4 8155488 1% /dev
tmpfs tmpfs 1634036 1208 1632828 1% /run
/dev/sda5 ext4 226298268 175047160 39732696 82% /
none tmpfs 4 0 4 0% /sys/fs/cgroup監視に設定されていないホストの名前または IP アドレスを使用して、cmk -d を実行することもできます。
この場合、ホストのレガシー設定（ポート 6556 への TCP 接続、エージェントコントローラーなし、暗号化なし、データソースプログラムなし）が使用されます。
4.5. エージェントのベイク
商業版では、web インターフェイスから行うのと同じように、コマンドラインからエージェントをベイクすることもできます。これにより、たとえば、クーロンジョブを使用してエージェントを定期的に更新するなどのオプションが可能になります。
エージェントをベイクするには、-A オプションの後にホスト名（1 つまたは複数）を指定します。
OMD[mysite]:~$ cmk -Av myserver123
myserver123...linux_deb:baking...linux_rpm:baking...(fast repackage)...solaris_pkg:baking...windows_msi:baking...linux_tgz:baking...(fast repackage)...solaris_tgz:baking...(fast repackage)...aix_tgz:baking...OK出力には、ホストmyserver123 で利用可能なエージェントパッケージが正常にベイクされたことが表示されます。ホストを指定しない場合、すべてのホストのパッケージがベイクされます。
このコマンドは、必要な場合にのみベイクを行います。パッケージが最新の状態である場合は、出力は次のようになります。
OMD[mysite]:~$ cmk -Av myserver123
myserver123..linux_deb:uptodate...linux_rpm:uptodate...solaris_pkg:uptodate...windows_msi:uptodate...linux_tgz:uptodate...solaris_tgz:uptodate...aix_tgz:uptodate...OK-f （強制）オプションを使用すると、強制的にベイクを実行できます。
4.6. ホストのリスト
cmk -l コマンドは、セットアップで設定されたすべてのホストの名前を単にリストします。
OMD[mysite]:~$ cmk -l
myserver123
myserver124
myserver125データは「そのまま」の「未処理」の状態で提供されるため、スクリプトで簡単に使用できます。 たとえば、すべてのホスト名をループするスクリプトを作成することができます。
OMD[mysite]:~$ for host in $(cmk -l) ; do echo "Host: $host" ; done
Host: myserver123
Host: myserver124
Host: myserver125echo の代わりに、何か意味のあるコマンドを挿入すると
非常に便利です。
cmk --list-tag コマンドも同様にホスト名を出力しますが、ホストタグによるフィルタリングも
可能です。ホストタグを入力するだけで、そのタグを持つすべてのホストが
表示されます。次の例は、SNMP によって監視されているすべてのホストをリストしています。
複数のタグを入力すると、それらのタグを持つホストがすべて表示されます。
OMD[mysite]:~$ cmk --list-tag snmp
myswitch01
myswitch02
myswitch03複数のタグを入力すると、それらは「and」で連結されます。 以下のコマンドは、SNMPおよびCheckmk エージェントの両方で監視されているすべてのホストを返します。 この条件を満たすホストがないため、出力は空のままです。
OMD[mysite]:~$ cmk --list-tag snmp tcp4.7. ホスト構成の表示
cmk -D は、1 つ以上の指定したホストについて、設定されている
サービス、ホストタグ、ラベル、その他の属性を表示します。サービスのリストは非常に
膨大であるため、ターミナルでは多少見づらくなる場合があります。出力の
途切れを防ぐため、less -S を通じて送信してください。
OMD[mysite]:~$ cmk -D myserver123 | less -S
myserver123
Addresses: 192.168.178.34
Tags: [address_family:ip-v4-only], [agent:cmk-agent], [criticality:prod], [ip-v4:ip-v4], [networking:lan], [piggyback:auto-piggyback], [site:mysite], [tcp:tcp]
Labels: [cmk/check_mk_server:yes], [cmk/os_family:linux]
Host groups: mylinuxservers
Contact groups: all
Agent mode: Normal Checkmk agent, or special agent if configured
Type of agent:
TCP: 192.168.178.34:6556
Process piggyback data from /omd/sites/mysite/tmp/check_mk/piggyback/mycmkserver
Services:
Type of agent: TCP (port: 6556)
Is aggregated: no
Services:
checktype item params
---------------- ----------------- ------------
cpu.loads None (5.0, 10.0)
kernel.util None {}4.8. チェックプラグインに関する情報
Checkmk には、標準で多数のプラグインが用意されています。
リリースごとにいくつかの新しいプラグインが追加されており、バージョン 2.4.0 ではすでに 2,000 以上のプラグインが含まれています。cmk コマンドの 3 つのオプションを使用すると、これらのプラグインに関する情報にアクセスできます。
cmk -L は、すべてのプラグインの名前、タイプ、および説明の表を表示します。
同時に、 に保存されている自作のプラグインもリストされます。local/
以下のタイプが利用可能です：
|
Checkmk エージェントからのデータを評価します。これは（通常）TCP ポート 6556 経由で取得されます。 |
|
SNMP 経由でデバイスの監視を行います。 |
|
監視用に Nagios 互換の標準タイプのプラグインを呼び出します。ここでは、Checkmk は実際には設定のみを採用します。 |
もちろん、特定の項目を検索する場合は、grep を使用してリストを簡単にフィルタリングすることができます。
OMD[mysite]:~$ cmk -L | grep f5
f5_bigip_apm snmp F5 Big-IP: Number of Current SSL/VPN Connections
f5_bigip_chassis_temp snmp F5 Big-IP: Chassis Temperature
f5_bigip_cluster snmp F5 Big-IP: Cluster State, Up to Firmware Version 10
f5_bigip_cluster_status snmp F5 Big-IP: Active/Active or Passive/Active Cluster Status (< V11.2)
f5_bigip_cluster_status_v11_2 snmp F5 Big-IP: Active/Active or Passive/Active Cluster Status (> V11.2)
f5_bigip_cluster_v11 snmp F5 Big-IP: Cluster State for Firmware Version >= 11
f5_bigip_conns snmp F5 Big-IP: Number of Current Connections
f5_bigip_cpu_temp snmp F5 Big-IP: CPU Temperature
f5_bigip_fans snmp F5 Big-IP: System Fans
f5_bigip_interfaces snmp F5 Big-IP: Special Network Interfaces
f5_bigip_mem snmp F5 Big-IP: Usage of Memory
f5_bigip_mem_tmm snmp F5 Big-IP: Usage of TMM Memory
f5_bigip_pool snmp F5 Big-IP: Load Balancing Pools
f5_bigip_psu snmp F5 Big-IP: Power Supplies
f5_bigip_snat snmp F5 Big-IP: Source NAT
f5_bigip_vcmpfailover snmp F5 Big-IP: Active/Active or Passive/Active vCMP Guest Failover Status
f5_bigip_vcmpguests snmp F5 Big-IP: Show Failover States of all vCMP Guests Running on a vCMP Host
f5_bigip_vserver snmp F5 Big-IP: Virtual Servers特定のプラグインに関する詳細情報が必要な場合は、cmk -M でマニュアルページとしてドキュメントを呼び出すことができます。
OMD[mysite]:~$ cmk -M f5_bigip_pool次のような出力が表示されます:
cmk -m をオプションなしで実行すると、すべてのチェックプラグインのマニュアルページの完全なカタログにアクセスできます。
OMD[mysite]:~$ cmk -mこのカタログ内でインタラクティブにナビゲーションできます:
5. セットアップなしの構成
セットアップメニューは優れた設定ツールです。しかし、 古き良き Linux の伝統であるテキストファイルによる設定を好む理由も十分あります。 同じ考えをお持ちの方には、良いニュースがあります。 Checkmk は、テキストファイルを使用して完全に設定することができます。Setup メニューのアクションは （この同じ）テキストファイルを処理するだけなので、どちらか一方を選択しなければならないという状況にはなりません。
5.1. ドキュメントはどこにありますか？
Checkmk で使用されるすべての設定ファイルの正確な構造を網羅した包括的な要約を期待されている場合 、残念ながら ご期待に添えないことをご承知おきください。設定ファイルは複雑で多様であるため 、このユーザーガイドで完全に説明することは不可能です。
以下の例は、Checkmk でファイルシステムを監視するチェックプラグインの パラメータセット全体を示しています。パラメータ数が多いため、 スクリーンショットは 2 つの部分に分け、小文字で表示しています。
設定ファイル内の対応する部分は次のように表示されます（やや 見やすくフォーマットされています）：
{ 'inodes_levels' : (10.0, 5.0),
'levels' : (80.0, 90.0),
'levels_low' : (50.0, 60.0),
'magic' : 0.8,
'magic_normsize' : 20,
'show_inodes' : 'onlow',
'show_levels' : 'onmagic',
'show_reserved' : True,
'subtract_reserved' : False,
'trend_mb' : (100, 200),
'trend_perc' : (5.0, 10.0),
'trend_perfdata' : True,
'trend_range' : 24,
'trend_showtimeleft' : True,
'trend_timeleft' : (12, 6)},ご覧のとおり、10 以上の異なるパラメータがあり、それぞれ
独自のロジックがあります。一部は浮動小数点数（0.8 ）で、一部は整数（24 ）で、一部は
キーワード（'onlow' ）で、一部はブール値（True ）で、
その他はこれらのさまざまな組み合わせをコード化するためにタプル（(5.0,
10.0) ）を使用しています。
これは 2,000 以上のプラグインのうちの 1 つの例にすぎません。もちろん、チェックパラメータとして 他の設定も可能です。期間、イベントコンソールのルール、ユーザープロファイルなど、 さまざまなものが考えられます。
もちろん、テキストファイルを構成として使用できないということではありません。 選択した構成タスクの正確な構文がまだわからない場合は、 それに適したツール、つまりセットアップと呼ばれるツールが必要です。
Checkmk テストサイトを作成してください。
Setup メニューを使用して、必要なパラメータを設定します。
変更された設定ファイルを特定します（詳細は後述）。
このファイルの関連セクションから、正確な構文を本番システムにコピーします。
したがって、セットアップが書き込むファイルを知っているだけで十分です。
注：ディレクトリ、ファイル、さらにはファイルの内容の名称に関しては、wato という用語がよく使用されます。WATO は、Web Administration Tool（Web 管理ツール）の略語で、1.6.0 までのバージョンの Checkmk 設定ツールです。
WATO の機能は、2.0.0 以降のバージョンでは、Setup （セットアップ）メニュー（略称：Setup）に引き継がれています。WATO は、web インターフェイスでは（ほぼ）完全に Setup に置き換えられましたが、ファイルシステムには残っています。
5.2. どの設定ファイルが使用されますか？
Setup が
変更したファイルを見つけるための便利なコマンドがあります。find です。次のパラメータを指定して「find」を実行すると
、etc/ にある、過去 1 分間に変更された (-mmin -1) すべてのファイル (-type f) を検索できます。
OMD[mysite]:~$ find etc/ -mmin -1 -type f
etc/check_mk/conf.d/wato/rules.mk設定の基本は、常にetc/check_mk ディレクトリです。
このディレクトリの下には、さまざまなドメインに細分化されており、これらは通常、
特定のサービスに適用されます。
同時に、各ドメインには、.d というサフィックスが付いたディレクトリがあり、
このディレクトリには、.mk というサフィックスが付いたすべてのファイルがアルファベット順で自動的に読み込まれます。
一部のディレクトリには、最初に読み込まれるメインファイルもあります。
これは手動での変更のみを目的としており、セットアップでは変更されません。
| ドメイン | 設定ディレクトリ | メインファイル | 変更をアクティブにする |
|---|---|---|---|
監視 |
|
|
|
|
|
自動的に |
|
|
|
|
|
|
自動的に |
5.3. セットアップおよび設定ファイル
.d/ 設定ディレクトリの下には、常にサブディレクトリwato （例：etc/check_mk/conf.d/wato ）があります。
セットアップは基本的に、このディレクトリのみを読み書きします。
ただし、設定ディレクトリを担当するサービスは、手動で作成したファイルが「その」.d ディレクトリに保存されている場合、そのディレクトリ内の他のファイルも読み込みます。つまり、
手動で設定した設定をセットアップで表示および編集できるようにする必要がある場合は、既存のパスを使用してください。
設定は単に機能すればよく、セットアップでは表示されない場合は、
wato/以外の独自のファイルを使用してください。設定で設定が表示され、変更できないようにする必要がある場合は、一部のファイルをロックすることができます。
ファイルおよびフォルダのロック
セットアップを使用せずに手動で設定ファイルを作成する一般的な理由は、監視する
ホストを構成管理データベース (CMDB) からインポートする必要がある場合です。
ここでは、REST API を使用する方法とは対照的に、スクリプトを使用して、etc/check_mk/conf.d/wato にホスト用のフォルダを直接作成し、そのフォルダに含まれるホスト用のファイルhosts.mk 、および必要に応じてフォルダ属性を含むファイル.wato を作成します。
このインポートが 1 回限りではなく、定期的に繰り返す場合 CMDB が主要システムであるため、ユーザーがセットアップを使用してファイルに変更を加えると、 次回のインポートで変更内容が失われてしまうため、非常に非現実的です。
hosts.mk ファイルは、lock 属性に次の行を追加することでロックできます：
# Created by WATO
# encoding: utf-8
_lock = Trueセットアップでこのフォルダを開くと、ホストリストの上に次のメッセージが表示されます。
hosts.mk ファイルを変更するすべての操作は、GUI でロックされます。
もちろん、これはサービスディスカバリーには適用されません。ホストの
サービスは、var/check_mk/autochecks/ に保存されます。
フォルダ属性もロックすることができます。
これは、フォルダの.wato ファイルにエントリを追加することで行います。ファイルの辞書で、lock 属性をTrue に設定します。
{'title': 'My folder',
'attributes': {},
'num_hosts': 1,
'lock': True,
'lock_subfolders': False,
'__id': '7f2a8906d3c3448fac8a379e2d1cec0e'}lock_subfolders 属性をTrue に設定すると、サブフォルダーの作成と削除が防止されます。
rules.mk などの他のファイルのロックは、現在サポートされていません。
5.4. ファイルの構文
純粋に形式的な用語では、Checkmk のすべての設定ファイルは Python 3構文で記述されています。ファイルには 2 種類あります。
Python によってスクリプトとして実行されるファイル。これには、
hosts.mkなどがあります。Python によって値として読み込まれるファイル。 これには、
.watoなどがあります。
実行可能ファイルは、値（= ）が代入される変数があることで識別できます。
その他のファイルには通常、開始括弧{ で始まる Python 辞書が含まれています。これらは単純な値である場合もあります。
ファイルに非 ASCII 文字（ドイツ語のウムラウト（
ファイルに非ASCII文字（ドイツ語のウムラウト（ä 、ö 、ü ）など）が必要の場合、
最初の行または2番目の行に次のコメントを記述する必要があります：
# encoding: utf-8そうしないと、ファイルを読み込むときに構文エラーが発生します。Python の構文に関する詳しいヒントについては 、専門サイトを参照することをお勧めします。 Python 言語リファレンス。
5.5. 設定ファイルのチェック
etc/check_mk/ で設定ファイルを手動で編集した場合は、設定をチェックすることをお勧めします。
これは、cmk-update-config ツールを使用して実行できます。このツールは、実際にはomd update によるバージョンアップデート後に自動的に実行されます。
OMD[mysite]:~$ cmk-update-config
...
Verifying Checkmk configuration...
01/05 Cleanup precompiled host and folder files...
02/05 Rulesets...
Exception while trying to load rulesets: Cannot read configuration file "/omd/sites/mysite/etc/check_mk/conf.d/wato/rules.mk":
'[' was never closed (<string>, line 44)
You can abort the update process (A) and try to fix the incompatibilities or try to continue the update (c).
Abort update? [A/c]
...例えば、上記の抜粋では、閉じられていないブラケットへの参照が確認できます。