ロギング

1. Elasticsearch Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から Elasticsearch Operator を選択し、Install をクリックします。
   3. All namespaces on the cluster が Installation Mode で選択されていることを確認します。

   4. openshift-operators-redhat が Installed Namespace で選択されていることを確認します。

      openshift-operators-redhat namespace を指定する必要があります。openshift-operators namespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。

   5. Enable operator recommended cluster monitoring on this namespace を選択します。

      このオプションは、namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニターリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

   6. Update Channel として 4.5 を選択します。

   7. Approval Strategy を選択します。

      • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
      • Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
   8. Install をクリックします。
   9. Operators → Installed Operators ページに切り替えて、Elasticsearch Operator がインストールされていることを確認します。
   10. Status が Succeeded の状態で、Elasticsearch Operator が すべてのプロジェクトに一覧表示されていることを確認します。

2. Cluster Logging Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から Cluster Logging を選択し、Install をクリックします。
   3. A specific namespace on the cluster が Installation Mode で選択されていることを確認します。
   4. Operator recommended namespace が Installed Namespace で openshift-logging になっていることを確認します。

   5. Enable operator recommended cluster monitoring on this namespace を選択します。

      このオプションは、namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニターリングが openshift-logging namespace を収集できるように、このオプションを選択する必要があります。

   6. Update Channel として 4.5 を選択します。

   7. Approval Strategy を選択します。

      • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
      • Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
   8. Install をクリックします。
   9. Operators → Installed Operators ページに切り替えて、Cluster Logging Operator がインストールされていることを確認します。

   10. Cluster Logging が Status が Succeeded の状態で openshift-logging プロジェクトに一覧表示されていることを確認します。

       Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

       • Operators → Installed Operators ページに切り替え、Status 列でエラーまたは失敗の有無を確認します。
       • Workloads → Pods ページに切り替え、 openshift-logging プロジェクトの Pod で問題を報告しているログの有無を確認します。

3. クラスターロギングのインスタンスを作成します。

   1. Administration → Custom Resource Definitions ページに切り替えます。
   2. Custom Resource Definitions ページで、ClusterLogging をクリックします。
   3. Custom Resource Definition Overview ページで、Actions メニューから View Instances を選択します。

   4. ClusterLoggings ページで、 Create ClusterLogging をクリックします。

      データを読み込むためにページを更新する必要がある場合があります。

   5. YAML フィールドで、コードを以下に置き換えます。

      注記

      このデフォルトのクラスターロギング設定は各種の環境をサポートすることが予想されます。クラスターロギングのクラスターに加えることのできる変更についての詳細は、クラスターロギングコンポーネントのチューニングおよび設定についてのトピックを確認してください。

      apiVersion: "logging.openshift.io/v1"
      kind: "ClusterLogging"
      metadata:
        name: "instance" 1
        namespace: "openshift-logging"
      spec:
        managementState: "Managed"  2
        logStore:
          type: "elasticsearch"  3
          retentionPolicy: 4
            application:
              maxAge: 1d
            infra:
              maxAge: 7d
            audit:
              maxAge: 7d
          elasticsearch:
            nodeCount: 3 5
            storage:
              storageClassName: "<storage-class-name>" 6
              size: 200G
            resources: 7
              requests:
                memory: "8Gi"
            proxy: 8
              resources:
                limits:
                  memory: 256Mi
                requests:
                   memory: 256Mi
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  9
          kibana:
            replicas: 1
        curation:
          type: "curator"
          curator:
            schedule: "30 3 * * *" 10
        collection:
          logs:
            type: "fluentd"  11
            fluentd: {}

      1

      名前は instance である必要があります。

      2

      クラスターロギングの管理状態。クラスターロギングのデフォルト値を変更する場合は、これを Unmanaged (管理外) に設定する必要がある場合があります。ただし、管理外のデプロイメントはクラスターロギングが管理対象の状態に戻されるまで更新を受信しません。

      3

      Elasticsearch の設定に必要な設定。CR を使用してシャードのレプリケーションポリシーおよび永続ストレージを設定できます。

      4

      Elasticsearch が各ログソースを保持する期間を指定します。整数および時間の指定 (weeks(w)、hour(h/H)、minutes(m)、および seconds(s)) を入力します。たとえば、7 日の場合は 7d となります。maxAge よりも古いログは削除されます。各ログソースの保持ポリシーを指定する必要があります。そうしない場合、Elasticsearch インデックスはそのソースに対して作成されません。

      5

      Elasticsearch ノードの数を指定します。この一覧に続く注記を確認してください。

      6

      Elasticsearch ストレージの既存のストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。ストレージクラスを指定しない場合、OpenShift Container Platform は一時ストレージのみのクラスターロギングをデプロイします。

      7

      Elasticsearch ストレージの既存のストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。ストレージクラスを指定しない場合、OpenShift Container Platform は一時ストレージのみのクラスターロギングをデプロイします。

      8

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

      9

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

      10

      Kibana の設定に必要な設定。CR を使用して、冗長性を確保するために Kibana をスケーリングし、Kibana ノードの CPU およびメモリーを設定できます。詳細は、ログビジュアライザーの設定 について参照してください。

      11

      Curator スケジュールの設定Curator は、OpenShift Container Platform 4.5 より前には Elasticsearch インデックス形式にあるデータを削除するために使用されましたが、今後のリリースでは削除されます。

      Fluentd の設定に必要な設定。CR を使用して Fluentd の CPU およびメモリー制限を設定できます。詳細はFluentd の設定を参照してください。

      注記

      Elasticsearch マスターノードの最大数は 3 です。3 を超える nodeCount を指定する場合、OpenShift Container Platform は、マスター、クライアントおよびデータロールを使用して、3 つのマスターとしての適格性のあるノードである Elasticsearch ノードを作成します。追加の Elasticsearch ノードは、クライアントおよびデータロールを使用してデータのみのノードとして作成されます。マスターノードは、インデックスの作成および削除、シャードの割り当て、およびノードの追跡などのクラスター全体でのアクションを実行します。データノードはシャードを保持し、CRUD、検索、および集計などのデータ関連の操作を実行します。データ関連の操作は、I/O、メモリーおよび CPU 集約型の操作です。これらのリソースを監視し、現行ノードがオーバーロードする場合にデータノード追加することが重要です。

      たとえば、nodeCount=4 の場合に、以下のノードが作成されます。

      $ oc get deployment

      出力例

      cluster-logging-operator       1/1     1            1           18h
      elasticsearch-cd-x6kdekli-1    0/1     1            0           6m54s
      elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
      elasticsearch-cdm-x6kdekli-2   0/1     1            0           6m49s
      elasticsearch-cdm-x6kdekli-3   0/1     1            0           6m44s

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

   6. Create をクリックします。これにより、クラスターロギングコンポーネント、Elasticsearch カスタムリソースおよびコンポーネント、および Kibana インターフェイスが作成されます。

4. インストールを確認します。

   1. Workloads → Pods ページに切り替えます。

   2. openshift-logging プロジェクトを選択します。

      以下の一覧のようなクラスターロギング、Elasticsearch、Fluentd、および Kibana のいくつかの Pod が表示されるはずです。

      • cluster-logging-operator-cb795f8dc-xkckc
      • elasticsearch-cdm-b3nqzchd-1-5c6797-67kfz
      • elasticsearch-cdm-b3nqzchd-2-6657f4-wtprv
      • elasticsearch-cdm-b3nqzchd-3-588c65-clg7g
      • fluentd-2c7dg
      • fluentd-9z7kk
      • fluentd-br7r2
      • fluentd-fn2sb
      • fluentd-pb2f8
      • fluentd-zqgqx
      • kibana-7fb4fd4cc9-bvt4p

1. Elasticsearch Operator の namespace を作成します。

   1. Elasticsearch Operator の namespace オブジェクト YAML ファイル (eo-namespace.yaml など) を作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-operators-redhat 1
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-monitoring: "true" 2

      1

      openshift-operators-redhat namespace を指定する必要があります。メトリクスとの競合が発生する可能性を防ぐには、Prometheus のクラスターモニターリングスタックを、openshift-operators namespace からではなく、openshift-operators-redhat namespace からメトリクスを収集するように設定する必要があります。openshift-operators namespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。

      2

      クラスターモニターリングが openshift-operators-redhat namespace を収集できるように、このラベルを上記のように指定する必要があります。

   2. namespace を作成します。

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

      以下は例になります。

      $ oc create -f eo-namespace.yaml

2. Cluster Logging Operator の namespace を作成します。

   1. Cluster Logging Operator の namespace オブジェクト YAML ファイル (clo-namespace.yaml など) を作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-logging
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-monitoring: "true"

   2. namespace を作成します。

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

      以下は例になります。

      $ oc create -f clo-namespace.yaml

3. 以下のオブジェクトを作成して Elasticsearch Operator をインストールします。

   1. Elasticsearch Operator の Operator グループオブジェクトの YAML ファイル (eo-og.yaml など) を作成します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: openshift-operators-redhat
        namespace: openshift-operators-redhat 1
      spec: {}

      1

      openshift-operators-redhat namespace を指定する必要があります。

   2. Operator グループオブジェクトを作成します。

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

      以下は例になります。

      $ oc create -f eo-og.yaml

   3. Subscription オブジェクト YAML ファイル (eo-sub.yaml など) を作成し、namespace を Elasticsearch Operator にサブスクライブします。

      Subscription の例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: "elasticsearch-operator"
        namespace: "openshift-operators-redhat" 1
      spec:
        channel: "4.5" 2
        installPlanApproval: "Automatic"
        source: "redhat-operators" 3
        sourceNamespace: "openshift-marketplace"
        name: "elasticsearch-operator"

      1

      openshift-operators-redhat namespace を指定する必要があります。

      2

      4.5 をチャネルとして指定します。

      3

      redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれるネットワークが制限された環境でインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成される CatalogSource オブジェクトの名前を指定します。

   4. Subscription オブジェクトを作成します。

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

      以下は例になります。

      $ oc create -f eo-sub.yaml

      Elasticsearch Operator は openshift-operators-redhat namespace にインストールされ、クラスター内の各プロジェクトにコピーされます。

   5. Operator のインストールを確認します。

      $ oc get csv --all-namespaces

      出力例

      NAMESPACE                                               NAME                                            DISPLAY                  VERSION               REPLACES   PHASE
      default                                                 elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      kube-node-lease                                         elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      kube-public                                             elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      kube-system                                             elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      openshift-apiserver-operator                            elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      openshift-apiserver                                     elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      openshift-authentication-operator                       elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      openshift-authentication                                elasticsearch-operator.4.5.0-202007012112.p0    Elasticsearch Operator   4.5.0-202007012112.p0               Succeeded
      ...

      それぞれの namespace には Elasticsearch Operator がなければなりません。バージョン番号が表示されるものと異なる場合があります。

