概要

OpenShiftのロギングとして、Red Hat OpenShift Logging 5.5 + LokiStack Operator5.5で、LokiStack + Vectorを導入していた時には、おそらくまだログの保持期間の設定(Retention)ができませんでした。
(そのため、自分の検証環境では、1週間ちょっとしたらLokiStack用のオブジェクトストレージ容量が溢れて正常に動作しなくなってしまいました。。)

それが、Red Hat OpenShift Logging 5.6 + Loki Operator 5.6からは、ちゃんとログの保持期間の設定(Retention)ができるようになったようです。

OCP 4.12 Docs / ロギング / 1. ロギングのリリースノート / 1.2. Logging 5.6 / 1.2.2. 機能拡張

今回の更新により、LokiStack カスタムリソースを使用して、テナントごと、ストリームごと、およびグローバルポリシーの保持ポリシーを優先度順に宣言できるようになります。(LOG-2695)

OCP 4.12 Docs / ロギング / 5. Loki / 5.3. Loki でストリームベースの保持を有効にする

Logging バージョン 5.6 以降では、ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。

今回はその設定をしてみましたので、その際のメモを残しておきます。

環境

最初は、ベアメタルUPIで導入したオンプレのOpenShift 4.11に、ロギングとしてRed Hat OpenShift Logging 5.5 + Loki Operator 5.5 を導入しています。
- Qiita / ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた
その後、OCPを4.12にアップデートし、ロギングはRed Hat OpenShift Logging 5.6 + Loki Operator 5.6 にアップデートした環境を使用します。
- Qiita / OpenShiftのアップデート(OCP4.11 to 4.12)

OCP構成

OCPのバージョンはOCP 4.12.3です。

[root@bastion-01 ~]# oc version
Client Version: 4.12.3
Kustomize Version: v4.5.7
Server Version: 4.12.3
Kubernetes Version: v1.25.4+a34b9e9
[root@bastion-01 ~]#

ノード構成

infra node、storage node専用のノードも作成しています。

[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-74f981727fab0316702889103c90d475    True      False      False      6              6                   6                     0                      228d
master   rendered-master-66bd7c1e50b9cd63ddc138121fdd26ca   True      False      False      3              3                   3                     0                      228d
worker   rendered-worker-74f981727fab0316702889103c90d475   True      False      False      2              2                   2                     0                      228d
[root@bastion-01 ~]#

[root@bastion-01 ~]# oc get node
NAME         STATUS   ROLES    AGE    VERSION
infra-01     Ready    infra    228d   v1.25.4+a34b9e9
infra-02     Ready    infra    228d   v1.25.4+a34b9e9
infra-03     Ready    infra    228d   v1.25.4+a34b9e9
master-01    Ready    master   228d   v1.25.4+a34b9e9
master-02    Ready    master   228d   v1.25.4+a34b9e9
master-03    Ready    master   228d   v1.25.4+a34b9e9
storage-01   Ready    infra    82d    v1.25.4+a34b9e9
storage-02   Ready    infra    82d    v1.25.4+a34b9e9
storage-03   Ready    infra    82d    v1.25.4+a34b9e9
worker-01    Ready    worker   228d   v1.25.4+a34b9e9
worker-02    Ready    worker   228d   v1.25.4+a34b9e9
[root@bastion-01 ~]#

Operator構成

以下のOperatorを導入しています。

ストレージ関連

Operator	Channel	更新承認ストラテジー	CSV	備考
Local Storage	`stable`	Manual	`local-storage-operator.v4.12.0-202302061702`
OpenShift Data Foundation	`stable-4.12`	Manual	`odf-operator.v4.12.0`

ロギング関連

ロギング関連は5.6を導入しています。

Operator	Channel	更新承認ストラテジー	CSV	備考
Red Hat OpenShift Logging	`stable-5.6`	Manual	`cluster-logging.v5.6.2`	以前は`Cluster Logging Operator`という名称だったが変更されたもの
Loki Operator	`stable-5.6`	Manual	`loki-operator.v5.6.2`

構成

LokiStackの使用するオブジェクトストレージはODFを使用しています。
構成としては、LokiSatckのログ保管領域としてのオブジェクトストレージはLoki専用に300GiBのバッキングストアを作成しています。(以下参照)
Qiita / ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた

手順概要

アップデート前の5.5で導入したKind: ClusterLoggingとKind: LokiStackのリソースの、ログ保管用のオブジェクトストレージが溢れて正常な状態ではなかったので、一旦これらのリソースを綺麗に削除してから、再度5.6のKind: ClusterLoggingと、Kind: LokiStackのリソースを作成しなおします。

手順

事前準備

ClusterLoggingとLokiStackのリソースをアンインストールしました。(手順は割愛します。)
また、「Qiita / ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた」の「オブジェクトストレージの準備」で作成したバッキングストア、Object Bucket Claimも、同じ手順で再作成しました。

LokiStackカスタムリソースの作成

ログのRetentionの設定方法

LokiStackのログのRetention方法は、以下に記載がありました。

OCP 4.12 Docs / ロギング / 5. Loki / 5.3. Loki でストリームベースの保持を有効にする

ドキュメントのサンプルとしては「(1)グローバルなストリームベースの保持の例」と「(2)テナントごとのストリームベースの保持の例」の二つがありました。

(1)グローバルなストリームベースの保持の例

.spec.limits.globalの(注)としてと以下のような記載がありました。

Sets retention policy for all log streams. Note: This field does not impact the retention period for stored logs in object storage.

ですので.spec.limits.global.stereamsのようにストリームだけの書き方だと、オブジェクトストレージに保持されたログはRetentionされないように思えました。

(2)テナントごとのストリームベースの保持の例

GlobalなRetentionの設定はspec.limits.global.retention.daysで設定できるようです。
また、テナント(application、infrastructure、audit)毎の設定は、spec.limits.tennants.<application/infrastructure/audit>の方で設定ができるようです。

この場合の注意書きとして以下のような文言がありました。

Note: This is not for managing the retention for stored logs. Global retention periods for stored logs to a supported maximum of 30 days is configured with your object storage.

こちらの場合はspec.limits.global.retention.daysでオブジェクトストレージに対するRetentionの設定ができて、最大30日までサポート？と書いているような気がします。

今回は、Loki 5.5の時にLokiStack用のオブジェクトストレージが溢れてしまっていたので、オブジェクトストレージに対するRetentionの設定(と思われる)(2)の方の設定をしてみたいと思います。
((1)もglobal.retention.daysは同じフィールドなので、本当はできる気もしますが念の為..)

(いずれにしても(2)の方でも、spec.limits.tenannts.applicationなどのテナントの下でストレームベースでも個別に設定できるようですので、基本的には(2)の方法の方がいいような気がしました。)

LokiStackカスタムリソースの作成 (ログののRetentionの設定部分)

LokiStackのカスタムリソースのログのRetention以外の部分のマニフェストは、「Qiita / ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた」の「(2) LokiStackカスタムリソースの作成」のセクションの通りに設定します。

それ以外の、ログのRetention部分は上述の「(2)テナントごとのストリームベースの保持の例」を参考に以下のように設定してみました。

Globalなログ保持期間の設定は3日とする。
テナント(application)のログ保持期間は1日とする。
- testて始まる名前のnamespaceだけ2日にしてみる。
- 今回の検証環境ではtestという文字列のnamespaceしかなかったので、selector: '{kubernetes_namespace_name="test"}'で十分ですが、ドキュメントのサンプルを真似してみました。
テナント(infrastructure)のログ保持期間は1日としてみる。個別のストリームベースの設定はしない。

spec:
  limits:
    global:
      retention:
        days: 3
    tenants:
      application:
        retention:
          days: 1
          streams:
            - days: 2
              selector: '{kubernetes_namespace_name=~"test.+"}'
      infrastructure:
        retention:
          days: 1

(補足)後ほど実際にやってみた結果を見るとtestで始まるnamespaceのログも1日で消えているようでしたので、おそらくapplicationのログ保持期間より大きい値はダメなのかもしれません。)

