Zebriumのログ分析機能 （2）異常検知とヒートマップ
Zebriumには、ログを構造化したのち、複数のログを突き合わせて異常を自動的に検知し、重大度の大きい箇所をダッシュボードに表示する「ヒートマップ」という機能がある。ヒートマップは、複数のログを突合して出力されているデータの相関を判断し、障害に関与している箇所を4種類程度の重大度に分類して表示する機能である。人間が障害の原因を突き止める作業においても、「どこが本当の障害箇所を示すエラーなのか」を明らかにすることが重要だが、ヒートマップはそれを支援してくれる機能だ。
複数のログを突き合わせて最も障害の可能性が高い時刻をサジェストするヒートマップ機能。
04:54:40近辺が被疑箇所であることが示されている。
実際にログを読んだ経験のある人には分かると思うが、一般にログには「障害の原因以外で起きたエラーやアラート」も大量に記録されているうえに、混乱した現場においては、正確にいつ障害が発生したのかを知ることが意外に難しい。最初の障害をトリガーとして二次障害、三次障害が発生することもあり、そうなると現場はカオスである。また、障害には確かに関係しているのだが、「根本原因ではないエラー」というのも、ログには大量に記録される。たとえば、本当の障害箇所がデータベースであっても、その影響を受けてフロントのWebサーバやAPサーバもエラーを出力したりダウンすることは頻繁に起きる（注3）。
したがって、ログ解析を行う人間には、「どこが根本の障害箇所なのか」を突き止める能力が必要なのだが、そのためにはエンジニアにも障害対応の経験、いわゆる「場数」が求められる。医者が問診や検査から病気を突き止めるために多くの症例を頭に入れておく必要があるように、障害解決に挑むエンジニアも多くの障害パターンを知っている必要がある。だが従来、そうした経験豊富なエンジニアは希少であり、そのノウハウも形式化が難しく属人化されていた。Zebriumは、こうした問題に悩む運用の現場にとっては大きな福音となる可能性を持っている。Zebriumの目指すところは、人間の関与なしに自動的に障害箇所を特定することだからだ。
他にも、特定のイベントや重大度でフィルタリングしたり特定のログパターンを登録して該当箇所を検出する「シグネチャ」と呼ばれる機能など、ログ解析に便利な機能が用意されている。（パターンとはたとえば、特定のキーワードAがあるログファイルに出現したあとに、キーワードBが異なるログファイルに出現する、といったものであり、複数のログを横断で設定できる）。シグネチャでヒットした情報をCSVとしてダウンロードも可能である。
特に、ユーザが検出した異常のレベルをフィードバックすることで、検出アルゴリズムを学習させられる機能は、機械学習を採用したツールならではのユニークなものだ。たとえば、当初Criticalレベルで検出された異常が実際には検出不要の事象だった場合には、そのパターンの優先度を下げるようエンジンに示唆を与えられる。これによってユーザごとに異常検知のアルゴリズムがカスタマイズされていく。
注3
データベースが応答を返さなくなると、WebサーバやAPサーバのスレッドやプロセスの数が滞留を始めることで異常に増加し、メモリなどのリソースを食い潰してダウンしたり、パラメータで設定されているプロセス数などの上限に抵触してエラーを返し始める。こうしたケースでは、いくらWebサーバやAPサーバを復旧したりリソースを増強しても障害は解消しない。時には悪化させることすらある。
