実運用の障害対応時間比較に見るFluentd＋Elasticsearch＋Kibanaのログ管理基盤の効果：実運用が分かる、OSSでログ管理入門（2）（2/2 ページ）

ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介します。

[嶋田啓伍，三菱総研DCS]

ログの一元管理

　それぞれのサーバで出力されているログは、FluentdによりリアルタイムでElasticsearchに転送されます。各サーバに分散していたログが一元的に、かつリアルタイムで管理されることになります。スポット的に発生した障害を調査する際、エラーが発生したサーバと並行して他のサーバのログを確認できます。

　また対象システムでは、集約したログ情報をサーバごとに色を分けてヒストグラムを表示しています（図3）。

図3　Kibana画面イメージ

　アクセス量の調査においてもログ管理基盤を用いることで、目的としているグラフを短時間で取得し、アクセス量の相対的な比較を効率的に行っています。このように冗長構成を組んでいる場合においても横断的なログ調査が可能となり、障害調査にかかる時間を短縮できます。

その他の利点

　課題の部分で記載しましたが、サーバ上で直接ログを操作することは危険性を伴います。

　Fluentdのログ収集処理は、ログを出力するプロセスとは非同期で行われます。またElasticsearch、Kibanaは別の管理用サーバで稼働させているため、サービスへの影響はありません。加えてユーザーの知識や技術に左右されず、GUIによる直感的な操作も実現しているため、弊社では入社間もない新人でもログ調査を行っています。さらに、別の案件でも同じログ管理基盤が構築されていれば、一度覚えたKibanaの操作方法が無駄になることはありません。

　これまで記載したログ管理導入前後の効果を図にまとめました（図4）。

図4　ログ管理基盤導入前後の効果

導入前後の障害対応時間比較

　実運用の中で、ログ管理基盤が具体的にどの程度効果を発揮しているのか。障害発生から恒久対応を除く暫定対応完了までの間を以下の4ステップに分けて、ログ管理基盤を導入した場合としない場合の各ステップの対応時間を比較します。今回、想定する状況は『プログラム不備によりデータ不整合が発生しオンラインサービスでシステムエラーが発生した。暫定対応としてデータパッチを実施して解消した』場合としています。

• 【1】事象確認：障害検知、サービスへの影響有無の確認
• 【2】調査：影響調査、対象サーバのログ取得・調査
• 【3】暫定対応：調査を基にした暫定対応内容検討、暫定対応実施
• 【4】暫定対応内容確認：暫定対応後の確認

　結果は、表1、図5に示す通りです。

表1　ログ管理基盤導入前後の障害対応時間比較

	利用前（分）	利用後（分）
【1】事象確認	13	15
【2】調査	62	8
【3】暫定対応	70	65
【4】暫定対応内容確認	14	6

図5　ログ管理基盤導入前後の障害対応時間比較

　【1】事象確認、【3】暫定対応は、ログ管理基盤を介さない部分となるため、それほど大きな違いはありません。対象システムにおいて、顕著に対応時間の短縮が見られるのは【2】調査部分です。これまで記載してきた通り、障害発生前後のログの取得、サーバをまたいだ横断的な調査を短時間で実現しているためです。また【4】暫定対応内容確認に関しても、ログレベルで同様の障害が発生していないか確認を行うため、効果が出ていることが分かります。

次回は、ログ管理基盤の最新動向、障害対応以外のログ管理基盤の利用方法

　今回は、実運用におけるログ管理基盤導入前後の効果という観点で記載してきました。対象システムでは、Fluentd、Kibana、Elasticsearchを利用したログ管理基盤以外にも、JenkinsやRedmineといったOSSを利用した運用を行っています。今後、OSSの活用事例として、機会があれば紹介したいと思います。

　次回は、ログ管理基盤の最新動向、ならびに実運用で検討している障害対応以外のログ管理基盤の利用方法を紹介します。