ロギング

手順

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

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ....
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         rsyslog:
           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: '' 4
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ....

手順

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

   $ oc edit ClusterLogging instance

   $ oc edit ClusterLogging instance
   
   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     managementState: "Managed" 1

   1

   管理状態を Managed (管理対象) または Unmanaged (管理外) として指定します。

手順

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

   $ oc edit ClusterLogging instance

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

   1

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

手順

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

   oc edit clusterlogging instance

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

   1

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

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

手順

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

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

手順

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

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

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

   $ oc project openshift-logging

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

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

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

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

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

      1

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

   2. 作成したルート YAML に Elasticsearch CA 証明書を追加します。

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

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

      $ oc create -f <file-name>.yaml
      
      route.route.openshift.io/elasticsearch created

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

   1. 要求に使用されるこの ServiceAccount のトークンを取得します。

      $ token=$(oc whoami -t)

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

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

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

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}/.operations.*/_search?size=1" | jq

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

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

手順

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

   $ oc edit ClusterLogging instance

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
       visualization:
         type: "kibana"
         kibana:
           replicas:
         resources:  1
           limits:
             memory: 1Gi
           requests:
             cpu: 500m
             memory: 1Gi
         proxy:  2
           resources:
             limits:
               memory: 100Mi
             requests:
               cpu: 100m
               memory: 100Mi

   1

   各ノードに割り当てる CPU およびメモリー制限を指定します。

   2

   Kibana プロキシーに割り当てる CPU およびメモリー制限を指定します。

