Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

9.3. 使用 OpenShift Serverless 的集群日志记录

9.3.1. 集群日志记录
复制链接

OpenShift Container Platform 集群管理员可以使用一些 CLI 命令和 OpenShift Container Platform Web 控制台安装 Elasticsearch Operator 和 Cluster Logging Operator，以此部署集群日志记录。安装 Operator 后，创建一个 ClusterLogging 自定义资源（CR）来调度集群日志记录 Pod 以及支持集群日志记录所需的其他资源。Operator 负责部署、升级和维护集群日志记录。

您可以通过修改名为 instance 的 ClusterLogging 自定义资源（CR）来配置集群日志记录。CR 定义包括日志记录堆栈的所有组件在内的完整集群日志记录部署，以收集、存储和视觉化日志。Cluster Logging Operator 监控 ClusterLogging 自定义资源并相应地调整日志记录部署。

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

9.3.2. 关于部署和配置集群日志记录
复制链接

OpenShift Container Platform 集群日志记录已设计为可搭配默认配置使用，该配置针对中小型 OpenShift Container Platform 集群进行了调优。

以下安装说明包括一个示例 ClusterLogging 自定义资源（CR），您可以使用它来创建集群日志记录实例并配置集群日志记录部署。

如果要使用默认集群日志记录安装，可直接使用示例 CR。

如果要自定义部署，请根据需要对示例 CR 进行更改。下文介绍了在安装集群日志记录实例或安装后修改时可以进行的配置。请参阅“配置”部分来了解有关使用各个组件的更多信息，包括可以在 ClusterLogging 自定义资源之外进行的修改。

9.3.2.1. 配置和调优集群日志记录
复制链接

您可以通过修改 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
  curation:
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      type: "curator"
Copy to Clipboard Toggle word wrap
Elasticsearch 存储
您可以使用 storageClass name 和 size 参数，为 Elasticsearch 集群配置持久性存储类和大小。Cluster Logging Operator 基于这些参数为 Elasticsearch 集群中的每个数据节点创建 PersistentVolumeClaim。 
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"
Copy to Clipboard Toggle word wrap

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

注意

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

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Copy to Clipboard Toggle word wrap
Elasticsearch 复制策略

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

  • FullRedundancy。各个索引的分片完整复制到每个数据节点上。
  • MultipleRedundancy。各个索引的分片分布到一半数据节点上。
  • SingleRedundancy。各个分片具有单个副本。只要存在至少两个数据节点，日志就能始终可用且可恢复。
  • ZeroRedundancy。所有分片均无副本。如果节点关闭或发生故障， 则可能无法获得日志数据。
Curator 调度
以 cron 格式指定 Curator 的调度。 
  spec:
    curation:
    type: "curator"
    resources:
    curator:
      schedule: "30 3 * * *"
Copy to Clipboard Toggle word wrap

9.3.2.2. 修改后的 ClusterLogging 自定义资源示例
复制链接

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

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

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 32Gi
        requests:
          cpu: 3
          memory: 32Gi
      storage: {}
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/5 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi
Copy to Clipboard Toggle word wrap

流程

  1. 要访问 Kibana UI（Elasticsearch 的可视化工具），请使用以下命令获取 Kibana 路由： 

    $ oc -n openshift-logging get route kibana
    Copy to Clipboard Toggle word wrap
  2. 使用路由的 URL 导航到 Kibana 仪表板并登录。
  3. 确保将索引设置为 .all。如果索引未设置为 .all，则只会列出 OpenShift Container Platform 系统日志。

  4. 您可使用 knative-serving 命名空间来过滤日志。在搜索框中输入 kubernetes.namespace_name:knative-serving 以过滤结果。

    注意

    Knative Serving 默认使用结构化日志记录。您可以通过自定义集群日志记录 Fluentd 设置来启用这些日志的解析。这允许在日志级别过滤来快速发现问题。

使用 OpenShift Container Platform 集群日志记录时，应用程序写入控制台的日志将在 Elasticsearch 中收集。以下流程概述了如何使用 Knative Serving 将这些功能应用到所部署的应用程序中。

流程

  1. 查找 Kibana URL： 

    $ oc -n cluster-logging get route kibana
    Copy to Clipboard Toggle word wrap
  2. 在浏览器中输入 URL 以打开 Kibana UI。
  3. 确保将索引设置为 .all。如果索引未设置为 .all，则只会列出 OpenShift Container Platform 系统日志。

  4. 通过使用服务部署到的 Kubernetes 命名空间来过滤日志。添加过滤条件以识别服务本身：kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{SERVICE_NAME}。

    注意

    除此之外还可使用 /configuration 或 /revision 来过滤。

  5. 您可使用 kubernetes.container_name:<user-container> 来缩小搜索范围，只显示由您的应用程序生成的日志。否则，会显示来自 queue-proxy 的日志。

    注意

    在应用程序中使用基于 JSON 的结构化日志记录，以便在生产环境中快速过滤这些日志。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat