搜索

日志记录

download PDF
OpenShift Container Platform 4.15

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

Red Hat OpenShift Documentation Team

摘要

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

第 1 章 发行注记

1.1. Logging 5.9

注意

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

注意

stable 频道只为日志记录的最新版本提供更新。要继续获得之前版本的更新,您必须将订阅频道改为 stable-x.y,其中 x.y 代表您安装的日志记录的主版本和次版本。例如,stable-5.7

logging-5-9-release-notes.adoc :_mod-docs-content-type: REFERENCE 中包含的 /module

1.1.1. 日志记录 5.9.2

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

1.1.1.1. 程序错误修复
  • 在此次更新之前,因为 ClusterLogForwarder CR 中的配置不正确,对 Logging Operator 的更改会导致错误。因此,升级到日志记录会删除 daemonset 收集器。在这个版本中,日志记录 Operator 会重新创建收集器 daemonset,除非出现 Not authorized to collect 错误。(LOG-4910)
  • 在此次更新之前,因为 Vector 日志收集器中的配置不正确,在有些情况下,轮转的基础架构日志文件会被发送到应用程序索引。在这个版本中,Vector 日志收集器配置可避免收集任何轮转的基础架构日志文件。(LOG-5156)
  • 在此次更新之前,日志记录 Operator 不会监控 grafana-dashboard-cluster-logging 配置映射的更改。在这个版本中,日志记录 Operator 会监控 ConfigMap 对象中的更改,确保系统保持同步并有效地响应配置映射修改。(LOG-5308)
  • 在此次更新之前,日志记录 Operator 的指标集合代码中的问题会导致它报告过时的遥测指标。在这个版本中,日志记录 Operator 不会报告过时的遥测指标。(LOG-5426)
  • 在此更改前,Fluentd out_http 插件会忽略 no_proxy 环境变量。在这个版本中,Fluentd 会修补 ruby 的 HTTP#start 方法,以符合 no_proxy 环境变量。(LOG-5466)
1.1.1.2. CVE

1.1.2. 日志记录 5.9.1

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

1.1.2.1. 功能增强
  • 在此次更新之前,Loki Operator 将 Loki 配置为使用 Amazon Simple Storage Service (S3) 的基于路径的风格访问,它已被弃用。在这个版本中,Loki Operator 默认为 virtual-host 样式,而无需更改其配置。(LOG-5401)
  • 在此次更新之前,Loki Operator 不会验证存储 secret 中使用的 Amazon Simple Storage Service (S3) 端点。在这个版本中,验证过程可确保 S3 端点是一个有效的 S3 URL,LokiStack 状态更新来指示任何无效的 URL。(LOG-5395)
1.1.2.2. 程序错误修复
  • 在此次更新之前,LogQL 解析中的错误会从查询中排除一些行过滤器。在这个版本中,解析会包括所有行过滤器,同时保持原始查询保持不变。(LOG-5268)
  • 在此次更新之前,没有定义的 pruneFilterSpec 的 prune 过滤器会导致 segfault。在这个版本中,如果修剪过滤器没有定义的 puneFilterSpec,会出现验证错误。(LOG-5322)
  • 在此次更新之前,没有定义的 dropTestsSpec 的 drop 过滤器会导致 segfault。在这个版本中,如果修剪过滤器没有定义的 puneFilterSpec,会出现验证错误。(LOG-5323)
  • 在此次更新之前,Loki Operator 不会验证存储 secret 中使用的 Amazon Simple Storage Service (S3) 端点 URL 格式。在这个版本中,S3 端点 URL 会经过验证步骤,它反映了 LokiStack 的状态。(LOG-5397)
  • 在此次更新之前,审计日志记录中格式化的时间戳字段会导致 Red Hat OpenShift Logging Operator 日志中出现 WARN 信息。在这个版本中,重新映射转换可确保正确格式化 timestamp 字段。(LOG-4672)
  • 在此次更新之前,当验证 ClusterLogForwarder 资源名称和命名空间没有对应于正确的错误时,错误消息会抛出。在这个版本中,系统会检查同一命名空间中是否存在具有相同名称的 ClusterLogForwarder 资源。如果没有,它对应于正确的错误。(LOG-5062)
  • 在此次更新之前,输出配置的验证功能需要一个 TLS URL,即使 Amazon CloudWatch 或 Google Cloud Logging 等服务,在设计不需要 URL。在这个版本中,在没有 URL 的服务的验证逻辑有所改进,错误消息会更为说明。(LOG-5307)
  • 在此次更新之前,定义基础架构输入类型不会从集合中排除日志工作负载。在这个版本中,集合排除日志记录服务以避免反馈循环。(LOG-5309)
1.1.2.3. CVE

没有 CVE。

1.1.3. Logging 5.9.0

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

1.1.3.1. 删除通知

Logging 5.9 发行版本不包含 OpenShift Elasticsearch Operator 的更新版本。来自之前日志记录版本的 OpenShift Elasticsearch Operator 实例被支持,直到日志记录版本的 EOL 为止。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。如需有关日志记录生命周期日期的更多信息,请参阅平台 Agnostic Operator

1.1.3.2. 弃用通知
  • 在 Logging 5.9,Fluentd,Elasticsearch、Fluentd 和 Kibana 已被弃用,计划在 Logging 6.0 中删除,该 6.0 应该与以后的 OpenShift Container Platform 版本一起提供。红帽将在当前发行生命周期中对这些组件提供关键及以上的 CVE 程序错误修复和支持,但这些组件将不再获得功能增强。由 Red Hat OpenShift Logging Operator 和 LokiStack 提供的基于 Vector 的收集器和 Loki Operator 提供的 LokiStack 是日志集合和存储的首选 Operator。我们鼓励所有用户使用 Vector 和 Loki 日志堆栈,因为这个组合会持续进一步进行改进。
  • 在 Logging 5.9 中,Splunk 输出类型的 Fields 选项没有实现,并现已弃用。它将在以后的发行版本中被删除。
1.1.3.3. 功能增强
1.1.3.3.1. 日志集合
  • 此功能增强增加了使用工作负载的元数据根据其内容 dropprune 日志的功能。另外,它允许收集基础架构日志(如日志或容器日志)和审计日志(如 kube apiovn 日志)仅收集单个源。(LOG-2155)
  • 此增强引入了一个新的远程日志接收器 (syslog 接收器)。您可以将其配置为通过网络公开端口,允许外部系统使用兼容工具(如 rsyslog)发送 syslog 日志。(LOG-3527)
  • 在这个版本中,ClusterLogForwarder API 支持转发到 Azure Monitor 日志,为用户提供更好的监控功能。此功能可帮助用户维护最佳的系统性能,并简化 Azure Monitor 中的日志分析过程,从而加快问题解决并提高操作效率。(LOG-4605)
  • 此功能增强通过将收集器部署为带有两个副本的部署来提高收集器资源利用率。当 ClusterLogForwarder 自定义资源 (CR) 中定义的唯一输入源是接收器输入而不是在所有节点上使用守护进程集时,会出现这种情况。此外,以这种方式部署的收集器不会挂载主机文件系统。要使用此增强,您需要使用 logging.openshift.io/dev-preview-enable-collector-as-deployment 注解来注解 ClusterLogForwarder CR。(LOG-4779)
  • 此功能增强引入了在所有支持的输出中自定义租户配置的功能,以逻辑方式促进日志记录的组织。但是,它不允许自定义租户配置来记录受管存储。(LOG-4843)
  • 在这个版本中,ClusterLogForwarder CR 使用一个或多个基础架构命名空间(如 defaultopenshift*kube* )指定应用程序输入,现在需要一个具有 collect-infrastructure-logs 角色的服务帐户。(LOG-4943)
  • 此功能增强引入了调整一些输出设置(如压缩、重试持续时间和最大有效负载)的功能,以匹配接收器的特性。此外,此功能还包括一种交付模式,允许管理员在吞吐量和日志持久性之间进行选择。例如,AtLeastOnce 选项配置收集日志的最小磁盘缓冲区,以便收集器重启后可以发送这些日志。(LOG-5026)
  • 此功能增强添加了三个新的 Prometheus 警报,警告用户有关 Elasticsearch、Fluentd 和 Kibana 弃用的信息。(LOG-5055)
1.1.3.3.2. 日志存储
  • LokiStack 中的这个增强通过使用新的 V13 对象存储格式并默认启用自动流分片功能,改进了对 OTEL 的支持。这也可让收集器为将来的改进和配置准备。(LOG-4538)
  • 此功能增强引进了对使用 Azure 和 AWS 日志存储的短期令牌工作负载身份联合的支持,启用了 STS 的 OpenShift Container Platform 4.14 及更新的版本。本地存储需要在 LokiStack CR 的 spec.storage.secret 下添加 CredentialMode: static 注解。(LOG-4540)
  • 在这个版本中,Azure 存储 secret 的验证被扩展,为某些错误状况提供早期警告。(LOG-4571)
  • 在这个版本中,Loki 添加了对 GCP 工作负载身份联邦机制的上游和下游支持。这允许对对应对象存储服务进行身份验证和授权访问。(LOG-4754)
1.1.3.4. 程序错误修复
  • 在此次更新之前,日志记录 must-gather 无法收集启用了 FIPS 的集群中的任何日志。在这个版本中,cluster-logging-rhel9-operator 中提供了一个新的 oc 客户端,must-gather 可以在 FIPS 集群中正常工作。(LOG-4403)
  • 在此次更新之前,LokiStack 规则器 pod 无法将 IPv6 pod IP 格式化为用于跨 pod 通信的 HTTP URL。此问题导致通过与 Prometheus 兼容的 API 查询规则和警报失败。在这个版本中,LokiStack 规则器 pod 将 IPv6 pod IP 封装在方括号中,从而解决了这个问题。现在,通过与 Prometheus 兼容的 API 查询规则和警报的工作方式就像在 IPv4 环境中一样。(LOG-4709)
  • 在这个版本中,日志记录 must-gather 的 YAML 内容在一行中导出,使其不可读取。在这个版本中,YAML 空格会被保留,确保该文件被正确格式化。(LOG-4792)
  • 在此次更新之前,当启用 ClusterLogForwarder CR 时,当 ClusterLogging.Spec.Collection 为 nil 时,Red Hat OpenShift Logging Operator 可能会进入 nil pointer 异常。在这个版本中,这个问题已在 Red Hat OpenShift Logging Operator 中解决。(LOG-5006)
  • 在此次更新之前,在特定的基础情形中,替换 ClusterLogForwarder CR status 字段会导致 resourceVersionStatus 条件中更改时间戳而持续更新。这个条件会导致一个无限的协调循环。在这个版本中,所有状态条件都会同步,以便在条件保持不变时时间戳保持不变。(LOG-5007)
  • 在此次更新之前,内部缓冲行为需要 drop_newest 来解决收集器高内存消耗,从而导致大量日志丢失。在这个版本中,行为恢复为使用收集器默认值。(LOG-5123)
  • 在此次更新之前,openshift-operators-redhat 命名空间中的 Loki Operator ServiceMonitor 使用静态令牌和 CA 文件进行身份验证,从而导致 ServiceMonitor 配置上的 User Workload Monitoring spec 中 Prometheus Operator 出现错误。在这个版本中,openshift-operators-redhat 命名空间中的 Loki Operator ServiceMonitor 现在通过 LocalReference 对象引用服务帐户令牌 secret。这种方法允许 Prometheus Operator 中的 User Workload Monitoring spec 成功处理 Loki Operator ServiceMonitor,使 Prometheus 能够提取 Loki Operator 指标。(LOG-5165)
  • 在此次更新之前,Loki Operator ServiceMonitor 的配置可能与许多 Kubernetes 服务匹配,从而导致 Loki Operator 指标被多次收集。在这个版本中,ServiceMonitor 的配置只与专用指标服务匹配。(LOG-5212)
1.1.3.5. 已知问题

无。

1.1.3.6. CVE

1.2. Logging 5.8

注意

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

注意

stable 频道只为日志记录的最新版本提供更新。要继续获得之前版本的更新,您必须将订阅频道改为 stable-x.y,其中 x.y 代表您安装的日志记录的主版本和次版本。例如,stable-5.7

1.2.1. Logging 5.8.7

此发行版本包括 OpenShift Logging 程序错误修复 5.8.7 安全更新OpenShift Logging 程序错误修复 5.8.7

1.2.1.1. 程序错误修复
  • 在此次更新之前,如果没有收集 < type> 日志(审计、基础架构或应用程序 ),elasticsearch-im -<type >jpeg pod 会失败。在这个版本中,当不收集 < type> 日志时,pod 不再会失败。(LOG-4949)
  • 在此次更新之前,输出配置的验证功能需要一个 SSL/TLS URL,即使 Amazon CloudWatch 或 Google Cloud Logging 等服务,在设计不需要 URL。在这个版本中,在没有 URL 的服务的验证逻辑有所改进,错误消息更为信息。(LOG-5467)
  • 在此次更新之前,日志记录 Operator 的指标集合代码中的问题会导致它报告过时的遥测指标。在这个版本中,日志记录 Operator 不会报告过时的遥测指标。(LOG-5471)
  • 在此次更新之前,因为 ClusterLogForwarder CR 中的配置不正确,对 Logging Operator 的更改会导致错误。因此,升级到日志记录会删除 daemonset 收集器。在这个版本中,日志记录 Operator 会重新创建收集器 daemonset,除非出现 Not authorized to collect 错误。(LOG-5514)
1.2.1.2. CVE

1.2.2. Logging 5.8.6

此发行版本包括 OpenShift Logging 程序错误修复 5.8.6 安全更新OpenShift Logging 程序错误修复 5.8.6

1.2.2.1. 功能增强
  • 在此次更新之前,Loki Operator 不会验证存储 secret 中使用的 Amazon Simple Storage Service (S3) 端点。在这个版本中,验证过程可确保 S3 端点是一个有效的 S3 URL,LokiStack 状态更新来指示任何无效的 URL。(LOG-5392)
  • 在此次更新之前,Loki Operator 将 Loki 配置为使用 Amazon Simple Storage Service (S3) 的基于路径的风格访问,它已被弃用。在这个版本中,Loki Operator 默认为 virtual-host 样式,而无需更改其配置。(LOG-5402)
1.2.2.2. 程序错误修复
  • 在此次更新之前,openshift-operators-redhat 命名空间中的 Elastisearch Operator ServiceMonitor 使用静态令牌和证书颁发机构(CA)文件进行身份验证,从而导致 ServiceMonitor 配置中的 Prometheus Operator 中出现错误。在这个版本中,openshift-operators-redhat 命名空间中的 Elastisearch Operator ServiceMonitor 现在通过 LocalReference 对象引用服务帐户令牌 secret。这种方法允许 Prometheus Operator 中的 User Workload Monitoring 规格成功处理 Elastisearch Operator ServiceMonitor。这可让 Prometheus 提取 Elastisearch Operator 指标。(LOG-5164)
  • 在此次更新之前,Loki Operator 不会验证存储 secret 中使用的 Amazon Simple Storage Service (S3) 端点 URL 格式。在这个版本中,S3 端点 URL 会经过验证步骤,它反映了 LokiStack 的状态。(LOG-5398)
1.2.2.3. CVE

1.2.3. Logging 5.8.5

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

1.2.3.1. 程序错误修复
  • 在此次更新之前,Loki Operator ServiceMonitor 的配置可能与许多 Kubernetes 服务匹配,从而导致 Loki Operator 指标被多次收集。在这个版本中,ServiceMonitor 的配置只与专用指标服务匹配。(LOG-5250)
  • 在此次更新之前,红帽构建管道不使用 Loki 构建中的现有构建详情,以及省略的信息,如修订、分支和版本。在这个版本中,红帽构建管道会在 Loki 构建中添加这些详情,从而解决了这个问题。(LOG-5201)
  • 在此次更新之前,Loki Operator 会检查 pod 是否正在运行,以确定 LokiStack 是否已就绪。在这个版本中,它还检查 pod 是否已就绪,以便 LokiStack 的就绪度反映了其组件的状态。(LOG-5171)
  • 在此次更新之前,对日志指标运行查询会导致直方图出现错误。在这个版本中,直方切换函数和图表被禁用并隐藏,因为直方图无法使用日志指标。(LOG-5044)
  • 在此次更新之前,Loki 和 Elasticsearch 捆绑包具有错误的 maxOpenShiftVersion,从而导致 IncompatibleOperatorsInstalled 警报。在这个版本中,包括 4.16 作为捆绑包中的 maxOpenShiftVersion 属性解决了这个问题。(LOG-5272)
  • 在此次更新之前,构建管道不包含构建日期的 linker 标志,从而导致 Loki 构建显示 buildDategoVersion 的空字符串。在这个版本中,在构建管道中添加缺少的 linker 标志解决了这个问题。(LOG-5274)
  • 在此次更新之前,LogQL 解析中的错误会从查询中排除一些行过滤器。在这个版本中,解析会包括所有行过滤器,同时保持原始查询保持不变。(LOG-5270)
  • 在此次更新之前,openshift-operators-redhat 命名空间中的 Loki Operator ServiceMonitor 使用静态令牌和 CA 文件进行身份验证,从而导致 ServiceMonitor 配置上的 User Workload Monitoring spec 中 Prometheus Operator 出现错误。在这个版本中,openshift-operators-redhat 命名空间中的 Loki Operator ServiceMonitor 现在通过 LocalReference 对象引用服务帐户令牌 secret。这种方法允许 Prometheus Operator 中的 User Workload Monitoring spec 成功处理 Loki Operator ServiceMonitor,使 Prometheus 能够提取 Loki Operator 指标。(LOG-5240)
1.2.3.2. CVE

1.2.4. Logging 5.8.4

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

1.2.4.1. 程序错误修复
  • 在此次更新之前,开发人员控制台日志没有考虑当前命名空间,从而导致在没有集群范围日志访问权限的情况下对用户进行查询。在这个版本中,所有支持的 OCP 版本都确保命名空间包含正确。(LOG-4905)
  • 在此次更新之前,Cluster Logging Operator 仅在默认日志输出为 LokiStack 时部署支持 LokiStack 部署的 ClusterRole。在这个版本中,角色被分成两个组:read 和 write。写入角色根据默认日志存储的设置部署,就像以前使用的所有角色一样。read 角色根据日志记录控制台插件是否活跃部署。(LOG-4987)
  • 在此次更新之前,多个定义相同输入接收器名称的 ClusterLogForwarders 因在一个服务上更改 ownerReferences 而被无限协调。在这个版本中,每个接收器输入都有自己的服务,其约定为 <CLF.Name>-<input.Name>。(LOG-5009)
  • 在此次更新之前,当在没有 secret 的情况下将日志转发到 cloudwatch 时,ClusterLogForwarder 不会报告错误。在这个版本中,当在没有 secret 时将日志转发到 cloudwatch 时会出现以下错误:secret must be provided for cloudwatch output。(LOG-5021)
  • 在此次更新之前,log_forwarder_input_info 包括 application, infrastructure, 和 audit 输入指标点。在这个版本中,http 也添加为指标点。(LOG-5043)
1.2.4.2. CVE

1.2.5. Logging 5.8.3

此发行版本包括 Logging 程序错误修复 5.8.3Logging 安全修复 5.8.3

1.2.5.1. 程序错误修复
  • 在此次更新之前,当配置为读取自定义 S3 证书颁发机构时,Loki Operator 不会在 ConfigMap 的名称或内容改变时自动更新配置。在这个版本中,Loki Operator 会监视 ConfigMap 的更改,并自动更新生成的配置。(LOG-4969)
  • 在此次更新之前,在没有有效 URL 的情况下配置的 Loki 输出会导致收集器 Pod 崩溃。在这个版本中,输出会根据 URL 验证进行相应的处理,从而解决了这个问题。(LOG-4822)
  • 在此次更新之前,Cluster Logging Operator 会为没有指定 secret 来使用服务帐户 bearer 令牌的输出生成收集器配置字段。在这个版本中,输出不需要身份验证,从而解决了这个问题。(LOG-4962)
  • 在此次更新之前,输出的 tls.insecureSkipVerify 字段没有设置为 true,且没有定义 secret。在这个版本中,不再需要一个 secret 来设置这个值。(LOG-4963)
  • 在此次更新之前,输出配置允许使用 TLS 身份验证的不安全(HTTP) URL 的组合。在这个版本中,为 TLS 身份验证配置的输出需要一个安全(HTTPS) URL。(LOG-4893)
1.2.5.2. CVE

1.2.6. Logging 5.8.2

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

1.2.6.1. 程序错误修复
  • 在此次更新之前,LokiStack 规则器 pod 不会将 IPv6 pod IP 格式化为用于跨 pod 通信的 HTTP URL,从而导致通过 Prometheus 兼容的 API 查询规则和警报失败。在这个版本中,LokiStack 规则器 pod 将 IPv6 pod IP 封装在方括号中,从而解决了这个问题。(LOG-4890)
  • 在此次更新之前,开发人员控制台日志没有考虑当前命名空间,从而导致在没有集群范围日志访问权限的情况下对用户进行查询。在这个版本中,命名空间包含已被修正,从而解决了这个问题。(LOG-4947)
  • 在此次更新之前,OpenShift Container Platform Web 控制台的日志记录视图插件不允许自定义节点放置和容限。在这个版本中,定义自定义节点放置和容限被添加到 OpenShift Container Platform Web 控制台的日志记录视图插件中。(LOG-4912)
1.2.6.2. CVE

1.2.7. Logging 5.8.1

此发行版本包括 OpenShift Logging 程序错误修复 5.8.1OpenShift Logging 程序错误修复 5.8.1 Kibana

1.2.7.1. 功能增强
1.2.7.1.1. 日志集合
  • 在这个版本中,在将 Vector 配置为收集器时,您可以在 Red Hat OpenShift Logging Operator 中添加逻辑,以使用 secret 中指定的令牌来代替与服务帐户关联的令牌。(LOG-4780)
  • 在这个版本中,BoltDB Shipper Loki 仪表板被重命名为 Index 仪表板。(LOG-4828)
1.2.7.2. 程序错误修复
  • 在此次更新之前,ClusterLogForwarder 在启用 JSON 日志解析后会创建空索引,即使没有满足滚动条件。在这个版本中,ClusterLogForwarder 会在 write-index 为空时跳过滚动。(LOG-4452)
  • 在此次更新之前,Vector 会错误地设置了默认日志级别。在这个版本中,通过改进正则表达式(regexp)进行日志级别检测来设置正确的日志级别。(LOG-4480)
  • 在此次更新之前,在创建索引模式的过程中,每个日志输出的初始索引中缺少默认别名。因此,Kibana 用户无法使用 OpenShift Elasticsearch Operator 创建索引模式。在这个版本中,在 OpenShift Elasticsearch Operator 中添加缺少的别名,从而解决了这个问题。Kibana 用户现在可以创建包含 {app,infra,audit}-000001 索引的索引模式。(LOG-4683)
  • 在此次更新之前,Fluentd 收集器 Pod 处于 CrashLoopBackOff 状态,因为 IPv6 集群上的 Prometheus 服务器绑定。在这个版本中,收集器可以在 IPv6 集群中正常工作。(LOG-4706)
  • 在此次更新之前,Red Hat OpenShift Logging Operator 会在 ClusterLogForwarder 中有更改时进行大量协调。在这个版本中,Red Hat OpenShift Logging Operator 会忽略触发协调的收集器 daemonset 的状态更改。(LOG-4741)
  • 在此次更新之前,Vector 日志收集器 pod 在 IBM Power 机器上处于 CrashLoopBackOff 状态。在这个版本中,Vector 日志收集器 Pod 在 IBM Power 架构机器上成功启动。(LOG-4768)
  • 在此次更新之前,使用旧的转发器转发到内部 LokiStack 会导致使用 Fluentd 收集器 Pod 生成 SSL 证书错误。在这个版本中,日志收集器服务帐户默认使用关联的令牌和 ca.crt 进行身份验证。(LOG-4791)
  • 在此次更新之前,使用旧的转发器转发到内部 LokiStack 会导致使用 Vector 收集器 Pod 生成 SSL 证书错误。在这个版本中,日志收集器服务帐户默认使用关联的令牌和 ca.crt 进行身份验证。(LOG-4852)
  • 在此次更新之前,在为占位符评估一个或多个主机后,不会正确解析 IPv6 地址。在这个版本中,IPv6 地址会被正确解析。(LOG-4811)
  • 在此次更新之前,需要创建一个 ClusterRoleBinding 来为 HTTP 接收器输入收集审计权限。在这个版本中,不需要创建 ClusterRoleBinding,因为端点已经依赖于集群证书颁发机构。(LOG-4815)
  • 在此次更新之前,Loki Operator 不会将自定义 CA 捆绑包挂载到规则 pod。因此,在评估警报或记录规则的过程中,对象存储访问会失败。在这个版本中,Loki Operator 将自定义 CA 捆绑包挂载到所有规则 pod。规则器 pod 可以从对象存储下载日志,以评估警报或记录规则。(LOG-4836)
  • 在此次更新之前,在删除 ClusterLogForwarder 中的 inputs.receiver 部分时,HTTP 输入服务及其关联的 secret 不会被删除。在这个版本中,如果需要,HTTP 输入资源会被删除。(LOG-4612)
  • 在此次更新之前,ClusterLogForwarder 指示状态中的验证错误,但输出和管道状态无法准确反映特定的问题。在这个版本中,管道状态会在错误的输出、输入或过滤器时正确显示验证失败的原因。(LOG-4821)
  • 在此次更新之前,更改使用控制的 LogQL 查询(如时间范围或严重性)更改了标签 matcher operator 定义它,就像正则表达式一样。在这个版本中,正则表达式运算符在更新查询时保持不变。(LOG-4841)
