ロギング

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-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     collection:
       logs:
         fluentd:
           resources:
             limits: 1
               memory: 736Mi
             requests:
               cpu: 100m
               memory: 736Mi

   1

   必要に応じて CPU、メモリー制限および要求を指定します。表示される値はデフォルト値です。

手順

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

   $ oc edit ClusterLogging instance

2. 以下のパラメーターを追加または変更します。

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   metadata:
     name: instance
     namespace: openshift-logging
   spec:
     forwarder:
       fluentd:
         buffer:
           chunkLimitSize: 8m 1
           flushInterval: 5s 2
           flushMode: interval 3
           flushThreadCount: 3 4
           overflowAction: throw_exception 5
           retryMaxInterval: "300s" 6
           retryType: periodic 7
           retryWait: 1s 8
           totalLimitSize: 32m 9
   ...

   1

   各チャンクの最大サイズを指定してから、フラッシュ用にキューに入れます。

   2

   チャンクのフラッシュの間隔を指定します。

   3

   チャンクのフラッシュを実行する方法を指定します ( lazy、interval、または immediate)。

   4

   チャンクのフラッシュに使用するスレッドの数を指定します。

   5

   キューが一杯になる場合のチャンクの動作を指定します (throw_exception、block、または drop_oldest_chunk)。

   6

   exponential_backoff チャンクのフラッシュ方法について最大の間隔 (秒単位) を指定します。

   7

   チャンクのフラッシュが失敗する場合の再試行タイプ (exponential_backoff または periodic) を指定します。

   8

   次のチャンクのフラッシュまでの時間 (秒単位) を指定します。

   9

   チャンクバッファーの最大サイズを指定します。

3. Flunentd Pod が再デプロイされていることを確認します。

   $ oc get pods -n openshift-logging

4. 新規の値が fluentd 設定マップにあることを確認します。

   $ oc extract configmap/fluentd --confirm

   fluentd.conf の例

   <buffer>
    @type file
    path '/var/lib/fluentd/default'
    flush_mode interval
    flush_interval 5s
    flush_thread_count 3
    retry_type periodic
    retry_wait 1s
    retry_max_interval 300s
    retry_timeout 60m
    queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}"
    total_limit_size 32m
    chunk_limit_size 8m
    overflow_action throw_exception
   </buffer>

手順

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

   $ oc edit ClusterLogging instance

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

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

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

4. Flunentd Pod が再デプロイされていることを確認します。

   $ oc get pods -n openshift-logging

1. ClusterLogForwarder CR YAML ファイルを作成するか、または既存の CR を編集します。

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

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

     1

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

     注記

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

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

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

     1

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

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

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

   1

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

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

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

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

   1

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

   2

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

   3

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

   4

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

   注記

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

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

   $ oc get cronjob

   出力例

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

手順

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

   $ oc edit ClusterLogging instance

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

   1

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

   2

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

手順

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

   $ oc edit clusterlogging instance

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

   1

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

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

手順

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

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

手順

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

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

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

   $ oc project openshift-logging

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

   $ oc get pods | grep elasticsearch-

3. Fluentd Pod をスケールダウンし、新規ログの Elasticsearch への送信を停止します。

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

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

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

   以下に例を示します。

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

   出力例

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

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

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

   以下に例を示します。

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

   出力例

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

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

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

      $ oc rollout resume deployment/<deployment-name>

      以下に例を示します。

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

      出力例

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

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

      $ oc get pods | grep elasticsearch-

      出力例

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

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

      $ oc rollout pause deployment/<deployment-name>

      以下に例を示します。

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

      出力例

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

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

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

      注記

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

      以下に例を示します。

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

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

      1

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

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

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

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

   以下に例を示します。

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

   出力例

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

