コミュニティ検出アルゴリズムでITSIのエピソードをさらにスマートに

このブログ記事では、IT Service Intelligence (ITSI)の重要イベントのポリシーの作成方法について説明します。このポリシーを作成すると、Smart ITSI Insights App for Splunkの教師なし機械学習で生成したラベルを使ってイベントをグループ化できるようになります。決して専門的な内容ではないので、安心して続きをお読みください。 

グラフ分析でシステム間の接続を理解する方法についての過去のブログ記事をすでにお読みになった方や、3D Graph Network Topology Visualization App for Splunkを実際に使ってみたという方もいらっしゃるかもしれません。このAppでは、接続されたシステムに機械学習を適用する方法が多数用意されていますが、今回注目するのはラベル伝播法と呼ばれる技術です。

ラベル伝播法とは、システムのノード間の接続の強さを調べ、接続の類似度に基づいてノードを分類する手法です。皆さんも日々、この分析手法によって分類される側を体験しているはずです。たとえば、自分と似た人たちが関心を示したものに基づいてソーシャルメディアやオンラインストアのおすすめコンテンツが表示されるあの仕組みも、ラベル伝播法の類です。

ここでは、ラベル伝播法をサービスモデルITSIに適用してサービスをサブコンポーネントにグループ化し、そのサブコンポーネントラベルで重要イベントの集約ポリシーを強化する方法について見ていきます。このポリシーは、モニタリングツールによって生成されるノイズを低減し、データを扱いやすいグループに分類するためのものです。

コミュニティを検出する

はじめに、サービスモデルを使って分析対象のコミュニティを検出します。ここで紹介する分析機能はすべてSmart ITSI Insights App for Splunkの[ITSI Service Tree Analysis]ダッシュボードに含まれていますが、参考までにそこで使用されるサーチの詳細について説明します。

ITSIには、各サービス間の接続の強さを表すテーブルの作成に利用できるコマンドやルックアップが多数用意されています。グラフ分析の場合は、接続された2つのエンティティの情報が各レコードに含まれるようにデータを構造化する必要がありますが、より広い用途では、通常、接続の性質を説明するデータを追加します。たとえば、「person(人), phone(電話), owns(所有する)」というレコードは「人(エンティティ)が電話(エンティティ)を所有する(関係)」を意味します。

今回の目的では、サービスモデル内の接続をソースとターゲットで表現したテーブルが必要です。そこで、getserviceコマンドとKPI属性ルックアップを使用します。以下のサーチは、インスタンス内の各サービスについて、そのサービスが依存している全サービスを返します。

| getservice 

| table serviceid services_depending_on_me

| eval dest=mvindex(split(mvindex(split(services_depending_on_me,"~"),0),"="),1)

| rename serviceid as src

次に、このサーチ結果に、各サービスの依存先の全サービスを示すテーブルを付加します。最後の行は、依存関係が定義されていないレコードをすべて取り除くためのものです。

| getservice 

| table serviceid services_depending_on_me

| eval dest=mvindex(split(mvindex(split(services_depending_on_me,"~"),0),"="),1)

| rename serviceid as src

| append [| getservice 

| table serviceid services_depends_on

| mvexpand services_depends_on | eval src=mvindex(split(mvindex(split(services_depends_on,"~"),0),"="),1)

| rename serviceid as dest]

| table src dest

| where isnotnull(src) AND isnotnull(dest)

しかし、このサーチで得られるテーブルはKPIとサービスIDを羅列しただけのもので意味を読み解くのは容易ではないため、ルックアップ「itsi_kpi_attributes.csv」を使ってサービスとKPIに名前を付けてサーチ結果をエンリッチ化します。

| getservice 

| table serviceid services_depending_on_me

| eval dest=mvindex(split(mvindex(split(services_depending_on_me,"~"),0),"="),1)

| rename serviceid as src

| append [| getservice 

| table serviceid services_depends_on

| mvexpand services_depends_on | eval src=mvindex(split(mvindex(split(services_depends_on,"~"),0),"="),1)

| rename serviceid as dest]

| table src dest

| where isnotnull(src) AND isnotnull(dest)

| join src [| getservice | table title serviceid | rename title as src_name serviceid as src]

| join dest [| getservice | table title serviceid | rename title as dest_name serviceid as dest]

| table src_name dest_name 

| dedup src_name dest_name

これにより、以下のようなテーブルが得られます。

このテーブルを3D Graph Network Topology Visualization App for Splunkで可視化すると、最上部にShared IT Infrastructureがある以下のようなツリー構造が得られます。

ただ、この図ではデータ内のコミュニティについてはほとんどわかりません。コミュニティラベルを特定するにはもう少し分析が必要です。といっても、実行するサーチ自体はごく簡単なものです。 

最初のサーチに以下を追加すると、データにコミュニティラベルが付きます。

…

| fit GraphLabelPropagation src_name dest_name

|  eval color_src="#".upper(substr(md5(labeled_community),0,6))

| eval color_dest=color_src 

| table src_name dest_name color_src color_dest

これによって得られたノードをコミュニティラベルごとに色分けして可視化すると、以下のようなグラフが得られます。

サービスモデルの各ツリー内に存在するサブコミュニティが、先ほどよりもかなりはっきり見えてきました。 

