7.2. ロギングコレクターの設定
Red Hat OpenShift のロギングサブシステムは、クラスターからオペレーションとアプリケーションログを収集し、Kubernetes Pod とプロジェクトメタデータでデータを強化します。
ログコレクターの CPU およびメモリー制限を設定し、ログコレクター Pod を特定のノードに移動 できます。ログコレクターに対するサポートされるすべての変更は、ClusterLogging
カスタムリソース (CR) の spec.collection.log.fluentd
スタンザを使用して実行できます。
7.2.1. サポートされる設定
Red Hat OpenShift のロギングサブシステムを設定するためにサポートされている方法は、このドキュメントで説明されているオプションを使用して設定することです。サポートされていない他の設定は使用しないでください。設定のパラダイムが 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 に戻すまで変更を受信しません。
7.2.2. ロギングコレクター Pod の表示
Fluentd ロギングコレクター Pod およびそれらが実行されている対応するノードを表示できます。Fluentd ロギングコレクター Pod は openshift-logging
プロジェクトでのみ実行されます。
手順
-
openshift-logging
プロジェクトで以下のコマンドを実行し、Fluentd ロギングコレクター Pod とそれらの詳細を表示します。
$ oc get pods --selector component=collector -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>
7.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、メモリー制限および要求を指定します。表示される値はデフォルト値です。
7.2.4. ログフォワーダーの高度な設定
Red Hat OpenShift のロギングサブシステムには、Fluentd ログ転送のパフォーマンスを調整するために使用できる複数の Fluentd パラメーターが含まれています。これらのパラメーターを使用すると、以下の Fluentd の動作を変更できます。
- チャンクおよびチャンクのバッファーサイズ
- チャンクのフラッシュ動作
- チャンク転送の再試行動作
Fluentd は、チャンク という単一の Blob でログデータを収集します。Fluentd がチャンクを作成する際に、チャンクは ステージ にあると見なされます。ここでチャンクはデータで一杯になります。チャンクが一杯になると、Fluentd はチャンクを キュー に移動します。ここでチャンクはフラッシュされる前か、送信先に書き込まれるまで保持されます。Fluentd は、ネットワークの問題や送信先での容量の問題などのさまざまな理由でチャンクをフラッシュできない場合があります。チャンクをフラッシュできない場合、Fluentd は設定通りにフラッシュを再試行します。
OpenShift Container Platform のデフォルトで、Fluentd は 指数関数的バックオフ 方法を使用してフラッシュを再試行します。この場合、Fluentd はフラッシュを再試行するまで待機する時間を 2 倍にします。これは、送信先への接続要求を減らすのに役立ちます。指数バックオフを無効にし、代わりに 定期的な 再試行方法を使用できます。これは、指定の間隔でチャンクのフラッシュを再試行します。
これらのパラメーターは、待ち時間とスループット間のトレードオフを判断するのに役立ちます。
- 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 -l component=collector -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>
7.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: {}
コレクター Pod が再デプロイされたことを確認します。
$ oc get pods -l component=collector -n openshift-logging
関連情報