日志记录

OpenShift Container Platform 4.17

在 OpenShift Container Platform 中配置和使用日志

Red Hat OpenShift Documentation Team

法律通告

摘要

使用日志记录来收集、视觉化、转发和存储日志数据来排除问题，识别性能瓶颈，并检测 OpenShift Container Platform 中的安全威胁。

第 1 章 Logging 6.0

1.1. 发行注记

1.1.1. Logging 6.0.2

此发行版本包括 RHBA-2024:10051。

1.1.1.1. 程序错误修复

在此次更新之前，Loki 没有正确加载一些配置，这会导致使用 Alibaba Cloud 或 IBM Cloud 对象存储时出现问题。在这个版本中解决了 Loki 中的 configuration-loading 代码，从而解决了这个问题。(LOG-5325)
在此次更新之前，收集器丢弃超过配置的阈值的审计日志消息。这会修改最大行大小以及读取周期读取的字节数的审计配置阈值。(LOG-5998)
在此次更新之前，Cluster Logging Operator 不会监视和协调与 ClusterLogForwarder 实例关联的资源，就像在以前的版本中一样。在这个版本中，修改 Operator 以监视和协调它拥有的所有资源并创建的资源。(LOG-6264)
在此次更新之前，发送到 Google Cloud Logging 的未知严重性级别的日志事件会在向量收集器中触发警告，然后将严重性默认设置为 'DEFAULT'。在这个版本中，日志严重性级别已被标准化，以匹配 Google Cloud Logging 规格，审计日志被分配为"INFO"的严重性。(LOG-6296)
在此次更新之前，当应用程序输入中包含基础架构命名空间时，log_type 被设置为 application。在这个版本中，应用程序输入中包含的基础架构命名空间的 log_type 被设置为 infrastructure。(LOG-6354)
在此次更新之前，为 ClusterLogForwarder 的 syslog.enrichment 字段指定值，将 namespace_name、container_name 和 pod_name 添加到非容器日志的消息中。在这个版本中，在设置了 syslog.enrichment 时，只有容器日志将 namespace_name、container_name 和 pod_name 包含在其消息中。(LOG-6402)

1.1.1.2. CVE

1.1.2. Logging 6.0.1

此发行版本包括 OpenShift Logging 程序错误修复 6.0.1。

1.1.2.1. 程序错误修复

在这个版本中，收集器的默认内存限值已从 1024 Mi 增加到 2024 Mi。但是，用户应始终根据集群规格和需求调整其资源限值。(LOG-6180)
在此次更新之前，Loki Operator 无法将默认的 namespace 标签添加到所有 AlertingRule 资源中，这会导致 User-Workload-Monitoring Alertmanager 跳过这些警报的路由。在这个版本中，将规则命名空间作为标签添加到所有警报和记录规则中，从而解决了这个问题并在 Alertmanager 中恢复正确的警报路由。(LOG-6151)
在此次更新之前，LokiStack ruler 组件视图没有正确初始化，从而导致 ruler 组件被禁用时导致无效的字段错误。在这个版本中，组件视图会使用空值初始化，从而解决了这个问题。(LOG-6129)
在此次更新之前，可以在修剪（prune）过滤器中设置 log_source，这可能会导致日志数据不一致。在这个版本中，在应用配置前会验证配置，修剪过滤器中包含 log_source 的任何配置都会被拒绝。(LOG-6202)

1.1.2.2. CVE

1.1.3. Logging 6.0.0

此发行版本包括 Red Hat OpenShift 程序错误修复 6.0.0 的 Logging

注意

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

表 1.1. 上游组件版本
日志记录版本	组件版本
Operator	`eventrouter`	`logfilemetricexporter`	`loki`	`lokistack-gateway`	`opa-openshift`	`vector`
6.0	0.4	1.1	3.1.0	0.1	0.1	0.37.1

1.1.4. 删除通知

在这个版本中，日志记录不再支持 ClusterLogging.logging.openshift.io 和 ClusterLogForwarder.logging.openshift.io 自定义资源。有关替换功能的详情，请参阅产品文档。(LOG-5803)
在这个版本中，日志记录不再管理或部署日志存储（如 Elasticsearch）、视觉化（如 Kibana）或基于 Fluentd 的日志收集器。(LOG-5368)

注意

为了继续使用由 elasticsearch-operator 管理的 Elasticsearch 和 Kibana，管理员必须在删除 ClusterLogging 资源前修改这些对象的 ownerRefs。

1.1.5. 新功能及功能增强

此功能通过将组件职责移到其相关 Operator （如存储、视觉化和集合）来为 Red Hat OpenShift 引入了一个新的架构。它引入了用于日志收集和转发的 ClusterLogForwarder.observability.openshift.io API。删除了对 ClusterLogging.logging.openshift.io 和 ClusterLogForwarder.logging.openshift.io API 以及 Red Hat managed Elastic stack (Elasticsearch 和 Kibana)的支持。建议用户迁移到 Red Hat LokiStack 用于日志存储。现有的受管 Elasticsearch 部署可用于有限时间。不提供日志集合的自动化迁移，因此管理员需要创建新的 ClusterLogForwarder.observability.openshift.io 规格来替换其以前的自定义资源。如需更多详细信息，请参阅官方产品文档。(LOG-3493)
在这个版本中，部署日志记录视图插件的责任从 Red Hat OpenShift Logging Operator 转换到 Cluster Observability Operator (COO)。对于需要视觉化的新日志存储安装，必须部署 Cluster Observability Operator 和关联的 UIPlugin 资源。如需了解更多详细信息，请参阅 Cluster Observability Operator 概述产品文档。(LOG-5461)
此功能增强根据 Vector 文档为 Vector 收集器部署内存和 CPU 使用量设置默认请求和限值。(LOG-4745)
此功能增强更新了 Vector，使其与上游版本 v0.37.1 保持一致。(LOG-5296)
此功能增强引入了一个警报，当日志收集器缓冲日志到节点的文件系统时触发，并使用 15% 的可用空间，代表潜在的后端压力问题。(LOG-5381)
此功能增强更新了所有组件的选择器，以使用常见的 Kubernetes 标签。(LOG-5906)
此增强更改了收集器配置，以部署为 ConfigMap 而不是 secret，允许用户在 ClusterLogForwarder 设置为 Unmanaged 时查看和编辑配置。(LOG-5599)
此功能增强添加了使用 ClusterLogForwarder 上的注解配置 Vector 收集器日志级别的功能，包含 trace、debug、info、warn、error 或 off 选项。(LOG-5372)
此功能增强添加了验证，以拒绝 Amazon CloudWatch 输出使用多个 AWS 角色的配置，从而防止日志路由不正确。(LOG-5640)
此功能增强从指标仪表板中删除了 Log Bytes Collected 和 Log Bytes Sent 图形。(LOG-5964)
此增强更新了 must-gather 功能，以只捕获用于检查 Logging 6.0 组件的信息，包括 ClusterLogForwarder.observability.openshift.io 资源及红帽管理的 LokiStack 中的 Vector 部署。(LOG-5949)
此功能增强通过为特定错误条件提供早期警告来提高 Azure 存储 secret 验证。(LOG-4571)

1.1.6. 技术预览功能

此发行版本引入了使用 OpenTelemetry 的日志转发的技术预览功能。新的输出类型' OTLP' 允许使用 OpenTelemetry 数据模型和资源语义约定发送 JSON 编码的日志记录。(LOG-4225)

1.1.7. 程序错误修复

在此次更新之前，CollectorHighErrorRate 和 CollectorVeryHighErrorRate 警报仍然存在。在这个版本中，两个警报都会在 logging 6.0 发行版本中删除，但可能会在以后的版本中被重新加入。(LOG-3432)

1.1.8. CVE

CVE-2024-34397

1.2. Logging 6.0

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

1.2.1. 输入和输出

输入指定要转发的日志源。日志记录提供内置输入类型： application、infrastructure 和 audit，它们从集群的不同部分选择日志。您还可以根据命名空间或 pod 标签定义自定义输入，以微调日志选择。

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

1.2.2. 接收器输入类型

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

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

1.2.3. 管道和过滤器

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

1.2.4. Operator 行为

Cluster Logging Operator 根据 managementState 字段管理收集器的部署和配置：

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

1.2.5. 验证

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

1.2.5.1. 快速入门

先决条件

集群管理员权限

流程

从 OperatorHub 安装 OpenShift Logging 和 Loki Operator。

在 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: '2022-06-01'
      version: v13
    secret:
      name: logging-loki-s3
      type: s3
    storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

为收集器创建服务帐户：

$ oc create sa collector -n openshift-logging

为收集器创建 ClusterRole ：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: logging-collector-logs-writer
rules:
- apiGroups:
  - loki.grafana.com
  resourceNames:
  - logs
  resources:
  - application
  - audit
  - infrastructure
  verbs:
  - create

将 ClusterRole 绑定到服务帐户：

$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector

安装 Cluster Observability Operator。

创建一个 UIPlugin 以启用 Observe 选项卡中的 Log 部分：

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki

在 collector 服务帐户中添加额外的角色：

$ oc project openshift-logging
$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector

创建一个 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:
      target:
        name: logging-loki
        namespace: openshift-logging
    authentication:
      token:
        from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - name: default-logstore
    inputRefs:
    - application
    - infrastructure
    outputRefs:
    - default-lokistack

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

1.3. 升级到 Logging 6.0

日志记录 v6.0 是之前版本的一个显著升级，实现了集群日志记录的几个长目标：

引入不同的 operator 来管理日志记录组件（如收集器、存储、视觉化）。
根据 Elastic 产品（如 Elasticsearch、Kibana）删除对受管日志存储和视觉化的支持。
弃用 Fluentd 日志收集器实现。
删除对 ClusterLogging.logging.openshift.io 和 ClusterLogForwarder.logging.openshift.io 资源的支持。

注意

cluster-logging-operator 不提供自动升级过程。

根据日志集合、转发和存储的各种配置，cluster-logging-operator 不会提供自动升级。本文档可帮助管理员将现有 ClusterLogging.logging.openshift.io 和 ClusterLogForwarder.logging.openshift.io 规格转换为新的 API。包括针对常见用例迁移的 ClusterLogForwarder.observability.openshift.io 资源示例。

1.3.1. 使用 `oc explain` 命令

oc explain 命令是 OpenShift CLI oc 中的基本工具，它提供了自定义资源(CR)中字段的详细描述。此命令对于在 OpenShift 集群中配置或故障排除资源的管理员和开发人员而言是不可能的。

1.3.1.1. 资源描述

oc explain 提供了对与特定对象关联的所有字段的深入说明。这包括标准资源，如 pod 和服务，以及更复杂的实体，如有状态集和 Operator 定义的自定义资源。

要查看 ClusterLogForwarder 自定义资源的 outputs 字段的文档，您可以使用：

$ oc explain clusterlogforwarders.observability.openshift.io.spec.outputs

注意

在 clusterlogforwarder 的位置，可以使用简短形式 obsclf。

这将显示有关这些字段的详细信息，包括类型、默认值和任何关联的子字段。

1.3.1.2. 层次结构

命令以分级格式显示资源字段的结构，从而阐明不同配置选项之间的关系。

例如，以下是如何更深入地进行 storage 配置用于 LokiStack 自定义资源：

$ oc explain lokistacks.loki.grafana.com
$ oc explain lokistacks.loki.grafana.com.spec
$ oc explain lokistacks.loki.grafana.com.spec.storage
$ oc explain lokistacks.loki.grafana.com.spec.storage.schemas

每个命令都显示了资源规格的深层次，使结构非常明确。

1.3.1.3. 类型信息

oc explain 也指示每个字段的类型（如字符串、整数或布尔值），允许您验证资源定义是否使用正确的数据类型。

例如：

$ oc explain lokistacks.loki.grafana.com.spec.size

这将显示 size 应使用整数值来定义。

1.3.1.4. 默认值

如果适用，命令会显示字段的默认值，以便在显式指定时了解哪些值将使用什么值。

再次使用 lokistacks.loki.grafana.com 作为示例：

$ oc explain lokistacks.spec.template.distributor.replicas

输出示例

GROUP:      loki.grafana.com
KIND:       LokiStack
VERSION:    v1

FIELD: replicas <integer>

DESCRIPTION:
    Replicas defines the number of replica pods of the component.

1.3.2. 日志存储

这个版本中唯一可用的受管日志存储解决方案是一个 Lokistack，由 loki-operator 管理。此解决方案以前作为受管 Elasticsearch 产品的首选替代方案提供，在部署过程中保持不变。

重要

要继续使用 elasticsearch-operator 提供的现有红帽受管 Elasticsearch 或 Kibana 部署，请从名为 elasticsearch 的 Elasticsearch 资源中删除所有者引用，并在 openshift-logging 命名空间中删除名为 kibana 的 Kibana 资源，然后删除同一命名空间中名为 instance 的 ClusterLogging 资源。

临时将 ClusterLogging 设置为 Unmanaged 状态

$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Unmanaged"}}' --type=merge

从 Elasticsearch 资源中删除 ClusterLogging ownerReferences
以下命令确保 ClusterLogging 不再拥有 Elasticsearch 资源。对 ClusterLogging 资源的 logStore 字段的更新将不会影响 Elasticsearch 资源。
```
$ oc -n openshift-logging patch elasticsearch/elasticsearch -p '{"metadata":{"ownerReferences": []}}' --type=merge
```
从 Kibana 资源中删除 ClusterLogging ownerReferences
以下命令确保 ClusterLogging 不再拥有 Kibana 资源。ClusterLogging 资源的 visualization 字段更新不再影响 Kibana 资源。
```
$ oc -n openshift-logging patch kibana/kibana -p '{"metadata":{"ownerReferences": []}}' --type=merge
```
将 ClusterLogging 设置为 Managed 状态

$ oc -n openshift-logging patch clusterlogging/instance -p '{"spec":{"managementState": "Managed"}}' --type=merge

1.3.3. 日志可视化

用于日志视觉化的 OpenShift 控制台 UI 插件已从 cluster-logging-operator 移到 cluster-observability-operator 中。

1.3.4. 日志集合和转发

日志转发和转发配置现在在新的 API 下指定，这是 observability.openshift.io API 组的一部分。以下小节重点介绍了与旧 API 资源的不同。

注意

Vector 是唯一支持的收集器实现。

1.3.5. 管理、资源分配和工作负载调度

用于管理状态的配置（如 Managed、Unmanaged）、资源请求和限值、容限和节点选择现在是新的 ClusterLogForwarder API 的一部分。