9. Fluentd Pod をスケールアップして、新規ログを Elasticsearch に送信します。

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

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

   $ oc project openshift-logging

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

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

   出力例

   admin-ca

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

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

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

      1

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

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

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

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

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

      出力例

      route.route.openshift.io/elasticsearch created

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

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

      $ token=$(oc whoami -t)

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

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

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

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

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

      出力例

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

手順

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

   $ oc edit ClusterLogging instance -n openshift-logging

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 2
         resources: 1
           limits:
             memory: 2Gi
           requests:
             cpu: 200m
             memory: 2Gi
         storage:
           storageClassName: "gp2"
           size: "200G"
         redundancyPolicy: "SingleRedundancy"
     visualization:
       type: "kibana"
       kibana:
         resources: 2
           limits:
             memory: 1Gi
           requests:
             cpu: 500m
             memory: 1Gi
         proxy:
           resources: 3
             limits:
               memory: 100Mi
             requests:
               cpu: 100m
               memory: 100Mi
         replicas: 2
     curation:
       type: "curator"
       curator:
         resources: 4
           limits:
             memory: 200Mi
           requests:
             cpu: 200m
             memory: 200Mi
         schedule: "*/10 * * * *"
     collection:
       logs:
         type: "fluentd"
         fluentd:
           resources: 5
             limits:
               memory: 736Mi
             requests:
               cpu: 200m
               memory: 736Mi

   1

   必要に応じてログの CPU およびメモリーの制限および要求を指定します。Elasticsearch の場合、要求値と制限値の両方を調整する必要があります。

   2 3

   必要に応じて、ログビジュアライザーの CPU およびメモリーの制限および要求を指定します。

   4

   必要に応じて、ログキュレーターの CPU およびメモリーの制限および要求を指定します。

   5

   必要に応じて、ログコレクターの CPU およびメモリーの制限および要求を指定します。

手順

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

   $ oc edit ClusterLogging instance

   $ oc edit ClusterLogging instance
   
   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
       visualization:
         type: "kibana"
         kibana:
           replicas: 1 1

   1

   Kibana ノードの数を指定します。

手順

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

   $ oc edit ClusterLogging instance -n openshift-logging

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 2
         resources: 1
           limits:
             memory: 2Gi
           requests:
             cpu: 200m
             memory: 2Gi
         storage:
           storageClassName: "gp2"
           size: "200G"
         redundancyPolicy: "SingleRedundancy"
     visualization:
       type: "kibana"
       kibana:
         resources: 2
           limits:
             memory: 1Gi
           requests:
             cpu: 500m
             memory: 1Gi
         proxy:
           resources: 3
             limits:
               memory: 100Mi
             requests:
               cpu: 100m
               memory: 100Mi
         replicas: 2
     curation:
       type: "curator"
       curator:
         resources: 4
           limits:
             memory: 200Mi
           requests:
             cpu: 200m
             memory: 200Mi
         schedule: "*/10 * * * *"
     collection:
       logs:
         type: "fluentd"
         fluentd:
           resources: 5
             limits:
               memory: 736Mi
             requests:
               cpu: 200m
               memory: 736Mi

   1

   必要に応じてログの CPU およびメモリーの制限および要求を指定します。Elasticsearch の場合、要求値と制限値の両方を調整する必要があります。

   2 3

   必要に応じて、ログビジュアライザーの CPU およびメモリーの制限および要求を指定します。

   4

   必要に応じて、ログキュレーターの CPU およびメモリーの制限および要求を指定します。

   5

   必要に応じて、ログコレクターの CPU およびメモリーの制限および要求を指定します。

手順

1. 以下のコマンドを使用して、クラスターロギング Pod をスケジュールするノードにテイントを追加します。

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

   以下は例になります。

   $ oc adm taint nodes node1 elasticsearch=node:NoExecute

   この例では、テイントをキー elasticsearch、値 node、およびテイントの効果 NoExecute のある node1 に配置します。NoExecute effect のノードは、テイントに一致する Pod のみをスケジュールし、一致しない既存の Pod を削除します。

