Azure SDK documentation update: Generate .NET SDK for Microsoft.Insights metric alerts 2024-03-01-preview versionで最初に確認すべきことは、「Azure Monitorのメトリックアラートを.NETから操作するコードに影響するか」です。結論として、Azure Portalだけでアラートを管理している場合は急いで対応する必要はありません。一方、C#や.NETのAzure SDKでメトリックアラートの作成、更新、一覧取得、ステータス確認を自動化しているチームは、プレビュー版パッケージの扱い、APIバージョン、identity、customProperties、actionProperties、PromQL関連の設定を確認しておくべきです。
今回の更新は、Azure SDKそのものを使う開発者だけでなく、Bicep、ARMテンプレート、Terraform AzAPI、CI/CDでAzure Monitorのアラート定義を管理している運用担当者にも関係します。特に本番環境で監視アラートをコード化している場合、「SDKが生成された」ことを単なるドキュメント更新として見ず、アラート通知・復旧判定・マネージドID・ペイロード設計まで見直すきっかけにしてください。
Azure SDKの今回の更新で押さえるべき結論
今回の対象は、Azure MonitorのMicrosoft.Insights/metricAlertsを.NET SDKから扱うための更新です。GitHubの対象PRは「Generate .NET SDK for Microsoft.Insights metric alerts 2024-03-01-preview version」という内容で、PRページ上ではDraftとして表示されています。つまり、公開済みドキュメントやプレビュー版パッケージを確認しつつも、本番移行は慎重に判断する必要があります。(GitHub)
Azure SDKの公式リリース一覧では、Resource Management – MonitorとしてAzure.ResourceManager.Monitorが掲載され、安定版1.3.1とプレビュー版1.4.0-beta.4が確認できます。(Azure) NuGetでもAzure.ResourceManager.Monitor 1.4.0-beta.4はプレリリース版として扱われており、インストールコマンドはdotnet add package Azure.ResourceManager.Monitor --version 1.4.0-beta.4です。([NuGet][3])
今回の変更を一言でまとめると、次のようになります。
| 確認項目 | 内容 |
|---|---|
| 対象サービス | Azure Monitor / Microsoft.Insights metric alerts |
| 対象SDK | Azure SDK for .NET / Azure.ResourceManager.Monitor |
| 対象APIバージョン | 2024-03-01-preview |
| 影響が大きい人 | .NETでメトリックアラートを作成・更新・取得している開発者 |
| すぐに避けたい対応 | プレビュー版を本番へ無検証で導入すること |
| まず行うべき対応 | 既存コード、IaC、通知設定、CI/CDの依存バージョン確認 |
何が変わったのか
今回のAzure SDK documentation updateで重要なのは、Microsoft.Insights/metricAlertsの2024-03-01-preview APIに対応した.NET側のリソース操作が明確になっている点です。
Microsoft Learnの.NET APIリファレンスでは、MetricAlertResourceがAzure.ResourceManager.Monitor名前空間に属し、Azure.ResourceManager.Monitor.dllに含まれるクラスとして掲載されています。対象パッケージには安定版v1.3.1とプレビュー版v1.4.0-beta.4が示され、プレビュー情報はリリース前に変更される可能性があると明記されています。(Microsoft Learn)
また、MetricAlertCollection.CreateOrUpdateAsyncは、メトリックアラート定義を作成または更新するメソッドとして記載され、既定APIバージョンが2024-03-01-previewになっています。(Microsoft Learn) さらに、サブスクリプション単位でメトリックアラート定義を取得するGetMetricAlertsでも、既定APIバージョンとして2024-03-01-previewが使われます。(Microsoft Learn)
つまり、これまでREST APIやBicepで扱っていたMicrosoft.Insights/metricAlerts@2024-03-01-previewの構造が、.NET SDKのモデルやメソッドとして使いやすくなった、と捉えると分かりやすいです。
2024-03-01-previewで特に確認したいプロパティ
Microsoft.Insights/metricAlertsのAPI変更ログでは、2024-03-01-previewでidentity、actionProperties、customProperties、PromQL関連のcriteria、QueryFailingPeriods、ResolveConfigurationなどが追加または更新されたことが示されています。(Microsoft Learn)
これらは、単にSDKの型が増えたという話ではありません。実務では、通知の内容、アラートの自動解決、PromQLベースの条件、マネージドIDを使う構成に影響する可能性があります。
| プロパティ・機能 | 確認すべきポイント | 実務での注意点 |
|---|---|---|
identity | メトリックアラートにマネージドIDを使うか | 権限不足で通知や連携処理が失敗しないか確認する |
actionProperties | アクション側に渡す追加情報があるか | WebhookやAction Group連携のペイロード差分を確認する |
customProperties | アラートペイロードに独自情報を載せるか | 通知先システムが新しい項目を正しく処理できるか確認する |
PromQLCriteria | PromQLベースの条件を使うか | Azure Monitor managed service for Prometheusやワークスペース設計と合わせて検証する |
ResolveConfiguration | アラートの解決方法を制御するか | 自動復旧・解決通知のタイミングが運用ルールと合っているか確認する |
targetResourceType / targetResourceRegion | 複数リソースやサブスクリプション単位で使うか | 指定漏れで作成・更新に失敗しないようにする |
MetricAlertDataのプロパティ一覧でも、ActionProperties、CustomProperties、Identity、ResolveConfiguration、TargetResourceRegion、TargetResourceTypeなどが確認できます。TargetResourceRegionとTargetResourceTypeは、スコープにサブスクリプション、リソースグループ、または複数リソースが含まれる場合に重要です。(Microsoft Learn)
対応が必要な人、様子見でよい人
今回のAzure SDK更新は、すべてのAzure利用者に即時対応を求めるものではありません。影響範囲を切り分けると、対応の優先順位を決めやすくなります。
| 利用状況 | 対応優先度 | 理由 |
|---|---|---|
| .NET SDKでメトリックアラートを作成・更新している | 高 | SDKモデルや既定APIバージョンの影響を受けやすい |
| C#の運用ツールでアラート一覧やステータスを取得している | 高 | MetricAlertResourceやGetMetricAlertsの動作確認が必要 |
BicepやARMテンプレートで2024-03-01-previewを使っている | 中 | SDK移行時にプロパティ差分を確認する必要がある |
| Terraform AzAPIでmetricAlertsを管理している | 中 | REST API構造との整合性確認が必要 |
| Azure Portalだけでアラートを設定している | 低 | 直接のSDK影響は小さい |
安定版Azure.ResourceManager.Monitor 1.3.1だけを使っている | 低〜中 | すぐに変更不要だが、将来の移行準備は必要 |
特に注意したいのは、「プレビュー版があるからすぐ更新する」という判断です。1.4.0-beta.4はNuGet上でプレリリース版として扱われています。([NuGet][3]) 本番環境では、安定版との違い、依存パッケージ、CI/CDの復元結果、既存テストの通過状況を確認してから採用してください。
移行前に確認すべき設定
パッケージバージョンを固定する
まず、プロジェクトがどのバージョンのAzure.ResourceManager.Monitorを参照しているか確認します。
dotnet list package | grep Azure.ResourceManager.MonitorWindowsのコマンドプロンプトでは次のように確認できます。
dotnet list package | findstr Azure.ResourceManager.Monitorプレビュー版を検証環境に入れる場合は、バージョンを明示します。
dotnet add package Azure.ResourceManager.Monitor --version 1.4.0-beta.4本番プロジェクトでは、次のような曖昧な指定を避けてください。
<PackageReference Include="Azure.ResourceManager.Monitor" Version="1.*" />プレビュー版や将来の版を意図せず取り込むと、ビルドは通ってもSDKモデルや生成コードの差分で実行時の挙動が変わることがあります。特に社内ツール、バッチ、監視設定の自動生成処理では、バージョン固定が基本です。
APIバージョンの差分を確認する
既存のIaCやREST呼び出しで2018-03-01を使っている場合、単純に2024-03-01-previewへ置き換えるのは避けてください。変更ログでは、2024-03-01-previewで追加されたプロパティが複数あります。(Microsoft Learn)
確認すべき検索キーワードは次の通りです。
grep -R "Microsoft.Insights/metricAlerts" -n .
grep -R "api-version=2018-03-01" -n .
grep -R "MetricAlertResource\|MetricAlertData\|GetMetricAlerts" -n .Windows環境なら、PowerShellで次のように検索できます。
Select-String -Path .\* -Pattern "Microsoft.Insights/metricAlerts","MetricAlertResource","MetricAlertData","GetMetricAlerts" -Recurse特に、古いAPIバージョンで作成したメトリックアラートを新しいSDKで更新する場合、既存定義を読み取り、同じ内容を再送しても差分が発生しないか検証してください。
criteriaの型を確認する
MetricAlertData.Criteriaは、単一の固定形式ではなく、シナリオに応じた派生クラスを割り当てる構造です。Microsoft Learnでは、利用可能な派生クラスとしてMetricAlertMultipleResourceMultipleMetricCriteria、PromQLCriteria、MetricAlertSingleResourceMultipleMetricCriteria、WebtestLocationAvailabilityCriteriaが示されています。(Microsoft Learn)
そのため、移行時は「アラート条件が何であるか」を先に分類してください。
| アラート条件 | 確認する観点 |
|---|---|
| 単一リソースのメトリック条件 | メトリック名、名前空間、集計方法、しきい値 |
| 複数リソースのメトリック条件 | targetResourceTypeとtargetResourceRegionの指定 |
| PromQL条件 | クエリ、静的・動的条件、解決設定 |
| Webテスト可用性条件 | 既存のWebテストリソースとの対応 |
PromQLを使う場合はさらに注意が必要です。PromQLCriteriaはAzure.ResourceManager.Monitor.Models名前空間のクラスで、Azure.ResourceManager.Monitor v1.4.0-beta.4に含まれるプレビュー情報として掲載されています。(Microsoft Learn) 本番の監視運用に入れる前に、クエリ結果、発火条件、解決条件、通知ペイロードを検証環境で確認してください。
通知ペイロードとWebhook連携を確認する
actionPropertiesやcustomPropertiesは便利ですが、通知先のシステムに影響しやすい項目です。
たとえば、Webhookでチケット管理システムやインシデント管理ツールへ連携している場合、次のような失敗が起きやすくなります。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| Webhook受信側でJSON解析に失敗する | 予期しないプロパティが追加された | 受信側で未知のプロパティを無視できるようにする |
| アラートの重要度が誤って分類される | severityの値と社内ルールがずれている | 0〜4の重大度を社内優先度にマッピングする |
| 復旧通知が想定より遅い・早い | autoMitigateやresolveConfigurationの理解不足 | 発火と解決の両方でテストする |
| 複数リソースのアラート作成に失敗する | targetResourceTypeやtargetResourceRegion不足 | スコープの種類ごとに必須項目を確認する |
REST APIのCreate Or Updateでも、properties.criteria、enabled、evaluationFrequency、scopes、severityが要求本文の主要項目として示され、identity、actionProperties、customProperties、resolveConfigurationなども扱われます。(Microsoft Learn)
実務での確認手順
本番環境へ影響を出さないため、次の順番で確認するのがおすすめです。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 現在のSDKバージョンを確認 | 安定版かプレビュー版かを把握する |
| 2 | 既存のmetricAlerts定義を棚卸し | Portal、Bicep、ARM、Terraform、C#コードの管理元を分ける |
| 3 | APIバージョンを確認 | 2018-03-01と2024-03-01-previewが混在していないか見る |
| 4 | 検証環境でSDK更新 | 1.4.0-beta.4を使う場合は本番とは別環境で試す |
| 5 | 作成・更新・一覧取得をテスト | CreateOrUpdateAsync、GetMetricAlerts、ステータス取得を確認する |
| 6 | 通知先までテスト | Action Group、Webhook、メール、チケット連携まで確認する |
| 7 | ロールバック方法を決める | パッケージを元のバージョンへ戻せるようにする |
この流れで重要なのは、アラート定義の作成だけでテストを終わらせないことです。監視設定は「作成できる」だけでは不十分です。実際に条件を満たしたときに発火し、正しい通知先へ届き、復旧時に期待通り解決されるところまで確認してください。
CI/CDで見落としやすいポイント
メトリックアラートをCI/CDで管理している場合、SDK更新はアプリケーションコードだけでなく、デプロイパイプラインにも影響します。
特に次の点は見落とされがちです。
| 確認対象 | 見落としやすい問題 |
|---|---|
Directory.Packages.props | 中央パッケージ管理で意図せず全プロジェクトに反映される |
| lockファイル | ローカルとCIで復元されるバージョンが違う |
| IaCテンプレート | Bicep/ARM側のAPIバージョンとSDK側のモデルがずれる |
| 権限 | マネージドIDやサービスプリンシパルに必要な権限が不足する |
| テスト | アラート定義の作成は通るが、通知や解決条件を検証していない |
監視設定の更新は、障害対応の入口を変える作業です。通常のSDK更新よりも、変更後の「通知が本当に届くか」を重視してください。
本番適用前のチェックリスト
本番適用前には、次の項目を確認してください。
Azure.ResourceManager.Monitorのバージョンを明示的に固定している- プレビュー版を使う理由が明確になっている
Microsoft.Insights/metricAlertsのAPIバージョンを把握している- 既存アラートのJSONまたはIaC定義をバックアップしている
criteriaの種類を把握している- 複数リソース対象の場合、
targetResourceTypeとtargetResourceRegionを確認している - Action Group、Webhook、メール通知の動作確認が済んでいる
customPropertiesやactionPropertiesを通知先が処理できる- PromQLを使う場合、発火条件と解決条件を実データで検証している
- ロールバック時に戻すパッケージバージョンと手順が決まっている
今回の更新をどう活用すべきか
Azure SDK documentation update: Generate .NET SDK for Microsoft.Insights metric alerts 2024-03-01-preview versionは、Azure Monitorのメトリックアラートを.NETでより扱いやすくする更新です。ただし、2024-03-01-previewという名前の通り、プレビューAPIに関連する要素が含まれます。
まずは既存環境でAzure.ResourceManager.Monitorを使っているかを確認してください。使っていない場合でも、Bicep、ARMテンプレート、Terraform AzAPIでMicrosoft.Insights/metricAlertsを管理しているなら、将来的に.NET SDKへ移行する可能性を見据えてプロパティ差分を把握しておく価値があります。
すぐにやるべきことは、パッケージ更新ではなく棚卸しです。どのアラートが、どのAPIバージョンで、どのツールから管理され、どの通知先へ接続されているかを整理してください。そのうえで検証環境にAzure.ResourceManager.Monitor 1.4.0-beta.4を入れ、作成・更新・一覧取得・通知・解決まで一通り確認するのが安全な進め方です。
[3]: https://www.nuget.org/packages/Azure.ResourceManager.Monitor/1.4.0-beta.4 “
NuGet Gallery
| Azure.ResourceManager.Monitor 1.4.0-beta.4
“
コメント