6.7. Fluentd の設定

oc get pods -o wide コマンドを使用して、Fluentd Pod がデプロイされるノードを表示できます。

$ oc get pods -o wide | grep fluentd

NAME                         READY     STATUS    RESTARTS   AGE     IP            NODE                           NOMINATED NODE
fluentd-5mr28                1/1       Running   0          4m56s   10.129.2.12   ip-10-0-164-233.ec2.internal   <none>
fluentd-cnc4c                1/1       Running   0          4m56s   10.128.2.13   ip-10-0-155-142.ec2.internal   <none>
fluentd-nlp8z                1/1       Running   0          4m56s   10.131.0.13   ip-10-0-138-77.ec2.internal    <none>
fluentd-rknlk                1/1       Running   0          4m56s   10.128.0.33   ip-10-0-128-130.ec2.internal   <none>
fluentd-rsm49                1/1       Running   0          4m56s   10.129.0.37   ip-10-0-163-191.ec2.internal   <none>
fluentd-wjt8s                1/1       Running   0          4m56s   10.130.0.42   ip-10-0-156-251.ec2.internal   <none>

ログの表示方法は、LOGGING_FILE_PATH の設定によって異なります。

それぞれのコンポーネント仕様は、CPU とメモリーの両方への調整を許可します。

Fluentd は、LOGGING_FILE_PATH 環境変数に応じて、指定されたファイルか、またはデフォルトの場所の /var/log/fluentd/fluentd.log にログを書き込みます。

とくに詳細なプロジェクトについては、管理者は処理される前の Fluentd によるログの読み取り速度を減速することができます。スロットリングによってログの読み取り速度が遅くなり、Kibana がレコードを表示するのにより長い時間がかかる可能性があります。

throttle-config.yaml: |
  - opensift-logging:
      read_lines_limit: 10
  - .operations:
      read_lines_limit: 100

Fluentd ロガーが多数のログを処理できない場合、メモリーの使用量を減らし、データ損失を防ぐためにファイルバッファリングに切り換える必要があります。

Fluentd ファイルバッファリングは、記録を chunks に保管します。チャンクは buffers に保管されます。

Fluentd buffer_chunk_limit は、デフォルト値が 8m の環境変数 BUFFER_SIZE_LIMIT によって決定されます。出力ごとのファイルのバッファーサイズは、デフォルト値が 256Mi の環境変数 FILE_BUFFER_LIMIT によって決定されます。永続的なボリュームサイズは、FILE_BUFFER_LIMIT に出力を乗算した結果よりも大きくなければなりません。

Fluentd Pod では、永続ボリューム /var/lib/fluentd は PVC または hostmount などによって作成する必要があります。その領域はファイルバッファーに使用されます。

buffer_type および buffer_path は、以下のように Fluentd 設定ファイルで設定されます。

$ egrep "buffer_type|buffer_path" *.conf
output-es-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-config`
output-es-ops-config.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-output-es-ops-config`

Fluentd buffer_queue_limit は変数 BUFFER_QUEUE_LIMIT の値です。この値はデフォルトで 32 になります。

環境変数 BUFFER_QUEUE_LIMIT は (FILE_BUFFER_LIMIT / (number_of_outputs * BUFFER_SIZE_LIMIT)) として計算されます。

BUFFER_QUEUE_LIMIT 変数にデフォルトの値のセットが含まれる場合、以下のようになります。

buffer_queue_limit の値は 32 になります。buffer_queue_limit を変更するには、FILE_BUFFER_LIMIT の値を変更する必要があります。

この数式では、number_of_outputs は、すべてのログが単一リソースに送信され、追加のリソースごとに 1 つずつ増分する場合に 1 になります。たとえば、number_of_outputs の値は以下のようになります。

Fluentd を、メッセージが JSON 形式であるかどうかを判別するために各ログメッセージを検査し、そのメッセージを Elasticsearch に送信された JSON ペイロードドキュメントにマージできるよう設定します。この機能はデフォルトでは無効にされています。

この機能は、fluentd daemonset で MERGE_JSON_LOG 環境変数を編集することによって有効にしたり、無効にしたりできます。

oc set env ds/fluentd MERGE_JSON_LOG=true 1

MERGE_JSON_LOG および CDM_UNDEFINED_TO_STRING の設定

MERGE_JSON_LOG および CDM_UNDEFINED_TO_STRING 環境変数を true に設定する場合、Elasticsearch 400 エラーを受信する可能性があります。このエラーは、`MERGE_JSON_LOG=true` の場合に Fluentd がフィールドに 文字列 以外のデータタイプを追加するために発生します。CDM_UNDEFINED_TO_STRING=true を設定する場合、Fluentd はそれらのフィールドに 文字列 の値を追加することを試行し、これにより Elasticsearch 400 エラーが生じます。このエラーはインデックスが翌日にロールオーバーされるとクリアされます。

Fluentd が次の日のログのインデックスをロールオーバーする場合、全く新しいインデックスが作成されます。フィールドの定義は更新され、400 エラーは発生しません。

スキーマ違反やデータ破損などの ハード (hard) エラーのあるレコードについては、再試行できません。Fluent はエラー処理のためにレコードを送信します。最後に表示される <label> のように Fluentd 設定に <label @ERROR> セクションを追加 する場合、それらのレコードを随時処理することができます。

例:

data:
  fluent.conf:

....

    <label @ERROR>
      <match **>
        @type file
        path /var/log/fluent/dlq
        time_slice_format %Y%m%d
        time_slice_wait 10m
        time_format %Y%m%dT%H%M%S%z
        compress gzip
      </match>
    </label>

このセクションではエラーレコードを Elasticsearch dead letter queue (DLQ) ファイル に書き込みます。ファイル出力についての詳細は fluentd のドキュメント を参照してください。

次に、レコードを手動でクリーンアップし、ファイルを Elasticsearch /_bulk index API で使用し、cURL を使用してそれらのレコードを追加できるようにファイルを編集することができます。Elasticsearch Bulk API についての詳細は Elasticsearch のドキュメント を参照してください。

クラスターロギングは、データベーススキーマなどの特定のデータモデルを使用して、ログレコードとそのメタデータをロギングストアに格納します。このデータについてはいくつかの制限があります。

これらの要件により、異なるサブシステムから収集されるログデータで競合や不整合が生じる場合があります。

たとえば、MERGE_JSON_LOG 機能 (MERGE_JSON_LOG=true) を使用する場合、アプリケーションの出力のログを JSON で記録し、ログコレクターが Elasticsearch 内でデータを自動的に解析し、インデックス化すると非常に便利です。ただし、これにより、以下のような問題が発生します。

以下の表で、Fluentd ログコレクターの daemonset、Fluentd または Rsyslog を編集し、環境変数を設定することで、クラスターロギングが異種ソースからフィールドを処理する方法を設定できます。

環境変数を使用して Fluentd 設定を変更することができます。

oc set env ds/fluentd <env-var>=<value>

例:

oc set env ds/fluentd LOGGING_FILE_AGE=30