2.3. 信頼性とパフォーマンスの向上
実稼働環境で Loki の信頼性と効率性を確保するには、次の設定を使用します。
2.3.1. Loki Pod の配置 リンクのコピーリンクがクリップボードにコピーされました!
Pod の toleration またはノードセレクターを使用して、Loki Pod が実行するノードを制御し、他のワークロードがそれらのノードを使用しないようにできます。
LokiStack カスタムリソース (CR) を使用して toleration をログストア Pod に適用し、ノード仕様を使用して taint をノードに適用できます。ノードの taint は、taint を容認しないすべての Pod を拒否するようノードに指示する key:value
ペアです。他の Pod にはない特定の key:value
ペアを使用すると、ログストア Pod のみがそのノードで実行できるようになります。
ノードセレクターを使用する LokiStack の例
ノードセレクターと toleration を使用する LokiStack CR の例
LokiStack (CR) の nodeSelector
フィールドと tolerations
フィールドを設定するには、oc explain
コマンドを使用して、特定のリソースの説明とフィールドを表示します。
oc explain lokistack.spec.template
$ oc explain lokistack.spec.template
出力例
詳細情報用に、特定のフィールドを追加できます。
oc explain lokistack.spec.template.compactor
$ oc explain lokistack.spec.template.compactor
出力例
2.3.2. ノードの障害を許容するための Loki の設定 リンクのコピーリンクがクリップボードにコピーされました!
ロギング 5.8 以降のバージョンでは、Loki Operator は、同じコンポーネントの Pod がクラスター内の異なる使用可能なノードにスケジュールされるように要求する Pod 非アフィニティールールの設定をサポートします。
アフィニティーとは、スケジュールするノードを制御する Pod の特性です。非アフィニティーとは、Pod がスケジュールされることを拒否する Pod の特性です。
OpenShift Container Platform では、Pod のアフィニティー と Pod の非アフィニティー によって、他の Pod のキー/値ラベルに基づいて、Pod のスケジュールに適したノードを制限できます。
Operator は、すべての Loki コンポーネント (compactor
、distributor
、gateway
、indexGateway
、ingester
、querier
、queryFrontend
、および ruler
コンポーネントを含む) に対してデフォルトの優先 podAntiAffinity
ルールを設定します。
requiredDuringSchedulingIgnoredDuringExecution
フィールドに必要な設定を指定して、Loki コンポーネントの希望の podAntiAffinity
設定を上書きできます。
インジェスターコンポーネントのユーザー設定の例
2.3.3. Loki でストリームベースの保持の有効化 リンクのコピーリンクがクリップボードにコピーされました!
ログストリームに基づいて保持ポリシーを設定できます。保持ルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。
s3 バケットまたは LokiStack カスタムリソース (CR) に保存期間が定義されていない場合、ログはプルーニングされず、s3 バケットに永久に残り、s3 ストレージがいっぱいになる可能性があります。
-
Logging バージョン 5.9 以降ではスキーマ
v12
がサポートされていますが、将来の互換性のためにスキーマv13
が推奨されます。 コスト効率の高いログプルーニングを行うには、オブジェクトストレージプロバイダーで直接保持ポリシーを設定します。ストレージプロバイダーのライフサイクル管理機能を使用して、古いログが自動的に削除されるようにします。これにより、Loki からの追加処理と S3 への削除リクエストも回避されます。
オブジェクトストレージがライフサイクルポリシーをサポートしていない場合は、内部で保持を強制するように LokiStack を設定する必要があります。サポートされる保持期間は最大 30 日間です。
前提条件
- 管理者権限がある。
- Loki Operator がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。
手順
ストリームベースの保持を有効にするには、
LokiStack
CR を作成し、YAML ファイルとして保存します。次の例では、lokistack.yaml
という名前になっています。S3 のグローバルストリームベースの保持の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- すべてのログストリームの保持ポリシーを設定します。このポリシーは、オブジェクトストレージに保存されるログの保持期間には影響しません。
- 2
retention
ブロックを CR に追加して、クラスター内の保持を有効にします。- 3
- ログストリームを保持ルールに一致させるための LogQL クエリー を指定します。
S3 のテナントごとのストリームベースの保持の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- テナントごとに保持ポリシーを設定します。有効なテナントタイプは、
application
、audit
、およびinfrastructure
です。 - 2
- ログストリームを保持ルールに一致させるための LogQL クエリー を指定します。
LokiStack
CR を適用します。oc apply -f lokistack.yaml
$ oc apply -f lokistack.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.4. メンバーリストの作成の失敗を許容する Loki の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターでは、管理者は通常、非プライベート IP ネットワーク範囲を使用します。その結果、LokiStack メンバーリストはデフォルトでプライベート IP ネットワークのみを使用するため、LokiStack メンバーリストの設定は失敗します。
管理者は、メンバーリスト設定の Pod ネットワークを選択できます。LokiStack
カスタムリソース (CR) を変更して、hashRing
仕様で podIP
アドレスを使用できます。LokiStack
CR を設定するには、以下のコマンドを使用します。
oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'
$ oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'
podIP
を含める LokiStack の例
2.3.5. クラスターの再起動中の LokiStack 動作 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターが再起動されると、LokiStack の取り込みとクエリーパスは、ノードで使用可能な CPU およびメモリーリソース内で引き続き動作します。つまり、OpenShift Container Platform クラスターの更新中に LokiStack でダウンタイムは発生しません。この動作は、PodDisruptionBudget
リソースを使用して実現されます。Loki Operator は、Loki に PodDisruptionBudget
リソースをプロビジョニングします。このリソースは、特定の条件下で通常の操作ができるようにコンポーネントごとに使用可能でなければならない Pod の最小数を決定します。