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

OpenShift Container Platform は Elasticsearch (ES) を使用してログデータを保存し、整理します。

ログストアに加えることのできる変更には、以下が含まれます。

  • Elasticsearch クラスターのストレージ。
  • シャードをクラスター内の複数のデータノードにレプリケートする方法 (完全なレプリケーションからレプリケーションなしを含む)。
  • Elasticsearch データへの外部アクセスを許可する。
注記

Elasticsearch ノードのスケールダウンはサポートされていません。スケールダウン時に Elasticsearch Pod が誤って削除される場合があり、その場合にはシャードが割り当てられず、レプリカシャードが失われる可能性があります。

Elasticsearch はメモリー集約型アプリケーションです。それぞれの Elasticsearch ノードには、クラスターロギングのカスタムリソースで指定しない限り、メモリー要求および制限の両方に 16G のメモリーが必要です。初期設定の OpenShift Container Platform ノードのセットは、Elasticsearch クラスターをサポートするのに十分な大きさではない場合があります。その場合、推奨されるサイズ以上のメモリーを使用して実行できるようにノードを OpenShift Container Platform クラスターに追加する必要があります。

各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境でのデプロイメントには推奨されません。

注記

Elasticsearch Operator (EO) を管理外の状態に設定し、Cluster Logging Operator (CLO) を管理対象のままにする場合、CLO は EO に加えた変更を元に戻します。EO は CLO によって管理されているためです。

7.4.1. Elasticsearch CPU およびメモリー制限の設定

それぞれのコンポーネント仕様は、CPU とメモリーの両方への調整を許可します。Elasticsearch Operator は環境に適した値を設定するため、これらの値を手動で調整する必要はありません。

各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境でのデプロイメントには推奨 されていません。実稼働環境での使用の場合には、デフォルトの 16Gi よりも小さい値を各 Pod に割り当てることはできません。 Pod ごとに割り当て可能な最大値は 64Gi であり、この範囲の中で、できるだけ多くのメモリーを割り当てることを推奨します。

前提条件

  • クラスターロギングおよび 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 が指定された制限を使用することを許可しません。requestslimites に同じ値を設定することにより、Elasticseach は必要な CPU およびメモリーを確実に使用できるようにします (利用可能な CPU およびメモリーがノードにあることを前提とします)。

7.4.2. Elasticsearch レプリケーションポリシーの設定

Elasticsearch シャードをクラスター内の複数のデータノードにレプリケートする方法を定義できます。

前提条件

  • クラスターロギングおよび Elasticsearch がインストールされていること。

手順

  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 バックアップ/復元ストラテジーを実装している場合は、このモードを使用できます。
注記

インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。

7.4.3. Elasticsearch ストレージの設定

Elasticsearch には永続ストレージが必要です。ストレージが高速になると、Elasticsearch のパフォーマンスも高速になります。

警告

NFS ストレージをボリュームまたは永続ボリュームを使用 (または Gluster などの NAS を使用する) ことは Elasticsearch ストレージではサポートされません。Lucene は NFS が指定しないファイルシステムの動作に依存するためです。データの破損およびその他の問題が発生する可能性があります。

前提条件

  • クラスターロギングおよび Elasticsearch がインストールされていること。

手順

  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"

この例では、クラスターの各データノードが、「200G」の AWS General Purpose SSD (gp2) ストレージを要求する Persistent Volume Claim (永続ボリューム要求、PVC) にバインドされるように指定します。

7.4.4. Elasticsearch での emptyDir ストレージの設定

Elasticsearch で emptyDir を使用することができます。これは、Pod のデータすべてが再起動時に失われる一時デプロイメントを作成します。

注記

emptyDir を使用する場合、Elasticsearch が再起動するか、または再デプロイされる場合にデータが失われます。

前提条件

  • クラスターロギングおよび Elasticsearch がインストールされていること。

手順

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

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

7.4.5. Elasticsearch のルートとしての公開

デフォルトでは、クラスターロギングでデプロイされた Elasticsearch はロギングクラスターの外部からアクセスできません。データにアクセスするツールについては、Elasticsearch へ外部アクセスするために re-encryption termination でルートを有効にすることができます。

re-encrypt ルート、OpenShift Container Platform トークンおよびインストールされた Elasticsearch CA 証明書を作成して Elasticsearch に外部からアクセスすることができます。次に、以下を含む cURL 要求を持つ Elasticsearch ノードにアクセスします。

内部からは、Elasticsearch クラスター IP を使用して Elastiscearch にアクセスすることができます。

以下のコマンドのいずれかを使用して、Elasticsearch クラスター IP を取得できます。

$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging

172.30.183.229
oc get service elasticsearch

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
elasticsearch   ClusterIP   172.30.183.229   <none>        9200/TCP   22h

$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    29  100    29    0     0    108      0 --:--:-- --:--:-- --:--:--   108

前提条件

  • クラスターロギングおよび Elasticsearch がインストールされていること。
  • ログにアクセスできるようになるには、プロジェクトへのアクセスが必要です。

手順

Elasticsearch を外部に公開するには、以下を実行します。

  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.keyspec.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"
              }
            }
          ]
        }
      }

7.4.6. Elasticsearch アラートルール

これらのアラートルールを Prometheus に表示できます。

アラート説明重大度

ElasticsearchClusterNotHealthy

クラスターのヘルスステータスは少なくとも 2m の間 RED になります。クラスターは書き込みを受け入れず、シャードが見つからない可能性があるか、またはマスターノードがまだ選択されていません。

critical

ElasticsearchClusterNotHealthy

クラスターのヘルスステータスは少なくとも 20m の間 YELLOW になります。一部のシャードレプリカは割り当てられません。

warning

ElasticsearchBulkRequestsRejectionJumps

クラスターのノードにおける高いバルク除去率 (High Bulk Rejection Ratio) を示します。このノードはインデックスの速度に追い付いていない可能性があります。

warning

ElasticsearchNodeDiskWatermarkReached

クラスターのノードでディスクの低い基準値に達しています。シャードをこのノードに割り当てることはできません。ノードにディスク領域を追加することを検討する必要があります。

alert

ElasticsearchNodeDiskWatermarkReached

クラスターのノードでディスクの高い基準値に達しています。一部のシャードは可能な場合に別のノードに再度割り当てられる可能性があります。ノードにディスク領域が追加されるか、またはこのノードに割り当てられる古いインデックスをドロップします。

high

ElasticsearchJVMHeapUseHigh

クラスター内のノード上での JVM ヒープの使用量は <value> です。

alert

AggregatedLoggingSystemCPUHigh

クラスター内のノード上でのシステム CPU の使用量は <value> です。

alert

ElasticsearchProcessCPUHigh

クラスター内のノード上での ES プロセス CPU の使用量は <value> です。

alert


このページには機械翻訳が使用されている場合があります (詳細はこちら)。