Azure Monitor エージェントを使用して Syslog イベントを収集する
注意
この記事では、間もなくサポート終了 (EOL) 状態になる Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。
Syslog は、Linux に共通のイベント ログ プロトコルです。 Linux デバイスおよびアプライアンスに組み込まれている Syslog デーモンを使用して、指定したタイプのローカル イベントを収集できます。 その後、それらのイベントを Log Analytics ワークスペースに送信させることができます。 アプリケーションでは、ローカル コンピューターへの保存または Syslog コレクターへの配信が可能なメッセージが送信されます。
Linux 用 Azure Monitor エージェントがインストールされると、データ収集ルール (DCR) で Syslog 収集が有効になっている場合に、エージェントにメッセージを転送するようにローカル Syslog デーモンが構成されます。 次に、Azure Monitor エージェントは、メッセージを Azure Monitor または Log Analytics ワークスペースに送信し、送信先で対応する Syslog レコードが Syslog テーブルに作成されます。
Syslog コレクターでは、次のファシリティがサポートされています。
- なし
- Kern
- user
- daemon
- auth
- syslog
- lpr
- news
- uucp
- ftp
- ntp
- 監査
- アラート
- mark
- local0
- local1
- local2
- local3
- local4
- local5
- local6
- local7
Azure Monitor エージェントのローカル インストールを許可しない一部の種類のデバイスの場合は、代わりに、Linux ベースの専用ログ フォワーダーにエージェントをインストールできます。 転送元のデバイスは、ローカル デーモンではなく、このフォワーダー上の Syslog デーモンに Syslog イベントを送信するように構成されている必要があります。 詳細については、「Sentinel チュートリアル」をご覧ください。
Configure Syslog
Linux 用 Azure Monitor エージェントは、構成で指定されているファシリティと重大度のイベントだけを収集します。 Azure Portal を通じて、または Linux エージェントで構成ファイルを管理することによって、Syslog を構成できます。
Azure Portal での Syslog の構成
Azure Monitor の [データ収集ルール] メニューから Syslog を構成します。 この構成は、各 Linux エージェントの構成ファイルに配信されます。
- [Add data source (データ ソースの追加)]を選択します。
- [データ ソースの種類] で、[Linux syslog] を選択します。
ファシリティごとに異なるログ レベルで Syslog イベントを収集できます。 既定では、すべての Syslog のファシリティの種類が収集されます。 たとえば、auth の種類のイベントを収集したくない場合は、auth ファシリティの [最小ログ レベル] リスト ボックスで [なし] を選択し、変更を保存します。 Syslog イベントの既定のログ レベルを変更し、ログ レベルがNOTICE 以上の優先順位のイベントのみを収集する必要がある場合は、[最小ログ レベル] リスト ボックスで [LOG_NOTICE] を選択します。
既定では、すべての構成変更は、DCR で構成されているすべてのエージェントに自動的にプッシュされます。
データ収集ルールを作成する
Log Analytics ワークスペースと同じリージョンにデータ収集ルールを作成します。 DCR は、ワークスペースに取り込まれるデータの処理方法を定義できる Azure リソースです。
Azure portal にサインインします。
Monitor を検索して開きます。
[設定] の下にある [データ収集ルール] を選択します。
［作成］ を選択します
![[作成] オプションが選択された [データ コレクション ルール] ウィンドウを示すスクリーンショット。](../../sentinel/media/forward-syslog-monitor-agent/create-data-collection-rule.png)
![[作成] オプションが選択された [データ コレクション ルール] ウィンドウを示すスクリーンショット。](../../sentinel/media/forward-syslog-monitor-agent/create-data-collection-rule.png#lightbox)
リソースを追加する
[リソースの追加] を選択します。
フィルターを使用して、ログの収集に使用したい仮想マシンを検索します。
仮想マシンを選択します。
[適用] を選択します。
[次へ: 収集と配信] を選択します。
データ ソースの追加
[Add data source (データ ソースの追加)]を選択します。
[データ ソースの種類] で、[Linux syslog] を選択します。
[最小のログ レベル] は、既定値 LOG_DEBUG のままにします。
[次へ: ターゲット] を選択します。
宛先の追加
[ターゲットの追加] を選択します。
![[宛先を追加] オプションが選択された [宛先] タブを示すスクリーンショット。](../../sentinel/media/forward-syslog-monitor-agent/create-rule-add-destination.png)
次の値を入力します。
フィールド 値 変換先の型 Azure Monitor ログ サブスクリプション 適切なサブスクリプションを選択します アカウントまたは名前空間 適切な Log Analytics ワークスペースを選択します [Add data source (データ ソースの追加)]を選択します。
確認と作成 をクリックします。
![[宛先を追加] オプションが選択された [宛先] タブを示すスクリーンショット。](../../sentinel/media/forward-syslog-monitor-agent/create-rule-add-destination.png#lightbox)
規則を作成する
- ［作成］ を選択します
- 20 分待ってから、次のセクションに進んでください。
VM に Azure Monitor エージェントがインストールされていない場合、DCR デプロイによって VM へのエージェントのインストールがトリガーされます。
Linux エージェントでの Syslog の構成
Azure Monitor エージェントが Linux マシンにインストールされると、DCR で Syslog が有効になっている場合に収集されるメッセージのファシリティと重大度を定義する既定の Syslog 構成ファイルがインストールされます。 クライアントにインストールされている Syslog デーモンによって、構成ファイルは異なります。
Rsyslog
多くの Linux ディストリビューションでは、rsyslogd デーモンは、Linux Syslog API を使用して送信されたログ メッセージの使用、格納、ルーティングの役割を担います。 Azure Monitor エージェントは、rsyslog の TCP 転送出力モジュール (omfwd) を使用して、ログ メッセージを Azure Monitor エージェントに転送します。
Azure Monitor エージェントのインストールには、次のディレクトリに配置される既定の構成ファイルが含まれています: /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/
Syslog が DCR に追加されると、これらの設定ファイルは etc/rsyslog.d システム ディレクトリにインストールされ、変更を有効にするために rsyslog が自動的に再起動されます。 これらのファイルは、出力モジュールを読み込み、定義されたルールを使用して Azure Monitor エージェント デーモンにイベントを転送するために、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")
CentOS 7.3 などの一部のレガシ システムでは、従来の転送形式を使用して 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
syslog-ng の構成ファイルは、/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);
};
Note
Azure Monitor では、rsyslog または syslog-ng によって送信されたメッセージの収集がサポートされています。rsyslog は既定のデーモンです。 Syslog イベントの収集に関して、バージョン 5 の Red Hat Enterprise Linux、CentOS、Oracle Linux 版の既定の Syslog デーモン (sysklog) はサポートされません。 このバージョンの各種ディストリビューションから Syslog データを収集するには、rsyslog デーモンをインストールし、sysklog を置き換えるように構成する必要があります。
Syslog 構成を編集した場合、変更を有効にするには、Syslog デーモンを再起動する必要があります。
前提条件
必要なもの:
- 少なくとも共同作成者権限がある Log Analytics ワークスペース。
- データ収集エンドポイント。
- ワークスペースでDCR オブジェクトを作成するためのアクセス許可。
- Syslog メッセージは RFC 標準 (RFC5424 または RFC3164) に従う必要があります
Syslog レコードのプロパティ
Syslog レコードの型は Syslog になり、次の表に示すプロパティがあります。
| プロパティ | 説明 |
|---|---|
| Computer | イベントが収集されたコンピューター。 |
| Facility | メッセージを生成したシステムの部分を定義します。 |
| HostIP | メッセージを送信するシステムの IP アドレスです。 |
| HostName | メッセージを送信するシステムの名前です。 |
| SeverityLevel | イベントの重大度レベルです。 |
| SyslogMessage | メッセージのテキストです。 |
| ProcessID | メッセージを生成したプロセスの ID です。 |
| EventTime | イベントが生成された日時です。 |
Syslog レコードのログ クエリ
次の表は、Syslog レコードを取得するログ クエリのさまざまな例をまとめたものです。
| クエリ | 説明 |
|---|---|
| syslog | すべての Syslog |
| Syslog | where SeverityLevel == "error" | 重大度がエラーであるすべての Syslog レコード |
| Syslog | where Facility == "auth" | ファシリティの種類が auth (認証) であるすべての Syslog レコード |
| Syslog | summarize AggregatedValue = count() by Facility | ファシリティごとの Syslog レコードの数 |
次のステップ
各項目の詳細情報