ログ管理

（仕様が決まったら英語にするか、必要なくなるなら削除する。）

要求

次の要求を満たすログ管理機能の仕様を検討する。

• 高効率なログ監視の仕組み
• 上記の設定を行うUIの用意
• 任意の範囲の時間範囲・マシン名等を指定してログを検索する機能

方針

次に示すユースケースを解決する仕様とすることで要求を満たす仕様を目指す。

• ○○というサービスを運用しており、そのシステムで障害が発生したらできるだけ速くサービスを復旧させたい
  • どのようなサービス（たとえばWebサービスなど）でZabbixを利用しているかまだ把握していない。そのあたりの情報をもらったら具体化する。
• ログを監視し、事前に設定した特定のキーワードにマッチしたら障害が発生したと判断し、アラートをあげたい。
• アラートがあがった障害はインシデント管理システムに登録され、障害対応の記録はそこで一元管理したい。
  • 今後同様の障害が発生したとき、対応の参考にするために参照したい。
• 障害を調査するときはログを参照したい。
  • 障害対応する人が使うと思っていたけど違った。
    • 障害発生時近辺の該当サービスのログを参照したい。
    • 障害発生時近辺の該当サービスが動いているマシンのログを参照したい。
      • CPU使用率やディスクI/O量などの統計情報はログよりもグラフで参照したい。
    • 障害発生時近辺の該当サービスが利用しているサービスのログを参照したい。
    • 障害発生時に今後同じ障害が発生したことを検出するアラートを新規で作るためにログを参照したい。
  • オペレーターの人（システムのことは詳しくない）が使う。
    • 障害発生時に障害対応する人に連絡しやすいとよい。
    • データをエクスポートして障害対応する人に渡したい。
    • エクスポートする前に絞り込めるとよい。
  • 情報システム部門の人？
• 障害対応報告書を作りたい。
  • 表計算ソフトにインポートしたい。（CSVでエクスポートできるとインポートできる。）
• アラートがあがった障害が既知の障害で対応方法が確立されているなら自動で復旧して欲しい。
  • そうでもない。勝手に復旧しないで復旧する前に確認したい。

ユースケース2:

• ログを保存したい
  • 保存する決まりだから。
  • 参照するときはもれなくが大事。

このユースケースのうち、ログ管理機能で対応する項目は次の通りである。

• ログを監視し、事前に設定した特定のキーワードにマッチしたら障害が発生したと判断し、アラートをあげたい。
• 障害を調査するときはログを参照したい。
  • 障害発生時近辺の該当サービスのログを参照したい。
  • 障害発生時近辺の該当サービスが動いているマシンのログを参照したい。
  • 障害発生時近辺の該当サービスが利用しているサービスのログを参照したい。

これらの項目は次の要求に対応する。

• 高効率なログ監視の仕組み
• 任意の範囲の時間範囲・マシン名等を指定してログを検索する機能

しかしながら、次の要求には対応する項目がない。これについてはHatoholの設定UIとログをどのように監視したいか（単なる正規表現マッチで十分なのか、もっと高度な方法が必要かなど）を確認してから検討する。

• 上記の設定を行うUIの用意

構成

Zabbixのログ監視機能は次の問題があるという。

• 負荷が高い
  • TODO: 具体的にどういうケース？たくさんのログファイルを読んでしまうケース？普通のログのサイズでも文字列処理が重いってこと？
• 即時性が低い
  • TODO: 具体的にどういうケース？他の処理をしていてログ監視機能が後回しになるってこと？

そのため、ログ監視にはZabbixを一切使わず、Fluentdを使ったログ監視システムを構築し、そのシステムとHatoholを連携する。

Fluentdではログのマッチをするマシンを分散することができる。そのため、負荷が高い場合は処理を分散することで問題を解決できる。即時性が低い場合も分散することで解決できる。

Fluentdは様々なストレージ（各種データベースを含む）にログを格納することもできるので、ログの検索のためのデータベースもFluentdを使ったログ監視システムで構築できる。

Fluentdを使ったログ監視システム案

Fluentdはプラグインベースのアーキテクチャを採用しているため、Fluentdを使ったシステムを検討する場合は、次の点を検討すればよい。

• どのプラグインを利用するか。
• どのような配置にするか。

プラグインは次の3つの観点で検討すればよい。

• 入力 - ログをどうやって収集するか
• フィルター - ログをどうやって選択するか
• 出力 - ログをどこに送るか

入力は監視対象次第である。syslogであれば、 in_syslog で直接受け取ることもできるし、 in_tail で/var/log/messagesなどから収集することもできる。監視対象を定めたら検討する。

フィルターでログの中に特定の文字列があるかどうかをチェックする。負荷が高い場合は、フィルターを複数のマシンで動かすことで負荷を分散させる。

正規表現で特定の文字列があるかどうかを確認するには fluent-plugin-rewrite-tag-filter が使えそうである。

出力はHatoholである。特定の文字列があったらHatoholにアラートを通知する。このときHatoholの○○というAPIを使う。（TODO: HatoholにはどんなAPIがある？）

Hatoholにアラートを送るFluentdのプラグインは存在しないため、これは新規に開発する必要がある。これは、（HatoholのAPI次第だが）1日で実装可能である。

Fluentdを使ったログ検索システム案

ログを検索するためにはログを蓄積しておく必要がある。高速に検索できるようにするにはデータベースに格納し、適切なインデックスを張る必要がある。高速でなくてもよい場合は単にストレージに保存しておくだけで十分である。

データベースを導入すると高速に検索できるというメリットはあるが、システムの管理コストが大きくなるというデメリットがある。

ストレージに保存するだけならサイズくらいを考慮するだけでよいのでシステムの管理コストは小さい。しかし、高速な検索は実現できない。

ここで想定しているユースケースは障害調査なので、それほど参照することは多くないと仮定できる。そうすると、単にストレージに保存しておき、障害が発生し、インシデント管理システムにインシデントとして登録するときに1度だけ関連ログを切り出して添付する、というやり方でも十分かもしれない。

データベースを使うなら、MongoDBがよく使われているようなので、MongoDBを使うという選択肢が考えられる。（感覚的なものなので、本当かどうかはわからない。）

個人的にはGroongaを推したい。理由はGroongaの開発に参加しているからである。検索機能、性能の面で考えるとデータベース間でそれほど大きな違いはないはずである。

MongoDBに蓄積する場合は fluent-plugin-mongo を利用する。

Groongaに蓄積する場合は fluent-plugin-groonga を利用する。

懸念点

• インシデント管理システムとどのくらい連携できる？
• 今のHatoholのAPIはどのくらい充実している？
• Zabbixでのログ監視まわりの情報はいつくらいに入手できる？