第 11 章 日志收集和转发
11.1. 关于日志收集和转发
Cluster Logging Operator 根据 ClusterLogForwarder
资源规格部署收集器。此 Operator 支持两个收集器选项:旧的 Fluentd 收集器和 Vector 收集器。
从日志记录版本 5.6 Fluentd 开始,计划在以后的发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序漏洞修复和支持,但这个功能将不再获得改进,并将被删除。作为 Fluentd 的替代选择,您可以使用 Vector。
11.1.1. 日志集合
日志收集器是一个守护进程集,它将 Pod 部署到每个 Red Hat OpenShift Service on AWS 节点,以收集容器和节点日志。
默认情况下,日志收集器使用以下源:
- 由来自操作系统、容器运行时和 Red Hat OpenShift Service on AWS 的 journald 日志消息生成的系统和基础架构日志。
-
/var/log/containers 3.11..log
用于所有容器日志。
如果您将日志收集器配置为收集审计日志,它会从 /var/log/audit/audit.log
收集它们。
日志收集器从这些源收集日志,并根据日志记录子系统配置在内部或外部转发它们。
11.1.1.1. 日志收集器类型
Vector 是一个日志收集器,作为日志记录子系统的 Fluentd 的一个替代方案。
您可以通过修改 ClusterLogging
自定义资源(CR) 集合
规格来配置集群使用的日志记录收集器类型:
将 Vector 配置为收集器的 ClusterLogging CR 示例
apiVersion: "logging.openshift.io/v1" kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: vector vector: {} # ...
11.1.1.2. 日志收集限制
容器运行时提供少许信息来标识日志消息的来源,如项目、容器名称和容器 ID。这些信息不足以区分日志的来源。如果在日志收集器开始处理日志之前删除了具有指定名称和项目的 Pod,则来自 API 服务器的信息(如标签和注解)可能会不可用。可能没有办法区分来自名称相似的 Pod 和项目的日志消息,也无法追溯日志的来源。这种限制意味着日志收集和规范化被视为 最佳工作。
可用的容器运行时提供少许信息来标识日志消息来源,无法确保唯一的个别日志消息,也不能保证可以追溯这些消息的来源。
11.1.1.3. 按类型划分的日志收集器功能
功能 | Fluentd | Vector |
---|---|---|
应用程序容器日志 | ✓ | ✓ |
特定于应用程序的路由 | ✓ | ✓ |
命名空间划分应用程序特定路由 | ✓ | ✓ |
Infra 容器日志 | ✓ | ✓ |
Infra 日志 | ✓ | ✓ |
kube API 审计日志 | ✓ | ✓ |
OpenShift API 审计日志 | ✓ | ✓ |
打开虚拟网络 (OVN) 审计日志 | ✓ | ✓ |
功能 | Fluentd | Vector |
---|---|---|
Elasticsearch 证书 | ✓ | ✓ |
Elasticsearch 用户名/密码 | ✓ | ✓ |
Cloudwatch keys | ✓ | ✓ |
Cloudwatch STS | ✓ | ✓ |
Kafka 证书 | ✓ | ✓ |
Kafka 用户名/密码 | ✓ | ✓ |
Kafka SASL | ✓ | ✓ |
Loki bearer 令牌 | ✓ | ✓ |
功能 | Fluentd | Vector |
---|---|---|
ViaQ 数据模型 - 应用程序 | ✓ | ✓ |
ViaQ 数据模型 - infra | ✓ | ✓ |
ViaQ 数据模型 - infra(journal) | ✓ | ✓ |
ViaQ 数据模型 - Linux 审计 | ✓ | ✓ |
ViaQ 数据模型 - kube-apiserver 审计 | ✓ | ✓ |
ViaQ 数据模型 - OpenShift API 审计 | ✓ | ✓ |
ViaQ 数据模型 - OVN | ✓ | ✓ |
loglevel Normalization | ✓ | ✓ |
JSON 解析 | ✓ | ✓ |
结构化索引 | ✓ | ✓ |
多行错误检测 | ✓ | ✓ |
multicontainer/ split 索引 | ✓ | ✓ |
Flatten 标签 | ✓ | ✓ |
CLF 静态标签 | ✓ | ✓ |
功能 | Fluentd | Vector |
---|---|---|
Fluentd readlinelimit | ✓ | |
Fluentd 缓冲 | ✓ | |
- chunklimitsize | ✓ | |
- totallimitsize | ✓ | |
- overflowaction | ✓ | |
- flushthreadcount | ✓ | |
- flushmode | ✓ | |
- flushinterval | ✓ | |
- retrywait | ✓ | |
- retrytype | ✓ | |
- retrymaxinterval | ✓ | |
- retrytimeout | ✓ |
功能 | Fluentd | Vector |
---|---|---|
指标 | ✓ | ✓ |
Dashboard | ✓ | ✓ |
警报 | ✓ |
功能 | Fluentd | Vector |
---|---|---|
全局代理支持 | ✓ | ✓ |
x86 支持 | ✓ | ✓ |
ARM 支持 | ✓ | ✓ |
IBM Power 支持 | ✓ | ✓ |
IBM Z 支持 | ✓ | ✓ |
IPv6 支持 | ✓ | ✓ |
日志事件缓冲 | ✓ | |
断开连接的集群 | ✓ | ✓ |
11.1.1.4. 收集器输出
支持以下收集器输出:
功能 | Fluentd | Vector |
---|---|---|
Elasticsearch v6-v8 | ✓ | ✓ |
Fluent 转发 | ✓ | |
Syslog RFC3164 | ✓ | IANA (logging 5.7+) |
Syslog RFC5424 | ✓ | IANA (logging 5.7+) |
Kafka | ✓ | ✓ |
Cloudwatch | ✓ | ✓ |
Cloudwatch STS | ✓ | ✓ |
Loki | ✓ | ✓ |
HTTP | ✓ | IANA (logging 5.7+) |
Google Cloud Logging | ✓ | ✓ |
Splunk | iwl (logging 5.6+) |
11.1.2. 日志转发
管理员可以创建 ClusterLogForwarder
资源,以指定要收集哪些日志、它们的转换方式以及它们被转发到的位置。
ClusterLogForwarder
资源可用于将容器、基础架构和审计日志转发到集群内部或外部的特定端点。支持传输层安全性(TLS),以便可以配置日志转发来安全地发送日志。
管理员也可以授权 RBAC 权限来定义哪些服务帐户和用户可以访问和转发哪些日志类型。
11.1.3. 日志转发实现
可用的日志转发实现有两个:旧的实现和多日志转发器功能。
仅支持 Vector 收集器与多日志转发器功能一起使用。Fluentd 收集器只能用于旧的实现。
11.1.3.1. 旧实施
在旧的实现中,集群中只能使用一个日志转发器。此模式的 ClusterLogForwarder
资源必须命名为 instance
,且必须在 openshift-logging
命名空间中创建。ClusterLogForwarder
资源还需要 openshift-logging
命名空间中名为 instance
的对应 ClusterLogging
资源。
11.1.3.2. 多日志转发器功能
日志记录 5.8 及更高版本中提供了多日志转发器功能,并提供以下功能:
- 管理员可以控制哪些用户被允许定义日志收集以及允许收集哪些日志。
- 具有所需权限的用户可以指定额外的日志收集配置。
- 从已弃用的 Fluentd 收集器迁移到 Vector 收集器的管理员可以独立于现有部署部署新的日志转发程序。在迁移工作负载时,现有和新的日志转发程序可以同时运行。
在多日志转发器实现中,您不需要为 ClusterLogForwarder
资源创建对应的 ClusterLogging
资源。您可以使用任何命名空间中的任何名称创建多个 ClusterLogForwarder
资源,但以下例外:
-
您无法在
openshift-logging
命名空间中创建一个名为instance
的ClusterLogForwarder
资源,因为它为支持使用 Fluentd 收集器的传统工作流的日志转发器保留。 -
您无法在
openshift-logging
命名空间中创建一个名为collector
的ClusterLogForwarder
资源,因为这为收集器保留。
11.1.4. 为集群启用多日志转发器功能
要使用多日志转发器功能,您必须为该服务帐户创建服务帐户和集群角色绑定。然后,您可以在 ClusterLogForwarder
资源中引用服务帐户来控制访问权限。
要在 openshift-logging
命名空间以外的额外命名空间中支持多日志转发,您必须更新 Cluster Logging Operator 以监视所有命名空间。新的 Cluster Logging Operator 版本 5.8 版本中默认支持此功能。
11.1.4.1. 授权日志收集 RBAC 权限
在日志记录 5.8 及更高版本中,Cluster Logging Operator 提供了 collect-audit-logs
、collect-application-logs
和 collect-infrastructure-logs
集群角色,使收集器能够分别收集审计日志、应用程序日志和基础架构日志。
您可以通过将所需的集群角色绑定到服务帐户来授权日志收集的 RBAC 权限。
先决条件
-
Cluster Logging Operator 安装在
openshift-logging
命名空间中。 - 有管理员权限。
流程
- 为收集器创建服务帐户。如果要将日志写入需要令牌进行身份验证的存储,则必须在服务帐户中包含令牌。
将适当的集群角色绑定到服务帐户:
绑定命令示例
$ oc adm policy add-cluster-role-to-user <cluster_role_name> - system:serviceaccount::<namespace_name>:<service_account_name>
11.1.5. 创建日志转发器
要创建日志转发器,您必须创建一个 ClusterLogForwarder
CR,以指定服务帐户可以收集的日志输入类型。您还可以指定日志可以转发到的输出。如果使用多日志转发器功能,还必须在 ClusterLogForwarder
CR 中引用服务帐户。
如果您在集群中使用多日志转发器功能,您可以使用任何名称在任意命名空间中创建 ClusterLogForwarder
自定义资源(CR)。如果使用旧的实现,ClusterLogForwarder
CR 必须命名为 instance
,且必须在 openshift-logging
命名空间中创建。
创建 ClusterLogForwarder
CR 的命名空间需要管理员权限。
ClusterLogForwarder 资源示例
apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: <log_forwarder_name> 1 namespace: <log_forwarder_namespace> 2 spec: serviceAccount: <service_account_name> 3 pipelines: - inputRefs: - <log_type> 4 outputRefs: - <output_name> 5 outputs: - name: <output_name> 6 type: <output_type> 7 url: <log_output_url> 8 # ...
- 1
- 在传统的实现中,CR 名称必须是
实例
。在多日志转发器实现中,您可以使用任何名称。 - 2
- 在旧的实现中,CR 命名空间必须是
openshift-logging
。在多日志转发器实现中,您可以使用任何命名空间。 - 3
- 服务帐户的名称。服务帐户只需要在多日志转发器实现中。
- 4
- 收集的日志类型。此字段的值可以是
audit
(用于审计日志)、application
(用于应用程序日志)、infrastructure
(用于基础架构日志),或输入为您的应用程序定义的名称。 - 5 7
- 要将日志转发到的输出类型。此字段的值可以是
default
,loki
,kafka
,elasticsearch
,fluentdForward
,syslog
, 或cloudwatch
。注意mutli 日志转发器实现不支持
默认
输出类型。 - 6
- 要将日志转发到的输出的名称。
- 8
- 要将日志转发到的输出的 URL。
11.1.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)
-
要启用日志记录来检测多行异常,并将其重新编译到一个日志条目中,请确保
ClusterLogForwarder
自定义资源(CR)包含detectMultilineErrors
字段,值为true
。
ClusterLogForwarder CR 示例
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: pipelines: - name: my-app-logs inputRefs: - application outputRefs: - default detectMultilineErrors: true
11.1.6.1. 详情
当日志消息作为一系列针对一个例外的信息出现时,会将它们合并到一个统一的日志记录中。第一个日志消息的内容被替换为序列中所有消息字段的连接内容。
语言 | Fluentd | Vector |
---|---|---|
Java | ✓ | ✓ |
JS | ✓ | ✓ |
Ruby | ✓ | ✓ |
Python | ✓ | ✓ |
Golang | ✓ | ✓ |
PHP | ✓ | |
Dart | ✓ | ✓ |
11.1.6.2. 故障排除
启用后,收集器配置将包括一个新的部分,类型是:detect_exceptions
vector 配置部分的示例
[transforms.detect_exceptions_app-logs] type = "detect_exceptions" inputs = ["application"] languages = ["All"] group_by = ["kubernetes.namespace_name","kubernetes.pod_name","kubernetes.container_name"] expire_after_ms = 2000 multiline_flush_interval_ms = 1000
fluentd config 部分的示例
<label @MULTILINE_APP_LOGS> <match kubernetes.**> @type detect_exceptions remove_tag_prefix 'kubernetes' message message force_line_breaks true multiline_flush_interval .2 </match> </label>
11.1.7. 将审计日志发送到内部日志存储
默认情况下,日志记录子系统会将容器和基础架构日志发送到 ClusterLogging
自定义资源中定义的默认内部日志存储。但是,它不会将审计日志发送到内部存储,因为它不提供安全存储。如果此默认配置满足您的需要,则不需要配置 Cluster Log Forwarder。
要将审计日志发送到内部 Elasticsearch 日志存储,请使用 Cluster Log Forwarder,如 将审计日志转发到日志存储 中所述。
11.1.8. 关于将日志转发到第三方系统
要将日志发送到 Red Hat OpenShift Service on AWS 集群内部和外部的特定端点,您可以在 ClusterLogForwarder
自定义资源(CR)中指定 outputs 和 pipelines 的组合。您还可以使用 输入 将与特定项目关联的应用程序日志转发到端点。身份验证由 Kubernetes Secret 对象提供。
- output
您定义的日志数据的目的地,或者您希望发送日志的位置。输出可以是以下类型之一:
-
elasticsearch
.一个外部 Elasticsearch 实例。elasticsearch
输出可以使用 TLS 连接。 -
fluentdForward
。一个支持 Fluentd 的外部日志聚合解决方案。这个选项使用 Fluentd 转发协议。fluentForward
输出可以使用 TCP 或 TLS 连接,并通过在 secret 中提供一个 shared_key 字段来支持共享密钥身份验证。共享密钥身份验证可在使用或不使用 TLS 的情况下使用。 -
syslog
。支持 syslog RFC3164 或 RFC5424 协议的外部日志聚合解决方案。syslog
输出可以使用 UDP、TCP 或 TLS 连接。 -
cloudwatch
。Amazon CloudWatch,一种由 Amazon Web Services (AWS) 托管的监控和日志存储服务。 -
loki
。Loki,一个可横向扩展的、高可用性、多租户日志聚合系统。 -
kafka
.Kafka 代理。kafka
输出可以使用 TCP 或 TLS 连接。 -
default
.内部 Red Hat OpenShift Service on AWS Elasticsearch 实例。您不需要配置默认输出。如果配置default
输出,您会收到出错信息,因为 Red Hat OpenShift Logging Operator 保留了default
输出。
-
- pipeline
定义从一个日志类型到一个或多个输出的简单路由,或定义您要发送的日志。日志类型是以下之一:
-
application
.由集群中运行的用户应用程序生成的容器日志(基础架构容器应用程序除外)。 -
infrastructure
.在openshift*
、kube*
或default
项目中运行的容器日志,以及来源于节点文件系统的 journal 日志。 -
audit
.由节点审计系统、auditd
、Kubernetes API 服务器、OpenShift API 服务器和 OVN 网络生成的审计日志。
您可以使用管道中的
key:value
对为出站日志消息添加标签。例如,您可以在转发给其他数据中心的消息中添加一个标签,或者根据类型为日志添加标签。添加到对象的标签也会通过日志消息转发。-
- 输入
将与特定项目关联的应用程序日志转发到管道。
在管道中,您要定义使用
inputRef
参数转发哪些日志类型,以及将日志转发到使用outputRef
参数的位置。- Secret
-
包含机密数据的
key:value 映射
,如用户凭据。
注意以下几点:
-
如果
ClusterLogForwarder
CR 对象存在,日志不会转发到默认的 Elasticsearch 实例,除非有带有default
输出的管道。 -
默认情况下,logging 子系统将容器和基础架构日志发送到
ClusterLogging
自定义资源中定义的默认内部 Elasticsearch 日志存储。但是,它不会将审计日志发送到内部存储,因为它不提供安全存储。如果此默认配置满足您的需要,则不需要配置 Log Forwarding API。 -
如果您没有为日志类型定义管道,则将丢弃未定义类型的日志。例如,如果您为
application
和audit
类型指定管道,但没有为infrastructure
类型指定管道,则infrastructure
日志会丢弃。 -
您可以使用
ClusterLogForwarder
自定义资源(CR)中的多种输出类型将日志发送到支持不同协议的服务器。 - 内部 Red Hat OpenShift Service on AWS Elasticsearch 实例不会为审计日志提供安全存储。您需要自己确保转发审计日志的系统符合您所在机构及政府的相关要求,并具有适当的安全性。logging 子系统不遵循这些规范。
以下示例将审计日志转发到安全的外部 Elasticsearch 实例,基础架构日志发送到不安全的外部 Elasticsearch 实例,应用程序日志发送到 Kafka 代理,以及 my-apps-logs
项目中的应用程序日志发送到内部 Elasticsearch 实例。
日志转发输出和管道示例
apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: elasticsearch-secure 3 type: "elasticsearch" url: https://elasticsearch.secure.com:9200 secret: name: elasticsearch - name: elasticsearch-insecure 4 type: "elasticsearch" url: http://elasticsearch.insecure.com:9200 - name: kafka-app 5 type: "kafka" url: tls://kafka.secure.com:9093/app-topic inputs: 6 - name: my-app-logs application: namespaces: - my-project pipelines: - name: audit-logs 7 inputRefs: - audit outputRefs: - elasticsearch-secure - default labels: secure: "true" 8 datacenter: "east" - name: infrastructure-logs 9 inputRefs: - infrastructure outputRefs: - elasticsearch-insecure labels: datacenter: "west" - name: my-app 10 inputRefs: - my-app-logs outputRefs: - default - inputRefs: 11 - application outputRefs: - kafka-app labels: datacenter: "south"
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 使用带有安全 URL 的 secret 来配置安全 Elasticsearch 输出。
- 描述输出的名称。
-
输出类型:
elasticsearch
。 - Elasticsearch 实例的安全 URL 和端口作为有效的绝对 URL,包括前缀。
-
用于 TLS 通信的端点所需的 secret。secret 必须存在于
openshift-logging
项目中。
- 4
- 配置不安全的 Elasticsearch 输出:
- 描述输出的名称。
-
输出类型:
elasticsearch
。 - Elasticsearch 实例的不安全 URL 和端口作为有效的绝对 URL,包括前缀。
- 5
- 使用客户端验证的 TLS 通信通过安全 URL 配置 Kafka 输出
- 描述输出的名称。
-
输出的类型:
kafka
。 - 将 Kafka 代理的 URL 和端口指定为一个有效的绝对 URL,包括前缀。
- 6
- 用于过滤
my-project
命名空间中的应用程序日志的输入配置。 - 7
- 用于将审计日志发送到安全的外部 Elasticsearch 实例的管道配置:
- 描述管道的名称。
-
inputRefs
是日志类型,在这个示例中是audit
。 -
outputRefs
是输出使用的名称,在本例中,elasticsearch-secure
可以转发到安全的 Elasticsearch 实例,default
转发到内部 Elasticsearch 实例。 - 可选:添加到日志的标签。
- 8
- 可选:字符串。要添加到日志中的一个或多个标签。对值加引号(如 "true"),以便它们被识别为字符串值,而不是作为布尔值。
- 9
- 管道配置,将基础架构日志发送到不安全的外部 Elasticsearch 实例。
- 10
- 管道配置,用于将日志从
my-project
项目发送到内部 Elasticsearch 实例。- 描述管道的名称。
-
inputRefs
是一个特定的输入:my-app-logs
。 -
outputRefs
是default
。 - 可选:字符串。要添加到日志中的一个或多个标签。
- 11
- 将日志发送到 Kafka 代理的管道配置,不带有管道名称:
-
inputRefs
是日志类型,在这个示例中是application
。 -
outputRefs
是要使用的输出名称。 - 可选:字符串。要添加到日志中的一个或多个标签。
-
当外部日志聚合器不可用时,Fluentd 日志处理
如果外部日志记录聚合器不可用且无法接收日志,Fluentd 会继续收集日志并将其存储在缓冲中。当日志聚合器可用时,日志转发会恢复,包括缓冲的日志。如果缓冲区已满,Fluentd 会停止收集日志。Red Hat OpenShift Service on AWS 轮转日志并删除它们。您无法调整缓冲区大小,或者将持久性卷声明(PVC)添加到 Fluentd 守护进程集或 Pod 中。
支持的授权密钥
这里提供了常见的密钥类型。某些输出类型支持额外的专用密钥,记录在特定于输出的配置字段中。所有 secret 密钥都是可选的。通过设置相关密钥来启用您想要的安全功能。您需要创建并维护外部目的地可能需要的额外配置,如密钥和 secret 、服务帐户、端口打开或全局代理服务器配置。Open Shift Logging 不会尝试验证授权组合间的不匹配。
- 传输层安全性(TLS)
使用没有 Secret 的 TLS URL('http://…' 或 'ssl://…')启用基本的 TLS 服务器端身份验证。可通过包含 Secret 并设置以下可选字段来启用额外的 TLS 功能:
-
tls.crt
: (字符串)包含客户端证书的文件名。启用 mutual 身份验证。需要tls.key
。 -
tls.key
:(字符串)包含私钥的文件名,用于解锁客户端证书。需要tls.crt
。 -
密码短语
:(字符串)对编码的 TLS 私钥进行解码。需要tls.key
。 -
ca-bundle.crt
: (字符串)用于服务器身份验证的客户 CA 的文件名。
-
- 用户名和密码
-
username
:(字符串)身份验证用户名。需要password
。 -
password
:(字符串)身份验证密码。需要username
。
-
- 简单身份验证安全层(SASL)
-
sasl.enable
(布尔值)明确指定启用或禁用 SASL。如果缺失,则设置了任何其他sasl.
密钥时自动启用 SASL。 -
sasl.mechanisms
:(array)允许的 SASL 机制名称列表。如果缺少或为空,则使用系统默认值。 -
sasl.allow-insecure
:(布尔值)允许发送明文密码的机制。默认为false。
-
11.1.8.1. 创建 Secret
您可以使用以下命令在包含您的证书和密钥文件的目录中创建 secret:
$ oc create secret generic -n openshift-logging <my-secret> \ --from-file=tls.key=<your_key_file> --from-file=tls.crt=<your_crt_file> --from-file=ca-bundle.crt=<your_bundle_file> --from-literal=username=<your_username> --from-literal=password=<your_password>
建议使用通用或不透明 secret 来获得最佳结果。
11.1.9. 将同一 pod 中的容器的 JSON 日志转发到单独的索引
您可以将来自同一 pod 的不同容器的结构化日志转发到不同的索引。要使用此功能,您必须使用多容器支持配置管道并注解 pod。日志被写入带有 app-
前缀的索引。建议将 Elasticsearch 配置为使用别名来容纳此目的。
日志的 JSON 格式化因应用程序而异。因为创建太多索引会影响性能,所以请限制使用此功能,仅对与 JSON 格式不兼容的日志创建索引。使用查询将日志与不同命名空间分离,或使用兼容 JSON 格式的应用程序进行隔离。
先决条件
- Logging subsystem for Red Hat OpenShift: 5.5
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件:apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputDefaults: elasticsearch: structuredTypeKey: kubernetes.labels.logFormat 1 structuredTypeName: nologformat enableStructuredContainerLogs: true 2 pipelines: - inputRefs: - application name: application-logs outputRefs: - default parse: json
创建或编辑定义
Pod
CR 对象的 YAML 文件:apiVersion: v1 kind: Pod metadata: annotations: containerType.logging.openshift.io/heavy: heavy 1 containerType.logging.openshift.io/low: low spec: containers: - name: heavy 2 image: heavyimage - name: low image: lowimage
此配置可能会显著增加集群中的分片数量。
其它资源
11.1.10. 将日志转发到外部 Elasticsearch 实例
除了内部 Red Hat OpenShift Service on AWS Elasticsearch 实例外,您还可以将日志转发到外部 Elasticsearch 实例。您需要配置外部日志聚合器,以接收来自 Red Hat OpenShift Service on AWS 的日志数据。
要配置日志转发到外部 Elasticsearch 实例,请创建一个 ClusterLogForwarder
自定义资源(CR),其中包含输出到该实例的输出以及使用输出的管道。外部 Elasticsearch 输出可以使用 HTTP(不安全)或 HTTPS(安全 HTTP)连接。
要将日志转发到外部和内部 Elasticsearch 实例,请将输出和管道创建到外部实例,以及一个使用 default
输出将日志转发到内部实例的管道。您不需要创建 default
输出。如果配置 default
输出,您会收到出错信息,因为 Red Hat OpenShift Logging Operator 保留了 default
输出。
如果您只 希望将日志转发到 AWS Elasticsearch 实例的内部 Red Hat OpenShift Service,则不需要创建一个 ClusterLogForwarder
CR。
先决条件
- 您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件:apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: elasticsearch-insecure 3 type: "elasticsearch" 4 url: http://elasticsearch.insecure.com:9200 5 - name: elasticsearch-secure type: "elasticsearch" url: https://elasticsearch.secure.com:9200 6 secret: name: es-secret 7 pipelines: - name: application-logs 8 inputRefs: 9 - application - audit outputRefs: - elasticsearch-secure 10 - default 11 labels: myLabel: "myValue" 12 - name: infrastructure-audit-logs 13 inputRefs: - infrastructure outputRefs: - elasticsearch-insecure labels: logs: "audit-infra"
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 指定
elasticsearch
类型。 - 5
- 指定外部 Elasticsearch 实例的 URL 和端口作为有效的绝对 URL。您可以使用
http
(不安全)或https
(安全 HTTP)协议。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。 - 6
- 对于安全连接,您可以通过指定
secret
来指定您进行身份验证的https
或http
URL。 - 7
- 对于
https
前缀,请指定 TLS 通信端点所需的 secret 名称。secret 必须存在于openshift-logging
项目中,且必须具有指向它们所代表的相应证书的:tls.crt、tls.key 和 ca-bundle.crt 的密钥。否则,对于http
和https
前缀,您可以指定一个包含用户名和密码的 secret。如需更多信息,请参阅以下"示例:设置包含用户名和密码的 secret"。 - 8
- 可选:指定管道的名称。
- 9
- 使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 10
- 指定使用此管道转发日志时使用的输出名称。
- 11
- 可选:指定将日志发送到内部 Elasticsearch 实例的
default
输出。 - 12
- 可选:字符串。要添加到日志中的一个或多个标签。
- 13
- 可选:配置多个输出,将日志转发到任何受支持类型的其他外部日志聚合器:
- 描述管道的名称。
-
inputRefs
是使用管道转发的日志类型:application
、infrastructure
或audit
。 -
outputRefs
是要使用的输出名称。 - 可选:字符串。要添加到日志中的一个或多个标签。
创建 CR 对象。
$ oc create -f <file-name>.yaml
示例:设置包含用户名和密码的 secret
您可以使用包含用户名和密码的 secret 来验证与外部 Elasticsearch 实例的安全连接。
例如,如果无法使用 mutual TLS (mTLS) 密钥,因为第三方运行 Elasticsearch 实例,您可以使用 HTTP 或 HTTPS 并设置包含用户名和密码的 secret。
创建类似于以下示例的
Secret
YAML 文件。将 base64 编码的值用于username
和password
字段。secret 类型默认为 opaque。apiVersion: v1 kind: Secret metadata: name: openshift-test-secret data: username: <username> password: <password>
创建 secret:
$ oc create secret -n openshift-logging openshift-test-secret.yaml
在
ClusterLogForwarder
CR 中指定 secret 的名称:kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: elasticsearch type: "elasticsearch" url: https://elasticsearch.secure.com:9200 secret: name: openshift-test-secret
注意在
url
字段中,前缀可以是http
或https
。创建 CR 对象。
$ oc create -f <file-name>.yaml
11.1.11. 使用 Fluentd 转发协议转发日志
您可以使用 Fluentd forward 协议将日志副本发送到配置为接受协议的外部日志聚合器,而非默认的 Elasticsearch 日志存储。您需要配置外部日志聚合器,以接收来自 Red Hat OpenShift Service on AWS 的日志。
要使用 forward 协议配置日志转发,请创建一个 ClusterLogForwarder
自定义资源(CR),并将一个或多个输出输出到使用这些输出的 Fluentd 服务器和管道。Fluentd 输出可以使用 TCP(不安全)或 TLS(安全 TCP)连接。
先决条件
- 您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件:apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: fluentd-server-secure 3 type: fluentdForward 4 url: 'tls://fluentdserver.security.example.com:24224' 5 secret: 6 name: fluentd-secret - name: fluentd-server-insecure type: fluentdForward url: 'tcp://fluentdserver.home.example.com:24224' pipelines: - name: forward-to-fluentd-secure 7 inputRefs: 8 - application - audit outputRefs: - fluentd-server-secure 9 - default 10 labels: clusterId: "C1234" 11 - name: forward-to-fluentd-insecure 12 inputRefs: - infrastructure outputRefs: - fluentd-server-insecure labels: clusterId: "C1234"
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 指定
fluentdForward
类型。 - 5
- 指定外部 Fluentd 实例的 URL 和端口作为有效的绝对 URL。您可以使用
tcp
(不安全)或者tls
(安全 TCP)协议。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。 - 6
- 如果使用
tls
前缀,您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于openshift-logging
项目中,且必须具有指向它们所代表的相应证书的:tls.crt、tls.key 和 ca-bundle.crt 的密钥。 - 7
- 可选:指定管道的名称。
- 8
- 使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 9
- 指定使用此管道转发日志时使用的输出名称。
- 10
- 可选:指定将日志转发到内部 Elasticsearch 实例的
default
输出。 - 11
- 可选:字符串。要添加到日志中的一个或多个标签。
- 12
- 可选:配置多个输出,将日志转发到任何受支持类型的其他外部日志聚合器:
- 描述管道的名称。
-
inputRefs
是使用管道转发的日志类型:application
、infrastructure
或audit
。 -
outputRefs
是要使用的输出名称。 - 可选:字符串。要添加到日志中的一个或多个标签。
创建 CR 对象。
$ oc create -f <file-name>.yaml
11.1.11.1. 为 Logstash 启用 nanosecond 精度来从 fluentd 摄取数据
对于 Logstash 从 fluentd 摄取数据,您必须在 Logstash 配置文件中启用 nanosecond 精度。
流程
-
在 Logstash 配置文件中,将
nanosecond_precision
设置为true
。
Logstash 配置文件示例
input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } } filter { } output { stdout { codec => rubydebug } }
11.1.12. 使用 syslog 协议转发日志
您可以使用 syslog RFC3164 或 RFC5424 协议将日志副本发送到配置为接受该协议的外部日志聚合器(替代默认的 Elasticsearch 日志存储或作为它的补充)。您需要配置外部日志聚合器(如 syslog 服务器)来接收来自 Red Hat OpenShift Service on AWS 的日志。
要使用 syslog 协议配置日志转,,请创建一个 ClusterLogForwarder
自定义资源(CR),并将一个或多个输出输出到使用这些输出的 syslog 服务器和管道。syslog 输出可以使用 UDP、TCP 或 TLS 连接。
先决条件
- 您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件:apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: rsyslog-east 3 type: syslog 4 syslog: 5 facility: local0 rfc: RFC3164 payloadKey: message severity: informational url: 'tls://rsyslogserver.east.example.com:514' 6 secret: 7 name: syslog-secret - name: rsyslog-west type: syslog syslog: appName: myapp facility: user msgID: mymsg procID: myproc rfc: RFC5424 severity: debug url: 'udp://rsyslogserver.west.example.com:514' pipelines: - name: syslog-east 8 inputRefs: 9 - audit - application outputRefs: 10 - rsyslog-east - default 11 labels: secure: "true" 12 syslog: "east" - name: syslog-west 13 inputRefs: - infrastructure outputRefs: - rsyslog-west - default labels: syslog: "west"
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 指定
syslog
类型。 - 5
- 可选:指定 syslog 参数,如下所列。
- 6
- 指定外部 syslog 实例的 URL 和端口。您可以使用
udp
(不安全)、tcp
(不安全)或者tls
(安全 TCP)协议。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。 - 7
- 如果使用
tls
前缀,您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于openshift-logging
项目中,且必须具有指向它们所代表的相应证书的:tls.crt、tls.key 和 ca-bundle.crt 的密钥。 - 8
- 可选:指定管道的名称。
- 9
- 使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 10
- 指定使用此管道转发日志时使用的输出名称。
- 11
- 可选:指定将日志转发到内部 Elasticsearch 实例的
default
输出。 - 12
- 可选:字符串。要添加到日志中的一个或多个标签。对值加引号(如 "true"),以便它们被识别为字符串值,而不是作为布尔值。
- 13
- 可选:配置多个输出,将日志转发到任何受支持类型的其他外部日志聚合器:
- 描述管道的名称。
-
inputRefs
是使用管道转发的日志类型:application
、infrastructure
或audit
。 -
outputRefs
是要使用的输出名称。 - 可选:字符串。要添加到日志中的一个或多个标签。
创建 CR 对象。
$ oc create -f <file-name>.yaml
11.1.12.1. 在消息输出中添加日志消息
您可以通过将 AddLogSource
字段添加到 ClusterLogForwarder
自定义资源(CR)将 namespace_name
、pod_name
和 container_name
元素添加到记录的 message
字段中。
spec: outputs: - name: syslogout syslog: addLogSource: true facility: user payloadKey: message rfc: RFC3164 severity: debug tag: mytag type: syslog url: tls://syslog-receiver.openshift-logging.svc:24224 pipelines: - inputRefs: - application name: test-app outputRefs: - syslogout
这个配置与 RFC3164 和 RFC5424 兼容。
没有 AddLogSource
的 syslog 消息输出示例
<15>1 2020-11-15T17:06:14+00:00 fluentd-9hkb4 mytag - - - {"msgcontent"=>"Message Contents", "timestamp"=>"2020-11-15 17:06:09", "tag_key"=>"rec_tag", "index"=>56}
带有 AddLogSource
的 syslog 消息输出示例
<15>1 2020-11-16T10:49:37+00:00 crc-j55b9-master-0 mytag - - - namespace_name=clo-test-6327,pod_name=log-generator-ff9746c49-qxm7l,container_name=log-generator,message={"msgcontent":"My life is my message", "timestamp":"2020-11-16 10:49:36", "tag_key":"rec_tag", "index":76}
11.1.12.2. syslog 参数
您可以为 syslog
输出配置以下内容。如需更多信息,请参阅 syslog RFC3164 或 RFC5424 RFC。
facility: syslog facility.该值可以是十进制整数,也可以是区分大小写的关键字:
-
0
或kern
用于内核信息 -
1
或user
代表用户级信息(默认)。 -
2
或mail
用于邮件系统。 -
3
或daemon
用于系统守护进程 -
4
或auth
用于安全/身份验证信息 -
5
或syslog
用于 syslogd 内部生成的信息 -
6
或lpr
用于行打印机子系统 -
7
或news
用于网络新闻子系统 -
8
或uucp
用于 UUCP 子系统 -
9
或cron
用于 clock 守护进程 -
10
或authpriv
用于安全身份验证信息 -
11
或ftp
用于 FTP 守护进程 -
12
或ntp
用于 NTP 子系统 -
13
或security
用于 syslog audit 日志 -
14
或console
用于 syslog alert 日志 -
15
或solaris-cron
用于 scheduling 守护进程 -
16
-23
或local0
-local7
用于本地使用的工具
-
可选:
payloadKey
:用作 syslog 消息有效负载的记录字段。注意配置
payloadKey
参数可防止将其他参数转发到 syslog。- RFC:用于使用 syslog 发送日志的 RFC。默认为 RFC5424。
severity:设置传出的 syslog 记录的syslog 的严重性。该值可以是十进制整数,也可以是区分大小写的关键字:
-
0
或Emergency
用于代表系统不可用的信息 -
1
或Alert
用于代表立即执行操作的信息 -
2
或Critical
用于代表关键状况的信息 -
3
或Error
用于代表错误状况的信息 -
4
或Warning
用于代表警告条件的信息 -
5
或Notice
用于代表正常但存在重要条件的信息 -
6
或Informational
用于代表提示信息的信息 -
7
或Debug
用于代表调试级别的信息(默认)
-
- tag:Tag 指定记录字段,用作 syslog 消息上的标签。
- trimPrefix:从标签中删除指定的前缀。
11.1.12.3. 其他 RFC5424 syslog 参数
以下参数适用于 RFC5424:
-
appName: APP-NAME 是一个自由文本字符串,用于标识发送日志的应用程序。必须为
RFC5424
指定。 -
msgID: MSGID 是一个用于标识消息类型的自由文本字符串。必须为
RFC5424
指定。 -
PROCID: PROCID 是一个自由文本字符串。该值的变化表示 syslog 报告不连续。必须为
RFC5424
指定。
11.1.13. 将日志转发到 Kafka 代理
除了默认的日志存储外,您还可以将日志转发到外部 Kafka 代理。
要配置日志转发到外部 Kafka 实例,您必须创建一个 ClusterLogForwarder
自定义资源(CR),其中包含输出到该实例的输出以及使用输出的管道。您可以在输出中包括特定的 Kafka 主题,也可以使用默认值。Kafka 输出可以使用 TCP(不安全)或者 TLS(安全 TCP)连接。
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件:apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: app-logs 3 type: kafka 4 url: tls://kafka.example.devlab.com:9093/app-topic 5 secret: name: kafka-secret 6 - name: infra-logs type: kafka url: tcp://kafka.devlab2.example.com:9093/infra-topic 7 - name: audit-logs type: kafka url: tls://kafka.qelab.example.com:9093/audit-topic secret: name: kafka-secret-qe pipelines: - name: app-topic 8 inputRefs: 9 - application outputRefs: 10 - app-logs labels: logType: "application" 11 - name: infra-topic 12 inputRefs: - infrastructure outputRefs: - infra-logs labels: logType: "infra" - name: audit-topic inputRefs: - audit outputRefs: - audit-logs - default 13 labels: logType: "audit"
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 指定
kafka
类型。 - 5
- 将 Kafka 代理的 URL 和端口指定为一个有效的绝对 URL,也可以同时指定特定标题。您可以使用
tcp
(不安全)或者tls
(安全 TCP)协议。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。 - 6
- 如果使用
tls
前缀,您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于openshift-logging
项目中,且必须具有指向它们所代表的相应证书的:tls.crt、tls.key 和 ca-bundle.crt 的密钥。 - 7
- 可选: 要发送不安全的输出,在 URL 前面使用
tcp
前缀。另外,省略此输出中的secret
键及其name
。 - 8
- 可选:指定管道的名称。
- 9
- 使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 10
- 指定使用此管道转发日志时使用的输出名称。
- 11
- 可选:字符串。要添加到日志中的一个或多个标签。
- 12
- 可选:配置多个输出,将日志转发到任何受支持类型的其他外部日志聚合器:
- 描述管道的名称。
-
inputRefs
是使用管道转发的日志类型:application
、infrastructure
或audit
。 -
outputRefs
是要使用的输出名称。 - 可选:字符串。要添加到日志中的一个或多个标签。
- 13
- 可选:指定
default
将日志转发到内部 Elasticsearch 实例。
可选: 要将单个输出转发到多个 Kafka 代理,请指定 Kafka 代理数组,如下例所示:
# ... spec: outputs: - name: app-logs type: kafka secret: name: kafka-secret-dev kafka: 1 brokers: 2 - tls://kafka-broker1.example.com:9093/ - tls://kafka-broker2.example.com:9093/ topic: app-topic 3 # ...
运行以下命令来应用
ClusterLogForwarder
CR:$ oc apply -f <filename>.yaml
11.1.14. 将日志转发到 Amazon CloudWatch
您可以将日志转发到 Amazon CloudWatch,这是由 Amazon Web Services (AWS) 托管的监控和日志存储服务。除了默认的日志存储外,您还可以将日志转发到 CloudWatch。
要配置日志转发到 CloudWatch,您必须创建一个 ClusterLogForwarder
自定义资源 (CR),其中包含 CloudWatch 的输出,以及使用输出的管道。
流程
创建一个
Secret
YAML 文件,它使用aws_access_key_id
和aws_secret_access_key
字段来指定您的 base64 编码的 AWS 凭证。例如:apiVersion: v1 kind: Secret metadata: name: cw-secret namespace: openshift-logging data: aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
创建 secret.例如:
$ oc apply -f cw-secret.yaml
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件。在文件中,指定 secret 的名称。例如:apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: cw 3 type: cloudwatch 4 cloudwatch: groupBy: logType 5 groupPrefix: <group prefix> 6 region: us-east-2 7 secret: name: cw-secret 8 pipelines: - name: infra-logs 9 inputRefs: 10 - infrastructure - audit - application outputRefs: - cw 11
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 指定
cloudwatch
类型。 - 5
- 可选:指定如何对日志进行分组:
-
logType
为每个日志类型创建日志组 -
namespaceName
为每个应用程序命名空间创建一个日志组。它还会为基础架构和审计日志创建单独的日志组。 -
namespaceUUID
为每个应用命名空间 UUID 创建一个新的日志组。它还会为基础架构和审计日志创建单独的日志组。
-
- 6
- 可选:指定一个字符串来替换日志组名称中的默认
infrastructureName
前缀。 - 7
- 指定 AWS 区域。
- 8
- 指定包含 AWS 凭证的 secret 名称。
- 9
- 可选:指定管道的名称。
- 10
- 使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 11
- 指定使用此管道转发日志时使用的输出名称。
创建 CR 对象:
$ oc create -f <file-name>.yaml
示例:在 Amazon CloudWatch 中使用 ClusterLogForwarder
在这里,您会看到 ClusterLogForwarder
自定义资源 (CR) 示例及其输出到 Amazon CloudWatch 的日志数据。
假设您正在运行名为 mycluster
的 ROSA 集群。以下命令返回集群的 infrastructureName
,稍后您将用它来编写 aws
命令:
$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName "mycluster-7977k"
要为本例生成日志数据,您可以在名为 app
的命名空间中运行 busybox
pod。busybox
pod 每隔三秒钟将消息写入 stdout:
$ oc run busybox --image=busybox -- sh -c 'while true; do echo "My life is my message"; sleep 3; done' $ oc logs -f busybox My life is my message My life is my message My life is my message ...
您可以查找 busybox
pod 运行的 app
命名空间的 UUID:
$ oc get ns/app -ojson | jq .metadata.uid "794e1e1a-b9f5-4958-a190-e76a9b53d7bf"
在 ClusterLogForwarder
自定义资源 (CR) 中,您可以将 infrastructure
、audit
和 application
日志类型配置为 all-logs
管道的输入。您还可以将此管道连接到 cw
输出,输出将日志转发到 us-east-2
区域的 CloudWatch 实例:
apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: cw type: cloudwatch cloudwatch: groupBy: logType region: us-east-2 secret: name: cw-secret pipelines: - name: all-logs inputRefs: - infrastructure - audit - application outputRefs: - cw
CloudWatch 中的每个地区都包含三个级别的对象:
日志组
日志流
- 日志事件
使用 ClusterLogForwarding
CR 中的 groupBy: logType
,inputRefs
中的三种日志类型会在 Amazon Cloudwatch 中生成三个日志组:
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "mycluster-7977k.application" "mycluster-7977k.audit" "mycluster-7977k.infrastructure"
每个日志组都包含日志流:
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.application | jq .logStreams[].logStreamName "kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log"
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.audit | jq .logStreams[].logStreamName "ip-10-0-131-228.us-east-2.compute.internal.k8s-audit.log" "ip-10-0-131-228.us-east-2.compute.internal.linux-audit.log" "ip-10-0-131-228.us-east-2.compute.internal.openshift-audit.log" ...
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.infrastructure | jq .logStreams[].logStreamName "ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-69f9fd9b58-zqzw5_openshift-oauth-apiserver_oauth-apiserver-453c5c4ee026fe20a6139ba6b1cdd1bed25989c905bf5ac5ca211b7cbb5c3d7b.log" "ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-ce51532df7d4e4d5f21c4f4be05f6575b93196336be0027067fd7d93d70f66a4.log" "ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-check-endpoints-82a9096b5931b5c3b1d6dc4b66113252da4a6472c9fff48623baee761911a9ef.log" ...
每个日志流都包含日志事件。要查看 busybox
Pod 的日志事件,您可以从 application
日志组中指定其日志流:
$ aws logs get-log-events --log-group-name mycluster-7977k.application --log-stream-name kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log { "events": [ { "timestamp": 1629422704178, "message": "{\"docker\":{\"container_id\":\"da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76\"},\"kubernetes\":{\"container_name\":\"busybox\",\"namespace_name\":\"app\",\"pod_name\":\"busybox\",\"container_image\":\"docker.io/library/busybox:latest\",\"container_image_id\":\"docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60\",\"pod_id\":\"870be234-90a3-4258-b73f-4f4d6e2777c7\",\"host\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"labels\":{\"run\":\"busybox\"},\"master_url\":\"https://kubernetes.default.svc\",\"namespace_id\":\"794e1e1a-b9f5-4958-a190-e76a9b53d7bf\",\"namespace_labels\":{\"kubernetes_io/metadata_name\":\"app\"}},\"message\":\"My life is my message\",\"level\":\"unknown\",\"hostname\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"pipeline_metadata\":{\"collector\":{\"ipaddr4\":\"10.0.216.3\",\"inputname\":\"fluent-plugin-systemd\",\"name\":\"fluentd\",\"received_at\":\"2021-08-20T01:25:08.085760+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-20T01:25:04.178986+00:00\",\"viaq_index_name\":\"app-write\",\"viaq_msg_id\":\"NWRjZmUyMWQtZjgzNC00MjI4LTk3MjMtNTk3NmY3ZjU4NDk1\",\"log_type\":\"application\",\"time\":\"2021-08-20T01:25:04+00:00\"}", "ingestionTime": 1629422744016 }, ...
示例:在日志组群名称中自定义前缀
在日志组名称中,您可以将默认的 infrastructureName
前缀 mycluster-7977k
替换为一个任意字符串,如 demo-group-prefix
。要进行此更改,您需要更新 ClusterLogForwarding
CR 中的 groupPrefix
字段:
cloudwatch: groupBy: logType groupPrefix: demo-group-prefix region: us-east-2
groupPrefix
的值替换默认的 infrastructureName
前缀:
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "demo-group-prefix.application" "demo-group-prefix.audit" "demo-group-prefix.infrastructure"
示例:应用程序命名空间名称后命名日志组
对于集群中的每个应用程序命名空间,您可以在 CloudWatch 中创建日志组,其名称基于应用程序命名空间的名称。
如果您删除应用程序命名空间对象并创建名称相同的新对象,CloudWatch 会继续使用与以前相同的日志组。
如果您认为名称相同的连续应用程序命名空间对象相互等效,请使用本例中描述的方法。否则,如果您需要将生成的日志组相互区分,请参阅以下"为应用命名空间 UUID 注入日志组"部分。
要创建名称基于应用程序命名空间名称的应用程序日志组,您可以在 ClusterLogForwarder
CR 中将 groupBy
字段的值设置为 namespaceName
:
cloudwatch: groupBy: namespaceName region: us-east-2
将 groupBy
设置为 namespaceName
只会影响应用程序日志组。它不会影响 audit
和 infrastructure
日志组。
在 Amazon Cloudwatch 中,命名空间名称显示在每个日志组名称的末尾。因为只有一个应用程序命名空间 "app",以下输出显示一个新的 mycluster-7977k.app
日志组,而不是 mycluster-7977k.application
:
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "mycluster-7977k.app" "mycluster-7977k.audit" "mycluster-7977k.infrastructure"
如果本例中的集群包含多个应用命名空间,则输出中会显示多个日志组,每个命名空间对应一个日志组。
groupBy
字段仅影响应用日志组。它不会影响 audit
和 infrastructure
日志组。
示例:应用程序命名空间 UUID 后命名日志组
对于集群中的每个应用程序命名空间,您可以在 CloudWatch 中创建日志组,其名称是基于应用程序命名空间的 UUID。
如果您删除应用程序命名空间对象并创建新对象,CloudWatch 会创建一个新的日志组。
如果您考虑使用名称相同的连续应用程序命名空间对象,请使用本例中描述的方法。否则,请参阅前面的 "Example: Naming log groups for application namespace name" 部分。
要在应用程序命名空间 UUID 后命名日志组,您可以在 ClusterLogForwarder
CR 中将 groupBy
字段的值设置为 namespaceUUID
:
cloudwatch: groupBy: namespaceUUID region: us-east-2
在 Amazon Cloudwatch 中,命名空间 UUID 出现在每个日志组名称的末尾。因为有一个应用程序命名空间 "app",以下输出显示一个新的 mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf
日志组,而不是 mycluster-7977k.application
:
$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName "mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf" // uid of the "app" namespace "mycluster-7977k.audit" "mycluster-7977k.infrastructure"
groupBy
字段仅影响应用日志组。它不会影响 audit
和 infrastructure
日志组。
11.1.14.1. 从启用了 STS 的集群将日志转发到 Amazon CloudWatch
对于启用了 AWS Security Token Service (STS)的集群,请创建允许日志转发的 AWS IAM 角色和策略,以及带有 CloudWatch 输出的 ClusterLogForwarder
自定义资源(CR)。
先决条件
- Red Hat OpenShift 的日志记录子系统: 5.5 及更新的版本
流程
准备 AWS 帐户:
使用以下内容创建 IAM 策略 JSON 文件:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "arn:aws:logs:*:*:*" } ] }
使用以下内容创建 IAM 信任 JSON 文件:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<your_aws_account_id>:oidc-provider/<openshift_oidc_provider>" 1 }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<openshift_oidc_provider>:sub": "system:serviceaccount:openshift-logging:logcollector" 2 } } } ] }
创建 IAM 角色:
$ aws iam create-role --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \ --assume-role-policy-document file://<your_trust_file_name>.json \ --query Role.Arn \ --output text
保存输出。您将在后续步骤中使用它。
创建 IAM 策略:
$ aws iam create-policy \ --policy-name "RosaCloudWatch" \ --policy-document file:///<your_policy_file_name>.json \ --query Policy.Arn \ --output text
保存输出。您将在后续步骤中使用它。
将 IAM 策略附加到 IAM 角色:
$ aws iam attach-role-policy \ --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \ --policy-arn <policy_ARN> 1
- 1
- 将
policy_ARN
替换为您在创建策略时保存的输出。
为 logging Operator 创建
Secret
YAML 文件:apiVersion: v1 kind: Secret metadata: name: cloudwatch-credentials namespace: openshift-logging stringData: credentials: |- [default] sts_regional_endpoints = regional role_arn: <role_ARN> 1 web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
- 1
- 将
role_ARN
替换为您在创建角色时保存的输出。
创建 secret:
$ oc apply -f cloudwatch-credentials.yaml
创建或编辑
ClusterLogForwarder
自定义资源:apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: cw 3 type: cloudwatch 4 cloudwatch: groupBy: logType 5 groupPrefix: <group prefix> 6 region: us-east-2 7 secret: name: <your_secret_name> 8 pipelines: - name: to-cloudwatch 9 inputRefs: 10 - infrastructure - audit - application outputRefs: - cw 11
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 指定
cloudwatch
类型。 - 5
- 可选:指定如何对日志进行分组:
-
logType
为每个日志类型创建日志组 -
namespaceName
为每个应用程序命名空间创建一个日志组。基础架构和审计日志不受影响,剩余的日志按照logType
分组。 -
namespaceUUID
为每个应用命名空间 UUID 创建一个新的日志组。它还会为基础架构和审计日志创建单独的日志组。
-
- 6
- 可选:指定一个字符串来替换日志组名称中的默认
infrastructureName
前缀。 - 7
- 指定 AWS 区域。
- 8
- 指定之前创建的 secret 的名称。
- 9
- 可选:指定管道的名称。
- 10
- 使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 11
- 指定使用此管道转发日志时使用的输出名称。
其他资源
11.1.14.2. 使用现有 AWS 角色为 AWS CloudWatch 创建 secret
如果您有一个 AWS 的现有角色,您可以使用 oc create secret --from-literal
命令为 AWS 使用 STS 创建 secret。
流程
在 CLI 中,输入以下内容来为 AWS 生成 secret:
$ oc create secret generic cw-sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/my-role_with-permissions
Secret 示例
apiVersion: v1 kind: Secret metadata: namespace: openshift-logging name: my-secret-name stringData: role_arn: arn:aws:iam::123456789012:role/my-role_with-permissions
11.1.15. 将日志转发到 Loki
除了内部的默认 Red Hat OpenShift Service on AWS Elasticsearch 实例外,您还可以将日志转发到外部 Loki 日志记录系统。
要配置日志转发到 Loki,您必须创建一个 ClusterLogForwarder
自定义资源 (CR),并创建一个输出到 Loki 的 ClusterLogForwarder 自定义资源 (CR),以及使用输出的管道。到 Loki 的输出可以使用 HTTP(不安全)或 HTTPS(安全 HTTP)连接。
先决条件
-
您必须有一个 Loki 日志记录系统在您通过 CR 中的
url
字段指定的 URL 中运行。
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件:apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: loki-insecure 3 type: "loki" 4 url: http://loki.insecure.com:3100 5 loki: tenantKey: kubernetes.namespace_name labelKeys: kubernetes.labels.foo - name: loki-secure 6 type: "loki" url: https://loki.secure.com:3100 secret: name: loki-secret 7 loki: tenantKey: kubernetes.namespace_name 8 labelKeys: kubernetes.labels.foo 9 pipelines: - name: application-logs 10 inputRefs: 11 - application - audit outputRefs: 12 - loki-secure
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 将类型指定为
"loki"
。 - 5
- 将 Loki 系统的 URL 和端口指定为有效的绝对 URL。您可以使用
http
(不安全)或https
(安全 HTTP)协议。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。Loki 用于 HTTP(S) 通讯的默认端口为 3100。 - 6
- 对于安全连接,您可以通过指定
secret
来指定您进行身份验证的https
或http
URL。 - 7
- 对于
https
前缀,请指定 TLS 通信端点所需的 secret 名称。secret 必须存在于openshift-logging
项目中,且必须具有指向它们所代表的相应证书的:tls.crt、tls.key 和 ca-bundle.crt 的密钥。否则,对于http
和https
前缀,您可以指定一个包含用户名和密码的 secret。如需更多信息,请参阅以下"示例:设置包含用户名和密码的 secret"。 - 8
- 可选:指定一个 meta-data key 字段,为 Loki 中的
TenantID
字段生成值。例如,设置tenantKey: kubernetes.namespace_name
使用 Kubernetes 命名空间的名称作为 Loki 中的租户 ID 的值。要查看您可以指定的其他日志记录字段,请查看以下"Additional resources"部分中的"Log Record Fields"链接。 - 9
- 可选:指定一个 meta-data 字段键列表来替换默认的 Loki 标签。Loki 标签名称必须与正则表达式
[a-zA-Z_:][a-zA-Z0-9_:]*
匹配。元数据键中的非法字符会替换为_
以组成标签名称。例如,kubernetes.labels.foo
meta-data 键变成 Loki 标签kubernetes_labels_foo
。如果没有设置labelKeys
,则默认值为:[log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host]
。尽量保持标签数量少,因为 Loki 会限制允许标签的大小和数量。请参阅配置 Loki、limit_config。您仍然可以使用查询过滤器基于任何日志记录字段进行查询。 - 10
- 可选:指定管道的名称。
- 11
- 使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 12
- 指定使用此管道转发日志时使用的输出名称。
注意由于 Loki 要求按时间戳正确排序日志流,
labelKeys
始终包含kubernetes_host
标签,即使您没有指定它。此包含确保每个流源自单一主机,这样可防止因为不同主机上的时钟差异而导致时间戳出现问题。创建 CR 对象。
$ oc create -f <file-name>.yaml
11.1.15.1. 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 # ...
其他资源
11.1.16. 将日志转发到 Splunk
除了内部的默认 Red Hat OpenShift Service on AWS 日志存储外,您还可以将日志转发到 Splunk HTTP Event Collector (HEC)。
不支持在 Fluentd 中使用此功能。
先决条件
- Red Hat OpenShift Logging Operator 5.6 及更高版本
- 指定为 collector 的 ClusterLogging 实例
- Base64 编码的 Splunk HEC 令牌
流程
使用您的 Base64 编码的 Splunk HEC 令牌创建 secret。
$ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>
使用以下模板创建或编辑
ClusterLogForwarder
自定义资源(CR):apiVersion: "logging.openshift.io/v1" kind: "ClusterLogForwarder" metadata: name: "instance" 1 namespace: "openshift-logging" 2 spec: outputs: - name: splunk-receiver 3 secret: name: vector-splunk-secret 4 type: splunk 5 url: <http://your.splunk.hec.url:8088> 6 pipelines: 7 - inputRefs: - application - infrastructure name: 8 outputRefs: - splunk-receiver 9
11.1.17. 通过 HTTP 转发日志
fluentd 和向量收集器都支持通过 HTTP 转发日志。要启用,在 ClusterLogForwarder
自定义资源(CR)中指定 http
作为输出类型。
流程
- 使用以下模板创建或编辑 ClusterLogForwarder 自定义资源(CR):
ClusterLogForwarder CR 示例
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogForwarder" metadata: name: "instance" namespace: "openshift-logging" spec: outputs: - name: httpout-app type: http url: 1 http: headers: 2 h1: v1 h2: v2 method: POST secret: name: 3 tls: insecureSkipVerify: 4 pipelines: - name: inputRefs: - application outputRefs: - 5
11.1.18. 从特定项目转发应用程序日志
您可以使用 Cluster Log Forwarder 将应用日志的副本从特定项目发送到外部日志聚合器。除了使用默认的 Elasticsearch 日志存储外,您还可以进行此操作。您还必须配置外部日志聚合器,以接收来自 Red Hat OpenShift Service on AWS 的日志数据。
要从项目中配置转发应用程序日志,创建一个 ClusterLogForwarder
自定义资源(CR),其中至少从一个项目中输入,为其他日志聚合器提供可选输出,以及使用这些输入和输出的管道。
先决条件
- 您必须有配置为使用指定协议或格式接收日志数据的日志服务器。
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件:apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: outputs: - name: fluentd-server-secure 3 type: fluentdForward 4 url: 'tls://fluentdserver.security.example.com:24224' 5 secret: 6 name: fluentd-secret - name: fluentd-server-insecure type: fluentdForward url: 'tcp://fluentdserver.home.example.com:24224' inputs: 7 - name: my-app-logs application: namespaces: - my-project pipelines: - name: forward-to-fluentd-insecure 8 inputRefs: 9 - my-app-logs outputRefs: 10 - fluentd-server-insecure labels: project: "my-project" 11 - name: forward-to-fluentd-secure 12 inputRefs: - application - audit - infrastructure outputRefs: - fluentd-server-secure - default labels: clusterId: "C1234"
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定输出的名称。
- 4
- 指定输出类型:
elasticsearch
、fluentdForward
、syslog
或kafka
。 - 5
- 将外部日志聚合器的 URL 和端口指定为有效的绝对 URL。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。
- 6
- 如果使用
tls
前缀,您必须为 TLS 通信指定端点所需的 secret 名称。secret 必须存在于openshift-logging
项目中,并具有每个指向它们所代表证书的 tls.crt、tls.key 和 ca-bundle.crt 密钥。 - 7
- 用于过滤指定项目的应用程序日志的输入配置。
- 8
- 管道配置,使用输入将项目应用程序日志发送到外部 Fluentd 实例。
- 9
my-app-logs
输入。- 10
- 要使用的输出名称。
- 11
- 可选:字符串。要添加到日志中的一个或多个标签。
- 12
- 管道配置,将日志发送到其他日志聚合器。
- 可选:指定管道的名称。
-
使用管道指定要转发的日志类型:
application
、infrastructure
或audit
。 - 指定使用此管道转发日志时使用的输出名称。
-
可选:指定将日志转发到内部 Elasticsearch 实例的
default
输出。 - 可选:字符串。要添加到日志中的一个或多个标签。
创建 CR 对象。
$ oc create -f <file-name>.yaml
11.1.19. 从特定 pod 转发应用程序日志
作为集群管理员,您可以使用 Kubernetes pod 标签从特定 pod 收集日志数据并将其转发到日志收集器。
假设您的应用由容器集组成,并与不同命名空间中的其他容器集一起运行。如果这些 pod 具有标识应用程序标签,您可以收集和输出其日志数据到特定的日志收集器。
要指定 pod 标签,请使用一个或多个 matchLabels
键值对。如果指定了多个键值对,pod 必须与要选择的所有值匹配。
流程
创建或编辑定义
ClusterLogForwarder
CR 对象的 YAML 文件。在文件中,使用inputs[].name.application.selector.matchLabels
下的简单基于平等的选择器来指定 pod 标签,如下例所示。ClusterLogForwarder
CR YAML 文件示例apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance 1 namespace: openshift-logging 2 spec: pipelines: - inputRefs: [ myAppLogData ] 3 outputRefs: [ default ] 4 inputs: 5 - name: myAppLogData application: selector: matchLabels: 6 environment: production app: nginx namespaces: 7 - app1 - app2 outputs: 8 - default ...
- 1
ClusterLogForwarder
CR 的名称必须是instance
。- 2
ClusterLogForwarder
CR 的命名空间必须是openshift-logging
。- 3
- 指定来自
inputs[].name
的一个或多个以逗号分隔的值。 - 4
- 指定来自
outputs[]
的一个或多个以逗号分隔的值。 - 5
- 为具有一组唯一 pod 标签的每个应用程序定义唯一的
inputs[].name
。 - 6
- 指定您要收集的日志数据的 pod 标签的键值对。您必须指定一个键和值,而不仅仅是一个键。要被选择,pod 必须与所有键值对匹配。
- 7
- 可选:指定一个或多个命名空间。
- 8
- 指定要将日志数据转发到的一个或多个输出。此处显示的可选
默认
输出将日志数据发送到内部 Elasticsearch 实例。
-
可选: 要将日志数据收集限制为特定的命名空间,请使用
inputs[].name.application.namespaces
,如上例中所示。 可选: 您可以从具有不同 pod 标签的额外应用程序向同一管道发送日志数据。
-
对于 pod 标签的每个唯一组合,创建一个类似于显示的
inputs[].name
部分。 -
更新
选择器(selectors)
以匹配此应用的容器集标签。 将新的
inputs[].name
值添加到inputRefs
。例如:- inputRefs: [ myAppLogData, myOtherAppLogData ]
-
对于 pod 标签的每个唯一组合,创建一个类似于显示的
创建 CR 对象。
$ oc create -f <file-name>.yaml
其他资源
-
如需有关 Kubernetes 中
matchLabels
的更多信息,请参阅支持基于集合的要求的资源。
其他资源
11.1.20. 日志转发故障排除
当您创建 ClusterLogForwarder
自定义资源 (CR) 时,如果 Red Hat OpenShift Logging Operator 没有自动重新部署 Fluentd Pod,您可以删除 Fluentd Pod 来强制重新部署它们。
先决条件
-
您已创建了
ClusterLogForwarder
自定义资源 (CR) 对象。
流程
删除 Fluentd Pod 以强制重新部署。
$ oc delete pod --selector logging-infra=collector