Elastic Stackのアラート
アラートは、Elasticのユースケースに不可欠です。2015年にWatcher（Elasticsearch向けにアラートを提供していたオリジナルシリーズプロダクト）をリリースして以来、Elasticには多数のフィードバックが寄せられ、アラートシステムがどうあるべきか、ユーザーエクスペリエンスがどうあるべきかについて理解を深める手助けとなってきました。本ブログ記事では、アラートに関するElasticの主要な知見をまとめるとともに、2019年現在、その知見が私たちの作業にどのような影響を与えているかや、Elastic Stackのアラートの今後についてお伝えしてまいります。
アラートについて
私たちはElasticでアラートに従事してきたこの4年間、アラートシステムに関して豊富な知識を獲得しました。Elasticが理解した内容は、未来志向の3つの所見にまとめることができます。すなわち「あらゆるユースケースにアラートが見られる」、「複数のユースケースにわたって意味をなすアラートにする必要がある」、「アラート検知と対応はますます洗練されている」という3点です。この3つの理解が、Elasticが考える「今後のアラート」を形成しています。
どこでもアラート
アラートは、Elasticのあらゆるプロダクトやユースケースにまたがって使われています。いわば「ライブデータのあるところに、アラートのケースあり」という状況です。Watcherが開発され、広く浸透した理由もそこにあります。一方、さまざまなユースケースから明らかなのは、「汎用型のアラートというものは存在しない」ということです。
Elastic Logs、SIEM、APM、Uptime、Infrastructure、Mapsといったプロダクトから、監視や機械学習といった機能や、多数のKibanaのダッシュボード、アラート、通知まで、すべてがクリティカルな役割を担っています。同時に、こうしたプロダクトや機能が条件を検知したり、それを表現する、あるいはコンテクスト内で表示する上で、各々に固有のニーズが存在します。アラートと監視を効果的に実施するためには、プロダクトに深く統合されている必要があります。スタックやその活用法の進化に応じて、Elasticsearchのアラートにも、緊密に統合され、各ユースケース内でのリッチなアラート表現を可能にする補完機能が必要であることが明らかになってきました。
“意味ある”アラートにする
「どこでもアラート」になった結果、様々なユースケースでアラートが生成され、アラート自体が独自のデータソースと化し、システムとその状態を理解する機会を提供するまでになっています。あるいはSite Reliability Engineering（SRE）コミュニティからは、システム全体のオブザーバビリティの向上機会だという指摘もでています。
いま、各ユースケースが独自の方法でデータを解釈し、ある1つの状況について、複数のアラートがさまざまな側面を示しています。インシデントに適切に対応できるかどうかが、複数のソースから来るデータと、異なるタイプのアラートとイベント同士の相関付けによる状況把握で決まる、ということは少なくありません。SIEMなどの一部のドメインでは、低次のアラートのパターンから、高次のアラートがトリガーされます。
Elastic Stackがますます多くのユースケースで使われるようになるにつれ、単にアラートを生成するだけが「適切なアラートシステム」ではなくなりました。適切なアラートシステムであるためには、アラートが複数のユースケースにわたって意味をなすよう支援することも必要です。たとえば、Uptimeのアラートがサービスの停止を表示しているとき、APMのアラートはどのトランザクションが問題を発生させたかの情報を提供しており、監視のアラートが原因をピンポイントで指摘している、といったことです。アラートシステムは、人間とマシンの双方に対して、コンテクストを提供し、相関付けを可能にし、アウェアネスを向上させるものでなければなりません。
検知とアクション
「“意味ある”アラートにする」こととは、より監視性にすぐれたシステムを使い、複雑な条件を検知できること、そしてより洗練されたアクションを講じるということです。こうなると、従来私たちが「アラート」として考えていたものとはかなり異なってきます。
これまでアラートに関しては、条件を検知して、人間の注意を喚起する機能が重視されており、多くの場合、それ以上のことは要求されませんでした。いま、アラートシステムを俯瞰的に見ると、制御、あるいはフィードバックのループの一部として捉えることができます。つまり、オブザーブし、条件を検知し、アクションを講じて、再びオブザーブする、というループです。
現在、一般的な「アクション」には通知が含まれます。すなわち、システムの制御と、修正を試みるループには人間がカウントされています。しかし、システムのインサイトが向上するにつれ、「アクション」が（通常は）人間の監視の下で、より広範な制御を引き受けることも可能になってきました。双方向通信（例：チャットボット）で制御される準自律的システムや、完全自律型システムがこれに相当します。自動スケールや自己回復、自己最適化アプリなどに見られるトレンドと同じ方向性の進化と言えるでしょう。
“検知”が単なるElasticsearchへのクエリに留まらない機能であること、そして“アクション”が単にメールを送るとか、ウェブフックをコールする以上の範囲をカバーする状況から逆算すると、アラートシステムは洗練された検知とアクションをサポートする必要があります。
知見を活かす
Elasticは2018年の秋に、Elasticのアラートを、上述の3つの所見をサポートするものにすると決定しました。
またその実施にあたって、アラートをKibanaの第一級エンティティとすることも決定しました。
- どこでもアラート：プラグイン、API、およびUIのレベルで、Elasticプロダクト全体にわたりリッチなアラートの統合を実現
- “意味ある”アラートにする：あらゆるアラートタイプにわたり、直感的なインターフェースを提供
- 検知とアクション：Kibanaプラグイン経由で、洗練された検知およびアクションのメカニズムを導入
またElasticは、Watcherの経験から、アラートが、運用負荷に対応する水準にスケールでき、かつ高可用で安定性にすぐれたものでなければならないことを理解しています。さらに、3つの所見のサポートを約束するAPI、UI、プラグイン/ライブラリは、確実でスケーラブルなベースの上に開発される必要があります。このすべての条件を満たすElasticのアラートシステムには、4つのレイヤーがあります。
2019年、私たちはKibanaに新しいアラートシステムの基礎を構築しました。
1月、6.7のリリースでTask Manager（タスクマネージャー）を追加しました。Task ManagerはKibanaのバックグラウンドスケジューリングに永続的なタスクを提供します。スケーラビリティとアベイラビリティ確保のため、タスクは複数のKibanaインスタンスに分散させることができます。Task Managerのようなアラートベースのレイヤーコンポーネントが実施できることは、アラートだけではありません。たとえばTask Managerによって、Kibanaの事前スケジュール済みのレポートエクスペリエンスが向上します。
さらに6月、私たちはKibanaに新しい2つのAPIを追加しました。“アラートAPI”と“アクションAPI”です。
アクションAPIを使うと、Kibanaにアクションを登録して発動させることができます。またアクションAPIは、独自のアクションを定義したり、簡単にカスタマイズするためのコントラクトを提供します。初回リリースには、例としてロギングやSlack、メール通知のアクションも提供されました。
一方、アラートAPIを使うと、Kibanaに検知の形式を“アラートタイプ”として登録することができ、Task Managementシステムを使って一連のチェックをスケジュール通りに実行できます。アクション同様、シンプルなアラートのコントラクトもあります。アラートを、Kibanaサーバーで実行されるJavaScript関数で表現できれば、アラートを駆動させることができます。
Elastic Stack 7.4は、低次のアラートシステムの補強に重点を置いています。セキュリティおよびspacesへのサポートを追加してAPIを強化したほか、インデキシング、ウェブフック、Pager Dutyなどの内蔵アクションを追加しています。
今後の予定
この数か月間、Kibanaのアラートシステムの開発は全力で進められてきており、7.xのリリースサイクルでも開発が継続される見通しです。Elasticは、アラートシステムを3段階で投入する予定です。
第1フェーズとして2019年の大部分を費やし、基礎を構築しています。スケーラブルなタスク管理とスケジューリング、アラート/アクション/APIのコントラクトに重点を置いています。
現在は第2フェーズへの移行中です。このフェーズでは、さまざまなユースケースをAPIとライブラリのレベルでアラートシステムに統合することが可能になります。また、アラートを意味あるものにする取り組みの一環としてKibanaのUIの再設計と開発を実施し、特定のユースケース（たとえば監視、Uptime、SIEMなど）で検証しています。
第3フェーズでは、テンプレートを使用したアラートであるか、Canvas表現などによる表現ベースのアラートかであるを問わず、Kibana全体でユーザー定義のアラートを実行可能にすることで、“どこでもアラート”と“検知とアクション”のテーマを拡張する予定です。
最終目標は、Elasticが“Elastic Stackのアラート”について持つビジョンを実現することです。ビジョンは、次の通りです。
- どこでもアラート：Kibanaにおいて、アラートは第一級の、空間アウェアなエンティティです。これにより、複数のグループにわたってアラートの作成と表示を分けることが可能となり、SIEMや監視、Uptimeをはじめとする各種プロダクトに、アラートをリッチに統合できます。ElasticのアラートはWatcherを補完するもので、併用が可能です。代替となるものではありません。
- “意味ある”アラートにする：リッチなアラート統合は、複数のアラートタイプにわたって包括的なビューを提供するKibana UIと、アラート履歴を相関付け、意味を持たせるツール類によって実現することができます。
- 検知とアクション：APIとプラグインは、Kibanaサーバーで実行するJavaScriptでの記述など、検知とアクションのメカニズムが、あらゆる指定に対応できるようにするために設計されています。これにより、SIEMや、オブザーバビリティソリューションなどのElasticプロダクトを経由してKibanaに表示される検知とアクションを、一層洗練させることが可能になります。