4. 以下のオブジェクトを作成して Cluster Logging Operator をインストールします。

   1. Cluster Logging Operator の OperatorGroup オブジェクトの YAML ファイル (eo-og.yaml など) を作成します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: cluster-logging
        namespace: openshift-logging 1
      spec:
        targetNamespaces:
        - openshift-logging 2

      1 2

      openshift-logging namespace を指定する必要があります。

   2. OperatorGroup オブジェクトを作成します。

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

      以下は例になります。

      $ oc create -f clo-og.yaml

   3. Subscription オブジェクト YAML ファイル (clo-sub.yaml など) を作成し、namespace を Cluster Logging Operator にサブスクライブします。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: cluster-logging
        namespace: openshift-logging 1
      spec:
        channel: "4.5" 2
        name: cluster-logging
        source: redhat-operators 3
        sourceNamespace: openshift-marketplace

      1

      openshift-logging namespace を指定する必要があります。

      2

      4.5 をチャネルとして指定します。

      3

      redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれる制限されたネットワークにインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成した CatalogSource オブジェクトの名前を指定します。

   4. Subscription オブジェクトを作成します。

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

      以下は例になります。

      $ oc create -f clo-sub.yaml

      Cluster Logging Operator は openshift-logging namespace にインストールされます。

   5. Operator のインストールを確認します。

      openshift-logging namespace には Cluster Logging Operator がなければなりません。バージョン番号が表示されるものと異なる場合があります。

      $ oc get csv -n openshift-logging

      出力例

      NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
      ...
      openshift-logging                                       clusterlogging.4.5.0-202007012112.p0         Cluster Logging          4.5.0-202007012112.p0              Succeeded
      ...

5. クラスターロギングのインスタンスを作成します。

   1. Cluster Logging Operator のインスタンスオブジェクト YAML ファイル (clo-instance.yaml など) を作成します。

      注記

      このデフォルトのクラスターロギング設定は各種の環境をサポートすることが予想されます。クラスターロギングのクラスターに加えることのできる変更についての詳細は、クラスターロギングコンポーネントのチューニングおよび設定についてのトピックを確認してください。

      apiVersion: "logging.openshift.io/v1"
      kind: "ClusterLogging"
      metadata:
        name: "instance" 1
        namespace: "openshift-logging"
      spec:
        managementState: "Managed"  2
        logStore:
          type: "elasticsearch"  3
          retentionPolicy: 4
            application:
              maxAge: 1d
            infra:
              maxAge: 7d
            audit:
              maxAge: 7d
          elasticsearch:
            nodeCount: 3 5
            storage:
              storageClassName: "<storage-class-name>" 6
              size: 200G
            resources: 7
              requests:
                memory: "8Gi"
            proxy: 8
              resources:
                limits:
                  memory: 256Mi
                requests:
                   memory: 256Mi
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  9
          kibana:
            replicas: 1
        curation:
          type: "curator"
          curator:
            schedule: "30 3 * * *" 10
        collection:
          logs:
            type: "fluentd"  11
            fluentd: {}

      1

      名前は instance である必要があります。

      2

      クラスターロギングの管理状態。クラスターロギングのデフォルト値を変更する場合は、これを Unmanaged (管理外) に設定する必要がある場合があります。ただし、管理外のデプロイメントはクラスターロギングが管理対象の状態に戻されるまで更新を受信しません。デプロイメントを管理対象の状態に戻すと、加えた変更が元に戻される可能性があります。

      3

      Elasticsearch の設定に必要な設定。カスタムリソース (CR) を使用してシャードのレプリケーションポリシーおよび永続ストレージを設定できます。

      4

      Elasticsearch が各ログソースを保持する期間を指定します。整数および時間の指定 (weeks(w)、hour(h/H)、minutes(m)、および seconds(s)) を入力します。たとえば、7 日の場合は 7d となります。maxAge よりも古いログは削除されます。各ログソースの保持ポリシーを指定する必要があります。そうしない場合、Elasticsearch インデックスはそのソースに対して作成されません。

      5

      Elasticsearch ノードの数を指定します。この一覧に続く注記を確認してください。

      6

      Elasticsearch ストレージの既存のストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。ストレージクラスを指定しない場合、OpenShift Container Platform は一時ストレージのみのクラスターロギングをデプロイします。

      7

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

      8

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

      9

      Kibana の設定に必要な設定。CR を使用して、冗長性を確保するために Kibana をスケーリングし、Kibana Pod の CPU およびメモリーを設定できます。詳細は、ログビジュアライザーの設定 について参照してください。

      10

      Curator スケジュールの設定Curator は、OpenShift Container Platform 4.5 より前には Elasticsearch インデックス形式にあるデータを削除するために使用されましたが、今後のリリースでは削除されます。

      11

      Fluentd の設定に必要な設定。CR を使用して Fluentd の CPU およびメモリー制限を設定できます。詳細はFluentd の設定を参照してください。

      注記

      Elasticsearch マスターノードの最大数は 3 です。3 を超える nodeCount を指定する場合、OpenShift Container Platform は、マスター、クライアントおよびデータロールを使用して、3 つのマスターとしての適格性のあるノードである Elasticsearch ノードを作成します。追加の Elasticsearch ノードは、クライアントおよびデータロールを使用してデータのみのノードとして作成されます。マスターノードは、インデックスの作成および削除、シャードの割り当て、およびノードの追跡などのクラスター全体でのアクションを実行します。データノードはシャードを保持し、CRUD、検索、および集計などのデータ関連の操作を実行します。データ関連の操作は、I/O、メモリーおよび CPU 集約型の操作です。これらのリソースを監視し、現行ノードがオーバーロードする場合にデータノード追加することが重要です。

      たとえば、nodeCount=4 の場合に、以下のノードが作成されます。

      $ oc get deployment

      出力例

      cluster-logging-operator       1/1     1            1           18h
      elasticsearch-cd-x6kdekli-1    1/1     1            0           6m54s
      elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
      elasticsearch-cdm-x6kdekli-2   1/1     1            0           6m49s
      elasticsearch-cdm-x6kdekli-3   1/1     1            0           6m44s

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

   2. インスタンスを作成します。

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

      以下は例になります。

      $ oc create -f clo-instance.yaml

      これにより、クラスターロギングコンポーネント、Elasticsearch カスタムリソースおよびコンポーネント、および Kibana インターフェイスが作成されます。