2. ClusterLogging CR の logstore セクションを編集し、Elasticsearch Pod の容認を設定します。

     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 1
         tolerations:
         - key: "elasticsearch"  1
           operator: "Exists"  2
           effect: "NoExecute"  3
           tolerationSeconds: 6000  4

   1

   ノードに追加したキーを指定します。

   2

   Exists Operator を指定し、キー elasticsearch のあるテイントがノードに存在する必要があるようにします。

   3

   NoExecute effect を指定します。

   4

   オプションで、tolerationSeconds パラメーターを指定して、エビクトされる前に Pod がノードにバインドされる期間を設定します。

手順

1. 以下のコマンドを使用して、ログビジュアライザー Pod をスケジュールする必要のあるノードにテイントを追加します。

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

   以下に例を示します。

   $ oc adm taint nodes node1 kibana=node:NoExecute

   この例では、テイントをキー kibana、値 node、およびテイントの効果 NoExecute のある node1 に配置します。NoExecute テイント effect を使用する必要があります。NoExecute は、テイントに一致する Pod のみをスケジュールし、一致しない既存の Pod を削除します。

2. ClusterLogging CR の visualization セクションを編集し、Kibana Pod の容認を設定します。

     visualization:
       type: "kibana"
       kibana:
         tolerations:
         - key: "kibana"  1
           operator: "Exists"  2
           effect: "NoExecute"  3
           tolerationSeconds: 6000 4

   1

   ノードに追加したキーを指定します。

   2

   Exists Operator を指定して、key/value/effect パラメーターが一致するようにします。

   3

   NoExecute effect を指定します。

   4

   オプションで、tolerationSeconds パラメーターを指定して、エビクトされる前に Pod がノードにバインドされる期間を設定します。

手順

1. 以下のコマンドを使用して、ロギングコレクター Pod がロギングコレクター Pod をスケジュールする必要のあるノードにテイントを追加します。

   $ oc adm taint nodes <node-name> <key>=<value>:<effect>

   以下に例を示します。

   $ oc adm taint nodes node1 collector=node:NoExecute

   この例では、テイントをキー collector、値 node、およびテイント effect NoExecute のある node1 に配置します。NoExecute テイント effect を使用する必要があります。NoExecute は、テイントに一致する Pod のみをスケジュールし、一致しない既存の Pod を削除します。

2. ClusterLogging カスタムリソース (CR) の collection スタンザを編集して、ロギングコレクター Pod の容認を設定します。

     collection:
       logs:
         type: "fluentd"
         fluentd:
           tolerations:
           - key: "collector"  1
             operator: "Exists"  2
             effect: "NoExecute"  3
             tolerationSeconds: 6000  4

   1

   ノードに追加したキーを指定します。

   2

   Exists Operator を指定して、key/value/effect パラメーターが一致するようにします。

   3

   NoExecute effect を指定します。

   4

   オプションで、tolerationSeconds パラメーターを指定して、エビクトされる前に Pod がノードにバインドされる期間を設定します。

手順

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

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ...
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     curation:
       curator:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ''
         resources: null
         schedule: 30 3 * * *
       type: curator
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 3
           node-role.kubernetes.io/infra: ''
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ...

手順

