1. 在 OpenShift Container Platform 控制台中点击 Application Launcher 并选择 Logging。

2. 点 Management → Index Patterns → Create index pattern 创建 Kibana 索引模式:

   • 首次登录 Kibana 时，每个用户必须手动创建索引模式才能查看其项目的日志。用户必须创建一个名为 app 的索引模式，并使用 @timestamp 时间字段查看其容器日志。
   • 每个 admin 用户在首次登录 Kibana 时，必须使用 @timestamp 时间字段为 app、infra 和 audit 索引创建索引模式。
3. 从新的索引模式创建 Kibana 视觉化。

流程

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. 验证 Fluentd 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. 如果存在，从 ClusterLogging CR 中删除 logStore、visualization、curation 小节。

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. 验证 Fluentd Pod 是否已重新部署：

   $ oc get pods -n openshift-logging

1. 创建 ClusterLogForwarder CR YAML 文件或编辑现有的 CR：

   • 创建 CR 以将所有日志类型发送到内部 Elasticsearch 实例。您可以在不进行任何更改的情况下使用以下示例：

     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

     管道（pipeline）定义使用指定输出转发的日志类型。默认输出将日志转发到内部 Elasticsearch 实例。

     注意

     您必须在管道中指定所有三种类型的日志：应用程序、基础架构和审核。如果没有指定日志类型，这些日志将不会被存储并丢失。

   • 如果您有一个现有的 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，以添加或修改 reservedPolicy 参数：

   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 应该保留每个日志源的时间。输入一个整数和时间单位： 周(w)、小时(h/H)、分钟(m)和秒。例如，1d 代表一天。时间超过 maxAge 的旧日志会被删除。默认情况下，日志会保留 7 天。

2. 您可以验证 Elasticsearch 自定义资源（CR）中的设置。

   例如，Cluster Logging Operator 更新了以下 Elasticsearch CR 以配置保留策略，包括设置以每八小时滚动基础架构日志的活跃索引，并在滚动后 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 job，以使用定义的策略为每个映射滚动索引,并使用 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

   根据需要指定 Elasticsearch 的 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 为每个索引的主分片制作一个副本。只要存在至少两个数据节点，日志就能始终可用且可恢复。使用 5 个或更多节点时，性能胜过 MultipleRedundancy。您不能将此策略应用于单个 Elasticsearch 节点的部署。
   • ZeroRedundancy：Elasticsearch 不制作主分片的副本。如果节点关闭或发生故障， 则可能无法获得日志数据。如果您更关注性能而非安全性，或者实施了自己的磁盘/PVC 备份/恢复策略，可以考虑使用此模式。

流程

1. 编辑 ClusterLogging CR，将集群中的每个数据节点指定为绑定到持久性卷声明。

   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 证书或使用下一步中的命令。您不必设置一些重新加密路由所需的 spec.tls.key、spec.tls.certificate 和 spec.tls.caCertificate 参数。

   2. 运行以下命令，将日志存储 CA 证书添加到您在上一步中创建的路由 YAML 中：

      $ 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

   根据需要为日志 visualizer 指定 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

   根据需要为日志 visualizer 指定 CPU 和内存限值和请求。

   4

   根据需要为日志记录器指定 CPU 和内存限值及请求。

   5

   根据需要指定日志收集器的 CPU 和内存限值及请求。

流程

1. 使用以下命令，将污点添加到要在其上调度集群日志记录 pod 的节点：

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

   例如：

   $ oc adm taint nodes node1 elasticsearch=node:NoExecute

   本例在 node1 上放置一个键为 elasticsearch 且值为 node 的污点，污点效果是 NoExecute。具有 NoExecute 效果的节点仅调度与污点匹配的 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 效果。

   4

   （可选）指定 tolerationSeconds 参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。

流程

1. 使用以下命令，将污点添加到要在其上调度日志可视化 pod：

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

   例如：

   $ oc adm taint nodes node1 kibana=node:NoExecute

   本例在 node1 上放置一个键为 kibana 且值为 node 的污点，污点效果是 NoExecute。您必须使用 NoExecute 污点设置。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 运算符，以要求匹配 key/value/effect 参数。

   3

   指定 NoExecute 效果。

   4

   （可选）指定 tolerationSeconds 参数，以设置 pod 在被逐出前可以保持绑定到节点的时长。

流程

