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

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

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

前提条件

• 共同作成者の権限以上がある Log Analytics ワークスペース。 Syslog イベントは、Syslog テーブルに送信されます。
• 「Azure Monitor エージェントを使用してデータを収集する」で説明されている新規または既存の DCR。

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

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

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

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

Destinations

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

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 が自動的に再起動されます。

次に示す既定の構成では、すべてのログ レベルのすべてのファシリティについて、ローカル エージェントから送信された 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"
queue.maxDiskSpace="1g"
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);
}; 

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

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

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

Syslog レコードのプロパティ

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

Syslog ログ クエリのサンプル

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

• すべての Syslog

    Syslog
  

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

    Syslog
    | where SeverityLevel == "error"
  

• ファシリティの種類が auto であるすべての Syslog レコード

    Syslog
    | where facility == "auth"
  

• ファシリティごとの Syslog レコードの数

    Syslog
    | summarize AggregatedValue = count() by facility
  

トラブルシューティング

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

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

次のステップ

各項目の詳細情報

• Azure Monitor エージェント
• データ収集ルール
• Azure Monitor のベスト プラクティス: コスト管理