$ 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
×
配置日志转发
ClusterLogForwarder (CLF) 允许用户配置将日志转发到各种目标。它提供了一种灵活的方式来选择来自不同来源的日志消息，将它们发送到可以转换或过滤它们的管道，并将它们转发到一个或多个输出。
ClusterLogForwarder的关键功能
-
使用输入选择日志消息
-
使用输出将日志转发到外部目标
-
使用过滤器过滤、转换和丢弃日志消息
-
定义连接输入、过滤器和输出的日志转发管道
设置日志收集
此版本的集群日志记录要求管理员显式地向与ClusterLogForwarder关联的服务帐户授予日志收集权限。在以前的版本中，对于由ClusterLogging和（可选）ClusterLogForwarder.logging.openshift.io资源组成的旧版日志记录方案，不需要此权限。
Red Hat OpenShift Logging Operator 提供collect-audit-logs、collect-application-logs和collect-infrastructure-logs集群角色，这些角色分别使收集器能够收集审计日志、应用程序日志和基础设施日志。
通过将所需的集群角色绑定到您的服务帐户来设置日志收集。
旧版服务帐户
要使用现有的旧版服务帐户logcollector，请创建以下ClusterRoleBinding
此外，如果收集审计日志，请创建以下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下的数组中配置。有三种内置输入类型
- application
-
选择来自所有应用程序容器的日志，不包括基础设施命名空间（如
default、openshift或任何以kube-或openshift-为前缀的命名空间）中的日志。 - infrastructure
-
选择来自
default和openshift命名空间中运行的基础设施组件以及节点日志的日志。 - audit
-
选择来自 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 服务器。
每种输出类型都有其自身的配置字段。
配置 OTLP 输出
集群管理员可以使用 OpenTelemetry 协议 (OTLP) 输出收集并将日志转发到 OTLP 接收器。OTLP 输出使用 OpenTelemetry 可观测性框架 定义的规范通过 HTTP 发送 JSON 编码的数据。
|
OpenTelemetry 协议 (OTLP) 输出日志转发器仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能，使客户能够在开发过程中测试功能并提供反馈。 有关 Red Hat 技术预览功能的支持范围的更多信息，请参阅 技术预览功能支持范围。 |
步骤
-
创建或编辑
ClusterLogForwarder自定义资源 (CR)，通过添加以下注释来启用使用 OTLP 进行转发ClusterLogForwarderCR 示例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: - otlp1 使用此注释启用 OpenTelemetry 协议 (OTLP) 输出，这是一个技术预览功能。 2 此 URL 必须是绝对 URL，它是发送日志的 OTLP 端点的占位符。
|
OTLP 输出使用 OpenTelemetry 数据模型，这与其他输出类型使用的 ViaQ 数据模型不同。它遵循使用 OpenTelemetry 语义约定 的 OTLP，由 OpenTelemetry 可观测性框架定义。 |
管道
管道在 spec.pipelines 下的数组中配置。每个管道必须具有唯一的名称，并且包含
- inputRefs
-
应将日志转发到此管道的输入的名称。
- outputRefs
-
要将日志发送到的输出的名称。
- filterRefs
-
(可选) 要应用的过滤器的名称。
filterRefs 的顺序很重要，因为它们是顺序应用的。较早的过滤器可能会丢弃不会被后续过滤器处理的消息。
启用多行异常检测
启用容器日志的多行错误检测。
|
启用此功能可能会影响性能，可能需要额外的计算资源或替代日志记录解决方案。 |
日志解析器通常会错误地将同一异常的单独行识别为单独的异常。这会导致额外的日志条目以及跟踪信息的视图不完整或不准确。
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>配置内容过滤器以丢弃不需要的日志记录
配置 drop 过滤器后，日志收集器会在转发之前根据过滤器评估日志流。收集器会丢弃与指定配置匹配的不需要的日志记录。
步骤
-
向
ClusterLogForwarderCR 中的filtersspec 添加过滤器的配置。以下示例显示如何配置
ClusterLogForwarderCR 以基于正则表达式丢弃日志记录ClusterLogForwarderCR 示例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过滤器配置指定多个测试时，如果任何测试通过，则记录被丢弃。 -
如果评估条件时出错，例如，日志记录中缺少该字段，则该条件将评估为假。
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过滤器的管道。 -
-
运行以下命令应用
ClusterLogForwarderCR$ 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）将被丢弃。 -
在与服务帐户相同命名空间中发生的 Service Account 写入事件将被丢弃。
-
所有其他事件都将转发，但会受到任何已配置速率限制的影响。
-
要禁用这些默认设置，请使用仅包含level 字段的规则结束规则列表，或添加一个空规则。
- 忽略响应代码
-
要忽略的整数状态码列表。您可以使用
OmitResponseCodes字段（列出不创建事件的 HTTP 状态码）根据响应中的 HTTP 状态码丢弃事件。默认值为[404, 409, 422, 429]。如果值为一个空列表[]，则不忽略任何状态码。
ClusterLogForwarder CR 审计策略附加于 OpenShift Container Platform 审计策略。ClusterLogForwarder CR 审计过滤器会更改日志收集器转发的对象，并提供按动词、用户、组、命名空间或资源进行过滤的功能。您可以创建多个过滤器，将同一审计流的不同摘要发送到不同位置。例如，您可以将详细的流发送到本地集群日志存储，并将不太详细的流发送到远程站点。
|
您必须拥有集群角色 |
审计策略示例
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 选择器基于标签表达式或匹配的标签键及其值包含应用程序日志。
步骤
-
向
ClusterLogForwarderCR 中的input规范添加过滤器的配置。以下示例演示如何配置
ClusterLogForwarderCR 以基于标签表达式或匹配的标签键/值包含日志：ClusterLogForwarderCR 示例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 指定精确的键值映射。 -
运行以下命令应用
ClusterLogForwarderCR$ oc apply -f <filename>.yaml
配置内容过滤器以修剪日志记录
配置prune 过滤器后，日志收集器会在转发之前根据过滤器评估日志流。收集器通过删除 pod 注释等低价值字段来修剪日志记录。
步骤
-
向
ClusterLogForwarderCR 中的prune规范添加过滤器的配置。以下示例演示如何配置
ClusterLogForwarderCR 以基于字段路径修剪日志记录：如果两者都指定，则首先基于
notIn数组修剪记录，notIn数组优先于in数组。使用notIn数组修剪记录后，再使用in数组修剪记录。ClusterLogForwarderCR 示例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字段。 -
运行以下命令应用
ClusterLogForwarderCR$ oc apply -f <filename>.yaml
按来源过滤审计和基础设施日志输入
您可以使用input 选择器定义要收集日志的audit 和infrastructure 源列表。
步骤
-
添加配置以在
ClusterLogForwarderCR 中定义audit和infrastructure源。以下示例演示如何配置
ClusterLogForwarderCR 以定义audit和infrastructure源：ClusterLogForwarderCR 示例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：来自开放虚拟网络服务的日志。
-
-
运行以下命令应用
ClusterLogForwarderCR$ oc apply -f <filename>.yaml
通过包含或排除命名空间或容器名称来过滤输入处的应用程序日志
您可以使用input 选择器基于命名空间和容器名称包含或排除应用程序日志。
步骤
-
添加配置以在
ClusterLogForwarderCR 中包含或排除命名空间和容器名称。以下示例演示如何配置
ClusterLogForwarderCR 以包含或排除命名空间和容器名称：ClusterLogForwarderCR 示例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字段。 -
运行以下命令应用
ClusterLogForwarderCR$ oc apply -f <filename>.yaml