Skip to content

MS_AzureMonitoring

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azureの監視と管理

概要

Azure の監視と管理

レイヤ

上位

アプリケーション・レイヤ

  • クラウド ≒ 同じ物理サーバーに同居するマルチ・テナントなので、
    原則としてはアプリ・レベルでの監視を基本に考える。
  • 「業務処理として正しく動いているかどうか」を監視

構成

Application ログ

出力

Application Insights
（高機能アプリ監視ツール（Deep Application Monitoring））

補足（「アプリ・レベルの監視を基本に」が本ページの主張）: この方針には
クラウド特有の理由がある。

オンプレミスでは、自分のサーバのハードウェア指標を見れば
性能が分かった。しかしクラウドでは、

  • 物理サーバは他テナントと共有されており、
    自分から見える指標が必ずしも実態を表さない（ノイジー ネイバー）、
  • インスタンスが勝手に入れ替わる（サービス ヒーリング、スケール、メンテナンス）、
  • PaaS ではそもそも OS の指標が見えない

ため、インフラ指標だけでは「遅い」の原因に辿り着けない。

したがって、

問い 答えを持つ層
業務は成立しているか アプリ層（Application Insights）
応答時間はどうか アプリ層（分散トレース）
なぜ遅いのか 両方（アプリ層で当たりを付け、インフラ層で確認）
リソースは足りているか インフラ層（Metrics）

という役割分担になる。
「まずアプリ層」というのは、
利用者から見た事実を最初に押さえるという意味であり、
オンプレでの障害分析
（因果関係の分析例）とも整合する考え方である。

下位

ミドル、インフラ・レイヤ

  • 障害予防や障害切り分けのための全体的な「症状」の監視
  • 3rd party ミドル製品のサポートが手薄（プリセット情報が無いので）。

移行メモ（体裁）: 原典の「障害切分のタメの」は
「障害切り分けのための」の略記であるため展開した。

構成

出力

ログを以下の出力系統に出力する。

  • ストレージ
    • 長期間保存に優れる。
    • Storage Explorer で生ログ参照。
    • お手軽だが分析は苦手。
  • Log Analytics
    高機能インフラ監視ツール
    （Deep Infrastructure Monitoring）
    • ログ分析ツール
      KQL (Kusto Query Language) の利用が必要
    • OMS ソリューション
      定型的な保守作業の管理画面を提供
    • Azure Sentinel
      特にセキュリティ・インシデントに関わる管理画面を提供
  • Azure Event Hubs
    外部連携へ。

2 系統以上の出力に飛ばすというケースもある。

補足（3 つの出力先の使い分けが設計の要）: 「2 系統以上に飛ばす」という
一行が示すとおり、出力先は排他ではなく併用するのが実務的である。

出力先 得意 苦手 費用
ストレージ 長期保存、監査証跡 検索・分析 安い
Log Analytics 検索・相関・アラート 長期保存（保持期間で課金） 高い（取り込み量課金）
Event Hubs 外部の SIEM / 分析基盤へ流す それ自体は保存しない 中

典型的な構成は次のようになる。

                ┌→ Log Analytics（直近 30〜90 日。検索・アラート）
ログ／メトリック ─┼→ ストレージ（1〜7 年。監査・法定保存。安価）
                └→ Event Hubs（既存の SIEM や Splunk 等へ）

費用の観点が重要で、Log Analytics は
取り込んだデータ量で課金される。
「全部 Log Analytics に入れる」と
監視費用がインフラ費用を上回ることがある。

対策としては、

  • 診断設定でカテゴリを絞る（全カテゴリを有効にしない）、
  • **基本ログ（Basic Logs）**を使う（安価だが検索機能が制限される）、
  • 保持期間を短くし、長期分はアーカイブ層やストレージへ、
  • コミットメント レベル（従量より割安な定額枠）を検討する

といった手がある。

VM診断の場合

（今後、統合されていく予定）

  • 古い機能
    基本的なルートは、ストレージ → 一部は Log Analytics
    • ブート診断
    • Azure Diagnostics 拡張機能エージェント
      • WAD : Windows エージェント
      • LAD : Linux エージェント
  • 新しい機能
    基本的なルートは、Log Analytics
    • Log Analytics エージェント
      • MMA : Microsoft Monitoring Agent
      • LAA : Log Analytics Agent
    • 依存関係エージェント

補足（最新化：統合は完了した）: 「今後、統合されていく予定」と
あるが、この統合は完了している。現在は
**Azure Monitor エージェント（AMA）**に一本化された。

世代 エージェント 状況
第 1 世代 WAD / LAD（Azure Diagnostics 拡張機能） 非推奨
第 2 世代 MMA / LAA（Log Analytics エージェント） 2024 年 8 月にサポート終了
現行 Azure Monitor エージェント（AMA） これに移行する

AMA の利点は、

  • 収集内容を「データ収集規則（DCR）」で一元管理できる
    （どのマシンから何を集めて、どこへ送るかを宣言的に定義）、
  • 1 つのエージェントで複数の送信先に振り分けられる、
  • Windows / Linux で同一の仕組み