6. openshift-logging プロジェクトに Pod を一覧表示して、インストールを検証します。

   以下の一覧のようなクラスターロギング、Elasticsearch、Fluentd、および Kibana のいくつかの Pod が表示されるはずです。

   $ oc get pods -n openshift-logging

   出力例

   NAME                                            READY   STATUS    RESTARTS   AGE
   cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
   elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
   elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
   elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
   fluentd-587vb                                   1/1     Running   0          2m26s
   fluentd-7mpb9                                   1/1     Running   0          2m30s
   fluentd-flm6j                                   1/1     Running   0          2m33s
   fluentd-gn4rn                                   1/1     Running   0          2m26s
   fluentd-nlgb6                                   1/1     Running   0          2m30s
   fluentd-snpkt                                   1/1     Running   0          2m28s
   kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s

手順 (UI)

1. OpenShift Container Platform コンソールで Workloads → Pods に移動するか、または調査するリソースから Pod に移動します。

   注記

   ビルドなどの一部のリソースには、直接クエリーする Pod がありません。このような場合には、リソースについて Details ページで Logs リンクを特定できます。

2. ドロップダウンメニューからプロジェクトを選択します。
3. 調査する Pod の名前をクリックします。
4. Logs をクリックします。

1. OpenShift Container Platform コンソールで、Application Launcher をクリックし、Logging を選択します。

2. Management → Index Patterns → Create index pattern をクリックして Kibana インデックスパターンを作成します。

   • 各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは app という名前のインデックスパターンを作成し、@timestamp 時間フィールドを使用してコンテナーログを表示する必要があります。
   • 管理ユーザーはそれぞれ、最初に Kibana にログインする際に、@timestamp 時間フィールドを使用して app、 infra および audit インデックスについてインデックスパターンを作成する必要があります。
3. 新規インデックスパターンから Kibana のビジュアライゼーション (Visualization) を作成します。

1. OpenShift Container Platform コンソールで、Application Launcher をクリックし、Logging を選択します。

2. OpenShift Container Platform コンソールにログインするために使用するものと同じ認証情報を使用してログインします。

   Kibana インターフェイスが起動します。

3. Kibana で Discover をクリックします。

4. 左上隅のドロップダウンメニューから作成したインデックスパターン (app、audit、または infra) を選択します。

   ログデータは、タイムスタンプ付きのドキュメントとして表示されます。

5. タイムスタンプ付きのドキュメントの 1 つを展開します。

6. JSON タブをクリックし、ドキュメントのログエントリーを表示します。

   例5.1 Kibana のインフラストラクチャーログエントリーのサンプル

   {
     "_index": "infra-000001",
     "_type": "_doc",
     "_id": "YmJmYTBlNDkZTRmLTliMGQtMjE3NmFiOGUyOWM3",
     "_version": 1,
     "_score": null,
     "_source": {
       "docker": {
         "container_id": "f85fa55bbef7bb783f041066be1e7c267a6b88c4603dfce213e32c1"
       },
       "kubernetes": {
         "container_name": "registry-server",
         "namespace_name": "openshift-marketplace",
         "pod_name": "redhat-marketplace-n64gc",
         "container_image": "registry.redhat.io/redhat/redhat-marketplace-index:v4.6",
         "container_image_id": "registry.redhat.io/redhat/redhat-marketplace-index@sha256:65fc0c45aabb95809e376feb065771ecda9e5e59cc8b3024c4545c168f",
         "pod_id": "8f594ea2-c866-4b5c-a1c8-a50756704b2a",
         "host": "ip-10-0-182-28.us-east-2.compute.internal",
         "master_url": "https://kubernetes.default.svc",
         "namespace_id": "3abab127-7669-4eb3-b9ef-44c04ad68d38",
         "namespace_labels": {
           "openshift_io/cluster-monitoring": "true"
         },
         "flat_labels": [
           "catalogsource_operators_coreos_com/update=redhat-marketplace"
         ]
       },
       "message": "time=\"2020-09-23T20:47:03Z\" level=info msg=\"serving registry\" database=/database/index.db port=50051",
       "level": "unknown",
       "hostname": "ip-10-0-182-28.internal",
       "pipeline_metadata": {
         "collector": {
           "ipaddr4": "10.0.182.28",
           "inputname": "fluent-plugin-systemd",
           "name": "fluentd",
           "received_at": "2020-09-23T20:47:15.007583+00:00",
           "version": "1.7.4 1.6.0"
         }
       },
       "@timestamp": "2020-09-23T20:47:03.422465+00:00",
       "viaq_msg_id": "YmJmYTBlNDktMDMGQtMjE3NmFiOGUyOWM3",
       "openshift": {
         "labels": {
           "logging": "infra"
         }
       }
     },
     "fields": {
       "@timestamp": [
         "2020-09-23T20:47:03.422Z"
       ],
       "pipeline_metadata.collector.received_at": [
         "2020-09-23T20:47:15.007Z"
       ]
     },
     "sort": [
       1600894023422
     ]
   }

