こちらは Microsoft Azure Tech Advent Calendar 2023 1日目 の記事です。
Azure Monitor Plivate Link Scope で、オンプレマシン からのログを閉域で Azure へ取る！
Azure 上のリソースは、各種テレメトリやログを Log Analytics ワークスペースへ一括して収集し、監視・分析をする構成が一般的です。
しかし、
- データの要件や、クラウドへ移行中といった事情から、オンプレミスマシンが存在するシステム
- 適材適所で、Azure や オンプレミス環境、他社クラウドサービスも併用しているというシステム
などなど、リソースが各所に分散しているシステムも多くあります。
Azure Arc を利用すれば、Azure のリソースに加えて、オンプレミスのマシンや他クラウドのリソースも Azure へ接続し、同じログ収集ルールで Azure へとログを収集し、監視するといった仕組みを構成できます。運用者も Azure Portal から一元的に監視することができるので、運用の効率化にもつながります。
さらに、Azure Monitor Plivate Link Scope を構成すれば、オンプレミス環境から Azure へログを収集する際に、インターネットを経由せずに、閉域網でログを収集することができます。
というわけで、今回は Azure Arc と Azure Monitor Private Link Scope を利用して、オンプレミスのマシンから Azure へログを収集する構成を構築してみます。公開ドキュメントでの参考手順はこちら[1]です。
Azure Arc と Azure Monitor Private Link Scope の構成
今回は上記のような構成を構築します。
ザっと構成を説明すると、以下のような構成になります。
- オンプレミス環境と Azure が ExpressRoute で接続されている
- オンプレミスマシンには Connected Machine Agent がインストールされ、Azure Arc Private Link Scope を利用して ExpressRoute で登録されている
- Azure Monitor Plivate Link Scope(AMPLS) が構成され、Azure Monitor リソース と プライベートエンドポイントが設定されている
- Azure Monitor リソース として、 Data Collection Endpoint (DCE) と Log Analytics Workspace (LA) が構成されている
- プライベートエンドポイントが構成されている
- Data Collection Rule (DCR) が構成され、Arc 登録した オンプレミスマシン に対して、収集対象のログと送付先が設定されている
- オンプレミスマシン から Arc および AMPLS に関連した DNS 名前解決ができるように、DNS サーバーが構成されている
なお本記事では 主に Azure Monitor Private Link Scope の構成について記載をしていきます。
そのため、オンプレミス環境と ExpressRoute で接続し、オンプレミスマシンを Azure Arc へ接続するところまでは、本記事では扱いません。
それぞれ以下の記事で説明しています。
Step 1. Azure Monitor Private Link Scope の構成
Step 1-1. Azure Monitor Private Link スコープを作成する
まずは、入れ物となる Azure Monitor Private Link Scope を作成しておきます。
Azure Monitor Private Link Scope は、Azure Monitor リソースとプライベートエンドポイントを関連付けるためのもの、とイメージすると良いかもしれません。
この段階では特に難しいものはなく、 Azure Portal から Azure Monitor Private Link Scope と検索し、リソースグループを指定して作成をするだけです。
ただし、現時点では クエリアクセスモード や インジェストアクセスモード は オープン としておきます。
Step 1-2. Data Collection Endpoint (DCE) を作成する
さて、続けて Azure Monitor Private Link Scope に関連付ける Azure Monitor リソースを作成していきます。まずは Data Collection Endpoint (DCE) を作成します。
なお、DCE というのは、以下の2つの役割を担っているリソースです。[4]:
- ① Data Collection Rule (DCR : どういったログを収集してどこへ送付するのか等を定義するもの) を Azure Monitor Agent に対し提供する役割
- ② DCR に従って Azure Monitor Agent が収集したログの送付先（＝ LogAnalyticsWorkspace のエンドポイント）となる役割
それでは、DCE を作成していきます。
Azure Portal から [データ収集エンドポイント] と検索します。
[+作成]を選択して作成画面を開き、好きなリソース名、リソースグループ、リージョンを指定し、作成をします。リージョンについては、先述の通りの制限がありますので、作成予定の Log Analytics Workspace と同じリージョンにしてください。
作成が完了しました。
リソースを確認しておくと、①構成アクセスエンドポイント と ②ログインジェストポイント 、双方に対応する記載があることがわかります。
Step 1-3. Log Analytics Workspace (LA) を作成する
Log Analytics ワークスペース も作成してしまいます。
Azure Portal から [Log Analytics ワークスペース] と検索し、[+作成] を選択します。
DCE と同じリージョンを選択して作成します。
Step 1-4. Azure Monitor Private Link に Azure Monitor リソースを追加
作成した データ収集エンドポイント と Log Analytics Workspace を Azure Monitor Private Link Scope に関連付けます。
Azure Portal から [Azure Monitor Private Link Scope] と検索し、作成済みの Azure Monitor Private Link Scope を開きます。
左側メニューの [Azure Monitor リソース] を選択し、[+追加] を選択します。
作成した データ収集エンドポイント] と [Log Analytics ワークスペース] を、[適用] を選択して追加してあげます。
これで関連付けできました。
Step 1-5. Private Endpoint と Private DNS Zone を追加
続けて、Private Endpoint を作成し、追加していきます。
Private DNS Zone もあわせて作成できますので、こちらも作成しておきます。
Azure Portal から [Azure Monitor Private Link Scope] と検索し、作成済みの Azure Monitor Private Link Scope を開きます。
左側メニューの [プライベートエンドポイント接続] を選択し、[+プライベートエンドポイント] を選択します。
プライベートエンドポイントのリソース名などを指定します。
続くリソースタブでは、
リソースの種類として Microsoft.Insights/privateLinkScopes を選択します。
リソースの種類を指定すると、リソースとして、作成済みの Azure Monitor Private Link Scope がプルダウンで選択できるようになります。
対象サブリソースは azuremonitor になります。
プライベートエンドポイントを配置する VNet とサブネットを指定します。
AMPLS をどこに配置するかですが、おおきく選択肢としては HubVNet に配置するか、SpokeVNet に配置するのか、という悩みになると思います。
基本的には HubVNet に配置するパターンが多いのではないかと思います ( この点は Step 2. でも少し扱います )が、今回は、Spoke に配置する構成を取ってみます。
続けて、Private DNS Zone を作成します。ゾーン統合する [はい] を選択し、5つの Private DNS Zone を作成します。Private DNS Zone のリソースを配置するリソースグループを指定し、作成します。
なお、作成される Private DNS Zone は以下の5つです。
privatelink.monitor.azure.comprivatelink.oms.opinsights.azure.comprivatelink.ods.opinsights.azure.comprivatelink.agentsvc.azure-automation.netprivatelink.blob.core.windows.net
Step 2. 名前解決の問題をケアする
さて、ここまでて、 Private DNS ゾーンが作成され、VNet と仮想ネットワークリンクで関連付けられているはずです。これでオンプレミスから名前解決して、AMPLS 関連の名前解決が正しく行われているでしょうか？
私は今回 Spoke VNet に対して Private Endpoint を作成したため、作成された Private DNS Zone も Spoke VNet にのみ関連付けられています。一方、オンプレミスの DNS サーバーがフォワーダーとして利用しているのは、Hub VNet に所属する DNS Proxy サーバーです。
DNS Proxy サーバーは、自身が所属する HubVNet とリンクされた Private DNS ゾーンは確認しますが、 AMPLS 関連のゾーンがリンクされていない場合には、Public に解決をしてしまいます。
そのため、しっかり Private DNS Zone を参照して AMPLS 関連の名前解決をしてもらうよう、Private DNS Zone と HubVNet との仮想ネットワークリンクを構成して、ケアをしておきます。
それでは仮想ネットワークリンクを構成していきます。なお作成された Private DNS Zone は5つあり、それぞれに仮想ネットワークリンクを構成する必要がありますので、以下手順を 5回 行うイメージです。
プライベート DNS ゾーンを開き、[仮想ネットワークリンク] を選択します。
[+追加]を選択して仮想ネットワークリンク作成画面を開きます。
仮想ネットワーク 欄にて DNS Proxy が所属している VNet を選択し、リンクを作成します。
なお、本記事では深くは扱いませんが、AMPLS に関しては ”名前解決をどう構成するべきか？” といったご相談がかなり多くあります。
名前解決をどう構成するべきかは様々なパターンがあり、メリット/デメリットがありますが、検討するにあたっては例えば以下の記事の議論などが非常に参考になるかとおもいますのでご紹介しておきます。[5][6]
Step 3. Data Collection Rule (DCR) を作成する
最後に Data Collection Rule (DCR) を作成していきます。
DCR は Azure モニター の画面から作成していきますので、まずは Azure Portal で [モニター] と検索するなどして Azure モニターの画面を開きます。
[設定] - [データ収集ルール] を選択し、[+作成] で作成画面へ進みます。
さて、DCR には、いくつか設定すべき項目がありますが、わかりにくいのは DCE との関係です。[7]:
- ①：どの監視対象リソースが、どこの DCE から取得するのか、を定義する設定
- ②：（カスタムログ / IISログ を送付する場合に）どこの DCE を介してログを送信するのか、を定義する設定
- ③：どういったログを収集し、どこの LogAnalytics へ収集するのか、を定義する設定
があります。
それでは、DCR を作成します。
まず設定するのは、②どこの DCE を介してログを送信するのか、を定義する設定 です。
ただし、ココで設定した DCE を介してログを送信するのは、カスタムログ / IISログ を送付する場合のみです。
たとえば Windows イベントログ を送付する場合には DCE を介することなく、PrivateEndpoint に対して直接送信されます。
DCR 作成時に、[基本] タブの下部で DCE を選択することで定義されます。
DCR を作成するリージョンを選択すると、選択可能な DCE がプルダウンで表示されますので、ここで選択します。
続く[リソース]タブでは、①どの監視対象リソースが、どこの DCE から取得するのか、を設定できます。
[+リソースの追加] を選択して、監視対象のリソースを選択します。Arc 登録したオンプレミスマシンを選択します。
また、「データ収集エンドポイントを有効にする」にチェックを入れ、Arc マシンが、どこの DCE から設定を取得するのか ① を設定します。
[収集と配信] タブで、[+データソースの追加] を選択して、収集対象のログを選択します。設定 ③ の部分です。
[データソース]タブで、いったん今回は、一通りの Windows イベントログ を収集するような感じで設定しました。
[ターゲット]タブにて、最終的にどこの LogAnalytics へこのログを格納するのかを選択します。
ここで選択できる LogAnalytics は、[基本]タブで選択した DCE と同一のリージョンに存在するものに限定されます。
Step4. オンプレミスマシンから Azure へログ送信を確認する
さて、これで構成が完了しました。
多少時間はかかりますが（10分程度といったイメージです）、上手くいっていれば、オンプレミスマシンから Azure へログが送信されているはずです。
Step 4-1. ログが送信されているか、確認する
Azure Portal より Log Analytics ワークスペース を開き、[ログ] を選択します。今回は、検証マシン１台のみですので、イベントログを一覧表示してみて、ログが送信されているかを確認してみました。もちろんオンプレミスマシン からの Hertbeat を確認するといった方法でも良いかと思います。
Event
しっかりとログが送信されていることが確認できました！
また、Azure Portal から、今回監視対象リソースとして指定したオンプレミスマシンの様子を確認してみます。
Azure Portal - [Arc] - [マシン] から、今回監視対象リソースとして指定したオンプレミスマシンを選択します。
左側メニュー [拡張機能] を開くと、Azure Arc の Connected Machine Agent が、DCR が構成されたことにより拡張機能が必要だと理解し、Azure Monitor Agent をオンプレマシンに対して導入し、実行してくれていることも確認できます。
実際、オンプレミスマシンにログインして確認してみると、Azure Monitor Agent 用のフォルダ存在しており、設定した DCR が格納されていることも確認できます。
Step 4-2. インターネット経由を遮断しても、ログが送付できているか、確認する
それでは仕上げとして、LogAnalytics ワークスペース と、AMPLS の設定を変更し、インターネット経由でのログ送信を遮断してみます。
LogAnalytics ワークスペース は、[設定] - [ネットワークの分離] を選択すると、設定を変更できます。
AMPLS は、[アクセスモード]から設定を変更できます。
これで遮断されているはずなので、再度時間を置いてみてログが継続して収集できているかを確認します。
なお、AMPLS のプライベートエンドポイントに疎通できない作業用端末などからは、以下のように、LogAnalytics ワークスペース へのアクセス自体ができないことが確認できます。
通信先がプライベートであることを確認しておく
最後に、オンプレミスマシン側でパケットキャプチャしてみて、どこへ通信しようとしているかを覗いてみました。
以下は、Azure Arc および AMPLS 関連の DNS クエリをパケットキャプチャしてみたものですが、認証(Entra ID)以外は宛先はプライベートなアドレスになっており、ExpressRoute 経由で Azure 側へ流れていることがわかりました。
通信の流れを図に起こしてみた
オンプレミスマシンを再起動してみて、発生した Azure Arc と AMPLS 関連の DNS クエリをパケットキャプチャしてみました。
大きく Azure Arc の Connectied Machine Agent が疎通を確立して認証のトークンを取得していく部分の流れと、その後、Azure Monitor Agent が認証トークンを利用しつつ、DCR を取得してログを送信する AMPLS 部分の流れという、2つのフローがあるように見えました。
パケットキャプチャしたものから Arc 関連の DNS クエリのみ抜粋
●Azure Arc Private Link Scope の処理
- ①システム割り当てマネージドID 証明書をプルするためリージョン エンドポイントを取得する
gbl.his.arc.azure.com: type CNAME, class IN, cname gbl.privatelink.his.arc.azure.com
gbl.privatelink.his.arc.azure.com: type A, class IN, addr 10.14.0.4
- ②システム割り当てマネージド ID 証明書をプルする
je.his.arc.azure.com: type CNAME, class IN, cname je.privatelink.his.arc.azure.com
je.privatelink.his.arc.azure.com: type A, class IN, addr 10.14.0.5
- ③Microsoft Entra ID
login.microsoftonline.com: type CNAME, class IN, cname login.mso.msidentity.com
グローバルIP に解決されている
パケットキャプチャしたものから AMPLS 関連の DNS クエリのみ抜粋
●AMPLS の処理
- ①システム割り当てマネージドID 証明書をプルするためリージョン エンドポイントを取得する
gbl.his.arc.azure.com: type CNAME, class IN, cname gbl.privatelink.his.arc.azure.com
gbl.privatelink.his.arc.azure.com: type A, class IN, addr 10.14.0.4
- ②AMPLSのグローバルな構成エンドポイント URL へ通信する
global.handler.control.monitor.azure.com: type CNAME, class IN, cname global.handler.control.privatelink.monitor.azure.com
global.handler.control.privatelink.monitor.azure.com: type A, class IN, addr 10.15.0.16
- ③AMPLSのリージョンの構成エンドポイント URLへ通信する
jpeast-endpoint-emru.japaneast-1.handler.control.monitor.azure.com: type CNAME, class IN, cname jpeast-endpoint-emru.japaneast-1.handler.control.privatelink.monitor.azure.com
jpeast-endpoint-emru.japaneast-1.handler.control.privatelink.monitor.azure.com: type A, class IN, addr 10.15.0.7
- ④LogAnalytics Workspcake に対応する AMPLS の Private Endpoint へログを送付
データ インジェスト エンドポイント URL
ad766fd2-b480-48d5-9a12-89f3c0ade7de.privatelink.ods.opinsights.azure.com: type A, class IN, addr 10.15.0.5
まとめ
今回は、Azure Arc と Azure Monitor Private Link Scope を利用し、オンプレミスのマシンから Azure へログを収集する構成を構築してみました。
Azure Monitor Private Link Scope は分かりにくい点がおおく、今回まとめてみて、私自身、理解が深まった気がします。
もしどこか誤りなどがあればご指摘いただいたり、ご質問いただけると幸いです！
参考
Discussion