本記事について
本記事ではオンプレ等のAzure外で稼働するサーバをAzureから管理するAzure Arc-enabled serversの仕組みを使って、Azure Monitorでサーバ監視をする方法をまとめます。
Azure Arc-enabled serversもAzure Monitorでの監視もシンプルなのでドキュメント通りに実装すればOKなのですが、一点引っかかったポイントがあったためそれを記録しておくものです。
- ポイント
Azure MonitorでArc-enabled serversのメトリック情報をAzure Monitor Metricストアに保存する場合は、メトリックエクスプローラーから見られないので注意しよう。
ついでに基本的な実装方法もおさらいしていますので、Azure MonitorやAzure Arcをご存じの方はArc-enabled serversをAzure Monitorで監視するまで飛んでいただければと思います。
前提機能のおさらい
Azure Monitorのおさらい（概要）
まずはAzure Monitorでのサーバ監視について基礎情報をおさらいしておきます。
Azure MonitorはAzureリソースやサーバにインストールしたAzure Monitor Agent等からログ、メトリックを収集し、可視化、分析するプラットフォームです。
メトリックとログ
Azure Monitorが収集するデータはメトリックとログに大別されます。
メトリックは時系列に沿って収集される数値情報、ログはイベントログやSyslog等自由に記載されるテキスト情報です。
MS Learn | Azure Monitor データプラットフォーム
Azure Monitorでメトリックとログを扱う上で抑えておきたいポイントとして、それぞれのデータの保存先と、それぞれを元に監視設定する際（アラートルール）の挙動の違いです。
また、メトリックはプラットフォームメトリックとカスタムメトリックの違いも抑えておくとよいでしょう。
プラットフォームメトリックとカスタムメトリック
プラットフォームメトリックはAzure基盤で既定で収集されるメトリックです。多くのAzureリソースで対応しています。
Azure VMの観点で言うとHyper-Vホストから見えるメトリック情報です。
一方、カスタムメトリックは現在プレビューな機能で、Azure Monitor AgentやAPIを通してAzure Monitor Metricストアに保存される情報です。
Azure Monitor Agentを通してデータ収集する方法は後述します。
MS Learn | Azure Monitor メトリックの概要
メトリックとログのデータ保存先
メトリックデータはAzure基盤に保存されます。そのため、ユーザーがLog Analyticsワークスペースやストレージを用意する必要はなく、保存に対して費用も発生しません。ただし、保存期間は93日間です。
データの閲覧は通常Azureポータルからメトリックエクスプローラーを介しておこないます。
また、カスタムメトリックは現在プレビューのため無料ですが、GA時にはデータインジェスト容量に応じて課金されるようです（Azure Monitorの価格ページ参照）。
一方でログデータはユーザーが用意したLog Analyticsワークスペースに保存されます。
保存期間はLog Analyticsワークスペースの設定に依存し、当然ログ量やインジェスト容量に応じて課金されます。
データの閲覧はKQLを利用しておこない、ブックを用いて可視化します。
少し紛らわしいのが、基本的には目的のデータがメトリックかログかは、データの種類に応じて決まるものですが、Azure Monitor Agentで取得したパフォーマンスカウンターの情報(例.CPU使用率)などは実はメトリック・ログどちらとして扱うこともできるという点です。
データとしては連続した数値情報なのでメトリック的な性質ですがログとして扱う方が適している場合はログとして扱います。
メトリックアラートとログ検索アラートの違い
そんなメトリックとして扱うかログとして扱うかの判断の一つにもなるのがアラート時の挙動の違いです。
監視の設定をおこなう際にもメトリックを対象とするかログを対象とするかで挙動が異なってきます。
メトリックアラートは時系列データの特定のポイントでの値を評価し、しきい値との上下関係でアラートの発火を判定します。
リアルタイム性が高く、アラートルールの費用は$0.1で固定です。
一方でログ検索アラートはアラートの評価頻度ごとに設定したKQLクエリを実行してその結果を評価します。
例えば直近5分間のHeartbeatのログがあるかどうかを評価するクエリを実行して、その結果行数が3行未満の場合（直近5分中3分間以上Heartbeatが届いていないタイミングがある）にアラートを発火するなどの設定ができます。
より複雑に複数のデータの状態を加味した監視条件も設定できるのが特徴です。
Log Analyticsワークスペースのログを検索した結果を評価する都合上、データがログ検索可能な状態で保存されるまで待つ必要があり、一般的にメトリックアラートよりリアルタイム性が落ちます。
また、ログ検索ルールはアラートの評価頻度が1分ごと、5分ごと、10分ごと、15分～ごとかで費用が変わってきます。
最後にわかりづらい概念ですがログのメトリックアラートというものもあります。
これはLog Analyticsワークスペースに保存されるログに対してメトリックアラートを設定できるものです。
サーバのパフォーマンスカウンターやHeartbeatなどの一部のデータの場合に利用できるもので、ログデータがLog Analyticsに送信された後でメトリックアラートで評価可能なようデータがフォークされ、それをアラートの評価に利用するようです。
何が嬉しいかというと、そのままログ検索アラートで検索するよりもリアルタイム性が高いことがあります。
ただし、設定はAzureポータルから簡単にできるものではなく、複雑化しますので詳細は以下を参照ください。
MS Learn | ログのメトリックアラート
このあたりのメトリックアラートとログ検索アラートの使い分けについてAzure VMの死活監視という観点で非常にわかりやすく解説してくださっているMicrosoftのサポートチームのBlogがあります。
非常に参考になるのでぜひ読んでおきましょう。
Japan Azure Monitoring Support Blog | Azure VMにおける死活監視の考え方
VM Insights機能
ここまでAzure Monitorの基本をおさらいしましたが、サーバのメトリックの収集・可視化を簡単に実装できる機能としてVM Insightsがあります。
これはAzure VMやArc-enabled serversに対して事前定義されたデータ収集ルールを実装してくれるもので、視覚化のための専用のワークブックも用意されています。
VM Insightsで収集したデータをもとにアラートルールを作成して監視を実装することももちろん可能です。
ただし、VM Insightsは非常に便利なものの、単に目的の監視項目だけを最小費用で実装しようと思うと不要なデータ収集がコストとしてかかってくるため環境によっては選択肢から外さざるを得ません。
また、Log Analyticsワークスペースにサーバのパフォーマンスカウンターの情報を保存する際のテーブルは手動でデータ収集ルールを設定した場合のPerfテーブルではなく、InsightsMetricsテーブルに保存されます (混ざらない) 。
Arc-enabled serversのおさらい
次にArc-enabled serversのおさらいです。
Arc-enabled serverはAzure外のサーバにエージェント (Connected Machine Agent) をインストールすることで、サーバをAzureに接続してAzureから管理するサービスです。
対応OSであればサーバがAzureにHTTPSでアウトバウンド通信さえできればどこで実行されていようとAzureに接続できます。
また、単にAzureに接続してサーバのインベントリ管理をおこなうだけであれば無料で利用できます。
無料で利用できる (接続した状態) だけでも以下の項目がAzureで閲覧できます。
また、Azure Resource Graphにも対応しているのでKQLで情報を取得・加工してワークブックに表示することもできます。
そして、Azure VM同様にAzureの管理サービスを利用できるのも大きな特徴です。
すべての機能が利用できるわけではありませんが、Azure MonitorやUpdate Manager、Defender for Servers等の多数の機能が現在対応しています。
対応している機能と価格体系は公式情報を参照ください (Azure VMと同様に課金されるもの、Arc-enabled serversゆえに追加課金があるものがあります) 。
Azure Arc の価格
Arc-enabled serversをAzure Monitorで監視する
さて、ここからが本題のArc-enabled serversをAzure Monitorで監視する際の話ですが、ここではサーバのパフォーマンスカウンターの情報 (CPU使用率やメモリ使用率) の監視に焦点を当ててみていきます。
パフォーマンスカウンター情報の収集方法の違い
Arc-enabled serversはAzure外で実行されるため当然プラットフォームメトリックには対応していません。
そのため、CPU使用率等を取得するにはAzure Monitor Agentを導入して、データ収集ルールの設定によりパフォーマンスカウンターの情報を収集します。
保存先は以下の2つから選択します (両方に保存も可) 。
この保存先によってAzure Monitorでメトリックとして扱うか、ログとして扱うかが決まります。
- Azure Monitor Metricストアにカスタムメトリックデータとして保存する
- Log Analyticsワークスペースにログデータとして保存する
Azure Monitor Metricストアは上述のカスタムメトリックにあたるものですので、現在はプレビューです。
どちらも一長一短ありますが、アラートルールのリアルタイム性の観点で見ると、メトリックアラートで検知できる前者が勝ると感じます。
加えて、Log Analyticsワークスペースを用意する必要もないので単にリアルタイム監視だけできればよい、分析のための情報収集や可視化は不要！という、オンプレZabbix監視の置き換えなどでは前者の方が必要最小限で済むケースもあります。
ということで、前者を使いたいというモチベーションでそれぞれを実装しながらメリット・デメリットを見ていきます。
なお、Arc-enabled serversもVM Insightsに対応しているため、深い分析・可視化が必要な場合はこちらを利用することを推奨します。
1. Azure Monitor Metricストアに収集する
収集の設定
データ収集ルールを作成し、[データソース]の[ターゲット]でAzure Monitor Metricsを選択します。
これによりAzure Monitor Metricストアにデータが送信されるようになります。
収集したデータを確認する
ここが一番のポイントになります。Arc-enabled serversのパフォーマンスカウンターの情報をAzure Monitor Metricストアに保存する場合、現時点ではメトリックエクスプローラーでデータを表示することができません。つまりAzureポータルでメトリックが閲覧できません。
Azure Monitorのデータ収集ルールのドキュメント内の注意書きに以下の記載があります。
MS Learn | Azure Monitor を使用して仮想マシンからパフォーマンスカウンターを収集する
現在、Microsoft.HybridCompute (Azure Arc 対応サーバー) リソースは メトリックス エクスプローラーで表示できませんが、メトリック データはメトリック REST API (メトリック名前空間 - リスト、メトリック定義 - リスト、メトリック - リスト) を使用して取得できます。
ではどうすればメトリックを確認できるかというと、Azure Monitor Metric用のREST APIを利用します。
専用のPowerShellやAzure CLIコマンドは無いようですのでネイティブなREST APIを実行する必要があります。
MS Learn | Azure Monitor REST APIのチュートリアル
このREST APIを使う際には以下を理解しておく必要があります。
- メトリック名前空間 (metricNamespaces)
- メトリック定義 (metricDefinitions)
REST APIでメトリックの値を取得する際には以下のエンドポイントにアクセスすることになるのですが、この際にメトリック名前空間とメトリック定義を指定します。
メトリック名前空間は以下のエンドポイントから取得でき、Linux OSのArc-enabled serversでは"Azure.VM.Linux.GuestMetrics"、Windows OSでは"Azure.VM.Windows.GuestMetrics"です。
# ${resourceId}はArc-enabled serversのリソースID
https://management.azure.com${resourceId}/providers/microsoft.insights/metricNamespaces?api-version=2023-10-01
メトリック定義はそのリソースがデータ収集ルールで取得しているメトリックとそのメトリックが対応しているデータの集計方法や集計頻度の定義です。以下のエンドポイントから取得できます。
# ${resourceId}はArc-enabled serversのリソースID
# ${metricNamespaceName}はメトリック名前空間
https://management.azure.com${resourceId}/providers/microsoft.insights/metricDefinitions?metricnamespace=${metricNamespaceName}&api-version=2023-10-01
そして、メトリックの値は以下のエンドポイントにアクセスすることで取得します。
フィルター等も設定することができます。
# 読みやすいようにクエリパラメータを改行して表示しています。
https://management.azure.com${resourceId}/providers/microsoft.insights/metrics
?api-version=2023-10-01 # APIバージョン (最新)
&metricnamespace=${metricNamespaceName} # メトリック名前空間
&metricnames=${metricName} # メトリック名
×pan=${startTime}/${endTime} # 取得するメトリックの時間
&interval=PT1M # メトリックの間隔 (PT1Mなら1分ごと)
# metricNameは以下のようにURLエンコードします。
$metricName = [System.Web.HttpUtility]::UrlEncode("mem/used")
# timespanのstartTime, endTimeの設定例 (直近1時間)
$startTime = (Get-Date).AddHours(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")
$endTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ")
実際にREST APIを利用するとこのような結果が得られます。
アラートを設定する
Arc-enabled serversをスコープとしてアラートルールを作成し、[シグナルの選択]画面でデータ収集ルールで取得してるメトリックが表示されるためそこから選択します。
なお、実はこの画面で選択したメトリック情報がプレビュー表示されるのでREST API以外でもこちらで限定的ではありますが収集したデータを確認できます。
2. Log Analyticsワークスペースに収集する
収集の設定
データ収集ルールを作成し、[データソース]の[ターゲット]でAzure Monitor Logsを選択して、任意のLog Analyticsワークスペースを指定します。
これにより指定したLog Analyticsワークスペースにデータが送信されるようになります。
収集したデータを確認する
こうすることでLog AnalyticsワークスペースのPerfテーブルにパフォーマンス情報が保存されます。
KQLを利用して以下のように値を取得できます。
アラートを設定する
Perfテーブルを利用してカスタムログ検索のログ検索アラートを設定します。
例えば、上で確認したメモリ使用量でアラートを設定するなら"Used Memory MBytes"や"% Used Memory"を対象にするとよいでしょう。
まとめ
Azure Arc-enabled serversのパフォーマンスカウンター情報を元にAzure Monitorでアラートを設定する方法を確認しました。
メトリックとして扱うかログとして扱うかが検討ポイントで、メトリックとして扱う場合は収集したデータの確認がAzureポータルからできない点に注意しましょう。
なお、コストに余裕があったり、単純な監視だけではなくポータルでの可視化も考える場合はVM Insightsを使ってデータ収集、可視化するのがおススメです。
その場合はログとしてLog Analyticsワークスペースにパフォーマンス情報が収集されますので、ログベースでアラートを設定することになります。