アップストリーム Fluentd の構成の互換性

Logging エージェントからアップストリームの Fluentd に移行する際に、構成の非互換性が発生し、起動エラーを回避するために回避策が必要になることがあります。このドキュメントでは、構成の非互換性を解決する方法について説明します。

以前の Logging エージェントとアップストリーム Fluentd の構文の変更

以前の Logging エージェントは Fluentd v0.12 構文に依存していますが、アップストリームの Fluentd は v1 標準を採用しています。この移行では、さまざまなパラメータが非推奨となり、以前使用されていたフラットな構成構造に代わって、コア機能を処理するための新しいネストされたディレクティブが導入されます。

重要: 同じプラグイン ディレクティブ内で v0.12 と v1 の構文を混在させないようにする必要があります。スタイルを混在させると、Fluentd は v0.12 パラメータを無視し、データ損失が発生する可能性があります。

起動の失敗を防ぎ、ログが正しく処理されるようにするには、非推奨のパラメータを削除または置き換える必要があります。以降のセクションでは、非推奨のパラメータを更新する方法について説明します。

出力プラグインの構成

次の表に、エラーを回避するために出力プラグインの構成で更新する必要があるパラメータを示します。

以前の Logging エージェントの構文	アップストリーム Fluentd の構文	メモ
なし	<buffer>	Fluentd 出力プラグインは、<match> セクションの下に <buffer> セクションをサポートし、イベントのバッファリングを構成します。詳細については、Fluentd のドキュメントの Config: Buffer Section をご覧ください。
buffer_type	@type
buffer_path	path
buffer_chunk_limit	chunk_limit_size
disable_retry_limit	retry_forever
retry_limit	retry_max_times
max_retry_wait	retry_max_interval
num_threads	flush_thread_count
partial_success	なし	このパラメータを削除します。アップストリームの Fluentd では、デフォルトで部分的な成功が永続的に有効になり、無効な行のみがドロップされます。

以下は、以前の Logging エージェントの google-cloud 出力プラグイン構成の例です。

<match **>
  @type google_cloud
  buffer_type file
  buffer_path /var/log/google-fluentd/buffers
  buffer_chunk_limit 512KB
  flush_interval 5s
  disable_retry_limit false
  retry_limit 3
  retry_wait 10
  max_retry_wait 300
  num_threads 8
</match>

更新後の構成は次のようになります。

<match **>
  @type google_cloud
  <buffer>
    @type file
    path /var/log/google-fluentd/buffers
    chunk_limit 512KB
    flush_interval 5s
    retry_forever false
    retry_max_times 3
    retry_wait 10
    retry_max_interval 300
    flush_thread_count 8
  </buffer>
</match>

入力プラグインの構成

次の表に、エラーを回避するために入力プラグインの構成で更新する必要があるパラメータを示します。

以前の Logging エージェントの構文	アップストリーム Fluentd の構文	メモ
format	<parse>	詳細については、構成: 解析セクションの Fluentd ドキュメントをご覧ください。
protocol_type	<transport>	syslog 転送のプロトコル（udp、tcp,、tls のいずれか）を示します。
auto_typecast		json 解析プラグイン内で使用する場合は、このパラメータを削除します。

以下は、以前の Logging エージェントの入力プラグイン構成の例です。

<source>
    @type tail
    path /var/log/my-app.log
    format json
</source>

更新後の構成は次のようになります。

<source>
    @type tail
    path /var/log/my-app.log
    <parse>
      @type json
    </parse>
</source>

Ruby Time オブジェクトのシリアル化

アップストリームの Fluentd では、<record> フィルタ内で使用される未加工の Ruby Time オブジェクト（record_transformer など）の明示的なキャストが必要です。明示的なキャストがないと、これらのオブジェクトが原因でバッファ フラッシュ中に致命的なシリアル化エラーが発生します。

構成で enable_ruby true を含む ${time} を使用している場合は、オブジェクトをプリミティブ型（整数または文字列）に明示的にキャストする必要があります。

以下に、以前の Logging エージェントのフィルタ プラグイン構成の例を示します。

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time}
  </record>
</filter>

更新後の構成は次のようになります。

<filter foo.bar>
  @type record_transformer
   enable_ruby true
  <record>
    raw_timestamp ${time.to_i}
  </record>
</filter>

gRPC トランスポートと圧縮のデフォルト設定

google_cloud 出力プラグインを使用すると、Cloud Logging API との通信で REST/JSON の代わりに gRPC を使用するかどうかを構成できます。

パフォーマンスを向上させるには、gRPC トランスポートを有効にして grpc_compression_algorithm gzip を構成することをおすすめします。この組み合わせにより、特に大量のログを処理する場合に、ネットワーク オーバーヘッドと CPU 使用率を最小限に抑えることができます。

これらの最適化を実装するには、次の構成を使用します。

<match **>
  @type google_cloud
  use_grpc true
  grpc_compression_algorithm gzip
</match>

また、gRPC はポート 443 の HTTP/2 ストリーミングに依存しているため、ネットワーク インフラストラクチャで gRPC/HTTP/2 トラフィックが許可されていることを確認する必要があります。gRPC が制限されている環境では、標準の HTTP/REST 通信に戻すために use_grpc false を明示的に定義する必要があります。

RabbitMQ の正規表現パターン

以前の Logging エージェントが RabbitMQ ログの取り込みに使用する正規表現パターンは、最新の RabbitMQ バージョンの出力形式と互換性がないことがよくあります。このような不一致があると、ログが誤って処理されたり、収集プロセス中にサイレントに破棄されたりする可能性があります。

最新の RabbitMQ ログには、YYYY-MM-DD HH:MM:SS.L などのタイムスタンプにミリ秒単位の精度が組み込まれており、[info] <0.213.0> などの特定の重大度と PID マーカーが含まれています。以前の正規表現では、これらのマーカーを照合できませんでした。

Fluentd エージェントが RabbitMQ ログを収集するように構成されている場合は、現在のログ形式を正しく処理するように <parser> セクションを更新する必要があります。

以下は、以前の Logging エージェントの RabbitMQ 入力プラグイン構成の例です。

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/lib/google-fluentd/pos/rabbitmq.pos
  tag rabbitmq
  format multiline
  format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/
  format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(?<severity>\w+)\] (?<message>.*)/
  time_format %Y-%m-%d %H:%M:%S
</source>

更新後の構成は次のようになります。

<source>
  @type tail
  path /var/log/rabbitmq/*.log
  pos_file /var/log/fluentd/pos/rabbitmq.pos
  read_from_head true
  tag rabbitmq
  <parse>
    @type multiline
    format_firstline /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}/
    format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) \[(?<severity>[^\]]+)\] <(?<pid>[^>]+)> (?m:(?<message>.*))$/
    time_format %Y-%m-%d %H:%M:%S.%L
  </parse>
</source>