10.4. Elasticsearch ログストアの設定

手順

1. ClusterLogging CR の logStore 仕様を変更します。

   ClusterLogging CR の例

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
   # ...
   spec:
   # ...
     logStore:
       type: <log_store_type> 1
       elasticsearch: 2
         nodeCount: <integer>
         resources: {}
         storage: {}
         redundancyPolicy: <redundancy_type> 3
       lokistack: 4
         name: {}
   # ...

   1

   ログストアのタイプを指定します。これは lokistack または elasticsearch のいずれかです。

   2

   Elasticsearch ログストアの任意の設定オプション。

   3

   冗長性のタイプを指定します。この値には、ZeroRedundancy、SingleRedundancy、MultipleRedundancy、または FullRedundancy を指定できます。

   4

   LokiStack の任意の設定オプション。

   LokiStack をログストアとして指定する ClusterLogging CR の例

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     managementState: Managed
     logStore:
       type: lokistack
       lokistack:
         name: logging-loki
   # ...

2. 次のコマンドを実行して、ClusterLogging CR を適用します。

   $ oc apply -f <filename>.yaml

1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

   • すべてのログタイプを内部 Elasticsearch インスタンスに送信するために CR を作成します。変更せずに以下の例を使用できます。

     apiVersion: logging.openshift.io/v1
     kind: ClusterLogForwarder
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       pipelines: 1
       - name: all-to-default
         inputRefs:
         - infrastructure
         - application
         - audit
         outputRefs:
         - default

     1

     パイプラインは、指定された出力を使用して転送するログのタイプを定義します。デフォルトの出力は、ログを内部 Elasticsearch インスタンスに転送します。

     注記

     パイプラインの 3 つのすべてのタイプのログをパイプラインに指定する必要があります (アプリケーション、インフラストラクチャー、および監査)。ログの種類を指定しない場合、それらのログは保存されず、失われます。

   • 既存の ClusterLogForwarder CR がある場合は、パイプラインを監査ログのデフォルト出力に追加します。デフォルトの出力を定義する必要はありません。以下に例を示します。

     apiVersion: "logging.openshift.io/v1"
     kind: ClusterLogForwarder
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       outputs:
        - name: elasticsearch-insecure
          type: "elasticsearch"
          url: http://elasticsearch-insecure.messaging.svc.cluster.local
          insecure: true
        - name: elasticsearch-secure
          type: "elasticsearch"
          url: https://elasticsearch-secure.messaging.svc.cluster.local
          secret:
            name: es-audit
        - name: secureforward-offcluster
          type: "fluentdForward"
          url: https://secureforward.offcluster.com:24224
          secret:
            name: secureforward
       pipelines:
        - name: container-logs
          inputRefs:
          - application
          outputRefs:
          - secureforward-offcluster
        - name: infra-logs
          inputRefs:
          - infrastructure
          outputRefs:
          - elasticsearch-insecure
        - name: audit-logs
          inputRefs:
          - audit
          outputRefs:
          - elasticsearch-secure
          - default 1

     1

     このパイプラインは、外部インスタンスに加えて監査ログを内部 Elasticsearch インスタンスに送信します。

1. ClusterLogging CR を編集して、retentionPolicy パラメーターを追加するか、変更します。

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   ...
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       retentionPolicy: 1
         application:
           maxAge: 1d
         infra:
           maxAge: 7d
         audit:
           maxAge: 7d
       elasticsearch:
         nodeCount: 3
   ...

   1

   Elasticsearch が各ログソースを保持する時間を指定します。整数および時間の指定 (weeks(w)、hour(h/H)、minutes(m)、および seconds(s)) を入力します。たとえば、1 日の場合は 1d になります。maxAge よりも古いログは削除されます。デフォルトで、ログは 7 日間保持されます。

2. Elasticsearch カスタムリソース (CR) で設定を確認できます。

   たとえば、Red Hat OpenShift Logging Operator は以下の Elasticsearch CR を更新し、8 時間ごとにインフラストラクチャーログのアクティブなインデックスをロールオーバーし、ロールオーバーされたインデックスはロールオーバーの 7 日後に削除される設定を含む保持ポリシーを設定するとします。OpenShift Container Platform は 15 分ごとにチェックし、インデックスをロールオーバーする必要があるかどうかを判別します。

   apiVersion: "logging.openshift.io/v1"
   kind: "Elasticsearch"
   metadata:
     name: "elasticsearch"
   spec:
   ...
     indexManagement:
       policies: 1
         - name: infra-policy
           phases:
             delete:
               minAge: 7d 2
             hot:
               actions:
                 rollover:
                   maxAge: 8h 3
           pollInterval: 15m 4
   ...

   1

   各ログソースについて、保持ポリシーは、そのソースのログを削除/ロールオーバーするタイミングを示します。

   2

   OpenShift Container Platform がロールオーバーされたインデックスを削除する場合。この設定は、ClusterLogging CR に設定する maxAge になります。

   3

   インデックスをロールオーバーする際に考慮する OpenShift Container Platform のインデックス期間。この値は、ClusterLogging CR に設定する maxAge に基づいて決定されます。

   4

   OpenShift Container Platform がインデックスをロールオーバーする必要があるかどうかをチェックする場合。この設定はデフォルトであるため、変更できません。

   注記

   Elasticsearch CR の変更はサポートされていません。保持ポリシーに対するすべての変更は ClusterLogging CR で行う必要があります。

   OpenShift Elasticsearch Operator は cron ジョブをデプロイし、pollInterval を使用してスケジュールされる定義されたポリシーを使用して各マッピングのインデックスをロールオーバーします。

   $ oc get cronjob

   出力例

   NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   elasticsearch-im-app     */15 * * * *   False     0        <none>          4s
   elasticsearch-im-audit   */15 * * * *   False     0        <none>          4s
   elasticsearch-im-infra   */15 * * * *   False     0        <none>          4s

手順

1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   ....
   spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:1
           resources:
             limits: 2
               memory: "32Gi"
             requests: 3
               cpu: "1"
               memory: "16Gi"
           proxy: 4
             resources:
               limits:
                 memory: 100Mi
               requests:
                 memory: 100Mi

   1

   必要に応じて CPU およびメモリー要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるはずです。デフォルト値は、メモリー要求の場合は 16Gi であり、CPU 要求の場合は 1 です。

   2

   Pod が使用できるリソースの最大量。

   3

   Pod のスケジュールに必要最小限のリソース。

   4

   必要に応じて Elasticsearch プロキシーの CPU およびメモリーの制限および要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるます。デフォルト値は、メモリー要求の場合は 256Mi、CPU 要求の場合は 100m です。

手順

1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

   $ oc edit clusterlogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     logStore:
       type: "elasticsearch"
       elasticsearch:
         redundancyPolicy: "SingleRedundancy" 1

   1

   シャードの冗長性ポリシーを指定します。変更の保存時に変更が適用されます。

   • FullRedundancy:Elasticsearch は、各インデックスのプライマリーシャードをすべてのデータノードに完全にレプリケートします。これは最高レベルの安全性を提供しますが、最大量のディスクが必要となり、パフォーマンスは最低レベルになります。
   • MultipleRedundancy:Elasticsearch は、各インデックスのプライマリーシャードをデータノードの半分に完全にレプリケートします。これは、安全性とパフォーマンス間の適切なトレードオフを提供します。
   • SingleRedundancy:Elasticsearch は、各インデックスのプライマリーシャードのコピーを 1 つ作成します。2 つ以上のデータノードが存在する限り、ログは常に利用可能かつ回復可能です。5 以上のノードを使用する場合は、MultipleRedundancy よりもパフォーマンスが良くなります。このポリシーは、単一 Elasticsearch ノードのデプロイメントには適用できません。
   • ZeroRedundancy:Elasticsearch は、プライマリーシャードのコピーを作成しません。ノードが停止または失敗した場合は、ログは利用不可となるか、失われる可能性があります。安全性よりもパフォーマンスを重視する場合や、独自のディスク/PVC バックアップ/復元ストラテジーを実装している場合は、このモードを使用できます。

手順

1. ClusterLogging CR を編集してクラスターの各データノードが永続ボリューム要求 (PVC) にバインドされるように指定します。

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   # ...
   spec:
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         storage:
           storageClassName: "gp2"
           size: "200G"

手順

1. ClusterLogging CR を編集して emptyDir を指定します。

    spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:
           nodeCount: 3
           storage: {}

1. openshift-logging プロジェクトに切り替えます。

   $ oc project openshift-logging

2. Elasticsearch Pod の名前を取得します。

   $ oc get pods -l component=elasticsearch

3. コレクター Pod をスケールダウンして、Elasticsearch への新しいログの送信を停止します。

   $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'

4. OpenShift Container Platform es_util ツールを使用してシャードの同期フラッシュを実行して、シャットダウンの前にディスクへの書き込みを待機している保留中の操作がないようにします。

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST

   以下に例を示します。

   $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST

   出力例

   {"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}

5. OpenShift Container Platform es_util ツールを使用して、ノードを意図的に停止する際のシャードのバランシングを防ぎます。

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

   以下に例を示します。

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

   出力例

   {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":

6. コマンドが完了したら、ES クラスターのそれぞれのデプロイメントについて、以下を実行します。

   1. デフォルトで、OpenShift Container Platform Elasticsearch クラスターはノードのロールアウトをブロックします。以下のコマンドを使用してロールアウトを許可し、Pod が変更を取得できるようにします。

      $ oc rollout resume deployment/<deployment-name>

      以下に例を示します。

      $ oc rollout resume deployment/elasticsearch-cdm-0-1

      出力例

      deployment.extensions/elasticsearch-cdm-0-1 resumed

      新規 Pod がデプロイされます。Pod に準備状態のコンテナーがある場合は、次のデプロイメントに進むことができます。

      $ oc get pods -l component=elasticsearch-

      出力例

      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h

   2. デプロイメントが完了したら、ロールアウトを許可しないように Pod をリセットします。

      $ oc rollout pause deployment/<deployment-name>

      以下に例を示します。

      $ oc rollout pause deployment/elasticsearch-cdm-0-1

      出力例

      deployment.extensions/elasticsearch-cdm-0-1 paused

   3. Elasticsearch クラスターが green または yellow 状態にあることを確認します。

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      注記

      直前のコマンドで使用した Elasticsearch Pod でロールアウトを実行した場合、Pod は存在しなくなっているため、ここで新規 Pod 名が必要になります。

      以下に例を示します。

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      {
        "cluster_name" : "elasticsearch",
        "status" : "yellow", 1
        "timed_out" : false,
        "number_of_nodes" : 3,
        "number_of_data_nodes" : 3,
        "active_primary_shards" : 8,
        "active_shards" : 16,
        "relocating_shards" : 0,
        "initializing_shards" : 0,
        "unassigned_shards" : 1,
        "delayed_unassigned_shards" : 0,
        "number_of_pending_tasks" : 0,
        "number_of_in_flight_fetch" : 0,
        "task_max_waiting_in_queue_millis" : 0,
        "active_shards_percent_as_number" : 100.0
      }

      1

      次に進む前に、このパラメーターが green または yellow であることを確認します。

7. Elasticsearch 設定マップを変更した場合は、それぞれの Elasticsearch Pod に対してこれらの手順を繰り返します。

8. クラスターのすべてのデプロイメントがロールアウトされたら、シャードのバランシングを再度有効にします。

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

   以下に例を示します。

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

   出力例

   {
     "acknowledged" : true,
     "persistent" : { },
     "transient" : {
       "cluster" : {
         "routing" : {
           "allocation" : {
             "enable" : "all"
           }
         }
       }
     }
   }

9. 新しいログが Elasticsearch に送信されるように、コレクター Pod をスケールアップします。

   $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'

1. openshift-logging プロジェクトに切り替えます。

   $ oc project openshift-logging

2. ログストアから CA 証明書を抽出し、admin-ca ファイルに書き込みます。

   $ oc extract secret/elasticsearch --to=. --keys=admin-ca

   出力例

   admin-ca

3. ログストアサービスのルートを YAML ファイルとして作成します。

   1. 以下のように YAML ファイルを作成します。

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: elasticsearch
        namespace: openshift-logging
      spec:
        host:
        to:
          kind: Service
          name: elasticsearch
        tls:
          termination: reencrypt
          destinationCACertificate: | 1

      1

      次の手順でログストア CA 証明書を追加するか、コマンドを使用します。一部の re-encrypt ルートで必要とされる spec.tls.key、spec.tls.certificate、および spec.tls.caCertificate パラメーターを設定する必要はありません。

   2. 以下のコマンドを実行して、前のステップで作成したルート YAML にログストア CA 証明書を追加します。

      $ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml

   3. ルートを作成します。

      $ oc create -f <file-name>.yaml

      出力例

      route.route.openshift.io/elasticsearch created

4. Elasticsearch サービスが公開されていることを確認します。

   1. 要求に使用されるこのサービスアカウントのトークンを取得します。

      $ token=$(oc whoami -t)

   2. 作成した elasticsearch ルートを環境変数として設定します。

      $ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`

   3. ルートが正常に作成されていることを確認するには、公開されたルート経由で Elasticsearch にアクセスする以下のコマンドを実行します。

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"

      以下のような出力が表示されます。

      出力例

      {
        "name" : "elasticsearch-cdm-i40ktba0-1",
        "cluster_name" : "elasticsearch",
        "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ",
        "version" : {
        "number" : "6.8.1",
        "build_flavor" : "oss",
        "build_type" : "zip",
        "build_hash" : "Unknown",
        "build_date" : "Unknown",
        "build_snapshot" : true,
        "lucene_version" : "7.7.0",
        "minimum_wire_compatibility_version" : "5.6.0",
        "minimum_index_compatibility_version" : "5.0.0"
      },
        "<tagline>" : "<for search>"
      }

手順

1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

   $ oc edit ClusterLogging instance

2. これらが存在する場合は、logStore、visualization スタンザを ClusterLogging CR から削除します。

3. ClusterLogging CR の collection スタンザを保持します。結果は以下の例のようになります。

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: "openshift-logging"
   spec:
     managementState: "Managed"
     collection:
       type: "fluentd"
       fluentd: {}

4. コレクター Pod が再デプロイされたことを確認します。

   $ oc get pods -l component=collector -n openshift-logging