配置日志转发 - 日志记录 | 可观测性 | OpenShift Container Platform 4.17

设置日志收集
- 旧版服务帐户
- 创建服务帐户
修改收集器中的日志级别
管理 Operator
ClusterLogForwarder 的结构
按来源过滤审计和基础设施日志输入
通过包含或排除命名空间或容器名称来过滤输入处的应用程序日志

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

ClusterLogForwarder 的关键功能

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

设置日志收集

此版本的 Cluster Logging 要求管理员显式地向与 ClusterLogForwarder 关联的服务帐户授予日志收集权限。在以前的版本中，对于由 ClusterLogging 和（可选）ClusterLogForwarder.logging.openshift.io 资源组成的旧版日志记录场景，不需要此权限。

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

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

旧版服务帐户

要使用现有的旧版服务帐户 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

创建服务帐户

先决条件

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>

您的服务帐户的集群角色绑定

role_binding.yaml 文件将 ClusterLogging 运算符的 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 所在的命名空间。

写入应用程序日志

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.

写入审计日志

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	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：授予创建新审计日志的权限。

写入基础架构日志

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 系统中创建基础架构日志的权限。

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 组。
4	resources：指定此角色可以管理的资源。
5	clusterlogforwarders：指 OpenShift 中的日志转发资源。
6	verbs：指定在 ClusterLogForwarders 上允许的操作。
7	create：授予创建新的 ClusterLogForwarders 的权限。
8	delete：授予删除现有 ClusterLogForwarders 的权限。
9	get：授予检索有关特定 ClusterLogForwarders 的信息的权限。
10	list：允许列出所有 ClusterLogForwarders。
11	patch：授予部分修改 ClusterLogForwarders 的权限。
12	update：授予更新现有 ClusterLogForwarders 的权限。
13	watch：授予监视 ClusterLogForwarders 更改的权限。

修改收集器中的日志级别

要修改收集器中的日志级别，可以将 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
# ...

管理运算符

ClusterLogForwarder 资源具有一个 managementState 字段，该字段控制运算符是否主动管理其资源或将其保留为 Unmanaged

Managed: （默认）运算符将驱动日志记录资源以匹配 CLF 规范中的所需状态。
Unmanaged: 运算符不会对日志记录组件采取任何操作。

这允许管理员通过将 managementState 设置为 Unmanaged 来暂时暂停日志转发。

ClusterLogForwarder 的结构

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

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

输入

输入在 spec.inputs 下的数组中配置。有三种内置输入类型

应用: 选择所有应用程序容器的日志，但不包括基础设施命名空间中的日志，例如default、openshift，或任何以kube-或openshift-为前缀的命名空间。
基础设施: 选择在default和openshift命名空间中运行的基础设施组件的日志以及节点日志。
审计: 选择OpenShift API服务器审计日志、Kubernetes API服务器审计日志、OVN审计日志以及来自auditd的节点审计日志。

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

输出

输出在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服务器。

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

管道

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

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

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

过滤器

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

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

启用多行异常检测

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

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

日志解析器通常会错误地将同一异常的单独行识别为单独的异常。这会导致额外的日志条目，以及对跟踪信息的查看不完整或不准确。

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>

详情

当日志消息显示为形成异常堆栈跟踪的连续序列时，它们将组合成单个统一的日志记录。第一个日志消息的内容将被序列中所有消息字段的串联内容替换。

收集器支持以下语言：

Java
JS
Ruby
Python
Golang
PHP
Dart

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

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

步骤

向ClusterLogForwarder CR中的filters规范添加过滤器的配置。

以下示例显示如何配置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	指定用于评估是否丢弃日志记录的测试的配置。如果为测试指定的全部条件都为真，则测试通过，并丢弃日志记录。当为`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配置，两个字段规范都必须为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"
# ...

API审计过滤器的概述

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

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

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

通配符

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

默认规则

策略中不匹配任何规则的事件将按如下方式过滤：

读取系统事件（例如 get、list 和 watch）将被丢弃。
在与服务帐户相同的命名空间中发生的的服务帐户写入事件将被丢弃。
所有其他事件都将转发，但要遵守任何已配置的速率限制。

要禁用这些默认设置，请使用仅包含level 字段的规则结束规则列表，或添加空规则。

忽略响应代码: 要忽略的整数状态代码列表。您可以使用OmitResponseCodes 字段根据响应中的 HTTP 状态代码丢弃事件，该字段列出了不创建事件的 HTTP 状态代码。默认值为[404, 409, 422, 429]。如果该值为一个空列表[]，则不忽略任何状态代码。

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

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

示例审计策略

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	审计策略的名称。

通过包含标签表达式或匹配的标签键和值来过滤输入处的应用程序日志

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

步骤

向ClusterLogForwarder CR 中的input规范添加过滤器的配置。

以下示例显示如何配置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	指定运算符。有效值包括：`In`、`NotIn`、`Exists` 和 `DoesNotExist`。
3	指定字符串值数组。如果`operator`值为`Exists`或`DoesNotExist`，则值数组必须为空。
4	指定精确的键值映射。

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

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

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

步骤

向ClusterLogForwarder CR 中的prune规范添加过滤器的配置。

以下示例显示如何配置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
```

按来源过滤审计和基础设施日志输入

您可以使用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
```

通过包含或排除命名空间或容器名称来过滤输入处的应用程序日志

您可以使用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)
      type: application
# ...

1	指定仅从这些命名空间收集日志。
2	指定仅从这些容器收集日志。
3	指定收集日志时要忽略的命名空间模式。
4	指定收集日志时要忽略的容器集。

excludes 字段优先于 includes 字段。

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