36.5.3. Fluentd

Fluentd はノードラベルセレクターに従ってノードをデプロイする DeamonSet としてデプロイされます。ノードラベルセレクターはインベントリーパラメーター openshift_logging_fluentd_nodeselector を使用して指定することができ、デフォルトは logging-infra-fluentd です。OpenShift クラスターのインストールの一環として、Fluentd ノードセレクターを永続化された ノードラベル の一覧に追加することが推奨されます。

Fluentd は journald をシステムログソースとして使用します。これらは、オペレーティングシステム、コンテナーランタイム、および OpenShift からのログメッセージです。

利用可能なコンテナーのランタイムでは、ログメッセージのソースを特定するための最小限の情報が提供されます。ログ収集およびログの正規化は、Pod が削除されてから行われるので、ラベルまたはアノテーションなどの追加のメタデータが API サーバーから取得できません。

ログコレクターがログの処理を完了する前に、特定の名前および namespace が含まれる Pod が削除された場合には、よく似た名前の Pod および namespace とログメッセージを区別する方法がなくなる可能性があります。これにより、ログがインデックス化され、Pod にデプロイしていないユーザーが所有するインデックスにアノテーションが付けられる可能性があります。

OpenShift Container Platform 3.9 以降のクリーンインストールではデフォルトのログドライバーとして json-file を使用しますが、OpenShift Container Platform 3.7 からアップグレードされた環境は既存の journald ログのドライバー設定を維持します。json-file ログドライバーの使用を推奨します。既存のログドライバー設定を json-file に変更する手順については、集計ロギングドライバーの変更 を参照してください。

Fluentd ログの表示

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

Fluentd ログの位置の設定

Fluentd は、LOGGING_FILE_PATH 環境変数に応じて、デフォルトの /var/log/fluentd/fluentd.log の指定ファイルか、またはコンソールにログを書き出します。

Fluentd ログ出力のデフォルトの位置を変更するには、デフォルトインベントリーファイル で LOGGING_FILE_PATH パラメーターを使用します。特定のファイルを指定するか、Fluentd のデフォルトの場所を使用できます。

LOGGING_FILE_PATH=console 1
LOGGING_FILE_PATH=<path-to-log/fluentd.log> 2

これらのパラメーターを変更した後に、ロギングインストーラー Playbook を再実行します。

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook [-i </path/to/inventory>] \
    playbooks/openshift-logging/config.yml

Fluentd ログローテーションの設定

現在の Fluentd ログファイルが指定されたサイズに達すると、OpenShift Container Platform は fluentd.log ログファイルの名前を自動的に変更し、新規のロギングデータを収集できるようにします。ログローテーションはデフォルトで有効にされます。

以下の例では、最大ログサイズが 1Mb で 4 つのログを保持する必要のあるクラスターのログを示しています。fluentd.log が 1Mb に達すると、OpenShift Container Platform は現在の fluentd.log.4 を削除し、Fluentd ログのそれぞれの名前を順番に変更し、新規の fluentd.log を作成します。

fluentd.log     0b
fluentd.log.1  1Mb
fluentd.log.2  1Mb
fluentd.log.3  1Mb
fluentd.log.4  1Mb

環境変数を使用して、Fluentd ログファイルのサイズおよび OpenShift Container Platform が保持する名前変更されたファイルの数を制御することができます。

以下に例を示します。

$ oc set env ds/logging-fluentd LOGGING_FILE_AGE=30 LOGGING_FILE_SIZE=1024000"

LOGGING_FILE_PATH=console を設定してログローテーションをオフにします。これにより、Fluentd はログを Fluentd のデフォルトの場所である /var/log/fluentd/fluentd.log に書き込みます。 ここでは、 oc logs -f <pod_name> コマンドを使用してそれらのログを取得できます。

$ oc set env ds/fluentd LOGGING_FILE_PATH=console

MERGE_JSON_LOG でのログの JSON 解析の無効化

デフォルトで、Fluentd はログメッセージが JSON 形式であり、そのメッセージを Elasticsearch に送信された JSON ペイロードドキュメントにマージするかどうかを判別します。

JSON 解析を使用する場合は、以下を行います。

これらの問題の一部を軽減する方法は、ログコレクターによってログを正規化する方法の設定 を参照してください。

これらの問題を回避する場合やログから JSON を解析する必要がない場合には、JSON 解析を無効にできます。

JSON 解析を無効にするには、以下を実行します。

ログコレクターによってログを正規化する方法の設定

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

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

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

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

未定義および空のフィールドの処理を設定するには、logging-fluentd daemonset を編集します。

MERGE_JSON_LOG および CDM_UNDEFINED_TO_STRING の設定

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

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

スキーマ違反やデータ破損などの ハード (hard) エラーのあるレコードについては、再試行できません。ログコレクターはエラー処理のためにレコードを送信します。最後に表示される <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 のドキュメント を参照してください。

複数行の Docker ログへの参加

Fluentd を Docker ログの部分的なフラグメントからログレコード全体を再構築するように Fluentd を設定できます。この機能は有効にすると、Fluentd は複数行の Docker ログを読み取り、それらを再作成し、データが欠落することなしにログを 1 つのレコードとして Elasticsearch に保存します。

