Zebriumのログ分析機能 （1）構造化
Zebriumのログ分析機能は、大きく次の3つの機能によって実現されている。
- ログ構造化：非構造データのフォーマッティングと時系列での整列
- 異常検知：機械学習を通した異常検知
- ヒートマップ：検出された異常の重みづけと時系列ベースの可視化
1つめのログ構造化とは、様々なフォーマットで出力されるアプリケーション、ミドルウェア、OSのログを自動的に構造化し、すべてのログを統合して時系列に沿って表示する機能である。
ログ解析を行ううえでは、CSVやリレーショナルデータベースのテーブルのような二次元表の形にフォーマットされているのが最も扱いやすい。端的に言うと、Excelに取り込みやすい形である。しかし、現実のログはそのようなきれいなフォーマットにはなっていない。タイムスタンプや重大度（Severity）など、ログ解析に重要な情報ですらすべてのレコードに付与されていないこともある（たとえばJavaのStack Traceなどが代表的である）。しかも、アプリケーションログにおける最も重要な情報は構造化されていないことも多い。Zebriumはこうした欠落をログの内容や前後の情報から自動的に判定し、補完してくれる。
構造化によって、ログはたとえば以下のような項目（カラム）別にフォーマットされる：
- タイムスタンプ
- ログ種別
- 重大度
- 変数（ログ内に表示されるパラメータ名や値）
- エラーメッセージ
適切なヘッダ情報がないログであっても、ある列が文字列かどうか、文字列ならばその内容を見て「この列はタイムスタンプ」「この列は重大度」というように自動的に判断を行う。これらは教師なし機械学習によって行われ、ユーザによる明示的な学習プロセスは不要である。
この構造化機能は、いわばデータプリパレーション（前処理）を代替してくれるものだ。AIなどの分析にかける業務データのフォーマットが構造化されていないという問題に対して、近年、データの整形や名寄せ、重複排除といった前処理に特化したインテリジェントなツールが多数登場している。シリコンバレーを拠点とするスタートアップにも、TamrやTrifactaなどが知られている。Zebriumもまた、ログ解析の前処理として必要なログの構造化に特化したデータプリパレーション機能を持っているわけである。
障害対応の現場では、こうした非構造化データを含む雑多なフォーマットのデータ整形や時系列の突き合わせという作業を、自作のツールやExcelを使って行うことが多い。この面倒なステップは（何しろログのデータ量が多いので）意外に時間を消費するわりに、しょせん解析の準備としか見なされず、顧客からの評価も低い。早く終わらせられるに越したことはないのだが、前述のようにミドルウェアやアプリケーションによってログフォーマットはまちまちで、しかも解析に適したフォーマットですら出力されないこともあるため、自動化が難しいという難点がある。この機能だけでもかなり助かるという開発や運用の現場は多いのではないだろうか。
大量のログを読み込む場合、その実行時間も気になるところだが、SCSKのシリコンバレー拠点でZebriumの機能評価を実施している中原氏によれば「数百万行のログでも10～20分程度で読み込まれるうえに、ストリーミングで実施されるため、読み込み中でもログ解析を始めることができる」という（注2）。
注2
SCSKは早くからZebriumに注目しており、現在同社内での技術検証を進めている。本稿の執筆においても同社のシリコンバレー拠点で活動される遠藤丈寛氏と中原丈晴氏にご協力いただいた。
