Contents
1. Service Health と Resource Health の違い
| 項目 | Azure Service Health | Azure Resource Health |
|---|---|---|
| 対象範囲 | サブスクリプション全体のサービス（例: SQL Database、AKS）に関わるインシデントや計画メンテナンス | 個別リソース（VM、App Service、SQL DB など）の現在状態・障害履歴 |
| 主な通知内容 | 障害 / 計画メンテナンス / プラン変更 の概要と影響範囲 | 正常 / 警告 / 障害 とその 原因コード（例: PlatformUnavailable） |
| 表示場所 | Azure ポータル → Service Health | Azure ポータル → 任意リソースの Resource health タブ |
| 参照先 (Microsoft Learn) | https://learn.microsoft.com/ja-jp/azure/service-health/ | https://learn.microsoft.com/ja-jp/azure/resource-health/ |
要点：Service Health が「サービス全体」の可用性情報を提供し、Resource Health が「リソース単位」の詳細状態を示すため、両方を併用することで障害の全容把握が可能になります。
2. Azure Portal で Service Health アラートを作成する手順
2‑1. 前提条件
- Azure Monitor の閲覧権限（
Monitoring Reader）とアラート作成権限（Contributor以上）が必要です。 - アラートの送信先となる Action Group を事前に作成しておくとスムーズです。
2‑2. 手順（2024 年 UI）
| 手順 | 操作内容 |
|---|---|
| 1 | Azure ポータルにサインインし、左メニューから Monitor → Service Health を選択 |
| 2 | 上部タブの アラート → ＋ アラート ルールの作成 をクリック |
| 3 | スコープ に対象サブスクリプション（またはリソースグループ）を指定。Resource フィールドは空白で全サービス対象、必要に応じて絞り込み可 |
| 4 | 条件 → 「Service Health イベント」→「イベント種別」を選択 ・障害 (Critical/Warning) ・計画メンテナンス ・プラン変更 |
| 5 | フィルターで リージョン（例: Japan East、Japan West）や サービス名 を追加設定 |
| 6 | アクション に先ほど作成した Action Group を指定 |
| 7 | 詳細設定：名前・説明を入力し、必要なら 重要度 (Severity) のデフォルトを Warning 以上に変更 |
| 8 | 保存 → アラートルールが有効化されます |
ポイント
- 「重要度 ≥ Warning」かつ「リージョン = Japan*」でフィルタすると、国内向けインシデントのみを取得できノイズを削減できます。
- 条件は複数選択可能なので、障害と計画メンテナンスの両方を同一ルールで捕捉できます。
参考: https://learn.microsoft.com/ja-jp/azure/service-health/how-to-configure-service-notifications
3. Action Group（通知チャネル）の作成と設定例
3‑1. 作成手順
| 手順 | 操作内容 |
|---|---|
| 1 | Monitor → アラート → Action groups を開く |
| 2 | ＋ 作成 をクリックし、以下を入力 ・名前: Ops_All_Channels・短縮名: ops-all（メール件名に自動使用） |
| 3 | 受信者の追加 で必要なチャネルを選択 |
3‑2. 主な通知チャネルと設定ポイント
| チャネル | 設定例 | 留意点 |
|---|---|---|
| メール | admin@example.com（件名テンプレート: [ServiceHealth] {{AlertName}}） |
SPF/DKIM が正しく構成されていないと受信拒否になる可能性あり |
| SMS | 国コード付き電話番号（例: +81-90-1234-5678） |
1 通あたり最大 160 文字。Unicode を使用すると文字数が半減する点に注意 |
| プッシュ通知 | Azure モバイルアプリにデバイス登録 → 「プッシュ」選択 | アプリの通知設定がオフになっていないか確認 |
| WebHook | https://hooks.example.com/az-alert（署名付きトークン推奨） |
ペイロードは JSON でカスタマイズ可能。例: json {"alertId":"{{AlertId}}","severity":"{{Severity}}","title":"{{AlertName}}"} |
| Microsoft Teams | コネクタ URL（例: https://teams.microsoft.com/...）を貼り付け |
メッセージテンプレートは {alertName}、{severity} が展開される |
ベストプラクティス：重大障害は メール + SMS、情報共有系は Teams や WebHook（Opsgenie など） に流す構成が推奨されています。
参考: https://learn.microsoft.com/ja-jp/azure/monitoring-and-diagnostics/alerts-action-groups
4. アラートのテスト・トラブルシューティング
4‑1. 手動テスト手順
- Monitor → アラート → ルール一覧 で対象ルールを選択
- [テスト] ボタン → 「テストイベント生成」画面で「障害」を選び 発火
- 設定した Action Group に通知が届くか確認
4‑2. PowerShell/CLI を使った自動シミュレーション例
|
1 2 3 4 5 6 7 8 |
# Azure CLI の例 az monitor metrics alert create ` --name TestServiceHealth ` --resource-group RG-Prod ` --scopes /subscriptions/<subId>/providers/Microsoft.ResourceHealth/availabilityStatuses/default ` --condition "count ServiceHealthEvent > 0" ` --action group <actionGroupResourceId> |
4‑3. よくあるエラーと対処法
| エラー | 主な原因 | 対策 |
|---|---|---|
| メール配信失敗 | 受信側がブロックリストに掲載、SPF/DKIM 未設定 | DNS に正しい SPF レコードを追加し、DKIM を有効化 |
| SMS 文字化け | Unicode 文字使用 | ASCII のみで構成し、文字数 ≤ 160 に抑える |
| WebHook タイムアウト | エンドポイントの応答遅延（> 30 秒） | Azure Function 等でリトライロジックを実装 |
| 重複通知 | 複数 Action Group が同一チャネルに設定 | 重複する受信先を整理し、1 つのグループに統合 |
4‑4. ログと診断情報の確認方法
- アラート履歴ページで発火時刻・ステータス・失敗理由が表示されます。
- Monitor → 診断設定から Log Analytics ワークスペースへログを送信し、Kusto クエリで詳細分析可能です。
参考: https://learn.microsoft.com/ja-jp/azure/monitoring-and-diagnostics/alerts-log
5. 実運用でのおすすめ構成例
| 構成要素 | 推奨設定 |
|---|---|
| スコープ | 全サブスクリプション、リージョンは japan* 正規表現で絞り込み |
| 条件式 | Severity == 'Critical' || (Severity == 'Warning' && EventType == 'PlannedMaintenance') |
| 通知チャネル | 重大障害 → メール + SMS 計画メンテナンス → Teams チャンネル |
| アクショングループ | Ops_All_Channels（メール、SMS、Teams、WebHook） |
| テスト頻度 | 毎月第1営業日、PowerShell スクリプトでシミュレーション実行 |
この構成により、重大インシデントは即時に担当者へ届き、計画メンテナンスは情報共有だけに留めるというノイズ抑止と迅速対応のバランスが取れます。
6. まとめ
- Service Health と Resource Health は補完関係。前者でサービス全体、後者でリソース単位の健康状態を把握することがベストプラクティスです。
- アラートは Azure Monitor の Service Health から作成し、Action Group に複数チャネル（メール・SMS・Teams・WebHook）を組み合わせて通知経路を冗長化しましょう。
- 作成後は必ず手動テストまたは自動シミュレーションで動作確認し、失敗時は アラート履歴と Log Analytics で原因を特定します。
- 定期的なテストと設定見直しを行うことで、障害発生時の通知漏れや過剰通知（ノイズ）を防ぎ、運用効率を高められます。
参考リンク
1. Azure Service Health – https://learn.microsoft.com/ja-jp/azure/service-health/
2. Azure Resource Health – https://learn.microsoft.com/ja-jp/azure/resource-health/
3. アラートとアクショングループの作成 – https://learn.microsoft.com/ja-jp/azure/monitoring-and-diagnostics/alerts-action-groups
4. Service Health の通知設定 – https://learn.microsoft.com/ja-jp/azure/service-health/how-to-configure-service-notifications
本稿は実装例を示すことが目的です。環境や組織ポリシーに合わせて適宜カスタマイズしてください。