アルゴリズムによって生成されるコミュニティラベルは数値ラベルのため、そのコミュニティが見つかったサービスツリーがどういうものかについてはほとんどわかりません。実務では、コミュニティラベルに説明的なテキストを付け加えることをおすすめします。この例であれば、コミュニティラベルに各ツリーの最上部のサービス名を追加するなどです(たとえば「1」から「Buttercup Stores Group 1」に変更)。こうしたコンテキスト情報を追加することで、重要イベントの集約ポリシーによって生成されるエピソードの意味が理解しやすくなります。実際、この方法はさまざまなお客様の環境でうまく機能しています。

コミュニティラベルを使ってエピソードを検出する

サービスツリー内のコミュニティを検出できたところで、続いてコミュニティラベルを使ってエピソードを生成する方法について見ていきます。これには2通りの方法があります。

1. Content Pack for Monitoring and Alertingの既存のフレームワークを使用する
2. コミュニティラベルを使って手動でエピソードを作成する

コンテンツパックのインストールの有無がAppによって自動的に判定されるので、それによってどちらの方法を使用できるかが変わってきます。

コンテンツパックを使用する方法

Content Pack for Monitoring and Alertingという優れたコンテンツパックには、ITSIインスタンスの価値を引き出すための便利なフレームワークが多数用意されています。ここでは、Appに同梱のルックアップ「itsi_kpi_attributes.csv」を使ってエピソードに自動的にコミュニティラベルを付加します。

このルックアップには、定義済みの重要イベント集約ポリシーにおいてエピソードを自動生成する際に使用されるalert_groupというフィールドがあります。ラベル伝播アルゴリズムの結果をもとにこのalert_groupフィールドの値をコミュニティラベルに置き換えると、即座にコミュニティラベルに基づいてエピソードが生成されるようになります。これは、Smart ITSI Insights App for Splunkの[ITSI Service Tree Analysis]ダッシュボードを開き、[Save Labels Using the Monitoring & Alerting Content Pack]ボタンをクリックすることで実行できます。ただし、この方法はContent Pack for Monitoring and Alertingがインストールされていないと使えないのでご注意ください。

手動で行う方法

ここからは、コミュニティラベルを手動で適用してエピソードを生成する方法について説明します。 

はじめに、ラベル伝播アルゴリズムの結果にoutputlookupコマンドを適用して、相関サーチのエンリッチ化に使用するCSVを作成します。これを行うには、[ITSI Service Tree Analysis]ダッシュボードの[save community labels]パネルでモデル名を入力し、[Save Community Labels into a Lookup]ボタンをクリックします。 

ここではルックアップの名前を「service_community_labels.csv」としました。以降の説明ではこのcsvを使います。

相関サーチをエンリッチ化する

作成したルックアップを使ってさっそく相関サーチをエンリッチ化していきます。参考までに相関サーチの例を以下に示しますが、これはデモ環境に対して行うサーチなので、本番環境のサーチはほとんどこのようにはならないと思います。

とはいえ、以下のサーチには要注目の要素もいくつかあります。それは、apply_entity_lookupマクロを使ってホストをエンティティにマッピングし、次にget_service_nameマクロでそのエンティティをサービスにマッピングしている点です。サービス名の取得後に、上の手順で作成したルックアップを使ってデータにコミュニティラベルを付加します。 

index=itsidemo sourcetype=nagios perfdata=SERVICEPERFDATA 

| rex field=reason "(?\d+\.?\d*)" 

| rex field=name "check_(?.+)"  

| eval norm_severity=case(severity=="CRITICAL",6,severity=="WARNING",4, severity="OK", 2) 

|  dedup consecutive=true src_host severity name 

| eval tmp_entity=host 

| eval host=src_host 

| `apply_entity_lookup(host)`

| eval host=tmp_entity 

| fields - tmp_entity 

| `get_service_name(serviceid,service_name)`

| lookup service_community_labels.csv src as service_name OUTPUTNEW labeled_community

これを相関サーチとして作成すると、以下のスクリーンショットのようになります。この場合は[Notable Event Identifier Fields]にもコミュニティラベルを追加します。

この相関サーチを有効化すると、インスタンスでコミュニティラベルを含む新しいアラートが生成されるようになります。重要イベントの集約ポリシーでコミュニティラベルを効果的に使用したい場合は、ITSIのすべての相関サーチにコミュニティラベルのルックアップを適用することをおすすめします。

コミュニティラベルを使ってエピソードを生成する

これでコミュニティラベル付きのアラートを生成する相関サーチを設定できたので、次はこのデータを使って集約ポリシーを作成します。

ポリシーの作成は簡単です。以下のように、まずコミュニティラベルを含む結果を探し、コミュニティ単位でフィルタリングして、エピソードにそのコミュニティの名前を付けます。イベント間の最小時間やエピソードの最大長などのパラメーターを追加で設定するのもおすすめです。

ポリシーを有効化すると、[Episode Review]ダッシュボードにそのポリシーによって生成されたエピソードが表示されるようになります。

エピソードにドリルダウンすると、問題のトリアージを開始するのに必要なコンテキストをすべて確認できます。

まとめ

このブログ記事では、ITSIサービスツリー内のさまざまなコミュニティを特定する方法と、そのコミュニティラベルを使ってアラートのエピソードを区別する方法をご紹介しました。コミュニティラベルは重要イベントの集約ポリシーでさまざまな活用が可能なことや、新たなKPIの生成に使用できることも、おわかりいただけたのではないでしょうか。ぜひ、ITSIのデータに機械学習を適用してみてください。

Splunkのメリットをどうぞお試しください。

このブログはこちらの英語ブログの翻訳、沼本 尚明によるレビューです。