Azure

Azure Service Health とサービス別ステータス API の活用方法と自動監視

ⓘ本ページはプロモーションが含まれています

お得なお知らせ

スポンサードリンク
1ヶ月で資格+現場入り

インフラエンジニアへの最短ルート

未経験でもAWS・Linux・ネットワーク資格を最短で取り、現場入りまでサポート。SREやクラウドエンジニアの入口。

CODE×CODEスピード転職|無料面談▶ SRE/クラウドのフリーランス案件▶

▶ AWS/GCP/Kubernetesの独学には Kindle Unlimited の技術書読み放題がコスパ最強。


スポンサードリンク

概要と利用シーン

  • Azure Service Health(リソースヘルス): サブスクリプション/リージョン単位で Azure のインフラ障害やメンテナンス情報を取得できる管理 API。
  • サービス別ステータス API: 各 PaaS が提供する public なエンドポイント(例:Web PubSub、Azure Databricks)から、リアルタイムの稼働状態(Healthy / Degraded / Unhealthy)を JSON で取得できる。

これらを組み合わせれば CI/CD パイプラインLogic Apps自動監視スクリプト に埋め込み、デプロイ前や定期チェック時に「サービスが正常か」を機械的に判定できます。


公式エンドポイントと正しい API バージョン

サービス エンドポイント例(プレースホルダー) 推奨 api-version
Azure Service Health (ResourceHealth) https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.ResourceHealth/availabilityStatuses?api-version=2024-02-01 2024‑02‑01(執筆時点で最新)
Web PubSub (Data plane) https://{resource}.webpubsub.azure.com/api/health?api-version=2024-01-01 2024‑01‑01
Azure Databricks (ステータスページ) https://status.databricks.com/api/v2/status.json 認証不要・バージョン指定なし

※注意
Service Health の API バージョンは頻繁に更新されます。最新版は公式ドキュメントの “Versioning” ページ(Microsoft.ResourceHealth REST reference)で必ず確認してください。


認証方式のまとめ

3‑1. Azure AD トークン取得(PowerShell / Azure CLI)

ツール 主なコマンド例 補足
PowerShell (Az モジュール) Connect-AzAccount(Get-AzAccessToken -ResourceUrl "https://management.azure.com/").Token Get-AzAccessToken は Azure AD アプリケーションやマネージド ID でも使用可能。
Azure CLI az account get-access-token --resource https://management.azure.com/ --query accessToken -o tsv Azure Cloud Shell でもそのまま実行できます。

正しい PowerShell サンプル

ポイント
Get-AzAccessToken-Credential パラメータは不要です。代わりに Azure CLI と同様に -ResourceUrl を指定し、現在のコンテキストからトークンを取得します。

3‑2. マネージド ID の利用例

Azure CLI(System‑assigned Managed Identity)

PowerShell(Managed Identity 環境)

3‑3. Databricks ステータス API は 認証不要

Databricks が提供する https://status.databricks.com/api/v2/status.json はパブリックエンドポイントです。
- ヘッダーに Authorization を付与しない(付与しても無視されます)。
- 取得頻度は公式ドキュメントで「1 分間に最大 30 リクエスト」程度と記載されていますが、実際のレートリミットは緩やかです。


レートリミットと再試行ポリシー

API 公開されているレートリミット(執筆時点)
Service Health (ResourceHealth) 1 分間に最大 60 リクエスト公式ドキュメント
Web PubSub Data Plane 1 秒あたり 10 リクエスト程度(推奨上限はサービスごとに異なるため、Retry-After ヘッダーで確認)
Databricks ステータス API 明示的なリミットは無いが、過度の呼び出しは 429 (Too Many Requests) を返すことがあります

再試行ロジック(PowerShell / Python 共通)


実装サンプル

1. PowerShell(Invoke‑RestMethod)

2. Azure CLI(az rest

3. Python(requests

4. Databricks ステータス(認証不要)


レスポンス解析とエラーハンドリング

主な JSON フィールド(共通)

フィールド 意味
status string "Healthy" / "Degraded" / "Unhealthy"
title string 人間が読める要約メッセージ
details array (任意) 障害時の詳細情報
timestamp ISO8601 データ取得時刻

PowerShell 判定ロジック

Python 判定ロジック

タイムアウト・例外処理のベストプラクティス

言語 推奨タイムアウト 失敗時の対応
PowerShell (Invoke-RestMethod) -TimeoutSec 15 try / catchSystem.Net.WebException を捕捉し、リトライロジックへ流す
Azure CLI (az rest) デフォルトは 60 秒 → 必要に応じて --max-request-timeout オプションで調整 エラーコードを $? で判定
Python (requests) timeout=10(秒) requests.exceptions.Timeout をキャッチし、再試行またはアラート送信

Log Analytics への連携例

Data Collector API の構成

項目 内容
エンドポイント https://<workspace-id>.ods.opinsights.azure.com/api/logs?api-version=2016-04-01
認証方式 Shared Key(Primary または Secondary キー)
カスタムログタイプ 任意(例:AzureServiceHealth

PowerShell 実装

ポイント
Log-Type は英数字とアンダースコアのみ使用可。Kusto クエリで AzureServiceHealth_CL のように自動的にサフィックス _CL が付与されます。

Kusto 例:障害が発生したレコードだけ抽出


CI/CD パイプラインでの前提チェック実装例

GitHub Actions(Python スクリプト呼び出し)

Azure DevOps(AzureCLI@2 タスク)


ベストプラクティスとトラブルシューティング

項目 推奨設定・対策
API バージョン管理 スクリプト内に定数として ApiVersion を保持し、変更があれば CI で自動検出できるようテストを追加。
認証情報の安全な保管 サービスプリンシパルは Key Vault に格納し、az keyvault secret show で取得して使用する。マネージド ID が利用可能なら必ず採用。
レートリミット回避 1 分あたりの呼び出し上限を超えそうな場合は Azure Scheduler または Logic AppsRecurrence トリガーで間隔を調整する。
ロギング API 呼び出し前後に必ず requestIdx-ms-request-id)とステータスコードをログへ残す。障害解析が楽になる。
テスト自動化 pester(PowerShell)や pytest(Python)で「Healthy が返ってくること」をユニットテストに組み込み、PR 時に検証。
エラーメッセージの国際化 画面表示とログは英語ベースで統一し、日本語メッセージは別途ローカライズ用ファイルに切り出す。
タイムゾーン timestamp は常に UTC(ISO8601)になるので、レポートやダッシュボードでは必要に応じてローカル時刻へ変換する (DateTime.ToLocalTime())。

よくある失敗例と対処法

症状 原因 解決策
401 Unauthorized が返る アプリ登録に API 権限 が付与されていない、または同意が取れていない Azure Portal → App registration → API permissions で Azure Service Management (user_impersonation) を追加し、管理者に同意させる。
429 Too Many Requests が頻発 複数スクリプトが同時実行/レートリミット設定を無視している 共通の RateLimiter ライブラリ(例:Polly for .NET、tenacity for Python)で制御。
JSON の構造が変わったときにエラーになる サービス側でステータス API のレスポンス形式を更新した スキーマバリデーション (jqjsonschema) を追加し、変更検知時は CI で警告。
Log Analytics に送れない Shared Key が間違っているか、有効期限が切れている キーのローテーション手順を自動化(Key Vault のシークレット更新 → スクリプト再取得)。

参考リンク

内容 URL
Azure Resource Health REST API (最新版) https://learn.microsoft.com/en-us/rest/api/resourcehealth/
Web PubSub Data Plane API – health エンドポイント https://learn.microsoft.com/azure/azure-web-pubsub/howto-manage-service#check-service-health
Databricks Status API(認証不要) https://status.databricks.com/api/v2/status.json
Azure Monitor の Rate Limits https://learn.microsoft.com/azure/azure-monitor/limits
Log Analytics Data Collector API https://learn.microsoft.com/azure/monitor/logs/data-collector-api
PowerShell Az モジュール – Get-AzAccessToken https://learn.microsoft.com/powershell/module/az.accounts/get-azaccesstoken
Azure CLI – az rest https://learn.microsoft.com/cli/azure/rest?view=azure-cli-latest

まとめ

  1. 最新 API バージョン を必ず公式ドキュメントで確認し、スクリプトにハードコーディングしない。
  2. 認証は Azure AD トークンかマネージド ID を利用するが、Databricks のステータス API は例外的に認証不要。
  3. レートリミット(1 分 60 リクエスト)を意識し、Retry-After ヘッダーで再試行ロジックを実装。
  4. コードは一貫したインデント・引用符 を保ち、PowerShell の Get-AzAccessToken 使用例は正しく記述する。
  5. 取得結果は Log Analytics カスタムログ に送信し、Kusto クエリや Logic Apps と連携すればアラート自動化が完結。
  6. CI/CD 前提チェック を組み込むことで、障害中のデプロイ失敗リスクを大幅に低減できる。

上記手順とサンプルコードをベースに、貴社環境へ 「サービスステータス取得 → 監視 → アラート」 のフローを実装すれば、Azure 全体の可用性管理がシームレスになります。ぜひリポジトリにある scripts/ ディレクトリをクローンし、環境変数や Key Vault の設定だけで動作確認してみてください。


スポンサードリンク

お得なお知らせ

スポンサードリンク
1ヶ月で資格+現場入り

インフラエンジニアへの最短ルート

未経験でもAWS・Linux・ネットワーク資格を最短で取り、現場入りまでサポート。SREやクラウドエンジニアの入口。

CODE×CODEスピード転職|無料面談▶ SRE/クラウドのフリーランス案件▶

▶ AWS/GCP/Kubernetesの独学には Kindle Unlimited の技術書読み放題がコスパ最強。


-Azure