1.2.7.3. CVE

1.2.8. Logging 5.8.0

此发行版本包括 OpenShift Logging 程序错误修复 5.8.0OpenShift Logging 程序错误修复 5.8.0 Kibana

1.2.8.1. 弃用通知

在 Logging 5.8 中,Elasticsearch、Fluentd 和 Kibana 已被弃用,计划在 Logging 6.0 中删除,该 6.0 应该与以后的 OpenShift Container Platform 版本一起提供。红帽将在当前发行生命周期中对这些组件提供关键及以上的 CVE 程序错误修复和支持,但这些组件将不再获得功能增强。由 Red Hat OpenShift Logging Operator 和 LokiStack 提供的基于 Vector 的收集器和 Loki Operator 提供的 LokiStack 是日志集合和存储的首选 Operator。我们鼓励所有用户使用 Vector 和 Loki 日志堆栈,因为这个组合会持续进一步进行改进。

1.2.8.2. 功能增强
1.2.8.2.1. 日志集合
  • 在这个版本中,LogFileMetricExporter 不再默认和收集器一起部署。您需要手动创建一个 LogFileMetricExporter 自定义资源 (CR),从运行容器生成的日志中生成指标。如果没有创建 LogFileMetricExporter CR,您可能会在 OpenShift Container Platform Web 控制台仪表板中看到 Produced LogsNo datapoints found 信息。(LOG-3819)
  • 在这个版本中,您可以在任何命名空间中部署多个、隔离和 RBAC 保护的 ClusterLogForwarder 自定义资源(CR)实例。这允许独立组将所需的日志转发到任何目的地,同时将其配置与其他收集器部署隔离。(LOG-1343)

    重要

    要在 openshift-logging 命名空间以外的额外命名空间中支持多集群日志转发功能,您必须更新 Red Hat OpenShift Logging Operator 以监视所有命名空间。在新的 Red Hat OpenShift Logging Operator 版本 5.8 版本中默认支持此功能。

  • 在这个版本中,您可以使用流控制或速率限制机制来限制可以通过丢弃超额日志记录来收集或转发日志数据的卷。输入限制防止性能不佳的容器过载 Logging,输出限制则限制在提供给给定数据存储的日志的速度上造成不佳。(LOG-884)
  • 在这个版本中,您可以将日志收集器配置为查找 HTTP 连接,并接收日志作为 HTTP 服务器,也称为 Webhook。(LOG-4562)
  • 在这个版本中,您可以配置审计策略来控制日志收集器转发哪些 Kubernetes 和 OpenShift API 服务器事件。(LOG-3982)
1.2.8.2.2. 日志存储
  • 在这个版本中,Loki 管理员可以更精细地控制谁可以通过基于命名空间授予对日志的访问权限。(LOG-3841)
  • 在这个版本中,Loki Operator 在 LokiStack 部署中引入了 PodDisruptionBudget 配置,通过保持 ingestion 和查询路径可用来确保 OpenShift Container Platform 集群重启期间正常操作。(LOG-3839)
  • 在这个版本中,现有 LokiStack 安装的可靠性通过应用一组默认的 Affinity 和 Anti-Affinity 策略来无缝改进。(LOG-3840)
  • 在这个版本中,您可以作为 LokiStack 中的管理员管理区感知数据复制,以便在区失败时增强可靠性。(LOG-3266)
  • 在这个版本中,增加了一个新的受支持的小规模的 LokiStack 大小(1x.extra-small),它适用于托管少量工作负载并有较小的 ingestion 卷(最多为 100GB/天)的 OpenShift Container Platform 集群。(LOG-4329)
  • 在这个版本中,Loki 管理员可以访问官方 Loki 仪表板,以检查存储性能和每个组件的健康状态。(LOG-4327)
1.2.8.2.3. 日志控制台
  • 在这个版本中,当 Elasticsearch 是默认的日志存储时,您可以启用日志记录控制台插件。(LOG-3856)
  • 在这个版本中,OpenShift Container Platform 应用程序所有者可以为 OpenShift Container Platform 版本 4.14 及之后的版本在 OpenShift Container Platform Web 控制台 Developer 视角中接收基于应用程序日志的警报的通知。(LOG-3548)
1.2.8.3. 已知问题
  • 目前,在升级到 Red Hat OpenShift Logging Operator 版本 5.8 后,Splunk 日志转发可能无法正常工作。这个问题是由从 OpenSSL 版本 1.1.1 转换到 3.0.7 版本造成的。在较新的 OpenSSL 版本中,有一个默认行为更改,如果没有公开 RFC 5746 扩展,则拒绝到 TLS 1.2 端点的连接。

    作为临时解决方案,请在 Splunk HEC (HTTP Event Collector) 端点前对 TLS 终止负载均衡器启用 TLS 1.3 支持。Splunk 是一个第三方系统,它应该从 Splunk 端配置。

  • 目前,在处理 HTTP/2 协议中的多路流中存在一个缺陷,您可以在其中重复向新的多路流发出请求,并立即发送 RST_STREAM 框架来取消它。这会为服务器设置和缩减流造成额外的工作,从而导致因为服务器资源消耗而拒绝服务。当前没有解决此问题的方法。(LOG-4609)
  • 目前,当使用 FluentD 作为收集器时,收集器 Pod 无法在 OpenShift Container Platform IPv6-enabled 集群中启动。pod 日志会生成 fluentd pod [error]: unexpected error error_class=SocketError error="getaddrinfo: Name or service not known 错误。当前没有解决此问题的方法。(LOG-4706)
  • 目前,启用了 IPv6 的集群上没有日志警报。当前没有解决此问题的方法。(LOG-4709)
  • 目前,must-gather 无法在启用了 FIPS 的集群中收集任何日志,因为 cluster-logging-rhel9-operator 中没有所需的 OpenSSL 库。当前没有解决此问题的方法。(LOG-4403)
  • 目前,当在启用了 FIPS 的集群上部署 logging 版本 5.8 时,收集器 Pod 无法启动,并处于 CrashLoopBackOff 状态,同时将 FluentD 用作收集器。当前没有解决此问题的方法。(LOG-3933)
1.2.8.4. CVE

1.3. Logging 5.7

注意

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

注意

stable 频道只为日志记录的最新版本提供更新。要继续获得之前版本的更新,您必须将订阅频道改为 stable-x.y,其中 x.y 代表您安装的日志记录的主版本和次版本。例如,stable-5.7

1.3.1. Logging 5.7.8

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

1.3.1.1. 程序错误修复
  • 在此次更新之前,当与 ClusterLogForwarder 自定义资源(CR)中的 outputRefsinputRefs 参数使用相同的名称时,则会有潜在的冲突。因此,收集器 Pod 在 CrashLoopBackOff 状态中输入。在这个版本中,输出标签包含 OUTPUT_ 前缀,以确保输出标签和管道名称之间的区别。(LOG-4383)
  • 在此次更新之前,在配置 JSON 日志解析器时,如果您没有为 Cluster Logging Operator 设置 structuredTypeKeystructuredTypeName 参数,则不会显示有关无效配置的警报。在这个版本中,Cluster Logging Operator 会告知您配置问题。(LOG-4441)
  • 在此次更新之前,如果为 Splunk 输出指定的 secret 中缺少 hecToken 键或不正确,验证会失败,因为向量在没有令牌的情况下将日志转发到 Splunk。在这个版本中,如果 hecToken 键缺失或不正确,验证会失败,并显示 A non-empty hecToken entry is required 错误消息。(LOG-4580)
  • 在此次更新之前,使用 web 控制台从自定义时间范围中选择日志的日期会导致出现错误。在这个版本中,您可以在 web 控制台中成功从时间范围模型中选择日期。(LOG-4684)
1.3.1.2. CVE

1.3.2. Logging 5.7.7

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

1.3.2.1. 程序错误修复
  • 在此次更新之前,FluentD 规范化由 EventRouter 发送的日志与 Vector 不同。在这个版本中,Vector 以一致的格式生成日志记录。(LOG-4178)
  • 在此次更新之前,在由 Cluster Logging Operator 创建的指标仪表板中,查询中存在一个错误,用于 FluentD Buffer Availability 图,因为它显示最小缓冲区用量。在这个版本中,图形显示最大缓冲区使用量,现在被重命名为 FluentD Buffer Usage。(LOG-4555)
  • 在此次更新之前,在 IPv6 或双栈 OpenShift Container Platform 集群上部署 LokiStack 会导致 LokiStack memberlist 注册失败。因此,经销商 Pod 会进入崩溃循环。在这个版本中,管理员可以通过将 lokistack.spec.hashRing.memberlist.enableIPv6: 值设置为 true 来启用 IPv6,这会解决这个问题。(LOG-4569)
  • 在此次更新之前,日志收集器依赖于默认配置设置来读取容器日志行。因此,日志收集器无法有效地读取轮转的文件。在这个版本中,读取字节数会增加,允许日志收集器高效地处理轮转文件。(LOG-4575)
  • 在此次更新之前,事件路由器中未使用的指标会导致容器因为过量内存用量而失败。在这个版本中,通过删除未使用的指标来减少事件路由器的内存用量。(LOG-4686)
1.3.2.2. CVE

1.3.3. Logging 5.7.6

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

1.3.3.1. 程序错误修复
  • 在此次更新之前,收集器依赖于默认配置设置来读取容器日志行。因此,收集器无法有效地读取轮转的文件。在这个版本中,读取字节数会增加,允许收集器高效地处理轮转文件。(LOG-4501)
  • 在此次更新之前,当用户使用预定义的过滤器粘贴 URL 时,一些过滤器没有反映。在这个版本中,UI 反映了 URL 中的所有过滤器。(LOG-4459)
  • 在此次更新之前,使用自定义标签转发到 Loki 会在从 Fluentd 切换到 Vector 时生成错误。在这个版本中,Vector 配置清理标签与 Fluentd 相同,以确保收集器启动并正确处理标签。(LOG-4460)
  • 在此次更新之前,Observability Logs 控制台搜索字段不接受它应该转义的特殊字符。在这个版本中,它会在查询中正确转义特殊字符。(LOG-4456)
  • 在此次更新之前,在将日志发送到 Splunk 会出现以下镜像信息:Timestamp was not found.在这个版本中,更改会覆盖用于检索 Timestamp 的日志字段的名称,并将其发送到 Splunk,而不发出警告。(LOG-4413)
  • 在此次更新之前,向量的 CPU 和内存用量随着时间增加。在这个版本中,Vector 配置包含 expire_metrics_secs=60 设置来限制指标的生命周期,并上限相关的 CPU 用量和内存占用量。(LOG-4171)
  • 在此次更新之前,LokiStack 网关会广泛缓存授权请求。因此,这会导致错误的授权结果。在这个版本中,Loki 网关缓存以更精细的方式缓存来解决这个问题。(LOG-4393)
  • 在此次更新之前,Fluentd 运行时镜像包含在运行时不需要的构建程序工具。在这个版本中,构建器工具已被删除,从而解决了这个问题。(LOG-4467)
1.3.3.2. CVE

1.3.4. Logging 5.7.4

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

1.3.4.1. 程序错误修复
  • 在此次更新之前,当将日志转发到 CloudWatch 时,namespaceUUID 值不会被附加到 logGroupName 字段中。在这个版本中,包含 namespaceUUID 值,因此 CloudWatch 中的 logGroupName 显示为 logGroupName: vectorcw.b443fb9e-bd4c-4b6a-b9d3-c0097f9ed286。(LOG-2701)
  • 在此次更新之前,当通过 HTTP 将日志转发到非集群目的地时,向量收集器无法向集群范围的 HTTP 代理进行身份验证,即使代理 URL 中提供了正确的凭证。在这个版本中,Vector 日志收集器可以向集群范围的 HTTP 代理进行身份验证。(LOG-3381)
  • 在此次更新之前,如果 Fluentd 收集器配置了 Splunk 作为输出,Operator 将失败,因为不支持此配置。在这个版本中,配置验证会拒绝不支持的输出,从而解决了这个问题。(LOG-4237)
  • 在此次更新之前,当 Vector 收集器在 AWS Cloudwatch 日志的 TLS 配置中更新了 enabled = true 值时,GCP Stackdriver 会导致配置错误。在这个版本中,为这些输出删除 enabled = true 值,从而解决了这个问题。(LOG-4242)
  • 在此次更新之前,向量收集器偶尔会在日志中出现以下错误信息:thread 'vector-worker' panicked at 'all branch are disabled, no else branch', src/kubernetes/reflector.rs:26:9。在这个版本中,这个错误已解决。(LOG-4275)
  • 在此次更新之前,如果 Operator 配置了该租户的额外选项,Loki Operator 中的问题会导致应用程序租户的 alert-manager 配置消失。在这个版本中,生成的 Loki 配置包含自定义和自动生成的配置。(LOG-4361)
  • 在此次更新之前,当使用多个角色使用带有 AWS Cloudwatch 转发的 STS 进行身份验证时,最近更新会导致凭证不是唯一的。在这个版本中,STS 角色和静态凭证的多个组合可以再次用于与 AWS Cloudwatch 进行身份验证。(LOG-4368)
  • 在此次更新之前,Loki 为活跃流过滤标签值,但没有删除重复,使 Grafana 的标签浏览器不可用。在这个版本中,Loki 会过滤活跃流的重复标签值,从而解决了这个问题。(LOG-4389)
  • 升级到 OpenShift Logging 5.7 后,在 ClusterLogForwarder 自定义资源 (CR) 中没有指定 name 字段的管道将停止工作。在这个版本中,这个错误已解决。(LOG-4120)
1.3.4.2. CVE

1.3.5. Logging 5.7.3

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

1.3.5.1. 程序错误修复
  • 在此次更新之前,当在 OpenShift Container Platform Web 控制台中查看日志时,缓存的文件会导致数据无法刷新。在这个版本中,bootstrap 文件不会被缓存,从而解决了这个问题。(LOG-4100)
  • 在此次更新之前,Loki Operator 会重置错误,导致识别配置问题很难排除故障。在这个版本中,错误会保留,直到配置错误解决为止。(LOG-4156)
  • 在此次更新之前,在更改 RulerConfig 自定义资源(CR) 后,LokiStack 规则器不会重启。在这个版本中,Loki Operator 在更新 RulerConfig CR 后重启规则 pod。(LOG-4161)
  • 在此次更新之前,当输入匹配标签值包含 ClusterLogForwarder 中的 / 字符时,向量收集器意外终止。在这个版本中,通过引用 match 标签解决了这个问题,使收集器能够启动和收集日志。(LOG-4176)
  • 在此次更新之前,当 LokiStack CR 定义租户限制而不是全局限制时,Loki Operator 意外终止。在这个版本中,Loki Operator 可以在没有全局限制的情况下处理 LokiStack CR,从而解决了这个问题。(LOG-4198)
  • 在此次更新之前,当提供的私钥受密码保护时,Fluentd 不会将日志发送到 Elasticsearch 集群。在这个版本中,Fluentd 在与 Elasticsearch 建立连接时可以正确地处理受密语保护的私钥。(LOG-4258)
  • 在此次更新之前,具有超过 8,000 个命名空间的集群会导致 Elasticsearch 拒绝查询,因为命名空间列表大于 http.max_header_size 设置。在这个版本中,标头大小的默认值有所增加,从而解决了这个问题。(LOG-4277)
  • 在此次更新之前,ClusterLogForwarder CR 中包含 / 字符的标签值会导致收集器意外终止。在这个版本中,斜杠被下划线替代,从而解决了这个问题。(LOG-4095)
  • 在此次更新之前,Cluster Logging Operator 会在设置为非受管状态时意外终止。在这个版本中,在启动 ClusterLogForwarder CR 的协调前,确保 ClusterLogging 资源处于正确的管理状态,从而解决了这个问题。(LOG-4177)
  • 在此次更新之前,当在 OpenShift Container Platform Web 控制台中查看日志时,通过拖放到直方图中的时间范围无法用于 pod 详情中的聚合日志视图。在这个版本中,可以通过拖动到这个视图中的直方图来选择时间范围。(LOG-4108)
  • 在此次更新之前,当在 OpenShift Container Platform Web 控制台中查看日志时,查询会超过 30 秒超时。在这个版本中,超时值可以在 configmap/logging-view-plugin 中配置。(LOG-3498)
  • 在此次更新之前,当在 OpenShift Container Platform Web 控制台中查看日志时,点更多数据可用选项仅在第一次点击时加载更多日志条目。在这个版本中,每次点击时会加载更多条目。(OU-188)
  • 在此次更新之前,当在 OpenShift Container Platform Web 控制台中查看日志时,点 streaming 选项只显示 流传输 日志消息,而无需显示实际日志。在这个版本中,消息和日志流都会正确显示。(OU-166)
1.3.5.2. CVE

1.3.6. Logging 5.7.2

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

1.3.6.1. 程序错误修复
  • 在此次更新之前,因为存在待处理的终结器,无法直接删除 openshift-logging 命名空间。在这个版本中,不再使用终结器 (finalizer),启用直接删除命名空间。(LOG-3316)
  • 在此次更新之前,如果根据 OpenShift Container Platform 文档更改了 run.sh 脚本,则 run.sh 脚本会显示一个不正确的 chunk_limit_size 值。但是,当通过环境变量 $BUFFER_SIZE_LIMIT 设置 chunk_limit_size 时,该脚本会显示正确的值。在这个版本中,run.sh 脚本会在这两种场景中都一致地显示正确的 chunk_limit_size 值。(LOG-3330)
  • 在此次更新之前,OpenShift Container Platform Web 控制台的日志记录视图插件不允许自定义节点放置或容限。在这个版本中,增加了为日志记录视图插件定义节点放置和容限的功能。(LOG-3749)
  • 在此次更新之前,当尝试通过 Fluentd HTTP 插件将日志发送到 DataDog 时,Cluster Logging Operator 遇到 Unsupported Media Type 异常。在这个版本中,用户可以通过配置 HTTP 标头 Content-Type 为日志转发无缝分配内容类型。提供的值会自动分配给插件中的 content_type 参数,确保成功传输日志。(LOG-3784)
  • 在此次更新之前,当 ClusterLogForwarder 自定义资源 (CR) 中的 detectMultilineErrors 字段设置为 true 时,PHP 多行错误被记录为单独的日志条目,从而导致堆栈跟踪在多个消息间分割。在这个版本中,启用了 PHP 的多行错误检测,确保整个堆栈追踪包含在单一日志消息中。(LOG-3878)
  • 在此次更新之前,ClusterLogForwarder 管道的名称中包含空格会导致 Vector 收集器 pod 持续崩溃。在这个版本中,管道名称中的所有空格、短划线 (-) 和点 (.) 都被替换为下划线 (_)。(LOG-3945)
  • 在此次更新之前,log_forwarder_output 指标不包括 http 参数。在这个版本中,在指标中添加缺少的参数。(LOG-3997)
  • 在此次更新之前,Fluentd 在以冒号结尾时无法识别一些多行 JavaScript 客户端异常。在这个版本中,Fluentd 缓冲名称的前缀为下划线,从而解决了这个问题。(LOG-4019)
  • 在此次更新之前,当将日志转发配置为写入与有效负载中键匹配的 Kafka 输出主题时,日志会因为错误而丢弃。在这个版本中,Fluentd 的缓冲区名称前缀为下划线,从而解决了这个问题。(LOG-4027)
  • 在此次更新之前,LokiStack 网关返回命名空间的标签值,而无需应用用户的访问权限。在这个版本中,Loki 网关应用标签值请求的权限,从而解决了这个问题。(LOG-4049)
  • 在此次更新之前,当 tls.insecureSkipVerify 选项被设置为 true 时,Cluster Logging Operator API 需要一个由 secret 提供的证书。在这个版本中,Cluster Logging Operator API 不再需要在这样的情形中由 secret 提供证书。以下配置已添加到 Operator 的 CR 中:

    tls.verify_certificate = false
    tls.verify_hostname = false

    (LOG-3445)

  • 在此次更新之前,LokiStack 路由配置会导致查询运行时间超过 30 秒。在这个版本中,Loki global 和 per-tenant queryTimeout 设置会影响路由超时设置,从而解决了这个问题。(LOG-4052)
  • 在此次更新之前,删除 collection.type 的默认修复会导致 Operator 不再遵循资源、节点选择和容限已弃用的 spec。在这个版本中,Operator 的行为总是首选 collection.logs spec 而不是这些集合。这与之前允许使用首选字段和已弃用字段的行为不同,但在填充 collection.type 时会忽略已弃用的字段。(LOG-4185)
  • 在此次更新之前,如果输出中没有指定代理 URL,Vector 日志收集器不会生成 TLS 配置,用于将日志转发到多个 Kafka 代理。在这个版本中,为多个代理生成 TLS 配置。(LOG-4163)
  • 在此次更新之前,为登录到 Kafka 的日志转发启用密码短语的选项不可用。这个限制会导致安全风险,因为它可能会公开敏感信息。在这个版本中,用户有一个无缝选项来为登录到 Kafka 的日志转发启用密码短语。(LOG-3314)
  • 在此次更新之前,Vector 日志收集器不会遵循传出 TLS 连接的 tlsSecurityProfile 设置。在这个版本中,Vector 可以正确地处理 TLS 连接设置。(LOG-4011)
  • 在此次更新之前,在 log_forwarder_output_info 指标中,并非所有可用的输出类型都包括在 log_forwarder_output_info 指标中。在这个版本中,指标包含之前缺少的 Splunk 和 Google Cloud Logging 数据。(LOG-4098)
  • 在此次更新之前,当将 follow_inodes 设置为 true 时,Fluentd 收集器可能会在文件轮转时崩溃。在这个版本中,follow_inodes 设置不会使收集器崩溃。(LOG-4151)
  • 在此次更新之前,Fluentd 收集器可能会因为如何跟踪这些文件而错误地关闭应该监视的文件。在这个版本中,跟踪参数已被修正。(LOG-4149)
  • 在此次更新之前,使用 Vector 收集器转发日志,并在 ClusterLogForwarder 实例 audit 中命名管道,applicationinfrastructure 会导致收集器 pod 处于 CrashLoopBackOff 状态,并在收集器日志中出现以下错误:

    ERROR vector::cli: Configuration error. error=redefinition of table transforms.audit for key transforms.audit

    在这个版本中,管道名称不再与保留输入名称冲突,管道可以被命名为 audit,applicationinfrastructure。(LOG-4218)

  • 在此次更新之前,当将日志转发到带有 Vector 收集器的 syslog 目的地,并将 addLogSource 标志设置为 true 时,将以下额外空字段添加到转发消息:namespace_name=container_name=pod_name=。在这个版本中,这些字段不再添加到日志日志中。(LOG-4219)
  • 在此次更新之前,当未找到 structuredTypeKey 且没有指定 structuredTypeName 时,日志消息仍然被解析为结构化对象。在这个版本中,日志的解析如预期。(LOG-4220)
1.3.6.2. CVE

1.3.7. Logging 5.7.1

此发行版本包括:OpenShift Logging 程序错误修复 5.7.1

1.3.7.1. 程序错误修复
  • 在此次更新之前,Cluster Logging Operator pod 日志中存在大量信息会导致日志的可读性降低,并增加识别重要系统事件的难度。在这个版本中,这个问题可以通过显著降低 Cluster Logging Operator pod 日志中的信息来解决。(LOG-3482)
  • 在此次更新之前,API 服务器会将 CollectorSpec.Type 字段的值重置为 vector,即使自定义资源使用了不同的值。在这个版本中,删除了 CollectorSpec.Type 字段的默认设置来恢复之前的行为。(LOG-4086)
  • 在此次更新之前,无法通过点击并在日志直方图上拖动,在 OpenShift Container Platform Web 控制台中选择时间范围。在这个版本中,可以使用单击和拖动来成功选择时间范围。(LOG-4501)
  • 在此次更新之前,点 OpenShift Container Platform Web 控制台中的 Show Resources 链接不会产生任何影响。在这个版本中,通过修复 "Show Resources" 链接的功能来解决这个问题,以切换每个日志条目的资源显示。(LOG-3218)
1.3.7.2. CVE

1.3.8. Logging 5.7.0

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

1.3.8.1. 功能增强

在这个版本中,您可以启用日志记录来检测多行异常,并将其重新编译到一条日志条目中。

要启用日志记录来检测多行异常,并将其重新编译到一个日志条目中,请确保 ClusterLogForwarder 自定义资源 (CR) 包含 detectMultilineErrors 字段,值为 true

1.3.8.2. 已知问题

无。

1.3.8.3. 程序错误修复
  • 在此次更新之前,LokiHost 的 Gateway 组件的 nodeSelector 属性不会影响节点调度。在这个版本中,nodeSelector 属性可以正常工作。(LOG-3713)
1.3.8.4. CVE

第 2 章 支持

logging 只支持本文档中介绍的配置选项。

不要使用任何其他配置选项,因为它们不被支持。各个 OpenShift Container Platform 发行版本的配置范例可能会有所变化,只有掌握了所有可能的配置,才能稳妥应对这样的配置变化。如果您使用本文档中描述的配置以外的配置,您的更改会被覆盖,因为 Operator 旨在协调差异。

注意

如果必须执行 OpenShift Container Platform 文档中未描述的配置,您需要将 Red Hat OpenShift Logging Operator 设置为 Unmanaged。不支持非受管日志记录实例,且不会接收更新,直到您将其状态返回为 Managed 为止。

注意

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

Red Hat OpenShift 的 logging 是一个建议的收集器,以及应用程序、基础架构和审计日志的规范化程序。它旨在将日志转发到各种支持的系统。

