配置 Elasticsearch 日志存储 - 日志记录 | 可观察性 | Red Hat OpenShift Service on AWS

编辑

配置日志存储
将审计日志转发到日志存储
配置日志保留时间
为日志存储配置 CPU 和内存请求
为日志存储配置复制策略
缩减 Elasticsearch Pod
为日志存储配置持久性存储
为日志存储配置 emptyDir 存储
执行 Elasticsearch 滚动集群重启
将日志存储服务公开为路由
如果您不使用默认的 Elasticsearch 日志存储，请移除未使用的组件

您可以使用 Elasticsearch 6 来存储和组织日志数据。

您可以修改日志存储，包括

Elasticsearch 集群的存储
集群中数据节点间的分片复制，从完全复制到不复制
对 Elasticsearch 数据的外部访问

编辑

配置日志存储

您可以通过修改ClusterLogging自定义资源 (CR) 来配置日志使用的日志存储类型。

先决条件

您拥有管理员权限。
您已安装 OpenShift CLI (oc)。
您已安装 Red Hat OpenShift Logging Operator 和一个内部日志存储，该存储为 LokiStack 或 Elasticsearch。
您已创建ClusterLogging CR。

Logging 5.9 版本不包含 OpenShift Elasticsearch Operator 的更新版本。如果您目前使用的是 Logging 5.8 发布的 OpenShift Elasticsearch Operator，它将继续与 Logging 一起使用，直到 Logging 5.8 结束生命周期。作为使用 OpenShift Elasticsearch Operator 管理默认日志存储的替代方案，您可以使用 Loki Operator。有关 Logging 生命周期日期的更多信息，请参阅与平台无关的 Operators。

步骤

修改ClusterLogging CR 的logStore规范

ClusterLogging CR 示例

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  logStore:
    type: <log_store_type> (1)
    elasticsearch: (2)
      nodeCount: <integer>
      resources: {}
      storage: {}
      redundancyPolicy: <redundancy_type> (3)
    lokistack: (4)
      name: {}
# ...

1	指定日志存储类型。这可以是`lokistack`或`elasticsearch`。
2	Elasticsearch 日志存储的可选配置选项。
3	指定冗余类型。此值可以是`ZeroRedundancy`、`SingleRedundancy`、`MultipleRedundancy`或`FullRedundancy`。
4	LokiStack 的可选配置选项。

指定 LokiStack 作为日志存储的ClusterLogging CR 示例

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-loki
# ...

通过运行以下命令应用ClusterLogging CR
```
$ oc apply -f <filename>.yaml
```

编辑

将审计日志转发到日志存储

在日志部署中，容器和基础设施日志默认情况下会转发到ClusterLogging自定义资源 (CR) 中定义的内部日志存储。

审计日志默认情况下不会转发到内部日志存储，因为这无法提供安全的存储。您有责任确保将审计日志转发到的系统符合您的组织和政府法规，并得到妥善保护。

如果此默认配置满足您的需求，则无需配置ClusterLogForwarder CR。如果存在ClusterLogForwarder CR，除非定义包含default输出的管道，否则日志不会转发到内部日志存储。

步骤

要使用日志转发 API 将审计日志转发到内部 Elasticsearch 实例

创建或编辑一个定义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 管道使用指定的输出定义要转发的日志类型。默认输出将日志转发到内部 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 实例。

其他资源

关于日志收集和转发

编辑

配置日志保留时间

您可以配置一个保留策略，该策略指定默认 Elasticsearch 日志存储为三个日志源中的每一个保留索引的时间长短：基础设施日志、应用程序日志和审计日志。

要配置保留策略，您需要在ClusterLogging自定义资源 (CR) 中为每个日志源设置maxAge参数。CR 将这些值应用于 Elasticsearch 滚动计划，该计划决定 Elasticsearch 何时删除已滚动的索引。

当索引匹配以下任何条件时，Elasticsearch 会滚动索引，移动当前索引并创建新的索引

索引的年龄超过Elasticsearch CR 中的rollover.maxAge值。
索引大小大于 40 GB × 主分片数。
索引文档计数大于 40960 KB × 主分片数。

Elasticsearch 根据您配置的保留策略删除已滚动的索引。如果您没有为任何日志源创建保留策略，则日志默认会在七天后被删除。

先决条件

必须安装 Red Hat OpenShift Logging Operator 和 OpenShift Elasticsearch Operator。

步骤

要配置日志保留时间

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

您可以在Elasticsearch自定义资源 (CR) 中验证设置。

