2.6. LokiStack でのログの保存
アプリケーション、監査、インフラストラクチャー関連のログを保存するように LokiStack CR を設定できます。
Loki は、水平スケーリング可能で可用性の高いマルチテナントログ集約システムで、OpenShift Observability UI で視覚化できる Logging for Red Hat OpenShift 用の GA ログストアとして提供されます。OpenShift Logging が提供する Loki 設定は、収集されたログを使用してユーザーが迅速にトラブルシューティングを実行できるように設計された短期ログストアです。この目的のために、Logging for Red Hat OpenShift の Loki 設定は短期ストレージを備えており、最新のクエリーに最適化されています。
長期間にわたる保存やクエリーの場合、ユーザーはクラスター外部のログストアを探す必要があります。Loki のサイズ設定は、最大 30 日間の短期ストレージに対してのみテストおよびサポートされます。
2.6.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- CLI または Web コンソールを使用して Loki Operator をインストールしている。
-
ClusterLogForwarderを作成するのと同じ namespace にserviceAccountがある。 -
serviceAccountにcollect-audit-logs、collect-application-logs、collect-infrastructure-logsのクラスターロールが割り当てられている。
2.6.2. コアのセットアップと設定 リンクのコピーリンクがクリップボードにコピーされました!
ロールベースのアクセス制御、基本的なモニタリング、および Loki をデプロイするための Pod の配置。
2.6.3. Loki デプロイメントのサイズ リンクのコピーリンクがクリップボードにコピーされました!
Loki のサイズは 1x.<size> の形式に従います。この場合の 1x はインスタンスの数を、<size> は性能を指定します。
1x.pico 設定は、最小限のリソースと制限要件を持つ単一の Loki デプロイメントを定義し、すべての Loki コンポーネントに高可用性 (HA) サポートを提供します。この設定は、単一のレプリケーションファクターまたは自動圧縮を必要としないデプロイメントに適しています。
ディスク要求はサイズ設定にかかわらず類似しているため、お客様はさまざまなサイズをテストして、それぞれのデプロイメントニーズに最適なサイズを決定できます。
デプロイメントサイズの 1x の数は変更できません。
| 1x.demo | 1x.pico [6.1+ のみ] | 1x.extra-small | 1x.small | 1x.medium | |
|---|---|---|---|---|---|
| Data transfer | デモ使用のみ | 50 GB/日 | 100 GB/日 | 500 GB/日 | 2 TB/日 |
| 1 秒あたりのクエリー数 (QPS) | デモ使用のみ | 200 ミリ秒で 1 - 25 QPS | 200 ミリ秒で 1 - 25 QPS | 200 ミリ秒で 25 - 50 QPS | 200 ミリ秒で 25 - 75 QPS |
| レプリケーション係数 | なし | 2 | 2 | 2 | 2 |
| 合計 CPU 要求 | なし | 仮想 CPU 7 個 | 仮想 CPU 14 個 | 仮想 CPU 34 個 | 仮想 CPU 54 個 |
| ルーラーを使用する場合の合計 CPU リクエスト | なし | 仮想 CPU 8 個 | 仮想 CPU 16 個 | 仮想 CPU 42 個 | 仮想 CPU 70 個 |
| 合計メモリー要求 | なし | 17 Gi | 31 Gi | 67 Gi | 139 Gi |
| ルーラーを使用する場合の合計メモリーリクエスト | なし | 18 Gi | 35 Gi | 83 Gi | 171 Gi |
| 合計ディスク要求 | 40 Gi | 590 Gi | 430 Gi | 430 Gi | 590 Gi |
| ルーラーを使用する場合の合計ディスクリクエスト | 60 Gi | 910 Gi | 750 Gi | 750Gi | 910 Gi |
2.6.4. LokiStack ルールの RBAC 権限の認可 リンクのコピーリンクがクリップボードにコピーされました!
管理者は、クラスターロールをユーザー名にバインドすることで、ユーザーが独自のアラートおよび記録ルールを作成および管理できるようにすることができます。クラスターロールは、ユーザーに必要なロールベースのアクセス制御 (RBAC) 権限を含む ClusterRole オブジェクトとして定義されます。
LokiStack では、アラートおよび記録ルール用の次のクラスターロールが利用できます。
| ルール名 | 説明 |
|---|---|
|
|
このロールを持つユーザーは、アラートルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、 |
|
|
このロールを持つユーザーは、 |
|
|
このロールを持つユーザーは、 |
|
|
このロールを持つユーザーは、 |
|
|
このロールを持つユーザーは、記録ルールを管理する管理レベルのアクセス権を持ちます。このクラスターロールは、 |
|
|
このロールを持つユーザーは、 |
|
|
このロールを持つユーザーは、 |
|
|
このロールを持つユーザーは、 |
2.6.4.1. 例 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーにクラスターロールを適用するには、既存のクラスターロールを特定のユーザー名にバインドする必要があります。
クラスターロールは、使用するロールバインディングの種類に応じて、クラスタースコープまたは namespace スコープにすることができます。RoleBinding オブジェクトを使用する場合は、oc adm policy add-role-to-user コマンドを使用する場合と同様に、クラスターロールが指定した namespace にのみ適用されます。ClusterRoleBinding オブジェクトを使用する場合は、oc adm policy add-cluster-role-to-user コマンドを使用する場合と同様に、クラスターロールがクラスター内のすべての namespace に適用されます。
次のコマンド例では、指定したユーザーに、クラスター内の特定の namespace のアラートルールに対する作成、読み取り、更新、および削除 (CRUD) 権限を付与します。
特定の namespace のアラートルールに対する CRUD 権限を付与するクラスターロールバインディングコマンドの例
$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
次のコマンドは、指定したユーザーに、すべての namespace のアラートルールに対する管理者権限を付与します。
管理者権限を付与するクラスターロールバインディングコマンドの例
$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
2.6.5. Loki を使用したログベースのアラートルールの作成 リンクのコピーリンクがクリップボードにコピーされました!
AlertingRule CR には、単一の LokiStack インスタンスのアラートルールグループを宣言するために使用する、仕様および Webhook 検証定義のセットが含まれます。Webhook 検証定義は、ルール検証条件もサポートします。
-
AlertingRuleCR に無効なinterval期間が含まれる場合、無効なアラートルールです。 -
AlertingRuleCR に無効なfor期間が含まれる場合、無効なアラートルールです。 -
AlertingRuleCR に無効な LogQLexprが含まれる場合、無効なアラートルールです。 -
AlertingRuleCR に同じ名前のグループが 2 つ含まれる場合、無効なアラートルールです。 - 上記のいずれも該当しない場合、アラートルールは有効とみなされます。
| テナントタイプ | AlertingRule CR の有効な namespace |
|---|---|
| application |
|
| audit |
|
| infrastructure |
|
手順
AlertingRuleカスタムリソース (CR) を作成します。インフラストラクチャー
AlertingRuleCR の例apiVersion: loki.grafana.com/v1 kind: AlertingRule metadata: name: loki-operator-alerts namespace: openshift-operators-redhat1 labels:2 openshift.io/<label_name>: "true" spec: tenantID: "infrastructure"3 groups: - name: LokiOperatorHighReconciliationError rules: - alert: HighPercentageError expr: |4 sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job) / sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job) > 0.01 for: 10s labels: severity: critical5 annotations: summary: High Loki Operator Reconciliation Errors6 description: High Loki Operator Reconciliation Errors7 - 1
- この
AlertingRuleCR が作成される namespace には、LokiStackspec.rules.namespaceSelector定義に一致するラベルが必要です。 - 2
labelsブロックは、LokiStack のspec.rules.selector定義と一致する必要があります。- 3
infrastructureテナントのAlertingRuleCR は、openshift-*、kube-\*、またはdefaultnamespaces でのみサポートされます。- 4
kubernetes_namespace_name:の値は、metadata.namespaceの値と一致する必要があります。- 5
- この必須フィールドの値は、
critical、warning、またはinfoである必要があります。 - 6
- このフィールドは必須です。
- 7
- このフィールドは必須です。
アプリケーション
AlertingRuleCR の例apiVersion: loki.grafana.com/v1 kind: AlertingRule metadata: name: app-user-workload namespace: app-ns1 labels:2 openshift.io/<label_name>: "true" spec: tenantID: "application" groups: - name: AppUserWorkloadHighError rules: - alert: expr: |3 sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job) for: 10s labels: severity: critical4 annotations: summary:5 description:6 - 1
- この
AlertingRuleCR が作成される namespace には、LokiStackspec.rules.namespaceSelector定義に一致するラベルが必要です。 - 2
labelsブロックは、LokiStack のspec.rules.selector定義と一致する必要があります。- 3
kubernetes_namespace_name:の値は、metadata.namespaceの値と一致する必要があります。- 4
- この必須フィールドの値は、
critical、warning、またはinfoである必要があります。 - 5
- この必須フィールドの値は、ルールの概要です。
- 6
- この必須フィールドの値は、ルールの詳細な説明です。
AlertingRuleCR を適用します。$ oc apply -f <filename>.yaml
2.6.6. メンバーリストの作成の失敗を許容する 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"}}}'
podIP を含む LokiStack の例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
# ...
hashRing:
type: memberlist
memberlist:
instanceAddrType: podIP
# ...
2.6.7. Loki でストリームベースの保持の有効化 リンクのコピーリンクがクリップボードにコピーされました!
ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。
s3 バケットまたは LokiStack カスタムリソース (CR) に保存期間が定義されていない場合、ログは削除されず、s3 バケットに永久に残り、s3 ストレージがいっぱいになる可能性があります。
スキーマ v13 が推奨されます。
手順
LokiStackCR を作成します。次の例に示すように、ストリームベースの保持をグローバルに有効にします。
AWS のグローバルストリームベースの保持の例
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: v13 secret: name: logging-loki-s3 type: aws storageClassName: gp3-csi tenants: mode: openshift-logging- 1
- すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
- 2
- このブロックが CR に追加されると、クラスターで保持が有効になります。
- 3
- ログ stream.spec: 制限を定義するために使用される LogQL クエリー が含まれます。
次の例に示すように、テナントごとにストリームベースの保持を有効にします。
AWS のテナントごとのストリームベースの保持の例
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: v13 secret: name: logging-loki-s3 type: aws storageClassName: gp3-csi tenants: mode: openshift-logging- 1
- テナントごとの保持ポリシーを設定します。有効なテナントタイプは、
application、audit、およびinfrastructureです。 - 2
- ログストリームの定義に使用される LogQL クエリー が含まれています。
LokiStackCR を適用します。$ oc apply -f <filename>.yaml
2.6.8. Loki Pod の配置 リンクのコピーリンクがクリップボードにコピーされました!
Pod の toleration またはノードセレクターを使用して、Loki Pod が実行するノードを制御し、他のワークロードがそれらのノードを使用しないようにできます。
LokiStack カスタムリソース (CR) を使用して toleration をログストア Pod に適用し、ノード仕様を使用して taint をノードに適用できます。ノードの taint は、taint を容認しないすべての Pod を拒否するようノードに指示する key:value ペアです。他の Pod にはない特定の key:value ペアを使用すると、ログストア Pod のみがそのノードで実行できるようになります。
ノードセレクターを使用する LokiStack の例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
# ...
template:
compactor:
nodeSelector:
node-role.kubernetes.io/infra: ""
distributor:
nodeSelector:
node-role.kubernetes.io/infra: ""
gateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
indexGateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
ingester:
nodeSelector:
node-role.kubernetes.io/infra: ""
querier:
nodeSelector:
node-role.kubernetes.io/infra: ""
queryFrontend:
nodeSelector:
node-role.kubernetes.io/infra: ""
ruler:
nodeSelector:
node-role.kubernetes.io/infra: ""
# ...
ノードセレクターと toleration を使用する LokiStack CR の例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
# ...
template:
compactor:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
distributor:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
indexGateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
ingester:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
querier:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
queryFrontend:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
ruler:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
gateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
# ...
LokiStack (CR) の nodeSelector フィールドと tolerations フィールドを設定するには、oc explain コマンドを使用して、特定のリソースの説明とフィールドを表示します。
$ oc explain lokistack.spec.template
出力例
KIND: LokiStack
VERSION: loki.grafana.com/v1
RESOURCE: template <Object>
DESCRIPTION:
Template defines the resource/limits/tolerations/nodeselectors per
component
FIELDS:
compactor <Object>
Compactor defines the compaction component spec.
distributor <Object>
Distributor defines the distributor component spec.
...
詳細情報用に、特定のフィールドを追加できます。
$ oc explain lokistack.spec.template.compactor
出力例
KIND: LokiStack
VERSION: loki.grafana.com/v1
RESOURCE: compactor <Object>
DESCRIPTION:
Compactor defines the compaction component spec.
FIELDS:
nodeSelector <map[string]string>
NodeSelector defines the labels required by a node to schedule the
component onto it.
...
2.6.8.1. 信頼性とパフォーマンスの向上 リンクのコピーリンクがクリップボードにコピーされました!
実稼働環境における Loki の信頼性と効率性を確保するための設定。
2.6.8.2. 有効期間の短いトークンを使用したクラウドベースのログストアへの認証の有効化 リンクのコピーリンクがクリップボードにコピーされました!
ワークロードアイデンティティーフェデレーションを使用すると、有効期間の短いトークンを使用してクラウドベースのログストアに対して認証できます。
手順
認証を有効にするには、次のいずれかのオプションを使用します。
-
OpenShift Container Platform Web コンソールを使用して Loki Operator をインストールすると、有効期間が短いトークンを使用するクラスターが自動的に検出されます。プロンプトが表示され、ロールを作成するように求められます。また、Loki Operator が
CredentialsRequestオブジェクトを作成するのに必要なデータを提供するように求められます。このオブジェクトにより、シークレットが設定されます。 OpenShift CLI (
oc) を使用して Loki Operator をインストールする場合は、次の例に示すように、ストレージプロバイダーに適したテンプレートを使用してSubscriptionオブジェクトを手動で作成する必要があります。この認証ストラテジーは、指定のストレージプロバイダーでのみサポートされます。Azure サンプルサブスクリプションの例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: loki-operator namespace: openshift-operators-redhat spec: channel: "stable-6.0" installPlanApproval: Manual name: loki-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: CLIENTID value: <your_client_id> - name: TENANTID value: <your_tenant_id> - name: SUBSCRIPTIONID value: <your_subscription_id> - name: REGION value: <your_region>AWS サンプルサブスクリプションの例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: loki-operator namespace: openshift-operators-redhat spec: channel: "stable-6.0" installPlanApproval: Manual name: loki-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: ROLEARN value: <role_ARN>
-
OpenShift Container Platform Web コンソールを使用して Loki Operator をインストールすると、有効期間が短いトークンを使用するクラスターが自動的に検出されます。プロンプトが表示され、ロールを作成するように求められます。また、Loki Operator が
2.6.8.3. ノードの障害を許容するための Loki の設定 リンクのコピーリンクがクリップボードにコピーされました!
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:
- labelSelector:
matchLabels:
app.kubernetes.io/component: ingester
topologyKey: kubernetes.io/hostname
# ...
2.6.8.4. クラスターの再起動中の LokiStack 動作 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターが再起動されると、LokiStack の取り込みとクエリーパスは、ノードで使用可能な CPU およびメモリーリソース内で引き続き動作します。つまり、OpenShift Container Platform クラスターの更新中に LokiStack でダウンタイムは発生しません。この動作は、PodDisruptionBudget リソースを使用して実現されます。Loki Operator は、Loki に PodDisruptionBudget リソースをプロビジョニングするため、特定の条件下で通常の動作を保証するためにコンポーネントごとに必要最小限、使用可能な Pod 数が決定されます。
2.6.8.5. 高度なデプロイメントとスケーラビリティー リンクのコピーリンクがクリップボードにコピーされました!
高可用性、スケーラビリティー、エラー処理のための特殊な設定。
2.6.8.6. ゾーン対応のデータレプリケーション リンクのコピーリンクがクリップボードにコピーされました!
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
replication:
factor: 2
zones:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
2.6.8.7. 障害が発生したゾーンからの Loki Pod の回復 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、特定のアベイラビリティーゾーンのリソースにアクセスできなくなると、ゾーン障害が発生します。アベイラビリティーゾーンは、冗長性とフォールトトレランスを強化することを目的とした、クラウドプロバイダーのデータセンター内の分離されたエリアです。OpenShift Container Platform クラスターがこの問題を処理するように設定されていない場合、ゾーン障害によりサービスまたはデータの損失が発生する可能性があります。
Loki Pod は StatefulSet の一部であり、StorageClass オブジェクトによってプロビジョニングされた永続ボリューム要求 (PVC) が付属しています。各 Loki Pod とその PVC は同じゾーンに存在します。クラスターでゾーン障害が発生すると、StatefulSet コントローラーが、障害が発生したゾーン内の影響を受けた Pod の回復を自動的に試みます。
次の手順では、障害が発生したゾーン内の PVC とそこに含まれるすべてのデータを削除します。完全なデータ損失を回避するには、LokiStack CR のレプリケーション係数フィールドを常に 1 より大きい値に設定して、Loki が確実にレプリケートされるようにする必要があります。
前提条件
-
LokiStackCR のレプリケーション係数が 1 より大きいことを確認している。 - コントロールプレーンによってゾーン障害が検出され、障害が発生したゾーン内のノードがクラウドプロバイダー統合によってマークされている。
StatefulSet コントローラーは、障害が発生したゾーン内の Pod を自動的に再スケジュールしようとします。関連する PVC も障害が発生したゾーンにあるため、別のゾーンへの自動再スケジュールは機能しません。新しいゾーンでステートフル Loki Pod とそのプロビジョニングされた PVC を正常に再作成できるようにするには、障害が発生したゾーンの PVC を手動で削除する必要があります。
手順
次のコマンドを実行して、
Pending中ステータスの Pod をリスト表示します。$ oc get pods --field-selector status.phase==Pending -n openshift-loggingoc get podsの出力例NAME READY STATUS RESTARTS AGE1 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' -roc 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これらのオブジェクトが正常に削除されると、使用可能なゾーンでオブジェクトが自動的に再スケジュールされます。
2.6.8.7.1. terminating 状態の PVC のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
PVC メタデータファイナライザーが kubernetes.io/pv-protection に設定されている場合、PVC が削除されずに terminating 状態でハングする可能性があります。ファイナライザーを削除すると、PVC が正常に削除されるようになります。
以下のコマンドを実行して各 PVC のファイナライザーを削除し、削除を再試行します。
$ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging
2.6.8.8. 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 exceededVector エラーメッセージの例
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このエラーは受信側にも表示されます。たとえば、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
手順
LokiStackCR のingestionBurstSizeおよびingestionRateフィールドを更新します。apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: limits: global: ingestion: ingestionBurstSize: 161 ingestionRate: 82 # ...- 1
ingestionBurstSizeフィールドは、ディストリビューターレプリカごとに最大ローカルレート制限サンプルサイズを MB 単位で定義します。この値はハードリミットです。この値を、少なくとも 1 つのプッシュリクエストで想定される最大ログサイズに設定します。ingestionBurstSize値より大きい単一リクエストは使用できません。- 2
ingestionRateフィールドは、1 秒あたりに取り込まれるサンプルの最大量 (MB 単位) に対するソフト制限です。ログのレートが制限を超えているにもかかわらず、コレクターがログの送信を再試行すると、レート制限エラーが発生します。合計平均が制限よりも少ない場合に限り、システムは回復し、ユーザーの介入なしでエラーが解決されます。