Logging 不是:

  • 一个大规模日志收集系统
  • 兼容安全信息和事件监控 (SIEM)
  • 历史或长日志的保留或存储
  • 保证的日志接收器
  • 安全存储 - 默认不存储审计日志

2.1. 支持的 API 自定义资源定义

LokiStack 开发正在进行。目前还不支持所有 API。

表 2.1. Loki API 支持状态
CustomResourceDefinition (CRD)ApiVersion支持状态

LokiStack

lokistack.loki.grafana.com/v1

在 5.5 中支持

RulerConfig

rulerconfig.loki.grafana/v1

在 5.7 中支持

AlertingRule

alertingrule.loki.grafana/v1

在 5.7 中支持

RecordingRule

recordingrule.loki.grafana/v1

在 5.7 中支持

2.2. 不支持的配置

您必须将 Red Hat OpenShift Logging Operator 设置为 Unmanaged 状态才能修改以下组件:

  • Elasticsearch 自定义资源(CR)
  • Kibana 部署
  • fluent.conf 文件
  • Fluentd 守护进程集

您必须将 OpenShift Elasticsearch Operator 设置为 Unmanaged 状态,才能修改 Elasticsearch 部署文件。

明确不支持的情形包括:

  • 配置默认日志轮转。您无法修改默认的日志轮转配置。
  • 配置所收集日志的位置。您无法更改日志收集器输出文件的位置,默认为 /var/log/fluentd/fluentd.log
  • 日志收集节流。您不能减慢日志收集器读取日志的速度。
  • 使用环境变量配置日志记录收集器。您不能使用环境变量来修改日志收集器。
  • 配置日志收集器规范日志的方式。您无法修改默认日志规范化。

2.3. 非受管 Operator 的支持策略

Operator 的 管理状态 决定了一个 Operator 是否按设计积极管理集群中其相关组件的资源。如果 Operator 设置为 非受管(unmanaged) 状态,它不会响应配置更改,也不会收到更新。

虽然它可以在非生产环境集群或调试过程中使用,但处于非受管状态的 Operator 不被正式支持,集群管理员需要完全掌控各个组件的配置和升级。

可使用以下方法将 Operator 设置为非受管状态:

  • 独立 Operator 配置

    独立 Operator 的配置中具有 managementState 参数。这可以通过不同的方法来访问,具体取决于 Operator。例如,Red Hat OpenShift Logging Operator 通过修改它管理的自定义资源(CR)来达到此目的,而 Cluster Samples Operator 使用了集群范围配置资源。

    managementState 参数更改为 Unmanaged 意味着 Operator 不会主动管理它的资源,也不会执行与相关组件相关的操作。一些 Operator 可能不支持此管理状态,因为它可能会损坏集群,需要手动恢复。

    警告

    将独立 Operator 更改为非受管状态会导致不支持该特定组件和功能。报告的问题必须在 受管(Managed) 状态中可以重复出现才能继续获得支持。

  • Cluster Version Operator (CVO) 覆盖

    可将 spec.overrides 参数添加到 CVO 配置中,以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的 spec.overrides[].unmanaged 参数设置为 true 会阻止集群升级并在设置 CVO 覆盖后提醒管理员:

    Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
    警告

    设置 CVO 覆盖会使整个集群处于不受支持状态。在删除所有覆盖后,必须可以重现报告的问题方可获得支持。

2.4. 为红帽支持收集日志记录数据

在提交问题单时,向红帽支持提供有关集群的调试信息会很有帮助。

您可以使用 must-gather 工具来收集有关项目级别资源、集群级别资源和每个日志记录组件的诊断信息。

为了获得快速支持,请提供 OpenShift Container Platform 和日志记录的诊断信息。

注意

不要使用 hack/logging-dump.sh 脚本。这个脚本不再被支持且不收集数据。

2.4.1. 关于 must-gather 工具

oc adm must-gather CLI 命令会收集最有助于解决问题的集群信息。

对于日志记录,must-gather 会收集以下信息:

  • 项目级别资源,包括 Pod、配置映射、服务帐户、角色、角色绑定和事件
  • 集群级资源,包括集群级别的节点、角色和角色绑定
  • openshift-loggingopenshift-operators-redhat 命名空间中的 OpenShift Logging 资源,包括日志收集器的健康状况、日志存储和日志可视化工具

在运行 oc adm must-gather 时,集群上会创建一个新 pod。在该 pod 上收集数据,并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。

2.4.2. 收集日志记录数据

您可以使用 oc adm must-gather CLI 命令来收集有关日志记录的信息。

流程

使用 must-gather 来收集日志信息:

  1. 进入要存储 must-gather 信息的目录。
  2. 针对日志记录镜像运行 oc adm must-gather 命令:

    $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')

    must-gather 工具会创建一个以当前目录中 must-gather.local 开头的新目录。例如: must-gather.local.4157245944708210408

  3. 从刚刚创建的 must-gather 目录创建一个压缩文件。例如,在使用 Linux 操作系统的计算机上运行以下命令:

    $ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408
  4. 红帽客户门户中为您的问题单附上压缩文件。

第 3 章 日志故障排除

3.1. 查看日志记录状态

您可以查看 Red Hat OpenShift Logging Operator 的状态和其他日志记录组件。

3.1.1. 查看 Red Hat OpenShift Logging Operator 的状态

您可以查看 Red Hat OpenShift Logging Operator 的状态。

先决条件

  • 安装了 Red Hat OpenShift Logging Operator 和 OpenShift Elasticsearch Operator。

流程

  1. 运行以下命令,切换到 openshift-logging 项目:

    $ oc project openshift-logging
  2. 运行以下命令来获取 ClusterLogging 实例状态:

    $ oc get clusterlogging instance -o yaml

    输出示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    # ...
    status:  1
      collection:
        logs:
          fluentdStatus:
            daemonSet: fluentd  2
            nodes:
              collector-2rhqp: ip-10-0-169-13.ec2.internal
              collector-6fgjh: ip-10-0-165-244.ec2.internal
              collector-6l2ff: ip-10-0-128-218.ec2.internal
              collector-54nx5: ip-10-0-139-30.ec2.internal
              collector-flpnn: ip-10-0-147-228.ec2.internal
              collector-n2frh: ip-10-0-157-45.ec2.internal
            pods:
              failed: []
              notReady: []
              ready:
              - collector-2rhqp
              - collector-54nx5
              - collector-6fgjh
              - collector-6l2ff
              - collector-flpnn
              - collector-n2frh
      logstore: 3
        elasticsearchStatus:
        - ShardAllocationEnabled:  all
          cluster:
            activePrimaryShards:    5
            activeShards:           5
            initializingShards:     0
            numDataNodes:           1
            numNodes:               1
            pendingTasks:           0
            relocatingShards:       0
            status:                 green
            unassignedShards:       0
          clusterName:             elasticsearch
          nodeConditions:
            elasticsearch-cdm-mkkdys93-1:
          nodeCount:  1
          pods:
            client:
              failed:
              notReady:
              ready:
              - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
            data:
              failed:
              notReady:
              ready:
              - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
            master:
              failed:
              notReady:
              ready:
              - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
    visualization:  4
        kibanaStatus:
        - deployment: kibana
          pods:
            failed: []
            notReady: []
            ready:
            - kibana-7fb4fd4cc9-f2nls
          replicaSets:
          - kibana-7fb4fd4cc9
          replicas: 1

    1
    在输出中,集群状态字段显示在 status 小节中。
    2
    Fluentd Pod 的相关信息。
    3
    Elasticsearch Pod 的相关信息,包括 Elasticsearch 集群健康状态 greenyellowred
    4
    Kibana Pod 的相关信息。
3.1.1.1. 情况消息示例

以下是来自 ClusterLogging 实例的 Status.Nodes 部分的一些情况消息示例。

类似于以下内容的状态消息表示节点已超过配置的低水位线,并且没有分片将分配给此节点:

输出示例

  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-clientdatamaster-0-1
    upgradeStatus: {}

类似于以下内容的状态消息表示节点已超过配置的高水位线,并且分片将重新定位到其他节点:

输出示例

  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: cluster-logging-operator
    upgradeStatus: {}

类似于以下内容的状态消息表示 CR 中的 Elasticsearch 节点选择器与集群中的任何节点都不匹配:

输出示例

    Elasticsearch Status:
      Shard Allocation Enabled:  shard allocation unknown
      Cluster:
        Active Primary Shards:  0
        Active Shards:          0
        Initializing Shards:    0
        Num Data Nodes:         0
        Num Nodes:              0
        Pending Tasks:          0
        Relocating Shards:      0
        Status:                 cluster health unknown
        Unassigned Shards:      0
      Cluster Name:             elasticsearch
      Node Conditions:
        elasticsearch-cdm-mkkdys93-1:
          Last Transition Time:  2019-06-26T03:37:32Z
          Message:               0/5 nodes are available: 5 node(s) didn't match node selector.
          Reason:                Unschedulable
          Status:                True
          Type:                  Unschedulable
        elasticsearch-cdm-mkkdys93-2:
      Node Count:  2
      Pods:
        Client:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:
        Data:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:
        Master:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:

类似于以下内容的状态消息表示请求的 PVC 无法绑定到 PV:

输出示例

      Node Conditions:
        elasticsearch-cdm-mkkdys93-1:
          Last Transition Time:  2019-06-26T03:37:32Z
          Message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
          Reason:                Unschedulable
          Status:                True
          Type:                  Unschedulable

类似于以下内容的状态消息表示无法调度 Fluentd Pod,因为节点选择器与任何节点都不匹配:

输出示例

Status:
  Collection:
    Logs:
      Fluentd Status:
        Daemon Set:  fluentd
        Nodes:
        Pods:
          Failed:
          Not Ready:
          Ready:

3.1.2. 查看日志记录组件的状态

您可以查看多个日志记录组件的状态。

先决条件

  • 安装了 Red Hat OpenShift Logging Operator 和 OpenShift Elasticsearch Operator。

流程

  1. 进入 openshift-logging 项目。

    $ oc project openshift-logging
  2. 查看日志记录环境的状态:

    $ oc describe deployment cluster-logging-operator

    输出示例

    Name:                   cluster-logging-operator
    
    ....
    
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    
    ....
    
    Events:
      Type    Reason             Age   From                   Message
      ----    ------             ----  ----                   -------
      Normal  ScalingReplicaSet  62m   deployment-controller  Scaled up replica set cluster-logging-operator-574b8987df to 1----

  3. 查看日志记录副本集的状态:

    1. 获取副本集的名称:

      输出示例

      $ oc get replicaset

      输出示例

      NAME                                      DESIRED   CURRENT   READY   AGE
      cluster-logging-operator-574b8987df       1         1         1       159m
      elasticsearch-cdm-uhr537yu-1-6869694fb    1         1         1       157m
      elasticsearch-cdm-uhr537yu-2-857b6d676f   1         1         1       156m
      elasticsearch-cdm-uhr537yu-3-5b6fdd8cfd   1         1         1       155m
      kibana-5bd5544f87                         1         1         1       157m

    2. 获取副本集的状态:

      $ oc describe replicaset cluster-logging-operator-574b8987df

      输出示例

      Name:           cluster-logging-operator-574b8987df
      
      ....
      
      Replicas:       1 current / 1 desired
      Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed
      
      ....
      
      Events:
        Type    Reason            Age   From                   Message
        ----    ------            ----  ----                   -------
        Normal  SuccessfulCreate  66m   replicaset-controller  Created pod: cluster-logging-operator-574b8987df-qjhqv----

3.2. 日志转发故障排除

3.2.1. 重新部署 Fluentd pod

当您创建 ClusterLogForwarder 自定义资源 (CR) 时,如果 Red Hat OpenShift Logging Operator 没有自动重新部署 Fluentd Pod,您可以删除 Fluentd Pod 来强制重新部署它们。

先决条件

  • 您已创建了 ClusterLogForwarder 自定义资源 (CR) 对象。

流程

  • 运行以下命令,删除 Fluentd pod 以强制重新部署:

    $ oc delete pod --selector logging-infra=collector

3.2.2. 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 中的 ingestionBurstSizeingestionRate 字段:

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

3.3. 日志记录警报故障排除

您可以使用以下步骤排除集群中的日志记录警报。

3.3.1. Elasticsearch 集群健康状态为红色

至少一个主分片及其副本没有分配给节点。使用以下步骤对此警报进行故障排除。

提示

本文档中的一些命令会使用 $ES_POD_NAME shell 变量来引用 Elasticsearch pod。如果要直接从本文档中复制并粘贴命令,您必须将此变量设置为对 Elasticsearch 集群有效的值。

您可以运行以下命令来列出可用的 Elasticsearch pod:

$ oc -n openshift-logging get pods -l component=elasticsearch

运行以下命令,选择列出的 pod 并设置 $ES_POD_NAME 变量:

$ export ES_POD_NAME=<elasticsearch_pod_name>

现在,您可以在命令中使用 $ES_POD_NAME 变量。

流程

  1. 运行以下命令,检查 Elasticsearch 集群健康状况并验证集群状态是否为红色:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- health
  2. 运行以下命令,列出已加入集群的节点:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cat/nodes?v
  3. 运行以下命令,列出 Elasticsearch Pod,并将它们与上一步中的命令输出中的节点进行比较:

    $ oc -n openshift-logging get pods -l component=elasticsearch
  4. 如果某些 Elasticsearch 节点没有加入集群,请执行以下步骤。

    1. 运行以下命令并查看输出,确认 Elasticsearch 已选定 master 节点:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=_cat/master?v
    2. 运行以下命令,并查看所选 master 节点的 pod 日志问题:

      $ oc logs <elasticsearch_master_pod_name> -c elasticsearch -n openshift-logging
    3. 运行以下命令并查看没有加入集群的节点日志:

      $ oc logs <elasticsearch_node_name> -c elasticsearch -n openshift-logging
  5. 如果所有节点都已加入集群,请运行以下命令检查集群是否处于恢复过程中,并观察输出:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cat/recovery?active_only=true

    如果没有命令输出,恢复过程可能会因为待处理的任务而延迟或停止。

  6. 运行以下命令并查看输出,检查是否有待处理的任务:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- health | grep number_of_pending_tasks
  7. 如果有待处理的任务,请监控其状态。如果它们的状态发生变化,并且表示集群正在恢复,请继续等待。恢复时间因集群大小和其它因素而异。否则,如果待处理任务的状态没有改变,这表示恢复已停止。
  8. 如果恢复似乎已停止,请运行以下命令检查 cluster.routing.allocation.enable 值设置为 none,然后观察输出:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cluster/settings?pretty
  9. 如果 cluster.routing.allocation.enable 被设为 none,请运行以下命令将其设置为 all

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cluster/settings?pretty \
      -X PUT -d '{"persistent": {"cluster.routing.allocation.enable":"all"}}'
  10. 运行以下命令并查看输出,检查任何索引仍然是红色的:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cat/indices?v
  11. 如果有任何索引仍然是红色的,请尝试通过执行以下步骤清除它们。

    1. 运行以下命令来清除缓存:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name>/_cache/clear?pretty
    2. 运行以下命令来增加最大分配重试次数:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name>/_settings?pretty \
        -X PUT -d '{"index.allocation.max_retries":10}'
    3. 运行以下命令来删除所有滚动项:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=_search/scroll/_all -X DELETE
    4. 运行以下命令来增加超时:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name>/_settings?pretty \
        -X PUT -d '{"index.unassigned.node_left.delayed_timeout":"10m"}'
  12. 如果前面的步骤没有清除红色索引,请单独删除索引。

    1. 运行以下命令来识别红色索引名称:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=_cat/indices?v
    2. 运行以下命令来删除红色索引:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_red_index_name> -X DELETE
  13. 如果没有红色索引且集群状态为红色,请在数据节点上检查是否有连续重量处理负载。

    1. 运行以下命令,检查 Elasticsearch JVM 堆使用率是否高:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=_nodes/stats?pretty

      在命令输出中,检查 node_name.jvm.mem.heap_used_percent 字段,以确定 JVM Heap 使用量。

    2. 检查高 CPU 使用率。如需有关 CPU 利用率的更多信息,请参阅 OpenShift Container Platform "查看监控仪表板"文档。

3.3.2. Elasticsearch 集群健康状态黄色

至少一个主分片的副本分片没有分配给节点。通过调整 ClusterLogging 自定义资源 (CR) 中的 nodeCount 值来增加节点数。

3.3.3. 已达到 Elasticsearch 节点磁盘低水位线

Elasticsearch 不会将分片分配给达到低水位线的节点。

提示

本文档中的一些命令会使用 $ES_POD_NAME shell 变量来引用 Elasticsearch pod。如果要直接从本文档中复制并粘贴命令,您必须将此变量设置为对 Elasticsearch 集群有效的值。

您可以运行以下命令来列出可用的 Elasticsearch pod:

$ oc -n openshift-logging get pods -l component=elasticsearch

运行以下命令,选择列出的 pod 并设置 $ES_POD_NAME 变量:

$ export ES_POD_NAME=<elasticsearch_pod_name>

现在,您可以在命令中使用 $ES_POD_NAME 变量。

流程

  1. 运行以下命令,识别在其上部署 Elasticsearch 的节点:

    $ oc -n openshift-logging get po -o wide
  2. 运行以下命令,检查是否有未分配的分片:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cluster/health?pretty | grep unassigned_shards
  3. 如果存在未分配的分片,请运行以下命令检查每个节点上的磁盘空间:

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
      do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
      -- df -h /elasticsearch/persistent; done
  4. 在命令输出中,检查 Use 列以确定该节点上使用的磁盘百分比。

    输出示例

    elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
    elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
    elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent

    如果使用的磁盘百分比超过 85%,则节点已超过低水位线,并且分片无法再分配给此节点。

  5. 要检查当前的 redundancyPolicy,请运行以下命令:

    $ oc -n openshift-logging get es elasticsearch \
      -o jsonpath='{.spec.redundancyPolicy}'

    如果在集群中使用 ClusterLogging 资源,请运行以下命令:

    $ oc -n openshift-logging get cl \
      -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

    如果集群 redundancyPolicy 值高于 SingleRedundancy 值,将其设置为 SingleRedundancy 值并保存这个更改。

  6. 如果前面的步骤没有解决这个问题,请删除旧的索引。

    1. 运行以下命令,检查 Elasticsearch 上所有索引的状态:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
    2. 确定可以删除的旧索引。
    3. 运行以下命令来删除索引:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE

3.3.4. 已达到 Elasticsearch 节点磁盘高水位线

Elasticsearch 会尝试将分片从达到高水位线的节点重新定位到磁盘使用率较低且未超过任何水位线阈值的节点。

要将分片分配给特定节点,您必须释放该节点上的一些空间。如果无法增加磁盘空间,请尝试向集群添加新数据节点,或者减少集群冗余策略总数。

提示

本文档中的一些命令会使用 $ES_POD_NAME shell 变量来引用 Elasticsearch pod。如果要直接从本文档中复制并粘贴命令,您必须将此变量设置为对 Elasticsearch 集群有效的值。

您可以运行以下命令来列出可用的 Elasticsearch pod:

$ oc -n openshift-logging get pods -l component=elasticsearch

运行以下命令,选择列出的 pod 并设置 $ES_POD_NAME 变量:

$ export ES_POD_NAME=<elasticsearch_pod_name>

现在,您可以在命令中使用 $ES_POD_NAME 变量。

流程

  1. 运行以下命令,识别在其上部署 Elasticsearch 的节点:

    $ oc -n openshift-logging get po -o wide
  2. 检查每个节点上的磁盘空间:

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
      do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
      -- df -h /elasticsearch/persistent; done
  3. 检查集群是否重新平衡:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_cluster/health?pretty | grep relocating_shards

    如果命令输出显示重新定位分片,则代表超过了高水位线。高水位线的默认值为 90%。

  4. 增加所有节点上的磁盘空间。如果无法增加磁盘空间,请尝试向集群添加新数据节点,或者减少集群冗余策略总数。
  5. 要检查当前的 redundancyPolicy,请运行以下命令:

    $ oc -n openshift-logging get es elasticsearch \
      -o jsonpath='{.spec.redundancyPolicy}'

    如果在集群中使用 ClusterLogging 资源,请运行以下命令:

    $ oc -n openshift-logging get cl \
      -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

    如果集群 redundancyPolicy 值高于 SingleRedundancy 值,将其设置为 SingleRedundancy 值并保存这个更改。

  6. 如果前面的步骤没有解决这个问题,请删除旧的索引。

    1. 运行以下命令,检查 Elasticsearch 上所有索引的状态:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
    2. 确定可以删除的旧索引。
    3. 运行以下命令来删除索引:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE

3.3.5. 已达到 Elasticsearch 节点磁盘水位线

Elasticsearch 在每个具有这两个条件的索引中强制使用只读索引块:

  • 为节点分配一个或多个分片。
  • 一个个或多个磁盘超过 flood stage

使用以下步骤对此警报进行故障排除。

提示

本文档中的一些命令会使用 $ES_POD_NAME shell 变量来引用 Elasticsearch pod。如果要直接从本文档中复制并粘贴命令,您必须将此变量设置为对 Elasticsearch 集群有效的值。

您可以运行以下命令来列出可用的 Elasticsearch pod:

$ oc -n openshift-logging get pods -l component=elasticsearch

运行以下命令,选择列出的 pod 并设置 $ES_POD_NAME 变量:

$ export ES_POD_NAME=<elasticsearch_pod_name>

现在,您可以在命令中使用 $ES_POD_NAME 变量。

流程

  1. 获取 Elasticsearch 节点的磁盘空间:

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
      do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
      -- df -h /elasticsearch/persistent; done
  2. 在命令输出中,检查 Avail 列以确定该节点上的可用磁盘空间。

    输出示例

    elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
    elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
    elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent

  3. 增加所有节点上的磁盘空间。如果无法增加磁盘空间,请尝试向集群添加新数据节点,或者减少集群冗余策略总数。
  4. 要检查当前的 redundancyPolicy,请运行以下命令:

    $ oc -n openshift-logging get es elasticsearch \
      -o jsonpath='{.spec.redundancyPolicy}'

    如果在集群中使用 ClusterLogging 资源,请运行以下命令:

    $ oc -n openshift-logging get cl \
      -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

    如果集群 redundancyPolicy 值高于 SingleRedundancy 值,将其设置为 SingleRedundancy 值并保存这个更改。

  5. 如果前面的步骤没有解决这个问题,请删除旧的索引。

    1. 运行以下命令,检查 Elasticsearch 上所有索引的状态:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
    2. 确定可以删除的旧索引。
    3. 运行以下命令来删除索引:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE
  6. 继续释放和监控磁盘空间。在使用的磁盘空间低于 90% 后,运行以下命令来取消阻塞写入此节点:

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
      -- es_util --query=_all/_settings?pretty \
      -X PUT -d '{"index.blocks.read_only_allow_delete": null}'

3.3.6. Elasticsearch JVM 堆使用率很高

使用的 Elasticsearch 节点 Java 虚拟机(JVM)堆内存超过 75%。考虑增大堆大小

3.3.7. 聚合日志记录系统 CPU 为高

节点上的系统 CPU 使用率高。检查集群节点的 CPU。考虑向节点分配更多 CPU 资源。

3.3.8. Elasticsearch 进程 CPU 为高

节点上的 Elasticsearch 进程 CPU 使用率很高。检查集群节点的 CPU。考虑向节点分配更多 CPU 资源。

3.3.9. Elasticsearch 磁盘空间运行较低

根据当前的磁盘用量,Elasticsearch 被预测在下一个 6 小时内耗尽磁盘空间。使用以下步骤对此警报进行故障排除。

流程

  1. 获取 Elasticsearch 节点的磁盘空间:

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
      do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
      -- df -h /elasticsearch/persistent; done
  2. 在命令输出中,检查 Avail 列以确定该节点上的可用磁盘空间。

    输出示例

    elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
    elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
    elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent

  3. 增加所有节点上的磁盘空间。如果无法增加磁盘空间,请尝试向集群添加新数据节点,或者减少集群冗余策略总数。
  4. 要检查当前的 redundancyPolicy,请运行以下命令:

    $ oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'

    如果在集群中使用 ClusterLogging 资源,请运行以下命令:

    $ oc -n openshift-logging get cl \
      -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

    如果集群 redundancyPolicy 值高于 SingleRedundancy 值,将其设置为 SingleRedundancy 值并保存这个更改。

  5. 如果前面的步骤没有解决这个问题,请删除旧的索引。

    1. 运行以下命令,检查 Elasticsearch 上所有索引的状态:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
    2. 确定可以删除的旧索引。
    3. 运行以下命令来删除索引:

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
        -- es_util --query=<elasticsearch_index_name> -X DELETE

3.3.10. Elasticsearch FileDescriptor 使用是高

根据当前的使用趋势,预计节点上的文件描述符数量不足。检查每个节点的 max_file_descriptors 值,如 Elasticsearch File Descriptors 文档中所述。

3.4. 查看 Elasticsearch 日志存储的状态

您可以查看 OpenShift Elasticsearch Operator 的状态以及多个 Elasticsearch 组件的状态。

3.4.1. 查看 Elasticsearch 日志存储的状态

您可以查看 Elasticsearch 日志存储的状态。

先决条件

  • 安装了 Red Hat OpenShift Logging Operator 和 OpenShift Elasticsearch Operator。

