关于 OpenShift 日志记录


Red Hat OpenShift Logging 6.2

OpenShift 日志记录简介.

Red Hat OpenShift Documentation Team

摘要

本文档概述 OpenShift Logging 功能,还包括发行注记和支持信息。

第 1 章 Red Hat OpenShift Logging 概述

ClusterLogForwarder 自定义资源(CR)是日志收集和转发的核心配置点。

1.1. 输入和输出

输入指定要转发的日志源。日志记录提供以下内置输入类型,它们从集群的不同部分选择日志:

  • application
  • receiver
  • infrastructure
  • audit

您还可以根据命名空间或 pod 标签定义自定义输入,以微调日志选择。

输出定义发送日志的目的地。每个输出类型都有自己的一组配置选项,允许您自定义行为和身份验证设置。

1.2. 接收器输入类型

接收器输入类型可让日志记录系统接受来自外部源的日志。它支持两种接收日志的格式:httpsyslog

ReceiverSpec 字段定义接收器输入的配置。

1.3. 管道和过滤器

Pipelines 决定从输入到输出的日志流。管道由一个或多个输入 refs、输出 refs 和可选过滤器 refs 组成。您可以使用过滤器来转换或丢弃管道中的日志消息。过滤器顺序很重要,随着顺序应用,较早的过滤器可能会阻止日志消息到达后续阶段。

1.4. Operator 行为

Cluster Logging Operator 根据 ClusterLogForwarder 资源的 managementState 字段管理收集器的部署和配置:

  • 当设置为 Managed (默认)时,Operator 会主动管理日志记录资源以匹配 spec 中定义的配置。
  • 当设置为 Unmanaged 时,Operator 不执行任何操作,供您手动管理日志记录组件。

1.5. 验证

日志记录包括广泛的验证规则和默认值,以确保平稳配置体验。ClusterLogForwarder 资源对必填字段、字段之间的依赖关系和输入值格式强制验证检查。为某些字段提供默认值,从而减少了常见场景中明确配置的需求。

第 2 章 集群日志记录支持

logging 只支持本文档中介绍的配置选项。

不要使用任何其他配置选项,因为它们不被支持。各个 OpenShift Container Platform 发行版本的配置范例可能会有所变化,只有掌握了所有可能的配置,才能稳妥应对这样的配置变化。如果您使用本文档中描述的配置以外的配置,您的更改会被覆盖,因为 Operator 旨在协调差异。

注意

如果必须执行 OpenShift Container Platform 文档中未描述的配置,您需要将 Red Hat OpenShift Logging Operator 设置为 Unmanaged。不支持非受管日志记录实例,且不会接收更新,直到您将其状态返回为 Managed 为止。

注意

日志记录作为一个可安装的组件提供,它有一个不同于 OpenShift Container Platform 的发布周期。Red Hat OpenShift Container Platform 生命周期政策 概述了发行版本兼容性。

Loki 是一个可横向扩展的、高度可用、多租户日志聚合系统,作为 Red Hat OpenShift 的日志记录的 GA 日志存储,可以使用 OpenShift Observability UI 视觉化。OpenShift Logging 提供的 Loki 配置是一个短期日志存储,旨在让用户使用收集的日志执行快速故障排除。为此,Loki 的 Red Hat OpenShift 配置的日志记录具有短期存储,并针对非常最新的查询进行了优化。对于长期存储或长时间查询,用户应查找其集群外部的日志存储。

Elasticsearch 在 ingestion 过程中完全索引传入的日志记录。Loki 在 ingestion 期间只索引几个固定标签,并延迟更复杂的解析,直到日志存储后为止。这意味着 Loki 可以更快地收集日志。

Red Hat OpenShift 的 logging 是一个建议的收集器,以及应用程序、基础架构和审计日志的规范化程序。它旨在将日志转发到各种支持的系统。

Logging 不是:

  • 一个大规模日志收集系统
  • 兼容安全信息和事件监控 (SIEM)
  • "自带" (BYO)日志收集器配置
  • 历史或长日志的保留或存储
  • 保证的日志接收器
  • 安全存储 - 默认不存储审计日志

2.1. 支持的 API 自定义资源定义

下表描述了支持的日志记录 API。

Expand
表 2.1. 日志记录 API 支持状态
CustomResourceDefinition (CRD)ApiVersion支持状态

LokiStack

lokistack.loki.grafana.com/v1

从 5.5 开始支持

RulerConfig

rulerconfig.loki.grafana/v1

从 5.7 开始支持

AlertingRule

alertingrule.loki.grafana/v1

从 5.7 开始支持

RecordingRule

recordingrule.loki.grafana/v1

从 5.7 开始支持

LogFileMetricExporter

LogFileMetricExporter.logging.openshift.io/v1alpha1

从 5.8 开始支持

ClusterLogForwarder

clusterlogforwarder.observability.openshift.io/v1

从 6.0 开始支持

2.2. 不支持的配置

您必须将 Red Hat OpenShift Logging Operator 设置为 Unmanaged 状态才能修改以下组件:

  • 收集器配置文件
  • collector daemonset

明确不支持的情形包括:

  • 使用环境变量配置日志记录收集器。您不能使用环境变量来修改日志收集器。
  • 配置日志收集器规范日志的方式。您无法修改默认日志规范化。

2.3. 非受管 Operator 的支持策略

Operator 的 管理状态 决定了一个 Operator 是否按设计积极管理集群中其相关组件的资源。如果 Operator 设置为 非受管(unmanaged) 状态,它不会响应配置更改,也不会收到更新。

虽然它可以在非生产环境集群或调试过程中使用,但处于非受管状态的 Operator 不被正式支持,集群管理员需要完全掌控各个组件的配置和升级。

可使用以下方法将 Operator 设置为非受管状态:

  • 独立 Operator 配置

    独立 Operator 的配置中具有 managementState 参数。这可以通过不同的方法来访问,具体取决于 Operator。例如,Red Hat OpenShift Logging Operator 通过修改它管理的自定义资源(CR)来达到此目的,而 Cluster Samples Operator 使用了集群范围配置资源。

    managementState 参数更改为 Unmanaged 意味着 Operator 不会主动管理它的资源,也不会执行与相关组件相关的操作。一些 Operator 可能不支持此管理状态,因为它可能会损坏集群,需要手动恢复。

    警告

    将独立 Operator 更改为非受管状态会导致不支持该特定组件和功能。报告的问题必须在 受管(Managed) 状态中可以重复出现才能继续获得支持。

  • Cluster Version Operator (CVO) 覆盖

    可将 spec.overrides 参数添加到 CVO 配置中,以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的 spec.overrides[].unmanaged 参数设置为 true 会阻止集群升级并在设置 CVO 覆盖后提醒管理员:

    Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
    Copy to Clipboard Toggle word wrap
    警告

    设置 CVO 覆盖会使整个集群处于不受支持状态。在删除所有覆盖后,必须可以重现报告的问题方可获得支持。

2.4. 为红帽支持收集日志记录数据

在提交问题单时,向红帽支持提供有关集群的调试信息会很有帮助。

您可以使用 must-gather 工具来收集有关 项目级别资源、集群级资源和每个日志记录组件的诊断信息。为了获得快速支持,请提供 OpenShift Container Platform 和日志记录的诊断信息。

2.4.1. 关于 must-gather 工具

oc adm must-gather CLI 命令会收集最有助于解决问题的集群信息。

对于日志记录,must-gather 会收集以下信息:

  • 项目级别资源,包括 Pod、配置映射、服务帐户、角色、角色绑定和事件
  • 集群级资源,包括集群级别的节点、角色和角色绑定
  • openshift-loggingopenshift-operators-redhat 命名空间中的 OpenShift Logging 资源,包括日志收集器的健康状况、日志存储和日志可视化工具

在运行 oc adm must-gather 时,集群上会创建一个新 pod。在该 pod 上收集数据,并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。

2.4.2. 收集日志记录数据

您可以使用 oc adm must-gather CLI 命令来收集有关日志记录的信息。

流程

