Log Analytics実践編｜DCR・Azure Monitor Agentでログを集める・横断クエリ・ログアラート・関数・コスト・RBAC

Log Analyticsを学びはじめて、KQL（Kusto Query Language）の書き方とワークスペースの概念が一通り分かってくると、次にぶつかるのが「そもそも、このログはどうやって集まってくるの？」という壁です。ポータルの「ログ」画面でクエリを書くところまではできても、そこに表示されるデータがどこから・どういう仕組みで流れ込んでいるのかが見えていないと、実務では手が止まってしまいます。

私自身、最初にAzure Monitorの周辺を触ったとき、「VMのログをLog Analyticsに送りたいだけなのに、DCRだのAMAだのエージェントだの、用語が多すぎて何から手をつければいいのか分からない」という状態でした。しかも公式のMicrosoft Learnは正確なぶん情報量が多く、初見だと迷子になりがちです。

「クエリは書けるようになったけど、VMのログを実際に集めて、アラートを鳴らして、コストも抑えて…という”運用”のイメージが全然わかない」

この記事では、KQLの基礎とワークスペースの概念は前提にしたうえで、その一歩先——実際にログを集めて運用に乗せる応用を扱います。具体的には、データ収集ルール（DCR）とAzure Monitor Agent（AMA）でログをどう集めるか、複数ワークスペースをまたいだ横断クエリ、KQLベースのログアラート、クエリを関数として再利用する方法、そして実務でいちばん怖い取り込みコストの管理とテーブル単位のアクセス制御（RBAC）までを、公式の正確さを保ちつつ、つまずきどころを日本語で噛み砕いて解説します。

なお、そもそもLog Analyticsやワークスペースが何者なのか・KQLの基本があやふやな方は、先に Azure Log Analyticsとは？（親記事・全体像とKQL入門）に目を通しておくと、この記事の位置づけがはっきりします。本記事はその「実践編」にあたる子記事です。

全体像：ログは「集める側」と「見る側」で分かれている
データ収集ルール（DCR）で「何を・どこへ集めるか」を定義する
Azure Monitor Agent（AMA）をVMに入れてDCRと紐付ける
複数リソース・ワークスペースをまたいで横断クエリする
保存済みクエリを「関数」として再利用する
KQLの結果でログアラートを作る
取り込み量とコミットメント階層でコストを管理する
RBACとテーブルレベルのアクセス制御
まとめ
次のステップ：クラウドエンジニアとしての市場価値

全体像：ログは「集める側」と「見る側」で分かれている

細かい手順に入る前に、Log Analytics運用の登場人物を一枚の地図にしておきます。ここがぼんやりしていると、DCRとAMAの話が急にややこしく感じるので、たとえ話で押さえておきましょう。

Log Analyticsワークスペースは、ログをためておく「大きな倉庫」です。ここに集まったデータをKQLで検索する、というのは前提記事で見たとおりですね。問題は、その倉庫に荷物（ログ）をどうやって運び込むかです。ここで出てくるのが次の2つの相棒です。

ひとつはAzure Monitor Agent（AMA）。これはVMなどの中に住み込む「運送ドライバー」だと思ってください。マシンの中でログやパフォーマンスカウンターを拾い集め、倉庫まで運ぶ役です。もうひとつがデータ収集ルール（DCR）。これは「何を・どこから拾って・どの倉庫へ届けるか」を書いた配送指示書にあたります。ドライバー（AMA）は、この指示書（DCR）を渡されて初めて「あ、このログをあの倉庫に運べばいいのね」と動けるわけです。

この関係を左揃えのツリーで表すとこうなります。

VM / サーバー
 └─ Azure Monitor Agent（AMA）… 中でログを拾う「運送ドライバー」
      └─ Data Collection Rule（DCR）… 「何を・どこへ」の配送指示書
           └─ Log Analytics ワークスペース … ログをためる倉庫
                └─ KQL / ログアラート / 関数 … 倉庫の中身を検索・監視・再利用

この記事は、おおむねこの図を下から上へ逆にたどる形——まず「集める側」（DCRとAMA）を厚めに、次に「見る側」（横断クエリ・アラート・関数）、最後に運用の土台になる「コスト」と「アクセス制御」——という順で進めていきます。

データ収集ルール（DCR）で「何を・どこへ集めるか」を定義する

まずは配送指示書、つまりデータ収集ルール（DCR：Data Collection Rule）からです。ここがLog Analytics実践の肝であり、かつ初心者が最初につまずくポイントでもあります。

DCRは名前のとおり「データをどう収集するか」を定義したAzureリソースです。ざっくり言うと、DCRには次の3つが書かれています。

データソース（何を集めるか）：Windowsのイベントログ、Linuxのsyslog、パフォーマンスカウンター（CPU使用率など）、特定のテキストログファイルなど。
宛先（どこへ送るか）：送信先のLog Analyticsワークスペース。1つのDCRから複数の宛先に送ることもできます。
変換（任意）：送る前にKQLで整形・フィルタする。いらない行を落として取り込み量＝コストを削る、といった使い方ができます（後半のコストの話につながります）。

昔のLog Analyticsを触ったことがある人は、「エージェントの設定画面でイベントログのレベルを選んで…」という記憶があるかもしれません。あれは旧来のレガシーエージェント（Log Analyticsエージェント／MMA）のやり方で、収集設定がワークスペース側に丸ごと結びついていました。現在のAMAベースでは、その収集設定がDCRという独立したリソースに切り出されたのが最大の違いです。

これが最初は面倒に感じるのですが、実務で効いてくるメリットがあります。DCRは使い回せるのです。たとえば「Webサーバー用の収集ルール（IISログ＋特定イベントIDだけ拾う）」というDCRを一度作れば、そのルールを100台のWebサーバーに同じ設定でまとめて適用できます。台ごとに手で設定して回る必要がありません。設定とマシンが分離されたことで、大規模運用に強くなったわけですね。

DCRの作り方（ポータルの入り口）

作成の入り口は Azureポータルの「モニター」→ 設定の「データ収集ルール」です。「作成」から進み、リソースグループとリージョンを選んだら、次の3ステップを順に埋めていきます。

リソース：このDCRを紐付ける対象（VMやスケールセット）を選ぶ。ここで対象を指定すると、後述のAMAが自動でインストールされます。
収集して配信：データソースの種類（Windowsイベントログ／syslog／パフォーマンスカウンター等）を追加し、それぞれの宛先ワークスペースを指定する。
確認と作成：内容を確認して作成。

ここで一つ、初見でつまずきやすい落とし穴があります。DCRのリージョンと、送信先ワークスペースのリージョンは基本的にそろえる必要がある、という点です。バラバラにしていると、リソースは紐付けられているのにログが一向に流れてこない、という気づきにくいトラブルになります。「集まらないな」と思ったら、まずここを疑ってください。

なお、DCRと対象リソースの間にはDCA（Data Collection Rule Association／関連付け）という結びつきが自動で作られます。用語としては出てきますが、ポータルで対象を選べば裏で勝手に作られるものなので、最初は「DCRとVMをつなぐ紐」くらいの理解で十分です。

Azure Monitor Agent（AMA）をVMに入れてDCRと紐付ける

配送指示書（DCR）ができたら、それを実行する運送ドライバー——Azure Monitor Agent（AMA）の出番です。AMAはVMやArm対応のマシンにインストールする軽量なエージェントで、DCRの指示にしたがってログやメトリックを収集し、ワークスペースへ送ります。

ここで嬉しいのは、多くの場合AMAのインストールを手作業でやる必要がないことです。前のステップでDCRの「リソース」に対象VMを指定すると、そのVMにAMAが自動で入り、DCRとの紐付けまで済みます。つまり実務の流れとしては、「AMAを入れる」より先に「DCRを作って対象を指定する」のが自然です。ドライバーを雇ってから指示書を渡すのではなく、指示書を作った瞬間にドライバーが配属される、というイメージですね。

AMAが動くための前提（つまずきどころ）

AMAが正しくログを送れないとき、原因はだいたい次のどれかに当てはまります。実務でハマりやすいので、うまく集まらないときのチェックリストとして押さえておいてください。

