This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.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
$ oc get pods --selector component=collector -o wide -n openshift-logging出力例
7.2.3. ログコレクター CPU およびメモリー制限の設定
ログコレクターは、CPU とメモリー制限の両方への調整を許可します。
手順
- openshift-loggingプロジェクトで- ClusterLoggingカスタムリソース (CR) を編集します。- oc -n openshift-logging edit ClusterLogging instance - $ oc -n openshift-logging edit ClusterLogging instance- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 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 - $ oc edit ClusterLogging instance- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 以下のパラメーターを追加または変更します。 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 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 - $ oc get pods -l component=collector -n openshift-logging- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 新規の値が - fluentd設定マップにあることを確認します。- oc extract configmap/fluentd --confirm - $ oc extract configmap/fluentd --confirm- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - fluentd.conf の例 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
7.2.5. デフォルトの Elasticsearch ログストアを使用しない場合の未使用のコンポーネントの削除
管理者がログをサードパーティーのログストアに転送し、デフォルトの Elasticsearch ログストアを使用しない場合は、ロギングクラスターからいくつかの未使用のコンポーネントを削除できます。
					つまり、デフォルトの Elasticsearch ログストアを使用しない場合は、内部 Elasticsearch logStore、Kibana visualization コンポーネントを ClusterLogging カスタムリソース (CR) から削除できます。これらのコンポーネントの削除はオプションですが、これによりリソースを節約できます。
				
前提条件
- ログフォワーダーがログデータをデフォルトの内部 Elasticsearch クラスターに送信しないことを確認します。ログ転送の設定に使用した - ClusterLogForwarderCR YAML ファイルを検査します。これには- defaultを指定する- outputRefs要素が ない ことを確認します。以下に例を示します。- outputRefs: - default - outputRefs: - default- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
						ClusterLogForwarder CR がログデータを内部 Elasticsearch クラスターに転送し、ClusterLogging CR から logStore コンポーネントを削除するとします。この場合、内部 Elasticsearch クラスターはログデータを保存するために表示されません。これがないと、データが失われる可能性があります。
					
手順
- openshift-loggingプロジェクトで- ClusterLoggingカスタムリソース (CR) を編集します。- oc edit ClusterLogging instance - $ oc edit ClusterLogging instance- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
							これらが存在する場合は、logStore、visualizationスタンザをClusterLoggingCR から削除します。
- ClusterLoggingCR の- collectionスタンザを保持します。結果は以下の例のようになります。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- コレクター Pod が再デプロイされたことを確認します。 - oc get pods -l component=collector -n openshift-logging - $ oc get pods -l component=collector -n openshift-logging- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow