7.4. ログデータを保存し、整理するための Elasticsearch の設定

手順

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

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   ....
   spec:
       logStore:
         type: "elasticsearch"
         elasticsearch:
           resources: 1
             limits:
               memory: 16Gi
             requests:
               cpu: 500m
               memory: 16Gi

   1

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

   Elasticsearch の CPU およびメモリーの容量を調整する場合、要求値と制限値の両方を変更する必要があります。

   以下は例になります。

         resources:
           limits:
             cpu: "8"
             memory: "32Gi"
           requests:
             cpu: "8"
             memory: "32Gi"

   Kubernetes は一般的にはノードの CPU 設定に従い、Elasticsearch が指定された制限を使用することを許可しません。requests と limites に同じ値を設定することにより、Elasticseach は必要な CPU およびメモリーを確実に使用できるようにします (利用可能な CPU およびメモリーがノードにあることを前提とします)。

手順

1. openshift-logging プロジェクトでクラスターロギングのカスタムリソース (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. クラスターロギング CR を編集してクラスターの各データノードが Persistent Volume Claim (永続ボリューム要求、PVC) にバインドされるように指定します。

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

手順

1. クラスターロギング CR を編集して emptyDir を指定します。

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

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

   $ oc project openshift-logging

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

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

3. Elasticsearch サービスのルートを 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

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

   2. 以下のコマンドを実行して作成したルート YAML に Elasticsearch 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. 要求に使用されるこの ServiceAccount のトークンを取得します。

      $ 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}/.operations.*/_search?size=1" | jq

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

        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
      100   944  100   944    0     0     62      0  0:00:15  0:00:15 --:--:--   204
      {
        "took": 441,
        "timed_out": false,
        "_shards": {
          "total": 3,
          "successful": 3,
          "skipped": 0,
          "failed": 0
        },
        "hits": {
          "total": 89157,
          "max_score": 1,
          "hits": [
            {
              "_index": ".operations.2019.03.15",
              "_type": "com.example.viaq.common",
              "_id": "ODdiNWIyYzAtMjg5Ni0TAtNWE3MDY1MjMzNTc3",
              "_score": 1,
              "_source": {
                "_SOURCE_MONOTONIC_TIMESTAMP": "673396",
                "systemd": {
                  "t": {
                    "BOOT_ID": "246c34ee9cdeecb41a608e94",
                    "MACHINE_ID": "e904a0bb5efd3e36badee0c",
                    "TRANSPORT": "kernel"
                  },
                  "u": {
                    "SYSLOG_FACILITY": "0",
                    "SYSLOG_IDENTIFIER": "kernel"
                  }
                },
                "level": "info",
                "message": "acpiphp: Slot [30] registered",
                "hostname": "localhost.localdomain",
                "pipeline_metadata": {
                  "collector": {
                    "ipaddr4": "10.128.2.12",
                    "ipaddr6": "fe80::xx:xxxx:fe4c:5b09",
                    "inputname": "fluent-plugin-systemd",
                    "name": "fluentd",
                    "received_at": "2019-03-15T20:25:06.273017+00:00",
                    "version": "1.3.2 1.6.0"
                  }
                },
                "@timestamp": "2019-03-15T20:00:13.808226+00:00",
                "viaq_msg_id": "ODdiNWIyYzAtMYTAtNWE3MDY1MjMzNTc3"
              }
            }
          ]
        }
      }