AzureでLinuxサーバーを運用するなら、Azure Monitorエージェント(AMA)とLog Analyticsワークスペースを組み合わせてログを一元収集する仕組みを作るべきです。AMAをVMにインストールするだけで、syslog・カスタムログが全てLog Analyticsワークスペースに集まり、KQLクエリで横断分析できるようになります。
この記事では、Log Analyticsワークスペースの作成からAMAインストール・Data Collection Rule(DCR)の設定・KQLによるログ分析まで、azコマンドを使った実践手順をRHEL 9.4実機ログで解説します。
この記事のポイント
・Azure Monitor Agent(AMA)がLog Analyticsのログ収集の核心でAMAは無料拡張機能
・DCR(Data Collection Rule)でどのログを収集するかを宣言的に定義する
・KQLのSyslogテーブルで複数VMのログを一画面で横断検索できる
・AMAは443/TCPのアウトバウンドが通れば追加のinbound穴あけは不要
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
LinuxサーバーのログをAzureで一元管理するメリット
オンプレミスのLinux運用ではサーバーごとに /var/log/messages や /var/log/secure を直接確認するのが当たり前でした。台数が増えると、全台で grep してエラーを拾うのは現実的ではありません。Azure MonitorとLog Analyticsを使うと:
・複数VMのログを一か所に集約できる:20台のVMのsyslogを1つのワークスペースで横断検索できる
・KQLで柔軟に分析できる:「直近1時間のエラー件数をVM別に集計」などのクエリが数行で書ける
・アラートと連動できる:特定のログパターンが出た時にメール通知や自動対応を仕込める
・オンプレとAzure VMを同一ワークスペースで管理できる:ハイブリッド構成でも一元管理可能
「どこかのサーバーがエラーを吐いている気がするが、どのVMかわからない」という状況を根本的に解消できます。
Azure MonitorとLog Analyticsの仕組み
ログ収集の構成要素は3つです。・Log Analytics ワークスペース:ログの保存先。テーブル構造を持つデータベースとして機能する
・Azure Monitor Agent(AMA):Linux VMにインストールするエージェント。ログをワークスペースに送信する
・Data Collection Rule(DCR):「何を収集してどこに送るか」を定義するルール。AMAにインストール後、DCRを関連付けることで収集が始まる
旧来のLog Analytics Agent(MMA/OMS Agent)は2024年8月に廃止となり、現在のAzure標準はAMAです。『azure log analytics agent linux』で古い情報を参考にしている場合は注意してください。AMAはDCRが必須なため、エージェントを入れただけでは収集は始まりません。
| コンポーネント | 役割 | 作成場所 |
|---|---|---|
| Log Analytics ワークスペース | ログの保存・検索 | az monitor log-analytics workspace create |
| Azure Monitor Agent(AMA) | VMからログ送信 | az vm extension set |
| Data Collection Rule(DCR) | 収集対象・送信先の定義 | az monitor data-collection rule create |
事前準備:Log Analytics ワークスペースを作成する
1. リソースグループとワークスペースを作成する
まず作業用リソースグループを作成し、その中にLog Analyticsワークスペースを作ります。# リソースグループを作成(東日本リージョン) az group create \ --name rg-monitoring \ --location japaneast # Log Analyticsワークスペースを作成 az monitor log-analytics workspace create \ --resource-group rg-monitoring \ --workspace-name law-linuxmonitor \ --location japaneast \ --retention-time 30
--retention-timeはログ保持日数です。デフォルトは30日。コスト最適化のためには保持日数を必要最小限に設定します。無料の保持期間は最大31日まで(2026年時点)。2. ワークスペースのリソースIDを確認する
後DCRの送信先としてワークスペースIDが必要です。# ワークスペースのリソースIDを取得 WORKSPACE_ID=$(az monitor log-analytics workspace show \ --resource-group rg-monitoring \ --workspace-name law-linuxmonitor \ --query id \ --output tsv) echo $WORKSPACE_ID
/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-linuxmonitor
workspaceResourceId に指定する値です。Azure Monitor Agent(AMA)をLinux VMにインストールする
1. AMAインストール前の前提条件
AMAはVM拡張機能としてインストールします。以下の前提条件を満たしているか確認してください。・Managed Identity(マネージドID)が有効:AMAはManaged IdentityでAzureに認証するため、VMにシステム割り当てのManaged Identityが必要
・443/TCPアウトバウンドが許可されている:AMAはHTTPS(443/TCP)でAzureエンドポイントにログを送信します。インバウンドの穴あけは不要です。ポートの確認方法はLinuxのポート確認(ss/lsofコマンド)を参照してください
・対応オペレーティングシステム:RHEL 8.x/9.x・Ubuntu 20.04/22.04/24.04・AlmaLinux 8.x/9.xなど主要ディストリビューションが対応
# Managed Identityを有効化する az vm identity assign \ --resource-group rg-monitoring \ --name vm-rhel94 # Identity が有効か確認 az vm identity show \ --resource-group rg-monitoring \ --name vm-rhel94
{ "principalId": "aabbccdd-1234-5678-90ab-cdef01234567", "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "type": "SystemAssigned", "userAssignedIdentities": null }
type: "SystemAssigned" が表示されていれば正常です。2. azコマンドでAMAをインストールする
VM拡張機能としてAMAをインストールします。# RHEL/Rocky/AlmaLinux 系(AzureMonitorLinuxAgent) az vm extension set \ --resource-group rg-monitoring \ --vm-name vm-rhel94 \ --name AzureMonitorLinuxAgent \ --publisher Microsoft.Azure.Monitor \ --version 1.0 \ --enable-auto-upgrade true
# VM内でサービス状態を確認 $ sudo systemctl status azuremonitoragent * azuremonitoragent.service - Azure Monitor Agent Loaded: loaded (/lib/systemd/system/azuremonitoragent.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2026-06-30 10:15:22 UTC; 3min ago Main PID: 1842 (mdsd) Jun 30 10:15:22 vm-rhel94 systemd[1]: Started Azure Monitor Agent.
Active: active (running) が確認できれば、AMAのインストールは完了です。Azure上でLinuxサーバーを体系的に学ぶには、Azure対応セミナーも参考にしてください。AMAの実機ハンズオンをカバーしています。
Data Collection Rule(DCR)でログ収集対象を設定する
AMAをインストールしただけではログ収集は始まりません。「何のログを収集して、どこに送るか」をDCRで定義し、VMに関連付ける必要があります。1. DCRをJSONファイルで定義する
DCRはJSON形式のルール定義ファイルで記述します。syslogを収集してLog Analyticsワークスペースに送る最小構成の例です。# dcr-syslog.json を作成する(workspaceResourceIdは実際の値で置き換える) cat << 'JSONEOF' > /tmp/dcr-syslog.json { "location": "japaneast", "properties": { "dataSources": { "syslog": [ { "name": "syslog-datasource", "streams": ["Microsoft-Syslog"], "facilityNames": ["auth", "authpriv", "kern", "syslog"], "logLevels": ["Warning", "Error", "Critical", "Alert", "Emergency"], "sendToChannels": ["dcr-channel"] } ] }, "destinations": { "logAnalytics": [ { "workspaceResourceId": "/subscriptions/xxxx/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-linuxmonitor", "name": "dcr-channel" } ] }, "dataFlows": [ { "streams": ["Microsoft-Syslog"], "destinations": ["dcr-channel"] } ] } } JSONEOF
facilityNamesは「どのsyslogファシリティを収集するか」、logLevelsは「どの重要度以上のログを収集するか」を指定します。2. DCRを作成してVMに関連付ける
# DCRを作成する az monitor data-collection rule create \ --resource-group rg-monitoring \ --name dcr-syslog-linux \ --rule-file /tmp/dcr-syslog.json # 作成したDCRのリソースIDを取得 DCR_ID=$(az monitor data-collection rule show \ --resource-group rg-monitoring \ --name dcr-syslog-linux \ --query id \ --output tsv) # VMのリソースIDを取得 VM_ID=$(az vm show \ --resource-group rg-monitoring \ --name vm-rhel94 \ --query id \ --output tsv) # DCRをVMに関連付ける(DCR Association) az monitor data-collection rule association create \ --name dcra-vm-rhel94 \ --resource $VM_ID \ --rule-id $DCR_ID
KQLクエリでログを分析する
Log Analyticsのログ検索はKQL(Kusto Query Language)を使います。syslogはSyslogテーブルに格納されます。基本的なクエリ例を紹介します。
// 直近1時間のエラーログ一覧 Syslog | where TimeGenerated > ago(1h) | where SeverityLevel in ("err", "crit", "alert", "emerg") | project TimeGenerated, Computer, Facility, SeverityLevel, SyslogMessage | order by TimeGenerated desc
// VM別のエラー件数を集計(過去24時間) Syslog | where TimeGenerated > ago(24h) | where SeverityLevel in ("err", "crit") | summarize ErrorCount = count() by Computer | order by ErrorCount desc
// authlogから「Failed password」を抄出(不正アクセス検知) Syslog | where TimeGenerated > ago(6h) | where Facility == "authpriv" | where SyslogMessage contains "Failed password" | project TimeGenerated, Computer, SyslogMessage
TimeGenerated が正確でなくなるため、VMのchronyが正常に動いているか事前に確認しておくことをおすすめします(ntpd時刻同期設定の参考)。よくあるエラーと対処法
「AMAをインストールしたのにSyslogテーブルにデータが来ない」
最も多いトラブルです。確認順序は以下の通りです。・DCRのassociationができているか確認する:AMAインストールだけではログは来ない。DCRのVMへの関連付けが必須
・VMのManaged Identityが有効か確認する:
az vm identity showでSystemAssignedが返るか確認・443/TCPアウトバウンドが許可されているか確認する:NSGのアウトバウンドルールで443を確認
・azuremonitoragentサービスが動いているか確認する:
sudo systemctl status azuremonitoragentで確認「AMAのインストールがProvisioningFailed で失敗する」
# AMA拡張のプロビジョニング状態を確認する az vm extension show \ --resource-group rg-monitoring \ --vm-name vm-rhel94 \ --name AzureMonitorLinuxAgent \ --query provisioningState # VM内の拡張ログを確認する sudo tail -50 /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/extension.log
本記事のまとめ
| やりたいこと | コマンド・手順 |
|---|---|
| Log Analyticsワークスペースを作成する | az monitor log-analytics workspace create --resource-group RG --workspace-name NAME --location japaneast |
| VMのManaged Identityを有効化する | az vm identity assign --resource-group RG --name VM_NAME |
| AMAをインストールする | az vm extension set --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor --vm-name VM_NAME --resource-group RG |
| DCRを作成する | az monitor data-collection rule create --resource-group RG --name DCR_NAME --rule-file FILE.json |
| DCRをVMに関連付ける | az monitor data-collection rule association create --name NAME --resource VM_ID --rule-id DCR_ID |
| syslogを検索する(KQL) | Syslog | where TimeGenerated > ago(1h) | order by TimeGenerated desc |
Azure対応セミナーの詳細を見る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 前のページへ:AzureとAWS VPCのネットワーク設計を比較する|VNet・NAT・NSGとVPC・SG・IGWの対応関係をazコマンドで実践
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます