4.2. ロギングコレクターの設定
OpenShift Container Platform は Fluentd を使用して、クラスターから操作およびアプリケーションログを収集し、Kubernetes Pod およびプロジェクトメタデータでデータを拡充します。
ログコレクターの CPU およびメモリー制限を設定し、ログコレクター Pod を特定のノードに移動 できます。ログコレクターに対するサポートされるすべての変更は、ClusterLogging
カスタムリソース (CR) の spec.collection.log.fluentd
スタンザを使用して実行できます。
4.2.1. サポートされる設定
OpenShift Logging の設定のサポートされる方法として、本書で説明されているオプションを使用してこれを設定することができます。サポートされていない他の設定は使用しないでください。設定のパラダイムが OpenShift Container Platform リリース間で変更される可能性があり、このような変更は、設定のすべての可能性が制御されている場合のみ適切に対応できます。本書で説明されている設定以外の設定を使用する場合、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator が差分を調整するため、変更内容は失われます。Operator はデフォルトで定義された状態にすべて戻します。
OpenShift Container Platform ドキュメントで説明されていない設定を実行する 必要がある 場合、Red Hat OpenShift Logging Operator または OpenShift Elasticsearch Operator を Unmanaged (管理外) に設定する 必要があります。管理外の OpenShift Logging 環境は サポート外 であり、OpenShift Logging を Managed に戻すまで変更を受信しません。
4.2.2. ロギングコレクター Pod の表示
Fluentd ロギングコレクター Pod およびそれらが実行されている対応するノードを表示できます。Fluentd ロギングコレクター Pod は openshift-logging
プロジェクトでのみ実行されます。
手順
-
openshift-logging
プロジェクトで以下のコマンドを実行し、Fluentd ロギングコレクター Pod とそれらの詳細を表示します。
$ oc get pods --selector component=fluentd -o wide -n openshift-logging
出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES fluentd-8d69v 1/1 Running 0 134m 10.130.2.30 master1.example.com <none> <none> fluentd-bd225 1/1 Running 0 134m 10.131.1.11 master2.example.com <none> <none> fluentd-cvrzs 1/1 Running 0 134m 10.130.0.21 master3.example.com <none> <none> fluentd-gpqg2 1/1 Running 0 134m 10.128.2.27 worker1.example.com <none> <none> fluentd-l9j7j 1/1 Running 0 134m 10.129.2.31 worker2.example.com <none> <none>
4.2.3. ログコレクター CPU およびメモリー制限の設定
ログコレクターは、CPU とメモリー制限の両方への調整を許可します。
手順
openshift-logging
プロジェクトでClusterLogging
カスタムリソース (CR) を編集します。$ oc -n openshift-logging edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: openshift-logging ... spec: collection: logs: fluentd: resources: limits: 1 memory: 736Mi requests: cpu: 100m memory: 736Mi
- 1
- 必要に応じて CPU、メモリー制限および要求を指定します。表示される値はデフォルト値です。
4.2.4. ログフォワーダーの高度な設定
OpenShift Logging には、Fluentd ログフォワーダーのパフォーマンスチューニングに使用できる複数の Fluentd パラメーターが含まれます。これらのパラメーターを使用すると、以下の Fluentd の動作を変更できます。
- 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 設定およびパフォーマンスに関する詳しい知識を持つ上級ユーザーのみが対象です。
- パフォーマンスチューニングのみを目的とします。ロギングの機能面に影響を与えることはありません。
パラメーター | 説明 | デフォルト |
---|---|---|
| 各チャンクの最大サイズ。Fluentd はこのサイズに達するとデータのチャンクへの書き込みを停止します。次に、Fluentd はチャンクをキューに送信し、新規のチャンクを開きます。 |
|
| ステージおよびキューの合計サイズであるバッファーの最大サイズ。バッファーサイズがこの値を超えると、Fluentd はデータのチャンクへの追加を停止し、エラーを出して失敗します。チャンクにないデータはすべて失われます。 |
|
|
チャンクのフラッシュの間隔。 |
|
| フラッシュを実行する方法:
|
|
| チャンクのフラッシュを実行するスレッドの数。スレッドの数を増やすと、フラッシュのスループットが改善し、ネットワークの待機時間が非表示になります。 |
|
| キューが一杯になると、チャンク動作は以下のようになります。
|
|
|
|
|
| フラッシュに失敗する場合の再試行方法:
|
|
| 次のチャンクのフラッシュまでの時間 (秒単位)。 |
|
Fluentd チャンクのライフサイクルの詳細は、Fluentd ドキュメントの Buffer Plugins を参照してください。
手順
openshift-logging
プロジェクトでClusterLogging
カスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
以下のパラメーターを追加または変更します。
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
- チャンクのフラッシュを実行する方法を指定します (
lazy
、interval
、またはimmediate
)。 - 4
- チャンクのフラッシュに使用するスレッドの数を指定します。
- 5
- キューが一杯になる場合のチャンクの動作を指定します (
throw_exception
、block
、またはdrop_oldest_chunk
)。 - 6
exponential_backoff
チャンクのフラッシュ方法について最大の間隔 (秒単位) を指定します。- 7
- チャンクのフラッシュが失敗する場合の再試行タイプ (
exponential_backoff
またはperiodic
) を指定します。 - 8
- 次のチャンクのフラッシュまでの時間 (秒単位) を指定します。
- 9
- チャンクバッファーの最大サイズを指定します。
Flunentd Pod が再デプロイされていることを確認します。
$ oc get pods -n openshift-logging
新規の値が
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 retry_type periodic retry_wait 1s retry_max_interval 300s retry_timeout 60m queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}" total_limit_size 32m chunk_limit_size 8m overflow_action throw_exception </buffer>
4.2.5. デフォルトの Elasticsearch ログストアを使用しない場合の未使用のコンポーネントの削除
管理者がログをサードパーティーのログストアに転送し、デフォルトの Elasticsearch ログストアを使用しない場合には、ロギングクラスターからいくつかの未使用のコンポーネントを削除できます。
つまり、デフォルトの Elasticsearch ログストアを使用しない場合、内部 Elasticsearch logStore
、Kibana visualization
コンポーネントを ClusterLogging
カスタムリソース (CR) から削除することができます。これらのコンポーネントの削除はオプションですが、これによりリソースを節約できます。
前提条件
ログフォワーダーがログデータをデフォルトの内部 Elasticsearch クラスターに送信しないことを確認します。ログ転送の設定に使用した
ClusterLogForwarder
CR YAML ファイルを検査します。これにはdefault
を指定するoutputRefs
要素が ない ことを確認します。以下に例を示します。outputRefs: - default
ClusterLogForwarder
CR がログデータを内部 Elasticsearch クラスターに転送し、ClusterLogging
CR から logStore
コンポーネントを削除するとします。この場合、内部 Elasticsearch クラスターはログデータを保存するために表示されません。これがないと、データが失われる可能性があります。
手順
openshift-logging
プロジェクトでClusterLogging
カスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
-
これらが存在する場合、
logStore
、visualization
スタンザをClusterLogging
CR から削除します。 ClusterLogging
CR のcollection
スタンザを保持します。結果は以下の例のようになります。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" collection: logs: type: "fluentd" fluentd: {}
Flunentd Pod が再デプロイされていることを確認します。
$ oc get pods -n openshift-logging
関連情報