使用 must-gather 来收集日志信息:

  1. 进入要存储 must-gather 信息的目录。
  2. 针对日志记录镜像运行 oc adm must-gather 命令:

    如果您使用 OKD :

    $ oc adm must-gather --image=quay.io/openshift/origin-cluster-logging-operator
    Copy to Clipboard Toggle word wrap

    否则:

    $ 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}')
    Copy to Clipboard Toggle word wrap

    must-gather 工具会创建一个以当前目录中 must-gather.local 开头的新目录。例如: must-gather.local.4157245944708210408

  3. 从刚刚创建的 must-gather 目录创建一个压缩文件。例如,在使用 Linux 操作系统的计算机上运行以下命令:

    $ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408
    Copy to Clipboard Toggle word wrap
  4. 红帽客户门户中为您的问题单附上压缩文件。

第 3 章 日志的视觉化

日志的视觉化是通过部署 Cluster Observability OperatorLogging UI 插件提供的,这需要 Operator 安装。

第 4 章 快速启动

OpenShift Logging 支持两种数据模型:

  • ViaQ (正式发布)
  • OpenTelemetry (技术预览)

您可以通过在 ClusterLogForwarder 中配置 lokiStack.dataModel 字段来根据要求选择其中任何一种数据模型。在将日志转发到 LokiStack 时,viaq 是默认的数据模型。

注意

在以后的 OpenShift Logging 版本中,默认的数据模型将从 ViaQ 改为 OpenTelemetry。

4.1. ViaQ 快速开始使用

要使用默认的 ViaQ 数据模型,请按照以下步骤执行:

先决条件

  • 您可以使用 cluster-admin 权限访问 OpenShift Container Platform 集群。
  • 已安装 OpenShift CLI(oc)。
  • 您可以访问受支持的对象存储。例如,AWS S3, Google Cloud Storage, Azure, Swift, Minio, 或 OpenShift Data Foundation。

流程

  1. 从 OperatorHub 安装 Red Hat OpenShift Logging OperatorLoki OperatorCluster Observability Operator (COO)
  2. openshift-logging 命名空间中创建 LokiStack 自定义资源(CR):

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      managementState: Managed
      size: 1x.extra-small
      storage:
        schemas:
        - effectiveDate: '2024-10-01'
          version: v13
        secret:
          name: logging-loki-s3
          type: s3
      storageClassName: gp3-csi
      tenants:
        mode: openshift-logging
    Copy to Clipboard Toggle word wrap
    注意

    确保事先创建 logging-loki-s3 secret。此 secret 的内容因使用的对象存储而异。如需更多信息,请参阅 Secret 和 TLS 配置。

  3. 为收集器创建服务帐户:

    $ oc create sa collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
  4. 允许收集器的服务帐户将数据写入 LokiStack CR:

    $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
    注意

    ClusterRole 资源是在 Cluster Logging Operator 安装过程中自动创建的,不需要手动创建。

  5. 要收集日志,请运行以下命令使用收集器的服务帐户:

    $ oc adm policy add-cluster-role-to-user collect-application-logs -z collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
    $ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
    $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
    注意

    示例将收集器绑定到所有三个角色(应用程序、基础架构和审计),但默认情况下,仅收集应用和基础架构日志。要收集审计日志,请更新 ClusterLogForwarder 配置使其包含它们。根据您的环境所需的特定日志类型,分配角色。

  6. 创建一个 UIPlugin CR,以启用 Observe 选项卡中的 Log 部分:

    apiVersion: observability.openshift.io/v1alpha1
    kind: UIPlugin
    metadata:
      name: logging
    spec:
      type: Logging
      logging:
        lokiStack:
          name: logging-loki
    Copy to Clipboard Toggle word wrap
  7. 创建一个 ClusterLogForwarder CR 来配置日志转发:

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: collector
      namespace: openshift-logging
    spec:
      serviceAccount:
        name: collector
      outputs:
      - name: default-lokistack
        type: lokiStack
        lokiStack:
          authentication:
            token:
              from: serviceAccount
          target:
            name: logging-loki
            namespace: openshift-logging
        tls:
          ca:
            key: service-ca.crt
            configMapName: openshift-service-ca.crt
      pipelines:
      - name: default-logstore
        inputRefs:
        - application
        - infrastructure
        outputRefs:
        - default-lokistack
    Copy to Clipboard Toggle word wrap
    注意

    dataModel 字段是可选的,默认保留未设置(dataModel: "")。这允许 Cluster Logging Operator (CLO) 自动选择数据模型。目前,当字段未设置时,CLO 会默认使用 ViaQ 模型,但这将在以后的版本中有所变化。指定 dataModel: ViaQ 可确保在默认设置有变化时配置仍然可以保持兼容。

