使用 OpenShift Logging 与 OpenShift Serverless - 集群日志 | 可观测性 | Red Hat OpenShift Serverless 1.34

关于为 Red Hat OpenShift 部署日志子系统
关于为 Red Hat OpenShift 部署和配置日志子系统
- 配置和调整日志子系统
- 修改后的 ClusterLogging 自定义资源示例

关于为 Red Hat OpenShift 部署日志子系统

OpenShift Container Platform 集群管理员可以使用 OpenShift Container Platform Web 控制台或 CLI 部署日志子系统，以安装 OpenShift Elasticsearch Operator 和 Red Hat OpenShift Logging Operator。安装运算符后，您可以创建一个 ClusterLogging 自定义资源 (CR) 来调度日志子系统 Pod 和支持日志子系统所需的其他资源。运算符负责部署、升级和维护日志子系统。

ClusterLogging CR 定义了一个完整的日志子系统环境，其中包括日志堆栈的所有组件，用于收集、存储和可视化日志。Red Hat OpenShift Logging Operator 监视日志子系统 CR 并相应地调整日志部署。

管理员和应用程序开发人员可以查看他们有查看权限的项目的日志。

关于为 Red Hat OpenShift 部署和配置日志子系统

日志子系统设计为与默认配置一起使用，该配置针对小型到中型 OpenShift Container Platform 集群进行了调整。

以下安装说明包括一个 ClusterLogging 自定义资源 (CR) 示例，您可以使用它来创建日志子系统实例并配置您的日志子系统环境。

如果您想使用默认日志子系统安装，可以直接使用示例 CR。

如果您想自定义部署，请根据需要更改示例 CR。以下描述了在安装 OpenShift Logging 实例时或安装后可以进行的配置。有关使用每个组件（包括可以在 ClusterLogging 自定义资源之外进行的修改）的更多信息，请参阅“配置”部分。

配置和调整日志子系统

您可以通过修改部署在 openshift-logging 项目中的 ClusterLogging 自定义资源来配置日志子系统。

您可以在安装时或安装后修改以下任何组件

内存和 CPU: 您可以通过使用有效的内存和 CPU 值修改 resources 块来调整每个组件的 CPU 和内存限制。

spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
      type: kibana

Elasticsearch 存储: 您可以使用 storageClass name 和 size 参数为 Elasticsearch 集群配置持久性存储类和大小。Red Hat OpenShift Logging Operator 根据这些参数为 Elasticsearch 集群中的每个数据节点创建一个持久性卷声明 (PVC)。

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

此示例指定集群中的每个数据节点都将绑定到请求“200G”的“gp2”存储的 PVC。每个主分片都将由单个副本支持。

省略 storage 块会导致仅包含临时存储的部署。

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

Elasticsearch 复制策略

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

FullRedundancy。每个索引的分片都完全复制到每个数据节点。
MultipleRedundancy。每个索引的分片分布在半数数据节点上。
SingleRedundancy。每个分片的单个副本。只要至少存在两个数据节点，日志始终可用且可恢复。
ZeroRedundancy（零冗余）。任何分片均无副本。如果节点宕机或故障，日志可能不可用（或丢失）。

修改后的 ClusterLogging 自定义资源示例

以下是使用前面描述的选项修改后的ClusterLogging自定义资源示例。

修改后的ClusterLogging自定义资源示例

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          cpu: 200m
          memory: 16Gi
        requests:
          cpu: 200m
          memory: 16Gi
        storage:
          storageClassName: "gp2"
          size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi