次の方法で共有


Azure Monitor エージェントを使用して Syslog イベントを収集する

Syslog イベントは、データ収集ルール (DCR) で使用されるデータ ソースの 1 つです。 DCR の作成の詳細については、「Azure Monitor エージェントを使用してデータを収集する」を参照してください。 この記事では、Syslog イベントのデータ ソースの種類について詳しく説明します。

Syslog は、Linux に共通のイベント ログ プロトコルです。 Linux デバイスとアプライアンスに組み込まれている Syslog デーモンを使用して、指定した種類のローカル イベントを収集できます。 アプリケーションでは、ローカル コンピューターに格納されているか、Syslog コレクターに配信されるメッセージが送信されます。

ヒント

Azure Monitor エージェントのローカル インストールを許可しないデバイスからデータを収集するには、専用の Linux ベースのログ フォワーダーを構成します。

前提条件

Syslog データの収集を構成する

DCR の [収集と配信] ステップで、[データ ソースの種類] ドロップダウンから [Linux Syslog] を選択します。

Syslog コレクターでは、次のファシリティがサポートされています。

優先度インデックス番号 優先名
{なし} 優先度なし
0 Kern
1 ユーザー
2 メール
3 daemon
4 auth
5 syslog
6 lpr
7 news
8 uucp
9 cron
10 authpriv
11 ftp
12 ntp
13 監査
14 アラート
15 clock
16 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7

データ ソースの種類と最小ログ レベルを選択するページを示すスクリーンショット。

既定では、エージェントは、Syslog 構成によって送信されるすべてのイベントを収集します。 各ファシリティの [最小ログ レベル] を変更して、データ収集を制限します。 [NONE] を選択すると、特定のファシリティのイベントが収集されません。

Destinations

Syslog データは、次の場所に送信できます。

宛先 テーブル / 名前空間
Log Analytics ワークスペース Syslog

Note

Azure Monitor Linux Agent バージョン 1.15.2 以上では、Cisco Meraki、Cisco ASA、Cisco FTD、Sophos XG、Juniper Networks、Corelight Zeek、CipherTrust、NXLog、McAfee および Common Event Format (CEF) などの syslog RFC 形式がサポートされます。

データ収集ルールの Azure Monitor ログの宛先の構成を示すスクリーンショット。

Linux エージェントでの Syslog の構成

Azure Monitor エージェントが Linux マシンにインストールされると、DCR で Syslog が有効になっている場合に収集されるメッセージのファシリティと重大度を定義する既定の Syslog 構成ファイルがインストールされます。 クライアントにインストールされている Syslog デーモンによって、構成ファイルは異なります。

Rsyslog

多くの Linux ディストリビューションでは、rsyslogd デーモンは、Linux Syslog API を使用して送信されたログ メッセージの使用、格納、ルーティングの役割を担います。 Azure Monitor エージェントでは、rsyslog の TCP 転送出力モジュール (omfwd) を使用して、ログ メッセージを転送します。

Azure Monitor エージェントのインストールには、/etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/ にある既定の構成ファイルが含まれています。 Syslog が DCR に追加されると、この構成は etc/rsyslog.d システム ディレクトリにインストールされ、変更を有効にするために rsyslog が自動的に再起動されます。

Note

rsyslog ベースのシステムでは、Azure Monitor Linux Agent は、rsyslog 構成で定義されている既定のルールセットに転送ルールを追加します。 複数のルールセットが使用されている場合、既定以外のルールセットにバインドされた入力は Azure Monitor Agent に転送されません。 rsyslog での複数のルールセットの詳細については、公式ドキュメントを参照してください。

次に示す既定の構成では、すべてのログ レベルのすべてのファシリティについて、ローカル エージェントから送信された Syslog メッセージを収集します。

$ cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent

template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%")
# queue.workerThreads sets the maximum worker threads, it will scale back to 0 if there is no activity
# Forwarding all events through TCP port
*.* action(type="omfwd"
template="AMA_RSYSLOG_TraditionalForwardFormat"
queue.type="LinkedList"
queue.filename="omfwd-azuremonitoragent"
queue.maxFileSize="32m"
action.resumeRetryCount="-1"
action.resumeInterval="5"
action.reportSuspension="on"
action.reportSuspensionContinuation="on"
queue.size="25000"
queue.workerThreads="100"
queue.dequeueBatchSize="2048"
queue.saveonshutdown="on"
target="127.0.0.1" Port="28330" Protocol="tcp")

SELinux を使用し、Unix ソケットを使うことにした場合は、次の構成が使用されます。