例如，Red Hat OpenShift Logging Operator 更新了以下Elasticsearch CR 以配置保留策略，该策略包括设置，用于每八小时滚动一次基础设施日志的活动索引，并且在滚动后七天删除已滚动的索引。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 作业，根据定义的策略和 `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

编辑

配置日志存储的 CPU 和内存请求

每个组件规范允许调整 CPU 和内存请求。您通常无需手动调整这些值，因为 OpenShift Elasticsearch Operator 会设置足以满足您环境需求的值。

在大规模集群中，Elasticsearch 代理容器的默认内存限制可能不足，导致代理容器被 OOMKilled。如果您遇到此问题，请增加 Elasticsearch 代理的内存请求和限制。

每个 Elasticsearch 节点可以使用较低的内存设置运行，但这**不**推荐用于生产部署。对于生产环境，每个 Pod 至少应分配默认的 16Gi 内存。最好尽可能多地分配内存，每个 Pod 最多可分配 64Gi。

先决条件

必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。

步骤

编辑 `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`。

调整 Elasticsearch 内存量时，应为 `requests` 和 `limits` 使用相同的值。

例如

      resources:
        limits: (1)
          memory: "32Gi"
        requests: (2)
          cpu: "8"
          memory: "32Gi"

1	资源的最大数量。
2	所需的最小数量。

Kubernetes 通常遵循节点配置，不允许 Elasticsearch 使用指定的限制。为 `requests` 和 `limits` 设置相同的值可确保 Elasticsearch 可以使用所需的内存，前提是节点有足够的可用内存。

编辑

配置日志存储的复制策略

您可以定义 Elasticsearch 分片在集群中的数据节点之间如何复制。

先决条件

必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。

步骤

编辑 `openshift-logging` 项目中的 `ClusterLogging` 自定义资源 (CR)

$ oc -n openshift-logging edit ClusterLogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"

....

spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      redundancyPolicy: "SingleRedundancy" (1)

指定分片的冗余策略。保存更改后将应用更改。

**FullRedundancy**。Elasticsearch 将每个索引的主分片完全复制到每个数据节点。这提供了最高的安全性，但代价是所需的磁盘空间最多，性能最差。
**MultipleRedundancy**。Elasticsearch 将每个索引的主分片完全复制到一半的数据节点。这在安全性和性能之间提供了良好的平衡。
**SingleRedundancy**。Elasticsearch 为每个索引创建主分片的一个副本。只要至少存在两个数据节点，日志始终可用并可恢复。在使用 5 个或更多节点时，性能优于 MultipleRedundancy。您不能将此策略应用于单个 Elasticsearch 节点的部署。
**ZeroRedundancy**。Elasticsearch 不创建主分片的副本。如果节点出现故障或失败，日志可能不可用或丢失。如果您更关注性能而不是安全性，或者已经实现了您自己的磁盘/PVC 备份/恢复策略，请使用此模式。

索引模板的主分片数等于 Elasticsearch 数据节点数。

编辑

缩减 Elasticsearch Pod 的规模

减少集群中 Elasticsearch Pod 的数量可能会导致数据丢失或 Elasticsearch 性能下降。

如果您要缩减规模，则应一次缩减一个 Pod，并允许集群重新平衡分片和副本。Elasticsearch 健康状态恢复到 `green` 后，您可以再缩减一个 Pod。

如果您的 Elasticsearch 集群设置为 `ZeroRedundancy`，则不应缩减 Elasticsearch Pod 的规模。

编辑

配置日志存储的持久化存储

Elasticsearch 需要持久化存储。存储速度越快，Elasticsearch 性能越高。

不支持使用 NFS 存储作为卷或持久卷（或通过 NAS，如 Gluster）作为 Elasticsearch 存储，因为 Lucene 依赖于 NFS 未提供的文件系统行为。可能会发生数据损坏和其他问题。

先决条件

必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。

步骤

编辑 `ClusterLogging` CR 以指定集群中的每个数据节点都绑定到持久卷声明。

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

此示例指定集群中的每个数据节点都绑定到一个持久卷声明，该声明请求“200G”的 AWS 通用用途 SSD (gp2) 存储。

如果您使用本地卷作为持久化存储，请不要使用原始块卷，原始块卷在 `LocalVolume` 对象中使用 `volumeMode: block` 描述。Elasticsearch 无法使用原始块卷。

编辑

为 emptyDir 存储配置日志存储

您可以将 emptyDir 与日志存储一起使用，这将创建一个临时部署，其中 Pod 的所有数据在重新启动时都会丢失。

使用 emptyDir 时，如果日志存储重新启动或重新部署，您将丢失数据。

先决条件

必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。

步骤

编辑 `ClusterLogging` CR 以指定 emptyDir

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

编辑

执行 Elasticsearch 滚动集群重启

更改 `elasticsearch` config map 或任何 `elasticsearch-*` 部署配置时，请执行滚动重启。

此外，如果运行 Elasticsearch Pod 的节点需要重新引导，也建议进行滚动重启。

先决条件

必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。

步骤

执行滚动集群重启

切换到 `openshift-logging` 项目
```
$ oc project openshift-logging
```

获取 Elasticsearch Pod 的名称

$ oc get pods -l component=elasticsearch

缩减收集器 Pod 的规模，以便它们停止向 Elasticsearch 发送新日志

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

使用 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}}

使用 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":

命令完成后，对于您为 ES 集群拥有的每个部署

默认情况下，Red Hat OpenShift Service on AWS Elasticsearch 集群会阻止对其节点的 rollout。使用以下命令允许 rollout 并允许 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

部署完成后，重置 Pod 以禁止 rollout

$ oc rollout pause deployment/<deployment-name>

例如

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

示例输出

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

检查 Elasticsearch 集群是否处于 `green` 或 `yellow` 状态

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

如果您对在上一个命令中使用的 Elasticsearch Pod 执行了 rollout，则该 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`。

如果您更改了 Elasticsearch 配置映射，请对每个 Elasticsearch Pod 重复这些步骤。

集群所有部署完成后，重新启用分片平衡。

$ 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"
        }
      }
    }
  }
}

扩展收集器 Pod，以便它们将新的日志发送到 Elasticsearch。

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

编辑

将日志存储服务公开为路由

默认情况下，与日志记录一起部署的日志存储无法从日志记录集群外部访问。您可以启用具有重新加密终止的路由，以便那些访问其数据的工具可以访问日志存储服务。

您可以通过创建重新加密路由、您的 Red Hat OpenShift Service on AWS 令牌和已安装的日志存储 CA 证书来从外部访问日志存储。然后，使用包含以下内容的 cURL 请求访问托管日志存储服务的节点：

Authorization: Bearer ${token}
Elasticsearch 重新加密路由和一个Elasticsearch API 请求。

您可以在内部使用日志存储集群 IP 访问日志存储服务，您可以使用以下任一命令获取该 IP：

$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging

示例输出

172.30.183.229

$ oc get service elasticsearch -n openshift-logging

示例输出

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
elasticsearch   ClusterIP   172.30.183.229   <none>        9200/TCP   22h

您可以使用类似于以下命令的命令检查集群 IP 地址：

$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"

示例输出

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    29  100    29    0     0    108      0 --:--:-- --:--:-- --:--:--   108

先决条件

必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。
您必须有权访问该项目才能访问日志。

步骤

要将日志存储公开到外部：

切换到 `openshift-logging` 项目
```
$ oc project openshift-logging
```
从日志存储中提取 CA 证书并写入**_admin-ca_**文件。
```
$ oc extract secret/elasticsearch --to=. --keys=admin-ca
```
示例输出
```
admin-ca
```

将日志存储服务的路由创建为 YAML 文件。

创建一个包含以下内容的 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`参数。

运行以下命令将日志存储 CA 证书添加到您在上一步中创建的路由 YAML 文件中：
```
$ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml
```

创建路由。

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

示例输出

route.route.openshift.io/elasticsearch created

检查 Elasticsearch 服务是否已公开。

获取此服务帐户的令牌，以便在请求中使用。
```
$ token=$(oc whoami -t)
```

将您创建的**elasticsearch**路由设置为环境变量。

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

要验证路由是否已成功创建，请运行以下命令，该命令通过公开的路由访问 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>"
}

编辑

如果您不使用默认的 Elasticsearch 日志存储，则删除未使用的组件

作为管理员，如果您将日志转发到第三方日志存储并且不使用默认的 Elasticsearch 日志存储，则在极少数情况下，您可以从日志记录集群中删除几个未使用的组件。

换句话说，如果您不使用默认的 Elasticsearch 日志存储，则可以从ClusterLogging自定义资源 (CR) 中删除内部 Elasticsearch logStore 和 Kibana visualization组件。删除这些组件是可选的，但可以节省资源。

先决条件

验证您的日志转发器是否未将日志数据发送到默认的内部 Elasticsearch 集群。检查用于配置日志转发的ClusterLogForwarder CR YAML 文件。验证它没有指定default的outputRefs元素。例如：
```
outputRefs:
- default
```

假设ClusterLogForwarder CR 将日志数据转发到内部 Elasticsearch 集群，并且您从ClusterLogging CR 中删除了logStore组件。在这种情况下，内部 Elasticsearch 集群将不存在以存储日志数据。这种缺失会导致数据丢失。

步骤

编辑 `openshift-logging` 项目中的 `ClusterLogging` 自定义资源 (CR)
```
$ oc edit ClusterLogging instance
```
如果存在，请从ClusterLogging CR 中删除logStore和visualization部分。

保留ClusterLogging CR 的collection部分。结果应类似于以下示例：

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

验证收集器 Pod 是否已重新部署。

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