Fluentdログの取り込みの設定| LogicMonitor

Fluentdは、さまざまなタイプのログ入力と出力の間の統合レイヤーを提供するオープンソースのデータコレクターです。すでにFluentdを使用してアプリケーションとシステムのログを収集している場合は、LM LogsFluentdプラグインを使用してログをLogicMonitorに転送できます。

LMログ用のFluentdプラグインは、次のリンクにあります。 https://github.com/logicmonitor/lm-logs-fluentd/

必須条件

LogicMonitorAPIトークンログ取り込みAPIへのすべてのリクエストを認証します。
ログ取り込みAPIに送信されるログには、「メッセージ」フィールドが含まれている必要があります。「メッセージ」なしで送信されたリクエストは受け付けられません。

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

プラグインをインストールするためのいくつかのオプションがあります。

gemを使用する場合（td-agent / fluentdがネイティブRubyとともにインストールされている場合）： gem install fluent-plugin-lm-logs
ネイティブtd-agent / fluentdプラグイン処理の場合： td-agent-gem install fluent-plugin-lm-logs

または、次を追加できます out_lm.rb Fluentdプラグインディレクトリに移動します。

プラグインの構成

カスタムを作成する fluent.conf ファイルを作成するか、既存のログを編集して、LogicMonitorに転送するログを指定します。詳細については、構成プロパティを参照してください。

# 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 5m
      </buffer> 
    debug false
    compression gzip
</match>

リクエスト例

次のリクエストを送信します。

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

イベントを返します：

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

構成プロパティ

プロパティ	製品説明
`company_name`	ターゲットURLのLogicMonitor会社名またはアカウント名： `https://<account>.logicmonitor.com`
`resource_mapping`	ログイベントのソースをLogicMonitorリソースに定義するマッピング。この場合、 `<event_key>` 着信イベントでは、の値にマップされます `<lm_property>`. 詳細と例については、を参照してください。リソースマッピング.
`access_id`	LogicMonitorAPIトークンはIDにアクセスします。 APIのみのユーザーを作成することをお勧めします。
`access_key`	LogicMonitorAPIトークンのアクセスキー。
`flush_interval`	ログのバッチをLogicMonitorに送信する前に待機する時間を秒単位で定義します。デフォルトは `60s`.
`flush_thread_count`	LogicMonitorに送信するログの並列バッチの数を定義します。デフォルトは1です。複数のスレッドを使用すると、IO /ネットワーク遅延を隠すことができますが、処理パフォーマンスは向上しません。
`debug`	ブドウやコーヒーチェリーのような甘い果実の発酵過程において、野生酵母は糖類を用いてアルコール発酵します。アルコールは酢酸菌によって更に<i> 酢酸</i>（お酢）に転化します。 `true`、Fluentdコンソールに詳細情報を記録します。
`force_encoding`	ログに無効なutf-8文字が含まれている場合は、charsetを指定します。
`compression`	着信イベントの圧縮を有効にします。現在サポートしています `gzip` エンコーディング。

リソースマッピング

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

たとえば、マップすることができます hostname LogicMonitorプロパティへのログイベントのフィールド system.hostname を使用して：

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

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

例1

この例では、一致するすべての着信レコード 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>

例2

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

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

流暢な例

Fluentdは統合ログレイヤーを提供するため、Fluentdを使用してさまざまなタイプのログを収集し、それらをLogicMonitorに転送して分析することができます。

Fluentdプラグインを使用してWindowsイベントログ、Apacheアクセスログなどを送信するための構成例を次の場所に提供します。 https://github.com/logicmonitor/lm-logs-fluentd/tree/master/Examples

性能チューニング

バッファー構成ブロックを編集することで、Fluentdのパフォーマンスを最適化できます。

たとえば、ログの入力速度がログの転送よりも速い場合、バッチは累積されます。これを修正するには、flush_thread_countを増やして、出力をLogicMonitorに並列化します。

<buffer>
@type memory
flush_interval 1s
chunk_limit_size 8m
flush_thread_count 8
<buffer>

トラブルシューティング

を設定してデバッグログを有効にします debug 「へのプロパティtrue"で fluent.conf Fluentdコンソールで追加情報を表示します。

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

見ますトラブルシューティング詳細については、ガイドを参照してください。

製品ドキュメント

Fluentdログの取り込みの設定