1. 使用以下命令，将污点添加到要在其上调度日志记录收集器 pod 的节点：

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

   例如：

   $ oc adm taint nodes node1 collector=node:NoExecute

   本例在 node1 上放置一个键为 collector 且值为 node 的污点，污点效果是 NoExecute。您必须使用 NoExecute 污点设置。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 运算符，以要求匹配 key/value/effect 参数。

   3

   指定 NoExecute 效果。

   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 将信息作为墙信息转发给所有登录的用户。

   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. 创建一个 MachineConfig 对象，其中包含上一步中创建的 jrnl_cnf 变量。以下示例命令为 worker 创建 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

   可选： 对于 control plane（也称为 master）节点，您可以提供文件名为 40-master-custom-journald.yaml。

   2

   可选： 对于 control plane（也称为 master）节点，将角色提供为 master。

   3

   可选： 对于 control plane（也称为 master）节点，您可以提供名称为 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

   以 cron 格式指定 Curator 的调度。

   注意

   时区是根据 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 日志，请使用 .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 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 elasticsearch 类型。

   5

   指定外部 Elasticsearch 实例的 URL 和端口作为有效的绝对 URL。您可以使用 http （不安全）或 https （安全 HTTP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 https 前缀，则必须指定 TLS 通信端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的 tls.crt、tls.key 和 ca-bundle.crt 的键。

   7

   可选：指定管道的名称。

   8

   指定使用该管道转发哪些日志类型：application、infrastructure 或 audit。

   9

   指定要与该管道搭配使用的输出来转发日志。

   10

   可选：指定将日志发送到内部 Elasticsearch 实例的 default 输出。

   11

   可选：字符串。要添加到日志中的一个或多个标签。

   12

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 可选。描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

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 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 fluentdForward 类型。

   5

   指定外部 Fluentd 实例的 URL 和端口作为有效的绝对 URL。您可以使用 tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的 tls.crt、tls.key 和 ca-bundle.crt 的键。

   7

   可选。为管道指定一个名称。

   8

   指定使用该管道转发哪些日志类型：application、infrastructure 或 audit。

   9

   指定要与该管道搭配使用的输出来转发日志。

   10

   可选。指定将日志转发到内部 Elasticsearch 实例的默认输出。

   11

   可选：字符串。要添加到日志中的一个或多个标签。

   12

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 可选。描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

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 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 syslog 类型。

   5

   可选。指定以下列出的 syslog 参数。

   6

   指定外部 syslog 实例的 URL 和端口。您可以使用 udp （不安全）、tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   7

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的 tls.crt、tls.key 和 ca-bundle.crt 的键。

   8

   可选：指定管道的名称。

   9

   指定使用该管道转发哪些日志类型：application、infrastructure 或 audit。

   10

   指定要与该管道搭配使用的输出来转发日志。

   11

   可选：指定将日志转发到内部 Elasticsearch 实例的 default 输出。

   12

   可选：字符串。要添加到日志中的一个或多个标签。对值加引号（如 "true"），以便它们被识别为字符串值，而不是作为布尔值。

   13

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 可选。描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

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 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定 kafka 类型。

   5

   将 Kafka 代理的 URL 和端口指定为一个有效的绝对 URL，也可以同时指定特定标题。您可以使用 tcp （不安全）或者 tls （安全 TCP）协议。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的 tls.crt、tls.key 和 ca-bundle.crt 的键。

   7

   可选： 要发送不安全的输出，在 URL 前面使用 tcp 前缀。另外，省略此输出中的 secret 键及其 name。

   8

   可选：指定管道的名称。

   9

   指定使用该管道转发哪些日志类型：application、infrastructure 或 audit。

   10

   指定要与该管道搭配使用的输出来转发日志。

   11

   可选：字符串。要添加到日志中的一个或多个标签。

   12

   可选：配置多个输出，将日志转发到任何受支持类型的其他外部日志聚合器：

   • 可选。描述管道的名称。
   • inputRefs 是使用管道转发的日志类型：application、infrastructure 或 audit。
   • outputRefs 是要使用的输出名称。
   • 可选：字符串。要添加到日志中的一个或多个标签。

   13

   可选：指定 default 将日志转发到内部 Elasticsearch 实例。

2. 可选： 要将单个输出转发到多个 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 键指定一个或多个代理的数组。

   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 的命名空间必须是 openshift-logging。

   3

   指定输出的名称。

   4

   指定输出类型： elasticsearch、fluentdForward、syslog 或 kafka。

   5

   将外部日志聚合器的 URL 和端口指定为有效的绝对 URL。如果启用了使用 CIDR 注解的集群范围代理，输出必须是服务器名称或 FQDN，而不是 IP 地址。

   6

   如果使用 tls 前缀，您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于 openshift-logging 项目中，且必须具有指向它们所代表的相应证书的 tls.crt、tls.key 和 ca-bundle.crt 的键。

   7

   用于过滤指定项目的应用程序日志的输入配置。

   8

   管道配置，使用输入将项目应用程序日志发送到外部 Fluentd 实例。

   9

   my-app-logs 输入。

   10

   要使用的输出名称。

   11

   可选：字符串。要添加到日志中的一个或多个标签。

   12

   管道配置，将日志发送到其他日志聚合器。

   • 可选：指定管道的名称。
   • 指定使用该管道转发哪些日志类型：application、infrastructure 或 audit。
   • 指定要与该管道搭配使用的输出来转发日志。
   • 可选：指定将日志转发到内部 Elasticsearch 实例的 default 输出。
   • 可选：字符串。要添加到日志中的一个或多个标签。

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 以忽略服务器 cert 主机名。

   4

   将私有 CA 证书文件的路径指定为 /etc/ocp-forward/ca_cert.pem。

   5

   根据需要指定 Fluentd 缓冲参数。

   6

   可选：为这个服务器输入一个名称。

   7

   指定服务器的主机名或 IP。

   8

   指定服务器的主机标识。

   9

   指定服务器的端口。

   10

   （可选）添加额外的服务器。如果您指定了两个或者两个以上的服务器，forward 会以轮循（round-robin）顺序使用这些服务器节点。

   要使用 Mutual 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

   指定接收方的端口。

   4

   可选：指定适当的 syslog 参数，例如：

   • 从 syslog 前缀中删除指定的 tag 字段的参数。
   • 参数将指定的字段设置为 syslog 键。
   • 指定 syslog 日志工具或源的参数。
   • 指定 syslog 日志严重性参数。
   • 参数来使用记录中的严重性和工具（如果可用）。如果为 true$1则输出内容中包含 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 Pod 的相关信息，包括 Elasticsearch 集群健康状态 green、yellow 或 red。

      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 不可调度。此外还显示适用于多个问题的情况，具体请参阅情况消息示例。

      4

      集群中的日志存储节点，带有 upgradeStatus。

      5

      集群中的日志存储客户端、数据和 master 节点，列在 failed、notReady 或 ready 状态下。

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. 在红帽客户门户中为您的问题单附上压缩文件。