みなさんは監視していますか？ 健全な運用には、まずは適切な監視が重要です。そんな監視をするツールは、 2016 年現在いろいろありますが、そうは言っても、監視と言えばとりあえず Nagios です。ということで、今回はそんな Nagios について知っておきたいポイントを 5 つほど紹介したいと思います。
その 1: “Nagios” の読み方を知る
そもそも Nagios はどのように読む・発音するのでしょうか？ 巷ではどうも「ナギオス」派と「ナジオス」派がいるようです。どちらが正しいのでしょうか。実はこの問いに対しては公式に答えが示されています。
Nagios Support – How do you pronounce Nagios?
つまりカタカナで書くならば「ナギオス」が公式見解に近いと言えましょう。
なお、以前は、公式サイトで Nagios の発音の mp3 が置いてあったのですが、 What is the correct pronunciation of Nagios? に “Answer originally linked to an mp3 audio file which contained the pronunciation as spoken by Ethan, the author of Nagios. File is no longer hosted by Nagios.” とありました。残念ですね…。
その 2: 必読の書籍を知る
まずは書籍です。幸いなことに Nagios については良い日本語で書かれた書籍があります。
“Nagios統合監視［実践］リファレンス”です。 Nagios に触るならば、手元に置いておきましょう。
その 3: Nagios による監視プログラム実行の 3 パターンを知る
Nagios による監視プログラム実行のパターンは 3 つあります。
- Nagios が監視プログラムを直接実行する
- Nagios がリモートの監視プログラムを NRPE で実行する
- 監視プログラムが NSCA を使って、結果を Nagios に通知する
1 は最もポピュラーなやり方です。デフォルトの監視項目はこれで動いています。これが大量にあると、 Nagios が動いているサーバで大量の監視プログラムのプロセスが起動することになります。
2 の NRPE = Nagios Remote Plugin Executer は 1 ではできない・やりづらいケースで用います。現実的にこれが有効なのは、「そのサーバにしか置いていないプログラムや設定ファイルを使うような監視」をやる場合でしょうか。ただし、 NRPE は、監視に用いたいコマンドを nrpe.cfg という設定ファイルに記述し、 Nagios の設定ファイル側では、その設定でのコマンド名を指定する、というようになります。例えば、 nrpe.cfg が以下のように記述されている場合、
|
1 |
command[check_supervisord_procs]=/usr/lib64/nagios/plugins/check_procs -c 1:1 -C supervisord |
これを呼び出すには Nagios 本体側の設定ファイルで以下のように記述することになります。
|
1 2 3 4 5 6 7 8 9 10 11 |
define command{ command_name check_nrpe_supervisord_procs command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_supervisord_procs # -c で指定された文字列が nrpe.cfg でのコマンド名に対応する } define service{ use generic-service host_name host1, host2 service_description check_procs supervisord check_command check_nrpe_supervisord_procs # これは上 define command で定義されている } |
3 の NSCA = Nagios Service Check Acceptor はいわば監視プログラム側からのプッシュ型です。監視のタイミングを Nagios で定められるような定期的な設定にしたくない場合は、これの出番となります。例えば「ログに特定の文字列が書き出されたらその時点でアラートを上げる」という場合は、これを使うと自然にできます。
その 4: Nagios プラグインの書き方を知る
さて、どのような監視方式を選ぶにしても、任意の監視をやりたいとなると、 Nagios プラグインを自身で実装することになります。
Nagios プラグイン、とだけ聞くと、何か書くにあたってめんどくさいルールを覚えないといけないのでは、と臆してしまうこともあるかもしれませんが、基本的には 2 つのルールだけ覚えておけば OK です。
ルール 1: プログラムの exit status を Nagios プラグイン的にする
Nagios による監視のステータスというのは 4 種類あって、 OK, WARNING, CRITICAL, UNKNOWN ですが、これは Nagios プラグインの exit status にてそれぞれ 0, 1, 2, 3 に対応しています。つまり、
| ステータスのラベル | exit status の値 |
|---|---|
| OK | 0 |
| WARNING | 1 |
| CRITICAL | 2 |
| UNKNOWN | 3 |
ということです。自分で Nagios プラグインを書くときも、ただこれに従うだけで良いのです。
ルール 2: メッセージを標準出力に書き出せ。ただしもっとも重要なことは 1 行目に。
Nagios の WebUI の Services のような、監視項目（これを Nagios 的には service と呼んでいる）の一覧表では Status Information というところに、メッセージが表示されていますが、これは、 Nagios プラグインが標準出力に書き出した 1 行目（ = 最初の改行文字よりも前の内容）です。そして、その監視項目の詳細を開くと 2 行目以降も表示されています。ということで、監視結果のステータスと合わせて伝えたい内容は、まず 1 行目に重要なことを書き、 2 行目以降により詳細な内容を書き出すようにしましょう。
また、その 1 行目・ 2 行目以降の内容は、 Nagios の内部的にはそれぞれ $SERVICEOUTPUT$, $LONGSERVICEOUTPUT$という変数で保持されています。このことを知っていると、監視の通知をするメールの本文の組み立てに活かすことができます。
その 5: 「通知」のためのプログラムを知る
Nagios というと「監視がひっかかったら、メールで通知してくれる」というイメージが強かろうと思いますが、この「メールで通知する」というのは、そもそもデフォルトではどう実現しているのでしょうか？
「通知」について知るには、まず contact の定義を読む必要があります。
contact は文字通り「連絡先」で、つまり、「通知」を出す相手を表すモノです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
# # デフォルトの contacts.cfg からの抜粋 # define contact{ contact_name nagiosadmin ; Short name of user use generic-contact ; Inherit default values from generic-contact template (defined above) alias Nagios Admin ; Full name of user email nagios@localhost ; <<***** CHANGE THIS TO YOUR EMAIL ADDRESS ****** } # # デフォルトの templates.cfg からの抜粋 # 上の nagiosadmin が use している generic-contact の定義がこれ。 # define contact{ name generic-contact ; The name of this contact template service_notification_period 24x7 ; service notifications can be sent anytime host_notification_period 24x7 ; host notifications can be sent anytime service_notification_options w,u,c,r,f,s ; send notifications for all service states, flapping events, and scheduled downtime events host_notification_options d,u,r,f,s ; send notifications for all host states, flapping events, and scheduled downtime events service_notification_commands notify-service-by-email ; send service notifications via email host_notification_commands notify-host-by-email ; send host notifications via email register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL CONTACT, JUST A TEMPLATE! } |
この contact の定義に service_notification_commands と host_notification_commands という項目がありますが、これはそれぞれ service の監視・ host の監視で通知対象となったとき（WARNING や CRITICAL になったときや、そこから復帰して OK になったときなど）に呼び出すコマンドです。 commands と複数形で書かれているとおり、複数指定することができます。
デフォルトで用意されている contact では、それぞれのコマンドとして notify-service-by-email や notify-host-by-email というのが指定されていますが、これらはそれぞれ、その名前で command として定義されています。そこで、 notify-service-by-email という command 定義を探してみると、デフォルトでは commands.cfg に定義されており、その command_line はデフォルトでは以下のようになっています。
|
1 2 3 4 5 |
# 'notify-service-by-email' command definition define command{ command_name notify-service-by-email command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$ } |
これを読むとわかるとおり、実は単に、本文として送りたい内容を Nagios が用意している変数を使いつつ printf コマンドで書き出し、それを mail コマンドに食わせているだけなのです。
ここまで読み解いてくると、「通知」のためのプログラムというのも、なんら特別なことはない、ということがわかります。 “$” で囲まれている定義済みの変数を上手く使って、件名や本文を組み立てたコマンドを用意すれば OK です。この “$” で囲まれている変数の一覧は Standard Macros in Nagios で確認することができます。前のセクションで触れた $SERVICEOUTPUT$, $LONGSERVICEOUTPUT$ についても、こちらで紹介されています。
例えば Nagios と Slack を使っている人の場合は、これを使っているかもしれませんが、これも結局、定義済みの変数を上手く使って Slack の API を叩くようなプログラムを呼び出しているだけ、です。
まとめ
今回は、 Nagios を扱う際に知っておきたい 5 つのことを書いてみました。 Nagios とうまく付き合っていくために覚えておきましょう。
Hadoop おじさん業を営んでいるが、元々は Java と Perl のウェブアプリケーションエンジニア。 実はまだウェブアプリケーションエンジニアとしてのキャリアの方がギリギリ長い。冬は毎週末スキーに行くため、夏はおとなしく過ごす。
