Fluentd ログの送信

流暢 は、さまざまな種類のログ入力と出力を統合するレイヤーを提供するオープンソースのデータ コレクターです。Fluentd は、複数のソースからログを収集し、データを JSON 形式で構造化できます。これにより、複数のソースと宛先にわたるログの収集、フィルタリング、バッファリング、出力などの統合ログ データ処理が可能になります。

すでに Fluentd を使用してアプリケーション ログとシステム ログを収集している場合は、次のコマンドを使用してログを LogicMonitor に転送できます。 LM ログ Fluentd プラグイン. これにより、LogicMonitor が開発した 宝石 これには、ログを LogicMonitor に送信するための具体的な手順が含まれています。

要件

• LogicMonitor アカウント名。
• A LogicMonitor API トークン ログ取り込みAPIへのすべてのリクエストを認証します。

プラグインのインストール

次のいずれかのオプションを使用して、プラグインを Fluentd インスタンスに追加します。 

• 連絡先 宝石 – ネイティブ Ruby とともに td-agent/fluentd がインストールされている場合: gem install fluent-plugin-lm-logs
•  ネイティブ td-agent/fluentd プラグインの処理: td-agent-gem install fluent-plugin-lm-logs
• または、次を追加できます out_lm.rb Fluentdプラグインディレクトリに移動します。 

プラグインの構成

このステップでは、LogicMonitor に転送するログを指定します。

カスタムを作成する fluent.conf ファイルを編集するか、既存のものを編集して、Fluentd 構成に以下を追加します。 以下にプロパティについて説明します。

# Match events tagged with "lm.**" and
# send them to LogicMonitor
<match lm.**>
    @type lm
    resource_mapping {"<event_key>": "<lm_property>"}
    company_name <lm_company_name>
    access_id <lm_access_id>
    access_key <lm_access_key>
      <buffer>
        @type memory
        flush_interval 1s
        chunk_limit_size 8m
      </buffer> 
    debug false
    compression gzip
</match>

構成プロパティ

リクエスト例

送信されるリクエストの例:

curl http://localhost:8888/lm.test -X POST -d 'json={"message":"hello LogicMonitor from fluentd", "event_key":"lm_property_value"}'

返されたイベント:

{
    "message": "hello LogicMonitor from fluentd"
}

リソースのマッピング

ログ データを生成するソースが正しい形式を使用してマッピングされていることが重要です。これにより、ログが LogicMonitor ログに送信されるときに正しく解析されます。

Fluentd イベントのソース マッピングを定義するとき、 <event_key> 着信イベントでは、次の値であるLogicMonitorリソースにマップされます。 <lm_property>.

たとえば、「hostname" フィールドを LogicMonitor プロパティに「system.hostname" を使用して：

