Log Analytics エージェントを使用して Syslog データ ソースを収集する
注意事項
この記事では、サービス終了 (EOL) 状態となっている Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。
Syslog は、Linux に共通のイベント ログ プロトコルです。 アプリケーションでは、ローカル コンピューターへの保存または Syslog コレクターへの配信が可能なメッセージが送信されます。 Linux 用 Log Analytics エージェントがインストールされている場合は、エージェントにメッセージを転送するローカル Syslog デーモンが構成されます。 エージェントでは Azure Monitor にメッセージが送信され、そこで対応するレコードが作成されます。
重要
レガシの Log Analytics エージェントは、2024 年 8 月 31 日の時点で非推奨となっています。 今後 Microsoft は、Log Analytics エージェントに関するすべてのサポートを提供しません。 Azure Monitor にデータを取り込むために Log Analytics エージェントを使用している場合は、今すぐ Azure Monitor エージェントに移行してください。
Note
Azure Monitor では、rsyslog または syslog-ng によって送信されたメッセージの収集がサポートされています。rsyslog は既定のデーモンです。 Syslog イベントの収集に関して、バージョン 5 の Red Hat Enterprise Linux、CentOS、Oracle Linux 版の既定の Syslog デーモン (sysklog) はサポートされません。 このバージョンの各種ディストリビューションから Syslog データを収集するには、rsyslog デーモンをインストールし、sysklog を置き換えるように構成する必要があります。
Syslog コレクターでは、次のファシリティがサポートされています。
- kern
- user
- daemon
- auth
- syslog
- lpr
- news
- uucp
- cron
- authpriv
- ftp
- local0-local7
その他のファシリティについては、Azure Monitor でカスタム ログ データ ソースを構成します。
Configure Syslog
Linux 用 Log Analytics エージェントは、構成で指定されているファシリティと重大度のイベントだけを収集します。 Azure Portal を通じて、または Linux エージェントで構成ファイルを管理することによって、Syslog を構成できます。
Azure Portal での Syslog の構成
Log Analytics ワークスペースの [エージェント構成] メニューから Syslog を構成します。 この構成は、各 Linux エージェントの構成ファイルに配信されます。
[ファシリティの追加] を選択して新しいファシリティを追加できます。 各ファシリティについて、選択した重大度のメッセージのみが収集されます。 各ファシリティで収集する重大度を選択します。 メッセージをフィルター処理するためのその他の条件を指定することはできません。
既定では、すべての構成変更はすべてのエージェントに自動的にプッシュされます。 各 Linux エージェントで Syslog を手動で構成する場合は、[下の構成をコンピューターに適用する] チェック ボックスを解除します。
Linux エージェントでの Syslog の構成
Linux クライアントに Log Analytics エージェントがインストールされている場合は、収集されるメッセージのファシリティと重大度を定義する既定の Syslog 構成ファイルがインストールされます。 このファイルを修正して、構成を変更することができます。 クライアントにインストールされている Syslog デーモンによって、構成ファイルは異なります。
Note
Syslog 構成を編集した場合、変更を有効にするには、Syslog デーモンを再起動する必要があります。
rsyslog
rsyslog の構成ファイルは、 /etc/rsyslog.d/95-omsagent.conf
にあります。 既定の内容を次の例に示します。 この例では、ローカル エージェントから送信された、すべてのファシリティの警告レベル以上の Syslog メッセージを収集します。
kern.warning @127.0.0.1:25224
user.warning @127.0.0.1:25224
daemon.warning @127.0.0.1:25224
auth.warning @127.0.0.1:25224
syslog.warning @127.0.0.1:25224
uucp.warning @127.0.0.1:25224
authpriv.warning @127.0.0.1:25224
ftp.warning @127.0.0.1:25224
cron.warning @127.0.0.1:25224
local0.warning @127.0.0.1:25224
local1.warning @127.0.0.1:25224
local2.warning @127.0.0.1:25224
local3.warning @127.0.0.1:25224
local4.warning @127.0.0.1:25224
local5.warning @127.0.0.1:25224
local6.warning @127.0.0.1:25224
local7.warning @127.0.0.1:25224
ファシリティを削除するには、構成ファイルの該当セクションを削除します。 ファシリティのエントリを変更することで、特定のファシリティで収集される重大度を制限することができます。 たとえば、ユーザー ファシリティを重大度がエラー以上のメッセージに制限するには、構成ファイルの該当行を次の例のように変更します。
user.error @127.0.0.1:25224
syslog-ng
syslog-ng の構成ファイルは、/etc/syslog-ng/syslog-ng.conf
にあります。 既定の内容をこの例に示します。 この例では、ローカル エージェントから送信された、すべてのファシリティのすべての重大度の Syslog メッセージを収集します。
#
# Warnings (except iptables) in one file:
#
destination warn { file("/var/log/warn" fsync(yes)); };
log { source(src); filter(f_warn); destination(warn); };
#OMS_Destination
destination d_oms { udp("127.0.0.1" port(25224)); };
#OMS_facility = auth
filter f_auth_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(auth); };
log { source(src); filter(f_auth_oms); destination(d_oms); };
#OMS_facility = authpriv
filter f_authpriv_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(authpriv); };
log { source(src); filter(f_authpriv_oms); destination(d_oms); };
#OMS_facility = cron
filter f_cron_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(cron); };
log { source(src); filter(f_cron_oms); destination(d_oms); };
#OMS_facility = daemon
filter f_daemon_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(daemon); };
log { source(src); filter(f_daemon_oms); destination(d_oms); };
#OMS_facility = kern
filter f_kern_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(kern); };
log { source(src); filter(f_kern_oms); destination(d_oms); };
#OMS_facility = local0
filter f_local0_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local0); };
log { source(src); filter(f_local0_oms); destination(d_oms); };
#OMS_facility = local1
filter f_local1_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local1); };
log { source(src); filter(f_local1_oms); destination(d_oms); };
#OMS_facility = mail
filter f_mail_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(mail); };
log { source(src); filter(f_mail_oms); destination(d_oms); };
#OMS_facility = syslog
filter f_syslog_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(syslog); };
log { source(src); filter(f_syslog_oms); destination(d_oms); };
#OMS_facility = user
filter f_user_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };
ファシリティを削除するには、構成ファイルの該当セクションを削除します。 リストから重大度を削除することで、特定のファシリティで収集される重大度の制限を変更することができます。 たとえば、ユーザー ファシリティをクリティカル メッセージのみのアラートに制限するには、構成ファイルの該当セクションを次の例に示されたように変更します。
#OMS_facility = user
filter f_user_oms { level(alert,crit) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };
他の Syslog ポートからデータを収集する
Log Analytics エージェントは、ポート 25224 でローカル クライアント上の Syslog メッセージを待ち受けます。 エージェントをインストールすると、既定の Syslog 構成が適用され、次の場所で見つかります。
- Rsyslog:
/etc/rsyslog.d/95-omsagent.conf
- Syslog-ng:
/etc/syslog-ng/syslog-ng.conf
2 つの構成ファイルを作成することでポート番号を変更できます: FluentD 構成ファイルと rsyslog または syslog-ng ファイル (インストールしている Syslog デーモンにより決まります)。
FluentD 構成ファイルは
/etc/opt/microsoft/omsagent/conf/omsagent.d
にある新しいファイルです。port
エントリの値をカスタム ポート番号に変更します。<source> type syslog port %SYSLOG_PORT% bind 127.0.0.1 protocol_type udp tag oms.syslog </source> <filter oms.syslog.**> type filter_syslog
rsyslog の場合、
/etc/rsyslog.d/
に新しい構成ファイルを作成し、値%SYSLOG_PORT%
をカスタム ポート番号に変更する必要があります。Note
構成ファイル
95-omsagent.conf
でこの値を変更すると、エージェントが既定の構成を適用したときに上書きされます。# OMS Syslog collection for workspace %WORKSPACE_ID% kern.warning @127.0.0.1:%SYSLOG_PORT% user.warning @127.0.0.1:%SYSLOG_PORT% daemon.warning @127.0.0.1:%SYSLOG_PORT% auth.warning @127.0.0.1:%SYSLOG_PORT%
syslog-ng 構成は次に示すサンプル構成をコピーして変更し、
/etc/syslog-ng/
にあるsyslog-ng.conf
構成ファイルの終わりに変更したカスタム設定を追加する必要があります。%WORKSPACE_ID%_oms
または%WORKSPACE_ID_OMS
の既定のラベルは使用 "しないでください"。 変更を区別するために、カスタム ラベルを定義してください。注意
構成ファイルの既定値を変更すると、エージェントで既定の構成が適用されたときに上書きされます。
filter f_custom_filter { level(warning) and facility(auth; }; destination d_custom_dest { udp("127.0.0.1" port(%SYSLOG_PORT%)); }; log { source(s_src); filter(f_custom_filter); destination(d_custom_dest); };
変更の終了後、構成の変更を適用するために Syslog と Log Analytics エージェント サービスを再起動します。
Syslog レコードのプロパティ
Syslog レコードの型は Syslog になり、次の表に示すプロパティがあります。
プロパティ | 説明 |
---|---|
Computer | イベントが収集されたコンピューター。 |
Facility | メッセージを生成したシステムの部分を定義します。 |
HostIP | メッセージを送信するシステムの IP アドレスです。 |
HostName | メッセージを送信するシステムの名前です。 |
SeverityLevel | イベントの重大度レベルです。 |
SyslogMessage | メッセージのテキストです。 |
ProcessID | メッセージを生成したプロセスの ID です。 |
EventTime | イベントが生成された日時です。 |
Syslog レコードのログ クエリ
次の表は、Syslog レコードを取得するログ クエリのさまざまな例をまとめたものです。
クエリ | 説明 |
---|---|
syslog | すべての Syslog |
Syslog | where SeverityLevel == "error" | 重大度がエラーであるすべての Syslog レコード |
Syslog | summarize AggregatedValue = count() by Computer | コンピューターごとの Syslog レコードの数 |
Syslog | summarize AggregatedValue = count() by Facility | ファシリティごとの Syslog レコードの数 |
次のステップ
- ログ クエリについて学習し、データ ソースとソリューションから収集されたデータを分析します。
- カスタム フィールドを使用して、Syslog レコードのデータを個別のフィールドに解析します。
- Linux エージェントを構成 して、他の種類のデータを収集します。