流程

  1. 运行以下命令,切换到 openshift-logging 项目:

    $ oc project openshift-logging
  2. 查看状态:

    1. 运行以下命令,获取 Elasticsearch 日志存储实例的名称:

      $ oc get Elasticsearch

      输出示例

      NAME            AGE
      elasticsearch   5h9m

    2. 运行以下命令来获取 Elasticsearch 日志存储状态:

      $ oc get Elasticsearch <Elasticsearch-instance> -o yaml

      例如:

      $ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml

      输出中包含类似于如下的信息:

      输出示例

      status: 1
        cluster: 2
          activePrimaryShards: 30
          activeShards: 60
          initializingShards: 0
          numDataNodes: 3
          numNodes: 3
          pendingTasks: 0
          relocatingShards: 0
          status: green
          unassignedShards: 0
        clusterHealth: ""
        conditions: [] 3
        nodes: 4
        - deploymentName: elasticsearch-cdm-zjf34ved-1
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-2
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-3
          upgradeStatus: {}
        pods: 5
          client:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          data:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          master:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
        shardAllocationEnabled: all

      1
      在输出中,集群状态字段显示在 status 小节中。
      2
      Elasticsearch 日志存储的状态:
      • 活跃的主分片的数量。
      • 活跃分片的数量。
      • 正在初始化的分片的数量。
      • Elasticsearch 日志存储数据节点的数量。
      • Elasticsearch 日志存储节点的总数。
      • 待处理的任务数量。
      • Elasticsearch 日志存储状态: 绿色红色黄色
      • 未分配分片的数量。
      3
      任何状态条件(若存在)。Elasticsearch 日志存储状态指示在无法放置 pod 时来自于调度程序的原因。显示与以下情况有关的所有事件:
      • 容器正在等待 Elasticsearch 日志存储和代理容器。
      • Elasticsearch 日志存储和代理容器的容器终止。
      • Pod 不可调度。此外还显示适用于多个问题的情况,具体请参阅情况消息示例
      4
      集群中的 Elasticsearch 日志存储节点,带有 upgradeStatus
      5
      Elasticsearch 日志存储在集群中的客户端、数据和 master pod,列在 failednotReadyready 状态下。
3.4.1.1. 情况消息示例

以下是来自 Elasticsearch 实例的 Status 部分的一些情况消息的示例。

以下状态消息表示节点已超过配置的低水位线,并且没有分片将分配给此节点。

status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}

以下状态消息表示节点已超过配置的高水位线,并且分片将重新定位到其他节点。

status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}

以下状态消息表示自定义资源(CR)中的 Elasticsearch 日志存储节点选择器与集群中的任何节点都不匹配:

status:
    nodes:
    - conditions:
      - lastTransitionTime: 2019-04-10T02:26:24Z
        message: '0/8 nodes are available: 8 node(s) didn''t match node selector.'
        reason: Unschedulable
        status: "True"
        type: Unschedulable

以下状态消息表示 Elasticsearch 日志存储 CR 使用不存在的持久性卷声明(PVC)。

status:
   nodes:
   - conditions:
     - last Transition Time:  2019-04-10T05:55:51Z
       message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
       reason:                Unschedulable
       status:                True
       type:                  Unschedulable

以下状态消息表示 Elasticsearch 日志存储集群没有足够的节点来支持冗余策略。

status:
  clusterHealth: ""
  conditions:
  - lastTransitionTime: 2019-04-17T20:01:31Z
    message: Wrong RedundancyPolicy selected. Choose different RedundancyPolicy or
      add more nodes with data roles
    reason: Invalid Settings
    status: "True"
    type: InvalidRedundancy

此状态消息表示集群有太多 control plane 节点:

status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: '2019-04-17T20:12:34Z'
      message: >-
        Invalid master nodes count. Please ensure there are no more than 3 total
        nodes with master roles
      reason: Invalid Settings
      status: 'True'
      type: InvalidMasters

以下状态消息表示 Elasticsearch 存储不支持您尝试进行的更改。

例如:

status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: "2021-05-07T01:05:13Z"
      message: Changing the storage structure for a custom resource is not supported
      reason: StorageStructureChangeIgnored
      status: 'True'
      type: StorageStructureChangeIgnored

reasontype 类型字段指定不受支持的更改类型:

StorageClassNameChangeIgnored
不支持更改存储类名称。
StorageSizeChangeIgnored
不支持更改存储大小。
StorageStructureChangeIgnored

不支持在临时存储结构和持久性存储结构间更改。

重要

如果您尝试将 ClusterLogging CR 配置为从临时切换到持久性存储,OpenShift Elasticsearch Operator 会创建一个持久性卷声明(PVC),但不创建持久性卷(PV)。要清除 StorageStructureChangeIgnored 状态,您必须恢复对 ClusterLogging CR 的更改并删除 PVC。

3.4.2. 查看日志存储组件的状态

您可以查看多个日志存储组件的状态。

Elasticsearch 索引

您可以查看 Elasticsearch 索引的状态。

  1. 获取 Elasticsearch Pod 的名称:

    $ oc get pods --selector component=elasticsearch -o name

    输出示例

    pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
    pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n
    pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7

  2. 获取索引的状态:

    $ oc exec elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -- indices

    输出示例

    Defaulting container name to elasticsearch.
    Use 'oc describe pod/elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -n openshift-logging' to see all of the containers in this pod.
    
    green  open   infra-000002                                                     S4QANnf1QP6NgCegfnrnbQ   3   1     119926            0        157             78
    green  open   audit-000001                                                     8_EQx77iQCSTzFOXtxRqFw   3   1          0            0          0              0
    green  open   .security                                                        iDjscH7aSUGhIdq0LheLBQ   1   1          5            0          0              0
    green  open   .kibana_-377444158_kubeadmin                                     yBywZ9GfSrKebz5gWBZbjw   3   1          1            0          0              0
    green  open   infra-000001                                                     z6Dpe__ORgiopEpW6Yl44A   3   1     871000            0        874            436
    green  open   app-000001                                                       hIrazQCeSISewG3c2VIvsQ   3   1       2453            0          3              1
    green  open   .kibana_1                                                        JCitcBMSQxKOvIq6iQW6wg   1   1          0            0          0              0
    green  open   .kibana_-1595131456_user1                                        gIYFIEGRRe-ka0W3okS-mQ   3   1          1            0          0              0

日志存储 pod

您可以查看托管日志存储的 pod 的状态。

  1. 获取 Pod 的名称:

    $ oc get pods --selector component=elasticsearch -o name

    输出示例

    pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
    pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n
    pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7

  2. 获取 Pod 的状态:

    $ oc describe pod elasticsearch-cdm-1godmszn-1-6f8495-vp4lw

    输出中包括以下状态信息:

    输出示例

    ....
    Status:             Running
    
    ....
    
    Containers:
      elasticsearch:
        Container ID:   cri-o://b7d44e0a9ea486e27f47763f5bb4c39dfd2
        State:          Running
          Started:      Mon, 08 Jun 2020 10:17:56 -0400
        Ready:          True
        Restart Count:  0
        Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3
    
    ....
    
      proxy:
        Container ID:  cri-o://3f77032abaddbb1652c116278652908dc01860320b8a4e741d06894b2f8f9aa1
        State:          Running
          Started:      Mon, 08 Jun 2020 10:18:38 -0400
        Ready:          True
        Restart Count:  0
    
    ....
    
    Conditions:
      Type              Status
      Initialized       True
      Ready             True
      ContainersReady   True
      PodScheduled      True
    
    ....
    
    Events:          <none>

日志存储 pod 部署配置

您可以查看日志存储部署配置的状态。

  1. 获取部署配置的名称:

    $ oc get deployment --selector component=elasticsearch -o name

    输出示例

    deployment.extensions/elasticsearch-cdm-1gon-1
    deployment.extensions/elasticsearch-cdm-1gon-2
    deployment.extensions/elasticsearch-cdm-1gon-3

  2. 获取部署配置状态:

    $ oc describe deployment elasticsearch-cdm-1gon-1

    输出中包括以下状态信息:

    输出示例

    ....
      Containers:
       elasticsearch:
        Image:      registry.redhat.io/openshift-logging/elasticsearch6-rhel8
        Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3
    
    ....
    
    Conditions:
      Type           Status   Reason
      ----           ------   ------
      Progressing    Unknown  DeploymentPaused
      Available      True     MinimumReplicasAvailable
    
    ....
    
    Events:          <none>

日志存储副本集

您可以查看日志存储副本集的状态。

  1. 获取副本集的名称:

    $ oc get replicaSet --selector component=elasticsearch -o name
    
    replicaset.extensions/elasticsearch-cdm-1gon-1-6f8495
    replicaset.extensions/elasticsearch-cdm-1gon-2-5769cf
    replicaset.extensions/elasticsearch-cdm-1gon-3-f66f7d
  2. 获取副本集的状态:

    $ oc describe replicaSet elasticsearch-cdm-1gon-1-6f8495

    输出中包括以下状态信息:

    输出示例

    ....
      Containers:
       elasticsearch:
        Image:      registry.redhat.io/openshift-logging/elasticsearch6-rhel8@sha256:4265742c7cdd85359140e2d7d703e4311b6497eec7676957f455d6908e7b1c25
        Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3
    
    ....
    
    Events:          <none>

3.4.3. Elasticsearch 集群状态

OpenShift Container Platform Web 控制台的 Observe 部分中的仪表板显示 Elasticsearch 集群的状态。

要获取 OpenShift Elasticsearch 集群的状态,请访问位于 <cluster_url>/monitoring/dashboards/grafana-dashboard-cluster-logging 的 OpenShift Container Platform Web 控制台的 Observe 部分中的 Grafana 仪表板。

Elasticsearch 状态字段

eo_elasticsearch_cr_cluster_management_state

显示 Elasticsearch 集群是否处于受管状态或非受管状态。例如:

eo_elasticsearch_cr_cluster_management_state{state="managed"} 1
eo_elasticsearch_cr_cluster_management_state{state="unmanaged"} 0
eo_elasticsearch_cr_restart_total

显示 Elasticsearch 节点重启证书、滚动重启或调度重启的次数。例如:

eo_elasticsearch_cr_restart_total{reason="cert_restart"} 1
eo_elasticsearch_cr_restart_total{reason="rolling_restart"} 1
eo_elasticsearch_cr_restart_total{reason="scheduled_restart"} 3
es_index_namespaces_total

显示 Elasticsearch 索引命名空间的总数。例如:

Total number of Namespaces.
es_index_namespaces_total 5
es_index_document_count

显示每个命名空间的记录数。例如:

es_index_document_count{namespace="namespace_1"} 25
es_index_document_count{namespace="namespace_2"} 10
es_index_document_count{namespace="namespace_3"} 5

"Secret Elasticsearch fields are either missing or empty" 信息

如果 Elasticsearch 缺少 admin-certadmin-keylogging-es.crtlogging-es.key 文件,仪表板会显示类似以下示例的状态消息:

message": "Secret \"elasticsearch\" fields are either missing or empty: [admin-cert, admin-key, logging-es.crt, logging-es.key]",
"reason": "Missing Required Secrets",

第 4 章 关于日志记录

作为集群管理员,您可以在 OpenShift Container Platform 集群上部署 logging,并使用它来收集和聚合节点系统日志、应用程序容器日志和基础架构日志。您可以将日志转发到所选的日志输出,包括在线集群、红帽管理的日志存储。您还可以视觉化 OpenShift Container Platform Web 控制台或 Kibana Web 控制台中的日志数据,具体取决于您部署的日志存储解决方案。

注意

Kibana Web 控制台现已弃用,计划在以后的日志记录发行版本中删除。

OpenShift Container Platform 集群管理员可以使用 Operator 部署日志记录。如需更多信息,请参阅安装日志记录

Operator 负责部署、升级和维护日志记录。安装 Operator 后,您可以创建一个 ClusterLogging 自定义资源(CR)来调度日志记录 pod 和支持日志记录所需的其他资源。您还可以创建一个 ClusterLogForwarder CR 来指定收集哪些日志、如何转换日志以及它们被转发到的位置。

注意

由于内部 OpenShift Container Platform Elasticsearch 日志存储无法为审计日志提供安全存储,所以审计日志默认不会存储在内部 Elasticsearch 实例中。如果要将审计日志发送到默认的内部 Elasticsearch 日志存储,例如要在 Kibana 中查看审计日志,则必须使用 Log Forwarding API,如 将审计日志转发到日志存储 中所述。

4.1. 日志记录架构

日志记录的主要组件有:

Collector

收集器是一个 daemonset,它将 pod 部署到每个 OpenShift Container Platform 节点。它从每个节点收集日志数据,转换数据并将其转发到配置的输出。您可以使用 Vector 收集器或旧的 Fluentd 收集器。

注意

Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

日志存储

日志存储存储用于分析的日志数据,是日志转发器的默认输出。您可以使用默认的 LokiStack 日志存储、传统的 Elasticsearch 日志存储,或将日志转发到额外的外部日志存储。

注意

Logging 5.9 发行版本不包含 OpenShift Elasticsearch Operator 的更新版本。如果您目前使用随 Logging 5.8 发布的 OpenShift Elasticsearch Operator,它将继续使用 Logging,直到 Logging 5.8 的 EOL 为止。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。如需有关日志记录生命周期日期的更多信息,请参阅平台 Agnostic Operator

视觉化

您可以使用 UI 组件查看日志数据的可视化表示。UI 提供了一个图形界面,用于搜索、查询和查看存储的日志。OpenShift Container Platform Web 控制台 UI 通过启用 OpenShift Container Platform 控制台插件来提供。

注意

Kibana Web 控制台现已弃用,计划在以后的日志记录发行版本中删除。

日志记录收集容器日志和节点日志。它们被归类为:

应用程序日志
由集群中运行的用户应用程序生成的容器日志(基础架构容器应用程序除外)。
基础架构日志
由基础架构命名空间生成的容器日志: openshift*kube*default,以及来自节点的 journald 信息。
审计日志
由 auditd 生成的日志,节点审计系统存储在 /var/log/audit/audit.log 文件中,以及 auditdkube-apiserveropenshift-apiserver 服务以及 ovn 项目(如果启用)中的日志。

4.2. 关于部署日志记录

管理员可以使用 OpenShift Container Platform Web 控制台或 OpenShift CLI (oc) 来安装 logging Operator。Operator 负责部署、升级和维护日志记录。

管理员和应用程序开发人员可以查看他们具有查看访问权限的项目的日志。

4.2.1. 日志记录自定义资源

您可以使用每个 Operator 实施的自定义资源 (CR) YAML 文件配置日志记录部署。

Red Hat OpenShift Logging Operator

  • ClusterLogging (CL) - 安装 Operator 后,您可以创建一个 ClusterLogging 自定义资源 (CR) 来调度 logging pod 和支持 logging 所需的其他资源。ClusterLogging CR 部署收集器和转发器,当前都由每个节点上运行的 daemonset 实施。Red Hat OpenShift Logging Operator 会监视 ClusterLogging CR,并相应地调整日志记录部署。
  • ClusterLogForwarder (CLF)- 生成收集器配置,以为每个用户配置转发日志。

Loki Operator

  • LokiStack - 将 Loki 集群控制为日志存储,以及带有 OpenShift Container Platform 身份验证集成的 Web 代理,以强制实施多租户。

OpenShift Elasticsearch Operator

注意

这些 CR 由 OpenShift Elasticsearch Operator 生成和管理。在 Operator 被覆盖的情况下,无法进行手动更改。

  • Elasticsearch - 配置和部署 Elasticsearch 实例作为默认日志存储。
  • Kibana - 配置和部署 Kibana 实例以搜索、查询和查看日志。

4.2.2. 关于 JSON OpenShift Container Platform Logging

您可以使用 JSON 日志记录配置 Log Forwarding API,将 JSON 字符串解析为结构化对象。您可以执行以下任务:

  • 解析 JSON 日志
  • 为 Elasticsearch 配置 JSON 日志数据
  • 将 JSON 日志转发到 Elasticsearch 日志存储

4.2.3. 关于收集并存储 Kubernetes 事件

OpenShift Container Platform 事件路由器是一个 pod,它监视 Kubernetes 事件,并在 OpenShift Container Platform Logging 中记录它们以收集。您必须手动部署 Event Router。

如需更多信息,请参阅关于收集和存储 Kubernetes 事件

4.2.4. 关于 OpenShift Container Platform Logging 故障排除

您可以通过执行以下任务排除日志问题:

  • 查看日志记录状态
  • 查看日志存储的状态
  • 了解日志记录警报
  • 为红帽支持收集日志记录数据
  • 关键警报故障排除

4.2.5. 关于导出字段

日志记录系统导出字段。导出的字段出现在日志记录中,可从 Elasticsearch 和 Kibana 搜索。

如需更多信息,请参阅关于导出字段

4.2.6. 关于事件路由

Event Router 是一个 pod,它监视 OpenShift Container Platform 事件,以便通过日志记录来收集这些事件。Event Router 从所有项目收集事件,并将其写入 STDOUT。Fluentd 收集这些事件并将其转发到 OpenShift Container Platform Elasticsearch 实例。Elasticsearch 将事件索引到 infra 索引。

您必须手动部署 Event Router。

如需更多信息,请参阅收集并存储 Kubernetes 事件

第 5 章 安装日志记录

您可以通过安装 Red Hat OpenShift Logging Operator 来部署日志记录。Red Hat OpenShift Logging Operator 会创建和管理日志记录堆栈的组件。

注意

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

重要

对于新安装,使用 Vector 和 LokiStack。Elasticsearch 和 Fluentd 已被弃用,计划在以后的发行版本中删除。

5.1. 使用 Web 控制台安装 Red Hat OpenShift Logging Operator

您可以使用 OpenShift Container Platform Web 控制台安装 Red Hat OpenShift Logging Operator。

先决条件

  • 有管理员权限。
  • 访问 OpenShift Container Platform web 控制台。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. Filter by keyword 框中键入 OpenShift Logging
  3. 从可用的 Operator 列表中选择 Red Hat OpenShift Logging,然后点 Install
  4. 选择 stable-5.y 作为 更新频道

    注意

    stable 频道只为日志记录的最新版本提供更新。要继续获得之前版本的更新,您必须将订阅频道改为 stable-x.y,其中 x.y 代表您安装的日志记录的主版本和次版本。例如,stable-5.7

  5. 选择 版本
  6. 确定在 Installation mode 下选择了 A specific namespace on the cluster
  7. 确定在 Installed Namespace 下的 Operator recommended namespaceopenshift-logging
  8. 选择一个 Update approval

    • Automatic 策略允许 Operator Lifecycle Manager(OLM)在有新版本可用时自动更新 Operator。
    • Manual 策略需要拥有适当凭证的用户批准 Operator 更新。
  9. Console 插件选择 EnableDisable
  10. Install

验证

  1. 通过切换到 OperatorsInstalled Operators 页来验证 Red Hat OpenShift Logging Operator 是否已安装。
  2. Status 列中,验证您看到了绿色的对勾标记,并为 InstallSucceeded,文本 Up to date
重要

Operator 可能会在安装完成前显示 Failed 状态。如果 Operator 安装完成并显示 InstallSucceeded 信息,请刷新页面。

如果 Operator 没有显示已安装状态,请选择以下故障排除选项之一:

  • 进入 OperatorsInstalled Operators 页面,检查 Status 列中是否有任何错误或故障。
  • 进入 WorkloadsPods 页面,检查 openshift-logging 项目中报告问题的 pod 的日志。

5.2. 使用 Web 控制台创建 ClusterLogging 对象

安装日志记录 Operator 后,您必须创建一个 ClusterLogging 自定义资源来为集群配置日志存储、视觉化和日志收集器。

先决条件

  • 已安装 Red Hat OpenShift Logging Operator。
  • 您可以访问 OpenShift Container Platform Web 控制台 Administrator 视角。

流程

  1. 进入 Custom Resource Definitions 页面。
  2. Custom Resource Definitions 页面上,点 ClusterLogging
  3. Custom Resource Definition details 页中,从 Actions 菜单中选择 View Instances
  4. ClusterLoggings 页中,点 Create ClusterLogging
  5. collection 部分中,选择一个 Collector Implementation

    注意

    Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

  6. logStore 部分中,选择一个类型。

    注意

    Logging 5.9 发行版本不包含 OpenShift Elasticsearch Operator 的更新版本。如果您目前使用随 Logging 5.8 发布的 OpenShift Elasticsearch Operator,它将继续使用 Logging,直到 Logging 5.8 的 EOL 为止。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。如需有关日志记录生命周期日期的更多信息,请参阅平台 Agnostic Operator

  7. Create

5.3. 使用 CLI 安装 Red Hat OpenShift Logging Operator

您可以使用 OpenShift CLI (oc) 安装 Red Hat OpenShift Logging Operator。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 创建一个 Namespace 对象作为一个 YAML 文件:

    Namespace 对象示例

    apiVersion: v1
    kind: Namespace
    metadata:
      name: <name> 1
      annotations:
        openshift.io/node-selector: ""
      labels:
        openshift.io/cluster-monitoring: "true"

    1
    您必须将 openshift-logging 指定为日志记录版本 5.7 及更早的版本的命名空间名称。对于日志记录 5.8 及更新的版本,您可以使用任何名称。
  2. 运行以下命令来应用 Namespace 对象:

    $ oc apply -f <filename>.yaml
  3. 以 YAML 文件形式创建 OperatorGroup 对象:

    OperatorGroup 对象示例

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: cluster-logging
      namespace: openshift-logging 1
    spec:
      targetNamespaces:
      - openshift-logging 2

    1 2
    您必须为日志记录版本 5.7 及更早的版本指定 openshift-logging 命名空间。对于日志记录 5.8 及更新的版本,您可以使用任何命名空间。
  4. 运行以下命令来应用 OperatorGroup 对象:

    $ oc apply -f <filename>.yaml
  5. 创建一个 Subscription 对象来订阅 Red Hat OpenShift Logging Operator 的命名空间:

    Subscription 对象示例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: cluster-logging
      namespace: openshift-logging 1
    spec:
      channel: stable 2
      name: cluster-logging
      source: redhat-operators 3
      sourceNamespace: openshift-marketplace

    1
    您必须为日志记录版本 5.7 及更早的版本指定 openshift-logging 命名空间。对于日志记录 5.8 及更新的版本,您可以使用任何命名空间。
    2
    指定 stablestable-x.y 作为频道。
    3
    指定 redhat-operators。如果 OpenShift Container Platform 集群安装在受限网络中(也称为断开连接的集群),请指定配置 Operator Lifecycle Manager (OLM) 时创建的 CatalogSource 对象的名称。
  6. 运行以下命令来应用订阅:

    $ oc apply -f <filename>.yaml

    Red Hat OpenShift Logging Operator 已安装到 openshift-logging 命名空间中。

验证

  1. 运行以下命令:

    $ oc get csv -n <namespace>
  2. 观察输出,并确认命名空间中存在 Red Hat OpenShift Logging Operator:

    输出示例

    NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
    ...
    openshift-logging                                       clusterlogging.5.8.0-202007012112.p0         OpenShift Logging          5.8.0-202007012112.p0              Succeeded
    ...

5.4. 使用 CLI 创建 ClusterLogging 对象

此默认日志记录配置支持广泛的环境。参阅有关调优和配置组件的主题,以了解有关您可以进行的修改的信息。

先决条件

  • 已安装 Red Hat OpenShift Logging Operator。
  • 您已为日志存储安装了 OpenShift Elasticsearch Operator。
  • 已安装 OpenShift CLI(oc)。

流程

  1. ClusterLogging 对象创建为 YAML 文件:

    ClusterLogging 对象示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance 1
      namespace: openshift-logging
    spec:
      managementState: Managed 2
      logStore:
        type: elasticsearch 3
        retentionPolicy: 4
          application:
            maxAge: 1d
          infra:
            maxAge: 7d
          audit:
            maxAge: 7d
        elasticsearch:
          nodeCount: 3 5
          storage:
            storageClassName: <storage_class_name> 6
            size: 200G
          resources: 7
              limits:
                memory: 16Gi
              requests:
                memory: 16Gi
          proxy: 8
            resources:
              limits:
                memory: 256Mi
              requests:
                memory: 256Mi
          redundancyPolicy: SingleRedundancy
      visualization:
        type: kibana 9
        kibana:
          replicas: 1
      collection:
        type: fluentd 10
        fluentd: {}

    1
    名称必须是 instance
    2
    OpenShift Logging 管理状态。在一些数情况下,如果更改了 OpenShift Logging 的默认值,则必须将其设置为 Unmanaged。但是,非受管部署不接收更新,直到 OpenShift Logging 重新变为受管状态为止。
    3
    用于配置 Elasticsearch 的设置。通过使用 CR,您可以配置分片复制策略和持久性存储。
    4
    指定 Elasticsearch 应该保留每个日志源的时间长度。输入一个整数和时间单位: 周(w)、小时(h/H)、分钟(m)和秒。例如,7d 代表 7 天。时间超过 maxAge 的旧日志会被删除。您必须为每个日志源指定一个保留策略,否则不会为该源创建 Elasticsearch 索引。
    5
    指定 Elasticsearch 节点的数量。请参阅此列表后面的备注。
    6
    为 Elasticsearch 存储输入现有存储类的名称。为获得最佳性能,请指定分配块存储的存储类。如果没有指定存储类,OpenShift Logging 将使用临时存储。
    7
    根据需要指定 Elasticsearch 的 CPU 和内存请求。如果这些值留白,则 OpenShift Elasticsearch Operator 会设置默认值,它们应足以满足大多数部署的需要。内存请求的默认值为 16Gi,CPU 请求为 1
    8
    根据需要指定 Elasticsearch 代理的 CPU 和内存请求。如果这些值留白,则 OpenShift Elasticsearch Operator 会设置默认值,它们应足以满足大多数部署的需要。内存请求的默认值为 256Mi,CPU 请求的默认值为 100m
    9
    用于配置 Kibana 的设置。通过使用 CR,您可以扩展 Kibana 来实现冗余性,并为 Kibana 节点配置 CPU 和内存。如需更多信息,请参阅配置日志可视化工具
    10
    用于配置 Fluentd 的设置。通过使用 CR,您可以配置 Fluentd CPU 和内存限值。如需更多信息,请参阅"配置 Fluentd"。
    注意

    Elasticsearch control plane 节点的最大数量为三个。如果您将 nodeCount 指定为大于 3,OpenShift Container Platform 只会创建三个符合 Master 节点条件的 Elasticsearch 节点(具有 master、client 和 data 角色)。其他 Elasticsearch 节点使用客户端和数据角色作为仅数据节点创建。control plane 节点执行集群范围的操作,如创建或删除索引、分片分配和跟踪节点。数据节点保管分片,并执行与数据相关的操作,如 CRUD、搜索和聚合等。与数据相关的操作会占用大量 I/O、内存和 CPU。务必要监控这些资源,并在当前节点过载时添加更多数据节点。

    例如,如果 nodeCount = 4,则创建以下节点:

    $ oc get deployment

    输出示例

    NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
    cluster-logging-operator       1/1     1            1           18h
    elasticsearch-cd-x6kdekli-1    1/1     1            1          6m54s
    elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
    elasticsearch-cdm-x6kdekli-2   1/1     1            1           6m49s
    elasticsearch-cdm-x6kdekli-3   1/1     1            1           6m44s

    索引模板的主分片数量等于 Elasticsearch 数据节点的数目。