验证

  • 验证日志是否在 OpenShift Container Platform web 控制台的 Observe 选项卡的 Log 部分可见。

4.2. 使用 OpenTelemetry 快速开始

重要

OpenTelemetry 协议(OTLP)输出日志转发器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

要配置 OTLP ingestion 并启用 OpenTelemetry 数据模型,请按照以下步骤执行:

先决条件

  • 集群管理员权限

流程

  1. 从 OperatorHub 安装 Red Hat OpenShift Logging Operator、Loki Operator 和 Cluster Observability Operator (COO)。
  2. openshift-logging 命名空间中创建 LokiStack 自定义资源(CR):

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      managementState: Managed
      size: 1x.extra-small
      storage:
        schemas:
        - effectiveDate: '2024-10-01'
          version: v13
        secret:
          name: logging-loki-s3
          type: s3
      storageClassName: gp3-csi
      tenants:
        mode: openshift-logging
    Copy to Clipboard Toggle word wrap
    注意

    确保事先创建 logging-loki-s3 secret。此 secret 的内容因使用的对象存储而异。如需更多信息,请参阅"Secrets 和 TLS 配置"。

  3. 为收集器创建服务帐户:

    $ oc create sa collector -n openshift-logging
    Copy to Clipboard Toggle word wrap
  4. 允许收集器的服务帐户将数据写入 LokiStack CR:

    $ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
    Copy to Clipboard Toggle word wrap
    注意

    ClusterRole 资源是在 Cluster Logging Operator 安装过程中自动创建的,不需要手动创建。

  5. 允许收集器的服务帐户收集日志:

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap
    $ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
    Copy to Clipboard Toggle word wrap
    $ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
    Copy to Clipboard Toggle word wrap
    $ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
    Copy to Clipboard Toggle word wrap
    注意

    示例将收集器绑定到所有三个角色(应用程序、基础架构和审计)。默认情况下,只收集应用程序和基础架构日志。要收集审计日志,请更新 ClusterLogForwarder 配置使其包含它们。根据您的环境所需的特定日志类型,分配角色。

  6. 创建一个 UIPlugin CR,以启用 Observe 选项卡中的 Log 部分:

    apiVersion: observability.openshift.io/v1alpha1
    kind: UIPlugin
    metadata:
      name: logging
    spec:
      type: Logging
      logging:
        lokiStack:
          name: logging-loki
    Copy to Clipboard Toggle word wrap
  7. 创建一个 ClusterLogForwarder CR 来配置日志转发:

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: collector
      namespace: openshift-logging
      annotations:
        observability.openshift.io/tech-preview-otlp-output: "enabled" 
    1
    
    spec:
      serviceAccount:
        name: collector
      outputs:
      - name: loki-otlp
        type: lokiStack 
    2
    
        lokiStack:
          target:
            name: logging-loki
            namespace: openshift-logging
          dataModel: Otel 
    3
    
          authentication:
            token:
              from: serviceAccount
        tls:
          ca:
            key: service-ca.crt
            configMapName: openshift-service-ca.crt
      pipelines:
      - name: my-pipeline
        inputRefs:
        - application
        - infrastructure
        outputRefs:
        - loki-otlp
    Copy to Clipboard Toggle word wrap
    1
    使用注解启用 Otel 数据模型,它是一个技术预览功能。
    2
    将输出类型定义为 lokiStack
    3
    指定 OpenTelemetry 数据模型。
    注意

    dataModelOtel 时,您无法使用 lokiStack.labelKeys。要在 dataModelOtel 时实现类似的功能,请参阅"为 OTLP 数据生成"配置 LokiStack。

验证

  • 进入 OpenShift web 控制台中的 ObserveOpenShift LoggingLokiStackWrites 来验证 OTLP 是否正常工作,并检查 Distributor - Structured Metadata

法律通告

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat