Contents
スポンサードリンク
1. Azure Status ページ ― 全体像と即時確認ポイント
| 項目 | 内容 |
|---|---|
| URL | https://status.azure.com/ |
| 提供情報 | サービス全体・リージョン別の稼働率、現在発生中の障害・メンテナンス情報、過去 30 日間のインシデント履歴 |
| 表示形式 | 「グローバル稼働率」カード（緑＝正常、黄＝警告、赤＝重大）と、サービスごとのカラータグ |
1‑1. グローバルビューの見方
- ページ上部にある「Azure 全体の稼働率」は、Microsoft の内部監視システム（Azure Monitor）とリアルタイムで同期しており、数秒以内に更新されます。
- カードをクリックすると サービス別カード が展開し、障害が発生中の項目は赤枠＋「障害中」のラベルが付与されます。
1‑2. リージョン別ステータス
- 左側メニューから対象リージョン（例：Japan East）を選択すると、その地域に限定したサービス状態がカード形式で表示されます。
- VM、SQL Database、App Service など主要リソースの稼働状況が一目で分かり、障害がある場合は赤枠と「障害中」ラベル が付くので見逃しにくい設計です。
実務上のヒント
- 自社アプリがデプロイされているリージョンだけをブックマークしておくと、障害発生時に即座に対象範囲を把握できます。
- カード右下の「過去 30 日間のインシデント」リンクで履歴を確認し、類似障害の再発リスクを評価しましょう。
2. Azure Service Health ― 個人・チーム向けダッシュボード構築
2‑1. 構成要素（3層モデル）
| 層 | 主な機能 |
|---|---|
| Service health | Azure 全体の障害、計画メンテナンス、緊急保守情報を取得 |
| Resource health | 個々のリソース（VM・AKS・SQL など）の現在状態と過去の障害履歴 |
| Personal health dashboard | サブスクリプション、リージョン、サービスを絞り込み、通知設定やアラートルールを個別管理 |
ポイント：全体把握 → 個別診断 → アラート配信というフローが自然に実装できるため、障害対応の手順がシンプルになります。
2‑2. ポータルでの設定手順（2024 年 UI）
- Service Health メニューへ遷移
-
Azure Portal の検索バーに「Service Health」と入力し、表示されたカードをクリック。
-
パーソナル ダッシュボード作成
-
画面右上の 「+ 新しいダッシュボード」 を選択 → 名前（例：
MyHealthDashboard）→ 「作成」。 -
対象リソースを追加
- 「リソースの追加」ボタンでサブスクリプション、リージョン、サービス種別をチェック。
-
左側ツリービューからドラッグ＆ドロップでカード配置が可能です（2024 年 UI でも同様に実装）。
-
通知設定（アラートルール）
- ダッシュボード上部の 「アラート」 タブ → 「+ 新しいアラートルール」 をクリック。
-
条件は「Service health の障害が発生したとき」や「Resource health が Unavailable になる」などから選択。
-
アクション グループの指定
-
Teams、メール、Webhook いずれか（または複数）を登録し、テスト送信 ボタンで実際に通知が届くか確認します。
-
保存・固定
- 設定完了後 「適用」 → 「ダッシュボードに固定」すれば、ポータルのホーム画面から常にアクセス可能です。
ベストプラクティス
- 重要度別（Sev0–Sev3）に応じたアクション グループを複数作成し、重大障害は Teams の緊急チャンネルへ、軽微な情報はメールだけというように通知先を分散させるとノイズが減ります。
3. CLI / PowerShell で可用性情報を取得する実装例
注意：本稿執筆時点（2024 年 4 月）で公式に提供されているコマンドは以下の通りです。将来的に名称が変更される可能性がありますので、常に最新ドキュメントをご確認ください。
3‑1. Azure CLI
(a) Resource Health の取得
|
1 2 3 4 5 6 7 8 |
# 特定リソース（例：VM）のヘルスステータスを JSON で取得 az resource show \ --resource-group MyRG \ --name myVM01 \ --resource-type "Microsoft.Compute/virtualMachines" \ --query "properties.healthStatus" \ -o json |
- ポイント：
healthStatusがAvailable、Unavailable、Unknownのいずれかで返ります。 - 活用例：取得結果を
jqで加工し、ステータスがUnavailableのときに Teams Webhook へ通知するシェルスクリプトを作成可能。
(b) Service Health アラートの一覧取得（Monitor API を利用）
|
1 2 3 4 5 6 |
az monitor activity-log list \ --resource-id "/subscriptions/<subId>/providers/microsoft.resourcehealth/availabilityStatuses/default" \ --offset 1d \ --query "[?operationName.value=='Microsoft.ResourceHealth/availabilityStatuses/read']" \ -o table |
- ポイント：Activity Log 経由で過去 24 時間のリソースヘルス変更履歴を取得でき、CI/CD パイプラインのテストステップに組み込みやすい。
3‑2. PowerShell（Az.Resources モジュール）
(a) Get‑AzResourceHealth
|
1 2 3 4 5 6 |
# Azure PowerShell にログイン済み前提 $resource = Get-AzResource -ResourceGroupName "MyRG" -Name "myVM01" Get-AzResourceHealth -ResourceId $resource.ResourceId | Select-Object ResourceId, HealthStatus, ReasonType | ConvertTo-Json -Depth 3 |
- ポイント：
HealthStatusがAvailable、Unavailable、Unknownの文字列で返り、ReasonTypeに障害理由が付与されます。
(b) Service Health アラートの自動作成（スクリプト例）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# 事前に Action Group が作成済みと仮定 $actionGroupId = "/subscriptions/<subId>/resourceGroups/rg-alerts/providers/microsoft.insights/actionGroups/ag-teams" New-AzMetricAlertRuleV2 -Name "ServiceHealthSev0" ` -ResourceGroupName "rg-monitor" ` -TargetResourceId "/providers/Microsoft.ResourceHealth/availabilityStatuses/default" ` -Condition (New-AzMetricAlertRuleV2Criteria -MetricNamespace "Microsoft.ResourceHealth" ` -MetricName "healthStatus" -Operator GreaterThanOrEqual -Threshold 1) ` -WindowSize (New-TimeSpan -Minutes 5) ` -Frequency (New-TimeSpan -Minutes 5) ` -Severity 0 ` -ActionGroupId $actionGroupId |
- ポイント：
MetricAlertRuleV2を利用すれば、Service Health の重大度（Sev0）に対して即座に Teams 通知が走ります。
実務での活用例
- CI/CD パイプライン：デプロイ前にaz resource show … --query healthStatusを実行し、Unavailableが返った場合はステージを失敗させる。
- 定期ジョブ（Azure Automation Runbook）：PowerShell スクリプトで全リソースのヘルスチェックを走査し、異常があれば Azure Logic Apps へ転送してインシデント管理ツールに自動登録。
4. Application Insights の可用性テストとアラート構築
| テスト種別 | 主な用途 |
|---|---|
| URL Ping | 単一エンドポイント（例：/health）の稼働確認。5 分ごとに複数ロケーションからリクエストし、ステータスコード 200 を期待値とします。 |
| 標準テスト（マルチステップ） | 複数 HTTP リクエストを順序付けて実行し、シナリオ全体の可用性・応答時間を測定。認証やデータ送信が必要な API に有効です。 |
4‑1. URL Ping テスト作成手順
- Application Insights リソースへ移動 → 左メニューの 「可用性」 を選択。
- 「+ 追加」 → 「URL ping テスト」 をクリック。
- 必要項目を入力：
- テスト名（例：
WebAppPing） - 対象 URL（例：
https://myapp.azurewebsites.net/health） - 頻度（5 分推奨）
- ロケーション（Japan East、Japan West、West US など最低 3 カ所）
- 期待ステータスコード：200
- 保存 → テストが即座に実行され、結果は「可用性」タブの一覧で確認可能。
4‑2. 標準テスト（マルチステップ）の設定
- 同様に 「+ 追加」 → 「標準テスト」 を選択。
- ウィザードで 「マルチステップ」 を有効化し、以下のようにシナリオを構築：
- ステップ 1：GET
/（ホームページ） → 期待コード 200 - ステップ 2：POST
/api/auth/login（認証 API）→ カスタムヘッダーContent-Type: application/json、期待コード 200 - 必要に応じて タイムアウト、リトライ回数 を設定。
- 設定完了後はテスト結果がグラフ化され、SLA（例：99.9%）が自動算出されます。
4‑3. 可用性アラートの作成
- テスト一覧から対象テストを選び 「規則 (アラート) を作成」 をクリック。
- 条件例：
availabilityResult < 0.99（可用率が 99% 未満） → アラート発火。 - アクション グループに Teams コネクタ、メール受信者を登録し、シリアル化オプションで同一障害の重複通知を抑制。
実務的ヒント：テスト失敗時は自動で Azure Function や Logic Apps を呼び出す「Webhook」アクションを追加すると、インシデント管理ツール（例：ServiceNow）へのチケット作成が即座に行えます。
5. 障害時の自動通知フローとベストプラクティス
5‑1. フロー全体像
|
1 2 3 4 5 6 7 |
Azure Status / Service Health ──► Azure Monitor アラート (Sev0/Sev1) │ │ ▼ ▼ Application Insights 可用性テスト ──► Azure Monitor アラート │ │ └───────► Teams/メール/Webhook へ通知 |
- ステップ 1：公式ステータスページや Service Health が障害情報を取得。
- ステップ 2：Azure Monitor のアラートルールが発火し、対象の Action Group（Teams・メール）へ配信。
- ステップ 3：Application Insights の可用性テストでも失敗が検知されれば同一 Action Group に追加通知。
5‑2. アクション グループ設定例（JSON）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
{ "location": "global", "properties": { "groupShortName": "TeamOps", "enabled": true, "emailReceivers": [ { "name": "ops-email", "emailAddress": "ops@example.com" } ], "itsmReceivers": [], "azureAppPushReceivers": [], "smsReceivers": [], "voiceReceivers": [], "logicAppReceivers": [], "automationRunbookReceivers": [], "eventHubReceivers": [], "webhookReceivers": [ { "name": "teams-webhook", "serviceUri": "https://outlook.office.com/webhook/..." } ], "armRoleReceivers": [] } } |
- ポイント：
webhookReceivers.serviceUriに Teams の Incoming Webhook URL を設定すれば、障害情報がそのまま Teams チャンネルへ投稿されます。
5‑3. 重複除外とノイズ低減のコツ
| 設定項目 | 推奨値 |
|---|---|
| 通知頻度 | 「1 回/障害」＋「再発時は 30 分ごと（上限 4 回）」 |
| シリアル化ウィンドウ | 10 分程度に設定し、同一インシデントの連続アラートをまとめる |
| Severity フィルタ | Sev0/Sev1 のみ Teams に送信、Sev2‑Sev3 はメールだけに限定 |
5‑4. テストと検証
- アクション グループ作成後は必ず 「テスト送信」 ボタンで Teams とメールの双方に届くか確認。
- 本番導入前にステージング環境で 障害シナリオ（例：VM を停止） を再現し、全てのフローが期待通りに動作することを検証してください。
6. まとめ（最終要点）
- Azure Status ページは全サービス・リージョンのリアルタイム稼働率を一目で把握できる第一情報源。異常色が出たら即座に Service Health へ遷移。
- Service Health の3層モデル（Service health / Resource health / Personal dashboard）を活用し、組織全体から個別リソースまで可視化・通知設定を最適化する。
- CLI/PowerShellで取得できる
az resource show … --query healthStatusとGet-AzResourceHealthはスクリプト化が容易。CI/CD パイプラインや Azure Automation Runbook に組み込んで自動ヘルスチェックを実装。 - Application Insights の可用性テスト（URL Ping・標準テスト）により、外部からのエンドポイント監視と SLA 計測が可能。失敗時は Azure Monitor アラートへ連携。
- 自動通知フローは Service Health と Application Insights のアラートを同一 Action Group に集約し、Teams・メール・Webhook で即座に関係者へ情報提供。重複除外やシリアル化設定でノイズも抑制できる。
これらの手順とベストプラクティスを組織全体で標準化すれば、Azure 環境の可用性監視が リアルタイムかつ自動化 され、障害対応のリードタイムは大幅に短縮します。
参考リンク（2024 年時点）
| 内容 | URL |
|---|---|
| Azure Status（公式） | https://status.azure.com/ |
| Service Health ドキュメント | https://learn.microsoft.com/ja-jp/azure/service-health/ |
| Azure CLI – Monitor metrics | https://learn.microsoft.com/cli/azure/monitor/metrics?view=azure-cli-latest |
| PowerShell – Get‑AzResourceHealth | https://learn.microsoft.com/powershell/module/az.resources/get-azresourcehealth |
| Application Insights 可用性テスト | https://learn.microsoft.com/ja-jp/azure/azure-monitor/app/availability |
| Azure Monitor アラートの作成 | https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/ |
次のステップ
- 本ガイドに沿って Service Health のパーソナルダッシュボード を構築し、テストアラートで通知設定を検証。
- 既存 CI/CD パイプラインに CLI/PowerShell スクリプトを追加し、デプロイ前のヘルスチェックを自動化。
以上、Azure の可用性監視と自動化に役立つ実践的情報でした。ご質問や具体的な実装例が必要な場合は遠慮なくお問い合わせください。
スポンサードリンク