1. 転送 パラメーターについて secure-forward.conf という名前の設定ファイルを作成します。

   1. シークレットおよび TLS 情報を設定します。

       <store>
        @type forward
      
        self_hostname ${hostname} 1
        shared_key <SECRET_STRING> 2
      
        transport tls 3
      
        tls_verify_hostname true 4
        tls_cert_path <path_to_file> 5

      1

      自動生成される証明書の共通名 (CN) のデフォルト値を指定します。

      2

      ノード間で共有キーを入力します。

      3

      tls を指定して TLS 検証を有効にします。

      4

      サーバー証明書のホスト名を確認するには true に設定します。サーバー証明書のホスト名を無視するには、false に設定します。

      5

      プライベート CA 証明書ファイルへのパスを /etc/ocp-forward/ca_cert.pem として指定します。

      mTLS を使用するには、クライアント証明書およびキーパラメーターなどの設定に関する情報として Fluentd のドキュメント を参照してください。

   2. 外部 Fluentd サーバーの名前、ホスト、およびポートを設定します。

        <server>
          name 1
          host 2
          hostlabel 3
          port 4
        </server>
        <server> 5
          name
          host
        </server>

      1

      オプションで、このサーバーの名前を入力します。

      2

      サーバーのホスト名または IP を指定します。

      3

      サーバーのホストラベルを指定します。

      4

      サーバーのポートを指定します。

      5

      オプションで、サーバーを追加します。2 つ以上のサーバーを指定する場合、forward はこれらのサーバーノードをラウンドロビン順で使用します。

      以下は例になります。

        <server>
          name externalserver1
          host 192.168.1.1
          hostlabel externalserver1.example.com
          port 24224
        </server>
        <server>
          name externalserver2
          host externalserver2.example.com
          port 24224
        </server>
        </store>

2. 設定ファイルから openshift-logging namespace に secure-forward という名前の ConfigMap を作成します。

   $ oc create configmap secure-forward --from-file=secure-forward.conf -n openshift-logging

3. オプション: レシーバーに必要なシークレットをインポートします。

   $ oc create secret generic secure-forward --from-file=<arbitrary-name-of-key1>=cert_file_from_fluentd_receiver --from-literal=shared_key=value_from_fluentd_receiver

   以下は例になります。

   $ oc create secret generic secure-forward --from-file=ca-bundle.crt=ca-for-fluentd-receiver/ca.crt --from-literal=shared_key=fluentd-receiver

4. fluentd Pod を更新し、secure-forward シークレットおよび secure-forward ConfigMap を適用します。

   $ oc delete pod --selector logging-infra=fluentd

5. 外部ログアグリゲーターを OpenShift Container Platform からメッセージを安全に受信できるように設定します。

1. <store> スタンザ内に以下のパラメーターが含まれる syslog.conf という名前の設定ファイルを作成します。

   1. syslog プロトコルタイプを指定します。

      @type syslog_buffered 1

      1

      使用するプロトコル (syslog または syslog_buffered のいずれか) を指定します。

   2. 外部 syslog サーバーの名前、ホスト、およびポートを設定します。

      remote_syslog <remote> 1
      port <number> 2
      hostname <name> 3

      1

      syslog サーバーの FQDN または IP アドレスを指定します。

      2

      syslog サーバーのポートを指定します。

      3

      この syslog サーバーの名前を指定します。

      以下は例になります。

      出力例

      remote_syslog syslogserver.openshift-logging.svc.cluster.local
      port 514
      hostname fluentd-server

   3. 必要に応じて他の syslog 変数を設定します。

      remove_tag_prefix 1
      tag_key <key> 2
      facility <value>  3
      severity <value>  4
      use_record <value> 5
      payload_key message 6

      1

      このパラメーターを追加して、tag フィールドを syslog 接頭辞から削除します。

      2

      syslog キーを設定するためのフィールドを指定します。

      3

      syslog ログファシリティーまたはソースを指定します。値については、RTF 3164 を参照してください。

      4

      syslog ログの重大度を指定します。値については、RTF 3164 リンクを参照してください。

      5

      true を指定して、レコードの重大度およびファシリティーを使用します (ある場合)。true の場合、container_name、namespace_name、および pod_name は、出力の内容に組み込まれます。

      6

      syslog メッセージのペイロードを設定するためにキーを指定します。デフォルトは message に設定されます。

      出力例

      facility local0
      severity info

      設定ファイルは以下のように表示されます。

      <store>
      @type syslog_buffered
      remote_syslog syslogserver.openshift-logging.svc.cluster.local
      port 514
      hostname ${hostname}
      tag_key ident,systemd.u.SYSLOG_IDENTIFIER
      facility local0
      severity info
      use_record false
      </store>