マネージドID：AMAは基本的にVMのマネージドID（システム割り当て）を使って認証します。IDが無効だと送信できません。ポータルからAMAを入れると通常は自動で有効化されますが、手動構成のときは見落としがちです。
ネットワーク（送信経路）：AMAはAzure Monitorのエンドポイントへ送信できる必要があります。閉域構成（Private Link）でアウトバウンドを絞っている環境では、AMPLS（Azure Monitor Private Link Scope）やDCE（データ収集エンドポイント）の構成が必要になります。閉域環境で「送れない」ときはここが鉄板の原因です。
DCRとの関連付け：エージェントは入っているのに、そのVMにDCRが紐付いていない。この場合、ドライバーはいるのに指示書がない状態なので、何も運ばれません。

ちなみに、旧来のLog Analyticsエージェント（MMA/OMS）はすでに提供終了（廃止）となっており、新規はもちろん既存もAMAへの移行が前提です。ネットで古い手順を見つけて「ワークスペースに直接エージェントをつなぐ」やり方をなぞろうとすると、現在のポータルと画面が合わずに混乱します。「エージェントの話はDCR経由が今の正解」と覚えておけば、情報の取捨選択がしやすくなります。

「ログが集まらない！」の9割は、DCRの紐付け忘れ・マネージドID・リージョン不一致・閉域の経路のどれか。まずこの4点を疑うと早いです。

複数リソース・ワークスペースをまたいで横断クエリする

ここからは「見る側」の話に移ります。倉庫にログが集まってきたら、次は検索です。ただ実務では、ワークスペースが1つとは限りません。「本番用」「検証用」「セキュリティ用」と分かれていたり、部署ごとに分割されていたりします。そんなとき、複数の倉庫を一度にまたいで検索できると一気に運用がラクになります。

基本の道具は2つです。ひとつはunion、もうひとつはworkspace()関数です。

まず同じワークスペース内で複数テーブルをまとめたいならunionです。たとえばエラー系を横断で見たいとき、こう書きます。

union AzureDiagnostics, AzureActivity
| where TimeGenerated > ago(1h)
| where Level == "Error"
| project TimeGenerated, Type, ResourceGroup, OperationName

そして別のワークスペースのテーブルを参照したいときに使うのがworkspace()関数です。今クエリを実行しているワークスペースとは別の倉庫を、名前やリソースIDで指定して覗きにいくイメージです。

// 別ワークスペース "security-ws" のSigninLogsを参照する
workspace("security-ws").SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize 失敗回数 = count() by UserPrincipalName
| order by 失敗回数 desc

この2つを組み合わせれば、「本番ワークスペースのエラーログ」と「セキュリティワークスペースのサインイン失敗」を1つのクエリで突き合わせる、といった横断分析ができます。

union
  AppRequests,
  workspace("security-ws").SigninLogs
| where TimeGenerated > ago(1h)

実務で気をつけたいのは、横断クエリには相応の権限が要る点です。参照先のワークスペースに対して読み取り権限がなければ、当然ながらそのデータは見られません。「クエリは正しいのに空っぽで返ってくる」ときは、構文よりもまず参照先ワークスペースへのアクセス権を疑ってください（このアクセス制御の話は、後半のRBACの節につながります）。また、たくさんのワークスペースを一気にまたぐとクエリが重くなるので、範囲は必要な倉庫だけに絞るのがコツです。

保存済みクエリを「関数」として再利用する

運用を続けていると、同じような長いKQLを何度も書くことになります。「エラーだけ抽出して、リソースグループごとに集計して、直近1時間に絞って…」というお決まりのクエリを、毎回コピペするのは面倒ですし、少しずつ書き方がブレて属人化していきます。ここで役立つのが関数（保存済み関数）です。

Log Analyticsの関数は、よく使うKQLに名前を付けて保存し、あとからまるでテーブルのように呼び出せる仕組みです。プログラミングで長い処理を関数化して使い回すのと同じ発想ですね。定義は一度きり、呼び出しはシンプル、という状態を作れます。

作り方は簡単で、「ログ」画面でクエリを書いたあと、上部の「保存」→「関数として保存」を選び、関数名と関数エイリアス（呼び出し名）を付けるだけです。たとえば直近1時間のエラーをまとめるクエリを RecentErrors というエイリアスで保存すれば、次からはこう呼ぶだけで済みます。