1. 必要な設定で journald.conf ファイルを作成します。

   Compress=yes 1
   ForwardToConsole=no 2
   ForwardToSyslog=no
   MaxRetentionSec=1month 3
   RateLimitBurst=10000 4
   RateLimitIntervalSec=30s
   Storage=persistent 5
   SyncIntervalSec=1s 6
   SystemMaxUse=8g 7
   SystemKeepFree=20% 8
   SystemMaxFileSize=10M 9

   1

   ログがファイルシステムに書き込まれる前にそれらのログを圧縮するかどうかを指定します。yes を指定してメッセージを圧縮するか、または no を指定して圧縮しないようにします。デフォルトは yes です。

   2

   ログメッセージを転送するかどうかを設定します。それぞれについて、デフォルトで no に設定されます。以下を指定します。

   • ForwardToConsole: ログをシステムコンソールに転送します。
   • ForwardToKsmg: ログをカーネルログバッファーに転送します。
   • ForwardToSyslog: syslog デーモンに転送します。
   • ForwardToWall: メッセージを wall メッセージとしてすべてのログインしているユーザーに転送します。

   3

   ジャーナルエントリーを保存する最大時間を指定します。数字を入力して秒数を指定します。または、year、month、week、day、h または m などの単位を含めます。無効にするには 0 を入力します。デフォルトは 1month です。

   4

   レート制限を設定します。RateLimitIntervalSec で定義される期間に、 RateLimitBurst で指定される以上のログが受信される場合、この期間内の追加のメッセージすべてはこの期間が終了するまでにドロップされます。デフォルト値である RateLimitIntervalSec=30s および RateLimitBurst=10000 を設定することが推奨されます。

   5

   ログの保存方法を指定します。デフォルトは persistent です。

   • volatile: ログを /var/log/journal/ のメモリーに保存します。
   • persistent: ログを /var/log/journal/ のディスクに保存します。systemd は存在しない場合はディレクトリーを作成します。
   • auto: ディレクトリーが存在する場合に、ログを /var/log/journal/ に保存します。存在しない場合は、systemd はログを /run/systemd/journal に一時的に保存します。
   • none: ログを保存しません。systemd はすべてのログをドロップします。

   6

   ERR、WARNING、NOTICE、INFO、および DEBUG ログについてジャーナルファイルをディスクに同期させるまでのタイムアウトを指定します。 systemd は、CRIT、ALERT、または EMERG ログの受信後すぐに同期を開始します。デフォルトは 1s です。

   7

   ジャーナルが使用できる最大サイズを指定します。デフォルトは 8g です。

   8

   systemd が残す必要のあるディスク領域のサイズを指定します。デフォルトは 20% です。

   9

   /var/log/journal に永続的に保存される個別のジャーナルファイルの最大サイズを指定します。デフォルトは 10M です。

   注記

   レート制限を削除する場合、システムロギングデーモンの CPU 使用率が高くなることがあります。 以前はスロットリングされていた可能性のあるメッセージが処理されるためです。

   systemd 設定の詳細については、https://www.freedesktop.org/software/systemd/man/journald.conf.html を参照してください。このページに一覧表示されるデフォルト設定は OpenShift Container Platform には適用されない可能性があります。

2. 次のコマンドを実行して、journal.conf ファイルを base64 に変換し、jrnl_cnf という名前の変数に保存します。

   $ export jrnl_cnf=$( cat journald.conf | base64 -w0 )

3. 前の手順で作成した jrnl_cnf 変数を含む MachineConfig オブジェクトを作成します。次のサンプルコマンドは、ワーカーの MachineConfig オブジェクトを作成します。

   $ cat << EOF > ./40-worker-custom-journald.yaml 1
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker 2
     name: 40-worker-custom-journald 3
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 3.1.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,${jrnl_cnf} 4
             verification: {}
           filesystem: root
           mode: 0644 5
           path: /etc/systemd/journald.conf.d/custom.conf
     osImageURL: ""
   EOF

   1

   オプション: コントロールプレーン (マスターとも呼ばれます) ノードの場合、ファイル名を 40-master-custom-journald.yaml として指定できます。

   2

   オプション: コントロールプレーン (マスターとも呼ばれます) ノードの場合、master としてのロールを指定します。

   3

   オプション: コントロールプレーン (マスターとも呼ばれます) ノードの場合、名前を 40-master-custom-journald として指定できます。

   4

   オプション: journald.conf ファイルにパラメーターの静的コピーを含めるには、${jrnl_cnf} を echo$jrnl_cnf コマンドの出力に置き換えます。

   5

   journal.conf ファイルのパーミッションを設定します。0644 パーミッションを設定することが推奨されます。