という点にある。
旧エージェントを使っている環境は移行が必要である。

なお、ブート診断は今も現役で、
VM が起動しない場合の切り分けに必須である
（Azure上に素早く環境を構築する）。

ログ

タイプ

コントロール / 管理ログ

Azure Resource Manager (ARM)の
CREATE、UPDATE、および DELETE 操作の可視性を提供。

データ プレーン ログ

Azure リソース使用の一環として発生するイベントの可視性を提供。

処理済みイベント

ユーザーに代わって処理された分析済みのイベント / アラートに関する情報を提供。

補足（コントロール プレーンとデータ プレーンの区別）: この 2 つの区別は、
障害調査で「どこを見るか」を決めるため重要である。

コントロール プレーン データ プレーン
何の記録か リソースへの操作（作った・変えた・消した） リソースの中で起きたこと
例 「誰が NSG の規則を変更したか」 「どの IP からアクセスがあったか」
ログ アクティビティ ログ 診断ログ
経路 ARM API（Azureの管理ポータルとARM API） 各サービス

実務での使い分けは明快で、

  • 「昨日まで動いていたのに今日は動かない」 → アクティビティ ログ
    （誰かが構成を変えた可能性。変更の切り分け）
  • 「特定のリクエストだけ失敗する」 → 診断ログ
    （中で何が起きたか）

となる。
アクティビティ ログはすべての ARM 操作が自動的に記録されるため、
何も設定しなくても残っている点も覚えておきたい。

構成要素

Applicationログ

  • アプリケーションが出すログ。
  • 出力先には以下がある。
    • ディスク
      • データディスク：不揮発
      • 一時ディスク：揮発性（VM の再デプロイで消失）
    • Azure Storage
    • KVS, RDB
    • , etc.

補足: 「一時ディスク（D:）は揮発性」という点は
Azureの仮想マシンでも触れたとおりで、
アプリのログを D: に書いてはいけない。
障害調査で最も必要なログが、
障害で VM が別ノードに移った瞬間に消えることになる。

アクティビティ ログ（Activity logs）

補足（保存期間は恒久ではない）: 「19 日間」は執筆当時の値で、
現在の既定保持は約 90 日である。
いずれにせよ恒久的ではない点が要点である。

監査要件で長期保存が必要な場合、
診断設定でストレージまたは Log Analytics に転送する必要がある。
「後から去年の変更履歴を調べたい」となっても、
転送設定をしていなければ残っていない。
サブスクリプション作成直後に設定しておくべき項目である。

診断ログ（Diagnostic logs）

補足（保存期間「？」への回答）: 診断ログは既定では
どこにも保存されない。これが本文の「？」の答えである。

アクティビティ ログが自動的に記録されるのに対し、
診断ログは「診断設定」を有効にして初めて出力が始まる。
設定しなければ、そもそもログが存在しない。

したがって保存期間は転送先の設定次第になる。

転送先 保存期間
ストレージ ライフサイクル管理で任意（年単位も可）
Log Analytics ワークスペースの保持期間（既定 30 日、最大 730 日、アーカイブでさらに長期）
Event Hubs 保持しない（転送のみ。最大 7 日のバッファ）

**「障害が起きてからログを有効にしても、その障害のログは無い」**という
当たり前だが痛い事態を避けるため、
本番リソースには最初から診断設定を入れておく必要がある。
Azure Policy で「診断設定を強制する」ことも可能である。

メトリック（Metrics）

  • CPU 利用率、実行数待ち時間、消費容量など、
    様々な指標の Azure リソースのパフォーマンス カウンタ。
  • 全てのリソースがメトリック（Metrics）を持っているわけではない。
  • 最初から有効で、サンプリング間隔は最短のもので 1 分、30 日間保存。

補足（メトリックとログの違い）: この 2 つは似て見えるが、
データ構造がまったく異なる。

メトリック ログ
構造 数値の時系列（固定スキーマ） 任意の構造
有効化 既定で有効 診断設定が必要
保持 93 日（現在） 転送先次第
応答速度 速い（専用の時系列 DB） 遅い（検索）
用途 アラート、ダッシュボード 原因調査

実務では、

メトリックでアラート（速い・安い）→ 異常を検知
      ↓
ログで原因を調査（詳細・重い）

という組み合わせになる。
アラートをログ ベースで組むと、遅延と費用が増えるため、
メトリックで表現できる条件はメトリックで組むのが定石である。

監視機能

なんとなく、ストレージ＋分析機能みたいなモノか。

共有機能

（Shared Capabilities）

Azure Alerts

Dashboards

Metric Explorer

メトリック（Metrics）を Log Analytics に送信して、他のソースから収集されたデータと合わせて分析できる。

モニター機能

（Core Monitoring）

Azure Monitor

Azure Advisor

  • リソース構成と使用状況に関するテレメトリを常に監視、リスクと潜在的な問題を検知。
  • ベスト プラクティスに基づいて、ユーザの環境に合わせた推奨事項、最善の解決策を提示。
  • これにより、リソースのコスト / パフォーマンス / セキュリティ / 可用性の最適化を図る。

補足（Advisor は「無料で効く」）: Azure Advisor は
追加費用なしで使え、5 つの観点で推奨事項を出す。

観点 例
コスト 未使用のパブリック IP・アイドル状態のディスク・過剰サイズの VMの検出、予約インスタンスの提案
信頼性 単一 VM の可用性セット未構成、バックアップ未設定
セキュリティ Defender for Cloud の推奨事項
パフォーマンス ディスク SKU、SQL のインデックス
オペレーショナル エクセレンス サービス正常性アラート未設定

Azureの課金の「VM を使ってない割に高額になる」への
実際的な対処として、まず Advisor のコスト タブを見るのが早い。
Azure Well-Architected Frameworkの
5 本の柱と観点が一致している点も、覚えやすさに繋がる。

Service Health

  • アプリケーションの正常性は、使用している Azure サービスの影響を受ける。
  • Azure サービスでアプリケーションに影響を与える可能性のある問題を発生/特定。
  • 予定メンテナンスの計画にも役立つ。

補足（Service Health のアラートは必ず設定する）: 「自分のシステムは
何も変えていないのに障害が起きた」という場合、
Azure 側の障害である可能性がある。
Service Health はこれを知る唯一の手段である。

3 種類の情報を扱う。

種別 内容
サービスの問題 現在発生中の Azure 側の障害
計画メンテナンス 予定された再起動等（Azureの高可用性設計）
正常性の勧告 サービスの廃止予告、構成変更の依頼

重要なのは、アラートを設定しない限り通知は来ないという点である。
ポータルを見に行かなければ気付けない。

サブスクリプション作成時に必ずやるべき設定として、

  1. Service Health アラート（自分が使うリージョンとサービスに絞る）、
  2. アクション グループ（メール／Teams／PagerDuty 等への通知）

の 2 つを挙げておきたい。無料である。

Activity logs

高機能インフラ監視ツール

（Deep Infrastructure Monitoring）

Log Analytics

高機能アプリ監視ツール

（Deep Application Monitoring）

Application Insights

Azure Security Center

補足（現在の全体像）: 本節の分類は執筆当時のもので、
現在はAzure Monitor が上位概念として整理し直されている。

【Azure Monitor】（傘となる名称）
  ├─ Metrics       … 数値の時系列
  ├─ Logs          … Log Analytics ワークスペースに集約
  │    └─ Application Insights も「ワークスペース ベース」に統合済み
  ├─ Alerts        … メトリック／ログ／アクティビティ ログを条件にアラート
  ├─ Dashboards / Workbooks / Managed Grafana … 可視化
  └─ Insights      … VM / コンテナ / アプリ 向けの既製の分析ビュー

主な改称・統合は次のとおり。

旧 現在
OMS（Operations Management Suite） Azure Monitor に統合
Log Analytics（製品名として） Log Analytics ワークスペース（Azure Monitor の一機能）
Application Insights（独立） ワークスペース ベース（Log Analytics 上に構築）
Azure Security Center Microsoft Defender for Cloud
Azure Sentinel Microsoft Sentinel

特に、Application Insights と Log Analytics が
同じワークスペースに乗ったことは実務上大きい。
アプリのトレースとインフラのログを 1 つの KQL クエリで結合できるため、
本ページ冒頭の「上位／下位レイヤ」を横断した分析が容易になった。

セキュア化とロックダウン

作業内容の安全性の確認

  • 入力制御（インバウンド）
    本機能への入力が、IaaS から見て出力なので、経路制限（特定経路の開放）について。
    • 大半の監視はエージェント型なので経路開放が必要
    • 隠し経路を利用するものと、明示的な経路開放が必要なものがある。
  • ハードニング（クライアント or サーバ）
    なし。
  • 出力制御（アウトバウンド）
    なし。
  • 参考

移行メモ（体裁）: 原典の「経路開放放が必要」は
「放」が重複していたため修正した。

補足（「隠し経路」＝プラットフォーム エンドポイント）: 本文の
「隠し経路を利用するもの」は、
Azureの仮想マシンで触れた
**基盤経路（168.63.129.16 等）**を指す。

経路 対象 NSG / Firewall の設定
基盤経路（隠し経路） ブート診断、VM エージェント、Azure Backup 不要
一般経路 Log Analytics、Application Insights 必要

閉域環境で監視を成立させる手段は 2 つある。

手段 内容
サービス タグで許可 NSG / Azure Firewall で AzureMonitor サービス タグを許可（IP 直書きより保守が楽）
Azure Monitor プライベート リンク スコープ（AMPLS） Private Endpoint 経由で監視データを送る。インターネットに出さない

「IP アドレスの一覧を許可する」という方法は、
IP が変動するため保守が破綻する。
参考リンクは当時のものだが、現在は
サービス タグまたは AMPLS を使うのが正しい
（Azureのアウトバウンド設計、
Azure Private Link）。

変更・保守、作業の一覧化

（記載なし）

参考

Azure Monitor

Microsoft Docs

ログ

監視

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally