11.3. LokiStack ログストアの設定
ロギングのドキュメントでは、LokiStack はロギングでサポートされている Loki および Web プロキシーと OpenShift Container Platform 認証統合を組み合わせたものを指します。LokiStack のプロキシーは、OpenShift Container Platform 認証を使用してマルチテナンシーを適用します。Loki では、ログストアを個別のコンポーネントまたは外部ストアと呼んでいます。
11.3.1. cluster-admin ユーザーロールの新規グループの作成
cluster-admin
ユーザーとして複数の namespace のアプリケーションログをクエリーすると、クラスター内のすべての namespace の文字数の合計が 5120 を超え、Parse error: input size too long (XXXX > 5120)
エラーが発生します。LokiStack のログへのアクセスをより適切に制御するには、cluster-admin
ユーザーを cluster-admin
グループのメンバーにします。cluster-admin
グループが存在しない場合は、作成して必要なユーザーを追加します。
次の手順を使用して、cluster-admin
権限のあるユーザー用に、新しいグループを作成します。
手順
以下のコマンドを入力して新規グループを作成します。
$ oc adm groups new cluster-admin
以下のコマンドを実行して、必要なユーザーを
cluster-admin
グループに追加します。$ oc adm groups add-users cluster-admin <username>
以下のコマンドを実行して
cluster-admin
ユーザーロールをグループに追加します。$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
11.3.2. クラスターの再起動中の LokiStack 動作
ロギングバージョン 5.8 以降のバージョンでは、OpenShift Container Platform クラスターが再起動されると、LokiStack の取り込みとクエリーパスは、ノードで使用可能な CPU リソースとメモリーリソース内で動作し続けます。つまり、OpenShift Container Platform クラスターの更新中に LokiStack でダウンタイムは発生しません。この動作は、PodDisruptionBudget
リソースを使用して実現されます。Loki Operator は、Loki に PodDisruptionBudget
リソースをプロビジョニングするため、特定の条件下で通常の動作を保証するためにコンポーネントごとに必要最小限、使用可能な Pod 数が決定されます。
11.3.3. ノードの障害を許容するための 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
設定を上書きできます。
インジェスターコンポーネントのユーザー設定の例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: # ... template: ingester: podAntiAffinity: # ... requiredDuringSchedulingIgnoredDuringExecution: 1 - labelSelector: matchLabels: 2 app.kubernetes.io/component: ingester topologyKey: kubernetes.io/hostname # ...
11.3.4. ゾーン対応のデータレプリケーション
ロギング 5.8 以降のバージョンでは、Loki Operator は Pod トポロジー分散制約を通じてゾーン対応のデータレプリケーションのサポートを提供します。この機能を有効にすると、信頼性が向上し、1 つのゾーンで障害が発生した場合のログ損失に対する保護が強化されます。デプロイメントサイズを 1x.extra.small
、1x.small
、または 1x.medium
に設定すると、replication.factor
フィールドは自動的に 2 に設定されます。
適切なレプリケーションを実現するには、少なくともレプリケーション係数で指定されているのと同じ数のアベイラビリティーゾーンが必要です。レプリケーション係数より多くのアベイラビリティーゾーンを設定することは可能ですが、ゾーンが少ないと書き込みエラーが発生する可能性があります。最適な運用を実現するには、各ゾーンで同じ数のインスタンスをホストする必要があります。
ゾーンレプリケーションが有効になっている LokiStack CR の例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: replicationFactor: 2 1 replication: factor: 2 2 zones: - maxSkew: 1 3 topologyKey: topology.kubernetes.io/zone 4
11.3.4.1. 障害が発生したゾーンからの Loki Pod の回復
OpenShift Container Platform では、特定のアベイラビリティーゾーンのリソースにアクセスできなくなると、ゾーン障害が発生します。アベイラビリティーゾーンは、冗長性とフォールトトレランスを強化することを目的とした、クラウドプロバイダーのデータセンター内の分離されたエリアです。OpenShift Container Platform クラスターがこの問題を処理するように設定されていない場合、ゾーン障害によりサービスまたはデータの損失が発生する可能性があります。
Loki Pod は StatefulSet の一部であり、StorageClass
オブジェクトによってプロビジョニングされた永続ボリューム要求 (PVC) が付属しています。各 Loki Pod とその PVC は同じゾーンに存在します。クラスターでゾーン障害が発生すると、StatefulSet コントローラーが、障害が発生したゾーン内の影響を受けた Pod の回復を自動的に試みます。
次の手順では、障害が発生したゾーン内の PVC とそこに含まれるすべてのデータを削除します。完全なデータ損失を回避するには、LokiStack
CR のレプリケーション係数フィールドを常に 1 より大きい値に設定して、Loki が確実にレプリケートされるようにする必要があります。
前提条件
- ロギングバージョン 5.8 以降。
-
LokiStack
CR のレプリケーション係数が 1 より大きいことを確認している。 - コントロールプレーンによってゾーン障害が検出され、障害が発生したゾーン内のノードがクラウドプロバイダー統合によってマークされている。
StatefulSet コントローラーは、障害が発生したゾーン内の Pod を自動的に再スケジュールしようとします。関連する PVC も障害が発生したゾーンにあるため、別のゾーンへの自動再スケジュールは機能しません。新しいゾーンでステートフル Loki Pod とそのプロビジョニングされた PVC を正常に再作成できるようにするには、障害が発生したゾーンの PVC を手動で削除する必要があります。
手順
次のコマンドを実行して、
Pending
中ステータスの Pod をリスト表示します。oc get pods --field-selector status.phase==Pending -n openshift-logging
oc get pods
の出力例NAME READY STATUS RESTARTS AGE 1 logging-loki-index-gateway-1 0/1 Pending 0 17m logging-loki-ingester-1 0/1 Pending 0 16m logging-loki-ruler-1 0/1 Pending 0 16m
- 1
- これらの Pod は、障害が発生したゾーンに対応する PVC があるため、
Pending
ステータスになっています。
次のコマンドを実行して、
Pending
ステータスの PVC をリストします。oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r
oc get pvc
の出力例storage-logging-loki-index-gateway-1 storage-logging-loki-ingester-1 wal-logging-loki-ingester-1 storage-logging-loki-ruler-1 wal-logging-loki-ruler-1
次のコマンドを実行して Pod の PVC を削除します。
oc delete pvc __<pvc_name>__ -n openshift-logging
次のコマンドを実行して Pod を削除します。
oc delete pod __<pod_name>__ -n openshift-logging
これらのオブジェクトが正常に削除されると、使用可能なゾーンでオブジェクトが自動的に再スケジュールされます。
11.3.4.1.1. terminating 状態の PVC のトラブルシューティング
PVC メタデータファイナライザーが kubernetes.io/pv-protection
に設定されている場合、PVC が削除されずに terminating 状態でハングする可能性があります。ファイナライザーを削除すると、PVC が正常に削除されるようになります。
以下のコマンドを実行して各 PVC のファイナライザーを削除し、削除を再試行します。
oc patch pvc __<pvc_name>__ -p '{"metadata":{"finalizers":null}}' -n openshift-logging
11.3.5. Loki ログへのアクセスの詳細設定
ロギング 5.8 以降では、Red Hat OpenShift Logging Operator はデフォルトですべてのユーザーにログへのアクセスを許可しません。Operator のアップグレード後に以前の設定を適用していない限り、管理者はユーザーのアクセスを設定する必要があります。設定とニーズに応じて、以下を使用してログへのアクセスを細かく設定できます。
- クラスター全体のポリシー
- スコープ指定が namespace のポリシー
- カスタム管理者グループの作成
管理者は、デプロイメントに適したロールバインディングとクラスターのロールバインディングを作成する必要があります。Red Hat OpenShift Logging Operator には、次のクラスターロールがあります。
-
cluster-logging-application-view
は、アプリケーションログの読み取り権限を付与します。 -
cluster-logging-infrastructure-view
は、インフラストラクチャーログの読み取り権限を付与します。 -
cluster-logging-audit-view
は、監査ログの読み取り権限を付与します。
以前のバージョンからアップグレードした場合、追加のクラスターロール logging-application-logs-reader
と関連するクラスターロールバインディング logging-all-authenticated-application-logs-reader
により下位互換性が提供され、認証されたユーザーに namespace の読み取り権限が許可されます。
namespace ごとのアクセス権を持つユーザーは、アプリケーションログをクエリーする際に namespace を提供する必要があります。
11.3.5.1. クラスター全体のアクセス
クラスターロールバインディングリソースはクラスターロールを参照し、クラスター全体に権限を設定します。
ClusterRoleBinding の例
kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: logging-all-application-logs-reader roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-logging-application-view 1 subjects: 2 - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io
11.3.5.2. namespace アクセス
RoleBinding
リソースを ClusterRole
オブジェクトと使用して、ユーザーまたはグループがログにアクセスできる namespace を定義できます。
RoleBinding の例
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: allow-read-logs
namespace: log-test-0 1
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-logging-application-view
subjects:
- kind: User
apiGroup: rbac.authorization.k8s.io
name: testuser-0
- 1
- この
RoleBinding
が適用される namespace を指定します。
11.3.5.3. カスタム管理者グループのアクセス権
多数のユーザーが広範な権限を必要とする大規模デプロイメントの場合は、adminGroup
フィールドを使用してカスタムグループを作成できます。LokiStack
CR の adminGroups
フィールドで指定されたグループのメンバーであるユーザーは、管理者とみなされます。
cluster-logging-application-view
ロールも割り当てられている管理者ユーザーは、すべての namespace のすべてのアプリケーションログにアクセスできます。
LokiStack CR の例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: tenants: mode: openshift-logging 1 openshift: adminGroups: 2 - cluster-admin - custom-admin-group 3
11.3.6. Loki でストリームベースの保持の有効化
Logging バージョン 5.6 以降では、ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。
s3 バケットまたは LokiStack カスタムリソース (CR) に保存期間が定義されていない場合、ログは削除されず、s3 バケットに永久に残り、s3 ストレージがいっぱいになる可能性があります。
ログバージョン 5.9 以上ではスキーマ v12 がサポートされていますが、v13 が推奨されます。
ストリームベースの保持を有効にするには、
LokiStack
CR を作成します。グローバルなストリームベースの保持の例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: limits: global: 1 retention: 2 days: 20 streams: - days: 4 priority: 1 selector: '{kubernetes_namespace_name=~"test.+"}' 3 - days: 1 priority: 1 selector: '{log_type="infrastructure"}' managementState: Managed replicationFactor: 1 size: 1x.small storage: schemas: - effectiveDate: "2020-10-11" version: v11 secret: name: logging-loki-s3 type: aws storageClassName: standard tenants: mode: openshift-logging
- 1
- すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
- 2
- このブロックが CR に追加されると、クラスターで保持が有効になります。
- 3
- ログストリームの定義に使用される LogQL クエリー が含まれています。
テナントごとのストリームベースの保持の例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: limits: global: retention: days: 20 tenants: 1 application: retention: days: 1 streams: - days: 4 selector: '{kubernetes_namespace_name=~"test.+"}' 2 infrastructure: retention: days: 5 streams: - days: 1 selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}' managementState: Managed replicationFactor: 1 size: 1x.small storage: schemas: - effectiveDate: "2020-10-11" version: v11 secret: name: logging-loki-s3 type: aws storageClassName: standard tenants: mode: openshift-logging
- 1
- テナントごとの保持ポリシーを設定します。有効なテナントタイプは、
application
、audit
、およびinfrastructure
です。 - 2
- ログストリームの定義に使用される LogQL クエリー が含まれています。
LokiStack
CR を適用します。$ oc apply -f <filename>.yaml
これは、保存されたログの保持を管理するためのものではありません。保存されたログのグローバルな保持期間 (最大 30 日間までサポート) は、オブジェクトストレージで設定します。
11.3.7. Loki レート制限エラーのトラブルシューティング
Log Forwarder API がレート制限を超える大きなメッセージブロックを Loki に転送すると、Loki により、レート制限 (429
) エラーが生成されます。
これらのエラーは、通常の動作中に発生する可能性があります。たとえば、すでにいくつかのログがあるクラスターにロギングを追加する場合、ロギングが既存のログエントリーをすべて取り込もうとするとレート制限エラーが発生する可能性があります。この場合、新しいログの追加速度が合計レート制限よりも低い場合、履歴データは最終的に取り込まれ、ユーザーの介入を必要とせずにレート制限エラーが解決されます。
レート制限エラーが引き続き発生する場合は、LokiStack
カスタムリソース (CR) を変更することで問題を解決できます。
LokiStack
CR は、Grafana がホストする Loki では利用できません。このトピックは、Grafana がホストする Loki サーバーには適用されません。
条件
- Log Forwarder API は、ログを Loki に転送するように設定されている。
システムは、次のような 2MB を超えるメッセージのブロックを Loki に送信する。以下に例を示します。
"values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\ ....... ...... ...... ...... \"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
oc logs -n openshift-logging -l component=collector
と入力すると、クラスター内のコレクターログに、次のいずれかのエラーメッセージを含む行が表示されます。429 Too Many Requests Ingestion rate limit exceeded
Vector エラーメッセージの例
2023-08-25T16:08:49.301780Z WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true
Fluentd エラーメッセージの例
2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"
このエラーは受信側にも表示されます。たとえば、LokiStack 取り込み Pod で以下を行います。
Loki 取り込みエラーメッセージの例
level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream
手順
LokiStack
CR のingestionBurstSize
およびingestionRate
フィールドを更新します。apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: limits: global: ingestion: ingestionBurstSize: 16 1 ingestionRate: 8 2 # ...
- 1
ingestionBurstSize
フィールドは、ディストリビューターレプリカごとに最大ローカルレート制限サンプルサイズを MB 単位で定義します。この値はハードリミットです。この値を、少なくとも 1 つのプッシュリクエストで想定される最大ログサイズに設定します。ingestionBurstSize
値より大きい単一リクエストは使用できません。- 2
ingestionRate
フィールドは、1 秒あたりに取り込まれるサンプルの最大量 (MB 単位) に対するソフト制限です。ログのレートが制限を超えているにもかかわらず、コレクターがログの送信を再試行すると、レート制限エラーが発生します。合計平均が制限よりも少ない場合に限り、システムは回復し、ユーザーの介入なしでエラーが解決されます。
11.3.8. メンバーリストの作成の失敗を許容する Loki の設定
OpenShift クラスターでは、管理者は通常、非プライベート IP ネットワーク範囲を使用します。その結果、LokiStack メンバーリストはデフォルトでプライベート IP ネットワークのみを使用するため、LokiStack メンバーリストの設定は失敗します。
管理者は、メンバーリスト設定の Pod ネットワークを選択できます。hashRing
仕様で podIP
を使用するように LokiStack CR を変更できます。LokiStack CR を設定するには、以下のコマンドを使用します。
$ oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP","type": "memberlist"}}}}'
podIP
を含める LokiStack の例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: # ... hashRing: type: memberlist memberlist: instanceAddrType: podIP # ...