Microsoft AzureのデータをSplunkに取り込む

このブログに関心を持たれた方は、さまざまなMicrosoft AzureサービスのデータをSplunkにどうやって取り込んだらよいのかお悩みなのではないでしょうか。Azureサービスの数が増え続け、データへのアクセス方法もいろいろある中、どういったデータが提供され、そのデータをSplunkにどのように取り込めるのかを把握することは、雲を掴むことに挑もうとするような無謀な話に聞こえるかもしれません(「クラウド」にかけてみました)。

このブログでは、Azureデータはどのように提供されるのか、Azureデータにはどうやってアクセスするのかを説明し、初期設定のままですぐにAzureデータを収集できるSplunkアドオンについて紹介します。では、さっそく本題に入りましょう。

Azureデータはどのように提供されるのか

Azureデータは、主に次の3つの方法で提供されます。

ストレージアカウント

ストレージアカウントは、Azureが登場した当初、標準的だった方法です。基本的に、Microsoftはサービスのデータを別の場所にあるストレージ(ストレージアカウント)にダンプします。たとえば、仮想マシンのイベントログを入手したい場合、Azureは指定されたストレージアカウントにイベントログをダンプします。ストレージアカウントはVMとは別のサービスであるため、VMについてのデータはVMを削除したあとも残ります。ストレージアカウントは独自のしくみでセキュリティを確保し、データを保持しますが、ここでは深くは触れません。独立したストレージアカウントにデータをダンプして、そこからデータを取得するようにソースサービスを設定できる、ということだけ押さえておいてください。

Event Hubs

標準といえば、ほとんどのAzureサービスで新たな標準となったのがEvent Hubsです。Event Hubsとは、保持期間の比較的短い、拡張性に優れたメッセージバスであると言えるでしょう。Azureは、前述したストレージアカウントと同様の方法で、(Azure Monitorと呼ばれるサービスを使用して) Event Hubにデータをダンプできます。ただし、Event Hubにデータを収集するのは、他のサービスが取得するためであり、Event Hubsにイベントが保持される期間はさほど長くありません(通常は24時間から7日)。また、Event Hubsは、データの受信や配信の負荷に応じてスケールアップまたはスケールダウンできます。

ヒント：Pub/Sub、Kafka、プロデューサー、コンシューマーといった用語になじみがある場合は、概念は同じと考えて差し支えありません。なじみがないと言う方は、今の話は忘れていただき、もう少し詳しく知りたいと思われた場合は、これらの用語をWebで検索してみてください。

REST API

Azureデータの3つ目の提供方法は、REST APIです。数多くのREST APIがありますが、  Splunkを利用されている方は「リスト」処理を実行することが多いでしょう。  こちらのページには、Azure VMを操作するためのAPIがすべて掲載されていますので、お役立てください。Microsoft Azure Add-on for Splunk (あとでもう少し詳しく触れます)は、「すべてをリスト」処理を使用して、Azure内にあるすべてのVMのリストを取得します。  この情報は、Splunk IT Service Intelligence (ITSI)やSplunk Enterprise Securityでエンティティとして使用できるほか、Splunkの他のデータソースと相関付けることもできます。

入手できるデータの種類

Azureデータの3つの主な提供方法がわかったところで、入手できるデータの種類について簡単に触れておきましょう。 ここでは、すべてのデータソースを網羅したリストを提供することはできないので、Splunkでよく利用されるソースをいくつか挙げます。  

• アクティビティデータ ^{_{[REST]または[Event Hub]}}：基本的には、誰がいつ何をしたかというデータです。  たとえば、Azureポータルにログオンして、新しいVMを作成すると、このVMを作成した行為がアクティビティログに取り込まれます。
• リソースデータ ^_[REST]：このデータソースには、使用しているサービスが取り込まれます。  アクティビティデータが「起こったこと」ならば、リソースデータは「存在しているもの」です。  たとえば、仮想マシン、ストレージアカウント、パブリックIPアドレスなどは、いずれもリソースです。
• 認証データ ^{_{[REST]または[Event Hub]}}：こちらについては、ほとんど説明の必要がないでしょうが、多要素認証データ、セルフサービスパスワードリセットデータ、条件付きアクセスポリシーデータ、Azure Active Directoryの全データなどを取得できることを付け加えておきたいと思います。
• ネットワークセキュリティグループ(NSG)のフローログ ^{_{[ストレージアカウント]}}：このソースは、接続元および接続先IPアドレス、ポート、プロトコルなどを含むネットワークトレースのようなものです。このトピックについて詳しくは、こちらのブログ記事(英語)をご覧ください。
• WebアプリケーションおよびApplication Insights _{^{[ストレージアカウント]}}：Webアプリケーションデータには、Webサーバーのデータ(ホステッドまたは共有)とWebアプリケーションのデータが含まれます。Application Insightsは、アプリケーションパフォーマンス管理(APM)データです。
• コストおよび消費量 _^[REST]：このデータソースには、使用中のサービスと、その使用コストに関する詳しいデータが含まれます。また、VM予約に関する推奨事項が含まれることもあります。これはVMのコスト削減に役立ちます。
• アラート _{^{[REST]または[Event Hub]}}：サービスアラートとセキュリティアラートの両方を、アクティビティログの一環として取得できます。  サービスアラートは、リージョン内のサービスが低下した場合などに送信されます。たとえば、利用しているリージョン内でストレージサービスが何かの影響を受けた場合、サービスアラートと関連メッセージが生成されます。セキュリティアラートは、たとえばグローバル管理者が1人しかいないような場合にMicrosoftから送られてきます。
• メトリクス _^[REST]：Azureは大量のメトリクスを提供しています。  Microsoftが提供しているメトリクスの全リストについては、こちらをご覧ください。

SplunkからAzureのデータにアクセスする方法

Azureデータの提供方法と、入手できるデータの種類はわかりましたが、そのデータをどうやってSplunkに取り込むのでしょうか。一番簡単なのは、アドオンを利用する方法です。よく使用されているアドオンには、Splunk Add-on for Microsoft Cloud ServicesとMicrosoft Azure Add-on for Splunkの2つがあります。

ところで、データの種類についての説明箇所に_{^{[ストレージアカウント]}}、_{^{[Event Hub]}}、_^[REST]というタグが付いていることに気づかれたでしょうか。このタグは、使用するアドオンを判断するヒントとして活用できます。次をご覧ください。

Splunk Add-on for Microsoft Cloud Services

• アクティビティデータとアラート _{^{[REST] [Event Hub]}}
• 認証データ _{^{[Event Hub]}}
• NSGのフローログ _{^{[ストレージアカウント]}}
• WebアプリケーションおよびApplication Insights _{^{[ストレージアカウント]}}
   

Microsoft Azure Add-on for Splunk

• リソースデータ _^[REST]
• 認証データ _^[REST]
• コストおよび消費量 _^[REST]
• メトリクス _^[REST]
   

パターンがあるのに気づかれたでしょうか。Splunk Add-on for Microsoft Cloud Servicesは、Event Hubs、ストレージアカウント、アクティビティログと統合されます。Microsoft Azure Add-on for Splunkは、さまざまなREST APIと統合されます。  なお、Splunk Add-on for Microsoft Cloud Servicesは、REST APIまたはEvent Hubを介してアクティビティログを取得できます。  どちらの方法でも取得できるデータは同じです。

データの流れ(GDI)図

百聞は一見にしかずということで、ここまでの話を図にしたサンキーダイアグラムを掲載します。お役に立てば幸いです。

^{ヒント：画像をクリックするとインタラクティブな図が表示されます。}

あわせて「Microsoft AzureへのSplunk Enterpriseの導入」やMicrosoft Azure監視ソリューションページもご覧ください。

このブログはこちらの英語ブログの翻訳、庄司 大助によるレビューです。