最終的な設定

上述を全て合わせたLokiStackのマニフェストファイルは以下のようにしました。

[root@bastion-01 logging]# vi lokistack.yaml
[root@bastion-01 logging]# cat lokistack.yaml

lokistack.yaml

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-lokistack
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 3
    tenants:
      application:
        retention:
          days: 1
          streams:
            - days: 2
              selector: '{kubernetes_namespace_name=~"test.+"}'
      infrastructure:
        retention:
          days: 1
  tenants:
    mode: openshift-logging
  managementState: Managed
  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: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
  storage:
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
    secret:
      name: loki-object-bucket
      type: s3
    tls:
      caKey: "service-ca.crt"
      caName: "openshift-service-ca.crt"
  size: 1x.small
  storageClassName: ocs-storagecluster-ceph-rbd

LokiStackのマニフェストの適用

作成したマニフェストファイルを適用します。

oc apply -f lokistack.yaml

(出力例)

[root@bastion-01 logging]# oc apply -f lokistack.yaml
lokistack.loki.grafana.com/logging-lokistack created
[root@bastion-01 logging]#

確認します。

oc get lokistack -n openshift-logging

oc get statefulset -n openshift-logging
oc get deployment -n openshift-logging
oc get daemonset -n openshift-logging
oc get pod -n openshift-logging -o wide

(出力例)

[root@bastion-01 logging]# oc get lokistack -n openshift-logging
NAME                AGE
logging-lokistack   3m15s
[root@bastion-01 logging]#

[root@bastion-01 logging]# oc get statefulset -n openshift-logging
NAME                              READY   AGE
logging-lokistack-compactor       1/1     3m54s
logging-lokistack-index-gateway   2/2     3m53s
logging-lokistack-ingester        2/2     3m54s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator           1/1     1            1           228d
logging-lokistack-distributor      2/2     2            2           4m6s
logging-lokistack-gateway          2/2     2            2           4m5s
logging-lokistack-querier          2/2     2            2           4m6s
logging-lokistack-query-frontend   2/2     2            2           4m5s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get daemonset -n openshift-logging
No resources found in openshift-logging namespace.
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get pod -n openshift-logging -o wide
NAME                                                READY   STATUS    RESTARTS   AGE     IP            NODE        NOMINATED NODE   READINESS GATES
cluster-logging-operator-75f4d8848d-gl6w7           1/1     Running   1          5d5h    10.131.2.9    worker-01   <none>           <none>
logging-lokistack-compactor-0                       1/1     Running   0          4m23s   10.129.2.20   infra-03    <none>           <none>
logging-lokistack-distributor-86dc454f9c-t9z6j      1/1     Running   0          4m24s   10.130.2.29   infra-01    <none>           <none>
logging-lokistack-distributor-86dc454f9c-tgh6j      1/1     Running   0          4m24s   10.129.2.17   infra-03    <none>           <none>
logging-lokistack-gateway-6c8445c574-nmwst          2/2     Running   0          4m23s   10.129.2.19   infra-03    <none>           <none>
logging-lokistack-gateway-6c8445c574-zwlcf          2/2     Running   0          4m23s   10.130.2.31   infra-01    <none>           <none>
logging-lokistack-index-gateway-0                   1/1     Running   0          4m23s   10.128.2.43   infra-02    <none>           <none>
logging-lokistack-index-gateway-1                   1/1     Running   0          3m58s   10.129.2.21   infra-03    <none>           <none>
logging-lokistack-ingester-0                        1/1     Running   0          4m24s   10.130.2.32   infra-01    <none>           <none>
logging-lokistack-ingester-1                        1/1     Running   0          3m17s   10.128.2.44   infra-02    <none>           <none>
logging-lokistack-querier-5c5c5d95f-hdgc5           1/1     Running   0          4m24s   10.128.2.41   infra-02    <none>           <none>
logging-lokistack-querier-5c5c5d95f-hpjvt           1/1     Running   0          4m23s   10.129.2.18   infra-03    <none>           <none>
logging-lokistack-query-frontend-55c9c85cb5-d5459   1/1     Running   0          4m23s   10.128.2.42   infra-02    <none>           <none>
logging-lokistack-query-frontend-55c9c85cb5-pb5cw   1/1     Running   0          4m23s   10.130.2.30   infra-01    <none>           <none>
[root@bastion-01 logging]#

永続ボリュームは以下のものができていました。

oc get pvc -n openshift-logging

(出力例)

[root@bastion-01 logging]# oc get pvc -n openshift-logging
NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
storage-logging-lokistack-compactor-0       Bound    pvc-66efb0c6-69f9-4e8d-9643-0edf884d8ee1   10Gi       RWO            ocs-storagecluster-ceph-rbd   5m18s
storage-logging-lokistack-index-gateway-0   Bound    pvc-1d88109d-e691-4359-a735-72389585a72d   50Gi       RWO            ocs-storagecluster-ceph-rbd   5m17s
storage-logging-lokistack-index-gateway-1   Bound    pvc-c5ac7e21-5f98-4168-a2ed-d33e6bf4105c   50Gi       RWO            ocs-storagecluster-ceph-rbd   4m52s
storage-logging-lokistack-ingester-0        Bound    pvc-8da56254-9079-476a-86d4-9a2588f8dd75   10Gi       RWO            ocs-storagecluster-ceph-rbd   5m18s
storage-logging-lokistack-ingester-1        Bound    pvc-1b6361a6-848a-460d-ad3e-296753db1486   10Gi       RWO            ocs-storagecluster-ceph-rbd   4m11s
wal-logging-lokistack-ingester-0            Bound    pvc-c47e8458-cfd0-49b0-b95e-8252911ad016   150Gi      RWO            ocs-storagecluster-ceph-rbd   5m18s
wal-logging-lokistack-ingester-1            Bound    pvc-afef2a4e-4829-404b-b38c-ece5a8611ae6   150Gi      RWO            ocs-storagecluster-ceph-rbd   4m11s
[root@bastion-01 logging]#

ClusterLoggingカスタムリソースの作成

最終的な設定

ClusterLoggingのカスタムリソースを作成します。

こちらは以下の設定と全く同じにしていますのでそちらをご参照ください。

Qiita / ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた / (3) ClusterLoggingカスタムリソースの作成(lokistackのデプロイ、vectorの有効化) / 最終的な設定

[root@bastion-01 logging]# vi clo-instance-5.6-lokistack.yaml
[root@bastion-01 logging]# cat clo-instance-5.6-lokistack.yaml

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: "openshift-logging"
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-lokistack
  collection:
    tolerations:
    - effect: NoSchedule
      key: node.ocs.openshift.io/storage
      value: "true"
    type: "vector"

ClusterLoggingのマニフェストの適用

作成したマニフェストファイルを適用します。

oc apply -f clo-instance-5.6-lokistack.yaml

(出力例)

[root@bastion-01 logging]# oc apply -f clo-instance-5.6-lokistack.yaml
clusterlogging.logging.openshift.io/instance created
[root@bastion-01 logging]#

確認します。

oc get clusterlogging -n openshift-logging

oc get statefulset -n openshift-logging
oc get deployment -n openshift-logging
oc get daemonset -n openshift-logging
oc get pod -n openshift-logging -o wide

(出力例)

[root@bastion-01 logging]# oc get clusterlogging -n openshift-logging
NAME       MANAGEMENT STATE
instance   Managed
[root@bastion-01 logging]#