验证

您可以通过列出 openshift-logging 项目中的 pod 来验证安装。

  • 运行以下命令列出 pod:

    $ oc get pods -n openshift-logging

    观察日志组件的 pod,类似于以下列表:

    输出示例

    NAME                                            READY   STATUS    RESTARTS   AGE
    cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
    elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
    elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
    elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
    collector-587vb                                   1/1     Running   0          2m26s
    collector-7mpb9                                   1/1     Running   0          2m30s
    collector-flm6j                                   1/1     Running   0          2m33s
    collector-gn4rn                                   1/1     Running   0          2m26s
    collector-nlgb6                                   1/1     Running   0          2m30s
    collector-snpkt                                   1/1     Running   0          2m28s
    kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s

5.5. 安装后的任务

安装 Red Hat OpenShift Logging Operator 后,您可以通过创建和修改 ClusterLogging 自定义资源(CR)来配置部署。

提示

如果没有使用 Elasticsearch 日志存储,您可以从 ClusterLogging 自定义资源(CR)中删除内部 Elasticsearch logStore 和 Kibana visualization 组件。删除这些组件是可选的,但会保存资源。请参阅如果没有使用 Elasticsearch 日志存储,删除未使用的组件

5.5.1. 关于 ClusterLogging 自定义资源

要更改日志记录环境,请创建并修改 ClusterLogging 自定义资源(CR)。

ClusterLogging 自定义资源(CR)示例

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  managementState: Managed 3
# ...

1
名称必须是 instance
2
CR 必须安装到 openshift-logging 命名空间。
3
Red Hat OpenShift Logging Operator 管理状态。当状态设置为 unmanaged 时,Operator 处于不支持的状态,且不会接收更新。

5.5.2. 配置日志存储

您可以通过修改 ClusterLogging 自定义资源(CR)来配置日志使用的日志存储类型。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 Red Hat OpenShift Logging Operator 和一个内部日志存储,它是 LokiStack 或 Elasticsearch。
  • 您已创建了 ClusterLogging CR。
注意

Logging 5.9 发行版本不包含 OpenShift Elasticsearch Operator 的更新版本。如果您目前使用随 Logging 5.8 发布的 OpenShift Elasticsearch Operator,它将继续使用 Logging,直到 Logging 5.8 的 EOL 为止。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。如需有关日志记录生命周期日期的更多信息,请参阅平台 Agnostic Operator

流程

  1. 修改 ClusterLogging CR logStore 规格:

    ClusterLogging CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      logStore:
        type: <log_store_type> 1
        elasticsearch: 2
          nodeCount: <integer>
          resources: {}
          storage: {}
          redundancyPolicy: <redundancy_type> 3
        lokistack: 4
          name: {}
    # ...

    1
    指定日志存储类型。这可以是 lokistackelasticsearch
    2
    Elasticsearch 日志存储的可选配置选项。
    3
    指定冗余类型。这个值可以是 ZeroRedundancySingleRedundancyMultipleRedundancyFullRedundancy
    4
    LokiStack 的可选配置选项。

    将 LokiStack 指定为日志存储的 ClusterLogging CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      managementState: Managed
      logStore:
        type: lokistack
        lokistack:
          name: logging-loki
    # ...

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

    $ oc apply -f <filename>.yaml

5.5.3. 配置日志收集器

您可以通过修改 ClusterLogging 自定义资源(CR)来配置日志使用哪个日志收集器类型。

注意

Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 您已创建了 ClusterLogging CR。

流程

  1. 修改 ClusterLogging CR collection 规格:

    ClusterLogging CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      collection:
        type: <log_collector_type> 1
        resources: {}
        tolerations: {}
    # ...

    1
    要用于日志记录的日志收集器类型。这可以是 vectorfluentd
  2. 运行以下命令来应用 ClusterLogging CR:

    $ oc apply -f <filename>.yaml

5.5.4. 配置日志可视化工具

您可以通过修改 ClusterLogging 自定义资源(CR)来配置日志可视化工具类型。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 您已创建了 ClusterLogging CR。
重要

如果要使用 OpenShift Container Platform Web 控制台进行视觉化,您必须启用日志记录控制台插件。请参阅有关 "Log visualization with the web console" 的文档。

流程

  1. 修改 ClusterLogging CR visualization 规格:

    ClusterLogging CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      visualization:
        type: <visualizer_type> 1
        kibana: 2
          resources: {}
          nodeSelector: {}
          proxy: {}
          replicas: {}
          tolerations: {}
        ocpConsole: 3
          logsLimit: {}
          timeout: {}
    # ...

    1
    要用于日志记录的可视化工具类型。这可以是 kibanaocp-console。Kibana 控制台仅与使用 Elasticsearch 日志存储的部署兼容,而 OpenShift Container Platform 控制台只与 LokiStack 部署兼容。
    2
    Kibana 控制台的可选配置。
    3
    OpenShift Container Platform Web 控制台的可选配置。
  2. 运行以下命令来应用 ClusterLogging CR:

    $ oc apply -f <filename>.yaml

5.5.5. 启用网络隔离时允许项目间的流量

集群网络插件可能会强制实施网络隔离。如果是这样,您必须允许包含 OpenShift Logging 部署的 Operator 的项目间的网络流量。

网络隔离会阻止位于不同项目中的 pod 或服务之间的网络流量。Logging 在 openshift-operators-redhat 项目中安装 OpenShift Elasticsearch Operator,在 openshift-logging 项目中安装 Red Hat OpenShift Logging Operator。因此,您必须允许这两个项目之间的流量。

OpenShift Container Platform 为网络插件(OpenShift SDN 和 OVN-Kubernetes)提供了两个支持的选择。这两个提供程序实施各种网络隔离策略。

OpenShift SDN 有三种模式:

网络策略
这是默认的模式。如果没有定义策略,它将允许所有流量。但是,如果用户定义了策略,它们通常先拒绝所有流量,然后再添加例外。此过程可能会破坏在不同项目中运行的应用。因此,显式配置策略以允许从一个与日志记录相关的项目出口到另一个项目的流量。
多租户
这个模式强制实施网络隔离。您必须加入两个与日志记录相关的项目,以允许它们之间的流量。
subnet
此模式允许所有流量。它不强制实施网络隔离。不需要操作。

OVN-Kubernetes 始终使用网络策略。因此,与 OpenShift SDN 一样,您必须配置策略,以允许流量从一个与日志相关的项目出口到另一个项目。

流程

  • 如果您以多租户(multitenant)模式使用 OpenShift SDN,请加入这两个项目。例如:

    $ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
  • 否则,对于网络策略模式的 OpenShift SDN 以及 OVN-Kubernetes,请执行以下操作:

    1. openshift-operators-redhat 命名空间中设置标签。例如:

      $ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
    2. openshift-logging 命名空间中创建一个网络策略对象,它允许从 openshift-operators-redhatopenshift-monitoringopenshift-ingress 项目的入站流量到 openshift-logging 项目。例如:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring-ingress-operators-redhat
      spec:
        ingress:
        - from:
          - podSelector: {}
        - from:
          - namespaceSelector:
              matchLabels:
                project: "openshift-operators-redhat"
        - from:
          - namespaceSelector:
              matchLabels:
                name: "openshift-monitoring"
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress

第 6 章 更新日志记录

有两种日志记录更新: 次版本更新(5.y.z)和主版本更新(5.y)。

6.1. 次发行版本更新

如果您使用 Automatic 更新批准选项安装日志记录 Operator,您的 Operator 会自动接收次版本更新。您不需要完成任何手动更新步骤。

如果使用 Manual 更新批准选项安装日志记录 Operator,您必须手动批准次版本更新。如需更多信息,请参阅手动批准待处理的 Operator 更新

6.2. 主发行版本更新

对于主版本更新,您必须完成一些手动步骤。

有关主版本的兼容性和支持信息,请参阅 OpenShift Operator 生命周期

6.3. 升级 Red Hat OpenShift Logging Operator 以监视所有命名空间

在日志记录 5.7 和旧版本中,Red Hat OpenShift Logging Operator 只监视 openshift-logging 命名空间。如果您希望 Red Hat OpenShift Logging Operator 监视集群中的所有命名空间,您必须重新部署 Operator。您可以完成以下步骤在不删除日志记录组件的情况下重新部署 Operator。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 有管理员权限。

流程

  1. 运行以下命令来删除订阅:

    $ oc -n openshift-logging delete subscription <subscription>
  2. 运行以下命令来删除 Operator 组:

    $ oc -n openshift-logging delete operatorgroup <operator_group_name>
  3. 运行以下命令来删除集群服务版本 (CSV):

    $ oc delete clusterserviceversion cluster-logging.<version>
  4. 按照"安装日志记录"文档重新部署 Red Hat OpenShift Logging Operator。

验证

  • 检查 OperatorGroup 资源中的 targetNamespaces 字段是否不存在或设置为空字符串。

    要做到这一点,请运行以下命令并检查输出:

    $ oc get operatorgroup <operator_group_name> -o yaml

    输出示例

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-logging-f52cn
      namespace: openshift-logging
    spec:
      upgradeStrategy: Default
    status:
      namespaces:
      - ""
    # ...

6.4. 更新 Red Hat OpenShift Logging Operator

要将 Red Hat OpenShift Logging Operator 更新至新的主版本,您必须修改 Operator 订阅的更新频道。

先决条件

  • 已安装 Red Hat OpenShift Logging Operator。
  • 有管理员权限。
  • 您可以访问 OpenShift Container Platform Web 控制台,并查看 Administrator 视角。

流程

  1. 导航到 OperatorsInstalled Operators
  2. 选择 openshift-logging 项目。
  3. Red Hat OpenShift Logging Operator。
  4. Subscription。在 Subscription details 部分,点 Update channel 链接。根据您的当前更新频道,这个链接文本可能是 stablestable-5.y
  5. Change Subscription Update Channel 窗口中,选择最新的主版本更新频道 stable-5.y,然后点 Save。请注意 cluster-logging.v5.y.z 版本。

验证

  1. 等待几秒钟,然后点 OperatorsInstalled Operators。验证 Red Hat OpenShift Logging Operator 版本是否与最新的 cluster-logging.v5.y.z 版本匹配。
  2. OperatorsInstalled Operators 页面中,等待 Status 字段报告 Succeeded

6.5. 更新 Loki Operator

要将 Loki Operator 更新至一个新的主版本,您必须修改 Operator 订阅的更新频道。

先决条件

  • 已安装 Loki Operator。
  • 有管理员权限。
  • 您可以访问 OpenShift Container Platform Web 控制台,并查看 Administrator 视角。

流程

  1. 导航到 OperatorsInstalled Operators
  2. 选择 openshift-operators-redhat 项目。
  3. Loki Operator
  4. Subscription。在 Subscription details 部分,点 Update channel 链接。根据您的当前更新频道,这个链接文本可能是 stablestable-5.y
  5. Change Subscription Update Channel 窗口中,选择最新的主版本更新频道 stable-5.y,然后点 Save。请注意 loki-operator.v5.y.z 版本。

验证

  1. 等待几秒钟,然后点 OperatorsInstalled Operators。验证 Loki Operator 版本是否与最新的 loki-operator.v5.y.z 版本匹配。
  2. OperatorsInstalled Operators 页面中,等待 Status 字段报告 Succeeded

6.6. 更新 OpenShift Elasticsearch Operator

要将 OpenShift Elasticsearch Operator 更新至当前版本,您必须修改订阅。

注意

Logging 5.9 发行版本不包含 OpenShift Elasticsearch Operator 的更新版本。如果您目前使用随 Logging 5.8 发布的 OpenShift Elasticsearch Operator,它将继续使用 Logging,直到 Logging 5.8 的 EOL 为止。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。如需有关日志记录生命周期日期的更多信息,请参阅平台 Agnostic Operator

先决条件

  • 如果您使用 Elasticsearch 作为默认日志存储,且 Kibana 作为 UI,请在更新 Red Hat OpenShift Logging Operator 前更新 OpenShift Elasticsearch Operator。

    重要

    如果您以错误的顺序更新 Operator,则 Kibana 不会更新,并且不会创建 Kibana 自定义资源 (CR)。要解决这个问题,删除 Red Hat OpenShift Logging Operator pod。当 Red Hat OpenShift Logging Operator pod 重新部署时,它会创建 Kibana CR 和 Kibana 再次可用。

  • Logging 处于健康状态:

    • 所有 pod 都处于 ready 状态。
    • Elasticsearch 集群处于健康状态。
  • 您的 Elasticsearch 和 Kibana 数据已被备份。
  • 有管理员权限。
  • 您已安装了 OpenShift CLI (oc) 进行验证步骤。

流程

  1. 在 OpenShift Container Platform web 控制台中,点击 OperatorsInstalled Operators
  2. 选择 openshift-operators-redhat 项目。
  3. OpenShift Elasticsearch Operator
  4. SubscriptionChannel
  5. Change Subscription Update Channel 窗口中,选择 stable-5.y 并点 Save。注意 elasticsearch-operator.v5.y.z 版本。
  6. 等待几秒钟,然后点 OperatorsInstalled Operators。验证 OpenShift Elasticsearch Operator 版本是否与最新的 elasticsearch-operator.v5.y.z 版本匹配。
  7. OperatorsInstalled Operators 页面中,等待 Status 字段报告 Succeeded

验证

  1. 输入以下命令并查看输出,验证所有 Elasticsearch pod 的状态是否为 Ready

    $ oc get pod -n openshift-logging --selector component=elasticsearch

    输出示例

    NAME                                            READY   STATUS    RESTARTS   AGE
    elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk   2/2     Running   0          31m
    elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk   2/2     Running   0          30m
    elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc     2/2     Running   0          29m

  2. 输入以下命令并查看输出来验证 Elasticsearch 集群状态是否为绿色

    $ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- health

    输出示例

    {
      "cluster_name" : "elasticsearch",
      "status" : "green",
    }

  3. 输入以下命令并查看输出来验证 Elasticsearch cron 作业是否已创建:

    $ oc project openshift-logging
    $ oc get cronjob

    输出示例

    NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    elasticsearch-im-app     */15 * * * *   False     0        <none>          56s
    elasticsearch-im-audit   */15 * * * *   False     0        <none>          56s
    elasticsearch-im-infra   */15 * * * *   False     0        <none>          56s

  4. 输入以下命令并验证日志存储是否已更新至正确的版本,并且索引是绿色的

    $ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices

    验证输出是否包含 app-00000xinfra-00000xaudit-00000x.security 索引;

    例 6.1. 带有绿色状态索引的输出示例

    Tue Jun 30 14:30:54 UTC 2020
    health status index                                                                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
    green  open   infra-000008                                                          bnBvUFEXTWi92z3zWAzieQ   3 1       222195            0        289            144
    green  open   infra-000004                                                          rtDSzoqsSl6saisSK7Au1Q   3 1       226717            0        297            148
    green  open   infra-000012                                                          RSf_kUwDSR2xEuKRZMPqZQ   3 1       227623            0        295            147
    green  open   .kibana_7                                                             1SJdCqlZTPWlIAaOUd78yg   1 1            4            0          0              0
    green  open   infra-000010                                                          iXwL3bnqTuGEABbUDa6OVw   3 1       248368            0        317            158
    green  open   infra-000009                                                          YN9EsULWSNaxWeeNvOs0RA   3 1       258799            0        337            168
    green  open   infra-000014                                                          YP0U6R7FQ_GVQVQZ6Yh9Ig   3 1       223788            0        292            146
    green  open   infra-000015                                                          JRBbAbEmSMqK5X40df9HbQ   3 1       224371            0        291            145
    green  open   .orphaned.2020.06.30                                                  n_xQC2dWQzConkvQqei3YA   3 1            9            0          0              0
    green  open   infra-000007                                                          llkkAVSzSOmosWTSAJM_hg   3 1       228584            0        296            148
    green  open   infra-000005                                                          d9BoGQdiQASsS3BBFm2iRA   3 1       227987            0        297            148
    green  open   infra-000003                                                          1-goREK1QUKlQPAIVkWVaQ   3 1       226719            0        295            147
    green  open   .security                                                             zeT65uOuRTKZMjg_bbUc1g   1 1            5            0          0              0
    green  open   .kibana-377444158_kubeadmin                                           wvMhDwJkR-mRZQO84K0gUQ   3 1            1            0          0              0
    green  open   infra-000006                                                          5H-KBSXGQKiO7hdapDE23g   3 1       226676            0        295            147
    green  open   infra-000001                                                          eH53BQ-bSxSWR5xYZB6lVg   3 1       341800            0        443            220
    green  open   .kibana-6                                                             RVp7TemSSemGJcsSUmuf3A   1 1            4            0          0              0
    green  open   infra-000011                                                          J7XWBauWSTe0jnzX02fU6A   3 1       226100            0        293            146
    green  open   app-000001                                                            axSAFfONQDmKwatkjPXdtw   3 1       103186            0        126             57
    green  open   infra-000016                                                          m9c1iRLtStWSF1GopaRyCg   3 1        13685            0         19              9
    green  open   infra-000002                                                          Hz6WvINtTvKcQzw-ewmbYg   3 1       228994            0        296            148
    green  open   infra-000013                                                          KR9mMFUpQl-jraYtanyIGw   3 1       228166            0        298            148
    green  open   audit-000001                                                          eERqLdLmQOiQDFES1LBATQ   3 1            0            0          0              0
  5. 输入以下命令并查看输出,验证日志可视化工具是否已更新至正确的版本:

    $ oc get kibana kibana -o json

    验证输出是否包含具有 ready 状态的 Kibana Pod:

    例 6.2. 带有就绪 Kibana pod 的输出示例

    [
    {
    "clusterCondition": {
    "kibana-5fdd766ffd-nb2jj": [
    {
    "lastTransitionTime": "2020-06-30T14:11:07Z",
    "reason": "ContainerCreating",
    "status": "True",
    "type": ""
    },
    {
    "lastTransitionTime": "2020-06-30T14:11:07Z",
    "reason": "ContainerCreating",
    "status": "True",
    "type": ""
    }
    ]
    },
    "deployment": "kibana",
    "pods": {
    "failed": [],
    "notReady": []
    "ready": []
    },
    "replicaSets": [
    "kibana-5fdd766ffd"
    ],
    "replicas": 1
    }
    ]

第 7 章 可视化日志

7.1. 关于日志视觉化

您可以根据部署的日志存储解决方案,在 OpenShift Container Platform Web 控制台中视觉化您的日志数据,或 Kibana Web 控制台。Kibana 控制台可用于 ElasticSearch 日志存储,OpenShift Container Platform Web 控制台可用于 ElasticSearch 日志存储或 LokiStack。

注意

Kibana Web 控制台现已弃用,计划在以后的日志记录发行版本中删除。

7.1.1. 配置日志可视化工具

您可以通过修改 ClusterLogging 自定义资源(CR)来配置日志可视化工具类型。

先决条件

  • 有管理员权限。
  • 已安装 OpenShift CLI(oc)。
  • 已安装 Red Hat OpenShift Logging Operator。
  • 您已创建了 ClusterLogging CR。
重要

如果要使用 OpenShift Container Platform Web 控制台进行视觉化,您必须启用日志记录控制台插件。请参阅有关 "Log visualization with the web console" 的文档。

流程

  1. 修改 ClusterLogging CR visualization 规格:

    ClusterLogging CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      visualization:
        type: <visualizer_type> 1
        kibana: 2
          resources: {}
          nodeSelector: {}
          proxy: {}
          replicas: {}
          tolerations: {}
        ocpConsole: 3
          logsLimit: {}
          timeout: {}
    # ...

    1
    要用于日志记录的可视化工具类型。这可以是 kibanaocp-console。Kibana 控制台仅与使用 Elasticsearch 日志存储的部署兼容,而 OpenShift Container Platform 控制台只与 LokiStack 部署兼容。
    2
    Kibana 控制台的可选配置。
    3
    OpenShift Container Platform Web 控制台的可选配置。
  2. 运行以下命令来应用 ClusterLogging CR:

    $ oc apply -f <filename>.yaml

7.1.2. 查看资源的日志

资源日志是一个默认功能,可提供有限的日志查看功能。您可以使用 OpenShift CLI (oc) 和 Web 控制台查看各种资源的日志,如构建、部署和 pod。

提示

为增强日志检索和查看体验,请安装 logging。日志记录将 OpenShift Container Platform 集群中的所有日志(如节点系统审计日志、应用程序容器日志和基础架构日志)聚合到专用日志存储中。然后,您可以通过 Kibana 控制台或 OpenShift Container Platform Web 控制台查询、发现和视觉化您的日志数据。资源日志无法访问日志记录日志存储。

7.1.2.1. 查看资源日志

您可以在 OpenShift CLI (oc) 和 Web 控制台中查看各种资源的日志。日志从日志的尾部或末尾读取。

先决条件

  • 访问 OpenShift CLI(oc)。

流程 (UI)

  1. 在 OpenShift Container Platform 控制台中,导航到 WorkloadsPods,或通过您要调查的资源导航到 pod。

    注意

    有些资源(如构建)没有直接查询的 pod。在这种情况下,您可以在资源的 Details 页面中找到 Logs 链接。

  2. 从下拉菜单中选择一个项目。
  3. 点您要调查的 pod 的名称。
  4. Logs

流程 (CLI)

  • 查看特定 pod 的日志:

    $ oc logs -f <pod_name> -c <container_name>

    其中:

    -f
    可选:指定输出是否遵循要写到日志中的内容。
    <pod_name>
    指定 pod 的名称。
    <container_name>
    可选:指定容器的名称。当 pod 具有多个容器时,您必须指定容器名称。

    例如:

    $ oc logs ruby-58cd97df55-mww7r
    $ oc logs -f ruby-57f7f4855b-znl92 -c ruby

    输出的日志文件内容。

  • 查看特定资源的日志:

    $ oc logs <object_type>/<resource_name> 1
    1
    指定资源类型和名称。

    例如:

    $ oc logs deployment/ruby

    输出的日志文件内容。

7.2. 使用 Web 控制台进行日志视觉化

您可以通过配置 logging 控制台插件,使用 OpenShift Container Platform Web 控制台来视觉化日志数据。

有关在日志记录安装过程中配置插件的详情,请参考使用 Web 控制台安装 logging

如果您已经安装了日志记录并希望配置插件,请使用以下步骤之一。

7.2.1. 安装 Red Hat OpenShift Logging Operator 后启用 logging 控制台插件

作为 Red Hat OpenShift Logging Operator 安装的一部分,您可以启用 logging 控制台插件,但如果您已禁用了插件,也可以启用插件。

先决条件

  • 有管理员权限。
  • 已安装 Red Hat OpenShift Logging Operator,并为 Console 插件选择了 Disabled
  • 访问 OpenShift Container Platform web 控制台。

流程

  1. 在 OpenShift Container Platform web 控制台的 Administrator 视角中,进入 OperatorsInstalled Operators
  2. Red Hat OpenShift Logging。这会进入 Operator Details 页面。
  3. Details 页面中,为 控制台插件选项点 Disabled
  4. 控制台插件启用对话框中,选择 Enable
  5. 点击 Save
  6. 验证 控制台插件选项现在显示 Enabled
  7. 应用更改后,web 控制台会显示一个弹出窗口。窗口提示您重新加载 Web 控制台。当您看到弹出窗口以应用更改时,刷新浏览器。

7.2.2. 安装 Elasticsearch 日志存储和 LokiStack 时配置日志记录控制台插件

在 logging 版本 5.8 及更高版本中,如果 Elasticsearch 日志存储是默认的日志存储,您也可以按照以下流程启用 logging 控制台插件。

先决条件

  • 有管理员权限。
  • 已安装 Red Hat OpenShift Logging Operator、OpenShift Elasticsearch Operator 和 Loki Operator。
  • 已安装 OpenShift CLI(oc)。
  • 您已创建了 ClusterLogging 自定义资源 (CR)。

