Azure Service Health の概要と活用方法｜ポータル・API・自動監視

Contents

1 1. Azure Service Health とは
2 2. 前提条件と有効化手順
3 3. ポータルから Service Health を確認する手順
4 4. Service Health の通知設定手順
- 4.1 4‑1. Azure Monitor アラートの作成（推奨）
- 4.2 4‑2. Logic Apps / Event Grid による高度なフロー
5 5. REST API の概要と正しい API バージョン
- 5.1 5‑1. 認証フロー（Azure AD）
6 6. サンプルコード（PowerShell / Azure CLI / Python）
7 7. 自動通知の実装例
- 7.1 7‑1. Logic Apps の簡易フロー
8 8. ポータル vs API の比較とベストプラクティス
- 8.1 推奨ワークフロー
9 9. エラーハンドリングとレート制限対策
10 10. まとめ

スポンサードリンク

1. Azure Service Health とは

項目	内容
対象	サブスクリプション全体、個別リソース、リージョン単位の障害・計画メンテナンス・ヘルスアドバイザリ
提供元	Azure Resource Health（Resource Provider: `Microsoft.ResourceHealth`）
主な利点	・インシデント情報をリアルタイムで取得・障害の影響範囲が自動抽出できる・Azure Monitor と連携したアラートやダッシュボード化が可能

2. 前提条件と有効化手順

Resource Provider の登録
bash az provider register --namespace Microsoft.ResourceHealth
（未登録の場合は「サービスの状態」メニュー自体が表示されません）
Service Health プランの有効化（Azure Monitor の一部として標準で利用可能ですが、組織によってはプライベートリンクやネットワーク制限が設定されている場合があります。必要に応じて Azure Policy で Microsoft.ResourceHealth/availabilityStatuses/read 権限を付与してください）
アラートの作成権限
ロール: Monitoring Contributor またはカスタムロールで Microsoft.Insights/alertRules/* の書き込み権限が必要です。

3. ポータルから Service Health を確認する手順

手順	操作内容
1	Azure Portal にサインインし、左側メニューの「Service Health」（※リソースプロバイダーが有効なら表示）をクリック
2	「概要」タブで現在発生中の障害・計画メンテナンスがカード形式で確認できる
3	「イベント」タブ → フィルターアイコンからサブスクリプション / サービス / リージョン / 期間を設定
4	必要に応じて「カスタムビュー」を保存し、ダッシュボードへピン留め。チーム全体で共有可能

ポイント
- フィルターは UI 上だけでなく URL クエリとしても取得できるので、ブックマークしておくと便利です。
- CSV エクスポート機能は過去 90 日までサポートしています。

4. Service Health の通知設定手順

4‑1. Azure Monitor アラートの作成（推奨）

Azure Portal → Monitor → アラート を開く
「+ 新しいアラートルール」→ 対象リソース にサブスクリプションまたは個別リソースを選択
条件の追加で 「Service Health のイベント」（Microsoft.ResourceHealth/availabilityStatuses）を選択
アクショングループに メール / Teams / Webhook など通知先を設定し、アラート名・説明を入力して作成

4‑2. Logic Apps / Event Grid による高度なフロー

フロー	主な構成要素
Logic Apps	- トリガ: 「Service Health イベントが発生したとき」 - アクション例: Teams メッセージ、メール送信、ServiceNow チケット作成
Event Grid	- Event Subscription で `Microsoft.ResourceHealth/availabilityStatuses` を購読 - 宛先は Azure Function / Storage Queue / Webhook など任意

必ず確認すべき点
- 通知対象に 「重大度」（Severe, Critical）を絞り込むことで、ノイズ削減が可能です。
- アラートの 抑制期間（例: 5 分）を設定し、同一障害での重複通知を防ぎます。

5. REST API の概要と正しい API バージョン

エンドポイント	HTTP メソッド	現行安定版 API バージョン（2024年4月時点）
サブスクリプション全体の可用性ステータス取得	`GET`	`2023-07-01`
特定リージョン・サービスのイベント一覧	`GET`	`2023-07-01`
Resource Graph 経由でリソース単位のヘルス情報取得	`POST`	`2021-03-01`（Resource Graph 固有）

注記
- 以前の記事に記載された "2024-10-01" は現時点では公開されていないバージョンです。最新版は公式ドキュメント（Azure Resource Health REST API reference）で随時確認してください。

5‑1. 認証フロー（Azure AD）

手順	コマンド例
アプリ登録	Azure Portal → Azure AD → アプリの登録 → `ServiceHealthMonitor` 作成
API 権限付与	「Azure Service Management (user_impersonation)」を追加し、管理者に同意
クライアントシークレット作成	有効期限は 1 年以上推奨。Key Vault に格納して運用
トークン取得（CLI）	`az account get-access-token --resource https://management.azure.com/ -o tsv`
PowerShell の場合	`$token = (Get-AzAccessToken).Token`

ベストプラクティス
- シークレットは決してコードにハードコーディングしない。Key Vault から取得するロジックを必ず入れること。
- トークンの有効期限は 1 時間なので、長時間走らせるバッチでは自動リフレッシュ機構を実装。

6. サンプルコード（PowerShell / Azure CLI / Python）

6‑1. PowerShell

# 前提: Connect-AzAccount が完了していること
$subscriptionId = "&lt;YOUR_SUBSCRIPTION_ID&gt;"
$token = (Get-AzAccessToken).Token

$uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.ResourceHealth/availabilityStatuses?api-version=2023-07-01"

$response = Invoke-RestMethod -Uri $uri `
    -Headers @{ Authorization = "Bearer $token" } `
    -Method GET

# 障害があるリソースだけ抽出
$issues = $response.value | Where-Object { $_.properties.availabilityState -ne 'Available' }

if ($issues) {
    Write-Host "&#x26a0;&#xfe0f; 現在の障害:"
    $issues | ForEach-Object {
        "$($_.name) - $($_.properties.title) (開始: $($_.properties.occurredTime))"
    }
}
else {
    Write-Host "&#x2705; 全リソースは正常です。"
}

# 前提: Connect-AzAccount が完了していること

$subscriptionId = "<YOUR_SUBSCRIPTION_ID>"

$token = (Get-AzAccessToken).Token

$uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.ResourceHealth/availabilityStatuses?api-version=2023-07-01"

$response = Invoke-RestMethod -Uri $uri `

-Headers @{ Authorization = "Bearer $token" } `

-Method GET

# 障害があるリソースだけ抽出

$issues = $response.value | Where-Object { $_.properties.availabilityState -ne 'Available' }

if ($issues) {

Write-Host "⚠️ 現在の障害:"

$issues | ForEach-Object {

"$($_.name) - $($_.properties.title) (開始: $($_.properties.occurredTime))"

}

else {

Write-Host "✅ 全リソースは正常です。"

}

6‑2. Azure CLI + `jq`

SUBSCRIPTION_ID=xxxxxxxxxxxx

TOKEN=$(az account get-access-token \
        --resource https://management.azure.com/ \
        -o tsv)

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.ResourceHealth/availabilityStatuses?api-version=2023-07-01" |
jq '.value[] | select(.properties.availabilityState!="Available") |
    "\(.name) - \(.properties.title) (開始: \(.properties.occurredTime))"'

SUBSCRIPTION_ID=xxxxxxxxxxxx

TOKEN=$(az account get-access-token \

--resource https://management.azure.com/ \

-o tsv)

curl -s -H "Authorization: Bearer $TOKEN" \

"https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.ResourceHealth/availabilityStatuses?api-version=2023-07-01" |

jq '.value[] | select(.properties.availabilityState!="Available") |

"\(.name) - \(.properties.title) (開始: \(.properties.occurredTime))"'

6‑3. Python

import os, requests, json
from azure.identity import ClientSecretCredential

# 環境変数から取得（Key Vault に保存したものをロードしても可）
tenant_id   = os.getenv("AZURE_TENANT_ID")
client_id   = os.getenv("AZURE_CLIENT_ID")
client_secret = os.getenv("AZURE_CLIENT_SECRET")
subscription_id = os.getenv("AZURE_SUBSCRIPTION_ID")

credential = ClientSecretCredential(tenant_id, client_id, client_secret)
access_token = credential.get_token("https://management.azure.com/.default").token

endpoint = f"https://management.azure.com/subscriptions/{subscription_id}/providers/Microsoft.ResourceHealth/availabilityStatuses"
params   = {"api-version": "2023-07-01"}
headers  = {"Authorization": f"Bearer {access_token}"}

resp = requests.get(endpoint, headers=headers, params=params)
data = resp.json()

issues = [i for i in data["value"] if i["properties"]["availabilityState"] != "Available"]
if issues:
    print("&#x26a0;&#xfe0f; 現在の障害:")
    for i in issues:
        print(f"{i['name']} - {i['properties']['title']} (開始: {i['properties']['occurredTime']})")
else:
    print("&#x2705; 全リソースは正常です。")

import os, requests, json

from azure.identity import ClientSecretCredential

# 環境変数から取得（Key Vault に保存したものをロードしても可）

tenant_id = os.getenv("AZURE_TENANT_ID")

client_id = os.getenv("AZURE_CLIENT_ID")

client_secret = os.getenv("AZURE_CLIENT_SECRET")

subscription_id = os.getenv("AZURE_SUBSCRIPTION_ID")

credential = ClientSecretCredential(tenant_id, client_id, client_secret)

access_token = credential.get_token("https://management.azure.com/.default").token

endpoint = f"https://management.azure.com/subscriptions/{subscription_id}/providers/Microsoft.ResourceHealth/availabilityStatuses"

params = {"api-version": "2023-07-01"}

headers = {"Authorization": f"Bearer {access_token}"}

resp = requests.get(endpoint, headers=headers, params=params)

data = resp.json()

issues = [i for i in data["value"] if i["properties"]["availabilityState"] != "Available"]

if issues:

print("⚠️ 現在の障害:")

for i in issues:

print(f"{i['name']} - {i['properties']['title']} (開始: {i['properties']['occurredTime']})")

else:

print("✅ 全リソースは正常です。")

7. 自動通知の実装例

方法	設計イメージ	主なメリット
Webhook + Azure Function	Service Health API → PowerShell/CLI で取得 → HTTP POST → Function が Teams に転送	軽量、カスタムロジックが自由に書ける
Logic Apps	「Service Health アラート」→「Parse JSON」→条件分岐→Teams / メール	コード不要、ビジュアルでフロー管理
Event Grid → Azure Function	Event Grid が `Microsoft.ResourceHealth/availabilityStatuses` を購読 → 関数が障害情報を加工・保存	大規模かつマルチサブスクリプション環境に最適

7‑1. Logic Apps の簡易フロー

トリガ：When a resource health event occurs（Event Grid 経由）
条件分岐：availabilityState != 'Available'
アクション：Post a message to Microsoft Teams (Channel)
完了：Response 200 OK

8. ポータル vs API の比較とベストプラクティス

項目	Azure Portal	Service Health REST API
取得速度	UI 更新は数分遅延することがある	トークン取得後、秒単位で最新データ取得可能
カスタマイズ性	GUI のフィルタのみ	クエリパラメータ・Resource Graph で柔軟に条件指定
自動化	手作業向き（手順の保存はできるがスクリプト不可）	スクリプト/CI/CD パイプラインへ組み込み可能
通知チャネル	ポータル内メール設定のみ	Webhook、Logic Apps、Event Grid、Azure Monitor アラートなど多彩
レートリミット	無制限（ユーザー操作）	1 分間に最大 1200 リクエスト／サブスクリプション（※超過時は 429）

推奨ワークフロー

ポータルで全体概要を日次チェック（経営層向けレポート作成用）。
API と Azure Monitor アラートで自動化：5 分以上の取得間隔に抑えることで、Service Health の更新頻度とリクエスト数を最適化。
通知は Logic Apps / Event Grid に集約し、Teams・メール・インシデント管理ツールへ同時配信。
ログは Log Analytics に流し、Kusto クエリで月次レポート（例: ResourceHealth | where availabilityState != "Available"）を作成。

9. エラーハンドリングとレート制限対策

HTTP ステータス	主な原因	推奨対処
401	トークン期限切れ、権限不足	再取得＋シークレット更新、ロール `Monitoring Reader` 以上を付与
403	API 権限未許可（user_impersonation が欠如）	Azure AD の「API 権限」→`Azure Service Management (user_impersonation)` に同意
404	サブスクリプション ID 誤り、対象リソース未存在	URL を再確認、必要なら `az account set --subscription <id>` でコンテキスト切替
429	レートリミット超過	エクスポネントバックオフ（2,4,8 秒）＋リトライロジック実装
500/503	Azure 側障害	数分待機後再試行、ステータスページで全体障害の有無確認

実装例（PowerShell）
powershell $maxRetry = 5; $delay = 2 for ($i=0;$i -lt $maxRetry;$i++) { try { return Invoke-RestMethod … } catch [System.Net.WebException] { if ($_.Response.StatusCode -eq 429) { Start-Sleep -Seconds $delay; $delay *= 2 } else { throw } } }

10. まとめ

Azure Service Health は障害・メンテナンス情報の中枢。ポータルでの可視化と API による自動取得を組み合わせれば、運用効率が大幅に向上します。
必須前提は Microsoft.ResourceHealth のプロバイダー登録と、適切な Azure AD 権限・アラート権限です。
API バージョンは 2023‑07‑01 が最新安定版（公式ドキュメントで随時確認）。過去記事にあった 2024‑10‑01 は誤情報ですので使用しないでください。
通知設定は Azure Monitor アラート、Logic Apps、Event Grid のいずれかを選択し、チームが利用しているコラボレーションツール（Teams・Slack 等）へ即時配信させます。
レートリミットやエラーコードへの対策、シークレットは Key Vault に保管するというベストプラクティスを守ることで、安定した監視基盤が構築できます。

これらの手順とベストプラクティスに沿って設定すれば、Azure 環境の 障害可視化 → インシデント対応 → 改善サイクル が自動化され、ビジネス継続性（BCP）を強固にすることができます。