LokiStackはすでに入っていたので、colectionとしてvectorがdaemonsetとして追加されました。

[root@bastion-01 logging]# oc get statefulset -n openshift-logging
NAME                              READY   AGE
logging-lokistack-compactor       1/1     12m
logging-lokistack-index-gateway   2/2     12m
logging-lokistack-ingester        2/2     12m
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator           1/1     1            1           228d
logging-lokistack-distributor      2/2     2            2           12m
logging-lokistack-gateway          2/2     2            2           12m
logging-lokistack-querier          2/2     2            2           12m
logging-lokistack-query-frontend   2/2     2            2           12m
logging-view-plugin                1/1     1            1           84s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get daemonset -n openshift-logging
NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
collector   11        11        11      11           11          kubernetes.io/os=linux   101s
[root@bastion-01 logging]#

vectorはtolerationsの設定が効いて、ODF専用のInfra node上でも稼働しています。

[root@bastion-01 logging]# oc get pod -n openshift-logging -o wide
NAME                                                READY   STATUS    RESTARTS   AGE    IP             NODE         NOMINATED NODE   READINESS GATES
cluster-logging-operator-75f4d8848d-gl6w7           1/1     Running   1          5d5h   10.131.2.9     worker-01    <none>           <none>
collector-4mc5s                                     2/2     Running   0          111s   10.129.0.35    master-02    <none>           <none>
collector-4tgz7                                     2/2     Running   0          111s   10.129.2.22    infra-03     <none>           <none>
collector-4v2wb                                     2/2     Running   0          111s   10.128.0.38    master-01    <none>           <none>
collector-gwtnw                                     2/2     Running   0          111s   10.130.2.33    infra-01     <none>           <none>
collector-j29t4                                     2/2     Running   0          111s   10.131.0.14    worker-02    <none>           <none>
collector-n2bzl                                     2/2     Running   0          111s   10.128.2.45    infra-02     <none>           <none>
collector-nht48                                     2/2     Running   0          111s   10.131.2.11    worker-01    <none>           <none>
collector-nx5xb                                     2/2     Running   0          111s   10.128.4.31    storage-01   <none>           <none>
collector-qdzzr                                     2/2     Running   0          111s   10.130.4.34    storage-03   <none>           <none>
collector-zrv6d                                     2/2     Running   0          111s   10.130.0.140   master-03    <none>           <none>
collector-zxrqq                                     2/2     Running   0          111s   10.129.4.41    storage-02   <none>           <none>
logging-lokistack-compactor-0                       1/1     Running   0          12m    10.129.2.20    infra-03     <none>           <none>
logging-lokistack-distributor-86dc454f9c-t9z6j      1/1     Running   0          12m    10.130.2.29    infra-01     <none>           <none>
logging-lokistack-distributor-86dc454f9c-tgh6j      1/1     Running   0          12m    10.129.2.17    infra-03     <none>           <none>
logging-lokistack-gateway-6c8445c574-nmwst          2/2     Running   0          12m    10.129.2.19    infra-03     <none>           <none>
logging-lokistack-gateway-6c8445c574-zwlcf          2/2     Running   0          12m    10.130.2.31    infra-01     <none>           <none>
logging-lokistack-index-gateway-0                   1/1     Running   0          12m    10.128.2.43    infra-02     <none>           <none>
logging-lokistack-index-gateway-1                   1/1     Running   0          12m    10.129.2.21    infra-03     <none>           <none>
logging-lokistack-ingester-0                        1/1     Running   0          12m    10.130.2.32    infra-01     <none>           <none>
logging-lokistack-ingester-1                        1/1     Running   0          11m    10.128.2.44    infra-02     <none>           <none>
logging-lokistack-querier-5c5c5d95f-hdgc5           1/1     Running   0          12m    10.128.2.41    infra-02     <none>           <none>
logging-lokistack-querier-5c5c5d95f-hpjvt           1/1     Running   0          12m    10.129.2.18    infra-03     <none>           <none>
logging-lokistack-query-frontend-55c9c85cb5-d5459   1/1     Running   0          12m    10.128.2.42    infra-02     <none>           <none>
logging-lokistack-query-frontend-55c9c85cb5-pb5cw   1/1     Running   0          12m    10.130.2.30    infra-01     <none>           <none>
logging-view-plugin-5c87d776ff-l8jgl                1/1     Running   0          112s   10.131.0.13    worker-02    <none>           <none>
[root@bastion-01 logging]#

