Show Table of Contents
4.5. ウォッチドッグの設定
4.5.1. 仮想マシンへのウォッチドッグカードの追加
仮想マシンにウォッチドッグカードを追加して、オペレーティングシステムの応答性を監視することができます。
手順4.9 仮想マシンへのウォッチドッグカードの追加
- 仮想マシン タブをクリックして、仮想マシンを 1 つ選択します。
- をクリックします。
- 高可用性 タブをクリックします。
- ウォッチドッグモデル のドロップダウンリストから使用するウォッチドッグモデルを選択します。
- ウォッチドッグアクション のドロップダウンリストからアクションを 1 つ選択します。これは、ウォッチドッグがトリガーされた場合に仮想マシンが取るアクションです。
- をクリックします。
4.5.2. ウォッチドッグのインストール
仮想マシンにアタッチされたウォッチドッグカードをアクティブ化するには、その仮想マシンに watchdog パッケージをインストールして
watchdog サービスを起動する必要があります
手順4.10 ウォッチドッグのインストール
- ウォッチドッグカードがアタッチされた仮想マシンにログインします。
- watchdog パッケージおよび依存関係をインストールします。
# yum install watchdog
/etc/watchdog.confファイルを編集して、以下の行のコメントを解除します。watchdog-device = /dev/watchdog
- 変更を保存します。
watchdogサービスを起動して、このサービスがブート時に起動されるようにします。- Red Hat Enterprise Linux 6 の場合:
# service watchdog start # chkconfig watchdog on
- Red Hat Enterprise Linux 7 の場合:
# systemctl start watchdog.service # systemctl enable watchdog.service
4.5.3. ウォッチドッグ機能の確認
ウォッチドッグカードが仮想マシンにアタッチされ、
watchdog サービスがアクティブな状態であることを確認します。
警告
以下の手順は、ウォッチドッグの機能をテストする目的のみで記載しています。実稼働環境のマシンでは決して実行しないでください。
手順4.11 ウォッチドッグ機能の確認
- ウォッチドッグカードがアタッチされた仮想マシンにログインします。
- ウォッチドッグカードが仮想マシンによって認識されていることを確認します。
# lspci | grep watchdog -i
- 以下のコマンドを実行して、ウォッチドッグがアクティブな状態であることを確認します。
- カーネルパニックをトリガーします。
# echo c > /proc/sysrq-trigger
watchdogサービスを終了します。# kill -9 `pgrep watchdog`
ウォッチドッグタイマーがリセットできなくなり、ウォッチドッグカウンターはその後すぐにゼロに達します。ウォッチドッグカウンターがゼロに達すると、仮想マシンの ウォッチドッグ ドロップダウンメニューで指定したアクションが実行されます。
4.5.4. watchdog.conf 内のウォッチドッグ用パラメーター
以下の一覧には、
/etc/watchdog.conf ファイルで使用可能な watchdog サービスの設定オプションをまとめています。オプションを設定するには、そのオプションのコメントを解除して、変更を保存した後に watchdog サービスを再起動する必要があります。
注記
watchdog サービスの設定と watchdog コマンドのオプションについての詳しい説明は watchdog の man ページを参照してください。
表4.2 watchdog.conf の変数
| 変数名 | デフォルト値 | 備考 |
|---|---|---|
ping | 該当なし | アドレスが到達可能かどうかを検証するためにウォッチドッグが ping の送信を試みる IP アドレス。ping の行をさらに追加して複数の IP アドレスを指定することができます。 |
interface | 該当なし | ウォッチドッグがモニターしてネットワークトラフィックの有無を確認するネットワークインターフェース。interface の別行に追記して複数のネットワークインターフェースを指定することができます。 |
file | /var/log/messages | ウォッチドッグが変更をモニターするローカルシステム上のファイル。file の行をさらに追加して複数のファイルを指定することができます。 |
change | 1407 | ウォッチドッグの間隔の数。この値を超えると、ウォッチドッグがファイルへの変更を確認します。change の行は、file 行の直後の行に指定する必要があります。この設定は、change 行の直前の file 行に適用されます。 |
max-load-1 | 24 | 仮想マシンが 1 分間維持することのできる負荷の最大平均。この平均値を超えると、ウォッチドッグがトリガーされます。値を 0 に設定すると、この機能は無効となります。 |
max-load-5 | 18 | 仮想マシンが 5 分間維持することのできる負荷の最大平均。この平均値を超えると、ウォッチドッグがトリガーされます。値を 0 に設定すると、この機能は無効となります。デフォルトでは、この変数の値は max-load-1 の約 3/4 の値に設定されます。 |
max-load-15 | 12 | 仮想マシンが 15 分間維持することのできる負荷の最大平均。この平均値を超えると、ウォッチドッグがトリガーされます。値を 0 に設定すると、この機能は無効となります。デフォルトでは、この変数の値は max-load-1 の約 1/2 の値に設定されます。 |
min-memory | 1 | 仮想マシン上で空けておく必要のある仮想メモリー容量。この値は、ページ単位で計測されます。値を 0 に設定すると、この機能は無効となります。 |
repair-binary | /usr/sbin/repair | ウォッチドッグのトリガー時に実行されるローカルシステム上のバイナリーファイルのパスとファイル名。指定したファイルによって、ウォッチドッグがウォッチドッグカウンターをリセットするのを妨げている問題が解決される場合には、ウォッチドッグアクションはトリガーされません。 |
test-binary | 該当なし | 各期間にウォッチドッグが実行を試みるローカルシステム上のバイナリーファイルのパスとファイル名。テストバイナリーにより、ユーザー定義のテスト用ファイルを指定することができます。 |
test-timeout | 該当なし | ユーザー定義のテストを実行することができる時間制限 (秒単位)。値を 0 に設定すると、ユーザー定義のテストを期間無制限で継続することができます。 |
temperature-device | 該当なし | watchdog サービスが実行されているマシンの温度を確認するデバイスのパスと名前 |
max-temperature | 120 | watchdog サービスが実行されているマシンの最大許容温度。この温度に達するとマシンが停止します。単位換算は考慮されないため、使用しているウォッチドッグカードに適合した値を指定する必要があります。 |
admin | root | メール通知の送信先メールアドレス |
interval | 10 | ウォッチドッグデバイスへの更新の間隔 (秒単位)。ウォッチドッグデバイスは、少なくとも毎分に 1 回更新があることを想定し、1 分間に更新がなかった場合には、ウォッチドッグがトリガーされます。この 1 分間はウォッチドッグデバイスのドライバーにハードコードされており、設定はできません。 |
logtick | 1 | watchdog サービスで詳細ログ記録を有効にすると、watchdog サービスは定期的にログメッセージをローカルシステムに書き込みます logtick の値はメッセージが書き込まれるウォッチドッグの間隔を示します。 |
realtime | yes | ウォッチドッグがメモリー内にロックされるかどうかを指定します。値を yes に指定すると、ウォッチドッグはメモリー内にロックされ、メモリーからスワップアウトされませんが、値を no に指定すると、ウォッチドッグはメモリーからスワップアウトできるようになります。ウォッチドッグがメモリーからスワップアウトされた後、ウォッチドッグカウンターがゼロに達する前にスワップインで書き戻されなかった場合には、ウォッチドッグがトリガーされます。 |
priority | 1 | realtime の値が yes に設定されている場合のスケジュールの優先順位 |
pidfile | /var/run/syslogd.pid | 対象のプロセスがアクティブかどうかを確認するためにウォッチドッグが監視する PID ファイルのパスとファイル名。対象のプロセスがアクティブでない場合には、ウォッチドッグがトリガーされます。 |

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.