流程

  1. 运行以下命令,确保启用了日志记录控制台插件:

    $ oc get consoles.operator.openshift.io cluster -o yaml |grep logging-view-plugin  \
    || oc patch consoles.operator.openshift.io cluster  --type=merge \
    --patch '{ "spec": { "plugins": ["logging-view-plugin"]}}'
  2. 运行以下命令,将 .metadata.annotations.logging.openshift.io/ocp-console-migration-target: lokistack-dev 注解添加到 ClusterLogging CR:

    $ oc patch clusterlogging instance --type=merge --patch \
    '{ "metadata": { "annotations": { "logging.openshift.io/ocp-console-migration-target": "lokistack-dev" }}}' \
    -n openshift-logging

    输出示例

    clusterlogging.logging.openshift.io/instance patched

验证

  • 运行以下命令并查看输出,验证注解是否已成功添加:

    $ oc get clusterlogging instance \
    -o=jsonpath='{.metadata.annotations.logging\.openshift\.io/ocp-console-migration-target}' \
    -n openshift-logging

    输出示例

    "lokistack-dev"

现在,日志记录控制台插件 pod 已被部署。您可以通过进入到 OpenShift Container Platform Web 控制台并查看 ObserveLogs 页面来查看日志数据。

7.3. 查看集群仪表板

OpenShift Container Platform web 控制台中的 Logging/Elasticsearch NodesOpenshift Logging 仪表板包括有关 Elasticsearch 实例以及用于防止和诊断问题的单个 Elasticsearch 节点的详细信息。

OpenShift Logging 仪表板包含 chart,在集群级别显示 Elasticsearch 实例的详情,包括集群资源、垃圾回收、集群中的分片和 Fluentd 统计。

Logging/Elasticsearch Nodes 仪表板包含 charts,显示 Elasticsearch 实例的详情,很多在节点级别,包括索引、分片、资源等详情。

7.3.1. 访问 Elasticsearch 和 OpenShift Logging 仪表板

您可以在 OpenShift Container Platform web 控制台中查看 Logging/Elasticsearch NodesOpenShift Logging 仪表板。

流程

启动仪表板:

  1. 在 OpenShift Container Platform web 控制台中点 ObserveDashboards
  2. Dashboards 页面中,从 Dashboard 菜单中选择 Logging/Elasticsearch NodesOpenShift Logging

    对于 Logging/Elasticsearch Nodes 仪表板,可以选择您要查看的 Elasticsearch 节点并设置数据解析。

    此时会显示正确的仪表板,显示多个数据图表。

  3. 可选:从 Time RangeRefresh Interval 菜单中选择不同时间范围来显示或刷新数据。

有关仪表板图表的信息,请参阅 关于 OpenShift Logging 仪表板关于 Logging/Elastisearch Nodes 仪表板

7.3.2. 关于 OpenShift Logging 仪表板

OpenShift Logging 仪表板包含 chart,可在集群级别显示 Elasticsearch 实例的详情,用于诊断和预期问题。

表 7.1. OpenShift Logging chart
指标描述

Elastic 集群状态

当前的 Elasticsearch 状态:

  • ONLINE - 表示 Elasticsearch 实例在线。
  • OFFLINE - 表示 Elasticsearch 实例离线。

弹性节点

Elasticsearch 实例中的 Elasticsearch 节点总数。

Elastic 分片

Elasticsearch 实例中的 Elasticsearch 分片的总数。

Elastic 文档

Elasticsearch 实例中的 Elasticsearch 文档总数。

磁盘上的总索引大小

正在用于 Elasticsearch 索引的总磁盘空间。

Elastic 待处理的任务

Elasticsearch 尚未完成的更改总数,如索引创建、索引映射、分片分配或分片失败。

Elastic JVM GC 时间

JVM 在集群中执行 Elasticsearch 垃圾回收操作所需的时间。

Elastic JVM GC 率

JVM 每秒执行垃圾操作的次数总数。

Elastic Query/Fetch Latency Sum

  • Query latency:Elasticsearch 搜索查询执行的平均时间。
  • 获取延迟:每个 Elasticsearch 搜索查询的平均时间获取数据。

获取延迟的时间通常比查询延迟要短。如果抓取延迟持续增加,则代表磁盘、数据配置速度较慢,或者带有许多结果的大量请求。

Elastic 查询率

每个 Elasticsearch 节点每秒对 Elasticsearch 实例执行的查询总数。

CPU

Elasticsearch、Fluentd 和 Kibana 使用的 CPU 数量,显示了各个组件的 CPU 数量。

已使用的 Elastic JVM Heap

使用的 JVM 内存量。在一个健康的集群中,图形显示由 JVM 垃圾回收所释放的内存。

Elasticsearch 磁盘使用量

Elasticsearch 实例用于每个 Elasticsearch 节点的总磁盘空间。

使用中的文件描述符

Elasticsearch、Fluentd 和 Kibana 使用的文件描述符总数。

Fluentd emit 数量

Fluentd 默认输出每秒的 Fluentd 消息总数,以及默认输出的重试计数。

Fluentd 缓冲使用

用于块的 Fluentd 缓冲的百分比。完整缓冲可能表示 Fluentd 无法处理收到的日志数量。

Elastic rx 字节

Elasticsearch 提供的 FluentD、Elasticsearch 节点和其它源的字节总数。

Elastic Index Failure Rate

Elasticsearch 索引失败的每秒总次数。高速率表示索引时出现问题。

Fluentd 输出错误率

FluentD 无法输出日志的每秒总次数。

7.3.3. Logging/Elasticsearch 节点仪表板上的图表

Logging/Elasticsearch Nodes 仪表板包含 charts,显示 Elasticsearch 实例的详情(很多在节点级别),以进行进一步诊断。

Elasticsearch 状态
Logging/Elasticsearch Nodes 仪表板包含有关 Elasticsearch 实例状态的以下图表。
表 7.2. Elasticsearch 状态字段
指标描述

集群状态

在所选时间段内的集群健康状态,使用 Elasticsearch 绿色、黄色和红色代表:

  • 0 - 表示 Elasticsearch 实例处于绿色状态,这意味着分配了所有分片。
  • 1 - 表示 Elasticsearch 实例处于黄色状态,这意味着至少一个分片的副本分片不会被分配。
  • 2 - 表示 Elasticsearch 实例处于红色状态,这意味着至少不分配一个主分片及其副本。

集群节点

集群中的 Elasticsearch 节点总数。

集群数据节点

集群中的 Elasticsearch 数据节点数量。

集群待定任务

集群状态更改的数量,这些更改尚未完成,并在集群队列中等待,例如索引创建、索引删除或分片分配。增长的倾向表示集群无法跟上变化。

Elasticsearch 集群索引分片状态
每个 Elasticsearch 索引都是一个或多个分片的逻辑组,它们是持久化数据的基本单元。索引分片有两种类型:主分片和副本分片。当将文档索引为索引时,会将其保存在其主分片中,并复制到该分片的每个副本中。当索引被创建时,主分片的数量会被指定,在索引生命周期内这个数量不能改变。您可以随时更改副本分片的数量。

索引分片可能处于几个状态,具体取决于其生命周期阶段或集群中发生的事件。当分片能够执行搜索和索引请求时,分片就是活跃的。如果分片无法执行这些请求,分片就不是活跃的。如果分片正在初始化、重新分配、取消分配等等,分片可能不是活跃的。

索引分片由多个较小的内部块组成,称为索引片段,它们是数据的物理表示。索引分段是一个相对较小的不可变 Lucene 索引,它是 Lucene 提交新索引数据时生成的。Lucene 是 Elasticsearch 使用的搜索库,将索引片段合并到后台里的较大片段,从而使片段总数较低。如果合并片段的过程比生成新网段的速度慢,则可能表明问题。

当 Lucene 执行数据操作(如搜索操作)时,Lucene 会根据相关索引中的索引片段执行操作。为此,每个片段都包含在内存中载入并映射的特定数据结构。索引映射会对片段数据结构使用的内存有重大影响。

Logging/Elasticsearch Nodes 仪表板包含有关 Elasticsearch 索引分片的以下图表。

表 7.3. Elasticsearch 集群分片状态 chart
指标描述

集群活跃分片

集群中活跃的主分片的数量和分片(包括副本)的总数。如果分片数量增加,集群性能就可以启动它。

集群初始化分片

集群中的非活跃分片数量。非活跃分片是正在初始化、被重新分配到不同节点或未分配的分片。集群通常具有非活跃分片(non-active 分片)的短时间。较长时间的非活跃分片数量增加可能代表有问题。

集群重新定位分片

Elasticsearch 重新定位到新节点的分片数量。Elasticsearch 由于多个原因重新定位节点,如在一个节点上或向集群中添加新节点时使用高内存。

集群未分配分片

未分配分片的数量。由于添加新索引或节点失败等原因,Elasticsearch 分片可能没有被分配。

Elasticsearch 节点指标
每个 Elasticsearch 节点都有有限的资源,可用于处理任务。当所有资源都被已被使用,Elasticsearch 尝试执行新任务时,Elasticsearch 会将任务放入队列等待出现可用的资源。

Logging/Elasticsearch Nodes 仪表板包含以下有关所选节点的资源使用情况,以及 Elasticsearch 队列中等待的任务数量的图表。

表 7.4. Elasticsearch 节点指标图表
指标描述

ThreadPool 任务

按任务类型显示的独立队列中等待的任务数量。在任何队列中的长期任务可能意味着节点资源短缺或其他问题。

CPU 用量

所选 Elasticsearch 节点使用的 CPU 量作为分配给主机容器的 CPU 总量的百分比。

内存用量

所选 Elasticsearch 节点使用的内存量。

磁盘用量

所选 Elasticsearch 节点上用于索引数据和元数据的总磁盘空间。

文档索引率

文档在所选 Elasticsearch 节点上索引的频率。

索引延迟

在所选 Elasticsearch 节点上索引文档所需时间。索引延迟会受到很多因素的影响,如 JVM Heap 内存和整个负载。延迟增加代表实例中资源容量不足。

搜索率

在所选 Elasticsearch 节点上运行的搜索请求数量。

搜索延迟

在所选 Elasticsearch 节点上完成搜索请求的时间。搜索延迟可能会受到很多因素的影响。延迟增加代表实例中资源容量不足。

文档计数(包括副本)

存储在所选 Elasticsearch 节点上的 Elasticsearch 文档数量,包括存储在主分片和节点上分配的副本分片中的文档。

文档删除速率

要从分配给所选 Elasticsearch 节点的任何索引分片中删除 Elasticsearch 文档的数量。

文档合并率

分配给所选 Elasticsearch 节点的任何索引分片中合并的 Elasticsearch 文档数量。

Elasticsearch 节点 fielddata
Fielddata 是一个 Elasticsearch 数据结构,它以索引形式保存术语列表,并保存在 JVM 堆中。因为 fielddata 构建非常昂贵,所以 Elasticsearch 会缓存 fielddata 结构。当底层索引分段被删除或合并时,或者没有足够 JVM HEAP 内存用于所有 fielddata 缓存时,Elasticsearch 可以驱除 fielddata 缓存,。

Logging/Elasticsearch Nodes 仪表板包含有关 Elasticsearch 字段数据的以下图表。

表 7.5. Elasticsearch 节点字段数据图表
指标描述

Fielddata 内存大小

用于所选 Elasticsearch 节点上的 fielddata 缓存的 JVM 堆数量。

Fielddata 驱除

从所选 Elasticsearch 节点中删除的 fielddata 结构数量。

Elasticsearch 节点查询缓存
如果索引中存储的数据没有改变,搜索查询结果会在节点级别的查询缓存中缓存,以便 Elasticsearch 重复使用。

Logging/Elasticsearch Nodes 仪表板包含有关 Elasticsearch 节点查询缓存的以下图表。

表 7.6. Elasticsearch 节点查询图表
指标描述

查询缓存大小

用于查询缓存的内存总量,用于分配给所选 Elasticsearch 节点的所有分片。

查询缓存驱除

所选 Elasticsearch 节点上的查询缓存驱除数量。

查询缓存点击

所选 Elasticsearch 节点上的查询缓存数量。

查询缓存丢失

所选 Elasticsearch 节点上丢失的查询缓存数。

Elasticsearch 索引节流
在索引文档时,Elasticsearch 将文档存储在索引片段中,这些部分是数据的物理表示。同时,Elasticsearch 会定期将较小的片段合并到较大的片段中,以优化资源使用。如果索引速度更快,那么合并过程就无法迅速完成,从而导致搜索和性能出现问题。为了防止这种情况,Elasticsearch 节流(throttles)的索引通常是通过减少分配给索引到单个线程的线程数量来实现的。

Logging/Elasticsearch Nodes 仪表板包含有关 Elasticsearch 索引节流的以下图表。

表 7.7. 索引节流图表
指标描述

索引节流

Elasticsearch 在所选 Elasticsearch 节点上节流索引操作的时间。

合并节流

Elasticsearch 在所选 Elasticsearch 节点上节流部署片段合并操作的时间。

节点 JVM 堆统计
Logging/Elasticsearch Nodes 仪表板包含以下有关 JVM Heap 操作的图表。
表 7.8. JVM Heap 统计图表
指标描述

使用的堆

所选 Elasticsearch 节点上分配的 JVM 堆空间量。

GC 计数

在所选 Elasticsearch 节点上运行的垃圾回收操作数量,包括旧垃圾回收量。

GC 时间

JVM 在所选 Elasticsearch 节点上运行垃圾回收操作的时间、旧的垃圾回收时间。

7.4. 使用 Kibana 进行日志视觉化

如果使用 ElasticSearch 日志存储,您可以使用 Kibana 控制台来视觉化收集的日志数据。

使用 Kibana,您可以使用您的数据进行以下操作:

  • 使用 Discover 标签页搜索并浏览数据。
  • 使用 Visualize 选项卡对数据进行图表显示。
  • 使用 Dashboard 标签页创建并查看自定义仪表板。

使用并配置 Kibana 界面的内容超出了本文档的范围。有关使用接口的更多信息,请参阅 Kibana 文档

注意

默认情况下,审计日志不会存储在 OpenShift Container Platform 内部 Elasticsearch 实例中。要在 Kibana 中查看审计日志,您必须使用 Log Forwarding API 配置使用审计日志的 default 输出的管道。

7.4.1. 定义 Kibana 索引模式

索引模式定义了您要视觉化的 Elasticsearch 索引。要在 Kibana 中探索和视觉化数据,您必须创建索引模式。

先决条件

  • 用户必须具有 cluster-admin 角色、cluster-reader 角色或这两个角色,才能在 Kibana 中查看 infraaudit 索引。默认 kubeadmin 用户具有查看这些索引的权限。

    如果可以查看 defaultkube-openshift- 项目中的 pod 和日志,则应该可以访问这些索引。您可以使用以下命令检查当前用户是否有适当的权限:

    $ oc auth can-i get pods --subresource log -n <project>

    输出示例

    yes

    注意

    默认情况下,审计日志不会存储在 OpenShift Container Platform 内部 Elasticsearch 实例中。要在 Kibana 中查看审计日志,您必须使用 Log Forward API 配置使用审计日志的 default 输出的管道。

  • 在创建索引模式前,Elasticsearch 文档必须被索引。这会自动完成,但在一个新的或更新的集群中可能需要几分钟。

流程

在 Kibana 中定义索引模式并创建视觉化:

  1. 在 OpenShift Container Platform 控制台中点击 Application Launcher app launcher 并选择 Logging
  2. ManagementIndex PatternsCreate index pattern 创建 Kibana 索引模式:

    • 首次登录 Kibana 时,每个用户必须手动创建索引模式才能查看其项目的日志。用户必须创建一个名为 app 的索引模式,并使用 @timestamp 时间字段查看其容器日志。
    • 每个 admin 用户在首次登录 Kibana 时,必须使用 @timestamp 时间字段为 appinfraaudit 索引创建索引模式。
  3. 从新的索引模式创建 Kibana 视觉化。

7.4.2. 在 Kibana 中查看集群日志

您可以在 Kibana web 控制台中查看集群日志。在 Kibana 中查看和视觉化您的数据的方法,它们超出了本文档的范围。如需更多信息,请参阅 Kibana 文档

先决条件

  • 必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。
  • Kibana 索引模式必须存在。
  • 用户必须具有 cluster-admin 角色、cluster-reader 角色或这两个角色,才能在 Kibana 中查看 infraaudit 索引。默认 kubeadmin 用户具有查看这些索引的权限。

    如果可以查看 defaultkube-openshift- 项目中的 pod 和日志,则应该可以访问这些索引。您可以使用以下命令检查当前用户是否有适当的权限:

    $ oc auth can-i get pods --subresource log -n <project>

    输出示例

    yes

    注意

    默认情况下,审计日志不会存储在 OpenShift Container Platform 内部 Elasticsearch 实例中。要在 Kibana 中查看审计日志,您必须使用 Log Forward API 配置使用审计日志的 default 输出的管道。

流程

在 Kibana 中查看日志:

  1. 在 OpenShift Container Platform 控制台中点击 Application Launcher app launcher 并选择 Logging
  2. 使用用来登录到 OpenShift Container Platform 控制台的相同凭证进行登录。

    Kibana 界面将出现。

  3. 在 Kibana 中,点 Discover
  4. 从左上角的下拉菜单中选择您创建的索引模式: appauditinfra

    日志数据显示为时间戳文档。

  5. 展开一个时间戳的文档。
  6. JSON 选项卡显示该文件的日志条目。

    例 7.1. Kibana 中的基础架构日志条目示例

    {
      "_index": "infra-000001",
      "_type": "_doc",
      "_id": "YmJmYTBlNDkZTRmLTliMGQtMjE3NmFiOGUyOWM3",
      "_version": 1,
      "_score": null,
      "_source": {
        "docker": {
          "container_id": "f85fa55bbef7bb783f041066be1e7c267a6b88c4603dfce213e32c1"
        },
        "kubernetes": {
          "container_name": "registry-server",
          "namespace_name": "openshift-marketplace",
          "pod_name": "redhat-marketplace-n64gc",
          "container_image": "registry.redhat.io/redhat/redhat-marketplace-index:v4.7",
          "container_image_id": "registry.redhat.io/redhat/redhat-marketplace-index@sha256:65fc0c45aabb95809e376feb065771ecda9e5e59cc8b3024c4545c168f",
          "pod_id": "8f594ea2-c866-4b5c-a1c8-a50756704b2a",
          "host": "ip-10-0-182-28.us-east-2.compute.internal",
          "master_url": "https://kubernetes.default.svc",
          "namespace_id": "3abab127-7669-4eb3-b9ef-44c04ad68d38",
          "namespace_labels": {
            "openshift_io/cluster-monitoring": "true"
          },
          "flat_labels": [
            "catalogsource_operators_coreos_com/update=redhat-marketplace"
          ]
        },
        "message": "time=\"2020-09-23T20:47:03Z\" level=info msg=\"serving registry\" database=/database/index.db port=50051",
        "level": "unknown",
        "hostname": "ip-10-0-182-28.internal",
        "pipeline_metadata": {
          "collector": {
            "ipaddr4": "10.0.182.28",
            "inputname": "fluent-plugin-systemd",
            "name": "fluentd",
            "received_at": "2020-09-23T20:47:15.007583+00:00",
            "version": "1.7.4 1.6.0"
          }
        },
        "@timestamp": "2020-09-23T20:47:03.422465+00:00",
        "viaq_msg_id": "YmJmYTBlNDktMDMGQtMjE3NmFiOGUyOWM3",
        "openshift": {
          "labels": {
            "logging": "infra"
          }
        }
      },
      "fields": {
        "@timestamp": [
          "2020-09-23T20:47:03.422Z"
        ],
        "pipeline_metadata.collector.received_at": [
          "2020-09-23T20:47:15.007Z"
        ]
      },
      "sort": [
        1600894023422
      ]
    }

7.4.3. 配置 Kibana

您可以通过修改 ClusterLogging 自定义资源(CR) 来使用 Kibana 控制台配置。

7.4.3.1. 配置 CPU 和内存限值

日志记录组件允许对 CPU 和内存限值进行调整。

流程

  1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源(CR):

    $ oc -n openshift-logging edit ClusterLogging instance
    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
      namespace: openshift-logging
    
    ...
    
    spec:
      managementState: "Managed"
      logStore:
        type: "elasticsearch"
        elasticsearch:
          nodeCount: 3
          resources: 1
            limits:
              memory: 16Gi
            requests:
              cpu: 200m
              memory: 16Gi
          storage:
            storageClassName: "gp2"
            size: "200G"
          redundancyPolicy: "SingleRedundancy"
      visualization:
        type: "kibana"
        kibana:
          resources: 2
            limits:
              memory: 1Gi
            requests:
              cpu: 500m
              memory: 1Gi
          proxy:
            resources: 3
              limits:
                memory: 100Mi
              requests:
                cpu: 100m
                memory: 100Mi
          replicas: 2
      collection:
        logs:
          type: "fluentd"
          fluentd:
            resources: 4
              limits:
                memory: 736Mi
              requests:
                cpu: 200m
                memory: 736Mi
    1
    根据需要指定日志存储的 CPU 和内存限值及请求。对于 Elasticsearch,您必须调整请求值和限制值。
    2 3
    根据需要为日志 visualizer 指定 CPU 和内存限值和请求。
    4
    根据需要指定日志收集器的 CPU 和内存限值及请求。
7.4.3.2. 为日志可视化器节点扩展冗余性

您可以扩展托管日志视觉化器的 pod 以增加它的冗余性。

流程

  1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源(CR):

    $ oc edit ClusterLogging instance
    $ oc edit ClusterLogging instance
    
    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
    
    ....
    
    spec:
        visualization:
          type: "kibana"
          kibana:
            replicas: 1 1
    1
    指定 Kibana 节点的数量。

第 8 章 配置日志部署

8.1. 为日志记录组件配置 CPU 和内存限值

您可以根据需要配置每个日志记录组件的 CPU 和内存限值。

8.1.1. 配置 CPU 和内存限值

日志记录组件允许对 CPU 和内存限值进行调整。

流程

  1. 编辑 openshift-logging 项目中的 ClusterLogging 自定义资源(CR):

    $ oc -n openshift-logging edit ClusterLogging instance
    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
      namespace: openshift-logging
    
    ...
    
    spec:
      managementState: "Managed"
      logStore:
        type: "elasticsearch"
        elasticsearch:
          nodeCount: 3
          resources: 1
            limits:
              memory: 16Gi
            requests:
              cpu: 200m
              memory: 16Gi
          storage:
            storageClassName: "gp2"
            size: "200G"
          redundancyPolicy: "SingleRedundancy"
      visualization:
        type: "kibana"
        kibana:
          resources: 2
            limits:
              memory: 1Gi
            requests:
              cpu: 500m
              memory: 1Gi
          proxy:
            resources: 3
              limits:
                memory: 100Mi
              requests:
                cpu: 100m
                memory: 100Mi
          replicas: 2
      collection:
        logs:
          type: "fluentd"
          fluentd:
            resources: 4
              limits:
                memory: 736Mi
              requests:
                cpu: 200m
                memory: 736Mi
    1
    根据需要指定日志存储的 CPU 和内存限值及请求。对于 Elasticsearch,您必须调整请求值和限制值。
    2 3
    根据需要为日志 visualizer 指定 CPU 和内存限值和请求。
    4
    根据需要指定日志收集器的 CPU 和内存限值及请求。

8.2. 配置 systemd-journald 和 Fluentd

Fluentd 需要从日志 (journal) 中读取数据。因为日志默认设置非常低,它可能无法跟上系统服务的日志记录率,所以日志条目可能会丢失。

我们推荐设置 RateLimitIntervalSec=30sRateLimitBurst=10000 (如有必要甚至更高)以防止日志丢失条目。

8.2.1. 为 OpenShift Logging 配置 systemd-journald

随着项目的扩展,默认的日志记录环境可能需要进行一些调整。

例如,如果有缺少日志数据的情况,则可能需要提高 journald 的速率限制。您可以调整在指定时间段内保留的消息数量,以确保 OpenShift Logging 在不丢弃日志的情况下不使用过量资源。

您还可以确定是否压缩日志、日志需要保留的时间、如何存储日志,以及其他设置。

