Azure Arc AgentのログをLog Analytics Workspaceにためて一元管理する方法

この記事の内容

  • Azure Arcで管理するハイブリッドサーバーのエージェントログをLog Analytics Workspaceに集約する手順を解説します
  • DCE（Data Collection Endpoint）とDCR（Data Collection Rule）を組み合わせたログ収集アーキテクチャを紹介します
  • KQL（Kusto照会言語）を使ったカスタムテキストログのパース変換方法を説明します
  • 収集したデータをKQLでクエリして、問題のあるサーバーを素早く特定する活用例を示します
  • 本手法はAzure Arcエージェントのログに限らず、任意のテキストベースのログファイルへの応用が可能です

はじめに

Azure Arcを通じて管理されているオンプレミスや他社クラウド上のサーバーでは、エージェントが正常に動作していることがサービス提供の前提となります。しかし、エージェントのログは各サーバー内に個別に保存されているため、トラブルシューティングの際には対象サーバーに直接アクセスして確認する必要がありました。

本記事では、Azure MonitorとLog Analytics Workspaceを活用し、すべてのサーバーのAzure Arcエージェントログを一箇所に集約して一元管理・分析する方法を解説します。

ログ収集のアーキテクチャ（全体像）

ログ収集の仕組みは、以下のコンポーネントが連携して動作します。

コンポーネント役割
ハイブリッドサーバーAzure Arc Connected Machine Agentがインストールされたオンプレ・他クラウドのサーバー
Log Analytics Workspaceログを格納・分析するための器。カスタムテーブルを作成して利用します
Data Collection Endpoint（DCE）サーバーからのログデータを受け取るための窓口
Data Collection Rule（DCR）「どのサーバー」から「どのログ」を「どう変換」して「どのテーブル」に格納するかを定義するルール
Azure Monitor Agent（AMA）DCRが適用されると自動インストールされ、ログを読み取って指定エンドポイントに送信するエージェント

このアーキテクチャを構築することで、Log Analytics Workspaceに集約されたデータに対してKQLを使った高度なクエリを実行したり、ダッシュボードで可視化したりすることが可能になります。

前提条件

実装を始める前に、以下の条件が満たされていることを確認してください。

  • Azure Arcに接続済みのサーバーが存在すること
  • 有効なAzureサブスクリプションを所有していること

実装手順

ステップ1：Log Analytics Workspaceにカスタムテーブルを作成する

最初に、収集したログを格納するための専用テーブルをLog Analytics Workspace内に作成します。

Log Analytics Workspaceでは、標準テーブルに加えて、ユーザーが独自のスキーマを定義したカスタムテーブルを作成できます。これにより、任意の構造を持つデータを柔軟に受け入れることが可能です。

カスタムテーブルの名前には末尾に _CL（Custom Log）というサフィックスが自動的に付与されます。

ステップ2：データ収集ルール（DCR）を作成する

次に、データの収集方法を定義するデータ収集ルール（DCR）を作成します。DCRにはデータソース、変換処理、送信先の3つを定義します。

データソースの指定

  • データソースの種類として「カスタム テキスト ログ」を選択します
  • 収集対象ログファイルのパスとファイル名パターンを指定します（例：/var/opt/azcmagent/log/himds.log）
  • 格納先として、ステップ1で作成したカスタムテーブルを選択します
  • レコードの区切り文字（例：改行）を指定します

データ変換（Transform）の設定

収集したログデータをテーブルの各列にマッピングするための変換処理を、KQLで定義します。

Azure Arcエージェントのログは、一般的に以下のような形式になっています。

Time=...Level=...MSG=...

この1行のログから Time・Level・MSG の各値を抽出し、それぞれ TimeGenerated・Level・Message という列に格納するためのKQLクエリを記述します。

source
| extend Time = extract("Time=([^ ]+)", 1, RawData)
| extend Level = extract("Level=([^ ]+)", 1, RawData)
| extend Message = extract("MSG=(.*)", 1, RawData)
| project TimeGenerated = todatetime(Time), Level, Message

このクエリでは、正規表現を使って RawData（ログの1行）から各要素を抽出し、指定した列にマッピングしています。todatetime() 関数で時刻データを適切な型に変換している点も重要なポイントです。

ステップ3：作成したDCRをAzure Arcサーバーに適用する

作成したDCRを、ログを収集したいAzure Arcサーバーに関連付けます。

適用方法は2種類あります。

  • 個別適用：特定のサーバーを選択して手動で関連付ける
  • Azure Policyによる一括適用：複数のサーバーにまとめて適用する（大規模環境向け）

DCRが適用されると、対象サーバーにAzure Monitor Agentの拡張機能が自動的にインストールされ、定義に従ってログ収集が開始されます。

収集したデータのクエリと活用

データがLog Analytics Workspaceに収集されたら、KQLを使って自由にクエリを実行できます。

以下の例では、サーバーごと・ログレベルごとにログの件数を集計しています。

YourCustomTableName_CL
| summarize count() by ArcVmId, Level
| order by ArcVmId, Level

このクエリを実行することで、特定のエラーログが多発しているサーバーを簡単に特定できます。また、KQLの豊富な関数を活用すれば、時系列での傾向分析やアラート設定など、さまざまな活用が可能です。

まとめ

Azure ArcエージェントのログをLog Analytics Workspaceに集約することで、以下のメリットが得られます。

  • 一元管理：ハイブリッド環境全体のログをAzure上の一箇所で確認できる
  • 効率的なトラブルシューティング：KQLを使った高度なクエリで問題のあるサーバーをすばやく特定できる
  • スケーラビリティ：Azure Policyを使えば、大量のサーバーへの設定適用も自動化できる
  • 汎用性：本手法はAzure Arcエージェントのログだけでなく、任意のテキストベースのログファイルにも応用可能

DCEとDCRを組み合わせたこのアーキテクチャは、複雑な設定なしにハイブリッドサーバーの監視基盤を構築できる強力な手段です。ぜひ自社のハイブリッド環境でも取り入れてみてください。