4.2.4. ログフォワーダーの高度な設定

OpenShift Logging には、Fluentd ログフォワーダーのパフォーマンスチューニングに使用できる複数の Fluentd パラメーターが含まれます。これらのパラメーターを使用すると、以下の Fluentd の動作を変更できます。

  • チャンクおよびチャンクのバッファーサイズ
  • チャンクのフラッシュ動作
  • チャンク転送の再試行動作

Fluentd は、チャンク という単一の Blob でログデータを収集します。Fluentd がチャンクを作成する際に、チャンクは ステージ にあると見なされます。ここでチャンクはデータで一杯になります。チャンクが一杯になると、Fluentd はチャンクを キュー に移動します。ここでチャンクはフラッシュされる前か、または送信先に書き込まれるまで保持されます。Fluentd は、ネットワークの問題や送信先での容量の問題などのさまざまな理由でチャンクをフラッシュできない場合があります。チャンクをフラッシュできない場合、Fluentd は設定通りにフラッシュを再試行します。

OpenShift Container Platform のデフォルトで、Fluentd は 指数関数的バックオフ 方法を使用してフラッシュを再試行します。この場合、Fluentd はフラッシュを再試行するまで待機する時間を 2 倍にします。これは、送信先への接続要求を減らすのに役立ちます。指数関数的バックオフを無効にし、代わりに 定期的な 再試行方法を使用できます。これは、指定の間隔でチャンクのフラッシュを再試行します。デフォルトで、Fluentd はチャンクのフラッシュを無限に再試行します。OpenShift Container Platform では、無限の再試行動作を変更することはできません。

これらのパラメーターは、待ち時間とスループット間のトレードオフを判断するのに役立ちます。

  • Fluentd のスループットを最適化するには、これらのパラメーターを使用して、より大きなバッファーおよびキューを設定し、フラッシュを遅延し、再試行の間隔の長く設定することで、ネットワークパケット数を減らすことができます。より大きなバッファーにはノードのファイルシステムでより多くの領域が必要になることに注意してください。
  • 待機時間が低い場合に最適化するには、パラメーターを使用してすぐにデータを送信し、バッチの蓄積を回避し、キューとバッファーが短くして、より頻繁にフラッシュおよび再試行を使用できます。

ClusterLogging カスタムリソース (CR) で以下のパラメーターを使用して、チャンクおよびフラッシュ動作を設定できます。次に、パラメーターは Fluentd で使用するために Fluentd 設定マップに自動的に追加されます。

注記

これらのパラメーターの特徴は以下の通りです。

  • ほとんどのユーザーには関連性がありません。デフォルト設定で、全般的に良いパフォーマンスが得られるはずです。
  • Fluentd 設定およびパフォーマンスに関する詳しい知識を持つ上級ユーザーのみが対象です。
  • パフォーマンスチューニングのみを目的とします。ロギングの機能面に影響を与えることはありません。

表4.1 高度な Fluentd 設定パラメーター

パラメーター説明デフォルト

chunkLimitSize

各チャンクの最大サイズ。Fluentd はこのサイズに達するとデータのチャンクへの書き込みを停止します。次に、Fluentd はチャンクをキューに送信し、新規のチャンクを開きます。

8m

totalLimitSize

ステージおよびキューの合計サイズであるバッファーの最大サイズ。バッファーサイズがこの値を超えると、Fluentd はデータのチャンクへの追加を停止し、エラーを出して失敗します。チャンクにないデータはすべて失われます。

8G

flushInterval

チャンクのフラッシュの間隔。s (秒)、m (分)、 h (時間)、または d (日) を使用できます。

1s

flushMode

フラッシュを実行する方法:

  • lazy: timekey パラメーターに基づいてチャンクをフラッシュします。timekey パラメーターを変更することはできません。
  • interval: flushInterval パラメーターに基づいてチャンクをフラッシュします。
  • immediate: データをチャンクに追加後すぐにチャンクをフラッシュします。

interval

flushThreadCount

チャンクのフラッシュを実行するスレッドの数。スレッドの数を増やすと、フラッシュのスループットが改善し、ネットワークの待機時間が非表示になります。

2

overflowAction

キューが一杯になると、チャンク動作は以下のようになります。

  • throw_exception: ログに表示される例外を発生させます。
  • block: 詳細のバッファーの問題が解決されるまでデータのチャンクを停止します。
  • drop_oldest_chunk: 新たな受信チャンクを受け入れるために最も古いチャンクをドロップします。古いチャンクの値は新しいチャンクよりも小さくなります。

block

retryMaxInterval

exponential_backoff 再試行方法の最大時間 (秒単位)。

300s

retryType

フラッシュに失敗する場合の再試行方法:

  • exponential_backoff: フラッシュの再試行の間隔を増やします。Fluentd は、retry_max_interval パラメーターに達するまで、次の試行までに待機する時間を 2 倍にします。
  • periodic: retryWait パラメーターに基づいてフラッシュを定期的に再試行します。

exponential_backoff

retryWait

次のチャンクのフラッシュまでの時間 (秒単位)。

1s

Fluentd チャンクのライフサイクルの詳細は、Fluentd ドキュメントの「Buffer Plugins」を参照してください。

手順

  1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

    $ oc edit ClusterLogging instance
  2. 以下のパラメーターを追加または変更します。

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      forwarder:
        fluentd:
          buffer:
            chunkLimitSize: 8m 1
            flushInterval: 5s 2
            flushMode: interval 3
            flushThreadCount: 3 4
            overflowAction: throw_exception 5
            retryMaxInterval: "300s" 6
            retryType: periodic 7
            retryWait: 1s 8
            totalLimitSize: 32m 9
    ...
    1
    各チャンクの最大サイズを指定してから、フラッシュ用にキューに入れます。
    2
    チャンクのフラッシュの間隔を指定します。
    3
    チャンクのフラッシュを実行する方法を指定します ( lazyinterval、または immediate)。
    4
    チャンクのフラッシュに使用するスレッドの数を指定します。
    5
    キューが一杯になる場合のチャンクの動作を指定します (throw_exceptionblock、または drop_oldest_chunk)。
    6
    exponential_backoff チャンクのフラッシュ方法について最大の間隔 (秒単位) を指定します。
    7
    チャンクのフラッシュが失敗する場合の再試行タイプ (exponential_backoff または periodic) を指定します。
    8
    次のチャンクのフラッシュまでの時間 (秒単位) を指定します。
    9
    チャンクバッファーの最大サイズを指定します。
  3. Flunentd Pod が再デプロイされていることを確認します。

    $ oc get pods -n openshift-logging
  4. 新規の値が fluentd 設定マップにあることを確認します。

    $ oc extract configmap/fluentd --confirm

    fluentd.conf の例

           <buffer>
            @type file
            path '/var/lib/fluentd/default'
            flush_mode interval
            flush_interval 5s
            flush_thread_count 3
            flush_at_shutdown true
            retry_type periodic
            retry_wait 1s
            retry_max_interval 300s
            retry_forever true
            queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32' }"
            total_limit_size "#{ENV['TOTAL_LIMIT_SIZE'] ||  8589934592 }" #32M
            chunk_limit_size "#{ENV['BUFFER_SIZE_LIMIT'] || '8m'}"
            overflow_action throw_exception
          </buffer>