RecentErrors
| where ResourceGroup == "prod-rg"
| summarize count() by Type

RecentErrors がまるで1つのテーブルのように振る舞い、そこにさらに絞り込みや集計をつなげられるわけです。関数にはパラメーターを持たせることもできるので、「対象時間を引数で変えられるエラー抽出関数」といった汎用的な部品も作れます。

チーム運用での効きどころは、ロジックの一元管理です。集計の定義を関数に閉じ込めておけば、後述のログアラートやダッシュボードからその関数を呼ぶだけで、判定ロジックを1か所で保守できます。「アラートの条件を直したいのに、あちこちに同じクエリが散らばっていて漏れる」という事故を防げます。

KQLの結果でログアラートを作る

ログを集めて検索できるようになったら、次は「まずい状態を自動で検知して知らせる」——ログアラートです。KQLクエリを定期的に実行し、その結果が決めたしきい値を超えたら発報するのがログアラートの基本動作です。

作成は「モニター」→「アラート」→「アラートルールの作成」から進みます。ざっくり次の流れです。

スコープ：どのワークスペース（またはリソース）を対象にするか。
条件：判定に使うKQLクエリと、しきい値・集計方法・評価の頻度を指定する。ここが核心です。
アクション：発報時に何をするか（メール送信・Webhook呼び出しなど）。ここは「アクショングループ」という仕組みでまとめて指定します。

条件のKQLは、たとえば「直近5分でエラーが10件を超えたら鳴らす」ならこんなイメージです。

AppExceptions
| where TimeGenerated > ago(5m)
| summarize ErrorCount = count()

このクエリに対して、条件を「集計値（ErrorCount）が 10 より大きい」「5分ごとに評価」と設定すれば、エラーが急増したときに通知が飛びます。先ほど作った関数を条件クエリとして呼ぶこともできるので、判定ロジックを関数に寄せておくと保守が一気にラクになります。

初心者がつまずきやすいのが、「評価の頻度」と「時間範囲」を混同することです。頻度は「どれくらいの間隔でクエリを回すか」、時間範囲（ago()）は「毎回どこまでさかのぼって見るか」です。この2つがちぐはぐだと、同じエラーを何度も数えて誤発報したり、逆に取りこぼしたりします。まずは「5分ごとに、直近5分を見る」のように頻度と範囲をそろえるところから始めると安全です。

なお、通知先をまとめるアクショングループや、複数アラートを俯瞰する統括的な仕組みは、話が大きくなるのでここでは深追いしません。それらはAzure Monitor全体の記事に譲り、本記事では「KQLの結果からログアラートを1本作る」ところまでを押さえておけば十分です。

取り込み量とコミットメント階層でコストを管理する

ここは実務でいちばん怖い、そして見落とされがちな話です。Log Analyticsの課金は、多くの部分が「ワークスペースに取り込んだデータ量（GB）」に対してかかります。つまりログを集めれば集めるほどお金がかかる。「とりあえず全部のログを最大詳細度で送っておこう」とやると、月末に想像以上の請求が来て青ざめる——これはあるあるです。

コストを抑える考え方は、大きく2方向あります。「そもそも取り込む量を減らす」と、「大量に取り込むなら単価を下げる」です。

取り込む量を減らす（送る前に絞る）

いちばん効くのは、そもそも要らないログを送らないことです。ここで前半のDCRが効いてきます。DCRには変換（Transformation）を仕込めるので、送信前にKQLでフィルタして、デバッグレベルのログや不要な列を落としてから取り込むことができます。「全部集めてから後で捨てる」のではなく「入り口で絞る」わけです。取り込み時に減らせば、そのぶん丸ごと課金対象から外れます。

もう一つ、テーブルごとの保有期間（Retention）も効きます。長く保存するほどコストがかかるので、「監査用は長く、デバッグ用は短く」とテーブル単位でメリハリをつける。さらに、めったに検索しないが法令等で残す必要があるログは、安価なBasicログ／アーカイブ層に寄せる、という手もあります（検索性は落ちるトレードオフあり）。