4. マシン設定を作成します。

   $ oc apply -f <file_name>.yaml

   コントローラーは新規の MachineConfig オブジェクトを検出し、新規の rendered-worker-<hash> バージョンを生成します。

5. 新規のレンダリングされた設定の各ノードへのロールアウトのステータスをモニターします。

   $ oc describe machineconfigpool/<node> 1

   1

   ノードを master または worker として指定します。

   worker の出力例

   Name:         worker
   Namespace:
   Labels:       machineconfiguration.openshift.io/mco-built-in=
   Annotations:  <none>
   API Version:  machineconfiguration.openshift.io/v1
   Kind:         MachineConfigPool
   
   ...
   
   Conditions:
     Message:
     Reason:                All nodes are updating to rendered-worker-913514517bcea7c93bd446f4830bc64e

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

   $ oc edit clusterlogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ...
   
     curation:
       curator:
         schedule: 30 3 * * * 1
       type: curator

   1

   Curator のスケジュールを cron 形式 で指定します。

   注記

   タイムゾーンは Curator Pod が実行されるホストノードに基づいて設定されます。

1. OpenShift Container Platform カスタム Curator 設定ファイルを編集します。

   $ oc edit configmap/curator

2. 必要に応じて以下のパラメーターを設定します。

   config.yaml: |
     project_name:
       action
         unit:value

   利用可能なパラメーターを以下に示します。

   表3.2 プロジェクトオプション

   変数名	説明
   project_name	プロジェクトの実際の名前 (myapp-devel など)。OpenShift Container Platform の操作ログについては、名前 .operations をプロジェクト名として使用します。
   action	実行するアクション。現在許可されているのは delete のみです。
   unit	削除に使用する期間 (days、weeks、または months)。
   value	単位数。

   表3.3 フィルターオプション

   変数名	説明
   .defaults	.defaults を project_name として使用し、指定されていないプロジェクトのデフォルトを設定します。
   .regex	プロジェクト名に一致する正規表現の一覧。
   pattern	適切にエスケープされた有効な正規表現パターン。一重引用符で囲まれています。

手順

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
        labels:
          myLabel: "myValue" 11
      - name: infrastructure-audit-logs 12
        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

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

   12

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

   • オプション。パイプラインを説明する名前。
   • 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
        labels:
          clusterId: "C1234" 11
      - name: forward-to-fluentd-insecure 12
        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

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

   12

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

   • オプション。パイプラインを説明する名前。
   • 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
        labels:
          secure: "true" 12
          syslog: "east"
      - name: syslog-west 13
        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

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

   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: 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
        labels:
          logType: "application" 11
      - name: infra-topic 12
        inputRefs:
        - infrastructure
        outputRefs:
        - infra-logs
        labels:
          logType: "infra"
      - name: audit-topic
        inputRefs:
        - audit
        outputRefs:
        - audit-logs
        - default 13
        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

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

   12

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

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

   13

   オプション: ログを内部 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
        labels: 11
          project: "my-project"
      - name: forward-to-fluentd-secure 12
        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

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

   12

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

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

2. 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. openshift-logging プロジェクトに切り替えます。

   $ oc project openshift-logging

2. クラスターロギングのステータスを表示するには、以下を実行します。

   1. クラスターロギングのステータスを取得します。

      $ oc get clusterlogging instance -o yaml

      出力例

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      
      ....
      
      status:  1
        collection:
          logs:
            fluentdStatus:
              daemonSet: fluentd  2
              nodes:
                fluentd-2rhqp: ip-10-0-169-13.ec2.internal
                fluentd-6fgjh: ip-10-0-165-244.ec2.internal
                fluentd-6l2ff: ip-10-0-128-218.ec2.internal
                fluentd-54nx5: ip-10-0-139-30.ec2.internal
                fluentd-flpnn: ip-10-0-147-228.ec2.internal
                fluentd-n2frh: ip-10-0-157-45.ec2.internal
              pods:
                failed: []
                notReady: []
                ready:
                - fluentd-2rhqp
                - fluentd-54nx5
                - fluentd-6fgjh
                - fluentd-6l2ff
                - fluentd-flpnn
                - fluentd-n2frh
        logstore: 3
          elasticsearchStatus:
          - ShardAllocationEnabled:  all
            cluster:
              activePrimaryShards:    5
              activeShards:           5
              initializingShards:     0
              numDataNodes:           1
              numNodes:               1
              pendingTasks:           0
              relocatingShards:       0
              status:                 green
              unassignedShards:       0
            clusterName:             elasticsearch
            nodeConditions:
              elasticsearch-cdm-mkkdys93-1:
            nodeCount:  1
            pods:
              client:
                failed:
                notReady:
                ready:
                - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
              data:
                failed:
                notReady:
                ready:
                - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
              master:
                failed:
                notReady:
                ready:
                - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
      visualization:  4
          kibanaStatus:
          - deployment: kibana
            pods:
              failed: []
              notReady: []
              ready:
              - kibana-7fb4fd4cc9-f2nls
            replicaSets:
            - kibana-7fb4fd4cc9
            replicas: 1

      1

      出力の status スタンザに、クラスターステータスのフィールドが表示されます。

      2

      Fluentd Pod についての情報

      3

      Elasticsearch クラスターの健全性 (green、yellow、または red) などの Elasticsearch Pod についての情報

      4

      Kibana Pod についての情報

手順

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

   $ oc project openshift-logging

2. クラスターロギング環境のステータスを表示します。

   $ oc describe deployment cluster-logging-operator

   出力例

   Name:                   cluster-logging-operator
   
   ....
   
   Conditions:
     Type           Status  Reason
     ----           ------  ------
     Available      True    MinimumReplicasAvailable
     Progressing    True    NewReplicaSetAvailable
   
   ....
   
   Events:
     Type    Reason             Age   From                   Message
     ----    ------             ----  ----                   -------
     Normal  ScalingReplicaSet  62m   deployment-controller  Scaled up replica set cluster-logging-operator-574b8987df to 1----

3. クラスターロギングレプリカセットのステータスを表示します。

   1. レプリカセットの名前を取得します。

      出力例

      $ oc get replicaset

      出力例

      NAME                                      DESIRED   CURRENT   READY   AGE
      cluster-logging-operator-574b8987df       1         1         1       159m
      elasticsearch-cdm-uhr537yu-1-6869694fb    1         1         1       157m
      elasticsearch-cdm-uhr537yu-2-857b6d676f   1         1         1       156m
      elasticsearch-cdm-uhr537yu-3-5b6fdd8cfd   1         1         1       155m
      kibana-5bd5544f87                         1         1         1       157m

   2. レプリカセットのステータスを取得します。

      $ oc describe replicaset cluster-logging-operator-574b8987df

      出力例

      Name:           cluster-logging-operator-574b8987df
      
      ....
      
      Replicas:       1 current / 1 desired
      Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed
      
      ....
      
      Events:
        Type    Reason            Age   From                   Message
        ----    ------            ----  ----                   -------
        Normal  SuccessfulCreate  66m   replicaset-controller  Created pod: cluster-logging-operator-574b8987df-qjhqv----

手順

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

   $ oc project openshift-logging