流程

  1. 创建一个 Butane 配置文件 40-worker-custom-journald.bu,其中包含带有所需设置的 /etc/systemd/journald.conf 文件。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.15.0
    metadata:
      name: 40-worker-custom-journald
      labels:
        machineconfiguration.openshift.io/role: "worker"
    storage:
      files:
      - path: /etc/systemd/journald.conf
        mode: 0644 1
        overwrite: true
        contents:
          inline: |
            Compress=yes 2
            ForwardToConsole=no 3
            ForwardToSyslog=no
            MaxRetentionSec=1month 4
            RateLimitBurst=10000 5
            RateLimitIntervalSec=30s
            Storage=persistent 6
            SyncIntervalSec=1s 7
            SystemMaxUse=8G 8
            SystemKeepFree=20% 9
            SystemMaxFileSize=10M 10
    1
    设置 journald.conf 文件的权限。建议把选项设置为 0644
    2
    指定是否要在将日志写入文件系统前压缩日志。指定 yes 来压缩消息,或指定 no 不压缩信息。默认为 yes
    3
    配置是否转发日志信息。每个默认值为 no 。指定:
    • ForwardToConsole 将日志转发到系统控制台。
    • ForwardToKMsg 将日志转发到内核日志缓冲区。
    • ForwardToSyslog 将日志转发到 syslog 守护进程。
    • ForwardToWall 将信息作为墙信息转发给所有登录的用户。
    4
    指定存储日志条目的最长时间。输入秒数。或包括一个单位:" year" 、"month" 、"week" 、"day" 、"h" 或 "m"。输入 0 来禁用。默认值为 1month
    5
    配置速率限制。如果在 RateLimitIntervalSec 定义的时间间隔内收到 RateLimitBurst 中指定的日志数,则该时间段内的所有进一步信息都会被丢弃,直到间隔结束。建议您设置 RateLimitIntervalSec=30sRateLimitBurst=10000,它们是默认值。
    6
    指定日志的存储方式。默认为 persistent
    • volatile,将日志存储在 /run/log/journal/ 中的内存中。这些日志在重启后会丢失。
    • persistent 把日志保存到磁盘的 /var/log/journal/。如果这个目录步存在,systemd 将会创建这个目录。
    • auto 将日志存储在 /var/log/journal/ 中 (如果存在这个目录)。如果不存在,systemd 会临时将日志保存在 /run/systemd/journal 中。
    • none 不存储日志。systemd 丢弃所有日志。
    7
    指定在将 ERR, WARNING, NOTICE, INFODEBUG 日志同步到磁盘上前等待的超时时间。systemd 在接收到 CRIT, ALERTEMERG 日志后会立即进行同步。默认值为 1s
    8
    指定日志可以使用的最大值。默认值为 8G
    9
    指定 systemd 必须保留多少磁盘空间。默认值为 20%
    10
    指定保存在 /var/log/journal 中的独立日志文件的最大大小。默认值为 10M
    注意

    如果删除速率限制,您可能会看到系统日志记录守护进程的 CPU 使用率增加,因为它需要处理在以前可以被限制掉的信息。

    如需了解更多关于 systemd 设置的信息,请参阅 https://www.freedesktop.org/software/systemd/man/journald.conf.html。该页面中列出的默认设置可能不适用于 OpenShift Container Platform。

  2. 使用 Butane 生成 MachineConfig 对象文件 40-worker-custom-journald.yaml,它包含要提供给节点的配置:

    $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
  3. 应用机器配置。例如:

    $ oc apply -f 40-worker-custom-journald.yaml

    控制器检测到新的 MachineConfig 对象,并生成新的 rendered-worker-<hash> 版本。

  4. 监控新配置在每个节点中的应用状态:

    $ oc describe machineconfigpool/worker

    输出示例

    Name:         worker
    Namespace:
    Labels:       machineconfiguration.openshift.io/mco-built-in=
    Annotations:  <none>
    API Version:  machineconfiguration.openshift.io/v1
    Kind:         MachineConfigPool
    
    ...
    
    Conditions:
      Message:
      Reason:                All nodes are updating to rendered-worker-913514517bcea7c93bd446f4830bc64e

第 9 章 日志收集和转发

9.1. 关于日志收集和转发

Red Hat OpenShift Logging Operator 根据 ClusterLogForwarder 资源规格部署一个收集器。此 Operator 支持两个收集器选项:旧的 Fluentd 收集器和 Vector 收集器。

注意

Fluentd 已被弃用,计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持,但此功能将不再获得改进。作为 Fluentd 的替代选择,您可以使用 Vector。

9.1.1. 日志集合

日志收集器是一个守护进程集,它将 Pod 部署到每个 OpenShift Container Platform 节点,以收集容器和节点日志。

