ロギング

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

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から OpenShift 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 として stable-5.x を選択します。

   7. Approval Strategy を選択します。

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

2. Red Hat OpenShift Logging Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から Red Hat OpenShift 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 として stable-5.x を選択します。

   7. Approval Strategy を選択します。

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

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

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

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

3. OpenShift Logging インスタンスを作成します。

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

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

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

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

      注記

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

      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
                limits:
                  memory: "16Gi"
                requests:
                  memory: "16Gi"
            proxy: 8
              resources:
                limits:
                  memory: 256Mi
                requests:
                  memory: 256Mi
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  9
          kibana:
            replicas: 1
        collection:
          logs:
            type: "fluentd"  10
            fluentd: {}

      1

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

      2

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

      3

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

      4

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

      5

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

      6

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

      7

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

      8

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

      9

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

      10

      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 をクリックします。これにより、OpenShift Logging コンポーネント、Elasticsearch カスタムリソースおよびコンポーネント、および Kibana インターフェイスが作成されます。

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

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

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

      以下の一覧のような 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. OpenShift Elasticsearch Operator の namespace を作成します。

   1. OpenShift 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. Red Hat OpenShift Logging Operator の namespace を作成します。

   1. Red Hat OpenShift Logging Operator の namespace オブジェクト YAML ファイル (olo-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 olo-namespace.yaml

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

   1. OpenShift 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 を OpenShift Elasticsearch Operator にサブスクライブします。

      Subscription の例

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

      1

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

      2

      5.0、stable または stable-5.<x> をチャネルとして指定します。以下の注意点を参照してください。

      3

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

      注記

      stable を指定すると、最新の安定したリリースの現行バージョンがインストールされます。installPlanApproval: "Automatic" で stable 使用すると、Operatar が自動的に最新の安定したメジャーおよびマイナーリリースにアップグレードします。

      stable-5.<x> を指定すると、特定のメジャーリリースの現在のマイナーバージョンがインストールされます。installPlanApproval: "Automatic" で stable-5.<x> を使用すると、x で指定したメジャーリリース内で最新の安定マイナーリリースに Operator が自動的にアップグレードされます。

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

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

      以下に例を示します。

      $ oc create -f eo-sub.yaml

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

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

      $ oc get csv --all-namespaces

      出力例

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

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

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

   1. Red Hat OpenShift Logging Operator の Operator グループオブジェクトの YAML ファイル (olo-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 olo-og.yaml

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

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

      1

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

      2

      5.0、stable または stable-5.<x> をチャネルとして指定します。

      3

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

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

      以下に例を示します。

      $ oc create -f olo-sub.yaml

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

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

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

      $ oc get csv -n openshift-logging

      出力例

      NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
      ...
      openshift-logging                                       clusterlogging.5.1.0-202007012112.p0         OpenShift Logging          5.1.0-202007012112.p0              Succeeded
      ...

5. OpenShift Logging インスタンスを作成します。

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

      注記

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

      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
              limits:
                memory: "16Gi"
              requests:
                memory: "16Gi"
            proxy: 8
              resources:
                limits:
                  memory: 256Mi
                requests:
                   memory: 256Mi
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  9
          kibana:
            replicas: 1
        collection:
          logs:
            type: "fluentd"  10
            fluentd: {}

      1

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

      2

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

      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 は一時ストレージのみの OpenShift Logging をデプロイします。

      7

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

      8

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

      9

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

      10

      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 olo-instance.yaml

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

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

   以下の一覧のような OpenShift Logging、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 タブをクリックし、ドキュメントのログエントリーを表示します。

   例6.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.7",
         "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. 以下のように ClusterLogForwarder CR YAML ファイルを作成します。

   apiVersion: "logging.openshift.io/v1"
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: elasticsearch-insecure 3
        type: "elasticsearch" 4
        url: http://elasticsearch.insecure.com:9200 5
      - name: elasticsearch-secure
        type: "elasticsearch"
        url: https://elasticsearch.secure.com:9200
        secret:
           name: es-secret 6
     pipelines:
      - name: application-logs 7
        inputRefs: 8
        - application
        - audit
        outputRefs:
        - elasticsearch-secure 9
        - default 10
        parse: json 11
        labels:
          myLabel: "myValue" 12
      - name: infrastructure-audit-logs 13
        inputRefs:
        - infrastructure
        outputRefs:
        - elasticsearch-insecure
        labels:
          logs: "audit-infra"

   1

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

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   出力の名前を指定します。

   4

   elasticsearch タイプを指定します。

   5

   外部 Elasticsearch インスタンスの URL およびポートを有効な絶対 URL として指定します。http (セキュアでない) プロトコルまたは https (セキュアな HTTP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   6

   https 接頭辞を使用する場合、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在し、tls.crt、tls.key、および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。

   7

   オプション: パイプラインの名前を指定します。

   8

   パイプラインを使用して、転送する必要のあるログタイプを指定します (application infrastructure、または audit)。

   9

   ログを転送するためにそのパイプラインで使用する出力を指定します。

   10

   オプション: ログを内部 Elasticsearch インスタンスに送信するために default 出力を指定します。

   11

   必要に応じて、構造化された JSON ログエントリーを structured フィールドの JSON オブジェクトとして転送します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は 構造化 フィールドを削除し、代わりにログエントリーをデフォルトのインデックス app-00000x に送信します。

   12

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   13

   オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。

   • オプション。パイプラインを説明する名前。
   • inputRefs は、そのパイプラインを使用して転送するログタイプです (application、infrastructure、または audit)。
   • outputRefs は使用する出力の名前です。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

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

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

手順

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: fluentd-server-secure 3
        type: fluentdForward 4
        url: 'tls://fluentdserver.security.example.com:24224' 5
        secret: 6
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     pipelines:
      - name: forward-to-fluentd-secure 7
        inputRefs:  8
        - application
        - audit
        outputRefs:
        - fluentd-server-secure 9
        - default 10
        parse: json 11
        labels:
          clusterId: "C1234" 12
      - name: forward-to-fluentd-insecure 13
        inputRefs:
        - infrastructure
        outputRefs:
        - fluentd-server-insecure
        labels:
          clusterId: "C1234"

   1

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

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   出力の名前を指定します。

   4

   fluentdForward タイプを指定します。

   5

   外部 Fluentd インスタンスの URL およびポートを有効な絶対 URL として指定します。tcp (セキュアでない) プロトコルまたは tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   6

   tls 接頭辞を使用する場合、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在し、tls.crt、tls.key、および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。

   7

   オプション。パイプラインの名前を指定します。

   8

   パイプラインを使用して、転送する必要のあるログタイプを指定します (application infrastructure、または audit)。

   9

   ログを転送するためにそのパイプラインで使用する出力を指定します。

   10

   オプション。ログを内部 Elasticsearch インスタンスに転送するために default 出力を指定します。

   11

   必要に応じて、構造化された JSON ログエントリーを structured フィールドの JSON オブジェクトとして転送します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は 構造化 フィールドを削除し、代わりにログエントリーをデフォルトのインデックス app-00000x に送信します。

   12

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   13

   オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。

   • オプション。パイプラインを説明する名前。
   • inputRefs は、そのパイプラインを使用して転送するログタイプです (application、infrastructure、または audit)。
   • outputRefs は使用する出力の名前です。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

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

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

手順

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: rsyslog-east 3
        type: syslog 4
        syslog: 5
          facility: local0
          rfc: RFC3164
          payloadKey: message
          severity: informational
        url: 'tls://rsyslogserver.east.example.com:514' 6
        secret: 7
           name: syslog-secret
      - name: rsyslog-west
        type: syslog
        syslog:
         appName: myapp
         facility: user
         msgID: mymsg
         procID: myproc
         rfc: RFC5424
         severity: debug
        url: 'udp://rsyslogserver.west.example.com:514'
     pipelines:
      - name: syslog-east 8
        inputRefs: 9
        - audit
        - application
        outputRefs: 10
        - rsyslog-east
        - default 11
        parse: json 12
        labels:
          secure: "true" 13
          syslog: "east"
      - name: syslog-west 14
        inputRefs:
        - infrastructure
        outputRefs:
        - rsyslog-west
        - default
        labels:
          syslog: "west"

   1

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

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   出力の名前を指定します。

   4

   syslog タイプを指定します。

   5

   オプション。以下に一覧表示されている syslog パラメーターを指定します。

   6

   外部 syslog インスタンスの URL およびポートを指定します。udp (セキュアでない)、tcp (セキュアでない) プロトコル、または tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   7

   tls 接頭辞を使用する場合、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在し、tls.crt、tls.key、および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。

   8

   オプション: パイプラインの名前を指定します。

   9

   パイプラインを使用して、転送する必要のあるログタイプを指定します (application infrastructure、または audit)。

   10

   ログを転送するためにそのパイプラインで使用する出力を指定します。

   11

   オプション: ログを内部 Elasticsearch インスタンスに転送するために default 出力を指定します。

   12

   必要に応じて、構造化された JSON ログエントリーを structured フィールドの JSON オブジェクトとして転送します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は 構造化 フィールドを削除し、代わりにログエントリーをデフォルトのインデックス app-00000x に送信します。

   13

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。"true" などの引用値は、ブール値としてではなく、文字列値として認識されるようにします。

   14

   オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。

   • オプション。パイプラインを説明する名前。
   • inputRefs は、そのパイプラインを使用して転送するログタイプです (application、infrastructure、または audit)。
   • outputRefs は使用する出力の名前です。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

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

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

手順

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: app-logs 3
        type: kafka 4
        url: tls://kafka.example.devlab.com:9093/app-topic 5
        secret:
          name: kafka-secret 6
      - name: infra-logs
        type: kafka
        url: tcp://kafka.devlab2.example.com:9093/infra-topic 7
      - name: audit-logs
        type: kafka
        url: tls://kafka.qelab.example.com:9093/audit-topic
        secret:
           name: kafka-secret-qe
     pipelines:
      - name: app-topic 8
        inputRefs: 9
        - application
        outputRefs: 10
        - app-logs
        parse: json 11
        labels:
          logType: "application" 12
      - name: infra-topic 13
        inputRefs:
        - infrastructure
        outputRefs:
        - infra-logs
        labels:
          logType: "infra"
      - name: audit-topic
        inputRefs:
        - audit
        outputRefs:
        - audit-logs
        - default 14
        labels:
          logType: "audit"

   1

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

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   出力の名前を指定します。

   4

   kafka タイプを指定します。

   5

   Kafka ブローカーの URL およびポートを有効な絶対 URL として指定し、オプションで特定のトピックで指定します。tcp (セキュアでない) プロトコルまたは tls (セキュアな TCP) プロトコルを使用できます。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   6

   tls 接頭辞を使用する場合、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在し、tls.crt、tls.key、および ca-bundle.crt のキーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。

   7

   オプション: 非セキュアな出力を送信するには、URL の前に tcp の接頭辞を使用します。また、この出力の secret キーとその name を省略します。

   8

   オプション: パイプラインの名前を指定します。

   9

   パイプラインを使用して、転送する必要のあるログタイプを指定します (application infrastructure、または audit)。

   10

   ログを転送するためにそのパイプラインで使用する出力を指定します。

   11

   必要に応じて、構造化された JSON ログエントリーを structured フィールドの JSON オブジェクトとして転送します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は 構造化 フィールドを削除し、代わりにログエントリーをデフォルトのインデックス app-00000x に送信します。

   12

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   13

   オプション: サポートされるタイプの他の外部ログアグリゲーターにログを転送するように複数の出力を設定します。

   • オプション。パイプラインを説明する名前。
   • inputRefs は、そのパイプラインを使用して転送するログタイプです (application、infrastructure、または audit)。
   • outputRefs は使用する出力の名前です。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   14

   オプション: ログを内部 Elasticsearch インスタンスに転送するために default を指定します。

2. オプション: 1 つの出力を複数の kafka ブローカーに転送するには、以下の例のように kafka ブローカーの配列を指定します。

   ...
   spec:
     outputs:
     - name: app-logs
       type: kafka
       secret:
         name: kafka-secret-dev
       kafka:  1
         brokers: 2
           - tls://kafka-broker1.example.com:9093/
           - tls://kafka-broker2.example.com:9093/
         topic: app-topic 3
   ...

   1

   brokers および topic キーを持つ kafka キーを指定します。

   2

   brokers キーを指定して、1 つ以上のブローカーを指定します。

   3

   topic キーを使用して、ログを受信するターゲットトピックを指定します。

3. CR オブジェクトを作成します。

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

手順

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

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     outputs:
      - name: fluentd-server-secure 3
        type: fluentdForward 4
        url: 'tls://fluentdserver.security.example.com:24224' 5
        secret: 6
           name: fluentd-secret
      - name: fluentd-server-insecure
        type: fluentdForward
        url: 'tcp://fluentdserver.home.example.com:24224'
     inputs: 7
      - name: my-app-logs
        application:
           namespaces:
           - my-project
     pipelines:
      - name: forward-to-fluentd-insecure 8
        inputRefs: 9
        - my-app-logs
        outputRefs: 10
        - fluentd-server-insecure
        parse: json 11
        labels:
          project: "my-project" 12
      - name: forward-to-fluentd-secure 13
        inputRefs:
        - application
        - audit
        - infrastructure
        outputRefs:
        - fluentd-server-secure
        - default
        labels:
          clusterId: "C1234"

   1

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

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   出力の名前を指定します。

   4

   出力タイプ elasticsearch、fluentdForward、syslog、または kafka を指定します。

   5

   外部ログアグリゲーターの URL およびポートを有効な絶対 URL として指定します。CIDR アノテーションを使用するクラスター全体のプロキシーが有効になっている場合、出力は IP アドレスではなくサーバー名または FQDN である必要があります。

   6

   tls 接頭辞を使用する場合、TLS 通信のエンドポイントに必要なシークレットの名前を指定する必要があります。シークレットは openshift-logging プロジェクトに存在し、 tls.crt、 tls.key、 および ca-bundle.crt キーが含まれる必要があります。これらは、それぞれが表す証明書を参照します。

   7

   指定されたプロジェクトからアプリケーションログをフィルターするための入力の設定。

   8

   入力を使用してプロジェクトアプリケーションログを外部 Fluentd インスタンスに送信するためのパイプラインの設定。

   9

   my-app-logs 入力。

   10

   使用する出力の名前。

   11

   必要に応じて、構造化された JSON ログエントリーを structured フィールドの JSON オブジェクトとして転送します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は 構造化 フィールドを削除し、代わりにログエントリーをデフォルトのインデックス app-00000x に送信します。

   12

   オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

   13

   ログを他のログアグリゲーターに送信するためのパイプラインの設定。

   • オプション: パイプラインの名前を指定します。
   • パイプラインを使用して、転送する必要のあるログタイプを指定します (application infrastructure、または audit)。
   • ログを転送するためにそのパイプラインで使用する出力を指定します。
   • オプション: ログを内部 Elasticsearch インスタンスに転送するために default 出力を指定します。
   • オプション: 文字列。ログに追加する 1 つまたは複数のラベル。

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

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

手順

1. ClusterLogForwarder カスタムリソース (CR) YAML ファイルを作成します。

2. YAML ファイルで、以下の例が示すように inputs[].name.application.selector.matchLabels の下で単純な等価ベース (Equality-based) のセレクターを使用して Pod ラベルを指定します。

   ClusterLogForwarder CR YAML ファイルのサンプル

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogForwarder
   metadata:
     name: instance 1
     namespace: openshift-logging 2
   spec:
     pipelines:
       - inputRefs: [ myAppLogData ] 3
         outputRefs: [ default ] 4
         parse: json 5
     inputs: 6
       - name: myAppLogData
         application:
           selector:
             matchLabels: 7
               environment: production
               app: nginx
           namespaces: 8
           - app1
           - app2
     outputs: 9
       - default
       ...

   1

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

   2

   ClusterLogForwarder CR の namespace は openshift-logging である必要があります。

   3

   inputs[].name から 1 つ以上のコンマ区切りの値を指定します。

   4

   outputs[] から 1 つ以上のコンマ区切りの値を指定します。

   5

   必要に応じて、構造化された JSON ログエントリーを structured フィールドの JSON オブジェクトとして転送します。ログエントリーに有効な構造化された JSON が含まれる必要があります。そうでない場合は、OpenShift Logging は 構造化 フィールドを削除し、代わりにログエントリーをデフォルトのインデックス app-00000x に送信します。

   6

   Pod ラベルの一意のセットを持つ各アプリケーションの一意の inputs[].name を定義します。

   7

   収集するログデータを持つ Pod ラベルのキー/値のペアを指定します。キーだけではなく、キーと値の両方を指定する必要があります。Pod を選択するには、Pod はすべてのキーと値のペアと一致する必要があります。

   8

   オプション: namespace を 1 つ以上指定します。

   9

   ログデータを転送する 1 つ以上の出力を指定します。ここで表示されるオプションの default 出力はログデータを内部 Elasticsearch インスタンスに送信します。

3. オプション: ログデータの収集を特定の namespace に制限するには、前述の例のように inputs[].name.application.namespaces を使用します。

4. オプション: 異なる Pod ラベルを持つ追加のアプリケーションから同じパイプラインにログデータを送信できます。

   1. Pod ラベルの一意の組み合わせごとに、表示されるものと同様の追加の inputs[].name セクションを作成します。
   2. このアプリケーションの Pod ラベルに一致するように、selectors を更新します。

   3. 新規の inputs[].name 値を inputRefs に追加します。以下に例を示します。

      - inputRefs: [ myAppLogData, myOtherAppLogData ]

5. CR オブジェクトを作成します。

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

1. secure-forward という名前の設定ファイルを作成し、<store> スタンザ内に以下のようなパラメーターを指定します。

   <store>
     @type forward
     <security>
       self_hostname ${hostname}
       shared_key <key> 1
     </security>
     transport tls 2
     tls_verify_hostname <value> 3
     tls_cert_path <path_to_file> 4
     <buffer> 5
       @type file
       path '/var/lib/fluentd/secureforwardlegacy'
       queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '1024' }"
       chunk_limit_size "#{ENV['BUFFER_SIZE_LIMIT'] || '1m' }"
       flush_interval "#{ENV['FORWARD_FLUSH_INTERVAL'] || '5s'}"
       flush_at_shutdown "#{ENV['FLUSH_AT_SHUTDOWN'] || 'false'}"
       flush_thread_count "#{ENV['FLUSH_THREAD_COUNT'] || 2}"
       retry_max_interval "#{ENV['FORWARD_RETRY_WAIT'] || '300'}"
       retry_forever true
     </buffer>
     <server>
       name 6
       host 7
       hostlabel 8
       port 9
     </server>
     <server> 10
       name
       host
     </server>

   1

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

   2

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

   3

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

   4

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

   5

   必要に応じて Fluentd バッファーパラメーター を指定します。

   6

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

   7

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

   8

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

   9

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

   10

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

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

2. 設定ファイルから openshift-logging プロジェクトに secure-forward という名前の設定マップを作成します。

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

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

   <store>
   @type <type> 1
   remote_syslog <syslog-server> 2
   port 514 3
   hostname ${hostname}
   remove_tag_prefix <prefix> 4
   facility <value>
   severity <value>
   use_record <value>
   payload_key message
   rfc 3164 5
   </store>

   1

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

   2

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

   3

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

   4

   オプション: 以下のように適切な syslog パラメーターを指定します。

   • syslog 接頭辞から指定された tag フィールドを削除するためのパラメーター。
   • 指定されたフィールドを syslog キーとして設定するパラメーター。
   • syslog ログファシリティーまたはソースを指定するパラメーター。
   • syslog ログの重大度を指定するパラメーター。
   • レコードの重大度およびファシリティーを使用するためのパラメーター (ある場合)。true の場合、container_name、namespace_name、および pod_name は、出力の内容に組み込まれます。
   • syslog メッセージのペイロードを設定するためのキーの指定に使用するパラメーター。デフォルトは message に設定されます。

   5

   レガシーの syslog メソッドでは、rfc 値に 3164 を指定する必要があります。

2. 設定ファイルから openshift-logging プロジェクトに syslog という名前の設定マップを作成します。

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

手順

1. 以下のスニペットを ClusterLogForwarder CR YAML ファイルに追加します。

   outputDefaults:
   - elasticsearch:
       structuredTypeKey: <log record field>
       structuredTypeName: <name>
   pipelines:
   - inputRefs:
     - application
     outputRefs: default
     parse: json

2. オプション: 上には、Elasticsearch の JSON ログデータの設定 で説明されているように、structuredTypeKey を使用してログレコードフィールドのいずれかを指定します。それ以外の場合は、この行を削除します。

3. オプション: Elasticsearch の JSON ログデータの設定 で前述しているように structuredTypeName を使用して <name> を指定します。それ以外の場合は、この行を削除します。

   重要

   JSON ログを解析するには、structuredTypeKey または structuredTypeName か、structuredTypeKey と structuredTypeName の両方を設定する必要があります。

4. inputRefs の場合は、application、infrastructure または audit などのパイプラインを使用して、転送する必要のあるログタイプを指定します。
5. parse: json 要素をパイプラインに追加します。

6. CR オブジェクトを作成します。

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

   Red Hat OpenShift Logging Operator は Fluentd Pod を再デプロイします。ただし、再デプロイが完了しない場合は、Fluentd Pod を削除して、強制的に再デプロイされるようにします。

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

手順

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

   kind: Template
   apiVersion: template.openshift.io/v1
   metadata:
     name: eventrouter-template
     annotations:
       description: "A pod forwarding kubernetes events to OpenShift Logging stack."
       tags: "events,EFK,logging,cluster-logging"
   objects:
     - kind: ServiceAccount 1
       apiVersion: v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
     - kind: ClusterRole 2
       apiVersion: rbac.authorization.k8s.io/v1
       metadata:
         name: event-reader
       rules:
       - apiGroups: [""]
         resources: ["events"]
         verbs: ["get", "watch", "list"]
     - kind: ClusterRoleBinding  3
       apiVersion: rbac.authorization.k8s.io/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 6
       displayName: Image
       value: "registry.redhat.io/openshift-logging/eventrouter-rhel8:v0.3"
     - name: CPU  7
       displayName: CPU
       value: "100m"
     - name: MEMORY 8
       displayName: Memory
       value: "128Mi"
     - name: NAMESPACE
       displayName: Namespace
       value: "openshift-logging" 9

   1

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

   2

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

   3

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

   4

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

   5

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

   6

   v0.3 などのタグで識別されるイメージを指定します。

   7

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

   8

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

   9

   オブジェクトをインストールする 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/eventrouter created
   clusterrole.authorization.openshift.io/event-reader created
   clusterrolebinding.authorization.openshift.io/event-reader-binding created
   configmap/eventrouter created
   deployment.apps/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. OpenShift Elasticsearch Operator を更新します。

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

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

      OpenShift Elasticsearch Operator のバージョンが 5.x.x であることを確認します。

      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 ウィンドウで 5.0 または stable-5.1 を選択し、Save をクリックします。

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

      Red Hat OpenShift Logging Operator のバージョンが 5.0.x または 5.1.x であることを確認します。

      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 -- 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. ログストアが 5.0 または 5.1 に更新され、インデックスが green であることを確認します。

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

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

      例10.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. ログコレクターが 5.0 または 5.1 に更新されていることを確認します。

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

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

      "containerName": "fluentd-init"

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

      $ oc get kibana kibana -o json

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

      例10.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
      }
      ]

手順

1. OpenShift Elasticsearch Operator を更新します。

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

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

      OpenShift Elasticsearch Operator のバージョンが 5.x.x であることを確認します。

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

2. Red Hat OpenShift Logging Operator を更新します。

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

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

      Red Hat OpenShift Logging Operator のバージョンが 5.x.x であることを確認します。

      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 -- 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. ログストアが 5.x に更新され、インデックスが green であることを確認します。

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

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

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

      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. ログコレクターが 5.x に更新されていることを確認します。

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

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

      "containerName": "fluentd-init"

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

      $ oc get kibana kibana -o json

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

      例10.4 準備状態にある 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
      }
      ]

1. OpenShift Container Platform Web コンソールで、Monitoring → Dashboards をクリックします。

2. Dashboards ページで、Dashboard メニューから Logging/Elasticsearch Nodes または Openshift Logging を選択します。

   Logging/Elasticsearch Nodes ダッシュボードの場合、表示する必要のある Elasticsearch ノードを選択し、データの解像度を設定できます。

   適切なダッシュボードが表示され、データの複数のチャートが表示されます。

3. 必要に応じて、Time Range メニューおよび Refresh Interval メニューから、データを表示する別の時間の範囲またはデータのリフレッシュレートを選択します。