ただし、この機能が原因でパフォーマンスの低下が発生する可能性があるため、機能はデフォルトでオフになっており、手動で有効にする必要があります。

以下の Fluentd 環境変数では、複数行の Docker ログを処理するようにクラスターロギングを設定します。

以下のコマンドで、使用されているログドライバーを確認できます。

$ docker info | grep -i log

以下のいずれかの出力が表示されます。

Logging Driver: json-file

Logging Driver: journald

複数行の Docker ログ処理をオンにするには、以下を実行します。

外部ログアグリゲーターにログを送信するための Fluentd の設定

secure-forward プラグインを使用して、デフォルトの Elasticsearch に加えてログのコピーを外部ログアグリゲーターに送信するように Fluentd を設定できます。ローカルにホストされている Fluentd による処理の後に、ログレコードをさらに処理することができます。

ロギングデプロイメントでは、外部ログアグリゲーターを設定するために、Fluentd configmap で secure-forward.conf セクションを指定します。

<store>
@type secure_forward
self_hostname pod-${HOSTNAME}
shared_key thisisasharedkey
secure yes
enable_strict_verification yes
ca_cert_path /etc/fluent/keys/your_ca_cert
ca_private_key_path /etc/fluent/keys/your_private_key
ca_private_key_passphrase passphrase
<server>
  host ose1.example.com
  port 24284
</server>
<server>
  host ose2.example.com
  port 24284
  standby
</server>
<server>
  host ose3.example.com
  port 24284
  standby
</server>
</store>

oc edit コマンドを使用して更新できます。

$ oc edit configmap/logging-fluentd

secure-forward.conf で使用される証明書を Fluentd Pod にマウントされる既存のシークレットに追加することができます。your_ca_cert と your_private_key の値は configmap/logging-fluentd の secure-forward.conf で指定されている値と一致している必要があります。

$ oc patch secrets/logging-fluentd --type=json \
  --patch "[{'op':'add','path':'/data/your_ca_cert','value':'$(base64 -w 0 /path/to/your_ca_cert.pem)'}]"
$ oc patch secrets/logging-fluentd --type=json \
  --patch "[{'op':'add','path':'/data/your_private_key','value':'$(base64 -w 0 /path/to/your_private_key.pem)'}]"

外部アグリゲーターを設定する際は、Fluentd からのメッセージを安全に受信できる必要があります。

外部アグリゲーターが別の Fluentd サーバーである場合、fluent-plugin-secure-forward プラグインがインストールされていて、それによって提供される入力プラグインを使用する必要があります。

<source>
  @type secure_forward

  self_hostname ${HOSTNAME}
  bind 0.0.0.0
  port 24284

  shared_key thisisasharedkey

  secure yes
  cert_path        /path/for/certificate/cert.pem
  private_key_path /path/for/certificate/key.pem
  private_key_passphrase secret_foo_bar_baz
</source>

fluent-plugin-secure-forward リポジトリー に fluent-plugin-secure-forward プラグインの設定方法に関する詳細の説明があります。

Fluentd から API サーバーへの接続数の削減

mux は Secure Forward のリスナーサービスです。

Fluentd でのログのスロットリング

とくに詳細なプロジェクトについては、管理者は処理される前の Fluentd によるログの読み取り速度を減速することができます。

Fluentd に対して制限する必要があるプロジェクトを指示するには、デプロイメント後に ConfigMap のスロットル設定を編集します。

$ oc edit configmap/logging-fluentd

throttle-config.yaml キーの形式は、プロジェクト名と、各ノードでのログの読み取りに必要な速度が含まれる YAML ファイルです。デフォルトはノードごとに一度に 1000 行です。以下に例を示します。

project-name:
  read_lines_limit: 50

second-project-name:
  read_lines_limit: 100

logging:
  read_lines_limit: 500

test-project:
  read_lines_limit: 10

.operations:
  read_lines_limit: 100

Fluentd に変更を加えるには、設定を変更し、Fluentd Pod を再起動して変更を適用します。Elasticsearch に変更を加えるには、まず Fluentd をスケールダウンしてから、Elasticsearch をゼロにスケールダウンする必要があります。変更を行った後、最初に Elasticsearch をスケーリングしてから、Fluentd を元の設定にスケーリングします。

Elasticsearch をゼロに調整するには、以下を実行します。

$ oc scale --replicas=0 dc/<ELASTICSEARCH_DC>

デーモンセット設定の nodeSelector がゼロに一致するように変更します。

$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector
     nodeSelector:
       logging-infra-fluentd: "true"

$ oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"nonexistlabel":"true"}}}}}'

$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector
     nodeSelector:
       "nonexistlabel: "true"

Elasticsearch のサイズをゼロから元に戻します。

$ oc scale --replicas=# dc/<ELASTICSEARCH_DC>

deamonset 設定の nodeSelector を変更して logging-infra-fluentd: "true" に戻します。

oc patch コマンドを使用して、deamonset の nodeSelector を変更します。

oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-fluentd":"true"}}}}}'

Buffer Chunk Limit の調整

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

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

Fluentd および Mux 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`
filter-pre-mux-client.conf:
  buffer_type file
  buffer_path `/var/lib/fluentd/buffer-mux-client`

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 の値は以下のようになります。