resource_mapping {"hostname": 'system.hostname"}

LogicMonitorリソースマッピングがわかっている場合、 event_key プロパティは、指定することでオーバーライドできます _lm.resourceId 各レコードの中で。

構成例

以下は、リソース マッピングの例です。

_lm.resourceID によるマッピング

この例では、一致するすべての着信レコード lm.** フィルターを通します。 指定された _lm.resourceId マッピングは、LogicMonitorに送信される前に追加されます。

<filter lm.**>
    @type record_transformer
    <record>
_lm.resourceId { "system.aws.arn": "arn:aws:ec2:us-west-1:xxx:instance/i-xxx"}
   	tag ${tag}
    </record>
</filter>

Kubernetes ログのマッピング

Fluentd の Kubernetes ログの場合、リソース マッピングは次のステートメントで定義できます。

 resource_mapping {"kubernetes.pod_name": "auto.name"}

ログ ファイル リソースのマッピング

特定のタグが付いたログのみを LogicMonitor に送信する場合は、正規表現パターンを ** から特定のタグに変更します。 この例では、タグは「lm.service」です。

 #Tail one or more log files
<source>
  @type tail
  <parse>
    @type none
  </parse>
  path /path/to/file
  tag lm.service
</source>

# send all logs to Logicmonitor
<match **> 
  @type lm
  resource_mapping {"Computer": "system.hostname"}
  company_name LM_COMPANY_NAME
  access_id LM_ACCESS_ID
  access_key LM_ACCESS_KEY
  <buffer>
    @type memory
    flush_interval 1s
    chunk_limit_size 8MB
  </buffer> 
  debug false
</match>

ログ ファイルの解析

場合によっては、ログのファイルをテーリングすることがあります。 ここでは、フィールドにタイムスタンプ、ホスト、ログ メッセージなどが正しく入力されるように、ログ行を解析することが重要です。 次の例は、このためにソースを構成する方法を示しています。

 #Tail one or more log files
<source>
  @type tail
  <parse>
    @type none # this will send log-lines as it is without parsing
  </parse>
  path /path/to/file
  tag lm.service
</source>

Fluentd などで使用できるパーサーは多数あります。 を使用してパーサープラグインをインストールできます gem インストール fluent-plugin-lm-logs。 詳細については、 Fluentd のドキュメント.

ログ レコードの変換

ソースによって読み取られるログには、必要なすべてのメタデータが含まれていない可能性があります。 フィルタ プラグインを使用すると、ログを LogicMonitor に書き込む前に変更できます。 次のブロックを構成ファイルに追加します。 

 # records are filtered against a tag
<filter lm.filter>
  @type record_transformer
  <record>
    system.hostname "#{Socket.gethostname}"
	service "lm.demo.service"
  </record>
</filter>

さらに高度なフィルタリングを追加して、Ruby コード ブロックを次のように記述できます。 レコードトランスフォーマー. パフォーマンスを向上させるには、次を使用できます レコード修飾子。 詳細については、 Fluentd のドキュメント.

より多くの例

Fluentd は、分析のために LogicMonitor に転送できる多くの種類のログを収集するために使用できる統合ログ レイヤーを提供します。 次に、構成サンプルのその他のソースを示します。

• 一般的なログ ソースの構成例については、次を参照してください。 ログ Fluentd の例 (GitHub).
• その他の利用可能な Fluentd プラグインについては、 Fluentd のドキュメント.

パフォーマンスの調整

場合によっては、構成を微調整して、Fluentd のパフォーマンスとリソースの使用を最適化する必要があります。 たとえば、ログの入力速度がログの転送よりも速い場合、バッチが蓄積されます。 これは、バッファ構成を調整することで防ぐことができます。

バッファ プラグインは、受信ストリームを送信前に一時的に保存するために使用されます。 詳細については、「 Fluentd のドキュメント.

次のタイプのバッファ プラグインがあります。

• メモリ (buf_memory)。 メモリを使用してバッファ チャンクを格納します。
• file (buf_file)。 ファイルを使用して、バッファー チャンクをディスクに格納します。

以下の設定例では、Fluentd は 8MB (_chunk_limit_size) のログのチャンクを作成し、1 秒ごとに LogicMonitor に送信します (flush_interval)。8MB が上限であっても、チャンクのサイズが 1MB より小さい場合でも、8 秒ごとに送信されることに注意してください。

<match lm.**>
    @type lm
    company_name LM_COMPANY_NAME
    access_id LM_ACCESS_ID
    access_key LM_ACCESS_KEY
    <buffer>
        @type memory   
        flush_interval 1s
        chunk_limit_size 8MB
    </buffer> 
    debug false
</match>

着信ログのレートを調整する

ログの入力速度がログの転送よりも速い場合、バッチが蓄積されます。 メモリベースのバッファを使用すると、ログ チャンクがメモリに保持されるため、メモリ使用量が増加します。 これを防ぐために、フラッシュ用に複数の並列スレッドを使用できます。

以下の説明に従って、バッファー構成を更新します。 追加する フラッシュスレッド数 8 出力レートを 8 倍にします。 

 <match lm.**>
    @type lm
    company_name LM_COMPANY_NAME
    access_id LM_ACCESS_ID
    access_key LM_ACCESS_KEY
    <buffer>
        @type memory   
        flush_interval 1s
        chunk_limit_size 8MB
		flush_thread_count 8
    </buffer> 
    debug false
</match>

ファイルベースのバッファリングの使用

並列スレッド処理に上限があり、着信ログ レートにスパイクがある場合は、代わりにファイル ベースのバッファリングを使用できます。 これを使用するには、変更します @type メモリ 〜へ @type ファイル バッファ構成ブロックで。 これにより、I/O 操作が増加する可能性があることに注意してください。

トラブルシューティング

を設定してデバッグログを有効にします debug 「へのプロパティtrue"で fluent.conf Fluentd コンソールで追加情報を表示します。 以下では、Fluentd を使用する場合の一般的なトラブルシューティング シナリオについて説明します。 ログのトラブルシューティングの詳細については、次を参照してください。 トラブルシューティング.

td-agent ログの調査

トラブルシューティングを行うときは、td-agent の親ディレクトリ (c:\opt\td-agent など) にあるログ ファイル td-agent.log を探します。

以下は、td-agent.conf ファイルの例です。

<source>
  @type tail
  path FILE_PATH
  pos_file C:\opt\td-agent\teamaccess.pos
  tag collector.teamaccess
  <parse>
	@type none
  </parse>
</source>

<filter collector.**>
  @type record_transformer
  <record>
	#computer_name ${hostname}
	computer_name "<removed>"
  </record>
</filter>
 
<match collector.**>
  @type lm
  company_name <COMPANY_NAME>
  access_id <ACCESS_ID>
  access_key <ACCESS_KEY>
  resource_mapping {"computer_name": "system.sysname"}
 <buffer>
 	@type memory
 	flush_interval 1s
 	chunk_limit_size 8MB
  </buffer>
  debug false
</match>

詳細は、こちらを参照してください。 Fluentd のドキュメント.

複数行イベントの遅延取り込み

複数行のイベントの場合、次のログ エントリが作成されるまでログの取り込みが遅れる可能性があります。 この遅延は、Fluentd が行末に改行が追加されたときに最後の行のみを解析するために発生します。 これを修正するには、構成プロパティを追加または増やします multiline_flush_interval （秒単位）で fluent.conf.

リソース マッピングの失敗

このような場合、Fluentd は動作しているように見えますが、LogicMonitor にログが表示されません。 これは、リソース マッピングが正しくないか、欠落していることが原因である可能性があります。 

デフォルトでは 流暢-プラグイン-lm Fluentd からのログ レコードで「ホスト」と「ホスト名」を探します。 プラグインは、LogicMonitor の「system.hostname」プロパティと同じ値を持つデバイスにレコードをマップしようとします。 マッピング先のリソースは、「system.hostname」で一意に識別できる必要があります　  と同じ値を持つ 「ホスト」/「ホスト名」をログに記録します。 

以下は、ホスト/ホスト名のマッピングの例です。

例

構成：

 resource_mapping {"hostname": "system.sysname"}

結果：

 if log : { "message" : "message", "host": "55.10.10.1", "timestamp" : ..........}

ログは、プロパティによって一意に識別可能な LM のリソースに対してマップされます system.sysname = 55.10.10.1

例

デバイスを一意に識別できる複数のプロパティを使用したマッピング。

構成：

 resource_mapping {"hostname": "system.sysname", "key_in_log" : "Property_key_in_lm"}

結果：

 if log : { "message" : "message", "host": "55.10.10.1", "key_in_log": "value", "timestamp" : ..........}

ログは、プロパティ system.sysname = 55.10.10.1 および Property_key_in_lm= value によって一意に識別可能な LogicMonitor のデバイスに対してマップされます。

例

すべてのログから XNUMX つのリソースへのハードコーディングされたリソース マッピング。 リソースは、使用されるプロパティによって一意に識別できる必要があります。

構成：

 #Tail one or more log files
<source>
.....
</source>

#force resource mapping to single device with record transformer
<filter lm.**>
 @type record_transformer
    <record>
        _lm.resourceId {"system.hostname" : "11.2.3.4", "system.region" : "north-east-1",  "system.devicetype" : "8"}
        tag lm.filter
    </record>
</filter>
# send all logs to Logicmonitor
<match lm.**> 
  @type lm
  company_name LM_COMPANY_NAME
  access_id LM_ACCESS_ID
  access_key LM_ACCESS_KEY
  <buffer>
    @type memory
    flush_interval 1s
    chunk_limit_size 8MB
  </buffer> 
  debug false
</match>

結果：

タグ lm.** を持つログは、プロパティで一意に識別されるリソースにマップされます: 
システムのホスト名 = 11.2.3.4
system.region = 北東-1
システム。デバイスタイプ = 8

ファイル パスのウィンドウとワイルドカード

内部の制限により、バックスラッシュ (\) ワイルドカード (*) は、Windows のファイル パスでは機能しません。 この制限によるエラーを回避するには、スラッシュ (/) 代わりに、td-agent.conf ファイルにファイル パスを追加します。

例： …\logs\filename.*.log の代わりに …/logs/filename.*.log を使用します。

詳細は、こちらを参照してください。 Fluentd のドキュメント.