默认情况下,日志收集器使用以下源:

  • 由来自操作系统、容器运行时和 OpenShift Container Platform 的 journald 日志消息生成的系统和基础架构日志。
  • /var/log/containers/*.log 用于所有容器日志

如果您将日志收集器配置为收集审计日志,它会从 /var/log/audit/audit.log 收集它们。

日志收集器从这些源收集日志,并根据日志记录配置在内部或外部转发它们。

9.1.1.1. 日志收集器类型

Vector 是一个日志收集器,作为日志记录的 Fluentd 的一个替代方案。

您可以通过修改 ClusterLogging 自定义资源(CR) collection 规格来配置集群使用的日志记录收集器类型:

将 Vector 配置为收集器的 ClusterLogging CR 示例

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    logs:
      type: vector
      vector: {}
# ...

9.1.1.2. 日志收集限制

容器运行时提供少许信息来标识日志消息的来源,如项目、容器名称和容器 ID。这些信息不足以区分日志的来源。如果在日志收集器开始处理日志之前删除了具有指定名称和项目的 Pod,则来自 API 服务器的信息(如标签和注解)可能会不可用。可能没有办法区分来自名称相似的 Pod 和项目的日志消息,也无法追溯日志的来源。这种限制意味着日志收集和规范化被视为 最佳工作

重要

可用的容器运行时提供少许信息来标识日志消息来源,无法确保唯一的个别日志消息,也不能保证可以追溯这些消息的来源。

9.1.1.3. 按类型划分的日志收集器功能
表 9.1. 日志源
功能FluentdVector

应用程序容器日志

特定于应用程序的路由

命名空间划分应用程序特定路由

Infra 容器日志

Infra 日志

kube API 审计日志

OpenShift API 审计日志

打开虚拟网络 (OVN) 审计日志

表 9.2. 授权和身份验证
功能FluentdVector

Elasticsearch 证书

Elasticsearch 用户名/密码

Amazon Cloudwatch 密钥

Amazon Cloudwatch STS

Kafka 证书

Kafka 用户名/密码

Kafka SASL

Loki bearer 令牌

表 9.3. 规范化和转换
功能FluentdVector

ViaQ 数据模型 - 应用程序

ViaQ 数据模型 - infra

ViaQ 数据模型 - infra(journal)

ViaQ 数据模型 - Linux 审计

ViaQ 数据模型 - kube-apiserver 审计

ViaQ 数据模型 - OpenShift API 审计

ViaQ 数据模型 - OVN

loglevel Normalization

JSON 解析

结构化索引

多行错误检测

multicontainer/ split 索引

Flatten 标签

CLF 静态标签

表 9.4. Tuning
功能FluentdVector

Fluentd readlinelimit

 

Fluentd 缓冲

 

- chunklimitsize

 

- totallimitsize

 

- overflowaction

 

- flushthreadcount

 

- flushmode

 

- flushinterval

 

- retrywait

 

- retrytype

 

- retrymaxinterval

 

- retrytimeout

 
表 9.5. 可见性
功能FluentdVector

指标

Dashboard

警报

表 9.6. 其它
功能FluentdVector

全局代理支持

x86 支持

ARM 支持

IBM Power® 支持

IBM Z® 支持

IPv6 支持

日志事件缓冲

 

断开连接的集群

9.1.1.4. 收集器输出

支持以下收集器输出:

表 9.7. 支持的输出
功能FluentdVector

Elasticsearch v6-v8

Fluent 转发

 

Syslog RFC3164

✓ (Logging 5.7+)

Syslog RFC5424

✓ (Logging 5.7+)

Kafka

Amazon Cloudwatch

Amazon Cloudwatch STS

Loki

HTTP

✓ (Logging 5.7+)

Google Cloud Logging

Splunk

 

✓ (Logging 5.6+)

9.1.2. 日志转发

管理员可以创建 ClusterLogForwarder 资源,以指定要收集哪些日志、它们的转换方式以及它们被转发到的位置。

ClusterLogForwarder 资源可用于将容器、基础架构和审计日志转发到集群内部或外部的特定端点。支持传输层安全性(TLS),以便可以配置日志转发来安全地发送日志。

管理员也可以授权 RBAC 权限来定义哪些服务帐户和用户可以访问和转发哪些日志类型。

9.1.2.1. 日志转发实现

可用的日志转发实现有两个:旧的实现和多日志转发器功能。

重要

仅支持 Vector 收集器与多日志转发器功能一起使用。Fluentd 收集器只能用于旧的实现。

9.1.2.1.1. 旧实施

在旧的实现中,集群中只能使用一个日志转发器。此模式的 ClusterLogForwarder 资源必须命名为 instance,且必须在 openshift-logging 命名空间中创建。ClusterLogForwarder 资源还需要 openshift-logging 命名空间中名为 instance 的对应 ClusterLogging 资源。

9.1.2.1.2. 多日志转发器功能

日志记录 5.8 及更高版本中提供了多日志转发器功能,并提供以下功能:

  • 管理员可以控制哪些用户被允许定义日志收集以及允许收集哪些日志。
  • 具有所需权限的用户可以指定额外的日志收集配置。
  • 从已弃用的 Fluentd 收集器迁移到 Vector 收集器的管理员可以独立于现有部署部署新的日志转发程序。在迁移工作负载时,现有和新的日志转发程序可以同时运行。

在多日志转发器实现中,您不需要为 ClusterLogForwarder 资源创建对应的 ClusterLogging 资源。您可以使用任何命名空间中的任何名称创建多个 ClusterLogForwarder 资源,但以下例外:

  • 您无法在 openshift-logging 命名空间中创建一个名为 instanceClusterLogForwarder 资源,因为它为支持使用 Fluentd 收集器的传统工作流的日志转发器保留。
  • 您无法在 openshift-logging 命名空间中创建一个名为 collectorClusterLogForwarder 资源,因为这为收集器保留。
9.1.2.2. 为集群启用多日志转发器功能

要使用多日志转发器功能,您必须为该服务帐户创建服务帐户和集群角色绑定。然后,您可以在 ClusterLogForwarder 资源中引用服务帐户来控制访问权限。

重要

要在 openshift-logging 命名空间以外的额外命名空间中支持多日志转发功能,您必须更新 Red Hat OpenShift Logging Operator 以监视所有命名空间。在新的 Red Hat OpenShift Logging Operator 版本 5.8 版本中默认支持此功能。

9.1.2.2.1. 授权日志收集 RBAC 权限

在日志记录 5.8 及更高版本中,Red Hat OpenShift Logging Operator 提供了 collect-audit-logscollect-application-logscollect-infrastructure-logs 集群角色,该角色可让收集器分别收集审计日志、应用程序日志和基础架构日志。

您可以通过将所需的集群角色绑定到服务帐户来授权日志收集的 RBAC 权限。

先决条件

  • 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>

9.2. 日志输出类型

输出 (output) 定义了日志转发器将日志发送到的目的地。您可以在 ClusterLogForwarder 自定义资源 (CR) 中配置多种输出类型,将日志发送到支持不同协议的服务器。

9.2.1. 支持的日志转发输出

输出可以是以下任意类型:

表 9.8. 支持的日志输出类型
输出类型协议测试使用日志记录版本支持的收集器类型

Elasticsearch v6

HTTP 1.1

6.8.1, 6.8.23

5.6+

Fluentd, Vector

Elasticsearch v7

HTTP 1.1

7.12.2, 7.17.7, 7.10.1

5.6+

Fluentd, Vector

Elasticsearch v8

HTTP 1.1

8.4.3, 8.6.1

5.6+

Fluentd [1], Vector

Fluent Forward

Fluentd forward v1

Fluentd 1.14.6, Logstash 7.10.1, Fluentd 1.14.5

5.4+

Fluentd

Google Cloud Logging

通过 HTTPS 的 REST

Latest

5.7+

Vector

HTTP

HTTP 1.1

Fluentd 1.14.6, Vector 0.21

5.7+

Fluentd, Vector

Kafka

Kafka 0.11

Kafka 2.4.1, 2.7.0, 3.3.1

5.4+

Fluentd, Vector

Loki

使用 HTTP 和 HTTPS 的 REST

2.3.0, 2.5.0, 2.7, 2.2.1

5.4+

Fluentd, Vector

Splunk

HEC

8.2.9, 9.0.0

5.7+

Vector

Syslog

RFC3164, RFC5424

Rsyslog 8.37.0-9.el7, rsyslog-8.39.0

5.4+

Fluentd, Vector [2]

Amazon CloudWatch

通过 HTTPS 的 REST

Latest

5.4+

Fluentd, Vector

  1. Fluentd 不支持日志记录版本 5.6.2 中的 Elasticsearch 8。
  2. Vector 支持日志记录版本 5.7 及更高版本中的 Syslog。

9.2.2. 输出类型描述

default

On-cluster、Red Hat 管理的日志存储。您不需要配置默认输出。

注意

如果您配置了默认输出,您会收到错误消息,因为保留了 default 输出名称以引用 on-cluster,Red Hat managed log store。

loki
Loki,一个可横向扩展的、高可用性、多租户日志聚合系统。
kafka
Kafka 代理。kafka 输出可以使用 TCP 或 TLS 连接。
elasticsearch
一个外部 Elasticsearch 实例。elasticsearch 输出可以使用 TLS 连接。
fluentdForward

一个支持 Fluentd 的外部日志聚合解决方案。这个选项使用 Fluentd 转发 协议。fluentForward 输出可以使用 TCP 或 TLS 连接,并通过在 secret 中提供 shared_key 字段来支持共享密钥身份验证。共享密钥身份验证可在使用或不使用 TLS 的情况下使用。

重要

只有在使用 Fluentd 收集器时,才会支持 fluentdForward 输出。如果您使用 Vector 收集器,则不支持它。如果使用 Vector 收集器,您可以使用 http 输出将日志转发到 Fluentd。

syslog
支持 syslog RFC3164RFC5424 协议的外部日志聚合解决方案。syslog 输出可以使用 UDP、TCP 或 TLS 连接。
cloudwatch
Amazon CloudWatch,一种由 Amazon Web Services (AWS) 托管的监控和日志存储服务。
cloudlogging
Google Cloud Logging,由 Google Cloud Platform (GCP) 托管的监控和日志存储服务。

9.3. 启用 JSON 日志转发

您可以配置 Log Forwarding API,将 JSON 字符串解析为结构化对象。

9.3.1. 解析 JSON 日志

您可以使用 ClusterLogForwarder 对象将 JSON 日志解析到结构化对象,并将它们转发到受支持的输出。

为了说明其工作原理,假定您有以下结构化 JSON 日志条目:

结构化 JSON 日志条目示例

{"level":"info","name":"fred","home":"bedrock"}

要启用解析 JSON 日志,您需要将 parse: json 添加到 ClusterLogForwarder CR 的管道中,如下例所示。

显示 parse: json 的片段示例

pipelines:
- inputRefs: [ application ]
  outputRefs: myFluentd
  parse: json

当使用 parse: json 来启用 JSON 日志解析时,CR 会复制 structured 项中的 JSON 结构化日志条目,如下例所示。

包含结构化 JSON 日志条目的 structured 输出示例

{"structured": { "level": "info", "name": "fred", "home": "bedrock" },
 "more fields..."}

重要

如果日志条目不包含有效的结构化 JSON,则将缺少 structured 字段。

9.3.2. 为 Elasticsearch 配置 JSON 日志数据

如果您的 JSON 日志遵循多个模式,在单个索引中存储它们可能会导致类型冲突和卡性问题。要避免这种情况,您必须配置 ClusterLogForwarder 自定义资源 (CR),将每个 schema 分组到单个输出定义中。这样,每个架构被转发到单独的索引。

重要

如果您将 JSON 日志转发到 OpenShift Logging 管理的默认 Elasticsearch 实例,它会根据您的配置生成新的索引。为避免与索引数量过多相关的性能问题,请考虑通过标准化到常见模式来保持可能的模式数量较低。

结构类型

您可以使用 ClusterLogForwarder CR 中的以下结构类型来为 Elasticsearch 日志存储构建索引名称:

  • structuredTypeKey 是 message 字段的名称。该字段的值用于构造索引名称。

    • kubernetes.labels.<key> 是 Kubernetes pod 标签,其值用于构造索引名称。
    • openshift.labels.<key>ClusterLogForwarder CR 中的 pipeline.label.<key> 元素,其值用于构造索引名称。
    • kubernetes.container_name 使用容器名称来构造索引名称。
  • structuredTypeName: 如果没有设置 structuredTypeKey 字段,或者其键不存在,则 structuredTypeName 值将用作结构化类型。当您将 structuredTypeKey 字段和 structuredTypeName 字段一起使用时,如果 JSON 日志数据中缺少 structuredTypeKey 字段中的密钥,则 structuredTypeName 值将提供一个回退索引名称。
注意

虽然您可以将 structuredTypeKey 的值设置为 "Log Record Fields" 主题中显示的任何字段,但最有用的字段将显示在前面的结构类型列表中。

structuredTypeKey: kubernetes.labels.<key> 示例

假设如下:

  • 集群正在运行以两种不同格式生成 JSON 日志的应用 pod,即 "apache" 和 "google"。
  • 用户使用 logFormat=apachelogFormat=google 标记这些应用 pod。
  • 您可以在 ClusterLogForwarder CR YAML 文件中使用以下代码片段。
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat 1
      structuredTypeName: nologformat
  pipelines:
  - inputRefs:
    - application
    outputRefs:
    - default
    parse: json 2
1
使用 Kubernetes logFormat 标签形成的键值对值。
2
启用解析 JSON 日志。

在这种情况下,以下结构化日志记录进入 app-apache-write 索引:

{
  "structured":{"name":"fred","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "apache", ...}}
}

以下结构化日志记录进入 app-google-write 索引中:

{
  "structured":{"name":"wilma","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "google", ...}}
}

structuredTypeKey: openshift.labels.<key> 示例

假设您在 ClusterLogForwarder CR YAML 文件中使用了以下代码片段:

outputDefaults:
 elasticsearch:
    structuredTypeKey: openshift.labels.myLabel 1
    structuredTypeName: nologformat
pipelines:
 - name: application-logs
   inputRefs:
   - application
   - audit
   outputRefs:
   - elasticsearch-secure
   - default
   parse: json
   labels:
     myLabel: myValue 2
1
使用由 OpenShift myLabel 标签组成的键值对的值。
2
myLabel 元素将字符串值 myValue 提供给结构化日志消息。

在这种情况下,以下结构化日志记录进入 app-myValue-write 索引中:

{
  "structured":{"name":"fred","home":"bedrock"},
  "openshift":{"labels":{"myLabel": "myValue", ...}}
}

其他注意事项

  • 结构化记录的 Elasticsearch 索引通过将"app-"添加到结构化类型并附加 "-write" 来形成。
  • 非结构化记录不会发送到结构化索引。在应用、基础架构或审计索引中,它们按照常态进行索引。
  • 如果没有非空的结构化类型,则转发一个没有 structured 项的 unstructured 记录。

不要过载有太多索引的 Elasticsearch。仅对不同的日志格式使用不同的结构化类型,而不用为每个应用程序或命名空间都使用不同的结构化类型。例如,大多数 Apache 应用使用相同的 JSON 日志格式和结构化类型,如 LogApache

9.3.3. 将 JSON 日志转发到 Elasticsearch 日志存储

对于 Elasticsearch 日志存储,如果您的 JSON 日志条目遵循不同的模式,请将 ClusterLogForwarder 自定义资源 (CR) 配置为将每个 JSON 模式分组到单个输出定义中。这样,Elasticsearch 会为每个 schema 使用一个单独的索引。

重要

因为将不同的模式转发到同一索引可能会导致类型冲突和卡化问题,所以您必须在将数据转发到 Elasticsearch 存储前执行此配置。

为避免与索引数量过多相关的性能问题,请考虑通过标准化到常见模式来保持可能的模式数量较低。

流程

  1. 将以下代码片段添加到 ClusterLogForwarder CR YAML 文件中。

    outputDefaults:
     elasticsearch:
        structuredTypeKey: <log record field>
        structuredTypeName: <name>
    pipelines:
    - inputRefs:
      - application
      outputRefs: default
      parse: json
  2. 使用 structuredTypeKey 字段指定其中一个日志记录字段。
  3. 使用 structuredTypeName 字段指定名称。

    重要

    要解析 JSON 日志,您必须同时设置 structuredTypeKeystructuredTypeName 字段。

  4. 对于 inputRefs,指定要使用该管道转发哪些日志类型,如 applicationinfrastructureaudit
  5. parse: json 元素添加到管道。
  6. 创建 CR 对象:

    $ oc create -f <filename>.yaml

    Red Hat OpenShift Logging Operator 会重新部署收集器 Pod。但是,如果没有重新部署,请删除收集器 Pod 以强制重新部署。

    $ oc delete pod --selector logging-infra=collector

9.3.4. 将同一 pod 中的容器的 JSON 日志转发到单独的索引

您可以将来自同一 pod 的不同容器的结构化日志转发到不同的索引。要使用此功能,您必须使用多容器支持配置管道并注解 pod。日志被写入带有 app- 前缀的索引。建议将 Elasticsearch 配置为使用别名来容纳此目的。

重要

日志的 JSON 格式化因应用程序而异。因为创建太多索引会影响性能,所以请限制使用此功能,仅对与 JSON 格式不兼容的日志创建索引。使用查询将日志与不同命名空间分离,或使用兼容 JSON 格式的应用程序进行隔离。

先决条件

  • Red Hat OpenShift 的日志记录: 5.5

流程

  1. 创建或编辑定义 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
    1
    使用 Kubernetes logFormat 标签形成的键值对值。
    2
    启用多容器输出。
  2. 创建或编辑定义 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
    1
    格式:containerType.logging.openshift.io/<container-name>: <index>
    2
    注解名称必须与容器名称匹配
警告

此配置可能会显著增加集群中的分片数量。

其它资源

其他资源

9.4. 配置日志转发

在日志记录部署中,容器和基础架构日志默认转发到 ClusterLogging 自定义资源(CR)中定义的内部日志存储。

默认情况下,审计日志不会转发到内部日志存储,因为这不提供安全存储。您需要自己确保转发审计日志的系统符合您所在机构及政府的相关要求,并具有适当的安全性。

如果此默认配置满足您的需要,则不需要配置一个 ClusterLogForwarder CR。如果存在 ClusterLogForwarder CR,日志不会转发到内部日志存储,除非定义了包含 default 输出的管道。

9.4.1. 关于将日志转发到第三方系统

要将日志发送到 OpenShift Container Platform 集群内部和外部的特定端点,您可以在 ClusterLogForwarder 自定义资源(CR)中指定输出管道的组合。您还可以使用 输入 将与特定项目关联的应用程序日志转发到端点。身份验证由 Kubernetes Secret 对象提供。

pipeline

定义从一个日志类型到一个或多个输出的简单路由,或定义您要发送的日志。日志类型是以下之一:

  • application.由集群中运行的用户应用程序生成的容器日志(基础架构容器应用程序除外)。
  • infrastructure.在 openshift*kube*default 项目中运行的容器日志,以及来源于节点文件系统的 journal 日志。
  • audit.由节点审计系统、auditd、Kubernetes API 服务器、OpenShift API 服务器和 OVN 网络生成的审计日志。

您可以使用管道中的 key:value 对为出站日志消息添加标签。例如,您可以在转发给其他数据中心的消息中添加一个标签,或者根据类型为日志添加标签。添加到对象的标签也会通过日志消息转发。

输入

将与特定项目关联的应用程序日志转发到管道。

在管道中,您要定义使用 inputRef 参数转发哪些日志类型,以及将日志转发到使用 outputRef 参数的位置。

Secret
包含机密数据的 key:value 映射,如用户凭据。

注意以下几点:

  • 如果您没有为日志类型定义管道,则将丢弃未定义类型的日志。例如,如果您为 applicationaudit 类型指定管道,但没有为 infrastructure 类型指定管道,则 infrastructure 日志会丢弃。
  • 您可以使用 ClusterLogForwarder 自定义资源(CR)中的多种输出类型将日志发送到支持不同协议的服务器。

以下示例将审计日志转发到安全的外部 Elasticsearch 实例,基础架构日志发送到不安全的外部 Elasticsearch 实例,应用程序日志发送到 Kafka 代理,以及 my-apps-logs 项目中的应用程序日志发送到内部 Elasticsearch 实例。

日志转发输出和管道示例

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name> 1
  namespace: <log_forwarder_namespace> 2
spec:
  serviceAccountName: <service_account_name> 3
  outputs:
   - name: elasticsearch-secure 4
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: elasticsearch
   - name: elasticsearch-insecure 5
     type: "elasticsearch"
     url: http://elasticsearch.insecure.com:9200
   - name: kafka-app 6
     type: "kafka"
     url: tls://kafka.secure.com:9093/app-topic
  inputs: 7
   - name: my-app-logs
     application:
        namespaces:
        - my-project
  pipelines:
   - name: audit-logs 8
     inputRefs:
      - audit
     outputRefs:
      - elasticsearch-secure
      - default
     labels:
       secure: "true" 9
       datacenter: "east"
   - name: infrastructure-logs 10
     inputRefs:
      - infrastructure
     outputRefs:
      - elasticsearch-insecure
     labels:
       datacenter: "west"
   - name: my-app 11
     inputRefs:
      - my-app-logs
     outputRefs:
      - default
   - inputRefs: 12
      - application
     outputRefs:
      - kafka-app
     labels:
       datacenter: "south"

1
在传统的实现中,CR 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
2
在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
3
服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器,则只有多日志转发器实现中才需要服务帐户。
4
使用带有安全 URL 的 secret 来配置安全 Elasticsearch 输出。
  • 描述输出的名称。
  • 输出类型: elasticsearch
  • Elasticsearch 实例的安全 URL 和端口作为有效的绝对 URL,包括前缀。
  • 用于 TLS 通信的端点所需的 secret。secret 必须存在于 openshift-logging 项目中。
5
配置不安全的 Elasticsearch 输出:
  • 描述输出的名称。
  • 输出类型: elasticsearch
  • Elasticsearch 实例的不安全 URL 和端口作为有效的绝对 URL,包括前缀。
6
使用客户端验证的 TLS 通信通过安全 URL 配置 Kafka 输出:
  • 描述输出的名称。
  • 输出的类型: kafka
  • 将 Kafka 代理的 URL 和端口指定为一个有效的绝对 URL,包括前缀。
7
用于过滤 my-project 命名空间中的应用程序日志的输入配置。
8
用于将审计日志发送到安全的外部 Elasticsearch 实例的管道配置:
  • 描述管道的名称。
  • inputRefs 是日志类型,在这个示例中是 audit
  • outputRefs 是输出使用的名称,在本例中,elasticsearch-secure 可以转发到安全的 Elasticsearch 实例,default 转发到内部 Elasticsearch 实例。
  • 可选:添加到日志的标签。
9
可选:字符串。要添加到日志中的一个或多个标签。对值加引号(如 "true"),以便它们被识别为字符串值,而不是作为布尔值。
10
管道配置,将基础架构日志发送到不安全的外部 Elasticsearch 实例。
11
管道配置,用于将日志从 my-project 项目发送到内部 Elasticsearch 实例。
  • 描述管道的名称。
  • inputRefs 是一个特定的输入: my-app-logs
  • outputRefsdefault
  • 可选:字符串。要添加到日志中的一个或多个标签。
12
将日志发送到 Kafka 代理的管道配置,不带有管道名称:
  • inputRefs 是日志类型,在这个示例中是 application
  • outputRefs 是要使用的输出名称。
  • 可选:字符串。要添加到日志中的一个或多个标签。
当外部日志聚合器不可用时,Fluentd 日志处理

如果外部日志记录聚合器不可用且无法接收日志,Fluentd 会继续收集日志并将其存储在缓冲中。当日志聚合器可用时,日志转发会恢复,包括缓冲的日志。如果缓冲区已满,Fluentd 会停止收集日志。OpenShift Container Platform 轮转日志并删除日志。您无法调整缓冲区大小,或者将持久性卷声明(PVC)添加到 Fluentd 守护进程集或 Pod 中。

支持的授权密钥

这里提供了常见的密钥类型。某些输出类型支持额外的专用密钥,记录在特定于输出的配置字段中。所有 secret 密钥都是可选的。通过设置相关密钥来启用您想要的安全功能。您需要创建并维护外部目的地可能需要的额外配置,如密钥和 secret 、服务帐户、端口打开或全局代理服务器配置。Open Shift Logging 不会尝试验证授权组合间的不匹配。

传输层安全性(TLS)

使用没有 secret 的 TLS URL (http://...ssl://...) 启用基本的 TLS 服务器端身份验证。可通过包含 Secret 并设置以下可选字段来启用额外的 TLS 功能:

  • 密码短语 :(字符串)对编码的 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。
9.4.1.1. 创建 Secret

您可以使用以下命令在包含您的证书和密钥文件的目录中创建 secret:

$ oc create secret generic -n <namespace> <secret_name> \
  --from-file=ca-bundle.crt=<your_bundle_file> \
  --from-literal=username=<your_username> \
  --from-literal=password=<your_password>
注意

建议使用通用或不透明 secret 来获得最佳结果。

9.4.2. 创建日志转发器

要创建日志转发器,您必须创建一个 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:
  serviceAccountName: <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 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
2
在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
3
服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器,则只有多日志转发器实现中才需要服务帐户。
4
收集的日志类型。此字段的值可以是 audit(用于审计日志)、application(用于应用程序日志)、infrastructure(用于基础架构日志),或输入为您的应用程序定义的名称。
5 7
要将日志转发到的输出类型。此字段的值可以是 default,loki,kafka,elasticsearch,fluentdForward,syslog, 或 cloudwatch
注意

多日志转发器实现不支持 default 输出类型。

6
要将日志转发到的输出的名称。
8
要将日志转发到的输出的 URL。

9.4.3. 调整日志有效负载和交付

在日志记录 5.9 及更新版本中,ClusterLogForwarder 自定义资源(CR)中的 tuning spec 提供了配置部署以优先选择日志吞吐量或持久性的方法。

例如,如果您需要减少收集器重启时日志丢失的可能性,或者您需要在收集器重启后收集日志消息来支持规范,您可以调整部署以优先选择日志持久性。如果您使用对可以接收的批处理大小有硬限制的输出,您可能需要调整部署以优先处理日志吞吐量。

重要

要使用这个功能,您的日志记录部署必须配置为使用 Vector 收集器。使用 Fluentd 收集器时,不支持 ClusterLogForwarder CR 中的 tuning spec。

以下示例显示了您可以修改的 ClusterLogForwarder CR 选项来调整日志转发器输出:

ClusterLogForwarder CR 调整选项示例

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  tuning:
    delivery: AtLeastOnce 1
    compression: none 2
    maxWrite: <integer> 3
    minRetryDuration: 1s 4
    maxRetryDuration: 1s 5
# ...

1
指定日志转发的交付模式。
  • AtLeastOnce 交付表示如果日志转发器崩溃或重启,则任何在崩溃前读取的日志都会重新发送到其目的地。有些日志可能会在崩溃后重复。
  • AtMostOnce 交付意味着日志转发器不会努力恢复崩溃期间丢失的日志。这个模式可以提供更好的吞吐量,但可能会导致日志丢失。
2
指定 compression 配置会导致在通过网络发送数据前压缩数据。请注意,并非所有输出类型都支持压缩,如果输出不支持指定的压缩类型,这会导致错误。此配置的可能值为 none(不压缩)、gzipsnappyzlibzstd。如果您使用 Kafka 输出,也可以使用 lz4 压缩。如需更多信息,请参阅表"支持压缩类型用于调优输出"。
3
为向输出发送操作的最大有效负载指定限制。
4
指定在失败后重试发送前在尝试之间等待的时间。这个值是一个字符串,可指定为毫秒(ms)、秒(s)或分钟(m)。
5
指定在失败后重试发送前在尝试之间等待的最长时间。这个值是一个字符串,可指定为毫秒(ms)、秒(s)或分钟(m)。
表 9.9. 支持的调整输出的压缩类型
压缩算法SplunkAmazon CloudwatchElasticsearch 8LokiStackApache KafkaHTTPSyslogGoogle CloudMicrosoft Azure Monitoring

gzip

X

X

X

X

 

X

   

snappy

 

X

 

X

X

X

   

zlib

 

X

X

  

X

   

zstd

 

X

  

X

X

   

lz4

    

X

    

9.4.4. 启用多行异常检测

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

警告

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

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

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

9.4.4.1. 详情

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

表 9.10. 每个收集器支持的语言:
语言FluentdVector

Java

JS

Ruby

Python

Golang

PHP

Dart

9.4.4.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>

9.4.5. 将日志转发到 Google Cloud Platform (GCP)

除了默认的 OpenShift Container Platform 日志存储外,您还可以将日志转发到 Google Cloud Logging

注意

不支持在 Fluentd 中使用此功能。

先决条件

  • Red Hat OpenShift Logging Operator 5.5.1 及更新的版本

流程

  1. 使用 Google 服务帐户密钥创建 secret。

    $ oc -n openshift-logging create secret generic gcp-secret --from-file google-application-credentials.json=<your_service_account_key_file.json>
  2. 使用以下模板创建 ClusterLogForwarder 自定义资源 YAML:

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
        - name: gcp-1
          type: googleCloudLogging
          secret:
            name: gcp-secret
          googleCloudLogging:
            projectId : "openshift-gce-devel" 4
            logId : "app-gcp" 5
      pipelines:
        - name: test-app
          inputRefs: 6
            - application
          outputRefs:
            - gcp-1
    1
    在传统的实现中,CR 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
    2
    在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
    3
    服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器,则只有多日志转发器实现中才需要服务帐户。
    4
    根据您要将日志存储在 GCP 资源层次结构中的位置,设置 projectId, folderId, organizationId, 或 billingAccountId 的项及其相应的值。
    5
    将值设为添加到 Log EntrylogName 字段的值。
    6
    使用管道指定要转发的日志类型:application, infrastructure, 或 audit

9.4.6. 将日志转发到 Splunk

除了内部的默认 OpenShift Container Platform 日志存储外,您还可以将日志转发到 Splunk HTTP 事件收集器 (HEC)

注意

不支持在 Fluentd 中使用此功能。

先决条件

  • Red Hat OpenShift Logging Operator 5.6 或更高版本
  • 带有指定了 vectorClusterLogging 实例作为收集器
  • Base64 编码的 Splunk HEC 令牌

流程

  1. 使用您的 Base64 编码的 Splunk HEC 令牌创建 secret。

    $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>
  2. 使用以下模板创建或编辑 ClusterLogForwarder 自定义资源 (CR):

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
        - name: splunk-receiver 4
          secret:
            name: vector-splunk-secret 5
          type: splunk 6
          url: <http://your.splunk.hec.url:8088> 7
      pipelines: 8
        - inputRefs:
            - application
            - infrastructure
          name: 9
          outputRefs:
            - splunk-receiver 10
    1
    在传统的实现中,CR 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
    2
    在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
    3
    服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器,则只有多日志转发器实现中才需要服务帐户。
    4
    指定输出的名称。
    5
    指定包含 HEC 令牌的 secret 名称。
    6
    将输出类型指定为 mvapich
    7
    指定 Splunk HEC 的 URL (包括端口)。
    8
    使用管道指定要转发的日志类型:application, infrastructure, 或 audit
    9
    可选:指定管道的名称。
    10
    指定使用此管道转发日志时使用的输出名称。

9.4.7. 通过 HTTP 转发日志

Fluentd 和 Vector 日志收集器都支持通过 HTTP 转发日志。要启用,在 ClusterLogForwarder 自定义资源 (CR) 中指定 http 作为输出类型。

流程

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

    ClusterLogForwarder CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
        - name: httpout-app
          type: http
          url: 4
          http:
            headers: 5
              h1: v1
              h2: v2
            method: POST
          secret:
            name: 6
          tls:
            insecureSkipVerify: 7
      pipelines:
        - name:
          inputRefs:
            - application
          outputRefs:
            - 8

    1
    在传统的实现中,CR 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
    2
    在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
    3
    服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器,则只有多日志转发器实现中才需要服务帐户。
    4
    日志的目标地址。
    5
    使用日志记录发送的其他标头。
    6
    目标凭证的 secret 名称。
    7
    值可以是 truefalse
    8
    这个值应当与输出名称相同。

9.4.8. 转发到 Azure Monitor 日志

使用日志记录 5.9 及之后的版本时,除了默认的日志存储外,您还可以将日志转发到 Azure Monitor 日志。这个功能由 Vector Azure Monitor Logs sink 提供。

先决条件

  • 熟悉如何管理和创建 ClusterLogging 自定义资源 (CR) 实例。
  • 熟悉如何管理和创建 ClusterLogForwarder CR 实例。
  • 您了解 ClusterLogForwarder CR 规格。
  • 您对 Azure 服务有一定的了解。
  • 您已为 Azure Portal 或 Azure CLI 访问配置了 Azure 帐户。
  • 您已获取了 Azure Monitor Logs 主或从安全密钥。
  • 您已确定要转发的日志类型。

通过 HTTP Data Collector API 启用日志转发到 Azure Monitor 日志:

使用您的共享密钥创建 secret:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: openshift-logging
type: Opaque
data:
  shared_key: <your_shared_key> 1
1
必须包含生成请求的 Log Analytics 工作区 的主或从密钥。

要获取共享密钥,您可以在 Azure CLI 中使用这个命令:

Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "<resource_name>" -Name "<workspace_name>”

使用与日志选择匹配的模板创建或编辑 ClusterLogForwarder CR。

转发所有日志

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id 1
      logType: my_log_type 2
    secret:
       name: my-secret
  pipelines:
  - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor

1
Log Analytics 工作区的唯一标识符。必填字段。
2
正在提交的数据的 Azure 记录类型。只能包含字母、数字和下划线 (_),且不得超过 100 个字符。

转发应用程序和基础架构日志

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor-app
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: application_log 1
    secret:
      name: my-secret
  - name: azure-monitor-infra
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: infra_log #
    secret:
      name: my-secret
  pipelines:
    - name: app-pipeline
      inputRefs:
      - application
      outputRefs:
      - azure-monitor-app
    - name: infra-pipeline
      inputRefs:
      - infrastructure
      outputRefs:
      - azure-monitor-infra

1
正在提交的数据的 Azure 记录类型。只能包含字母、数字和下划线 (_),且不得超过 100 个字符。

高级配置选项

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: my_log_type
      azureResourceId: "/subscriptions/111111111" 1
      host: "ods.opinsights.azure.com" 2
    secret:
       name: my-secret
  pipelines:
   - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor

1
数据应与之关联的 Azure 资源的资源 ID。可选字段。
2
专用 Azure 区域的替代主机。可选字段。默认值为 ods.opinsights.azure.com。Azure Government 的默认值为 ods.opinsights.azure.us

9.4.9. 从特定项目转发应用程序日志

除了内部日志存储外,您还可以将特定项目的应用程序日志副本转发到外部日志聚合器。您还必须配置外部日志聚合器,以接收来自 OpenShift Container Platform 的日志数据。

要从项目中配置转发应用程序日志,创建一个 ClusterLogForwarder 自定义资源(CR),其中至少从一个项目中输入,为其他日志聚合器提供可选输出,以及使用这些输入和输出的管道。

先决条件

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

流程

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

    ClusterLogForwarder CR 示例

    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 8
      pipelines:
       - name: forward-to-fluentd-insecure 9
         inputRefs: 10
         - my-app-logs
         outputRefs: 11
         - fluentd-server-insecure
         labels:
           project: "my-project" 12
       - name: forward-to-fluentd-secure 13
         inputRefs:
         - application 14
         - 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.crttls.keyca-bundle.crt 密钥。
    7
    用于过滤指定项目的应用程序日志的输入配置。
    8
    如果没有指定命名空间,则会从所有命名空间收集日志。
    9
    管道配置将来自一个命名输入的日志定向到一个命名的输出。在本例中,名为 forward-to-fluentd-insecure 的管道将日志从一个名为 my-app-logs 的输入转发到名为 fluentd-server-insecure 的输出。
    10
    输入列表。
    11
    要使用的输出名称。
    12
    可选:字符串。要添加到日志中的一个或多个标签。
    13
    管道配置,将日志发送到其他日志聚合器。
    • 可选:指定管道的名称。
    • 使用管道指定要转发的日志类型:applicationinfrastructureaudit
    • 指定使用此管道转发日志时使用的输出名称。
    • 可选:指定将日志转发到默认日志存储的默认输出。
    • 可选:字符串。要添加到日志中的一个或多个标签。
    14
    请注意,使用此配置时,会从所有命名空间收集应用程序日志。
  2. 运行以下命令来应用 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml

9.4.10. 从特定 pod 转发应用程序日志

作为集群管理员,您可以使用 Kubernetes pod 标签从特定 pod 收集日志数据并将其转发到日志收集器。

假设您的应用由容器集组成,并与不同命名空间中的其他容器集一起运行。如果这些 pod 具有标识应用程序标签,您可以收集和输出其日志数据到特定的日志收集器。

要指定 pod 标签,请使用一个或多个 matchLabels 键值对。如果指定了多个键值对,pod 必须与要选择的所有值匹配。

流程

  1. 创建或编辑定义 ClusterLogForwarder CR 对象的 YAML 文件。在文件中,使用 inputs[].name.application.selector.matchLabels 下的简单基于平等的选择器来指定 pod 标签,如下例所示。

    ClusterLogForwarder CR YAML 文件示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 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
        - <output_name>
        ...

    1
    在传统的实现中,CR 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
    2
    在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
    3
    指定来自 inputs[].name 的一个或多个以逗号分隔的值。
    4
    指定来自 outputs[] 的一个或多个以逗号分隔的值。
    5
    为具有一组唯一 pod 标签的每个应用程序定义唯一的 inputs[].name
    6
    指定您要收集的日志数据的 pod 标签的键值对。您必须指定一个键和值,而不仅仅是一个键。要被选择,pod 必须与所有键值对匹配。
    7
    可选:指定一个或多个命名空间。
    8
    指定要将日志数据转发到的一个或多个输出。
  2. 可选: 要将日志数据收集限制为特定的命名空间,请使用 inputs[].name.application.namespaces,如上例中所示。
  3. 可选: 您可以从具有不同 pod 标签的额外应用程序向同一管道发送日志数据。

    1. 对于 pod 标签的每个唯一组合,创建一个类似于显示的 inputs[].name 部分。
    2. 更新选择器(selectors)以匹配此应用的容器集标签。
    3. 将新的 inputs[].name 值添加到 inputRefs。例如:

      - inputRefs: [ myAppLogData, myOtherAppLogData ]
  4. 创建 CR 对象。

    $ oc create -f <file-name>.yaml

其他资源

9.4.11. API 审计过滤器概述

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

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

在日志记录 5.8 及更高版本中,ClusterLogForwarder 自定义资源 (CR) 使用与标准 Kubernetes Audit 策略相同的格式,同时提供以下附加功能:

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

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

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

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

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

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

注意

提供的示例旨在说明审计策略中可能的规则范围,不是推荐的配置。

Audit 策略示例

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-pipeline
      inputRefs: audit 1
      filterRefs: my-policy 2
      outputRefs: default
  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
审计策略的名称。

9.4.12. 将日志转发到外部 Loki 日志记录系统

除了默认的日志存储外,您还可以将日志转发到外部 Loki 日志记录系统。

要配置日志转发到 Loki,您必须创建一个 ClusterLogForwarder 自定义资源 (CR),并创建一个输出到 Loki 的 ClusterLogForwarder 自定义资源 (CR),以及使用输出的管道。到 Loki 的输出可以使用 HTTP(不安全)或 HTTPS(安全 HTTP)连接。

先决条件

  • 您必须有一个 Loki 日志记录系统在您通过 CR 中的 url 字段指定的 URL 中运行。

流程

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

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
      - name: loki-insecure 4
        type: "loki" 5
        url: http://loki.insecure.com:3100 6
        loki:
          tenantKey: kubernetes.namespace_name
          labelKeys:
          - kubernetes.labels.foo
      - name: loki-secure 7
        type: "loki"
        url: https://loki.secure.com:3100
        secret:
          name: loki-secret 8
        loki:
          tenantKey: kubernetes.namespace_name 9
          labelKeys:
          - kubernetes.labels.foo 10
      pipelines:
      - name: application-logs 11
        inputRefs:  12
        - application
        - audit
        outputRefs: 13
        - loki-secure
    1
    在传统的实现中,CR 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
    2
    在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
    3
    服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器,则只有多日志转发器实现中才需要服务帐户。
    4
    指定输出的名称。
    5
    将类型指定为 "loki"
    6
    将 Loki 系统的 URL 和端口指定为有效的绝对 URL。您可以使用 http (不安全)或 https (安全 HTTP)协议。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。Loki 用于 HTTP(S) 通讯的默认端口为 3100。
    7
    对于安全连接,您可以通过指定 secret 来指定您进行身份验证的 httpshttp URL。
    8
    对于 https 前缀,请指定 TLS 通信端点所需的 secret 名称。secret 必须包含一个 ca-bundle.crt 键,它指向它所代表的证书。否则,对于 httphttps 前缀,您可以指定一个包含用户名和密码的 secret。在旧的实现中,secret 必须存在于 openshift-logging 项目中。如需更多信息,请参阅以下"示例:设置包含用户名和密码的 secret"。
    9
    可选:指定一个 metadata key 字段,为 Loki 中的 TenantID 字段生成值。例如,设置 tenantKey: kubernetes.namespace_name 使用 Kubernetes 命名空间的名称作为 Loki 中的租户 ID 的值。要查看您可以指定的其他日志记录字段,请查看以下"Additional resources"部分中的"Log Record Fields"链接。
    10
    可选:指定一个 metadata 字段键列表来替换默认的 Loki 标签。Loki 标签名称必须与正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]* 匹配。元数据键中的非法字符被替换为 _,以组成标签名称。例如,kubernetes.labels.foo 元数据键变成 Loki 标签 kubernetes_labels_foo。如果没有设置 labelKeys,则默认值为:[log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host]。尽量保持标签数量少,因为 Loki 会限制允许标签的大小和数量。请参阅配置 Loki、limit_config。您仍然可以使用查询过滤器基于任何日志记录字段进行查询。
    11
    可选:指定管道的名称。
    12
    使用管道指定要转发的日志类型:applicationinfrastructureaudit
    13
    指定使用此管道转发日志时使用的输出名称。
    注意

    由于 Loki 要求按时间戳正确排序日志流,labelKeys 始终包含 kubernetes_host 标签,即使您没有指定它。此包含确保每个流源自单一主机,这样可防止因为不同主机上的时钟差异而导致时间戳出现问题。

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

    $ oc apply -f <filename>.yaml

其他资源

9.4.13. 将日志转发到外部 Elasticsearch 实例

除了内部日志存储外,您还可以将日志转发到外部 Elasticsearch 实例。您需要配置外部日志聚合器,以接收来自 OpenShift Container Platform 的日志数据。

要配置日志转发到外部 Elasticsearch 实例,请创建一个 ClusterLogForwarder 自定义资源(CR),其中包含输出到该实例的输出以及使用输出的管道。外部 Elasticsearch 输出可以使用 HTTP(不安全)或 HTTPS(安全 HTTP)连接。

要将日志转发到外部和内部 Elasticsearch 实例,请将输出和管道创建到外部实例,以及一个使用 default 输出将日志转发到内部实例的管道。

注意

如果您只想将日志转发到内部 Elasticsearch 实例,则不需要创建一个 ClusterLogForwarder CR。

先决条件

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

流程

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

    ClusterLogForwarder CR 示例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name> 1
      namespace: <log_forwarder_namespace> 2
    spec:
      serviceAccountName: <service_account_name> 3
      outputs:
       - name: elasticsearch-example 4
         type: elasticsearch 5
         elasticsearch:
           version: 8 6
         url: http://elasticsearch.example.com:9200 7
         secret:
           name: es-secret 8
      pipelines:
       - name: application-logs 9
         inputRefs: 10
         - application
         - audit
         outputRefs:
         - elasticsearch-example 11
         - default 12
         labels:
           myLabel: "myValue" 13
    # ...

    1
    在传统的实现中,CR 名称必须是 instance。在多日志转发器实现中,您可以使用任何名称。
    2
    在旧的实现中,CR 命名空间必须是 openshift-logging。在多日志转发器实现中,您可以使用任何命名空间。
    3
    服务帐户的名称。如果没有在 openshift-logging 命名空间中部署日志转发器,则只有多日志转发器实现中才需要服务帐户。
    4
    指定输出的名称。
    5
    指定 elasticsearch 类型。
    6
    指定 Elasticsearch 版本。这可以是 678
    7
    指定外部 Elasticsearch 实例的 URL 和端口作为有效的绝对 URL。您可以使用 http (不安全)或 https (安全 HTTP)协议。如果启用了使用 CIDR 注解的集群范围代理,输出必须是服务器名称或 FQDN,而不是 IP 地址。
    8
    对于 https 前缀,请指定 TLS 通信端点所需的 secret 名称。secret 必须包含一个 ca-bundle.crt 键,它指向它所代表的证书。否则,对于 httphttps 前缀,您可以指定一个包含用户名和密码的 secret。在旧的实现中,secret 必须存在于 openshift-logging 项目中。如需更多信息,请参阅以下"示例:设置包含用户名和密码的 secret"。
    9
    可选:指定管道的名称。
    10
    使用管道指定要转发的日志类型:applicationinfrastructureaudit
    11
    指定使用此管道转发日志时使用的输出名称。
    12
    可选:指定将日志发送到内部 Elasticsearch 实例的 default 输出。
    13
    可选:字符串。要添加到日志中的一个或多个标签。
  2. 应用 ClusterLogForwarder CR:

    $ oc apply -f <filename>.yaml

示例:设置包含用户名和密码的 secret

您可以使用包含用户名和密码的 secret 来验证与外部 Elasticsearch 实例的安全连接。

例如,如果无法使用 mutual TLS (mTLS) 密钥,因为第三方运行 Elasticsearch 实例,您可以使用 HTTP 或 HTTPS 并设置包含用户名和密码的 secret。

  1. 创建类似于以下示例的 Secret YAML 文件。将 base64 编码的值用于 usernamepassword 字段。secret 类型默认为 opaque。

    apiVersion: v1
    kind: Secret
    metadata:
      name: openshift-test-secret
    data:
      username: <username>
      password: <password>
    # ...
  2. 创建 secret:

    $ oc create secret -n openshift-logging openshift-test-secret.yaml
  3. 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 字段中,前缀可以是 httphttps

  4. 应用 CR 对象:

    $ oc apply -f <filename>.yaml

9.4.14. 使用 Fluentd 转发协议转发日志

您可以使用 Fluentd forward 协议将日志副本发送到配置为接受协议的外部日志聚合器,而非默认的 Elasticsearch 日志存储。您需要配置外部日志聚合器以接收来自 OpenShift Container Platform 的日志。

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

先决条件

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

流程

  1. 创建或编辑定义 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 项目中,且必须包含指向它所代表证书的 ca-bundle.crt 键。
    7
    可选:指定管道的名称。
    8
    使用管道指定要转发的日志类型:applicationinfrastructureaudit
    9
    指定使用此管道转发日志时使用的输出名称。
    10
    可选:指定将日志转发到内部 Elasticsearch 实例的 default 输出。
    11
    可选:字符串。要添加到日志中的一个或多个标签。
    12
    可选:配置多个输出,将日志转发到任何受支持类型的其他外部日志聚合器:
    • 描述管道的名称。
    • inputRefs 是使用管道转发的日志类型:applicationinfrastructureaudit
    • outputRefs 是要使用的输出名称。
    • 可选:字符串。要添加到日志中的一个或多个标签。
  2. 创建 CR 对象:

    $ oc create -f <file-name>.yaml
9.4.14.1. 为 Logsta