ログコンソールプラグインの有効化

こちらは「(4) ログコンソールプラグインの有効化」の通りですので、割愛します。

確認

ログの確認 (Retention前)

ログの種別としてapplications、infrastructure、auditが選択できます。

infrastructureに変更するとinfrastructure関連のログが表示されます。
infrastructureのログは2023/02/26 3:00前後から記録されています。
今回は、テナントがinfrastructureのRetentionは1dと設定していますので1日ちょっと時間が経ってからログが削除されているか確認します。

アプリケーションPod用のnamespaceのログがあった場合は、ログの種別としてapplicationを選択することで表示することができます。
今回はtest namespaceにnginxのアプリPodをデプロイして、2023/02/26 3:00頃だけちょっとアクセスして、ログを記録しました。その後の時間は何もログがありません。
こちらもテナントがapplicationのRetentionは1日、その中でtestから始まるnamespaceのRetentionは2dと設定しているので、こちらも1日ちょっと経ってからどうなるか確認します。

Retentionの設定の確認

Loki関連の設定は、OCP 4.12 Docs / ロギング / 5. Loki / 5.4. ログのLokiStackの転送 / 5.4.1. "entry out of order" エラーのトラブルシューティングで、間接的にloki.yamlにするとドキュメントに書かれています。しかし、どうやってloki.yamlに設定をするのかは全く記載がありません。。

またOSSの方のGrafana Loki / Configuring Grafana Lokiを参照すると、やはりLokiの設定ファイルはloki.yamlのようでした。

OCPのドキュメントには書かれていませんが、Loki OperatorでLokiStackを導入している場合は、このloki.yamlの設定を変更する場合は、LokiStackのカスタムリソースで設定をする必要があると思われます。

今回のRetentionの設定は、前述の通りLokiStackのリソースで以下のように設定しています。

[root@bastion-01 logging]# vi lokistack.yaml
[root@bastion-01 logging]# cat lokistack.yaml

lokistack.yaml

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-lokistack
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 3
    tenants:
      application:
        retention:
          days: 1
          streams:
            - days: 2
              selector: '{kubernetes_namespace_name=~"test.+"}'
      infrastructure:
        retention:
          days: 1
  tenants:
  (略)

Loki Operatorでは、先ほどのloki.yamlに相当する設定ファイルはlogging-lokistack-configという名前のConfigmap内のbinaryDataのconfig.yamlとruntime-config.yamlというものに対応し、ここに先ほどのKind: LokiStackのカスタムリソースの設定が反映しているようでした。

[root@bastion-01 ~]# oc get cm -n openshift-logging logging-lokistack-config
NAME                       DATA   AGE
logging-lokistack-config   2      43m
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc describe cm -n openshift-logging logging-lokistack-config
Name:         logging-lokistack-config
Namespace:    openshift-logging
(略)
Data
====

BinaryData
====
config.yaml: 8600 bytes
runtime-config.yaml: 210 bytes

Events:  <none>
[root@bastion-01 ~]#

このうち、config.yamlはLokiStack全体の設定ファイルとなり、Kind: LokiStackのカスタムリソースのspec.limits.global.retentionの設定が反映するようです。
また、テナント毎のRetentionのspec.limits.tenantsの設定はruntime-config.yamlに反映されて適用されるようです。

config.yamlの中身

spec.limits.global.retention.daysの設定は、limits_configの箇所に反映している？？

[root@bastion-01 ~]# oc get cm -n openshift-logging logging-lokistack-config -o json | jq -r '.binaryData."config.yaml"' | base64 -d

(略)
# NOTE: Keep the order of keys as in Loki docs
# to enable easy diffs when vendoring newer
# Loki releases.
# (See https://grafana.com/docs/loki/latest/configuration/#limits_config)
#
# Values for not exposed fields are taken from the grafana/loki production
# configuration manifests.
# (See https://github.com/grafana/loki/blob/main/production/ksonnet/loki/config.libsonnet)
limits_config:
  ingestion_rate_strategy: global
  ingestion_rate_mb: 15
  ingestion_burst_size_mb: 20
  max_label_name_length: 1024
  max_label_value_length: 2048
  max_label_names_per_series: 30
  reject_old_samples: true
  reject_old_samples_max_age: 168h
  creation_grace_period: 10m
  enforce_metric_name: false
  # Keep max_streams_per_user always to 0 to default
  # using max_global_streams_per_user always.
  # (See https://github.com/grafana/loki/blob/main/pkg/ingester/limiter.go#L73)
  max_streams_per_user: 0
  max_line_size: 256000
  max_entries_limit_per_query: 5000
  max_global_streams_per_user: 10000
  max_chunks_per_query: 2000000
  max_query_length: 721h
  max_query_parallelism: 32
  max_query_series: 500
  cardinality_limit: 100000
  max_streams_matchers_per_query: 1000
  query_timeout: 1m
  retention_period: 3d                             # 設定されたのは多分ここ？？？
  max_cache_freshness_per_query: 10m
  per_stream_rate_limit: 3MB
  per_stream_rate_limit_burst: 15MB
  split_queries_by_interval: 30m
memberlist:
  abort_if_cluster_join_fails: true
  bind_port: 7946
  join_members:
    - logging-lokistack-gossip-ring.openshift-logging.svc.cluster.local:7946
  max_join_backoff: 1m
  max_join_retries: 10
  min_join_backoff: 1s
(略)

runtime-config.yamlの中身

spec.limits.tenantsで設定したテナント毎のRetentionの設定が反映していると思われます。

[root@bastion-01 ~]# oc get cm -n openshift-logging logging-lokistack-config -o json | jq -r '.binaryData."runtime-config.yaml"' | base64 -d

---
overrides:
  application:
    retention_period: 1d
    retention_stream:
    - selector: '{kubernetes_namespace_name=~"test.+"}'
      priority: 1
      period: 2d
  infrastructure:
    retention_period: 1d

上述を見ると、一応設定はConfigmapに正しく反映してそうですので、あとは、少し時間をおいてみてみることにします。

Retention後の確認

ClusterLoggingのインスタンスの作成日時は「2023/02/26 3:03」です。
それから「1日と17時間ぐらい」経った時間でログとディスク容量を確認してみます。

ログの確認(`infrastructure`)

テナントがinfrastructureのretentoin_periodは1dと設定していました。

実際のにログを確認します。
テナントがinfrastractureのログをLast 2 daysで表示したところ、最新のログは2/27 19:49ぐらいでした。

Date列で並べ替えると、一番古いログは、2/26 16:53ぐらいでした。

ですので、ClusterLoggingインスタンスを作成した直後からのログは削除され、「1日と3時間」ぐらい前からのログしか残っていないように思われます。

ログの確認(`application`)

テナントがapplicationのretentoin_periodは1dと設定していました。

ClusterLoggingインスタンスの作成直後だけtest namespaceにサンプルアプリを入れて少しだけログが出るようにしていましたが、テナントがapplicationのログはLast 2 daysで表示しても何も表示されませんでした。
従って、おそらくこの1dの設定が効いてログが削除されていると思われます。