従量課金 vs コミットメント階層

単価そのものを下げる仕組みがコミットメント階層（Commitment Tier）です。デフォルトは従量課金（Pay-As-You-Go）で、取り込んだGBぶんだけ課金される、いちばん素直なモデルです。少量なら無駄がありません。

一方、取り込み量が安定してそれなりに多い場合は、「1日あたり◯◯GBぶんを前もって約束（コミット）する代わりに、GB単価を割り引く」のがコミットメント階層です。携帯電話の「使い放題プラン」に近いイメージで、たくさん使う前提なら固定額のほうが結果的に安くなる、というものです。日次で100GB、200GB…といった段階（ティア）が用意されていて、上のティアほど割引率が高くなります。

選び分けの目安はシンプルで、まず数週間は従量課金で実際の取り込み量を観察し、日次の取り込みが安定して割引ラインを超えるようならコミットメント階層に切り替える、という順番が現実的です。最初から大きく約束すると、使い切れないぶんも払うことになりかねません。取り込み量そのものは、次のクエリで確認できます。

Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize 取り込みGB = sum(Quantity) / 1000 by bin(TimeGenerated, 1d), DataType
| order by TimeGenerated desc

このUsageテーブルは「どのテーブル（DataType）が課金対象データを食っているか」を教えてくれる、コスト管理の要です。想定外に膨らんでいるログが見つかったら、その収集をDCRの変換で絞る——という「計測→削減」のループを回すのが、Log Analytics運用のコスト最適化の王道です。

RBACとテーブルレベルのアクセス制御

最後は運用の土台になるアクセス制御です。ログにはサインイン履歴やアクティビティなど、見せる相手を選びたい情報が含まれます。「開発チームにはアプリのログだけ見せたいが、セキュリティ監査ログは見せたくない」といった要求は普通に発生します。

Log Analyticsのアクセス制御は、大きく2つの層で考えます。

ひとつはアクセスモード。ワークスペースには「ワークスペース単位でまとめて権限を管理するモード」と「リソース単位の権限を尊重するモード」があり、後者ではそのリソースを見られる人だけが、そのリソースのログを見られるようになります。VMの閲覧権限を持つ人が、そのVMのログも自然に見られる、という直感的な制御ができるわけです。

もうひとつが、より細かいテーブルレベルRBACです。これは「このユーザー（グループ）には、このテーブルだけ読ませる／このテーブルだけ隠す」という、倉庫の中の棚ごとに鍵をかける制御です。カスタムロールを作り、対象テーブルを許可・拒否の対象に指定することで実現します。先ほどの例なら、開発チームのグループにはAppRequests系のテーブルだけを許可し、サインインログのテーブルは対象外にする、といった具合です。

実務のコツは、Entra IDの原則と同じで権限は個人ではなくグループに付けることです。「開発閲覧グループ」「監査グループ」を作り、そこにテーブルレベルの読み取りロールを割り当てておけば、人の入れ替わりはグループのメンバー変更だけで済みます。Log Analyticsのアクセス設計も、結局はAzure RBACの最小権限の考え方の延長線上にある——ここが腑に落ちると、権限まわりで迷わなくなります。

まとめ

この記事では、Log Analyticsを「実際にログを集めて運用に乗せる」視点で、つまずく順に見てきました。要点を振り返っておきます。

集める側：DCR（配送指示書）で「何を・どこへ」を定義し、AMA（運送ドライバー）がVMからログを運ぶ。集まらない時はDCRの紐付け・マネージドID・リージョン・閉域経路を疑う。
横断クエリ：同一ワークスペースはunion、別ワークスペースはworkspace()。空で返るときは参照先の権限を確認。
関数：よく使うKQLに名前を付けて再利用。判定ロジックを一元管理でき、アラートからも呼べる。
ログアラート：KQLの結果をしきい値判定して発報。頻度と時間範囲をそろえるのがコツ。
コスト：課金は取り込み量ベース。DCRの変換で入り口から絞り、Usageで計測。量が安定して多いならコミットメント階層で単価を下げる。
アクセス制御：アクセスモードとテーブルレベルRBACで棚ごとに鍵をかける。権限はグループに付ける。