以前的配置

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
spec:
  managementState: "Managed"
  collection:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

当前配置

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  managementState: Managed
  collector:
    resources:
      limits: {}
      requests: {}
    nodeSelector: {}
    tolerations: {}

1.3.6. 输入规格

输入规格是 ClusterLogForwarder 规格的可选部分。管理员可以继续使用 application、infrastructure 和 audit 的预定义值来收集这些源。

1.3.6.1. 应用程序输入

命名空间和容器包含和排除项已整合到一个字段中。

使用 Namespace 和 Container Includes 和 Excludes 的 5.9 应用程序输入

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       namespaces:
       - foo
       - bar
       includes:
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

带有 Namespace 和 Container Includes 和 Excludes 的 6.0 应用程序输入

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
   - name: application-logs
     type: application
     application:
       includes:
       - namespace: foo
       - namespace: bar
       - namespace: my-important
         container: main
       excludes:
       - container: too-verbose

注意

application, infrastructure, 和 audit 是保留词语，在定义输入时不能用作名称。

1.3.6.2. 输入接收者

对输入接收器的更改包括：

在接收器级别明确配置类型。
端口设置移到接收器级别。

5.9 Input Receivers

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    receiver:
      http:
        port: 8443
        format: kubeAPIAudit
  - name: a-syslog
    receiver:
      type: syslog
      syslog:
        port: 9442

6.0 Input Receivers

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
spec:
  inputs:
  - name: an-http
    type: receiver
    receiver:
      type: http
      port: 8443
      http:
        format: kubeAPIAudit
  - name: a-syslog
    type: receiver
    receiver:
      type: syslog
      port: 9442

1.3.7. 输出规格

输出规格的高级更改包括：

URL 设置移到每个输出类型规格中。
调整参数移到每个输出类型规格中。
将 TLS 配置与身份验证分离.
明确配置密钥和 secret/configmap，以用于 TLS 和身份验证。

1.3.8. secret 和 TLS 配置

现在，每个输出都会将 secret 和 TLS 配置划分为身份验证和 TLS 配置。它们必须在规格中明确定义，而不依赖于管理员使用可识别的密钥定义 secret。升级 TLS 和授权配置需要管理员了解之前识别的密钥才能继续使用现有的 secret。以下小节中的示例详细介绍了如何配置 ClusterLogForwarder secret 以转发到现有的红帽受管日志存储解决方案。

1.3.9. Red Hat Managed Elasticsearch

v5.9 转发到 Red Hat Managed Elasticsearch

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: elasticsearch

v6.0 转发到 Red Hat Managed Elasticsearch

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-elasticsearch
    type: elasticsearch
    elasticsearch:
      url: https://elasticsearch:9200
      version: 6
      index: <log_type>-write-{+yyyy.MM.dd}
    tls:
      ca:
        key: ca-bundle.crt
        secretName: collector
      certificate:
        key: tls.crt
        secretName: collector
      key:
        key: tls.key
        secretName: collector
  pipelines:
  - outputRefs:
    - default-elasticsearch
  - inputRefs:
    - application
    - infrastructure

注意

在本例中，应用程序日志被写入 application-write alias/index 中，而不是 app-write。

1.3.10. Red Hat Managed LokiStack

v5.9 转发到 Red Hat Managed LokiStack

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  logStore:
    type: lokistack
    lokistack:
      name: lokistack-dev

v6.0 转发到 Red Hat Managed LokiStack

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: default-lokistack
    type: lokiStack
    lokiStack:
      target:
        name: lokistack-dev
        namespace: openshift-logging
      authentication:
        token:
          from: serviceAccount
    tls:
      ca:
        key: service-ca.crt
        configMapName: openshift-service-ca.crt
  pipelines:
  - outputRefs:
    - default-lokistack
  - inputRefs:
    - application
    - infrastructure

1.3.11. 过滤和管道配置

Pipeline 配置现在只定义到其输出目的地的输入源路由，任何所需的转换都会作为过滤器单独配置。本发行版本中管道的所有属性都已转换为过滤器。单个过滤器在 filters 规格中定义，并由管道引用。

5.9 过滤器

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
spec:
  pipelines:
   - name: application-logs
     parse: json
     labels:
       foo: bar
     detectMultilineErrors: true

6.0 过滤器配置

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
spec:
  filters:
  - name: detectexception
    type: detectMultilineException
  - name: parse-json
    type: parse
  - name: labels
    type: openshiftLabels
    openshiftLabels:
      foo: bar
  pipelines:
  - name: application-logs
    filterRefs:
    - detectexception
    - labels
    - parse-json

1.3.12. 验证和状态

在创建或更新资源时，会强制进行大多数验证，从而提供即时反馈。这与之前的版本不同，验证会在创建后发生，需要检查资源状态。有些验证仍然会在创建后进行，在创建或更新时无法验证。

ClusterLogForwarder.observability.openshift.io 的实例必须满足以下条件，然后才能部署日志收集器：Authorized、Valid、Ready。这些条件示例如下：

6.0 状态条件

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
status:
  conditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: 'permitted to collect log types: [application]'
    reason: ClusterRolesExist
    status: "True"
    type: observability.openshift.io/Authorized
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/Valid
  - lastTransitionTime: "2024-09-13T12:16:45Z"
    message: ""
    reason: ReconciliationComplete
    status: "True"
    type: Ready
  filterConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "detectexception" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-detectexception
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: filter "parse-json" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidFilter-parse-json
  inputConditions:
  - lastTransitionTime: "2024-09-13T12:23:03Z"
    message: input "application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidInput-application1
  outputConditions:
  - lastTransitionTime: "2024-09-13T13:02:59Z"
    message: output "default-lokistack-application1" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidOutput-default-lokistack-application1
  pipelineConditions:
  - lastTransitionTime: "2024-09-13T03:28:44Z"
    message: pipeline "default-before" is valid
    reason: ValidationSuccess
    status: "True"
    type: observability.openshift.io/ValidPipeline-default-before

注意

满足且适用的条件的 "status" 值为 "True"。状态不是 "True" 的条件会提供一个原因，并给出一个说明问题的消息。

1.4. 配置日志转发

ClusterLogForwarder (CLF)允许用户配置将日志转发到各种目的地。它提供从不同来源选择日志消息的灵活方法，通过管道发送或过滤它们，并将它们转发到一个或多个输出。

ClusterLogForwarder 的主要功能

使用输入选择日志消息
使用输出将日志转发到外部目的地
使用过滤器过滤、转换和丢弃日志消息
定义日志转发管道连接输入、过滤器和输出

1.4.1. 设置日志集合

此 Cluster Logging 发行版本要求管理员为与 ClusterLogForwarder 关联的服务帐户明确授予日志收集权限。在以前的版本中，不需要传统的日志场景由 ClusterLogging 以及一个可选的 ClusterLogForwarder.logging.openshift.io 资源组成。

Red Hat OpenShift Logging Operator 提供 collect-audit-logs、collect-application-logs 和 collect-infrastructure-logs 集群角色，使收集器能够分别收集审计日志、应用程序日志和基础架构日志。

通过将所需的集群角色绑定到服务帐户来设置日志收集。

1.4.1.1. 传统服务帐户

要使用现有的旧服务帐户 logcollector，请创建以下 ClusterRoleBinding ：

$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector

另外，如果收集审计日志，请创建以下 ClusterRoleBinding ：

$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector

1.4.1.2. 创建服务帐户

先决条件

Red Hat OpenShift Logging Operator 安装在 openshift-logging 命名空间中。
有管理员权限。

流程

为收集器创建服务帐户。如果要将日志写入需要令牌进行身份验证的存储，则必须在服务帐户中包含令牌。

将适当的集群角色绑定到服务帐户：

绑定命令示例

$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>

1.4.1.2.1. 服务帐户的集群角色绑定

role_binding.yaml 文件将 ClusterLogging operator 的 ClusterRole 绑定到特定的 ServiceAccount，允许其在集群范围管理 Kubernetes 资源。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: manager-rolebinding
roleRef:                                           1
  apiGroup: rbac.authorization.k8s.io              2
  kind: ClusterRole                                3
  name: cluster-logging-operator                   4
subjects:                                          5
  - kind: ServiceAccount                           6
    name: cluster-logging-operator                 7
    namespace: openshift-logging                   8

1: roleRef：引用绑定应用到的 ClusterRole。
2: apiGroup ：指示 RBAC API 组，指定 ClusterRole 是 Kubernetes 的 RBAC 系统的一部分。
3: kind：指定引用的角色是一个 ClusterRole，它将应用集群范围的。
4: name ：绑定到 ServiceAccount 的 ClusterRole 名称，这里是 cluster-logging-operator。
5: subjects ：定义从 ClusterRole 授予权限的实体（用户或服务帐户）。
6: kind：指定主体是一个 ServiceAccount。
7: Name ：被授予权限的 ServiceAccount 的名称。
8: namespace ：指示 ServiceAccount 所在的命名空间。

1.4.1.2.2. 编写应用程序日志

write-application-logs-clusterrole.yaml 文件定义了一个 ClusterRole，它授予将应用程序日志写入 Loki 日志记录应用程序的权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-application-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - application                                 5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9
Annotations
<1> rules: Specifies the permissions granted by this ClusterRole.
<2> apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system.
<3> loki.grafana.com: The API group for managing Loki-related resources.
<4> resources: The resource type that the ClusterRole grants permission to interact with.
<5> application: Refers to the application resources within the Loki logging system.
<6> resourceNames: Specifies the names of resources that this role can manage.
<7> logs: Refers to the log resources that can be created.
<8> verbs: The actions allowed on the resources.
<9> create: Grants permission to create new logs in the Loki system.

1.4.1.2.3. 编写审计日志

write-audit-logs-clusterrole.yaml 文件定义了一个 ClusterRole，它授予在 Loki 日志记录系统中创建审计日志的权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-audit-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - audit                                       5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1 1: rules：定义此 ClusterRole 授予的权限。
2 2: apiGroups ：指定 API 组 loki.grafana.com。
3 3: loki.grafana.com ：负责 Loki 日志记录资源的 API 组。
4 4: resources：请参阅此角色管理的资源类型，本例中为 audit。
5 5: audit：指定角色管理 Loki 中的审计日志。
6 6: resourceNames ：定义角色可访问的特定资源。
7 7: logs ：引用可以由此角色管理的日志。
8 8: verbs ：资源允许的操作。
9 9: create ：授予创建新审计日志的权限。

1.4.1.2.4. 编写基础架构日志

write-infrastructure-logs-clusterrole.yaml 文件定义了一个 ClusterRole，它授予在 Loki 日志记录系统中创建基础架构日志的权限。

YAML 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-infrastructure-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - infrastructure                              5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1: rules：指定此 ClusterRole 授予的权限。
2: apiGroups ：指定 Loki 相关资源的 API 组。
3: loki.grafana.com ：管理 Loki 日志记录系统的 API 组。
4: resources：定义此角色可以与之交互的资源类型。
5: infrastructure ：请参阅此角色管理的基础架构相关资源。
6: resourceNames：指定此角色可以管理的资源的名称。
7: logs ：引用与基础架构相关的日志资源。
8: verbs ：此角色所允许的操作。
9: create ：授予在 Loki 系统中创建基础架构日志的权限。

1.4.1.2.5. ClusterLogForwarder 编辑器角色

clusterlogforwarder-editor-role.yaml 文件定义了一个 ClusterRole，允许用户在 OpenShift 中管理 ClusterLogForwarders。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterlogforwarder-editor-role
rules:                                              1
  - apiGroups:                                      2
      - observability.openshift.io                  3
    resources:                                      4
      - clusterlogforwarders                        5
    verbs:                                          6
      - create                                      7
      - delete                                      8
      - get                                         9
      - list                                        10
      - patch                                       11
      - update                                      12
      - watch                                       13

1: rules：指定此 ClusterRole 授予的权限。
2: apiGroups ：请参阅特定于 OpenShift 的 API 组
3: obervability.openshift.io ：用于管理可观察性资源的 API 组，如 logging。
4: resources：指定此角色可以管理的资源。
5: clusterlogforwarders ：请参阅 OpenShift 中的日志转发资源。
6: verbs ：指定 ClusterLogForwarders 上允许的操作。
7: create: Grants 权限来创建新的 ClusterLogForwarders。
8: delete: Grants 权限删除现有 ClusterLogForwarders。
9: get ：授予检索有关特定 ClusterLogForwarders 的信息的权限。
10: list ：允许列出所有 ClusterLogForwarders。
11: patch ：授予部分修改 ClusterLogForwarders 的权限。
12: update: 授予更新现有 ClusterLogForwarders 的权限。
13: watch ：授予监控 ClusterLogForwarders 的更改的权限。

1.4.2. 修改收集器中的日志级别

要修改收集器中的日志级别，您可以将 observability.openshift.io/log-level 注解设置为 trace、debug、info、warn、error 和 off。

日志级别注解示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  annotations:
    observability.openshift.io/log-level: debug
# ...

1.4.3. 管理 Operator

ClusterLogForwarder 资源有一个 managementState 字段，用于控制 Operator 是否主动管理其资源或保留其非受管状态：

受管: （默认）Operator 将驱动日志记录资源以匹配 CLF spec 中所需状态。
Unmanaged: Operator 不执行与日志记录组件相关的任何操作。

这样，管理员可以通过将 managementState 设置为 Unmanaged 来临时暂停日志转发。

1.4.4. ClusterLogForwarder 的结构

CLF 有一个 spec 部分，其中包含以下关键组件：

输入: 选择要转发的日志消息。来自集群不同部分的内置输入类型 application, infrastructure 和 audit。您还可以定义自定义输入。
输出: 定义要将日志转发到的目的地。每个输出都有一个唯一的名称和特定于类型的配置。
Pipelines: 定义通过过滤器到输出的路径日志从输入中获取。管道具有唯一名称，它由输入、输出和过滤器名称列表组成。
过滤器: 在管道中转换或丢弃日志消息。用户可以定义匹配某些日志字段并丢弃或修改消息的过滤器。过滤器按管道中指定的顺序应用。

1.4.4.1. 输入

输入在 spec.inputs 下的阵列中配置。有三个内置输入类型：

application: 从所有应用程序容器中选择日志，不包括基础架构命名空间中的日志，如 default、openshift 或带有 kube- 或 openshift- 前缀的任何命名空间。
infrastructure: 选择在 default 和 openshift 命名空间和节点日志中运行的基础架构组件的日志。
audit: 从 OpenShift API 服务器审计日志、Kubernetes API 服务器审计日志、ovn 审计日志和 auditd 的节点审计日志中选择日志。

用户可以定义类型 application 的自定义输入，它们从特定的命名空间选择日志或使用 pod 标签。

1.4.4.2. 输出

输出在 spec.outputs 下的一个数组中配置。每个输出都必须具有唯一的名称和类型。支持的类型有：

azureMonitor: 将日志转发到 Azure Monitor。
cloudwatch: 将日志转发到 AWS CloudWatch。
elasticsearch: 将日志转发到外部 Elasticsearch 实例。
googleCloudLogging: 将日志转发到 Google Cloud Logging。
http: 将日志转发到通用 HTTP 端点。
kafka: 将日志转发到 Kafka 代理。
loki: 将日志转发到 Loki 日志记录后端。
lokistack: 将日志转发到 Loki 和 Web 代理与 OpenShift Container Platform 身份验证集成支持的日志组合。LokiStack 的代理使用 OpenShift Container Platform 身份验证来强制实施多租户
otlp: 使用 OpenTelemetry 协议转发日志。
splunk: 将日志转发到 Splunk。
syslog: 将日志转发到外部 syslog 服务器。

每种输出类型都有自己的配置字段。

1.4.4.3. Pipelines

管道在 spec.pipelines 下的数组中配置。每个管道都必须具有唯一的名称，它由以下组成：

inputRefs: 日志应转发到此管道的输入名称。
outputRefs: 将日志发送到的输出名称。
filterRefs: （可选）要应用的过滤器名称。

filterRefs 的顺序很重要，因为它们会按顺序应用。较早的过滤器可以丢弃不会被后续过滤器处理的消息。

1.4.4.4. 过滤器

过滤器在 spec.filters 下的数组中配置。它们可以根据结构化字段的值匹配传入的日志消息，并修改或丢弃它们。

管理员可以配置以下过滤器：

1.4.4.5. 启用多行异常检测

启用容器日志的多行错误检测。

警告

启用此功能可能会对性能有影响，可能需要额外的计算资源或备用日志记录解决方案。

日志解析器通常会错误地将同一个例外中的不同的行识别为不同的例外。这会导致额外的日志条目，以及要跟踪的信息的不完整或不正确。

java 异常示例

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)

要启用日志记录来检测多行异常并将其重新编译到单个日志条目中，请确保 ClusterLogForwarder 自定义资源(CR)包含 .spec.filters 下的 detectMultilineErrors 字段。

ClusterLogForwarder CR 示例

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <name>
    type: detectMultilineException
  pipelines:
    - inputRefs:
        - <input-name>
      name: <pipeline-name>
      filterRefs:
        - <filter-name>
      outputRefs:
        - <output-name>

1.4.4.5.1. 详情

当日志消息作为一系列针对一个例外的信息出现时，会将它们合并到一个统一的日志记录中。第一个日志消息的内容被替换为序列中所有消息字段的连接内容。

收集器支持以下语言：

Java
JS
Ruby
Python
Golang
PHP
Dart

1.4.4.6. 配置内容过滤器以丢弃不需要的日志记录

配置 drop 过滤器后，日志收集器会根据过滤器在转发前评估日志流。收集器丢弃与指定配置匹配的不需要的日志记录。

流程

将过滤器的配置添加到 ClusterLogForwarder CR 中的 filters spec 中。
以下示例演示了如何配置 ClusterLogForwarder CR，以根据正则表达式丢弃日志记录：
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: drop 1
    drop: 2
    - test: 3
      - field: .kubernetes.labels."foo-bar/baz" 4
        matches: .+ 5
      - field: .kubernetes.pod_name
        notMatches: "my-pod" 6
  pipelines:
  - name: <pipeline_name> 7
    filterRefs: ["<filter_name>"]
# ...
```
1
指定过滤器的类型。drop 过滤器丢弃与过滤器配置匹配的日志记录。
2
指定应用 drop 过滤器的配置选项。
3
指定用于评估是否丢弃日志记录的测试配置。
如果为测试指定的所有条件都为 true，则测试会通过，记录将被丢弃。
当为 drop 过滤器配置指定多个测试时，如果有任何测试通过，则会丢弃记录。
如果评估条件时出错，例如，被评估的日志记录中缺少该字段，则条件评估为 false。
4
指定点分隔的字段路径，它是日志记录中字段的路径。该路径可以包含字母数字字符和下划线 (a-zA-Z0-9_)，例如 .kubernetes.namespace_name。如果网段包含此范围之外的字符，段必须放在引号内，例如，.kubernetes.labels."foo.bar-bar/baz"。您可以在单个 test 配置中包含多个字段路径，但它们都必须评估为 true 才能通过测试以及要应用的 drop 过滤器。
5
指定正则表达式。如果日志记录与此正则表达式匹配，它们将被丢弃。您可以为单个 field 路径设置 matches 或 notMatches 条件，但不能同时设置这两个条件。
6
指定正则表达式。如果日志记录与此正则表达式不匹配，它们将被丢弃。您可以为单个 field 路径设置 matches 或 notMatches 条件，但不能同时设置这两个条件。
7
指定 drop 过滤器应用到的管道。
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

其他示例

下面的额外示例演示了如何将 drop 过滤器配置为仅保留更高优先级的日志记录：

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...

除了在单一 test 配置中包含多个字段路径外，您还可以包含被视为 OR 检查的额外测试。在以下示例中，如果 test 配置评估为 true，则记录将被丢弃。但是，对于第二个 test 配置，两个字段 specs 都必须是 true，才能将其评估为 true ：

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .kubernetes.namespace_name
        matches: "^open"
    - test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...

1.4.4.7. API 审计过滤器概述

OpenShift API 服务器为每个 API 调用生成审计事件，详细说明请求者的请求、响应和请求者的身份，从而导致大量数据。API 审计过滤器使用规则启用非必要事件和事件大小减少，从而提高更易于管理的审计跟踪。规则按顺序检查，检查会在第一个匹配项时停止。事件中包含的数据量由 level 字段的值决定：

None: 事件被丢弃。
Metadata：只包含审计元数据，请求和响应正文会被删除。
Request：包含审计元数据和请求正文，响应正文会被删除。
RequestResponse：包含所有数据：元数据、请求正文和响应正文。响应正文可能非常大。例如，oc get pods -A 生成包含集群中每个 pod 的 YAML 描述的响应正文。

ClusterLogForwarder 自定义资源 (CR) 使用与标准 Kubernetes Audit 策略相同的格式，同时提供以下附加功能：

通配符

用户、组、命名空间和资源的名称可以在前导或尾部带有 * 星号字符。例如，命名空间 openshift-\* 匹配 openshift-apiserver 或 openshift-authentication。资源 \*/status 匹配 Pod/status 或 Deployment/status。

默认规则

与策略中任何规则不匹配的事件将被过滤，如下所示：

get、list 和 watch 等只读系统事件会被丢弃。
服务帐户写入发生在与服务帐户相同的命名空间中的事件将被丢弃。
所有其他事件都会被转发，受任何配置的速率限制。

要禁用这些默认值，请使用只有一个 level 字段的规则结束您的规则列表，或者添加一条空规则。

省略响应代码: 要省略的整数状态代码列表。您可以使用 OmitResponseCodes 字段（没有创建事件）的 HTTP 状态代码列表根据响应中的 HTTP 状态代码丢弃事件。默认值为 [404, 409, 422, 429]。如果该值为空列表 []，则不会省略状态代码。

ClusterLogForwarder CR Audit 策作为 OpenShift Container Platform 审计策略外的补充起作用。ClusterLogForwarder CR 审计过滤器更改日志收集器转发的内容，并提供按操作动词、用户、组、命名空间或资源过滤的功能。您可以创建多个过滤器，将同一审计流的不同摘要发送到不同的位置。例如，您可以将详细的流发送到本地集群日志存储，并将不太详细的流发送到远程站点。

注意

您必须具有集群角色 collect-audit-logs 才能收集审计日志。以下示例旨在说明审计策略中可能的规则范围，不是推荐的配置。

Audit 策略示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  pipelines:
    - name: my-pipeline
      inputRefs: audit 1
      filterRefs: my-policy 2
  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata

1: 收集的日志类型。此字段的值可以是 audit(用于审计日志）、application（用于应用程序日志）、infrastructure（用于基础架构日志），或输入为您的应用程序定义的名称。
2: 审计策略的名称。

1.4.4.8. 在输入 ny 过滤应用程序日志，包括标签表达式或匹配的标签键和值

您可以使用 input 选择器，根据标签表达式或匹配的标签键及其值包含应用程序日志。

流程

将过滤器的配置添加到 ClusterLogForwarder CR 中的 input spec 中。

以下示例演示了如何配置 ClusterLogForwarder CR，使其包含基于标签表达式或匹配的标签键/值的日志：

ClusterLogForwarder CR 示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env 1
            operator: In 2
            values: ["prod", "qa"] 3
          - key: zone
            operator: NotIn
            values: ["east", "west"]
          matchLabels: 4
            app: one
            name: app1
      type: application
# ...

1: 指定要匹配的标签键。
2: 指定 operator。有效值包括： In,NotIn,Exists, 和 DoesNotExist。
3: 指定字符串值的数组。如果 operator 值为 Exists 或 DoesNotExist，则值数组必须为空。
4: 指定准确的键或值映射。

运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

1.4.4.9. 配置内容过滤器以修剪日志记录

配置 prune 过滤器时，日志收集器会根据过滤器在转发前评估日志流。收集器通过删除 pod 注解等低值字段来修剪日志记录。

流程

将过滤器的配置添加到 ClusterLogForwarder CR 中的 prune spec 中。
以下示例演示了如何配置 ClusterLogForwarder CR，以根据字段路径修剪日志记录：
重要
如果指定了这两个信息，则首先根据 notIn 数组修剪记录，这优先于 in 数组。在使用 notIn 数组修剪记录后，会使用 in 数组来修剪这些记录。
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: prune 1
    prune: 2
      in: [.kubernetes.annotations, .kubernetes.namespace_id] 3
      notIn: [.kubernetes,.log_type,.message,."@timestamp"] 4
  pipelines:
  - name: <pipeline_name> 5
    filterRefs: ["<filter_name>"]
# ...
```
1
指定过滤器的类型。prune 过滤器根据配置的字段修剪日志记录。
2
指定应用 prune 过滤器的配置选项。in 和 notIn 字段被指定为点分隔字段路径的数组，它们是日志记录中字段的路径。这些路径可以包含字母数字字符和下划线 (a-zA-Z0-9_)，例如 .kubernetes.namespace_name。如果网段包含此范围之外的字符，段必须放在引号内，例如，.kubernetes.labels."foo.bar-bar/baz"。
3
可选：此阵列中指定的任何字段都会从日志记录中删除。
4
可选：没有在此阵列中指定的任何字段都会从日志记录中删除。
5
指定 prune 过滤器应用到的管道。
注意
过滤器显示 log_type、.log_source 和 .message 字段。
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

1.4.5. 根据源过滤审计和基础架构日志输入

您可以使用 input 选择器定义 audit 和 infrastructure 源列表，以收集日志。

流程

添加配置，以在 ClusterLogForwarder CR 中定义 audit 和 infrastructure 源。
以下示例演示了如何配置 ClusterLogForwarder CR 以定义 audit 和 infrastructure 源：
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs1
      type: infrastructure
      infrastructure:
        sources: 1
          - node
    - name: mylogs2
      type: audit
      audit:
        sources: 2
          - kubeAPI
          - openshiftAPI
          - ovn
# ...
```
1
指定要收集的基础架构源列表。有效的源包括：
node ：来自节点的日志
container ：命名空间中部署的工作负载的日志
2
指定要收集的审计源列表。有效的源包括：
kubeAPI: 来自 Kubernetes API 服务器的日志
openshiftAPI: 来自 OpenShift API 服务器的日志
auditd: 来自节点 auditd 服务的日志
ovn ：来自开放虚拟网络服务的日志
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

1.4.6. 通过包含或排除命名空间或容器名称，在输入中过滤应用程序日志

您可以使用 input 选择器根据命名空间和容器名称包含或排除应用程序日志。

流程

添加配置，以在 ClusterLogForwarder CR 中包含或排除命名空间和容器名称。
以下示例演示了如何配置 ClusterLogForwarder CR 以包含或排除命名空间和容器名称：
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project" 1
            container: "my-container" 2
        excludes:
          - container: "other-container*" 3
            namespace: "other-namespace" 4
# ...
```
1
指定日志只从这些命名空间中收集数据。
2
指定日志只从这些容器中收集数据。
3
指定收集日志时要忽略的命名空间模式。
4
指定收集日志时要忽略的容器集合。
注意
excludes 字段优先于 includes 字段。
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

1.5. 使用 LokiStack 存储日志

您可以配置 LokiStack CR 来存储应用程序、审计和基础架构相关的日志。

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

重要

对于长期存储或长时间查询，用户应查找其集群外部的日志存储。Loki 大小只针对短期存储（最多 30 天）进行了测试并被支持。

1.5.1. 先决条件

已使用 CLI 或 Web 控制台安装 Loki Operator。
在同一命名空间中有一个 serviceAccount，您可以在其中创建 ClusterLogForwarder。
serviceAccount 被分配了 collect-audit-logs、collect-application-logs 和 collect-infrastructure-logs 集群角色。

1.5.2. 核心设置和配置

基于角色的访问控制、基本监控和 pod 放置来部署 Loki。

1.5.3. 授权 LokiStack 规则 RBAC 权限

管理员可以允许用户通过将集群角色绑定到 username 来创建和管理自己的警报和记录规则。集群角色定义为 ClusterRole 对象，其中包含用户所需的基于角色的访问控制(RBAC)权限。

LokiStack 有以下用于警报和记录规则的集群角色：

运行名称	描述
`alertingrules.loki.grafana.com-v1-admin`	具有此角色的用户具有管理级别访问权限来管理警报规则。此集群角色授予在 `loki.grafana.com/v1` API 组中创建、读取、更新、删除、列出和监视 `AlertingRule` 资源的权限。
`alertingrules.loki.grafana.com-v1-crdview`	具有此角色的用户可以查看与 `loki.grafana.com/v1` API 组中的 `AlertingRule` 资源相关的自定义资源定义(CRD)的定义，但没有修改或管理这些资源的权限。
`alertingrules.loki.grafana.com-v1-edit`	具有此角色的用户有权创建、更新和删除 `AlertingRule` 资源。
`alertingrules.loki.grafana.com-v1-view`	具有此角色的用户可以读取 `loki.grafana.com/v1` API 组中的 `AlertingRule` 资源。它们可以检查现有警报规则的配置、标签和注解，但不能对它们进行任何修改。
`recordingrules.loki.grafana.com-v1-admin`	具有此角色的用户具有管理记录规则的管理级别访问权限。此集群角色授予在 `loki.grafana.com/v1` API 组中创建、读取、更新、删除、列出和监视 `RecordingRule` 资源的权限。
`recordingrules.loki.grafana.com-v1-crdview`	具有此角色的用户可以查看与 `loki.grafana.com/v1` API 组中的 `RecordingRule` 资源相关的自定义资源定义(CRD)的定义，但没有修改或管理这些资源的权限。
`recordingrules.loki.grafana.com-v1-edit`	具有此角色的用户有权创建、更新和删除 `RecordingRule` 资源。
`recordingrules.loki.grafana.com-v1-view`	具有此角色的用户可以读取 `loki.grafana.com/v1` API 组中的 `RecordingRule` 资源。它们可以检查现有警报规则的配置、标签和注解，但不能对它们进行任何修改。

1.5.3.1. 例子

要为用户应用集群角色，您必须将现有集群角色绑定到特定用户名。

集群角色可以是集群或命名空间范围，具体取决于您使用的角色绑定。使用 RoleBinding 对象时，如使用 oc adm policy add-role-to-user 命令时，集群角色仅适用于指定的命名空间。当使用 ClusterRoleBinding 对象时，如使用 oc adm policy add-cluster-role-to-user 命令时，集群角色会应用到集群中的所有命名空间。

以下示例命令为指定用户在集群中的特定命名空间中创建、读取、更新和删除(CRUD)权限：

特定命名空间中警报规则 CRUD 权限的集群角色绑定命令示例

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>

以下命令为所有命名空间中的警报规则授予指定用户管理员权限：

管理员权限的集群角色绑定命令示例

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>

1.5.4. 使用 Loki 创建基于日志的警报规则

AlertingRule CR 包含一组规格和 webhook 验证定义，用于声明单个 LokiStack 实例的警报规则组。另外，webhook 验证定义支持规则验证条件：

如果 AlertingRule CR 包含无效的 interval 周期，则它是一个无效的警报规则
如果 AlertingRule CR 包含无效的 for 周期，则它是一个无效的警报规则
如果 AlertingRule CR 包含无效的 LogQL expr，则它是一个无效的警报规则。
如果 AlertingRule CR 包含两个同名的组，则它是一个无效的警报规则。
如果以上都不适用，则警报规则被视为有效。

表 1.2. AlertingRule 定义
租户类型	`AlertingRule` CR 的有效命名空间
application	`<your_application_namespace>`
audit	`openshift-logging`
infrastructure	`openshift-/`, `kube-/\`, `default`

流程

创建 AlertingRule 自定义资源 (CR)：

基础架构 AlertingRule CR 示例

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure" 3
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: | 4
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical 5
            annotations:
              summary: High Loki Operator Reconciliation Errors 6
              description: High Loki Operator Reconciliation Errors 7

1: 创建此 AlertingRule CR 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
2: labels 块必须与 LokiStack spec.rules.selector 定义匹配。
3: infrastructure 租户的 AlertingRule CR 只在 openshift-*, kube-\*, 或 default 命名空间中被支持。
4: kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
5: 此必需字段的值必须是 critical、warning 或 info。
6: 这个字段是必须的。
7: 这个字段是必须的。

应用程序 AlertingRule CR 示例

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: | 3
              sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical 4
            annotations:
              summary:  5
              description:  6

1: 创建此 AlertingRule CR 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
2: labels 块必须与 LokiStack spec.rules.selector 定义匹配。
3: kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
4: 此必需字段的值必须是 critical、warning 或 info。
5: 此必需字段的值是规则的摘要。
6: 此必填字段的值是规则的详细描述。

应用 AlertingRule CR：
```
$ oc apply -f <filename>.yaml
```

1.5.5. 配置 Loki 以容许 memberlist 创建失败

在 OpenShift Container Platform 集群中，管理员通常使用非专用 IP 网络范围。因此，Loki memberlist 配置会失败，因为默认情况下，它只使用私有 IP 网络。

作为管理员，您可以为 memberlist 配置选择 pod 网络。您可以修改 LokiStack 自定义资源(CR)以使用 hashRing spec 中的 podIP 地址。要配置 LokiStack CR，请使用以下命令：

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'

LokiStack 示例，使其包含 podIP

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...

1.5.6. 使用 Loki 启用基于流的保留

您可以根据日志流配置保留策略。这些规则可全局设置，可以是每个租户，或两者。如果同时配置这两个，则租户规则会在全局规则之前应用。

重要

如果没有在 s3 存储桶或 LokiStack 自定义资源 (CR) 中定义保留周期，则不会修剪日志，它们会永久保留在 s3 存储桶中，这可能会填满 s3 存储。

注意

建议采用 schema v13。

流程

创建 LokiStack CR：

全局启用基于流的保留，如下例所示：

AWS 的基于流的全局保留示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
   global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 为所有日志流设置保留策略。注：此字段不会影响存储在对象存储中的保留周期。
2: 当此块被添加到 CR 时，集群中会启用保留。
3: 包含用于定义日志 stream.spec: limits 的 LogQL 查询：

根据租户启用基于流的保留，如下例所示：

AWS 的基于流的基于流的保留示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 根据租户设置保留策略。有效的租户类型是 application、audit 和 infrastructure。
2: 包含用于定义日志流的 LogQL 查询。

应用 LokiStack CR：
```
$ oc apply -f <filename>.yaml
```

1.5.7. Loki pod 放置

您可以通过在 pod 上使用容忍度或节点选择器来控制 Loki pod 在哪些节点上运行，并防止其他工作负载使用这些节点。

您可以使用 LokiStack 自定义资源 (CR) 将容限应用到日志存储 pod，并将污点应用到具有节点规格的节点。节点上的污点是一个 key:value 对，它指示节点排斥所有不允许污点的 pod。通过使用不在其他 pod 上的特定 key:value 对，可确保只有日志存储 pod 能够在该节点上运行。

带有节点选择器的 LokiStack 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1: 指定应用到节点选择器的组件 pod 类型。
2: 指定移到包含定义标签的节点的 pod。

带有节点选择器和容限的 LokiStack CR 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

要配置 LokiStack (CR) 的 nodeSelector 和 tolerations 字段，您可以使用 oc explain 命令查看特定资源的描述和字段：

$ oc explain lokistack.spec.template

输出示例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

如需更多信息，您可以添加一个特定字段：

$ oc explain lokistack.spec.template.compactor

输出示例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

1.5.7.1. 增强的可靠性和性能

配置以确保 Loki 在生产环境中的可靠性和效率。

1.5.7.2. 使用简短的令牌启用对基于云的日志存储的身份验证

工作负载身份联邦允许使用简短的令牌对基于云的日志存储进行身份验证。

流程

使用以下选项之一启用身份验证：

如果使用 OpenShift Container Platform Web 控制台安装 Loki Operator，则会自动检测到使用简短令牌的集群。系统将提示您创建角色，并提供 Loki Operator 所需的数据，以创建 CredentialsRequest 对象，该对象填充 secret。

如果使用 OpenShift CLI (oc) 安装 Loki Operator，则必须使用正确的模板为存储供应商手动创建 Subscription 对象，如下例所示。此身份验证策略只支持所示的存储供应商。

Azure 示例订阅

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>

AWS 示例订阅示例

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>

1.5.7.3. 配置 Loki 以容忍节点故障

Loki Operator 支持设置 pod 反关联性规则，以请求同一组件的 pod 调度到集群中的不同可用节点上。

关联性是 pod 的一个属性，用于控制它们希望调度到的节点。反关联性是 pod 的一个属性，用于阻止 pod 调度到某个节点上。

在 OpenShift Container Platform 中，可以借助 pod 关联性和 pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。

Operator 会为所有 Loki 组件设置默认、首选的 podAntiAffinity 规则，其中包括 compactor, distributor, gateway, indexGateway, ingester, querier, queryFrontend, 和 ruler 组件。

您可以通过在 requiredDuringSchedulingIgnoredDuringExecution 字段中配置所需的设置来覆盖 Loki 组件的首选 podAntiAffinity 设置：

ingester 组件的用户设置示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution: 1
        - labelSelector:
            matchLabels: 2
              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...

1: 定义必要规则的小节。
2: 必须匹配键-值对（标签）才能应用该规则。

1.5.7.4. 集群重启过程中的 LokiStack 行为

当 OpenShift Container Platform 集群重启时，LokiStack ingestion 和查询路径将继续在可用于节点的可用 CPU 和内存资源中运行。这意味着 OpenShift Container Platform 集群更新过程中，LokiStack 没有停机。此行为通过使用 PodDisruptionBudget 资源来实现。Loki Operator 为 Loki 置备 PodDisruptionBudget 资源，它决定了每个组件必须可用的最少 pod 数量，以确保特定条件下正常操作。

1.5.7.5. 高级部署和可扩展性

用于高可用性、可扩展性和错误处理的专用配置。

1.5.7.6. 支持区域的数据复制

Loki Operator 通过 pod 拓扑分布限制支持区感知数据复制。启用这个功能可提高可靠性，并防止出现单一区域故障的日志丢失。在将部署大小配置为 1x.extra-small, 1x.small, 或 1x.medium 时，replication.factor 字段会自动设置为 2。

为确保正确复制，您需要至少具有与复制因子指定的可用区数量。虽然可用区可能会比复制因素更多，但区域数量较少可能会导致写入失败。每个区域应托管相等的实例数量，以实现最佳操作。

启用区复制的 LokiStack CR 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2 1
 replication:
   factor: 2 2
   zones:
   -  maxSkew: 1 3
      topologyKey: topology.kubernetes.io/zone 4

1: 弃用的字段，输入的值会被 replication.factor 覆盖。
2: 当在设置时选择部署大小时，会自动设置这个值。
3: 两个拓扑域间的 pod 数量的最大差别。默认值为 1，您无法指定 0。
4: 以与节点标签对应的拓扑键的形式定义区域。

1.5.7.7. 从失败的区恢复 Loki pod

在 OpenShift Container Platform 中，当特定可用区资源无法访问时，会发生区失败。可用性区域是云提供商数据中心内的隔离区域，旨在增强冗余和容错能力。如果您的 OpenShift Container Platform 集群没有配置为处理此操作，则区失败可能会导致服务或数据丢失。

Loki pod 是 StatefulSet 的一部分，它们附带 StorageClass 对象置备的 PVC。每个 Loki pod 及其 PVC 驻留在同一区域中。当在集群中发生区故障时，StatefulSet 控制器会自动尝试恢复失败的区中受影响的 pod。

警告

以下流程将删除失败的区中的 PVC，以及其中包含的所有数据。为了避免完成数据丢失的 LokiStack CR 的 replication factor 字段，应该始终设置为大于 1 的值，以确保 Loki 复制。

先决条件

验证 LokiStack CR 是否具有大于 1 的复制因素。
control plane 检测到区失败，故障区中的节点由云供应商集成标记。

StatefulSet 控制器会自动尝试重新调度失败的区中的 pod。因为关联的 PVC 也位于失败的区中，所以自动重新调度到不同的区无法正常工作。您必须手动删除失败的区中 PVC，以便在新区中成功重新创建有状态 Loki Pod 及其置备的 PVC。

流程

运行以下命令，列出处于 Pending 状态的 pod：

$ oc get pods --field-selector status.phase==Pending -n openshift-logging

oc get pods 输出示例

NAME                           READY   STATUS    RESTARTS   AGE 1
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m

1: 这些 pod 处于 Pending 状态，因为它们对应的 PVC 位于失败的区中。

运行以下命令，列出处于 Pending 状态的 PVC：

$ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

oc get pvc 输出示例

storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1

运行以下命令，删除 pod 的 PVC：

$ oc delete pvc <pvc_name>  -n openshift-logging

运行以下命令来删除 pod：
```
$ oc delete pod <pod_name>  -n openshift-logging
```
成功删除这些对象后，应在可用区域中自动重新调度它们。

1.5.7.7.1. 对处于终止状态的 PVC 进行故障排除

如果 PVC 元数据终结器被设置为 kubernetes.io/pv-protection，PVC 可能会处于 terminating 状态。删除终结器应该允许 PVC 成功删除。

运行以下命令删除每个 PVC 的终结器，然后重试删除。

$ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging

1.5.7.8. Loki 速率限制错误故障排除

如果 Log Forwarder API 将超过速率限制的大量信息转发到 Loki，Loki 会生成速率限制(429)错误。

这些错误可能会在正常操作过程中发生。例如，当将 logging 添加到已具有某些日志的集群中时，logging 会尝试充分利用现有日志条目时可能会出现速率限制错误。在这种情况下，如果添加新日志的速度小于总速率限值，历史数据最终会被处理，并且不要求用户干预即可解决速率限制错误。

如果速率限制错误持续发生，您可以通过修改 LokiStack 自定义资源(CR)来解决此问题。

重要

LokiStack CR 在 Grafana 托管的 Loki 上不可用。本主题不适用于 Grafana 托管的 Loki 服务器。

Conditions

Log Forwarder API 配置为将日志转发到 Loki。

您的系统向 Loki 发送大于 2 MB 的消息块。例如：

"values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
.......
......
......
......
\"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}

输入 oc logs -n openshift-logging -l component=collector 后，集群中的收集器日志会显示包含以下错误消息之一的行：

429 Too Many Requests Ingestion rate limit exceeded

Vector 错误消息示例

2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true

Fluentd 错误消息示例

2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"

在接收结束时也会看到这个错误。例如，在 LokiStack ingester pod 中：

Loki ingester 错误消息示例

level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream

流程

更新 LokiStack CR 中的 ingestionBurstSize 和 ingestionRate 字段：
```
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 16 1
        ingestionRate: 8 2
# ...
```
1
ingestionBurstSize 字段定义每个经销商副本的最大本地速率限制示例大小（以 MB 为单位）。这个值是一个硬限制。将此值设置为至少在单个推送请求中预期的最大日志大小。不允许大于 ingestionBurstSize 值的单个请求。
2
ingestionRate 字段是每秒最大最大样本量的软限制（以 MB 为单位）。如果日志速率超过限制，则会出现速率限制错误，但收集器会重试发送日志。只要总平均值低于限制，系统就会在没有用户干预的情况下解决错误。

1.6. 日志的视觉化

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

重要

在 Cluster Observability Operator (COO) （当前为技术预览(TP)）正式发布 (GA) 版本之前，在 OpenShift Container Platform 4.14 或更新版本中，红帽为使用 Logging 6.0 或更新版本、带有 COO 作为其日志记录 UI 插件的用户提供支持。这个支持例外是临时的，因为 COO 包括几个独立的功能，其中的一些功能仍为 TP 功能，但日志记录 UI 插件已准备好 GA。

第 2 章 Logging 6.1

2.1. Logging 6.1

2.1.1. 日志记录 6.1.0 发行注记

此发行版本包括 Red Hat OpenShift 程序错误修复 6.1.0 的 Logging。

2.1.1.1. 新功能及功能增强

2.1.1.1.1. 日志集合

此功能增强将源 iostream 添加到从收集的容器日志发送的属性中。该值根据收集器如何接收它，设置为 stdout 或 stderr。(LOG-5292)
在这个版本中，收集器的默认内存限值从 1024 Mi 增加到 2048 Mi。用户应该根据集群的特定需求和规格来调整资源限值。(LOG-6072)
在这个版本中，用户可以将 ClusterLogForwarder CR 的 syslog 输出交付模式设置为 AtLeastOnce 或 AtMostOnce。(LOG-6355)

2.1.1.1.2. 日志存储

在这个版本中，新的 1x.pico LokiStack 大小支持具有较少工作负载的集群，以及减少日志卷（最多 50GB/day）。(LOG-5939)

2.1.1.2. 技术预览

重要

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

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

在这个版本中，OpenTelemetry 日志可以使用 OTel (OpenTelemetry)数据模型转发到 Red Hat Managed LokiStack 实例。要启用此功能，请在 ClusterLogForwarder 配置中添加 observability.openshift.io/tech-preview-otlp-output: "enabled" 注解。如需了解更多配置信息，请参阅 OTLP Forwarding。
在这个版本中，在 lokiStack 输出规格中添加了一个 dataModel 字段。将 dataModel 设置为 Otel，以使用 OpenTelemetry 数据格式配置日志转发。默认值为 Viaq。有关数据映射的详情，请参考 OTLP 规格。

2.1.1.3. 程序错误修复

无。

2.1.1.4. CVE

2.2. Logging 6.1

上下文： logging-6x-6.1

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

2.2.1. 输入和输出

输入指定要转发的日志源。日志记录提供内置输入类型： 应用程序、接收器、基础架构 和 审计，它们从集群的不同部分选择日志。您还可以根据命名空间或 pod 标签定义自定义输入，以微调日志选择。

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

2.2.2. 接收器输入类型

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

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

2.2.3. 管道和过滤器

2.2.4. Operator 行为

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

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

2.2.5. 验证

2.2.6. 快速启动

OpenShift Logging 支持两种数据模型：

ViaQ （通用可用性）
OpenTelemetry （技术预览）

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

注意

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

2.2.6.1. quick start with ViaQ

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

先决条件

集群管理员权限

流程

从 OperatorHub 安装 Red Hat OpenShift Logging Operator、Loki Operator 和 Cluster Observability Operator (COO)。

在 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

注意

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

为收集器创建服务帐户：

$ oc create sa collector -n openshift-logging

允许收集器的服务帐户将数据写入 LokiStack CR：
```
$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
```
注意
ClusterRole 资源是在 Cluster Logging Operator 安装过程中自动创建的，不需要手动创建。
允许收集器的服务帐户收集日志：
```
$ oc project openshift-logging
```
```
$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
```
注意
示例将收集器绑定到所有三个角色（应用程序、基础架构和审计），但默认情况下，仅收集应用和基础架构日志。要收集审计日志，请更新 ClusterLogForwarder 配置使其包含它们。根据您的环境所需的特定日志类型，分配角色。

创建一个 UIPlugin CR，以启用 Observe 选项卡中的 Log 部分：

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki

创建一个 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

注意

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

验证

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

2.2.6.2. 使用 OpenTelemetry 快速开始

重要

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

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

先决条件

集群管理员权限

流程

从 OperatorHub 安装 Red Hat OpenShift Logging Operator、Loki Operator 和 Cluster Observability Operator (COO)。

在 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

注意

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

为收集器创建服务帐户：

$ oc create sa collector -n openshift-logging

允许收集器的服务帐户将数据写入 LokiStack CR：
```
$ oc adm policy add-cluster-role-to-user logging-collector-logs-writer -z collector
```
注意
ClusterRole 资源是在 Cluster Logging Operator 安装过程中自动创建的，不需要手动创建。
允许收集器的服务帐户收集日志：
```
$ oc project openshift-logging
```
```
$ oc adm policy add-cluster-role-to-user collect-application-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-audit-logs -z collector
```
```
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs -z collector
```
注意
示例将收集器绑定到所有三个角色（应用程序、基础架构和审计）。默认情况下，只收集应用程序和基础架构日志。要收集审计日志，请更新 ClusterLogForwarder 配置使其包含它们。根据您的环境所需的特定日志类型，分配角色。

创建一个 UIPlugin CR，以启用 Observe 选项卡中的 Log 部分：

apiVersion: observability.openshift.io/v1alpha1
kind: UIPlugin
metadata:
  name: logging
spec:
  type: Logging
  logging:
    lokiStack:
      name: logging-loki

创建一个 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

1: 使用注解启用 Otel 数据模型，它是一个技术预览功能。
2: 将输出类型定义为 lokiStack。
3: 指定 OpenTelemetry 数据模型。

注意

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

验证

进入 OpenShift web 控制台中的 Observe → OpenShift Logging → LokiStack → Writes 来验证 OTLP 是否正常工作，并检查 Distributor - Structured Metadata。

2.3. 配置日志转发

ClusterLogForwarder 的主要功能

使用输入选择日志消息
使用输出将日志转发到外部目的地
使用过滤器过滤、转换和丢弃日志消息
定义日志转发管道连接输入、过滤器和输出

2.3.1. 设置日志集合

通过将所需的集群角色绑定到服务帐户来设置日志收集。

2.3.1.1. 传统服务帐户

要使用现有的旧服务帐户 logcollector，请创建以下 ClusterRoleBinding ：

$ oc adm policy add-cluster-role-to-user collect-application-logs system:serviceaccount:openshift-logging:logcollector
$ oc adm policy add-cluster-role-to-user collect-infrastructure-logs system:serviceaccount:openshift-logging:logcollector

另外，如果收集审计日志，请创建以下 ClusterRoleBinding ：

$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector

2.3.1.2. 创建服务帐户

先决条件

Red Hat OpenShift Logging Operator 安装在 openshift-logging 命名空间中。
有管理员权限。

流程

为收集器创建服务帐户。如果要将日志写入需要令牌进行身份验证的存储，则必须在服务帐户中包含令牌。

将适当的集群角色绑定到服务帐户：

绑定命令示例

$ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>

2.3.1.2.1. 服务帐户的集群角色绑定

role_binding.yaml 文件将 ClusterLogging operator 的 ClusterRole 绑定到特定的 ServiceAccount，允许其在集群范围管理 Kubernetes 资源。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: manager-rolebinding
roleRef:                                           1
  apiGroup: rbac.authorization.k8s.io              2
  kind: ClusterRole                                3
  name: cluster-logging-operator                   4
subjects:                                          5
  - kind: ServiceAccount                           6
    name: cluster-logging-operator                 7
    namespace: openshift-logging                   8

1: roleRef：引用绑定应用到的 ClusterRole。
2: apiGroup ：指示 RBAC API 组，指定 ClusterRole 是 Kubernetes 的 RBAC 系统的一部分。
3: kind：指定引用的角色是一个 ClusterRole，它将应用集群范围的。
4: name ：绑定到 ServiceAccount 的 ClusterRole 名称，这里是 cluster-logging-operator。
5: subjects ：定义从 ClusterRole 授予权限的实体（用户或服务帐户）。
6: kind：指定主体是一个 ServiceAccount。
7: Name ：被授予权限的 ServiceAccount 的名称。
8: namespace ：指示 ServiceAccount 所在的命名空间。

2.3.1.2.2. 编写应用程序日志

write-application-logs-clusterrole.yaml 文件定义了一个 ClusterRole，它授予将应用程序日志写入 Loki 日志记录应用程序的权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-application-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - application                                 5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9
Annotations
<1> rules: Specifies the permissions granted by this ClusterRole.
<2> apiGroups: Refers to the API group loki.grafana.com, which relates to the Loki logging system.
<3> loki.grafana.com: The API group for managing Loki-related resources.
<4> resources: The resource type that the ClusterRole grants permission to interact with.
<5> application: Refers to the application resources within the Loki logging system.
<6> resourceNames: Specifies the names of resources that this role can manage.
<7> logs: Refers to the log resources that can be created.
<8> verbs: The actions allowed on the resources.
<9> create: Grants permission to create new logs in the Loki system.

2.3.1.2.3. 编写审计日志

write-audit-logs-clusterrole.yaml 文件定义了一个 ClusterRole，它授予在 Loki 日志记录系统中创建审计日志的权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-audit-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - audit                                       5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1 1: rules：定义此 ClusterRole 授予的权限。
2 2: apiGroups ：指定 API 组 loki.grafana.com。
3 3: loki.grafana.com ：负责 Loki 日志记录资源的 API 组。
4 4: resources：请参阅此角色管理的资源类型，本例中为 audit。
5 5: audit：指定角色管理 Loki 中的审计日志。
6 6: resourceNames ：定义角色可访问的特定资源。
7 7: logs ：引用可以由此角色管理的日志。
8 8: verbs ：资源允许的操作。
9 9: create ：授予创建新审计日志的权限。

2.3.1.2.4. 编写基础架构日志

write-infrastructure-logs-clusterrole.yaml 文件定义了一个 ClusterRole，它授予在 Loki 日志记录系统中创建基础架构日志的权限。

YAML 示例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-logging-write-infrastructure-logs
rules:                                              1
  - apiGroups:                                      2
      - loki.grafana.com                            3
    resources:                                      4
      - infrastructure                              5
    resourceNames:                                  6
      - logs                                        7
    verbs:                                          8
      - create                                      9

1: rules：指定此 ClusterRole 授予的权限。
2: apiGroups ：指定 Loki 相关资源的 API 组。
3: loki.grafana.com ：管理 Loki 日志记录系统的 API 组。
4: resources：定义此角色可以与之交互的资源类型。
5: infrastructure ：请参阅此角色管理的基础架构相关资源。
6: resourceNames：指定此角色可以管理的资源的名称。
7: logs ：引用与基础架构相关的日志资源。
8: verbs ：此角色所允许的操作。
9: create ：授予在 Loki 系统中创建基础架构日志的权限。

2.3.1.2.5. ClusterLogForwarder 编辑器角色

clusterlogforwarder-editor-role.yaml 文件定义了一个 ClusterRole，允许用户在 OpenShift 中管理 ClusterLogForwarders。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterlogforwarder-editor-role
rules:                                              1
  - apiGroups:                                      2
      - observability.openshift.io                  3
    resources:                                      4
      - clusterlogforwarders                        5
    verbs:                                          6
      - create                                      7
      - delete                                      8
      - get                                         9
      - list                                        10
      - patch                                       11
      - update                                      12
      - watch                                       13

1: rules：指定此 ClusterRole 授予的权限。
2: apiGroups ：请参阅特定于 OpenShift 的 API 组
3: obervability.openshift.io ：用于管理可观察性资源的 API 组，如 logging。
4: resources：指定此角色可以管理的资源。
5: clusterlogforwarders ：请参阅 OpenShift 中的日志转发资源。
6: verbs ：指定 ClusterLogForwarders 上允许的操作。
7: create: Grants 权限来创建新的 ClusterLogForwarders。
8: delete: Grants 权限删除现有 ClusterLogForwarders。
9: get ：授予检索有关特定 ClusterLogForwarders 的信息的权限。
10: list ：允许列出所有 ClusterLogForwarders。
11: patch ：授予部分修改 ClusterLogForwarders 的权限。
12: update: 授予更新现有 ClusterLogForwarders 的权限。
13: watch ：授予监控 ClusterLogForwarders 的更改的权限。

2.3.2. 修改收集器中的日志级别

要修改收集器中的日志级别，您可以将 observability.openshift.io/log-level 注解设置为 trace、debug、info、warn、error 和 off。

日志级别注解示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  annotations:
    observability.openshift.io/log-level: debug
# ...

2.3.3. 管理 Operator

ClusterLogForwarder 资源有一个 managementState 字段，用于控制 Operator 是否主动管理其资源或保留其非受管状态：

受管: （默认）Operator 将驱动日志记录资源以匹配 CLF spec 中所需状态。
Unmanaged: Operator 不执行与日志记录组件相关的任何操作。

这样，管理员可以通过将 managementState 设置为 Unmanaged 来临时暂停日志转发。

2.3.4. ClusterLogForwarder 的结构

CLF 有一个 spec 部分，其中包含以下关键组件：

输入: 选择要转发的日志消息。来自集群不同部分的内置输入类型 application, infrastructure 和 audit。您还可以定义自定义输入。
输出: 定义要将日志转发到的目的地。每个输出都有一个唯一的名称和特定于类型的配置。
Pipelines: 定义通过过滤器到输出的路径日志从输入中获取。管道具有唯一名称，它由输入、输出和过滤器名称列表组成。
过滤器: 在管道中转换或丢弃日志消息。用户可以定义匹配某些日志字段并丢弃或修改消息的过滤器。过滤器按管道中指定的顺序应用。

2.3.4.1. 输入

输入在 spec.inputs 下的阵列中配置。有三个内置输入类型：

application: 从所有应用程序容器中选择日志，不包括基础架构命名空间中的日志，如 default、openshift 或带有 kube- 或 openshift- 前缀的任何命名空间。
infrastructure: 选择在 default 和 openshift 命名空间和节点日志中运行的基础架构组件的日志。
audit: 从 OpenShift API 服务器审计日志、Kubernetes API 服务器审计日志、ovn 审计日志和 auditd 的节点审计日志中选择日志。

用户可以定义类型 application 的自定义输入，它们从特定的命名空间选择日志或使用 pod 标签。

2.3.4.2. 输出

输出在 spec.outputs 下的一个数组中配置。每个输出都必须具有唯一的名称和类型。支持的类型有：

azureMonitor: 将日志转发到 Azure Monitor。
cloudwatch: 将日志转发到 AWS CloudWatch。
elasticsearch: 将日志转发到外部 Elasticsearch 实例。
googleCloudLogging: 将日志转发到 Google Cloud Logging。
http: 将日志转发到通用 HTTP 端点。
kafka: 将日志转发到 Kafka 代理。
loki: 将日志转发到 Loki 日志记录后端。
lokistack: 将日志转发到 Loki 和 Web 代理与 OpenShift Container Platform 身份验证集成支持的日志组合。LokiStack 的代理使用 OpenShift Container Platform 身份验证来强制实施多租户
otlp: 使用 OpenTelemetry 协议转发日志。
splunk: 将日志转发到 Splunk。
syslog: 将日志转发到外部 syslog 服务器。

每种输出类型都有自己的配置字段。

2.3.5. 配置 OTLP 输出

集群管理员可以使用 OpenTelemetry 协议(OTLP)输出来收集日志并将其转发到 OTLP 接收器。OTLP 输出使用 OpenTelemetry Observability 框架定义的规格使用 JSON 编码通过 HTTP 发送数据。

重要

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

流程

创建或编辑 ClusterLogForwarder 自定义资源(CR)，通过添加以下注解来启用使用 OTLP 的转发：

ClusterLogForwarder CR 示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  annotations:
    observability.openshift.io/tech-preview-otlp-output: "enabled" 1
  name: clf-otlp
spec:
  serviceAccount:
    name: <service_account_name>
  outputs:
  - name: otlp
    type: otlp
    otlp:
      tuning:
        compression: gzip
        deliveryMode: AtLeastOnce
        maxRetryDuration: 20
        maxWrite: 10M
        minRetryDuration: 5
      url: <otlp_url> 2
  pipelines:
  - inputRefs:
    - application
    - infrastructure
    - audit
    name: otlp-logs
    outputRefs:
    - otlp

1: 使用此注解启用 OpenTelemetry 协议(OTLP)输出，它是一个技术预览功能。
2: 此 URL 必须是绝对的，是发送日志的 OTLP 端点的占位符。

注意

OTLP 输出使用 OpenTelemetry 数据模型，它与其他输出类型的 ViaQ 数据模型不同。它遵循 OpenTelemetry Observability 框架定义的 OpenTelemetry Semantic Conventions。

2.3.5.1. Pipelines

管道在 spec.pipelines 下的数组中配置。每个管道都必须具有唯一的名称，它由以下组成：

inputRefs: 日志应转发到此管道的输入名称。
outputRefs: 将日志发送到的输出名称。
filterRefs: （可选）要应用的过滤器名称。

filterRefs 的顺序很重要，因为它们会按顺序应用。较早的过滤器可以丢弃不会被后续过滤器处理的消息。

2.3.5.2. 过滤器

过滤器在 spec.filters 下的数组中配置。它们可以根据结构化字段的值匹配传入的日志消息，并修改或丢弃它们。

管理员可以配置以下过滤器：

2.3.5.3. 启用多行异常检测

启用容器日志的多行错误检测。

警告

启用此功能可能会对性能有影响，可能需要额外的计算资源或备用日志记录解决方案。

日志解析器通常会错误地将同一个例外中的不同的行识别为不同的例外。这会导致额外的日志条目，以及要跟踪的信息的不完整或不正确。

java 异常示例

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)

要启用日志记录来检测多行异常并将其重新编译到单个日志条目中，请确保 ClusterLogForwarder 自定义资源(CR)包含 .spec.filters 下的 detectMultilineErrors 字段。

ClusterLogForwarder CR 示例

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <name>
    type: detectMultilineException
  pipelines:
    - inputRefs:
        - <input-name>
      name: <pipeline-name>
      filterRefs:
        - <filter-name>
      outputRefs:
        - <output-name>

2.3.5.3.1. 详情

收集器支持以下语言：

Java
JS
Ruby
Python
Golang
PHP
Dart

2.3.5.4. 配置内容过滤器以丢弃不需要的日志记录

配置 drop 过滤器后，日志收集器会根据过滤器在转发前评估日志流。收集器丢弃与指定配置匹配的不需要的日志记录。

流程

将过滤器的配置添加到 ClusterLogForwarder CR 中的 filters spec 中。
以下示例演示了如何配置 ClusterLogForwarder CR，以根据正则表达式丢弃日志记录：
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: drop 1
    drop: 2
    - test: 3
      - field: .kubernetes.labels."foo-bar/baz" 4
        matches: .+ 5
      - field: .kubernetes.pod_name
        notMatches: "my-pod" 6
  pipelines:
  - name: <pipeline_name> 7
    filterRefs: ["<filter_name>"]
# ...
```
1
指定过滤器的类型。drop 过滤器丢弃与过滤器配置匹配的日志记录。
2
指定应用 drop 过滤器的配置选项。
3
指定用于评估是否丢弃日志记录的测试配置。
如果为测试指定的所有条件都为 true，则测试会通过，记录将被丢弃。
当为 drop 过滤器配置指定多个测试时，如果有任何测试通过，则会丢弃记录。
如果评估条件时出错，例如，被评估的日志记录中缺少该字段，则条件评估为 false。
4
指定点分隔的字段路径，它是日志记录中字段的路径。该路径可以包含字母数字字符和下划线 (a-zA-Z0-9_)，例如 .kubernetes.namespace_name。如果网段包含此范围之外的字符，段必须放在引号内，例如，.kubernetes.labels."foo.bar-bar/baz"。您可以在单个 test 配置中包含多个字段路径，但它们都必须评估为 true 才能通过测试以及要应用的 drop 过滤器。
5
指定正则表达式。如果日志记录与此正则表达式匹配，它们将被丢弃。您可以为单个 field 路径设置 matches 或 notMatches 条件，但不能同时设置这两个条件。
6
指定正则表达式。如果日志记录与此正则表达式不匹配，它们将被丢弃。您可以为单个 field 路径设置 matches 或 notMatches 条件，但不能同时设置这两个条件。
7
指定 drop 过滤器应用到的管道。
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

其他示例

下面的额外示例演示了如何将 drop 过滤器配置为仅保留更高优先级的日志记录：

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: important
    type: drop
    drop:
    - test:
      - field: .kubernetes.namespace_name
        matches: "^open"
    - test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...

2.3.5.5. API 审计过滤器概述

None: 事件被丢弃。
Metadata：只包含审计元数据，请求和响应正文会被删除。
Request：包含审计元数据和请求正文，响应正文会被删除。
RequestResponse：包含所有数据：元数据、请求正文和响应正文。响应正文可能非常大。例如，oc get pods -A 生成包含集群中每个 pod 的 YAML 描述的响应正文。

ClusterLogForwarder 自定义资源 (CR) 使用与标准 Kubernetes Audit 策略相同的格式，同时提供以下附加功能：

通配符

默认规则

与策略中任何规则不匹配的事件将被过滤，如下所示：

get、list 和 watch 等只读系统事件会被丢弃。
服务帐户写入发生在与服务帐户相同的命名空间中的事件将被丢弃。
所有其他事件都会被转发，受任何配置的速率限制。

要禁用这些默认值，请使用只有一个 level 字段的规则结束您的规则列表，或者添加一条空规则。

省略响应代码: 要省略的整数状态代码列表。您可以使用 OmitResponseCodes 字段（没有创建事件）的 HTTP 状态代码列表根据响应中的 HTTP 状态代码丢弃事件。默认值为 [404, 409, 422, 429]。如果该值为空列表 []，则不会省略状态代码。

注意

您必须具有集群角色 collect-audit-logs 才能收集审计日志。以下示例旨在说明审计策略中可能的规则范围，不是推荐的配置。

Audit 策略示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  pipelines:
    - name: my-pipeline
      inputRefs: audit 1
      filterRefs: my-policy 2
  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata

1: 收集的日志类型。此字段的值可以是 audit(用于审计日志）、application（用于应用程序日志）、infrastructure（用于基础架构日志），或输入为您的应用程序定义的名称。
2: 审计策略的名称。

2.3.5.6. 在输入 ny 过滤应用程序日志，包括标签表达式或匹配的标签键和值

您可以使用 input 选择器，根据标签表达式或匹配的标签键及其值包含应用程序日志。

流程

将过滤器的配置添加到 ClusterLogForwarder CR 中的 input spec 中。

以下示例演示了如何配置 ClusterLogForwarder CR，使其包含基于标签表达式或匹配的标签键/值的日志：

ClusterLogForwarder CR 示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env 1
            operator: In 2
            values: ["prod", "qa"] 3
          - key: zone
            operator: NotIn
            values: ["east", "west"]
          matchLabels: 4
            app: one
            name: app1
      type: application
# ...

1: 指定要匹配的标签键。
2: 指定 operator。有效值包括： In,NotIn,Exists, 和 DoesNotExist。
3: 指定字符串值的数组。如果 operator 值为 Exists 或 DoesNotExist，则值数组必须为空。
4: 指定准确的键或值映射。

运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

2.3.5.7. 配置内容过滤器以修剪日志记录

配置 prune 过滤器时，日志收集器会根据过滤器在转发前评估日志流。收集器通过删除 pod 注解等低值字段来修剪日志记录。

流程

将过滤器的配置添加到 ClusterLogForwarder CR 中的 prune spec 中。
以下示例演示了如何配置 ClusterLogForwarder CR，以根据字段路径修剪日志记录：
重要
如果指定了这两个信息，则首先根据 notIn 数组修剪记录，这优先于 in 数组。在使用 notIn 数组修剪记录后，会使用 in 数组来修剪这些记录。
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  filters:
  - name: <filter_name>
    type: prune 1
    prune: 2
      in: [.kubernetes.annotations, .kubernetes.namespace_id] 3
      notIn: [.kubernetes,.log_type,.message,."@timestamp"] 4
  pipelines:
  - name: <pipeline_name> 5
    filterRefs: ["<filter_name>"]
# ...
```
1
指定过滤器的类型。prune 过滤器根据配置的字段修剪日志记录。
2
指定应用 prune 过滤器的配置选项。in 和 notIn 字段被指定为点分隔字段路径的数组，它们是日志记录中字段的路径。这些路径可以包含字母数字字符和下划线 (a-zA-Z0-9_)，例如 .kubernetes.namespace_name。如果网段包含此范围之外的字符，段必须放在引号内，例如，.kubernetes.labels."foo.bar-bar/baz"。
3
可选：此阵列中指定的任何字段都会从日志记录中删除。
4
可选：没有在此阵列中指定的任何字段都会从日志记录中删除。
5
指定 prune 过滤器应用到的管道。
注意
过滤器显示 log_type、.log_source 和 .message 字段。
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

2.3.6. 根据源过滤审计和基础架构日志输入

您可以使用 input 选择器定义 audit 和 infrastructure 源列表，以收集日志。

流程

添加配置，以在 ClusterLogForwarder CR 中定义 audit 和 infrastructure 源。
以下示例演示了如何配置 ClusterLogForwarder CR 以定义 audit 和 infrastructure 源：
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs1
      type: infrastructure
      infrastructure:
        sources: 1
          - node
    - name: mylogs2
      type: audit
      audit:
        sources: 2
          - kubeAPI
          - openshiftAPI
          - ovn
# ...
```
1
指定要收集的基础架构源列表。有效的源包括：
node ：来自节点的日志
container ：命名空间中部署的工作负载的日志
2
指定要收集的审计源列表。有效的源包括：
kubeAPI: 来自 Kubernetes API 服务器的日志
openshiftAPI: 来自 OpenShift API 服务器的日志
auditd: 来自节点 auditd 服务的日志
ovn ：来自开放虚拟网络服务的日志
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

2.3.7. 通过包含或排除命名空间或容器名称，在输入中过滤应用程序日志

您可以使用 input 选择器根据命名空间和容器名称包含或排除应用程序日志。

流程

添加配置，以在 ClusterLogForwarder CR 中包含或排除命名空间和容器名称。
以下示例演示了如何配置 ClusterLogForwarder CR 以包含或排除命名空间和容器名称：
ClusterLogForwarder CR 示例
```
apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
# ...
spec:
  serviceAccount:
    name: <service_account_name>
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project" 1
            container: "my-container" 2
        excludes:
          - container: "other-container*" 3
            namespace: "other-namespace" 4
# ...
```
1
指定日志只从这些命名空间中收集数据。
2
指定日志只从这些容器中收集数据。
3
指定收集日志时要忽略的命名空间模式。
4
指定收集日志时要忽略的容器集合。
注意
excludes 字段优先于 includes 字段。
运行以下命令来应用 ClusterLogForwarder CR：
```
$ oc apply -f <filename>.yaml
```

2.4. 使用 LokiStack 存储日志

您可以配置 LokiStack CR 来存储应用程序、审计和基础架构相关的日志。

重要

对于长期存储或长时间查询，用户应查找其集群外部的日志存储。Loki 大小只针对短期存储（最多 30 天）进行了测试并被支持。

2.4.1. Loki 部署大小

Loki 的大小使用 1x.<size> 格式，其中值 1x 是实例数量，<size> 指定性能功能。

1x.pico 配置定义了具有最少资源和限制要求的单个 Loki 部署，为所有 Loki 组件提供高可用性(HA)支持。此配置适用于不需要单个复制因子或自动编译的部署。

磁盘请求在大小配置之间相似，允许客户测试不同的大小，以确定其部署需求的最佳选择。

重要

对于部署大小，无法更改 1x 值。

表 2.1. Loki 大小
	1x.demo	1x.pico [仅限6.1+]	1x.extra-small	1x.small	1x.medium
数据传输	仅用于演示	50GB/day	100GB/day	500GB/day	2TB/day
每秒查询数 (QPS)	仅用于演示	1-25 QPS at 200ms	1-25 QPS at 200ms	25-50 QPS at 200ms	25-75 QPS at 200ms
复制因子	None	2	2	2	2
总 CPU 请求	None	7 个 vCPU	14 个 vCPU	34 个 vCPU	54 个 vCPU
使用标尺的 CPU 请求总数	None	8 个 vCPU	16 个 vCPU	42 个 vCPU	70 个 vCPU
内存请求总数	None	17Gi	31Gi	67Gi	139Gi
使用规则器的内存请求总数	None	18Gi	35Gi	83Gi	171Gi
磁盘请求总数	40Gi	590Gi	430Gi	430Gi	590Gi
使用标尺的磁盘请求总数	80Gi	910Gi	750Gi	750Gi	910Gi

2.4.2. 先决条件

已使用 CLI 或 Web 控制台安装 Loki Operator。
在同一命名空间中有一个 serviceAccount，您可以在其中创建 ClusterLogForwarder。
serviceAccount 被分配了 collect-audit-logs、collect-application-logs 和 collect-infrastructure-logs 集群角色。

2.4.3. 核心设置和配置

基于角色的访问控制、基本监控和 pod 放置来部署 Loki。

2.4.4. 授权 LokiStack 规则 RBAC 权限

LokiStack 有以下用于警报和记录规则的集群角色：

运行名称	描述
`alertingrules.loki.grafana.com-v1-admin`	具有此角色的用户具有管理级别访问权限来管理警报规则。此集群角色授予在 `loki.grafana.com/v1` API 组中创建、读取、更新、删除、列出和监视 `AlertingRule` 资源的权限。
`alertingrules.loki.grafana.com-v1-crdview`	具有此角色的用户可以查看与 `loki.grafana.com/v1` API 组中的 `AlertingRule` 资源相关的自定义资源定义(CRD)的定义，但没有修改或管理这些资源的权限。
`alertingrules.loki.grafana.com-v1-edit`	具有此角色的用户有权创建、更新和删除 `AlertingRule` 资源。
`alertingrules.loki.grafana.com-v1-view`	具有此角色的用户可以读取 `loki.grafana.com/v1` API 组中的 `AlertingRule` 资源。它们可以检查现有警报规则的配置、标签和注解，但不能对它们进行任何修改。
`recordingrules.loki.grafana.com-v1-admin`	具有此角色的用户具有管理记录规则的管理级别访问权限。此集群角色授予在 `loki.grafana.com/v1` API 组中创建、读取、更新、删除、列出和监视 `RecordingRule` 资源的权限。
`recordingrules.loki.grafana.com-v1-crdview`	具有此角色的用户可以查看与 `loki.grafana.com/v1` API 组中的 `RecordingRule` 资源相关的自定义资源定义(CRD)的定义，但没有修改或管理这些资源的权限。
`recordingrules.loki.grafana.com-v1-edit`	具有此角色的用户有权创建、更新和删除 `RecordingRule` 资源。
`recordingrules.loki.grafana.com-v1-view`	具有此角色的用户可以读取 `loki.grafana.com/v1` API 组中的 `RecordingRule` 资源。它们可以检查现有警报规则的配置、标签和注解，但不能对它们进行任何修改。

2.4.4.1. 例子

要为用户应用集群角色，您必须将现有集群角色绑定到特定用户名。

以下示例命令为指定用户在集群中的特定命名空间中创建、读取、更新和删除(CRUD)权限：

特定命名空间中警报规则 CRUD 权限的集群角色绑定命令示例

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>

以下命令为所有命名空间中的警报规则授予指定用户管理员权限：

管理员权限的集群角色绑定命令示例

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>

2.4.5. 使用 Loki 创建基于日志的警报规则

AlertingRule CR 包含一组规格和 webhook 验证定义，用于声明单个 LokiStack 实例的警报规则组。另外，webhook 验证定义支持规则验证条件：

如果 AlertingRule CR 包含无效的 interval 周期，则它是一个无效的警报规则
如果 AlertingRule CR 包含无效的 for 周期，则它是一个无效的警报规则
如果 AlertingRule CR 包含无效的 LogQL expr，则它是一个无效的警报规则。
如果 AlertingRule CR 包含两个同名的组，则它是一个无效的警报规则。
如果以上都不适用，则警报规则被视为有效。

表 2.2. AlertingRule 定义
租户类型	`AlertingRule` CR 的有效命名空间
application	`<your_application_namespace>`
audit	`openshift-logging`
infrastructure	`openshift-/`, `kube-/\`, `default`

流程

创建 AlertingRule 自定义资源 (CR)：

基础架构 AlertingRule CR 示例

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure" 3
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: | 4
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical 5
            annotations:
              summary: High Loki Operator Reconciliation Errors 6
              description: High Loki Operator Reconciliation Errors 7

1: 创建此 AlertingRule CR 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
2: labels 块必须与 LokiStack spec.rules.selector 定义匹配。
3: infrastructure 租户的 AlertingRule CR 只在 openshift-*, kube-\*, 或 default 命名空间中被支持。
4: kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
5: 此必需字段的值必须是 critical、warning 或 info。
6: 这个字段是必须的。
7: 这个字段是必须的。

应用程序 AlertingRule CR 示例

  apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns 1
    labels: 2
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: | 3
              sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical 4
            annotations:
              summary:  5
              description:  6

1: 创建此 AlertingRule CR 的命名空间必须具有与 LokiStack spec.rules.namespaceSelector 定义匹配的标签。
2: labels 块必须与 LokiStack spec.rules.selector 定义匹配。
3: kubernetes_namespace_name: 的值必须与 metadata.namespace 的值匹配。
4: 此必需字段的值必须是 critical、warning 或 info。
5: 此必需字段的值是规则的摘要。
6: 此必填字段的值是规则的详细描述。

应用 AlertingRule CR：
```
$ oc apply -f <filename>.yaml
```

2.4.6. 配置 Loki 以容许 memberlist 创建失败

在 OpenShift Container Platform 集群中，管理员通常使用非专用 IP 网络范围。因此，Loki memberlist 配置会失败，因为默认情况下，它只使用私有 IP 网络。

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'

LokiStack 示例，使其包含 podIP

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...

2.4.7. 使用 Loki 启用基于流的保留

您可以根据日志流配置保留策略。这些规则可全局设置，可以是每个租户，或两者。如果同时配置这两个，则租户规则会在全局规则之前应用。

重要

如果没有在 s3 存储桶或 LokiStack 自定义资源 (CR) 中定义保留周期，则不会修剪日志，它们会永久保留在 s3 存储桶中，这可能会填满 s3 存储。

注意

建议采用 schema v13。

流程

创建 LokiStack CR：

全局启用基于流的保留，如下例所示：

AWS 的基于流的全局保留示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
   global: 1
      retention: 2
        days: 20
        streams:
        - days: 4
          priority: 1
          selector: '{kubernetes_namespace_name=~"test.+"}' 3
        - days: 1
          priority: 1
          selector: '{log_type="infrastructure"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 为所有日志流设置保留策略。注：此字段不会影响存储在对象存储中的保留周期。
2: 当此块被添加到 CR 时，集群中会启用保留。
3: 包含用于定义日志 stream.spec: limits 的 LogQL 查询：

根据租户启用基于流的保留，如下例所示：

AWS 的基于流的基于流的保留示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      retention:
        days: 20
    tenants: 1
      application:
        retention:
          days: 1
          streams:
            - days: 4
              selector: '{kubernetes_namespace_name=~"test.+"}' 2
      infrastructure:
        retention:
          days: 5
          streams:
            - days: 1
              selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}'
  managementState: Managed
  replicationFactor: 1
  size: 1x.small
  storage:
    schemas:
    - effectiveDate: "2020-10-11"
      version: v13
    secret:
      name: logging-loki-s3
      type: aws
  storageClassName: gp3-csi
  tenants:
    mode: openshift-logging

1: 根据租户设置保留策略。有效的租户类型是 application、audit 和 infrastructure。
2: 包含用于定义日志流的 LogQL 查询。

应用 LokiStack CR：
```
$ oc apply -f <filename>.yaml
```

2.4.8. Loki pod 放置

您可以通过在 pod 上使用容忍度或节点选择器来控制 Loki pod 在哪些节点上运行，并防止其他工作负载使用这些节点。

带有节点选择器的 LokiStack 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor: 1
      nodeSelector:
        node-role.kubernetes.io/infra: "" 2
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1: 指定应用到节点选择器的组件 pod 类型。
2: 指定移到包含定义标签的节点的 pod。

带有节点选择器和容限的 LokiStack CR 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

要配置 LokiStack (CR) 的 nodeSelector 和 tolerations 字段，您可以使用 oc explain 命令查看特定资源的描述和字段：

$ oc explain lokistack.spec.template

输出示例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

如需更多信息，您可以添加一个特定字段：

$ oc explain lokistack.spec.template.compactor

输出示例

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

2.4.8.1. 增强的可靠性和性能

配置以确保 Loki 在生产环境中的可靠性和效率。

2.4.8.2. 使用简短的令牌启用对基于云的日志存储的身份验证

工作负载身份联邦允许使用简短的令牌对基于云的日志存储进行身份验证。

流程

使用以下选项之一启用身份验证：

如果使用 OpenShift Container Platform Web 控制台安装 Loki Operator，则会自动检测到使用简短令牌的集群。系统将提示您创建角色，并提供 Loki Operator 所需的数据，以创建 CredentialsRequest 对象，该对象填充 secret。

Azure 示例订阅

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>

AWS 示例订阅示例

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-6.0"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>

2.4.8.3. 配置 Loki 以容忍节点故障

Loki Operator 支持设置 pod 反关联性规则，以请求同一组件的 pod 调度到集群中的不同可用节点上。

关联性是 pod 的一个属性，用于控制它们希望调度到的节点。反关联性是 pod 的一个属性，用于阻止 pod 调度到某个节点上。

在 OpenShift Container Platform 中，可以借助 pod 关联性和 pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。

您可以通过在 requiredDuringSchedulingIgnoredDuringExecution 字段中配置所需的设置来覆盖 Loki 组件的首选 podAntiAffinity 设置：

ingester 组件的用户设置示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution: 1
        - labelSelector:
            matchLabels: 2
              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...

1: 定义必要规则的小节。
2: 必须匹配键-值对（标签）才能应用该规则。

2.4.8.4. 集群重启过程中的 LokiStack 行为

2.4.8.5. 高级部署和可扩展性

用于高可用性、可扩展性和错误处理的专用配置。

2.4.8.6. 支持区域的数据复制

启用区复制的 LokiStack CR 示例

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2 1
 replication:
   factor: 2 2
   zones:
   -  maxSkew: 1 3
      topologyKey: topology.kubernetes.io/zone 4

1: 弃用的字段，输入的值会被 replication.factor 覆盖。
2: 当在设置时选择部署大小时，会自动设置这个值。
3: 两个拓扑域间的 pod 数量的最大差别。默认值为 1，您无法指定 0。
4: 以与节点标签对应的拓扑键的形式定义区域。

2.4.8.7. 从失败的区恢复 Loki pod

警告

先决条件

验证 LokiStack CR 是否具有大于 1 的复制因素。
control plane 检测到区失败，故障区中的节点由云供应商集成标记。

流程

运行以下命令，列出处于 Pending 状态的 pod：

$ oc get pods --field-selector status.phase==Pending -n openshift-logging

oc get pods 输出示例

NAME                           READY   STATUS    RESTARTS   AGE 1
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m

1: 这些 pod 处于 Pending 状态，因为它们对应的 PVC 位于失败的区中。

运行以下命令，列出处于 Pending 状态的 PVC：

$ oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r

oc get pvc 输出示例

storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1

运行以下命令，删除 pod 的 PVC：

$ oc delete pvc <pvc_name>  -n openshift-logging

运行以下命令来删除 pod：
```
$ oc delete pod <pod_name>  -n openshift-logging
```
成功删除这些对象后，应在可用区域中自动重新调度它们。

2.4.8.7.1. 对处于终止状态的 PVC 进行故障排除

如果 PVC 元数据终结器被设置为 kubernetes.io/pv-protection，PVC 可能会处于 terminating 状态。删除终结器应该允许 PVC 成功删除。

运行以下命令删除每个 PVC 的终结器，然后重试删除。

$ oc patch pvc <pvc_name> -p '{"metadata":{"finalizers":null}}' -n openshift-logging

2.4.8.8. Loki 速率限制错误故障排除

如果 Log Forwarder API 将超过速率限制的大量信息转发到 Loki，Loki 会生成速率限制(429)错误。

如果速率限制错误持续发生，您可以通过修改 LokiStack 自定义资源(CR)来解决此问题。

重要

LokiStack CR 在 Grafana 托管的 Loki 上不可用。本主题不适用于 Grafana 托管的 Loki 服务器。

Conditions

Log Forwarder API 配置为将日志转发到 Loki。

您的系统向 Loki 发送大于 2 MB 的消息块。例如：

"values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
.......
......
......
......
\"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}

输入 oc logs -n openshift-logging -l component=collector 后，集群中的收集器日志会显示包含以下错误消息之一的行：

429 Too Many Requests Ingestion rate limit exceeded

Vector 错误消息示例

2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true

Fluentd 错误消息示例

2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"

在接收结束时也会看到这个错误。例如，在 LokiStack ingester pod 中：

Loki ingester 错误消息示例

level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream

流程

更新 LokiStack CR 中的 ingestionBurstSize 和 ingestionRate 字段：
```
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 16 1
        ingestionRate: 8 2
# ...
```
1
ingestionBurstSize 字段定义每个经销商副本的最大本地速率限制示例大小（以 MB 为单位）。这个值是一个硬限制。将此值设置为至少在单个推送请求中预期的最大日志大小。不允许大于 ingestionBurstSize 值的单个请求。
2
ingestionRate 字段是每秒最大最大样本量的软限制（以 MB 为单位）。如果日志速率超过限制，则会出现速率限制错误，但收集器会重试发送日志。只要总平均值低于限制，系统就会在没有用户干预的情况下解决错误。

2.5. Loki 中的 OTLP 数据 ingestion

日志记录 6.1 使用 OpenTelemetry 协议(OTLP)启用 API 端点。因为 OTLP 是不是为 Loki 设计的标准化格式，因此需要 Loki 端的额外配置，才能将 OpenTelemetry 的数据格式映射到 Loki 的数据模型。OTLP 缺少概念，如 流标签或 结构化元数据。相反，OTLP 以属性形式提供有关日志条目的元数据，并分为三个类别：

资源
影响范围
Log

这允许根据需要为多个条目同时或单独设置元数据。

2.5.1. 为 OTLP 数据生成配置 LokiStack

重要

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

要为 OTLP ingestion 配置 LokiStack 自定义资源(CR)，请按照以下步骤执行：

先决条件

确保您的 Loki 设置支持结构化元数据，在模式版本 13 中引入的，以启用 OTLP 日志 ingestion。

流程

设置 schema 版本：
- 在创建新的 LokiStack CR 时，在存储 schema 配置中设置 version: v13。
  注意
  对于现有配置，使用 version: v13 添加新 schema 条目，并在以后有 有效Date。有关更新模式版本的更多信息，请参阅升级架构 (Grafana 文档)。
配置存储模式，如下所示：
配置存储模式示例
```
# ...
spec:
  storage:
    schemas:
    - version: v13
      effectiveDate: 2024-10-25
```
传递了 有效Date 后，v13 模式将生效，使 LokiStack 能够存储结构化的元数据。

2.5.2. 属性映射

当 Loki Operator 设置为 openshift-logging 模式时，它会自动应用一组默认的属性映射。这些映射将特定的 OTLP 属性与 Loki 的流标签和结构化元数据保持一致。

对于典型的设置，这些默认映射应足够。但是，在以下情况下，您可能需要自定义属性映射：

使用自定义 Collector：如果设置包含一个生成额外属性的自定义收集器，请考虑自定义映射以确保在 Loki 中保留这些属性。
调整属性详细级别：如果默认属性集比必要更详细，则只能将其减少到必要的属性。这可以避免过量数据存储并简化日志记录过程。

重要

没有映射到流标签或结构化元数据的属性不会存储在 Loki 中。

2.5.2.1. OpenShift 的自定义属性映射

当在 openshift-logging 模式中使用 Loki Operator 时，属性映射会遵循 OpenShift 默认值，但可以配置自定义映射来调整它们。自定义映射允许进一步配置来满足特定的需求。

在 openshift-logging 模式中，可以根据需要为所有租户或单独的租户配置自定义属性映射。定义自定义映射后，它们会被附加到 OpenShift 默认值。如果不需要默认推荐的标签，可以在租户配置中禁用它们。

注意

Loki Operator 和 Loki 本身之间的主要区别在于继承处理。默认情况下，Loki 仅将 default_resource_attributes_as_index_labels 复制到租户，而 Loki Operator 会将整个全局配置应用到 openshift-logging 模式中的每个租户。

在 LokiStack 中，属性映射配置通过 limits 设置进行管理：

# ...
spec:
  limits:
    global:
      otlp: {} 1
    tenants:
      application:
        otlp: {} 2

1: 全局 OTLP 属性配置。
2: openshift-logging 模式中 应用程序 租户的 OTLP 属性配置。

注意

全局和每个租户 OTLP 配置都可以将属性映射到流标签或结构化元数据。至少需要一个流标签才能将日志条目保存到 Loki 存储，因此请确保此配置满足要求。

流标签仅从资源级别属性生成，Lokial 资源结构反映：

spec:
  limits:
    global:
      otlp:
        streamLabels:
          resourceAttributes:
          - name: "k8s.namespace.name"
          - name: "k8s.pod.name"
          - name: "k8s.container.name"

结构化元数据从资源、范围或日志级别属性生成：

# ...
spec:
  limits:
    global:
      otlp:
        streamLabels:
          # ...
        structuredMetadata:
          resourceAttributes:
          - name: "process.command_line"
          - name: "k8s\\.pod\\.labels\\..+"
            regex: true
          scopeAttributes:
          - name: "service.name"
          logAttributes:
          - name: "http.route"

提示

在 Loki 中映射类似属性时，通过设置 regex: true 来使用正则表达式。

重要

避免使用正则表达式进行流标签，因为这会增加数据卷。

2.5.2.2. 自定义 OpenShift 默认值

在 openshift-logging 模式中，需要某些属性，且因为 OpenShift 功能的角色而无法从配置中删除。如果性能会受到影响，可能会禁用标记为推荐的其他属性。

当在没有自定义属性的情况下使用 openshift-logging 模式时，您可以立即实现与 OpenShift 工具的兼容性。如果需要其他属性作为流标签或结构化元数据，使用自定义配置。自定义配置可以使用默认配置合并。

2.5.2.3. 删除推荐的属性

要在 openshift-logging 模式中减少默认属性，请禁用推荐的属性：

# ...
spec:
  tenants:
    mode: openshift-logging
    openshift:
      otlp:
        disableRecommendedAttributes: true 1

1: 设置 disableRecommendedAttributes: true 以删除推荐的属性，这会将默认属性限制为 所需的属性。

注意

如果默认属性导致性能或存储问题，这个选项很有用。此设置可能会对查询性能造成负面影响，因为它会删除默认流标签。您应该将此选项与自定义属性配置配对，以保留对查询至关重要的属性。

2.5.3. 其他资源

2.6. OpenTelemetry 数据模型

本文档概述了 Red Hat OpenShift Logging 的 OpenTelemetry 支持带有 Logging 6.1 的协议和语义约定。

重要

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

2.6.1. 转发和ingestion 协议

Red Hat OpenShift Logging 使用 OTLP Specification 收集和将日志转发到 OpenTelemetry 端点。OTLP 编码、传输和交付遥测数据。您还可以部署 Loki 存储，它提供了一个 OTLP endpont 来 ingest 日志流。本文档定义了从各种 OpenShift 集群源收集的日志的语义约定。

2.6.2. 语义约定

此解决方案中的日志收集器收集以下日志流：

容器日志
集群节点日志
集群节点 auditd 日志
Kubernetes 和 OpenShift API 服务器日志
OpenShift Virtual Network (OVN)日志

您可以根据 OpenTelemetry 语义属性定义的语义约定来转发这些流。OpenTelemetry 中的语义惯例将资源定义为生成遥测的实体的不可变表示，由属性标识。例如，容器中运行的进程包括 container_name、cluster_id、pod_name、namespace 以及可能 部署或 app_name 等属性。这些属性在资源对象下分组，这有助于减少重复并优化日志传输作为遥测数据。

除了资源属性外，日志也可以包含特定于检测库的范围属性，以及特定于每个日志条目的日志属性。这些属性提供有关每个日志条目的详细信息，并在存储中查询日志时增强过滤功能。

以下部分定义通常转发的属性。

2.6.2.1. 日志条目结构

所有日志流都包括以下日志数据字段：

Applicable Sources 列指示每个字段应用到哪些日志源：

All: 此字段存在于所有日志中。
容器 ：此字段存在于 Kubernetes 容器日志中，包括应用程序和基础架构。
audit: 此字段存在于 Kubernetes、OpenShift API 和 OVN 日志中。
auditd ：此字段存在于节点 auditd 日志中。
journal: 此字段存在于节点日志中。

Name	适用的源	注释
`正文（body）`	all
`observedTimeUnixNano`	all
`timeUnixNano`	all
`severityText`	容器, journal
`属性`	all	（可选）转发流特定属性时演示

2.6.2.2. 属性

日志条目根据其源包括一组资源、范围和日志属性，如下表中所述。

Location 列指定属性类型：

resource ：指示资源属性
Scope ：指示范围属性
log ：指示日志属性

Storage 列指示属性是否使用默认 openshift-logging 模式存储在 LokiStack 中，并指定属性存储的位置：

流标签 ：
- 针对特定标签启用有效的过滤和查询。
- 如果 Loki Operator 在配置中强制实施此属性，则可以被标记为 required。
结构化元数据 ：
- 允许详细过滤和存储键值对。
- 允许用户在不需要 JSON 解析的情况下使用直接标签进行简化的查询。

使用 OTLP 时，用户可以通过标签直接过滤查询，而不是使用 JSON 解析，从而提高了查询的速度和效率。

Name	位置	适用的源	存储(LokiStack)	注释
`log_source`	resource	all	所需的流标签	(DEPRECATED) Compatibility 属性，包含与 `openshift.log.source`相同的信息
`log_type`	resource	all	所需的流标签	(DEPRECATED) Compatibility 属性，包含与 `openshift.log.type`相同的信息
`kubernetes.container_name`	resource	container	流标签	(DEPRECATED) Compatibility 属性，包含与 `k8s.container.name`相同的信息
`kubernetes.host`	resource	all	流标签	(DEPRECATED) Compatibility 属性，包含与 `k8s.node.name`相同的信息
`kubernetes.namespace_name`	resource	container	所需的流标签	(DEPRECATED) Compatibility 属性，包含与 `k8s.namespace.name`相同的信息
`kubernetes.pod_name`	resource	container	流标签	(DEPRECATED) Compatibility 属性，包含与 `k8s.pod.name`相同的信息
`openshift.cluster_id`	resource	all		(DEPRECATED) Compatibility 属性，包含与 `openshift.cluster.uid`相同的信息
`level`	log	容器, journal		(DEPRECATED) Compatibility 属性，包含与 `severityText`相同的信息
`openshift.cluster.uid`	resource	all	所需的流标签
`openshift.log.source`	resource	all	所需的流标签
`openshift.log.type`	resource	all	所需的流标签
`openshift.labels.*`	resource	all	结构化元数据
`k8s.node.name`	resource	all	流标签
`k8s.namespace.name`	resource	container	所需的流标签
`k8s.container.name`	resource	container	流标签
`k8s.pod.labels.*`	resource	container	结构化元数据
`k8s.pod.name`	resource	container	流标签
`k8s.pod.uid`	resource	container	结构化元数据
`k8s.cronjob.name`	resource	container	流标签	根据 pod 的创建条件转发
`k8s.daemonset.name`	resource	container	流标签	根据 pod 的创建条件转发
`k8s.deployment.name`	resource	container	流标签	根据 pod 的创建条件转发
`k8s.job.name`	resource	container	流标签	根据 pod 的创建条件转发
`k8s.replicaset.name`	resource	container	结构化元数据	根据 pod 的创建条件转发
`k8s.statefulset.name`	resource	container	流标签	根据 pod 的创建条件转发
`log.iostream`	log	container	结构化元数据
`k8s.audit.event.level`	log	audit	结构化元数据
`k8s.audit.event.stage`	log	audit	结构化元数据
`k8s.audit.event.user_agent`	log	audit	结构化元数据
`k8s.audit.event.request.uri`	log	audit	结构化元数据
`k8s.audit.event.response.code`	log	audit	结构化元数据
`k8s.audit.event.annotation.*`	log	audit	结构化元数据
`k8s.audit.event.object_ref.resource`	log	audit	结构化元数据
`k8s.audit.event.object_ref.name`	log	audit	结构化元数据
`k8s.audit.event.object_ref.namespace`	log	audit	结构化元数据
`k8s.audit.event.object_ref.api_group`	log	audit	结构化元数据
`k8s.audit.event.object_ref.api_version`	log	audit	结构化元数据
`k8s.user.username`	log	audit	结构化元数据
`k8s.user.groups`	log	audit	结构化元数据
`process.executable.name`	resource	journal	结构化元数据
`process.executable.path`	resource	journal	结构化元数据
`process.command_line`	resource	journal	结构化元数据
`process.pid`	resource	journal	结构化元数据
`service.name`	resource	journal	流标签
`systemd.t.*`	log	journal	结构化元数据
`systemd.u.*`	log	journal	结构化元数据

注意

标记为 Compatibility 属性 的属性支持最小的与 ViaQ 数据模型的兼容性。这些属性已弃用，作为兼容性层，以确保持续 UI 功能。这些属性将保持支持，直到日志记录 UI 在以后的版本中完全支持 OpenTelemetry 对应部分。

当将属性名称持久化到存储中时，Loki 会更改属性名称。该名称将被小写，并且集合中的所有字符(..,/,-)将被下划线(_)替换。例如，k8s.namespace.name 将变为 k8s_namespace_name。

2.6.3. 其他资源

2.7. 日志的视觉化

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

重要

Legal Notice

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.

日志记录

在 OpenShift Container Platform 中配置和使用日志

第 1 章 Logging 6.0

1.1. 发行注记

1.1.1. Logging 6.0.2

1.1.1.1. 程序错误修复

1.1.1.2. CVE

1.1.2. Logging 6.0.1

1.1.2.1. 程序错误修复

1.1.2.2. CVE

1.1.3. Logging 6.0.0

1.1.4. 删除通知

1.1.5. 新功能及功能增强

1.1.6. 技术预览功能

1.1.7. 程序错误修复

1.1.8. CVE

1.2. Logging 6.0

1.2.1. 输入和输出

1.2.2. 接收器输入类型

1.2.3. 管道和过滤器

1.2.4. Operator 行为

1.2.5. 验证

1.2.5.1. 快速入门

1.3. 升级到 Logging 6.0

1.3.1. 使用 oc explain 命令

1.3.1.1. 资源描述

1.3.1.2. 层次结构

1.3.1.3. 类型信息

1.3.1.4. 默认值

1.3.2. 日志存储

1.3.3. 日志可视化

1.3.4. 日志集合和转发

1.3.5. 管理、资源分配和工作负载调度

1.3.6. 输入规格

1.3.6.1. 应用程序输入

1.3.6.2. 输入接收者

1.3.7. 输出规格

1.3.8. secret 和 TLS 配置

1.3.9. Red Hat Managed Elasticsearch

1.3.10. Red Hat Managed LokiStack

1.3.11. 过滤和管道配置

1.3.12. 验证和状态

1.4. 配置日志转发

1.4.1. 设置日志集合

1.4.1.1. 传统服务帐户

1.4.1.2. 创建服务帐户

1.4.1.2.1. 服务帐户的集群角色绑定

1.4.1.2.2. 编写应用程序日志

1.4.1.2.3. 编写审计日志

1.4.1.2.4. 编写基础架构日志

1.4.1.2.5. ClusterLogForwarder 编辑器角色

1.4.2. 修改收集器中的日志级别

1.4.3. 管理 Operator

1.4.4. ClusterLogForwarder 的结构

1.4.4.1. 输入

1.4.4.2. 输出

1.4.4.3. Pipelines

1.4.4.4. 过滤器

1.4.4.5. 启用多行异常检测

1.4.4.5.1. 详情

1.4.4.6. 配置内容过滤器以丢弃不需要的日志记录

1.4.4.7. API 审计过滤器概述

1.4.4.8. 在输入 ny 过滤应用程序日志，包括标签表达式或匹配的标签键和值

1.4.4.9. 配置内容过滤器以修剪日志记录

1.4.5. 根据源过滤审计和基础架构日志输入

1.4.6. 通过包含或排除命名空间或容器名称，在输入中过滤应用程序日志

1.5. 使用 LokiStack 存储日志

1.5.1. 先决条件

1.5.2. 核心设置和配置

1.5.3. 授权 LokiStack 规则 RBAC 权限

1.5.3.1. 例子

1.5.4. 使用 Loki 创建基于日志的警报规则

1.5.5. 配置 Loki 以容许 memberlist 创建失败

1.5.6. 使用 Loki 启用基于流的保留

1.5.7. Loki pod 放置

1.5.7.1. 增强的可靠性和性能

1.5.7.2. 使用简短的令牌启用对基于云的日志存储的身份验证

1.5.7.3. 配置 Loki 以容忍节点故障

1.5.7.4. 集群重启过程中的 LokiStack 行为

1.5.7.5. 高级部署和可扩展性

1.3.1. 使用 `oc explain` 命令