• 戻る（Azureの監視と管理）

• SIEM（Azure Sentinel など）に入れるアラート
• 重大な状態を事前に通知
• 可能であれば修正のためのアクションを実行

• メトリック
• ログ

補足（最新化 / シグナルの種類）: 現在のアラートは、
シグナル（入力）の種類でルールの型が分かれている。

型	入力	特徴
メトリック アラート	Metrics	安価・低遅延（1 分粒度）。まずこれを検討する
ログ アラート	Logs（KQL）	柔軟だが、クエリ実行に応じた課金と評価間隔の遅延がある
アクティビティ ログ アラート	アクティビティ ログ	「誰が何を操作したか」に反応（サービス正常性も含む）
スマート検出	Application Insights	異常を自動検出（現在は Workbook/アラート ルールへ移行中）
プロメテウス アラート	Managed Prometheus	AKS 等のコンテナ監視向け

• アクション

  • E-Mail
  • SMS
  • RunBooks
  • WebHook
  • , etc.

• ビュー

  • カスタム

• アラートの状態

  • アラート・ターゲット

    • Log Analytics の Workspace
    • ...

  • アラートの条件

    • 検索クエリ
    • アラート・ロジック
    • 評価基準

• アラートの詳細

  • アラートの名前
  • アラートの説明
  • アラートの重要度

• アクション・グループ
  アウトプット > アクション

補足（アクション グループの再利用）: アクション グループは
アラート ルールとは独立したリソースであり、複数のルールから共有できる。
「本番の重大障害は電話 ＋ ITSM 起票、検証環境はメールのみ」といった
通知ポリシーをアクション グループ側に閉じ込めておくと、
ルールを増やしても通知設計が破綻しない。

なお、アラートの重要度は Sev 0（重大）〜 Sev 4（詳細） の 5 段階。
「全部 Sev 0」にすると運用が麻痺するため、
呼び出す（Sev 0-1）／翌営業日に見る（Sev 2-3）／記録のみ（Sev 4）
のように、行動と対応させて割り当てる。

• アラート状態の定義
• アクション・グループの定義
• アラート詳細の定義

補足（アラート処理ルール）: 現在は **アラート処理ルール
（Alert Processing Rules、旧アクション ルール）**があり、
「計画メンテナンス中はこのリソース グループのアラートを抑止する」
といった制御をルール本体とは別に定義できる。
メンテナンス時に個々のアラート ルールを無効化して
戻し忘れるという事故の予防になる。

補足: 「緊急事態用アカウント（break glass アカウント）」は、
条件付きアクセスや MFA の設定ミスで全管理者が締め出される事態に備えた
例外アカウントである。
常時は使わないため、使われたこと自体がインシデントであり、
サインインを検知して通知する設定が必須になる、という趣旨。

• Azure Monitor のアラートの概要
  https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/alerts-overview

---

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, Azure