はじめに
私は最近こういった相談を受けることが多いです。
「Azureを使ってるんだけど、月に何万件もアラートがでて管理が大変です。どうにかなりませんか。」
相談を受けていて、世の中の人達がなぜこんなにもAzureMonitorに苦しめられているのかを思い知りました。その中で、同じ悩みを持つ外部のエンジニアの助けになればと思い、私の経験談も踏まえて分析と解決案の提示をしていきます。
1. Azure Monitor とは
そもそもAzureMonitorってどんな機能があるのか皆さん説明できますか。
Azure Monitor は Microsoft Azure のネイティブ監視ツールで、以下のような機能を提供します
- メトリクス監視：CPU、メモリ、ディスク I/O、ネットワーク等のパフォーマンス指標
- ログ分析：Azure リソースやアプリケーションのログを Log Analytics ワークスペースに集約
- アラート：条件に基づいてアラートルール（Alert Rules）を定義し、メール・Slack・PagerDuty 等に通知
- Application Insights：アプリケーション層の監視（パフォーマンス・トレース・依存関係）
- ダッシュボード・ブック：リアルタイムデータ可視化
とまぁ、見てわかる通り、Azure Monitor自体は包括的にAzure環境の監視ができる監視基盤でAzureの管理には必須のサービスです。
しかし、クラウドの運用経験が浅いエンジニアにとっては、AzureMonitorで何をどう監視すればいいか不明確です。そして、とりあえず重要そうなアラートを詰め込んだら、月に4万件もアラートが！？なんてことになります。
では、そうなってしまうと何が起こるのか考えてみましょう。
2. 膨大なアラートの放置がもたらす悪影響
何も考えずにアラートを作り続けたり、アラートを長期間放置しておくと様々な弊害が出てきます。ここではその代表的な2つを紹介します。
2.1 コスト増大化
Azure MonitorのアラートではAlert Rules の数やAction Group の呼び出し、Log Analytics Ingestion に従量課金が発生します。気づかぬうちに月間数万円のコスト増加があることもあります。
また、古いアラートが残っていることでその請求が続いていることも珍しくありません。定期的にアラートの棚卸をして、必要なアラートだけ残すようにすることはアラート管理の基本です。
2.2 アラート疲れ
問題が、上記に挙げたコストだけならまだいいでしょう。最悪のケースは「重大なアラートを見逃すこと」です。アラート件数が多いすぎると、本当に検知しなくてはならないアラートに気づかず障害への対応が遅れます。一度そうなったら最後、後は是正するまもなく芋づる式に障害対応の遅れが発生します。そうなる前に、必ずアラートの整理はしておかなくてはなりません。
3. アラートが増える原因
何故そんな事が起きてしまうのでしょうか。アラート過多になる根本原因について、人的要因と技術的要因の大きく２つの視点で見ていきます。
3.1. 人的要因
まず、目の前のアラートに対してこんな問いをかけてみてください。
Q: 「なぜこのアラートルール設定したんですか？」
よくあるNGなA: 「サポートがAMBAの推奨設定をそのまま使えと言ったので...」
こんなAでは、設定した技術的な背景が全くわかりません。何故こんなNGなAが生まれるのでしょうか。アラートの設計者や運用者に対して、以下のような甘えがないでしょうか。
- 設計者：「とりあえず監視したら安全」という思い込みをしている
- 運用者：「誰かが見ているだろう」という心理が働き、アラートへの関心が薄い
では、一方でどんな回答が理想なのでしょうか。
OKなA1: 「ApplicationInsightによって取得したRequestの監視でアプリの死活を監視しています。このRequestの監視でアラートが出た場合はアプリケーションがユーザー側で使用できなくなっている可能性が高いです。アラートが発生したら、直ちに原因分析を行うためAppServiceの状態と直近のデプロイ履歴を確認する必要があります。」
何故、このAが良いのか。それはアラートの技術的な背景とアラート発生時のアクションが明確であるためです。以下3点を気にしてAの作成をしましょう。
- 何のサービスを使用して、何を見ているのか技術的な説明ができる
- アラート発生時の影響範囲を説明できる
- アラートが発生したらどのように対処すればよいかが説明できる
もしあなたが運用チームのリーダーであれば定期的なアラートの見直しの機会を作成し、まずは今月発生件数の多い上位10件のアラートについて、上記の問を投げかけてみましょう。はっきりしないものは不要なアラートです。ノイズになるので問答無用で削除しましょう。
3.2. 技術的要因
もちろん、原因は人だけではなくAzure Monitor側にもあります。私はAzure Monitor（Azure）には以下に挙げるような欠点があり、監視業務に負荷をかけています。
- アラートが自動で集約されず、類似のアラートが上がり続ける
- EventGridやExpressRoute等のPaaS系のサービスは指標の種類が多いわりに、ドキュメントが浅くて理解が進まない（不安になる）
- StorageAccountやAppService等のスケールするサービスの監視が難しい
- 監視基盤（特にDCR（Data Collection Rule）、Transform（KQL ベースの変換）、AMPLS（Azure Monitor Private Link Scope））の構成が複雑過ぎて意図しないフィルタが掛かる
- 意外と手の届かない項目が多い（例：仮想マシン(Linux)のLatencyはログとして取れない等）
4. 解決策と構成例
ここまで読んで多くの読者は、どうすればいいかさらに技術的に教えて欲しいと思っていると思います。ここでは、アラート設定時の考え方について説明をしていきます。
4.1. アラートルール見直しの原則
4.1.1. SLO に直結する指標だけを監視する
一番最初にして最も重要なワードです。SLOって何なの？って方はこちらを先に呼んでください。そして、このSLOに直結しないアラートは捨てましょう。この考え方はオブザーバビリティに基づく、ユーザー目線での監視に切り替えて重要なアラートだけを残すための最も重要な考え方です。一方で、CPU使用率やIOPS等を指標とすることはノイズ（偽陽性）を発生させる原因になります。SLA/SLOを決めていない？では、まずは今すぐ設定しましょう。最初は既存のアラートとの併用でスモールスタートでも十分です。システムのオーナーと相談をして徐々にSLOを育て、SLOベースの監視へ切り替えていきましょう。
✗ ダメな例
- 仮想マシン CPU > 50%
- ディスク IOPS > 1000
- API Gateway バックエンド リクエスト処理時間 > 5 秒
✓ 良い例
- アプリケーション エラー率 > 1% （ビジネス SLA）
- API 可用性 < 99.5% （ユーザー影響）
- バジェット消費率 > 80% （月次チェック）
4.1.2. 比率で複合的な条件での評価を使う（メトリクス値の生値ではなく）
「平均値」「最大値」は環境スケールに依存しやすく、ノイズが多いので避けましょう。その対策として、成功数 / 失敗数や比率（成功率）で評価するのが良いです。また複合的な条件にするのもおすすめです。
✗ CPU が 70% 超えたらアラート（スケール依存で意味が薄い）
✓ リクエスト エラー件数が 5 件以上 /5 分 かつ
全リクエスト中の エラー率 > 1%
// Log Analytics での成功率クエリ例
requests
| where timestamp > ago(5m)
| summarize Total = count(), Failed = countif(success == false) by bin(timestamp, 1m)
| project timestamp, SuccessRate = (Total - Failed) * 100.0 / Total
| where SuccessRate < 99
4.1 3. PaaS のアラートは最小限に
PaaS（App Service、SQL Database、Cosmos DB等）は Microsoft が自動スケーリング・自動フェイルオーバーを行うため、基本的に監視は不要です。 ビジネス指標 のみの監視で十分です。
App Service
→ 監視対象：HTTP エラー率、応答時間 P95
→ 監視不要：CPU、メモリ（PaaS が自動調整）
SQL Database
→ 監視対象：接続タイムアウト、クエリ実行時間 P99
→ 監視不要：DTU 使用率（自動スケーリング）
Cosmos DB
→ 監視対象：4xx / 5xx エラー率
→ 監視不要：スループット使用率（スケール依存）
4.1.4. 仮想マシンの管理は基本自動化
仮想マシンはオンプレミスサーバーと一緒で、少し管理に手間がかかります。しかし、管理はオートスケールやバースト機能に極力任せましょう。サーバー再起動や証明書の更新などで対処できるような障害のアラートは、Automationをキックさせて自動化しておくことも効果的です。ただし、定期的にサイズの見直しが必要になってくるのでダッシュボードでスケール数やバースト回数、Automationの実行回数と成功率を表示できるようにしておきましょう。どうしても、仮想マシンのメトリクス監視が必要な場合は「連続 15 分以上 CPU > 90%」など継続性を条件にしておきます。
4.1.5. バジェットアラートを活用する
前述の通り、IOPSのバーストやStorage Acountのトランザクション数のアラート設定は不要です。その代わりに、バジェットアラートを設定しておきましょう。バジェットの消費が激しい時は、基本的に何か構成の見直しが必要な時になります。
# Azure Cost Management のバジェットアラート設定
- 毎月のバジェット上限を設定
- 80% / 100% / 110% 到達時にアラート
- これだけで「月末に請求額爆増」は防げる
4.2. インシデント管理ツールの統合
4.1で説明をしたアラートの整理ができた上で、まだアラートの管理が大変と感じるかもしれません。そういった場合はPagerDuty等のインシデント管理ツールを活用しましょう。インシデント管理ツールでは膨大なアラートを集約して優先度を振り分けるトリアージ機能があります。また、自動で荷電をしたり障害対応の自動化を支援する機能もあります。最近はAIがそれらの機能をアシストする機能も出てきているので、是非検討してみて下さい。
5. よくある質問
Q. 既に数百個のアラートルールがある場合は？
→ 重要度順に段階的に見直しましょう。最初は「0 - 重大」から整理し、段階的に「1 - エラー」、「2 - 警告」へと広げていきましょう。1ヶ月で30～50%のアラートを削減することを目標として進めてみて下さい。
Q. チーム内で「あの指標も見たい」という要望が来る場合は？
→ SLOに直結しないのであれば、DashboardやLog Analyticsワークスペースで見てもらうようにしましょう。SLOに直結問題が起きた時だけ確認する運用で十分なはずです。
Q. オンプレミス + ハイブリッド環境では？
→ AzureArc対応サーバーでAzure Monitorに統合し、オンプレミスも同じように監視ができます。Azure Arcの導入に興味のある方は是非、以前私の書いたこちらの記事を呼んでみてください。
Q. 開発環境・テスト環境のアラートはどうする？
→ 無効化したり設定しないのが理想ですが、どうしても必要であれば重要度も低く設定し、本番環境と分離して管理できるようにアラートルールへタグの設定をしましょう。
8. まとめ
Azure Monitor はきわめて強力なツールですが、設定にはAzureの各サービス、データベースやミドルウェア等様々な知見が必要になります。しかし、私が言いたいのは運用において最も重要なのはアラートへの関心です。公式ドキュメントで調べながら、AIや周りのチームに聞きながらで大丈夫です、ゆっくりでいいのでアラートへの理解を深めて不要なアラートは破棄していきましょう。
その上で、アラートの設定に重要なのはSLA に直結する指標だけ監視することです。みんなでアラート過多の悪夢から抜け出しましょう。
質問やご指摘があればコメントでお願いします。改善提案も歓迎です！