2.4. 配置日志转发


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

ClusterLogForwarder 的主要功能

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

2.4.1. 设置日志集合

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

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

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

2.4.1.1. 传统服务帐户

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

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

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

$ oc adm policy add-cluster-role-to-user collect-audit-logs system:serviceaccount:openshift-logging:logcollector
Copy to Clipboard Toggle word wrap

2.4.1.2. 创建服务帐户

先决条件

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

步骤

  1. 为收集器创建服务帐户。如果要将日志写入需要令牌进行身份验证的存储,则必须在服务帐户中包含令牌。
  2. 将适当的集群角色绑定到服务帐户:

    绑定命令示例

    $ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
    Copy to Clipboard Toggle word wrap

2.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
Copy to Clipboard Toggle word wrap
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.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
Copy to Clipboard Toggle word wrap
1
rules:指定此 ClusterRole 授予的权限。
2
apiGroups :请参阅与 Loki 日志记录系统相关的 API 组 loki.grafana.com。
3
loki.grafana.com :用于管理 Loki 相关资源的 API 组。
4
resources :ClusterRole 授予权限的用户的资源类型。
5
application: 引用 Loki 日志记录系统中的应用程序资源。
6
resourceNames:指定此角色可以管理的资源的名称。
7
logs :引用可以创建的日志资源。
8
verbs :资源允许的操作。
9
create: 授予在 Loki 系统中创建新日志的权限。
2.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
Copy to Clipboard Toggle word wrap
1
rules:定义此 ClusterRole 授予的权限。
2
apiGroups :指定 API 组 loki.grafana.com。
3
loki.grafana.com :负责 Loki 日志记录资源的 API 组。
4
resources:请参阅此角色管理的资源类型,本例中为 audit。
5
audit:指定角色管理 Loki 中的审计日志。
6
resourceNames :定义角色可访问的特定资源。
7
logs :引用可以由此角色管理的日志。
8
verbs :资源允许的操作。
9
create :授予创建新审计日志的权限。
2.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
Copy to Clipboard Toggle word wrap

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.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
Copy to Clipboard Toggle word wrap
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.4.2. 修改收集器中的日志级别

要修改收集器中的日志级别,您可以将 observability.openshift.io/log-level 注解设置为 tracedebuginfowarnerroroff

日志级别注解示例

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: collector
  annotations:
    observability.openshift.io/log-level: debug
# ...
Copy to Clipboard Toggle word wrap

2.4.3. 管理 Operator

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

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

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

2.4.4. ClusterLogForwarder 的结构

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

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

2.4.4.1. 输入

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

application
从所有应用程序容器中选择日志,不包括基础架构命名空间中的日志。
infrastructure

从节点以及在以下命名空间中运行的基础架构组件中选择日志:

  • default
  • kube
  • openshift
  • 包含 kube-openshift- 前缀
audit
从 OpenShift API 服务器审计日志、Kubernetes API 服务器审计日志、ovn 审计日志和 auditd 的节点审计日志中选择日志。

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

2.4.4.2. 输出

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

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

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

2.4.5. 配置 OTLP 输出

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

重要

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

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

流程

  • 创建或编辑 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
    Copy to Clipboard Toggle word wrap

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

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

2.4.5.1. Pipelines

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

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

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

2.4.5.2. 过滤器

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

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

2.4.6. 启用多行异常检测

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

警告

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

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

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

  • 要启用日志记录来检测多行异常并将其重新编译到单个日志条目中,请确保 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>
Copy to Clipboard Toggle word wrap

2.4.6.1. 详情

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

收集器支持以下语言:

  • Java
  • JS
  • Ruby
  • Python
  • Golang
  • PHP
  • Dart

2.4.7. 通过 HTTP 转发日志

要启用通过 HTTP 转发日志,在 ClusterLogForwarder 自定义资源(CR)中指定 http 作为输出类型。

流程

  • 使用以下模板创建或编辑 ClusterLogForwarder CR:

    ClusterLogForwarder CR 示例

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name>
      namespace: <log_forwarder_namespace>
    spec:
      managementState: Managed
      outputs:
      - name: <output_name>
        type: http
        http:
          headers:  
    1
    
              h1: v1
              h2: v2
          authentication:
            username:
              key: username
              secretName: <http_auth_secret>
            password:
              key: password
              secretName: <http_auth_secret>
          timeout: 300
          proxyURL: <proxy_url> 
    2
    
          url: <url> 
    3
    
        tls:
          insecureSkipVerify: 
    4
    
          ca:
            key: <ca_certificate>
            secretName: <secret_name> 
    5
    
      pipelines:
        - inputRefs:
            - application
          name: pipe1
          outputRefs:
            - <output_name>  
    6
    
      serviceAccount:
        name: <service_account_name> 
    7
    Copy to Clipboard Toggle word wrap

    1
    使用日志记录发送的其他标头。
    2
    可选:应用于通过 http 或 https 转发日志的 HTTP/HTTPS 代理的 URL。此设置覆盖集群或节点的任何默认代理设置。
    3
    日志的目标地址。
    4
    值可以是 truefalse
    5
    目标凭证的 secret 名称。
    6
    这个值应当与输出名称相同。
    7
    服务帐户的名称。

2.4.8. 使用 syslog 协议转发日志

您可以使用 syslog RFC3164RFC5424 协议将日志副本发送到配置为接受该协议的外部日志聚合器,而非默认的 Elasticsearch 日志存储。您需要配置外部日志聚合器(如 syslog 服务器)来接收来自 Red Hat OpenShift Service on AWS 经典架构的日志。

要使用 syslog 协议配置日志转,,请创建一个 ClusterLogForwarder 自定义资源(CR),并将一个或多个输出输出到使用这些输出的 syslog 服务器和管道。syslog 输出可以使用 UDP、TCP 或 TLS 连接。

先决条件

  • 您必须有配置为使用指定协议或格式接收日志数据的日志服务器。

流程

  1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件:

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: collector
    spec:
      managementState: Managed
      outputs:
      - name: rsyslog-east 
    1
    
        syslog:
          appName: <app_name> 
    2
    
          enrichment: KubernetesMinimal
          facility: <facility_value> 
    3
    
          msgId: <message_ID> 
    4
    
          payloadKey: <record_field> 
    5
    
          procId: <process_ID> 
    6
    
          rfc: <RFC3164_or_RFC5424> 
    7
    
          severity: informational 
    8
    
          tuning:
            deliveryMode: <AtLeastOnce_or_AtMostOnce> 
    9
    
          url: <url> 
    10
    
        tls: 
    11
    
          ca:
            key: ca-bundle.crt
            secretName: syslog-secret
        type: syslog
      pipelines:
      - inputRefs: 
    12
    
        - application
        name: syslog-east 
    13
    
        outputRefs:
        - rsyslog-east
      serviceAccount: 
    14
    
        name: logcollector
    Copy to Clipboard Toggle word wrap
    1
    指定输出的名称。
    2
    可选:指定 syslog 消息标头的 APP-NAME 部分的值。该值必须符合 Syslog 协议。该值可以是由字段路径后跟 || 组成的静态和动态值的组合,然后是另一个字段路径或静态值。最终值的最大长度为 48 个字符。您需要使用一个大括号将动态值括起,值必须后跟一个用 || 分隔的静态回退值。静态值只能包含字母数字字符以及短划线、下划线、点和正斜杠。示例值:<value1>-{.<value2>||"none"}。
    3
    可选:指定 syslog-msg 标头的 Facility 部分的值。
    4
    可选:指定 syslog-msg 标头的 MSGID 部分的值。该值可以是由字段路径后跟 || 组成的静态和动态值的组合,然后是另一个字段路径或静态值。最终值的最大长度为 32 个字符。您需要使用一个大括号将动态值括起,值必须后跟一个用 || 分隔的静态回退值。静态值只能包含字母数字字符以及短划线、下划线、点和正斜杠。示例值:<value1>-{.<value2>||"none"}。
    5
    可选:指定用作有效负载的记录字段。payloadKey 值必须是单一字段路径,包括在一个大括号 {} 中。示例:{.<value>}。
    6
    可选:指定 syslog 消息标头的 PROCID 部分的值。该值必须符合 Syslog 协议。该值可以是由字段路径后跟 || 组成的静态和动态值的组合,然后是另一个字段路径或静态值。最终值的最大长度为 48 个字符。您需要使用一个大括号将动态值括起,值必须后跟一个用 || 分隔的静态回退值。静态值只能包含字母数字字符以及短划线、下划线、点和正斜杠。示例值:<value1>-{.<value2>||"none"}。
    7
    可选:设置生成的消息符合的 RFC。该值可以是 RFC3164RFC5424
    8
    可选:为消息设置严重性级别。如需更多信息,请参阅 Syslog 协议
    9
    可选:为日志转发设置交付模式。该值可以是 AtLeastOnce,也可以是 AtMostOnce
    10
    使用方案指定绝对 URL。有效方案是:tcptlsudp。例如:tls://syslog-receiver.example.com:6514
    11
    指定控制传输层安全(TLS)客户端连接的选项的设置。
    12
    使用管道指定要转发的日志类型:applicationinfrastructureaudit
    13
    为管道指定一个名称。
    14
    服务帐户的名称。
  2. 创建 CR 对象:

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

2.4.8.1. 在消息输出中添加日志消息

您可以通过将 enrichment 字段添加到 ClusterLogForwarder 自定义资源(CR),将 namespace_namepod_namecontainer_name 元素添加到记录的 message 字段中。

# ...
  spec:
    outputs:
    - name: syslogout
      syslog:
        enrichment: KubernetesMinimal
        facility: user
        payloadKey: message
        rfc: RFC3164
        severity: debug
      type: syslog
      url: tls://syslog-receiver.example.com:6514
    pipelines:
    - inputRefs:
      - application
      name: test-app
      outputRefs:
      - syslogout
# ...
Copy to Clipboard Toggle word wrap
注意

这个配置与 RFC3164 和 RFC5424 兼容。

带有 enrichment: None 的 syslog 信息输出。

 2025-03-03T11:48:01+00:00  example-worker-x  syslogsyslogserverd846bb9b: {...}
Copy to Clipboard Toggle word wrap

带有 enrichment: KubernetesMinimal 的 syslog 信息输出。

2025-03-03T11:48:01+00:00  example-worker-x  syslogsyslogserverd846bb9b: namespace_name=cakephp-project container_name=mysql pod_name=mysql-1-wr96h,message: {...}
Copy to Clipboard Toggle word wrap

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

流程

  1. 将过滤器的配置添加到 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>"]
    # ...
    Copy to Clipboard Toggle word wrap

    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 路径设置 matchesnotMatches 条件,但不能同时设置这两个条件。
    6
    指定正则表达式。如果日志记录与此正则表达式不匹配,它们将被丢弃。您可以为单个 field 路径设置 matchesnotMatches 条件,但不能同时设置这两个条件。
    7
    指定 drop 过滤器应用到的管道。
  2. 运行以下命令来应用 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

其他示例

下面的额外示例演示了如何将 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"
# ...
Copy to Clipboard Toggle word wrap

除了在单一 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"
# ...
Copy to Clipboard Toggle word wrap

2.4.10. API 审计过滤器概述

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

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

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

通配符
用户、组、命名空间和资源的名称可以在前导或尾部带有 * 星号字符。例如,命名空间 openshift-\* 匹配 openshift-apiserveropenshift-authentication。资源 \*/status 匹配 Pod/statusDeployment/status
默认规则

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

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

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

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

除了 Red Hat OpenShift Service on AWS 经典架构审计策略外,ClusterLogForwarder CR 审计策略还可以正常工作。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
Copy to Clipboard Toggle word wrap

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

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

流程

  1. 将过滤器的配置添加到 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
    # ...
    Copy to Clipboard Toggle word wrap

    1
    指定要匹配的标签键。
    2
    指定 operator。有效值包括: In,NotIn,Exists, 和 DoesNotExist
    3
    指定字符串值的数组。如果 operator 值为 ExistsDoesNotExist,则值数组必须为空。
    4
    指定准确的键或值映射。
  2. 运行以下命令来应用 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

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

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

流程

  1. 将过滤器的配置添加到 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>"]
    # ...
    Copy to Clipboard Toggle word wrap

    1
    指定过滤器的类型。prune 过滤器根据配置的字段修剪日志记录。
    2
    指定应用 prune 过滤器的配置选项。innotIn 字段被指定为点分隔字段路径的数组,它们是日志记录中字段的路径。这些路径可以包含字母数字字符和下划线 (a-zA-Z0-9_),例如 .kubernetes.namespace_name。如果网段包含此范围之外的字符,段必须放在引号内,例如,.kubernetes.labels."foo.bar-bar/baz"
    3
    可选:此阵列中指定的任何字段都会从日志记录中删除。
    4
    可选:没有在此阵列中指定的任何字段都会从日志记录中删除。
    5
    指定 prune 过滤器应用到的管道。
    注意

    过滤器显示 log_type.log_source.message 字段。

  2. 运行以下命令来应用 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

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

您可以使用 input 选择器定义 auditinfrastructure 源列表,以收集日志。

流程

  1. 添加配置,以在 ClusterLogForwarder CR 中定义 auditinfrastructure 源。

    以下示例演示了如何配置 ClusterLogForwarder CR 以定义 auditinfrastructure 源:

    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
    # ...
    Copy to Clipboard Toggle word wrap

    1
    指定要收集的基础架构源列表。有效的源包括:
    • node :来自节点的日志
    • container :命名空间中部署的工作负载的日志
    2
    指定要收集的审计源列表。有效的源包括:
    • kubeAPI: 来自 Kubernetes API 服务器的日志
    • openshiftAPI: 来自 OpenShift API 服务器的日志
    • auditd: 来自节点 auditd 服务的日志
    • ovn :来自开放虚拟网络服务的日志
  2. 运行以下命令来应用 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

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

流程

  1. 添加配置,以在 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
    
          type: application
    # ...
    Copy to Clipboard Toggle word wrap

    1
    指定日志只从这些命名空间中收集数据。
    2
    指定日志只从这些容器中收集数据。
    3
    指定收集日志时要忽略的命名空间模式。
    4
    指定收集日志时要忽略的容器集合。
    注意

    excludes 字段优先于 includes 字段。

  2. 运行以下命令来应用 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat