fluentd+MetabaseでAccess.log可視化の試み
ヨシダです。
Software Designのバックナンバー2017年3月号を読み返しました。
本号はログ＆データ分析基盤入門が特集されており、非常に興味がある分野で、かつこれからの働き方改革にマッチしたネタでもあると考え、ログ可視化を試してみました。
ダッシュボードには５種類をサンプルとして作成した。
1.平均レスポンス時間
2.ステータス別件数
3.アクセス先件数
4.時間帯別アクセス数
5.アクセス遅延監視
調査の目的
１．本番サーバーにおける障害検知、初動調査のスピードアップ。
２．ログの民主化。
３．ログのデータラングリングによるAI活用素材提供。
１．本番サーバーにおける障害検知、初動調査のスピードアップ
本番サーバ障害の検知方法について、リアルタイム監視、検知するソリューションは数多あるが、OSSで実用に耐えうるソリューションを調査し、活用する道筋を立てることが調査目的の１つでである。
２．ログの民主化
障害調査が属人化することは特定要員の負荷上昇を招き、解決スピードを低下原因となり問題である。チーム全員が短時間でログ調査を完結できることが望ましい。適したソリューションを調査するのが目的の１つである。
３．データラングリングによるログのAI活用
システムのクラウド化、複雑化に伴い閾値監視の限界が問われる中、ログのパターンを分析、学習し障害予測するソリューションが近年リリースされている。
コグニティブ技術で実現する次世代システム監視～システム障害の予兆を検知(https://www.imagazine.co.jp)
著名なAIソリューションを使う場合にしても、社内で内製するにしても、対象ログをツールやサービスにInputする場合には「データ取得」「データ加工」の２工程が必要になる。この２工程すなわち「データラングリング」の手法を学習し、ログファイルだけではなく、JSON、XML、PDF、Excel等多様なデータソースに対応できるスキルを習得することは、サーバやIot機器、センサーが提供するデータだけではなく、官公庁が提供する公的データ等の活用も期待でき、AIのさらなる活用が期待できる。「データラングリング」の手法調査が目的の１つである。
調査したソリューション
図：システム構成図
システム構成に対して「Log収集」「可視化」の２種類のツール導入を前提に調査した。
「Log収集」
flientdはOSSログ収集ツールの中で最もメジャーなツールである。特徴は300を超えるInput/outputプラグインにより、様々なデータ収集/データ格納のチャネルが標準で準備されている事である。Yahoo!がヤフオクやショピングサイトのサーバログ収集に用いている事例があり、大規模システムにも耐える実績あり。競合としてlogstash、Apache Flumeなど。
「可視化」
Metabaseは導入が容易である。LinuxやMacであれば１コマンド数秒で可能であり、データ元のデータベース設定もブラウザベースで可能と操作も容易で取っ付きやすい点が特徴である。
競合はElasticsearch、Re:dash、Supersetなど。
所感
メリット
・導入が容易。flientdとMetabaseはJavaベースのアプリでjar化済モジュールをgithubからダウンロードしてくれば直ぐに起動する。Ansibleで構成管理すれば横展開も容易になる。
・ブラウザ+SQLのハイブリッド。Metabaseはブラウザ操作だけではなくSQLでカスタムレポートを作成可能である。品質管理レポート作成の内容充実化や効率化に一役担えるツールと考える。
・Slackとの連携が可能。メール通知ではなくSlackへの通知は、チームメンバー全員にエラーを通知することが容易である。普段からSlackを運用しているチームへの導入障壁が低い点はメリットとなりうる。
問題点
・システムには適切なサーバースペックが必要となる。可視化ツールはMetabaseだけではなく他の競合OSSソリューション全てにおいて、相当量メモリを消費する。試しにAWS EC2のt2.micro構成で実験してみたが、起動はメモリ関連のエラーにより失敗。４Gbyte程度のサーバメモリは必要であり、サーバをクラウド調達する場合ランニングの検討が必要となる。
・「Logパターン解析」の前工程が発生する。F.ACEのように多少ログ出力をカスタマイズしているシステムを「Log取得」の対象とする場合、標準プラグイン(nginx標準)では対応出来ない。本調査では正規表現で対応したが、非常に面倒。
以上
