こんにちは。torippy1024です。
本日は、SplunkのITOA(IT Operation Analysis)機能であるIT Service Intelligenceについてざっくりまとめます。
Splunk IT Service Intelligence(Splunk ITSI)とは
Splunk IT Service Intelligence(Splunk ITSI)とは、Splunkが提供する運用製品の一つです。
(資料によっては、ITSIは、ITOAとかAIOpsとかIT運用とかの異なるカテゴリで分類されていることがあります。本記事はざっくりと説明することが目的なので"運用"とざっくり説明することにします)
Splunk IT Service Intelligenceは、システムの健全性を、サーバー一台一台のCPUやメモリといった単位でなく、ユーザーに提供される「サービス」という単位で考え、それらサービスを細かいサブサービスにブレークダウンすることによってシステムの健全性を監視する製品です。
これによって、ITにあまり詳しくない担当者であっても、システムのどのサービス(または機能)がどのサービス(または機能)と関連しており、障害発生時の影響範囲特定を迅速に行うことができます。
公式サイト：
https://www.splunk.com/ja_jp/products/it-service-intelligence.html
Splunk IT Service Intelligenceは、Enterprise Securityと同じく、SplunkのPremium Appと呼ばれる有償Appです。
https://splunkbase.splunk.com/app/1841
公式サイト上では、Splunk ITSIはAIOpsプラットフォームであるなどの記述がありますが、個人的にこの表現は大げさだと思っています。Splunk ITSIは、システム監視や障害対応業務を強化するためのプラットフォームであり、また機械学習などの機能は使うことができます。
しかしながら、まだ一般の人がAIOpsと言われてイメージするほどのAIを駆使した運用機能は現状持ち合わせていないと思っています。
Splunk IT Service Intelligenceの用語
Splunk IT Service Intelligenceは、謎の用語が複数登場します。
中でも「サービス」「サービスヘルススコア(サービス健全性スコアとも表現される)」「KPI」「エンティティ」といった用語と、それぞれの用語の関連性は非常に重要であるため、簡単にまとめてみます。
(https://docs.splunk.com/Documentation/ITSI/4.19.1/SI/AboutSI より引用)
| 用語名 | 説明 |
|---|---|
| サービス | 監視対象となる機能やプロセス。ユーザーにとってわかりやすい機能やプロセスを指定する。サービスはトップレベルのサービスからブレークダウンされて分解される。例えば、ECサイトであればトップレベルのサービスを「ECサイト」などとして、トップレベルサービスを構成するサブサービスとして、「商品閲覧機能」「購入機能」「ログイン/ログアウト機能」などと分解していくことが考えられる。 |
| サービスヘルススコア(サービス健全性スコア) | サービスの健全性を示す指標。0-100までの値で示され、高いほど健全であることを示す。この値が一定値を下回るとサービスの色が変化し、異常であることが視覚的にわかる。 |
| KPI(Key Performance Indicator) | サービスヘルススコアを決める要素。例として、CPU、ディスク空き容量(または率)、エラー数(または率)などの指標が考えられる。Splunkのスケジュールドサーチによって定期的に集計される。これを元にして、KPI毎の重みを加算することでサービスヘルススコアが算出される。 |
| エンティティ | サービスやKPIを集計する際に分割するための要素。具体的には、複数のWebサーバーで構成されるWebサービスがあったとき、各サーバーごとにKPIを計算するため、ホスト名をエンティティとしてホスト名ごとにKPIを分離して計算するときなどに使用する。 |
いきなり複数の専門用語が登場するため、それなりにとっかかりにくさがある製品です。
しかし、サービスという人間中心の観点でシステムの健全性を評価するというのは、他に見られない面白い機能であり、これがSplunk ITSIの独自性だと考えています。
Splunk IT Service Intelligenceの主な機能
では、Splunk IT Service Intelligenceでできる具体的な機能について見てみます。
独断と偏見で、以下のマニュアルから参照できるいくつかの機能を紹介します。
Service Insights Manual
https://docs.splunk.com/Documentation/ITSI/4.19.1/SI/AboutSI
Event Analytics Manual
https://docs.splunk.com/Documentation/ITSI/4.19.1/EA/AboutEA
Service Analyzer
システムの健全性を、サービスとKPIと呼ばれるSplunkのサーチによって得られる値で表現することによって、ITにあまり詳しくない担当者であっても、障害発生時の影響範囲特定を迅速に行うことができる機能です。ツリービューとタイルビューという二種類のビューがあります。
サービスアナライザー：ツリービュー
(https://docs.splunk.com/Documentation/ITSI/4.19.1/SI/AboutSA より引用)
サービスアナライザー：タイルビュー
(https://docs.splunk.com/Documentation/ITSI/4.19.1/SI/AboutSA より引用)
Deep dives
サービスアナライザーやDeep Diveなどから数回のクリックによってこの機能に素早くアクセスすることができます。指定されたサービスのヘルススコアやKPIについて、簡単に時系列表示をすることができ、迅速にパフォーマンスの変化を追跡・分析することができます。
Glass tables
ユーザー自身が自由に設計・実装できるダッシュボードです。
サービス、KPIといった情報を、自由に追加できるアイコンなどと一緒に視覚的に表示できます。
システムの状態や関連を直感的に理解できるダッシュボードを作成することができます。
(注：事前定義されたものがあるというよりは、テンプレートやサンプルなどを使用して自分でダッシュボードを作成して使用するための機能があるというものです)
multi-KPI alerts
複数のKPIに基づくアラートを通知できる機能です。
複数のKPIに対してそれぞれの重みを設定し、それらの積算が一定値を超えた場合にアラートを通知させることができます。
Episode Review/Event aggregation
Splunk ITSIには関連するインシデントをエピソードと呼ばれるグループにまとめる機能があり、これをEvent Addregationと呼びます。
これによって、対応するインシデントを共通のエピソードにまとめることによって、対応しなければならない項目を絞り込み、ノイズに悩まされずインシデント対応を行うことができます。
Episode Reviewは、これらエピソードを一覧表示して調査することができる画面です。
Event Analytics dashboard
Splunk ITSIを使用して集約したインシデントやエピソード数を集計して表示したりするEvent Analytics Audit dashboardと、Splunk ITSI自身のヘルスチェックなどを行うことができるEvent Analytics Monitoring dashboardから構成されます。
どちらも、システムではなくSplunk ITSIそのものを分析するためのダッシュボードです。
Content Pack
一般的な製品(例えばAWS, Windows, Linux/Unix, VMware等)について、事前定義されたサービスやKPI、アラート集約ポリシーなどを含むパッケージです。
これを使用することで、全てのサービスやKPIなどをゼロから設計・実装せずに済むため、導入時の手間を削減することができます。
(https://docs.splunk.com/Documentation/ITSICP/current/Config/AboutMA )
Anomaly Detection/Adaptive Thresholds(異常検知/動的しきい値)
Splunk ITSIでは、比較的簡単な操作で異常検知(通常のふるまいかた逸脱した挙動を検知する機能)や、動的しきい値(時間によって動的にしきい値を変更してくれる機能)などの機械学習機能をSplunkに貯められたログに適用することができます。
ただし機械学習による検知ができると言っても、十分に前提条件や制限や仕組みを理解しないまま利用してしまうと、意味のある効果が得られない可能性があるので、安易に飛びついて利用を開始することはあまりおすすめできません。
ITSIを導入にすることによるメリットとデメリット
結論として、Splunk IT Service Intelligeceを導入することによるメリットには、以下のようなことが挙げられると思いました。
メリット
- システムの健全性をサービスや機能といった観点で表現することで、ITやシステムに詳しくない担当者でも、障害時に迅速に影響範囲を理解することができる
- 障害発生時は、Deep Dive等の機能を使うことにより、問題が発生しているサービスに対するKPIの時系列などを簡単に分析できる
- アラートを集約化することにより、アラートノイズを削減し、必要なアラートに収集して対応することができる
- 振る舞い検知や動的しきい値などの機能を比較的容易に実装できる(ただし適切に使いこなすためにはしっかりとした知識やチューニングは必要)
一方で、Splunk IT Service Intelligeceを利用するためには、デメリット・・・というか、十分に注意しなければならない点も存在します。例えば以下の点はしっかりと考慮する必要があります。
デメリット
- サービスアナライザーや、Glass Tableは、事前定義されているものではなく、ユーザーが監視したい対象のシステムに対して個別に設計し、実装する必要がある。このためにSplunkやSplunk ITSIに関する高い知識や経験が必要。一応、コンテンツパックと呼ばれる事前定義されたサービスの部品はあるが、多くの人は、導入の際にSplunkのデリバリーコンサルタントなどによる実装支援が必要と思われる
- ミッションクリティカルなシステム向けの監視製品として使用する場合、耐障害性についてしっかりと考慮する必要がある。例えば、Indexerは大企業でSplunkをそれなりに利用している場合またはSplunk Cloudを利用している場合は冗長化されるが、Search Headは必ずしも冗長化されていないことが多い。Search Head Clusterを構成するのはそれなりにコストも手間もかかるため、Splunk ITSIを導入したときにSearch Head自体に障害が発生した時の対応などは考慮が必要と思われる
最後に
Splunk IT Service Intelligeceは、システムの健全性をサービスという、人間にわかりやすい指標で表現するという観点で、ユニークな機能を持っている製品です。(私が物知らずなだけかもしれませんが、こういった発想で構成されているITシステムの監視製品を私は知りません)
一方で、サービスツリーを自分で設計・実装しなければならない、ミッションクリティカルなシステムの監視製品として使用するためにはSplunk自身の耐障害性について検討が必要、といった点に対して考慮するべきと思いました。