Nagiosと連携して運用自動化！ 事例と適用ポイント： OSS「JobScheduler」で実現するこれからの運用自動化（5）（3/3 ページ）

JobSchedulerのジョブ実行ログの参照

　これまでの説明で、APIを介して、JobSchedulerに対しOrderの追加、変更、削除ができるようになりました。では、Orderで実行したJobChainの結果は、どのように参照すればよいのでしょうか。

　JobSchedulerでは、MySQLやPostgreSQLなど、インストール時に指定したデータベースに設定やログが保存されています。そのため、実行結果はデータベースから参照できます。

　具体的には、「scheduler_order_history」テーブルにOrderで実行したJobChainの結果が格納されています。CakePHPではSchedulerOrderHistoryモデルを作成して、これを参照します。JobChainOrderモデルとは、order_idを外部キーとしてhas many関係を設定しておくとよいでしょう。

$options = array('conditions' => array('SchedulerOrderHistory.' . $this->SchedulerOrderHistory->primaryKey => $id));
$this->set('schedulerOrderHistory', $this->SchedulerOrderHistory->find('first', $options));

　ちなみに、このコードはCakePHPのbakeコマンドを使用して自動生成したものです。これだけで、実行結果を参照できるようになります。

ログ参照画面

　ところで、JobSchedulerがセットアップするテーブル名、カラム名は全て大文字になっています。それを前提としてコードを書いてもいいのですが、CakePHPではどちらも「小文字」が原則ですから、テーブル名とカラム名は小文字にして作り直し、MySQLの設定ファイル（my.cnf）に下記の設定を追加するとよいでしょう。

lower_case_table_names = 1

　Viewの方も見てみましょう。これもbakeコマンドで自動生成したものです。

<dl>
	<dt><?php echo __('Order Id'); ?></dt>
	<dd>
		<?php echo h($schedulerOrderHistory['SchedulerOrderHistory']['order_id']); ?>
		 
	</dd>
	<dt><?php echo __('Start Time'); ?></dt>
	<dd>
		<?php echo h($schedulerOrderHistory['SchedulerOrderHistory']['start_time']); ?>
		 
	</dd>
	<dt><?php echo __('End Time'); ?></dt>
	<dd>
		<?php echo h($schedulerOrderHistory['SchedulerOrderHistory']['end_time']); ?>
		 
	</dd>
	<dt><?php echo __('Log'); ?></dt>
	<dd>
		<?php echo h($schedulerOrderHistory['SchedulerOrderHistory']['log']); ?>
		 
	</dd>
</dl>

　logカラムにはジョブが実行時に出力したメッセージ、ログが全て保存されていますが、JobSchedulerのデフォルトインストールでは、おそらく、ログが化けて見えてしまうでしょう。これは、logカラムだけgzipで圧縮した上で格納する設定になっているためです。

　アプリケーション側でgzip圧縮を展開した上で表示してもいいですが、手っ取り早いのは、logカラムに平文を格納してしまうことです。JobSchedulerユーザーのホームディレクトリ配下にある、sos-berlin.com/jobscheduler/（Spooler ID）/config/factory.iniを下記のように設定します。

history_with_log        = yes		; gzipからyesに変更する（以下同）
order_history_with_log  = yes
history_archive         = yes

　データベースとしてMySQLを使用している場合、JobSchedulerの以前のバージョン（1.3系）では、照合順序としてlatin1_swedish_ciが指定されていました。ログに日本語が出力される場合、そのままでは文字化けが発生してしまうので「utf8_general_ci」に変更する必要がありました。

　しかし、2013年10月時点で最新バージョンである1.5.3253では、最初から「utf8_general_ci」が指定されるため、特に問題はありません。

Nagiosとの連携を実現する

　JobSchedulerによるOrderの実行結果は、標準のWeb画面である「JOC」から参照できますし、エラー発生時にメールで通知する機能もあります。

　しかし、既に何らかの監視システムが構築されていることもある、いやむしろ多いでしょう。そうした環境を生かすため、ここではオープンソースの監視システムであるNagiosに対して結果を連携する方法を紹介します。

　Nagiosに対して外部から監視結果を通知する方法は幾つかありますが、ここでは「Nagios Service Check Acceptor（NSCA）」を用いる方法を説明します。NSCAを使うと、NagiosとJobSchedulerが別のサーバーに導入されていたとしても、TCP通信で結果を通知できます（もちろん、同じサーバーに導入されている構成でも構いません）。

　まず、下記のようなジョブを作成します。

<?xml version="1.0" encoding="ISO-8859-1"?>
<job  order="yes" stop_on_error="no">
    <script  language="shell">
        <![CDATA[
echo "starting SendResultToNagiosJob..."
HOST_NAME=$SCHEDULER_PARAM_HOST_NAME
SERVICE_DESC=$SCHEDULER_PARAM_SERVICE_DESC
RESULT=$SCHEDULER_PARAM_RESULT
OUTPUT=$SCHEDULER_PARAM_OUTPUT
/usr/bin/printf "%s\t%s\t%s\t%s\n" "$HOST_NAME" "$SERVICE_DESC" $RESULT "$OUTPUT" | /opt/nagios/libexec/send_nsca localhost -c /opt/nagios/etc/send_nsca.cfg
echo "SendResultToNagiosJob completed."
exit 0
        ]]>
    </script>
    <run_time />
</job>

　ジョブの引数として、Nagiosで管理されているホスト名とサービス定義名、さらに監視結果（0:OK / 1:WARNING / 2:CRITICAL）と、監視出力（監視結果を示すメッセージのようなもの）を取得します。

　後はNSCAで提供されているsend_nscaコマンドを使って、Nagiosホスト側のNSCAデーモンに結果を送信します。

　このジョブは、JobSchedulerとNagiosを併用する際に極めて汎用的なものです。全てのJobChainの最後にこのJobを入れておくことで、全てのJobChainの実行結果がNagiosに連携されるようになります。

　このように、共通で使用できる汎用的なJobを作成できるのも、「JobChainによって複数のJobを柔軟にまとめることができる」というJobSchedulerの特徴故です。

まとめ〜DevとOpsが手を組むために〜

　第5回では、業務システムにJobSchedulerを組み込むメリットを紹介した上で、実際にコードを示し、JobSchedulerを組み込んだシステムを開発する方法を解説しました。

　筆者は、基本的に業務システムの開発をずっとやってきた「Dev側」のエンジニアです。そのため、JobSchedulerのような「Ops側」に位置付けられるソフトウェアは縁遠いのが現実でした。しかし、縁あってJobSchedulerに触れてみると、それはDev側のエンジニアにとっても十分興味深く、可能性を感じるものでした。

　この連載も最後となりましたが、まさにDevOpsの時代の中、一連の記事を通じて、Ops側のエンジニアだけなく、Dev側のエンジニアもぜひ、JobSchedulerに興味を持ち、日本JobScheduelrユーザー会に足を運んでいただければ幸いです。