2. 設定ファイルから openshift-logging namespace に syslog という名前の ConfigMap を作成します。

   $ oc create configmap syslog --from-file=syslog.conf -n openshift-logging

   Cluster Logging Operator は Fluentd Pod を再デプロイします。Pod が再デプロイされない場合、強制的に再デプロイするために Fluentd Pod を削除できます。

   $ oc delete pod --selector logging-infra=fluentd

手順

1. イベントルーターのテンプレートを作成します。

   kind: Template
   apiVersion: v1
   metadata:
     name: eventrouter-template
     annotations:
       description: "A pod forwarding kubernetes events to cluster logging stack."
       tags: "events,EFK,logging,cluster-logging"
   objects:
     - kind: ServiceAccount 1
       apiVersion: v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
     - kind: ClusterRole 2
       apiVersion: v1
       metadata:
         name: event-reader
       rules:
       - apiGroups: [""]
         resources: ["events"]
         verbs: ["get", "watch", "list"]
     - kind: ClusterRoleBinding  3
       apiVersion: v1
       metadata:
         name: event-reader-binding
       subjects:
       - kind: ServiceAccount
         name: eventrouter
         namespace: ${NAMESPACE}
       roleRef:
         kind: ClusterRole
         name: event-reader
     - kind: ConfigMap 4
       apiVersion: v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
       data:
         config.json: |-
           {
             "sink": "stdout"
           }
     - kind: Deployment 5
       apiVersion: apps/v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
         labels:
           component: eventrouter
           logging-infra: eventrouter
           provider: openshift
       spec:
         selector:
           matchLabels:
             component: eventrouter
             logging-infra: eventrouter
             provider: openshift
         replicas: 1
         template:
           metadata:
             labels:
               component: eventrouter
               logging-infra: eventrouter
               provider: openshift
             name: eventrouter
           spec:
             serviceAccount: eventrouter
             containers:
               - name: kube-eventrouter
                 image: ${IMAGE}
                 imagePullPolicy: IfNotPresent
                 resources:
                   requests:
                     cpu: ${CPU}
                     memory: ${MEMORY}
                 volumeMounts:
                 - name: config-volume
                   mountPath: /etc/eventrouter
             volumes:
               - name: config-volume
                 configMap:
                   name: eventrouter
   parameters:
     - name: IMAGE
       displayName: Image
       value: "registry.redhat.io/openshift4/ose-logging-eventrouter:latest"
     - name: CPU  6
       displayName: CPU
       value: "100m"
     - name: MEMORY 7
       displayName: Memory
       value: "128Mi"
     - name: NAMESPACE
       displayName: Namespace
       value: "openshift-logging" 8

   1

   イベントルーターの openshift-logging プロジェクトでサービスアカウントを作成します。

   2

   ClusterRole を作成し、クラスター内のイベントを監視します。

   3

   ClusterRoleBinding を作成し、ClusterRole をサービスアカウントにバインドします。

   4

   openshift-logging プロジェクトで設定マップを作成し、必要な config.json ファイルを生成します。

   5

   openshift-logging プロジェクトでデプロイメントを作成し、イベントルーター Pod を生成し、設定します。

   6

   イベントルーター Pod に割り当てるメモリーの最小量を指定します。デフォルトは 128Mi に設定されます。

   7

   イベントルーター Pod に割り当てる CPU の最小量を指定します。デフォルトは 100m に設定されます。

   8

   オブジェクトをインストールする openshift-logging プロジェクトを指定します。

2. 以下のコマンドを使用してテンプレートを処理し、これを適用します。

   $ oc process -f <templatefile> | oc apply -n openshift-logging -f -

   以下に例を示します。

   $ oc process -f eventrouter.yaml | oc apply -n openshift-logging -f -

   出力例

   serviceaccount/logging-eventrouter created
   clusterrole.authorization.openshift.io/event-reader created
   clusterrolebinding.authorization.openshift.io/event-reader-binding created
   configmap/logging-eventrouter created
   deployment.apps/logging-eventrouter created

