9.2. 配置日志存储

1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件：

   • 创建 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）中的设置。

   例如，Red Hat OpenShift Logging Operator 更新了以下 Elasticsearch CR 以配置保留策略，包括设置以每八小时滚动基础架构日志的活跃索引，并在滚动后 7 天删除滚动的索引。Red Hat OpenShift Service on AWS 每 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

   当 Red Hat OpenShift Service on AWS 删除滚动索引时。此设置是在 ClusterLogging CR 中设置的 maxAge。

   3

   Red Hat OpenShift Service on AWS 的索引年龄，在滚动索引时需要考虑。此值由 ClusterLogging CR 中的 maxAge 决定。

   4

   当 Red Hat OpenShift Service on AWS 上检查是否应滚动索引。这是默认设置，不可更改。

   注意

   不支持修改 Elasticsearch CR。对保留策略的所有更改都必须在 ClusterLogging CR 中进行。

   OpenShift Elasticsearch Operator 部署 cron job，以使用定义的策略为每个映射滚动索引,并使用 pollInterval 调度。

   $ oc get cronjob

   输出示例

   NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   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:1
           resources:
             limits: 2
               memory: "32Gi"
             requests: 3
               cpu: "1"
               memory: "16Gi"
           proxy: 4
             resources:
               limits:
                 memory: 100Mi
               requests:
                 memory: 100Mi

   1

   根据需要指定 Elasticsearch 的 CPU 和内存请求。如果这些值留白，则 OpenShift Elasticsearch Operator 会设置默认值，它们应足以满足大多数部署的需要。内存请求的默认值为 16Gi，CPU 请求为 1。

   2

   pod 可以使用的最大资源量。

   3

   调度 pod 所需的最小资源。

   4

   根据需要指定 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 -l component=elasticsearch

3. 缩减收集器 pod，以便它们停止向 Elasticsearch 发送新日志：

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

4. 使用 Red Hat OpenShift Service on AWS 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. 使用 Red Hat OpenShift Service on AWS 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. 默认情况下，AWS Elasticsearch 集群上的 Red Hat OpenShift Service 会阻止部署到其节点上。使用以下命令来允许推出部署并允许 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 -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

   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. 扩展收集器 Pod，以便它们会将新日志发送到 Elasticsearch。

   $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "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

2. 如果存在，请从 ClusterLogging CR 中删除 logStore 和 visualization 小节。

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

   $ oc get pods -l component=collector -n openshift-logging