(一方、applicationの内、testから始まるnamespaceのログは2dまで残すという設定ができるのか？と試してみた設定については、ログが消えてしまっていたので、application.retention_periodより短くは設定できないと思われます。)

オブジェクトストレージのディスク使用量

メトリクス欄で使用されている容量を表示すると、以下の感じでした。

openshift-storage namespaceのLokiStackのログ保管領域としての、ODFのバッキングストアのバックエンドのPVCの容量は1日ちょっとしたあたりから一定の容量になっているようでした。
これは、1日ちょっとしたあたりから、Retentionの1dの設定が聞いて、1日前のログが消えていくため、1日程度たった後は、その時までのディスク使用量の15-16GB位でずっと推移しているように見えました。

メトリクス例 (openshift-storage namespaceのPVC)

sum(kubelet_volume_stats_used_bytes{namespace="openshift-storage"}) by (namespace, persistentvolumeclaim) / (1024 * 1024 * 1024)

OpenShift Data Foudationの方の画面からも確認してみます。

Object Storageを使っているかは、Data Foundationの画面から確認できます。

OCPコンソールの左側のメニューからストレージ -> Data Foudationを選択して「ストレージシステム」タブを選択し、表示されるストレージシステムのエントリー(ocs-storagecluster-storagesystem)をクリックします。

「Object」タブを選択すると、ObjectStorageのMulticloud Object Gateway 経由で使用しているバケットの容量が確認できます。
こちらを確認すると、15GBちょっとのディスク容量を使用していることがわかります。

また、PVCの容量は、ストレージ -> 永続ボリューム要求画面で確認できます。
LokiStackの使用するオブジェクトストレージのバッキングストアのバックエンドのPVCのディスクの使用済み容量は「4〜7GiB」で合計「15-16GB」程度でした。

補足(永続ボリューム)

LokiStackはオブジェクトストレージ以外にも、いくつかのStatefulsetが使用する永続ボリュームがあります。
PVCの容量は、ストレージ -> 永続ボリューム要求画面で確認できます。
openshift-logging namespaceのLokiStackのStatefulSetに関連するPVCのディスク使用率はほぼない状況でした。

またメトリクスで推移を確認してみても、ログ自体が多く出力されていないような環境では、そこまで容量は多くは使われていないようでした。ですのでPVの方はそこまで溢れることはないのではと思われます。

メトリクス例(openshift-logging namespaceのPVC)

sum(kubelet_volume_stats_used_bytes{namespace="openshift-logging"}) by (namespace, persistentvolumeclaim) / (1024 * 1024 * 1024)

まとめ

Red Hat OpenShift Logging 5.6 + Loki Operator 5.6からは、ちゃんとログのRetentionの設定ができるようになりました。
実際にテナント(infrastructure、application)毎のRetentionの設定を1dとてみたところ、大体1日ちょっとぐらいでちゃんとログが削除されて、オブジェクトストレージの容量が溢れることは無くなったようでした。
これでEFKスタックの時と同じようにディスクのRetentionの設定がLokiStackでもできるようになっているようですので一安心かなと思います。

OpenShiftのロギング(LokiStack)でログの保持期間の設定をする(OpenShift 4.12 + LokiStack 5.6)

概要

環境

OCP構成

ノード構成

Operator構成

ストレージ関連

ロギング関連

構成

手順概要

手順

事前準備

LokiStackカスタムリソースの作成

ログのRetentionの設定方法

LokiStackカスタムリソースの作成 (ログののRetentionの設定部分)

最終的な設定

LokiStackのマニフェストの適用

ClusterLoggingカスタムリソースの作成

最終的な設定

ClusterLoggingのマニフェストの適用

ログコンソールプラグインの有効化

確認

ログの確認 (Retention前)

Retentionの設定の確認

Retention後の確認

ログの確認(infrastructure)

ログの確認(application)

オブジェクトストレージのディスク使用量

補足(永続ボリューム)

まとめ

ログの確認(`infrastructure`)

ログの確認(`application`)