Azure Monitor エージェントを使用して Syslog イベントを収集する
Syslog イベントは、データ収集ルール (DCR) で使用されるデータ ソースの 1 つです。 DCR の作成の詳細については、「Azure Monitor エージェントを使用してデータを収集する」を参照してください。 この記事では、Syslog イベントのデータ ソースの種類について詳しく説明します。
Syslog は、Linux に共通のイベント ログ プロトコルです。 Linux デバイスとアプライアンスに組み込まれている Syslog デーモンを使用して、指定した種類のローカル イベントを収集できます。 アプリケーションでは、ローカル コンピューターに格納されているか、Syslog コレクターに配信されるメッセージが送信されます。
ヒント
Azure Monitor エージェントのローカル インストールを許可しないデバイスからデータを収集するには、専用の Linux ベースのログ フォワーダーを構成します。
前提条件
- 共同作成者の権限以上がある Log Analytics ワークスペース。 Syslog イベントは、Syslog テーブルに送信されます。
- 「Azure Monitor エージェントを使用してデータを収集する」で説明されている新規または既存の DCR。
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 形式がサポートされます。
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 に書き込まれていることを確認する。
- 「操作の確認」を参照し、エージェントが動作していて、データが受信されているかどうかを確認する。
次のステップ
各項目の詳細情報