2.5. LokiStack でのログの保存

手順

1. AlertingRule カスタムリソース (CR) を作成します。

   インフラストラクチャー AlertingRule CR の例

     apiVersion: loki.grafana.com/v1
     kind: AlertingRule
     metadata:
       name: loki-operator-alerts
       namespace: openshift-operators-redhat 1
       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: critical 5
               annotations:
                 summary: High Loki Operator Reconciliation Errors 6
                 description: High Loki Operator Reconciliation Errors 7

   1

   この AlertingRule CR が作成される namespace には、LokiStack spec.rules.namespaceSelector 定義に一致するラベルが必要です。

   2

   labels ブロックは、LokiStack の spec.rules.selector 定義と一致する必要があります。

   3

   infrastructure テナントの AlertingRule CR は、openshift-*、kube-\*、または default namespaces でのみサポートされます。

   4

   kubernetes_namespace_name: の値は、metadata.namespace の値と一致する必要があります。

   5

   この必須フィールドの値は、critical、warning、または info である必要があります。

   6

   このフィールドは必須です。

   7

   このフィールドは必須です。

   アプリケーション AlertingRule CR の例

     apiVersion: loki.grafana.com/v1
     kind: AlertingRule
     metadata:
       name: app-user-workload
       namespace: app-ns 1
       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: critical 4
               annotations:
                 summary:  5
                 description:  6

   1

   この AlertingRule CR が作成される namespace には、LokiStack spec.rules.namespaceSelector 定義に一致するラベルが必要です。

   2

   labels ブロックは、LokiStack の spec.rules.selector 定義と一致する必要があります。

   3

   kubernetes_namespace_name: の値は、metadata.namespace の値と一致する必要があります。

   4

   この必須フィールドの値は、critical、warning、または info である必要があります。

   5

   この必須フィールドの値は、ルールの概要です。

   6

   この必須フィールドの値は、ルールの詳細な説明です。

2. AlertingRule CR を適用します。

   $ oc apply -f <filename>.yaml

手順

1. LokiStack CR を作成します。

   • 以下の例のように、ストリームベースの保持をグローバルに有効にします。

     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 クエリー が含まれています。

2. LokiStack CR を適用します。

   $ oc apply -f <filename>.yaml

   注記

   これは、保存されたログの保持を管理するためのものではありません。保存されたログのグローバルな保持期間 (最大 30 日間までサポート) は、オブジェクトストレージで設定します。

手順

1. 次のコマンドを実行して、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 ステータスになっています。

2. 次のコマンドを実行して、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

3. 次のコマンドを実行して Pod の PVC を削除します。

   $ oc delete pvc <pvc_name>  -n openshift-logging

4. 次のコマンドを実行して Pod を削除します。

   $ oc delete pod <pod_name>  -n openshift-logging

   これらのオブジェクトが正常に削除されると、使用可能なゾーンでオブジェクトが自動的に再スケジュールされます。