2. ステータスを表示するには、以下を実行します。

   1. ログストアインスタンスの名前を取得します。

      $ oc get Elasticsearch

      出力例

      NAME            AGE
      elasticsearch   5h9m

   2. ログストアのステータスを取得します。

      $ oc get Elasticsearch <Elasticsearch-instance> -o yaml

      以下に例を示します。

      $ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml

      出力には、以下のような情報が含まれます。

      出力例

      status: 1
        cluster: 2
          activePrimaryShards: 30
          activeShards: 60
          initializingShards: 0
          numDataNodes: 3
          numNodes: 3
          pendingTasks: 0
          relocatingShards: 0
          status: green
          unassignedShards: 0
        clusterHealth: ""
        conditions: [] 3
        nodes: 4
        - deploymentName: elasticsearch-cdm-zjf34ved-1
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-2
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-3
          upgradeStatus: {}
        pods: 5
          client:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          data:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          master:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
        shardAllocationEnabled: all

      1

      出力の status スタンザに、クラスターステータスのフィールドが表示されます。

      2

      ログストアのステータス:

      • アクティブなプライマリーシャードの数
      • アクティブなシャードの数
      • 初期化されるシャードの数
      • ログストアデータノードの数。
      • ログストアノードの合計数。
      • 保留中のタスクの数。
      • ログストアのステータス: green、red、yellow。
      • 未割り当てのシャードの数。

      3

      ステータス状態 (ある場合)。ログストアのステータスは、Pod が配置されていない場合にスケジューラーからの理由を示します。以下の状況に関連したイベントが表示されます。

      • ログストアおよびプロキシーコンテナーの両方についてコンテナーが待機中。
      • ログストアおよびプロキシーコンテナーの両方についてコンテナーが終了している。
      • Pod がスケジュール対象外である。さらに多数の問題についての状態が表示されます。詳細は、状態メッセージのサンプル を参照してください。

      4

      upgradeStatus のあるクラスター内のログストアノード。

      5

      'failed`、notReady または ready 状態の下に一覧表示された、クラスター内のログストアクライアント、データ、およびマスター Pod。

1. OpenShift Container Platform コンソールで、Monitoring → Alerting をクリックします。
2. Alerts タブをクリックします。選択したフィルターに基づいてアラートが一覧表示されます。

1. Curator のデバッグログを有効にします。

   $ oc set env cronjob/curator CURATOR_LOG_LEVEL=DEBUG CURATOR_SCRIPT_LOG_LEVEL=DEBUG

   ログレベルを指定します。

   • CRITICAL。Curator は重大なメッセージのみを表示します。
   • ERROR。Curator はエラーおよび重大なメッセージのみを表示します。
   • WARNING。Curator はエラー、警告、および重大なメッセージのみを表示します。
   • INFO。Curator は情報、エラー、警告、および重大なメッセージのみを表示します。

   • DEBUG。Curator は上記のすべてに加えてデバッグメッセージのみを表示します。

     デフォルト値は INFO です。

     注記

     クラスターロギングは、OpenShift Container Platform ラッパースクリプト (run.sh および convert.py) で OpenShift Container Platform カスタム環境変数 CURATOR_SCRIPT_LOG_LEVEL を使用します。この環境変数は、必要に応じてスクリプトのデバッグ用に CURATOR_LOG_LEVEL と同じ値を取ります。

2. 次の Curator の反復をトリガーします。

   $ oc create job --from=cronjob/curator <job_name>

3. 以下のコマンドを使用して cron ジョブを制御します。

   • cron ジョブを一時停止します。

     $ oc patch cronjob curator -p '{"spec":{"suspend":true}}'

   • cron ジョブを再開します。

     $ oc patch cronjob curator -p '{"spec":{"suspend":false}}'

   • cron ジョブスケジュールを変更します。

     $ oc patch cronjob curator -p '{"spec":{"schedule":"0 0 * * *"}}' 1

     1

     schedule オプションは、cron 形式 のスケジュールを受け入れます。

1. must-gather 情報を保存する必要のあるディレクトリーに移動します。

2. クラスターロギングイメージに対して oc adm must-gather コマンドを実行します。

   $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

   must-gather ツールは、現行ディレクトリー内の must-gather.local で始まる新規ディレクトリーを作成します。例: must-gather.local.4157245944708210408

3. 作成された must-gather ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。

   $ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408

4. 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。