$ cat /etc/rsyslog.d/10-azuremonitoragent.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent
$OMUxSockSocket /run/azuremonitoragent/default_syslog.socket
template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%") 
$OMUxSockDefaultTemplate AMA_RSYSLOG_TraditionalForwardFormat
# Forwarding all events through Unix Domain Socket
*.* :omuxsock: 
$ cat /etc/rsyslog.d/05-azuremonitoragent-loadomuxsock.conf
# Azure Monitor Agent configuration: load rsyslog forwarding module. 
$ModLoad omuxsock

一部のレガシ システムでは、従来の転送形式を使用して Syslog イベントを Azure Monitor エージェントに送信すると、rsyslog ログの形式に関する問題が発生する場合があります。 これらのシステムの場合、Azure Monitor エージェントは代わりに従来のフォワーダー テンプレートを自動的に配置します。

template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%\n")

Syslog-ng

Azure Monitor エージェントのインストールには、/etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf にある既定の構成ファイルが含まれています。 Syslog が DCR に追加されると、この構成は /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf システム ディレクトリにインストールされ、変更を有効にするために syslog-ng が自動的に再起動されます。

既定の内容を次の例に示します。 この例では、ローカル エージェントから送信された、すべてのファシリティのすべての重大度の Syslog メッセージを収集します。

$ cat /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf 
# Azure MDSD configuration: syslog forwarding config for mdsd agent
options {};

# during install time, we detect if s_src exist, if it does then we
# replace it by appropriate source name like in redhat 's_sys'
# Forwrding using tcp
destination d_azure_mdsd {
	network("127.0.0.1" 
	port(28330)
	log-fifo-size(25000));			
};

log {
	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf
	destination(d_azure_mdsd);
	flags(flow-control);
};

SELinux を使用し、Unix ソケットを使うことにした場合は、次の構成が使用されます。

$ cat /etc/syslog-ng/conf.d/azuremonitoragent.conf 
# Azure MDSD configuration: syslog forwarding config for mdsd agent options {}; 
# during install time, we detect if s_src exist, if it does then we 
# replace it by appropriate source name like in redhat 's_sys' 
# Forwrding using unix domain socket 
destination d_azure_mdsd { 
	unix-dgram("/run/azuremonitoragent/default_syslog.socket" 
	flags(no_multi_line) ); 
};
 
log {
	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf 
	destination(d_azure_mdsd);
}; 

Note

Azure Monitor では、rsyslog または syslog-ng によって送信されたメッセージの収集がサポートされています。rsyslog は既定のデーモンです。 Syslog イベントの収集に関して、バージョン 5 の Red Hat Enterprise Linux と Oracle Linux 版の既定の Syslog デーモン (sysklog) はサポートされません。 このバージョンの各種ディストリビューションから Syslog データを収集するには、rsyslog デーモンをインストールし、sysklog を置き換えるように構成する必要があります。

Syslog 構成を編集した場合、変更を有効にするには、Syslog デーモンを再起動する必要があります。

サポートされるファシリティ

Syslog コレクターでは、次のファシリティがサポートされています。

初期インデックス 初期名
0 なし
1 Kern
2 ユーザー
3 メール
4 daemon
4 auth
5 syslog
6 lpr
7 news
8 uucp
9 ftp
10 ntp
11 監査
12 アラート
13 mark
14 local0
15 local1
16 local2
17 local3
18 local4
19 local5
20 local6
21 local7

Syslog レコードのプロパティ

Syslog レコードの型は Syslog になり、次の表に示すプロパティがあります。

プロパティ 説明
Computer イベントが収集されたコンピューター。
Facility メッセージを生成したシステムの部分を定義します。
HostIP メッセージを送信するシステムの IP アドレスです。
HostName メッセージを送信するシステムの名前です。
SeverityLevel イベントの重大度レベルです。
SyslogMessage メッセージのテキストです。
ProcessID メッセージを生成したプロセスの ID です。
EventTime イベントが生成された日時です。

Syslog ログ クエリのサンプル

次の表は、Syslog レコードを取得するログ クエリのさまざまな例をまとめたものです。

  • すべての Syslog

      Syslog
    
  • 重大度がエラーであるすべての Syslog レコード

      Syslog
      | where SeverityLevel == "error"
    
  • ファシリティの種類が auto であるすべての Syslog レコード

      Syslog
      | where facility == "auth"
    
  • ファシリティごとの Syslog レコードの数

      Syslog
      | summarize AggregatedValue = count() by facility
    

トラブルシューティング

想定している JSON ログからデータを収集しない場合は、次の手順を行います。

  • データが Syslog に書き込まれていることを確認する。
  • 操作の確認」を参照し、エージェントが動作していて、データが受信されているかどうかを確認する。

次のステップ

各項目の詳細情報