3. イベントルーターが openshift-logging プロジェクトにインストールされていることを確認します。

   1. 新規イベントルーター Pod を表示します。

      $ oc get pods --selector  component=eventrouter -o name -n openshift-logging

      出力例

      pod/cluster-logging-eventrouter-d649f97c8-qvv8r

   2. イベントルーターによって収集されるイベントを表示します。

      $ oc logs <cluster_logging_eventrouter_pod> -n openshift-logging

      以下に例を示します。

      $ oc logs cluster-logging-eventrouter-d649f97c8-qvv8r -n openshift-logging

      出力例

      {"verb":"ADDED","event":{"metadata":{"name":"openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","namespace":"openshift-service-catalog-removed","selfLink":"/api/v1/namespaces/openshift-service-catalog-removed/events/openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","uid":"787d7b26-3d2f-4017-b0b0-420db4ae62c0","resourceVersion":"21399","creationTimestamp":"2020-09-08T15:40:26Z"},"involvedObject":{"kind":"Job","namespace":"openshift-service-catalog-removed","name":"openshift-service-catalog-controller-manager-remover","uid":"fac9f479-4ad5-4a57-8adc-cb25d3d9cf8f","apiVersion":"batch/v1","resourceVersion":"21280"},"reason":"Completed","message":"Job completed","source":{"component":"job-controller"},"firstTimestamp":"2020-09-08T15:40:26Z","lastTimestamp":"2020-09-08T15:40:26Z","count":1,"type":"Normal"}}

      また、Elasticsearch infra インデックスを使用してインデックスパターンを作成し、Kibana を使用してイベントを表示することもできます。

手順

1. Elasticsearch Operator を更新します。

   1. Web コンソールで Operators → Installed Operators をクリックします。
   2. openshift-operators-redhat プロジェクトを選択します。
   3. Elasticsearch Operatorをクリックします。
   4. Subscription → Channel をクリックします。
   5. Change Subscription Update Channel ウィンドウで 4.5 を選択し、Save をクリックします。

   6. 数秒待ってから Operators → Installed Operators をクリックします。

      Elasticsearch Operator が 4.5 と表示されます。以下は例になります。

      Elasticsearch Operator
      4.5.0-202007012112.p0 provided
      by Red Hat, Inc

      Status フィールドで Succeeded を報告するのを待機します。

2. Cluster Logging Operator を更新します。

   1. Web コンソールで Operators → Installed Operators をクリックします。
   2. openshift-logging プロジェクトを選択します。
   3. Cluster Logging Operatorをクリックします。
   4. Subscription → Channel をクリックします。
   5. Change Subscription Update Channel ウィンドウで 4.5 を選択し、Save をクリックします。

   6. 数秒待ってから Operators → Installed Operators をクリックします。

      Cluster Logging Operator は 4.5 として表示されます。以下は例になります。

      Cluster Logging
      4.5.0-202007012112.p0 provided
      by Red Hat, Inc

      Status フィールドで Succeeded を報告するのを待機します。

3. ロギングコンポーネントを確認します。

   1. すべての Elasticsearch Pod が Ready ステータスであることを確認します。

      $ oc get pod -n openshift-logging --selector component=elasticsearch

      出力例

      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk   2/2     Running   0          31m
      elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk   2/2     Running   0          30m
      elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc     2/2     Running   0          29m

   2. Elasticsearch クラスターが正常であることを確認します。

      $ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- es_cluster_health

      {
        "cluster_name" : "elasticsearch",
        "status" : "green",
      }
      ...

   3. Elasticsearch cron ジョブが作成されていることを確認します。

      $ oc project openshift-logging

      $ oc get cronjob

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

   4. ログストアが 4.5 に更新され、インデックスが green であることを確認します。

      $ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices

      出力に app-00000x、 infra-00000x、audit-00000x、.security インデックス が含まれることを確認します。

      例8.1 緑色のステータスのインデックスを含む出力例

      Tue Jun 30 14:30:54 UTC 2020
      health status index                                                                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
      green  open   infra-000008                                                          bnBvUFEXTWi92z3zWAzieQ   3 1       222195            0        289            144
      green  open   infra-000004                                                          rtDSzoqsSl6saisSK7Au1Q   3 1       226717            0        297            148
      green  open   infra-000012                                                          RSf_kUwDSR2xEuKRZMPqZQ   3 1       227623            0        295            147
      green  open   .kibana_7                                                             1SJdCqlZTPWlIAaOUd78yg   1 1            4            0          0              0
      green  open   infra-000010                                                          iXwL3bnqTuGEABbUDa6OVw   3 1       248368            0        317            158
      green  open   infra-000009                                                          YN9EsULWSNaxWeeNvOs0RA   3 1       258799            0        337            168
      green  open   infra-000014                                                          YP0U6R7FQ_GVQVQZ6Yh9Ig   3 1       223788            0        292            146
      green  open   infra-000015                                                          JRBbAbEmSMqK5X40df9HbQ   3 1       224371            0        291            145
      green  open   .orphaned.2020.06.30                                                  n_xQC2dWQzConkvQqei3YA   3 1            9            0          0              0
      green  open   infra-000007                                                          llkkAVSzSOmosWTSAJM_hg   3 1       228584            0        296            148
      green  open   infra-000005                                                          d9BoGQdiQASsS3BBFm2iRA   3 1       227987            0        297            148
      green  open   infra-000003                                                          1-goREK1QUKlQPAIVkWVaQ   3 1       226719            0        295            147
      green  open   .security                                                             zeT65uOuRTKZMjg_bbUc1g   1 1            5            0          0              0
      green  open   .kibana-377444158_kubeadmin                                           wvMhDwJkR-mRZQO84K0gUQ   3 1            1            0          0              0
      green  open   infra-000006                                                          5H-KBSXGQKiO7hdapDE23g   3 1       226676            0        295            147
      green  open   infra-000001                                                          eH53BQ-bSxSWR5xYZB6lVg   3 1       341800            0        443            220
      green  open   .kibana-6                                                             RVp7TemSSemGJcsSUmuf3A   1 1            4            0          0              0
      green  open   infra-000011                                                          J7XWBauWSTe0jnzX02fU6A   3 1       226100            0        293            146
      green  open   app-000001                                                            axSAFfONQDmKwatkjPXdtw   3 1       103186            0        126             57
      green  open   infra-000016                                                          m9c1iRLtStWSF1GopaRyCg   3 1        13685            0         19              9
      green  open   infra-000002                                                          Hz6WvINtTvKcQzw-ewmbYg   3 1       228994            0        296            148
      green  open   infra-000013                                                          KR9mMFUpQl-jraYtanyIGw   3 1       228166            0        298            148
      green  open   audit-000001                                                          eERqLdLmQOiQDFES1LBATQ   3 1            0            0          0              0

   5. ログコレクターが 4.5 に更新されていることを確認します。

      $ oc get ds fluentd -o json | grep fluentd-init

      出力に fluentd-init コンテナーが含まれていることを確認します。

      "containerName": "fluentd-init"

   6. Kibana CRD を使用してログビジュアライザーが 4.5 に更新されていることを確認します。

      $ oc get kibana kibana -o json

      出力に ready ステータスの Kibana Pod が含まれることを確認します。

      例8.2 準備状態にある Kibana Pod の出力例

      [
      {
      "clusterCondition": {
      "kibana-5fdd766ffd-nb2jj": [
      {
      "lastTransitionTime": "2020-06-30T14:11:07Z",
      "reason": "ContainerCreating",
      "status": "True",
      "type": ""
      },
      {
      "lastTransitionTime": "2020-06-30T14:11:07Z",
      "reason": "ContainerCreating",
      "status": "True",
      "type": ""
      }
      ]
      },
      "deployment": "kibana",
      "pods": {
      "failed": [],
      "notReady": []
      "ready": []
      },
      "replicaSets": [
      "kibana-5fdd766ffd"
      ],
      "replicas": 1
      }
      ]

   7. Curator が 4.5 に更新されていることを確認します。

      $ oc get cronjob -o name

      cronjob.batch/curator
      cronjob.batch/elasticsearch-delete-app
      cronjob.batch/elasticsearch-delete-audit
      cronjob.batch/elasticsearch-delete-infra
      cronjob.batch/elasticsearch-rollover-app
      cronjob.batch/elasticsearch-rollover-audit
      cronjob.batch/elasticsearch-rollover-infra

      出力に elasticsearch-delete-* および elasticsearch-rollover-* インデックスが含まれることを確認します。

