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

　今回対象としたシステムは、さまざまな要件を実現するため、複数のパッケージ製品やOSS（オープンソースソフトウェア）を利用している大規模システムです。とりわけメインとなる業務処理は、アプリケーション開発で実現しており、これらは可用性を高めるために十数台のアプリケーションサーバで冗長構成を組んでいます。

弊社システムにおけるログ管理における課題

　続いて、ログ管理基盤導入前まで、弊社システムで抱えていたログ管理に関する課題を紹介します。

肥大化したログの扱い

　複数台あるアプリケーションサーバのうち幾つかは、ログ調査のためにトレースレベルでのログ出力が必須であったため、プレーンテキスト形式で1日に約6GBものログが出力されています。障害発生時、エラー発生箇所ならびに、その前後のログを取得するだけでも多くの時間を要していました。またログ調査自体にも危険性を伴います。

　過去に、障害発生時にサーバ上で肥大化したログを展開（catコマンド実行）しようとした結果、OOMキラー（Out of Memory Killer）が働き、Javaプロセスが停止するといった事象が発生しました。普段Linuxの操作になじみのない担当者が実施したということもあるのですが、そもそも『システムを保守していく上で、6GBにも及ぶプレーンテキスト形式のログをどのように扱っていくか』という点に課題があると考えました。

サーバごとに分散したログの扱い

　システム概要にも記載した通り、今回ログ管理基盤導入の対象としたアプリケーションサーバは冗長構成を組んでいます。障害発生時、Zabbix（サーバの監視ツール）によってエラーを検知したサーバや時刻は確認できますが、冗長構成を組んでいる別のサーバで同様のリスクがないか、また別のサーバが起因となっていないかなどの調査に時間がかかっていました。同様にアクセス量を調査する場合においても、各サーバに分散しているアクセスログを、ツールを用いてグラフ化し比較する、といったように手間を掛けないと横断的な調査はできませんでした。

対応策（ログ管理基盤導入）

　対象のシステムにおいて、このようなログ管理における課題を解決するため、Fluentd、Kibana、Elasticsearchを用いたログ管理基盤を導入しました。対象のサーバは冗長構成を組んでいる全てのアプリケーションサーバとし、収集対象のログはサーバログ、アクセスログとしています。導入したそれぞれのプロダクトのバージョンは以下の通りです。

• ログ収集ツール：Fluentd 0.10.41
• ログ検索ツール：Elasticsearch 0.90.9
• ログ可視化ツール：Kibana 3.0.0

　アプリケーションサーバの構成とログ管理基盤の関係を図1に示します。

図1　ログ管理基盤導入システムの構成

ログ管理基盤の導入効果

　続いて、ログ管理基盤導入後に明らかになった効果を紹介します。

視覚的に分かりやすいログ解析が可能

　保守担当者は、ブラウザ経由でKibanaにアクセスします。Kibanaは、ユーザーが指定した任意の形式でElasticsearchに蓄積されたログデータを変換することで、視覚的に分かりやすいログ調査を実現します。

　対象システムでは、収集したログ情報をヒストグラムならびに「サーバ名、時間、ログレベル、ログメッセージ」一覧として表示しています。ヒストグラム上で障害発生時間帯を範囲指定することで、グラフ範囲が絞られ同時に一覧の範囲も絞ることができます（図2）。

図2　Kibanaを用いた操作イメージ

　またフィルタリング機能で独自の検索条件を作成でき、例えばログレベルをエラー（level:ERROR）と記載することでエラーのみのログに絞ることができます。これらを駆使することでエラー発生時のログだけではなく、前後の詳細なログも簡単に確認できます。