1. openshift-logging プロジェクトでクラスターロギングのカスタムリソース (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. 必要な場合は、Cluster Logging Operator のインストール時にデフォルトで作成される Kibana ルートを取得します。

   $ oc get routes -n openshift-logging
   
   NAMESPACE                  NAME                       HOST/PORT                                                            PATH     SERVICES                   PORT    TERMINATION          WILDCARD
   openshift-logging          kibana                     kibana-openshift-logging.apps.openshift.com                                   kibana                     <all>   reencrypt/Redirect   None

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

   $ oc get pods -l component=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

3. この手順で必要とされるユーザーごとに必要な設定を作成します。

   1. ダッシュボードを追加する必要のあるユーザーとして Kibana ダッシュボードにログインします。

      https://kibana-openshift-logging.apps.openshift.com 1

      1

      URL は Kibana ルートです。

   2. Authorize Access ページが表示される場合、すべてのパーミッションを選択してから Allow selected permissions をクリックします。
   3. Kibana ダッシュボードからログアウトします。

4. Elastiscearch Pod のいずれかの名前を使用して、Pod が置かれているプロジェクトで以下のコマンドを実行します。

   $ oc exec <es-pod> -- es_load_kibana_ui_objects <user-name>

   例:

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k -- es_load_kibana_ui_objects <user-name>

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

   $ 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

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

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

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

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

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

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 です。

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

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

2. 以下のコマンドを使用して CronJob を制御します。

   • CronJob を一時停止します。

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

   • CronJob を再開します。

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

   • CronJob スケジュールを変更します。

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

     1

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

1. Curator ConfigMap を編集します。

   oc edit cm/curator -n openshift-logging

2. action ファイルに以下の変更を加えます。

   actions:
   1:
         action: delete_indices 1
         description: >-
           Delete .operations indices older than 30 days.
           Ignore the error if the filter does not
           result in an actionable list of indices (ignore_empty_list).
           See https://www.elastic.co/guide/en/elasticsearch/client/curator/5.2/ex_delete_indices.html
         options:
           # Swallow curator.exception.NoIndices exception
           ignore_empty_list: True
           # In seconds, default is 300
           timeout_override: ${CURATOR_TIMEOUT}
           # Don't swallow any other exceptions
           continue_if_exception: False
           # Optionally disable action, useful for debugging
           disable_action: False
         # All filters are bound by logical AND
         filters:            2
         - filtertype: pattern
           kind: regex
           value: '^\.operations\..*$'
           exclude: False    3
         - filtertype: age
           # Parse timestamp from index name
           source: name
           direction: older
           timestring: '%Y.%m.%d'
           unit: days
           unit_count: 30
           exclude: False

   1

   delete_indices を指定して指定されたインデックスを削除します。

   2

   filers パラメーターを使用して削除されるインデックスを指定します。これらのパラメーターについての詳細は Elastic Search Curator のドキュメント を参照してください。

   3

   インデックスが削除されるように false を指定します。

手順

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

   $ oc edit ClusterLogging instance

   $ oc edit ClusterLogging instance
   
   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
   
   ....
   
   spec:
     collection:
       logs:
         fluentd:
           resources:
             limits: 1
               cpu: 250m
               memory: 1Gi
             requests:
               cpu: 250m
               memory: 1Gi

   1

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

1. fluentd daemonset で LOGGING_FILE_PATH パラメーターを編集します。特定のファイルまたは console を指定できます。

   spec:
     template:
       spec:
         containers:
             env:
               - name: LOGGING_FILE_PATH
                 value: console 1
   
   LOGGING_FILE_PATH= 2

   1

   ログの出力方法を指定します。

   • console を使用して Fluentd のデフォルトの場所を使用します。oc logs [-f] <pod_name> コマンドでログを取得します。

   • <path-to-log/fluentd.log> を使用してログ出力を指定されたファイルに送信します。`oc exec <pod_name> — logs コマンドでログを取得します。これはデフォルトの設定です。

     または、CLI を使用します。

     oc -n openshift-logging set env daemonset/fluentd LOGGING_FILE_PATH=console

手順

1. Fluentd を特定プロジェクトを制限するように設定するには、デプロイメント後に Fluentd ConfigMap でスロットル設定を編集します。

   $ oc edit configmap/fluentd

   throttle-config.yaml キーの形式は、プロジェクト名と、各ノードでのログの読み取りに必要な速度が含まれる YAML ファイルです。デフォルトはノードごとに一度に 1000 行です。例:

1. 必要に応じてフィールドの処理方法を設定します。

   1. CDM_EXTRA_KEEP_FIELDS を使用して移動するフィールドを指定します。
   2. CSV 形式で CDM_KEEP_EMPTY_FIELDS パラメーターで保持する空のフィールドをすべて指定します。

2. 必要に応じて未定義フィールドの処理方法を設定します。

   1. CDM_USE_UNDEFINED を true に設定し、未定義のフィールドを最上位の undefined フィールドに移動します。
   2. CDM_UNDEFINED_NAME パラメーターを使用して、未定義フィールドの名前を指定します。
   3. CDM_UNDEFINED_MAX_NUM_FIELDS をデフォルトの -1 以外の値に設定し、単一レコードにおける未定義フィールド数の上限を設定します。
3. CDM_UNDEFINED_DOT_REPLACE_CHAR を指定して、未定義フィールド名のすべてのドット (.) 文字を別の文字に変更します。たとえば、CDM_UNDEFINED_DOT_REPLACE_CHAR=@@@ の場合で、foo.bar.baz という名前のフィールドがある場合、そのフィールドは foo@@@bar@@@baz に変換されます。
4. UNDEFINED_TO_STRING を true に設定し、未定義フィールドを JSON 文字列表現に変換します。

1. openshift-logging プロジェクトで fluentd daemonset を編集します。

   $ oc edit ds/fluentd
   
   spec:
     template:
       spec:
         containers:
             env:
             - name: ES_HOST
               value: elasticsearch
             - name: ES_PORT
               value: '9200'
             - name: ES_CLIENT_CERT
               value: /etc/fluent/keys/app-cert
             - name: ES_CLIENT_KEY
               value: /etc/fluent/keys/app-key
             - name: ES_CA
               value: /etc/fluent/keys/app-ca
             - name: OPS_HOST
               value: elasticsearch
             - name: OPS_PORT
               value: '9200'
             - name: OPS_CLIENT_CERT
               value: /etc/fluent/keys/infra-cert
             - name: OPS_CLIENT_KEY
               value: /etc/fluent/keys/infra-key
             - name: OPS_CA
               value: /etc/fluent/keys/infra-ca

2. 外部 Elasticsearch インスタンスにアプリケーションログと操作ログの両方を含めるには、ES_HOST と OPS_HOST を同じ宛先に設定し、ES_PORT と OPS_PORT が同一の値を持つことを確認します。
3. TLS の外部でホストされる Elasticsearch インスタンスを設定します。相互 TLS を使用する外部でホストされた Elasticsearch インスタンスのみが許可されます。

手順

1. openshift-logging プロジェクトの fluentd daemonset で環境変数を設定します。

   spec:
     template:
       spec:
         containers:
           - name: fluentd
             image: 'registry.redhat.io/openshift4/ose-logging-fluentd:v4.1'
             env:
               - name: REMOTE_SYSLOG_HOST 1
                 value: host1
               - name: REMOTE_SYSLOG_HOST_BACKUP
                 value: host2
               - name: REMOTE_SYSLOG_PORT_BACKUP
                 value: 5555

   1

   必要なリモート syslog ホスト。各ホストで必須です。

   これによって 2 つの宛先が作成されます。host1 の syslog サーバーはデフォルトポート 514 でメッセージを受信し、host2 は同じメッセージをポート 5555 で受信します。

2. または、openshift-logging プロジェクトに独自の fluentd daemonset を設定できます。

   Fluentd 環境変数

   パラメーター	説明
   USE_REMOTE_SYSLOG	デフォルトは false です。fluent-plugin-remote-syslog gem を使用できるようにするには、true に設定します。
   REMOTE_SYSLOG_HOST	(必須) リモート syslog サーバーのホスト名または IP アドレス。
   REMOTE_SYSLOG_PORT	接続先のポート番号。デフォルトは 514 です。
   REMOTE_SYSLOG_SEVERITY	syslog の重大度を設定します。デフォルトは debug です。
   REMOTE_SYSLOG_FACILITY	syslog ファシリティーを設定します。デフォルトは local0 です。
   REMOTE_SYSLOG_USE_RECORD	デフォルトは false です。レコードの重大度フィールドおよびファシリティーフィールドを使用して syslog メッセージに設定するには、true に設定します。
   REMOTE_SYSLOG_REMOVE_TAG_PREFIX	タグからプレフィックスを削除します。デフォルトは '' (空) です。
   REMOTE_SYSLOG_TAG_KEY	これが指定されている場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにタグを設定します。
   REMOTE_SYSLOG_PAYLOAD_KEY	これが指定されている場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにペイロードを設定します。
   REMOTE_SYSLOG_TYPE	トランスポート層プロトコルタイプを設定します。デフォルトは syslog_buffered になり、これにより、TCP プロトコルが設定されます。UDP に切り替えるには、これを syslog に設定します。

   警告

   この実装は安全ではないため、接続にスヌーピングがないことを保証できる環境でのみ使用してください。

1. Fluentd 設定マップの secure-forward.conf セクションを編集します。

   $ oc edit configmap/fluentd -n openshift-logging

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

   #   <server>
   #     host server.fqdn.example.com  # or IP
   #     port 24284
   #   </server>
   #   <server>
   #     host 203.0.113.8 # ip address to connect
   #     name server.fqdn.example.com # The name of the server. Used for logging and certificate verification in TLS transport (when host is address).
   #   </server>

   例:

     <server>
       name externalserver1 1
       host 192.168.1.1 2
       port 24224 3
     </server>
     <server> 4
       name externalserver1
       host 192.168.1.2
       port 24224
     </server>
   </store>

   1

   オプションで、この外部のアグリゲーターの名前を入力します。

   2

   外部アグリゲーターのホスト名または IP を指定します。

   3

   外部アグリゲーターのポートを指定します。

   4

   オプションで、追加の外部のアグリゲーターを追加します。

3. CA 証明書とプライベートキーへのパスを secure-forward.conf セクションに追加します。

   #   <security>
   #     self_hostname ${hostname} # ${hostname} is a placeholder. 1
   #     shared_key <shared_key_between_forwarder_and_forwardee> 2
   #   </security>
   
   #   tls_cert_path /path/for/certificate/ca_cert.pem 3

   1

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

   2

   認証に共有キーを指定します。

   3

   CA 証明書へのパスを指定します。

   以下は例になります。

      <security>
        self_hostname client.fqdn.local
        shared_key cluster_logging_key
      </security>
   
      tls_cert_path /etc/fluent/keys/ca.crt

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

4. secure-forward.conf で使用される証明書を Fluentd Pod にマウントされる既存のシークレットに追加します。your_ca_cert と your_private_key の値は configmap/logging-fluentd の secure-forward.conf で指定されている値と一致している必要があります。

   $ oc patch secrets/fluentd --type=json \
     --patch "[{'op':'add','path':'/data/your_ca_cert','value':'$(base64 -w0 /path/to/your_ca_cert.pem)'}]"
   $ oc patch secrets/fluentd --type=json \
     --patch "[{'op':'add','path':'/data/your_private_key','value':'$(base64 -w0 /path/to/your_private_key.pem)'}]"

   注記

   your_private_key は、汎用的な名前に置き換えます。これは、JSON パスへのリンクであり、使用しているホストシステムのパスではありません。

   以下は例になります。

   $ oc patch secrets/fluentd --type=json \
     --patch "[{'op':'add','path':'/data/ca.crt','value':'$(base64 -w0 /etc/fluent/keys/ca.crt)'}]"
   $ oc patch secrets/fluentd --type=json \
     --patch "[{'op':'add','path':'/data/ext-agg','value':'$(base64 -w0 /etc/fluent/keys/ext-agg.pem)'}]"

5. 外部アグリゲーターで secure-forward.conf ファイルを設定し、Fluentd からのメッセージを安全に受け入れられるようにします。

   外部アグリゲーターを設定する際は、Fluentd からのメッセージを安全に受信できる必要があります。

手順

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

   Compress=no 1
   ForwardToConsole=yes 2
   ForwardToSyslog=no 3
   MaxRetentionSec=30s 4
   RateLimitBurst=10000 5
   RateLimitInterval=1s 6
   Storage=volatile 7
   SyncIntervalSec=1s 8
   SystemMaxUse=8g 9
   SystemKeepFree=20% 10
   SystemMaxFileSize10M 11

   1

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

   2 3

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

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

   4

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

   5 6

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

   7

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

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

   8

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

   9

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

   10

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

   11

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

   注記

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

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

2. journal.conf ファイルを base64 に変換します。

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

3. マスターまたはワーカー用に新規の MachineConfig を作成し、journal.conf パラメーターを追加します。

   例:

   ...
   
   config:
     storage:
       files:
       - contents:
           source: data:text/plain;charset=utf-8;base64,${jrnl_cnf}
           verification: {}
         filesystem: root
         mode: 0644 1
         path: /etc/systemd/journald.conf 2
     systemd: {}

   1

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

   2

   base64 でエンコードされた journal.conf ファイルへのパスを指定します。

4. MachineConfig を作成します。

   $ oc apply -f <filename>.yaml

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

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

   $ oc describe machineconfigpool/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