1. OpenShift Container Platform コンソールで、Application Launcher をクリックし、Logging を選択します。

2. Management → Index Patterns → Create index pattern をクリックして Kibana インデックスパターンを作成します。

   • 各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは app という名前のインデックスパターンを作成し、@timestamp 時間フィールドを使用してコンテナーログを表示する必要があります。
   • 管理ユーザーはそれぞれ、最初に Kibana にログインする際に、@timestamp 時間フィールドを使用して app、 infra および audit インデックスについてインデックスパターンを作成する必要があります。
3. 新規インデックスパターンから Kibana のビジュアライゼーション (Visualization) を作成します。

1. OpenShift Container Platform Web コンソールを使って ClusterLogging CR を削除できます。

   1. Administration → Custom Resource Definitions ページに切り替えます。
   2. Custom Resource Definitions ページで、ClusterLogging をクリックします。
   3. Custom Resource Definition Details ページで、 Instances をクリックします。
   4. インスタンスの横にある Options メニュー をクリックし、 Delete ClusterLogging を選択します。

2. オプション: カスタムリソース定義 (CRD) を削除します。

   1. Administration → Custom Resource Definitions ページに切り替えます。
   2. ClusterLogging の横にある Options メニュー をクリックし、 Delete Custom Resource Definition を選択します。
   3. Elasticsearch の横にある Options メニュー をクリックし、Delete Custom Resource Definition を選択します。
   4. LogForwarding の横にある Options メニュー をクリックし、 Delete Custom Resource Definition を選択します。

3. オプション: Cluster Logging Operator および Elasticsearch Operator を削除します。

   1. Operators → Installed Operators ページに切り替えます。
   2. openshift-logging プロジェクトを選択します。
   3. Cluster Logging Operator の横にある Options メニュー をクリックし、Uninstall Operator を選択します。
   4. openshift-operators-redhat プロジェクトを選択します。
   5. Elasticsearch Operator の横にある Options メニュー をクリックし、Uninstall Operator を選択します。

4. オプション: Cluster Logging および Elasticsearch プロジェクト。

   1. Home → Projects ページに切り替えます。
   2. openshift-logging プロジェクトの横にある Options メニュー をクリックし、Delete Project を選択します。
   3. ダイアログボックスで openshift-logging を入力して、Delete をクリックし、削除を確認します。

   4. openshift-operators-redhat プロジェクトの横にある Options メニュー をクリックし、Delete Project を選択します。

      重要

      他のグローバル Operator がこの namespace にインストールされている場合、openshift-operators-redhat プロジェクトを削除しないでください。

   5. ダイアログボックスで openshift-operators-redhat を入力し、Delete をクリックして削除を確認します。