搜索
支持控制台（Console）开发人员开始试用联系人

日志记录

download PDF
OpenShift Container Platform 4.11

OpenShift Logging 安装、使用和发行注记

Red Hat OpenShift Documentation Team

摘要

本文档提供有关安装、配置和使用 OpenShift Logging 的说明，该 Logging 将汇总多个 OpenShift Container Platform 服务的日志。

第 1 章 发行注记

1.1. Logging 5.7

注意

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

注意

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

1.1.1. Logging 5.7.10

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

1.1.1.1. 程序错误修复

在此次更新之前，LokiStack 规则器 pod 不会将 IPv6 pod IP 格式化为用于跨 pod 通信的 HTTP URL，从而导致通过 Prometheus 兼容的 API 查询规则和警报失败。在这个版本中，LokiStack 规则器 pod 将 IPv6 pod IP 封装在方括号中，从而解决了这个问题。(LOG-4891)

1.1.1.2. CVE

1.1.2. Logging 5.7.9

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

1.1.2.1. 程序错误修复
  • 在此次更新之前，在为占位符评估一个或多个主机后，不会正确解析 IPv6 地址。在这个版本中，IPv6 地址会被正确解析。(LOG-4281)
  • 在此次更新之前，Vector 无法在只使用 IPv4 的节点上启动。因此，无法为其指标端点创建一个监听程序，并显示以下错误：Failed to start Prometheus exporter: TCP bind failed: Address family not supported by protocol (os error 97)。在这个版本中，Vector 通常在 IPv4 节点上运行。(LOG-4589)
  • 在此次更新之前，在创建索引模式的过程中，每个日志输出的初始索引中缺少默认别名。因此，Kibana 用户无法使用 OpenShift Elasticsearch Operator 创建索引模式。在这个版本中，在 OpenShift Elasticsearch Operator 中添加缺少的别名，从而解决了这个问题。Kibana 用户现在可以创建包含 {app,infra,audit}-000001 索引的索引模式。(LOG-4806)
  • 在此次更新之前，Loki Operator 不会将自定义 CA 捆绑包挂载到规则 pod。因此，在评估警报或记录规则的过程中，对象存储访问会失败。在这个版本中，Loki Operator 将自定义 CA 捆绑包挂载到所有规则 pod。规则器 pod 可以从对象存储下载日志，以评估警报或记录规则。(LOG-4837)
  • 在此次更新之前，使用控制（如时间范围或严重性）更改 LogQL 查询会改变标签 matcher 运算符，就像正则表达式一样定义。在这个版本中，正则表达式运算符在更新查询时保持不变。(LOG-4842)
  • 在此次更新之前，Vector 收集器部署依赖于默认的重试和缓冲行为。因此，交付管道会在输出不稳定时尝试发送每个消息。在这个版本中，Vector 收集器部署会在超过阈值后限制消息重试和丢弃消息的数量。(LOG-4536)
1.1.2.2. CVE

1.1.3. Logging 5.7.8

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

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

1.1.4. Logging 5.7.7

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

1.1.4.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.1.4.2. CVE

1.1.5. Logging 5.7.6

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

1.1.5.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.1.5.2. CVE

1.1.6. Logging 5.7.4

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

1.1.6.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.1.6.2. CVE

1.1.7. Logging 5.7.3

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

1.1.7.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.1.7.2. CVE

1.1.8. Logging 5.7.2

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

1.1.8.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 中命名管道，application 或 infrastructure 会导致收集器 pod 处于 CrashLoopBackOff 状态，并在收集器日志中出现以下错误： 

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

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

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

1.1.9. Logging 5.7.1

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

1.1.9.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.1.9.2. CVE

1.1.10. Logging 5.7.0

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

1.1.10.1. 功能增强

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

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

1.1.10.2. 已知问题

无。

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

1.2. Logging 5.6

注意

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

注意

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

1.2.1. Logging 5.6.16

此发行版本包括 日志记录程序错误修复 5.6.16

1.2.1.1. 程序错误修复
  • 在此次更新之前，当配置为读取自定义 S3 证书颁发机构时，Loki Operator 不会在 ConfigMap 的名称或内容改变时自动更新配置。在这个版本中，Loki Operator 会监视 ConfigMap 的更改，并自动更新生成的配置。(LOG-4967)
1.2.1.2. CVE

1.2.2. Logging 5.6.15

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

1.2.2.1. 程序错误修复

在此次更新之前，LokiStack 规则器 pod 不会将 IPv6 pod IP 格式化为用于跨 pod 通信的 HTTP URL，从而导致通过 Prometheus 兼容的 API 查询规则和警报失败。在这个版本中，LokiStack 规则器 pod 将 IPv6 pod IP 封装在方括号中，从而解决了这个问题。(LOG-4892)

1.2.2.2. CVE

1.2.3. Logging 5.6.14

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

1.2.3.1. 程序错误修复
  • 在此次更新之前，在创建索引模式的过程中，每个日志输出的初始索引中缺少默认别名。因此，Kibana 用户无法使用 OpenShift Elasticsearch Operator 创建索引模式。在这个版本中，在 OpenShift Elasticsearch Operator 中添加缺少的别名，从而解决了这个问题。Kibana 用户现在可以创建包含 {app,infra,audit}-000001 索引的索引模式。(LOG-4807)
  • 在此次更新之前，Loki Operator 不会将自定义 CA 捆绑包挂载到规则 pod。因此，在评估警报或记录规则的过程中，对象存储访问会失败。在这个版本中，Loki Operator 将自定义 CA 捆绑包挂载到所有规则 pod。规则器 pod 可以从对象存储下载日志，以评估警报或记录规则。(LOG-4838)
1.2.3.2. CVE

1.2.4. Logging 5.6.13

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

1.2.4.1. 程序错误修复

无。

1.2.4.2. CVE

1.2.5. Logging 5.6.12

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

1.2.5.1. 程序错误修复
  • 在此次更新之前，在 IPv6 或双栈 OpenShift Container Platform 集群上部署 LokiStack 会导致 LokiStack memberlist 注册失败。因此，经销商 Pod 会进入崩溃循环。在这个版本中，管理员可以通过将 lokistack.spec.hashRing.memberlist.enableIPv6: 值设置为 true 来启用 IPv6，这会解决这个问题。目前，启用了 IPv6 的集群上没有日志警报。(LOG-4570)
  • 在此次更新之前，在由 Cluster Logging Operator 创建的指标仪表板中，查询中存在一个错误，用于 FluentD Buffer Availability 图，因为它显示最小缓冲区用量。在这个版本中，图形显示最大缓冲区使用量，现在被重命名为 FluentD Buffer Usage。(LOG-4579)
  • 在此次更新之前，事件路由器中未使用的指标会导致容器因为过量内存用量而失败。在这个版本中，通过删除未使用的指标来减少事件路由器的内存用量。(LOG-4687)
1.2.5.2. CVE

1.2.6. Logging 5.6.11

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

1.2.6.1. 程序错误修复
  • 在此次更新之前，LokiStack 网关会广泛缓存授权请求。因此，这会导致错误的授权结果。在这个版本中，Loki 网关缓存以更精细的方式缓存来解决这个问题。(LOG-4435)
1.2.6.2. CVE

1.2.7. Logging 5.6.9

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

1.2.7.1. 程序错误修复
  • 在此次更新之前，当使用多个角色使用带有 AWS Cloudwatch 转发的 STS 进行身份验证时，最近更新会导致凭证不是唯一的。在这个版本中，STS 角色和静态凭证的多个组合可以再次用于与 AWS Cloudwatch 进行身份验证。(LOG-4084)
  • 在此次更新之前，向量收集器偶尔会在日志中出现以下错误信息：thread 'vector-worker' panicked at 'all branch are disabled, no else branch', src/kubernetes/reflector.rs:26:9。在这个版本中，这个错误已解决。(LOG-4276)
  • 在此次更新之前，Loki 为活跃流过滤标签值，但没有删除重复，使 Grafana 的标签浏览器不可用。在这个版本中，Loki 会过滤活跃流的重复标签值，从而解决了这个问题。(LOG-4390)
1.2.7.2. CVE

1.2.8. Logging 5.6.8

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

1.2.8.1. 程序错误修复
  • 在此次更新之前，当输入匹配标签值包含 ClusterLogForwarder 中的 / 字符时，向量收集器意外终止。在这个版本中，通过引用 match 标签解决了这个问题，使收集器能够启动和收集日志。(LOG-4091)
  • 在此次更新之前，当在 OpenShift Container Platform Web 控制台中查看日志时，点更多数据可用选项仅在第一次点击时加载更多日志条目。在这个版本中，每次点击时会加载更多条目。(OU-187)
  • 在此次更新之前，当在 OpenShift Container Platform Web 控制台中查看日志时，点 streaming 选项只显示 流传输 日志消息，而无需显示实际日志。在这个版本中，消息和日志流都会正确显示。(OU-189)
  • 在此次更新之前，Loki Operator 会重置错误，导致识别配置问题很难排除故障。在这个版本中，错误会保留，直到配置错误解决为止。(LOG-4158)
  • 在此次更新之前，具有超过 8,000 个命名空间的集群会导致 Elasticsearch 拒绝查询，因为命名空间列表大于 http.max_header_size 设置。在这个版本中，标头大小的默认值有所增加，从而解决了这个问题。(LOG-4278)
1.2.8.2. CVE

1.2.9. Logging 5.6.5

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

1.2.9.1. 程序错误修复
  • 在此次更新之前，模板定义会阻止 Elasticsearch 索引一些标签和 namespace_labels，从而导致数据 ingestion 出现问题。在这个版本中，修复替换了标签中的点和斜杠，以确保正确修正、有效地解决问题。(LOG-3419)
  • 在此次更新之前，如果 OpenShift Web 控制台的 Logs 页面无法连接到 LokiStack，则会显示通用错误消息，从而不提供额外的上下文或故障排除建议。在这个版本中，错误消息已被改进，使其包含更具体的故障排除详情和建议。(LOG-3750)
  • 在此次更新之前，时间范围格式不会被验证，从而导致选择自定义日期范围的错误。在这个版本中，时间格式会被验证，允许用户选择有效的范围。如果选择了无效的时间范围格式，则会向用户显示错误消息。(LOG-3583)
  • 在此次更新之前，当在 Loki 中搜索日志时，即使表达式的长度不超过 5120 个字符，查询也会在很多情况下失败。在这个版本中，查询授权标签匹配程序已被优化，从而解决了这个问题。(LOG-3480)
  • 在此次更新之前，Loki Operator 无法生成一个 memberlist 配置，该配置足以在使用 memberlist 进行私有 IP 时查找所有组件。在这个版本中，确保生成的配置包含公告的端口，从而成功查找所有组件。(LOG-4008)
1.2.9.2. CVE

1.2.10. Logging 5.6.4

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

1.2.10.1. 程序错误修复
  • 在此次更新之前，当 LokiStack 部署为日志存储时，Loki pod 生成的日志会被收集并发送到 LokiStack。在这个版本中，Loki 生成的日志不包括在集合中，不会存储。(LOG-3280)
  • 在此次更新之前，当 OpenShift Web 控制台的 Logs 页面中的查询编辑器为空时，下拉菜单不会被填充。在这个版本中，如果尝试空查询，会显示错误消息，且下拉菜单现在会如预期填充。(LOG-3454)
  • 在此次更新之前，当 tls.insecureSkipVerify 选项被设置为 true 时，Cluster Logging Operator 会生成不正确的配置。因此，当尝试跳过证书验证时，Operator 无法将数据发送到 Elasticsearch。在这个版本中，Cluster Logging Operator 会生成正确的 TLS 配置，即使启用了 tls.insecureSkipVerify。因此，即使尝试跳过证书验证，数据也可以成功发送到 Elasticsearch。(LOG-3475)
  • 在此次更新之前，当启用结构化解析且消息转发到多个目的地时，它们不会被深度复制。这会导致一些接收的日志，包括结构化消息，而其他日志则没有。在这个版本中，在 JSON 解析前，配置生成已被修改为深度复制信息。因此，所有收到的消息现在都包含结构化消息，即使它们被转发到多个目的地。(LOG-3640)
  • 在此次更新之前，如果 collection 字段包含 {}，可能会导致 Operator 崩溃。在这个版本中，Operator 将忽略这个值，允许 Operator 在不中断的情况下平稳运行。(LOG-3733)
  • 在此次更新之前，LokiiHost 的 Gateway 组件的 nodeSelector 属性没有任何效果。在这个版本中，nodeSelector 属性可以正常工作。(LOG-3783)
  • 在此次更新之前，静态 LokiStack memberlist 配置只依赖于私有 IP 网络。因此，当 OpenShift Container Platform 集群 pod 网络配置了公共 IP 范围时，Lokiition pod 会出现 crashloop。在这个版本中，Loki 管理员可以选择将 pod 网络用于 memberlist 配置。这解决了这个问题，并防止 LokiStack pod 在 OpenShift Container Platform 集群 pod 网络配置了公共 IP 范围时进入 crashloop 状态。(LOG-3814)
  • 在此次更新之前，如果 tls.insecureSkipVerify 字段设置为 true，Cluster Logging Operator 会生成不正确的配置。因此，当尝试跳过证书验证时，Operator 无法将数据发送到 Elasticsearch。在这个版本中，即使启用了 tls.insecureSkipVerify，Operator 也会生成正确的 TLS 配置。因此，即使尝试跳过证书验证，数据也可以成功发送到 Elasticsearch。(LOG-3838)
  • 在此次更新之前，如果 Cluster Logging Operator (CLO) 安装没有 Elasticsearch Operator，则 CLO pod 会持续显示与删除 Elasticsearch 相关的错误消息。在这个版本中，CLO 在显示任何错误消息前执行额外的检查。因此，没有 Elasticsearch Operator 时不再显示与 Elasticsearch 删除相关的错误消息。(LOG-3763)
1.2.10.2. CVE

1.2.11. Logging 5.6.3

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

1.2.11.1. 程序错误修复
  • 在此次更新之前，Operator 将网关租户 secret 信息存储在配置映射中。在这个版本中，Operator 将此信息存储在 secret 中。(LOG-3717)
  • 在此次更新之前，Fluentd 收集器不会捕获存储在 /var/log/auth-server/audit.log 中的 OAuth 登录事件。在这个版本中，Fluentd 会捕获这些 OAuth 登录事件，从而解决了这个问题。(LOG-3729)
1.2.11.2. CVE

1.2.12. 日志记录 5.6.2

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

1.2.12.1. 程序错误修复
  • 在此次更新之前，收集器没有根据 systemd 日志的优先级正确设置 level 字段。在这个版本中，level 字段会被正确设置。(LOG-3429)
  • 在此次更新之前，Operator 会错误地在 OpenShift Container Platform 4.12 或更高版本上生成不兼容警告。在这个版本中，Operator 最大 OpenShift Container Platform 版本值已被修正，从而解决了这个问题。(LOG-3584)
  • 在此次更新之前，创建一个带有 default 值的 ClusterLogForwarder 自定义资源(CR)不会生成任何错误。在这个版本中，这个值无效生成的错误警告。(LOG-3437)
  • 在此次更新之前，当 ClusterLogForwarder 自定义资源 (CR) 配置了多个管道时，会将一个输出设置为默认，收集器 Pod 会重启。在这个版本中，输出验证的逻辑已被修正，从而解决了这个问题。(LOG-3559)
  • 在此次更新之前，收集器 Pod 在创建后会重启。在这个版本中，部署的收集器不会自行重启。(LOG-3608)
  • 在此次更新之前，补丁版本会从目录中删除了 Operator 的早期版本。这使得无法安装旧版本。这个版本更改了捆绑包配置，以便以前的同一次版本的发行版本保留在目录中。(LOG-3635)
1.2.12.2. CVE

1.2.13. Logging 5.6.1

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

1.2.13.1. 程序错误修复
  • 在此次更新之前，紧凑器会在保留活跃时报告 TLS 证书错误与 querier 通信。在这个版本中，紧凑器和 querier 不再通过 HTTP 进行通信。(LOG-3494)
  • 在此次更新之前，Loki Operator 不会重试设置 LokiStack CR 的状态，这会导致过时的状态信息。在这个版本中，Operator 会重试冲突的状态信息更新。(LOG-3496)
  • 在此次更新之前，当 kube-apiserver-operator Operator 检查 Webhook 的有效性时，Loki Operator Webhook 服务器会导致 TLS 错误。在这个版本中，Loki Operator Webhook PKI 由 Operator Lifecycle Manager (OLM) 管理，从而解决了这个问题。(LOG-3510)
  • 在此次更新之前，LokiStack Gateway Labels Enforcer 会在使用带有布尔值表达式的组合标签过滤器时为有效的 LogQL 查询生成解析错误。在这个版本中，LokiStack LogQL 实现支持带有布尔值表达式的标签过滤器，并解决这个问题。(LOG-3441),(LOG-3397)
  • 在此次更新之前，如果多个标签键具有相同的前缀，一些键包含点，则写入 Elasticsearch 的记录将失败。在这个版本中，下划线替换标签键中的点，从而解决了这个问题。(LOG-3463)
  • 在此次更新之前，因为 OpenShift Container Platform 控制台和 logging-view-plugin 之间的不兼容，Red Hat OpenShift Logging Operator 不适用于 OpenShift Container Platform 4.10 集群。在这个版本中，插件可以与 OpenShift Container Platform 4.10 管理控制台正确集成。(LOG-3447)
  • 在此次更新之前，ClusterLogForwarder 自定义资源的协调会错误地报告引用默认日志存储的管道的降级状态。在这个版本中，管道会正确验证。(LOG-3477)
1.2.13.2. CVE

1.2.14. Logging 5.6.0

此版本包括 OpenShift Logging Release 5.6。

1.2.14.1. 弃用通知

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

1.2.14.2. 功能增强
  • 在这个版本中，日志记录与 OpenShift Container Platform 集群范围的加密策略兼容。(LOG-895)
  • 在这个版本中，您可以通过 LokiStack 自定义资源（按优先级排序）来为每个租户、每个流和全局策略保留策略声明。(LOG-2695)
  • 在这个版本中，Splun 是日志转发的可用输出选项。(LOG-2913)
  • 在这个版本中，Vector 替换了 Fluentd 作为默认的 Collector。(LOG-2222)
  • 在这个版本中，Developer 角色可以访问在运行 OpenShift Container Platform 4.11 及更高版本的集群中将其分配到的 Log Console Plugin 中的每个项目工作负载日志。(LOG-3388)

  • 在这个版本中，任何源的日志包含一个字段 openshift.cluster_id，它是部署 Operator 的集群的唯一标识符。您可以使用以下命令查看 clusterID 值： 

    $ oc get clusterversion/version -o jsonpath='{.spec.clusterID}{"\n"}'

    (LOG-2715)

1.2.14.3. 已知问题
  • 在此次更新之前，如果多个标签键具有相同的前缀，并且一些键包含 . 字符，则 Elasticsearch 将拒绝日志。这通过将标签键中的 . 替换为 _ 来解决 Elasticsearch 的限制。这个问题的一个临时解决方案是删除导致错误的标签，或向标签添加一个命名空间。(LOG-3463)
1.2.14.4. 程序错误修复
  • 在此次更新之前，如果您删除了 Kibana 自定义资源，OpenShift Container Platform Web 控制台将继续显示到 Kibana 的链接。在这个版本中，删除 Kibana 自定义资源也会删除该链接。(LOG-2993)
  • 在此次更新之前，用户无法查看其有权访问的命名空间的应用程序日志。在这个版本中，Loki Operator 会自动创建一个集群角色和集群角色绑定，允许用户读取应用程序日志。(LOG-3072)
  • 在此次更新之前，Operator 在使用 LokiStack 作为默认日志存储时删除了 ClusterLogForwarder 自定义资源中定义的任何自定义输出。在这个版本中，Operator 会在处理 ClusterLogForwarder 自定义资源时将自定义输出与默认输出合并。(LOG-3090)
  • 在此次更新之前，CA 密钥用作将 CA 挂载到 Loki 的卷名称，从而导致 CA Key 包含非格式字符（如点）时出现错误状态。在这个版本中，卷名称标准化为一个内部字符串，用于解决这个问题。(LOG-3331)
  • 在此次更新之前，在 LokiStack 自定义资源定义中设置的默认值，会导致无法创建 LokiStack 实例，而无需 ReplicationFactor 为 1。在这个版本中，Operator 为使用的大小设置实际值。(LOG-3296)
  • 在此次更新之前，当启用 JSON 解析时向量解析消息字段，而不定义 structuredTypeKey 或 structuredTypeName 值。在这个版本中，在将结构化日志写入 Elasticsearch 时，structuredTypeKey 或 structuredTypeName 所需的值。(LOG-3195)
  • 在此次更新之前，Elasticsearch Operator 的 secret 创建组件会持续修改的内部 secret。在这个版本中，现有 secret 会被正确处理。(LOG-3161)
  • 在此次更新之前，Operator 可以在 Elasticsearch 或 Kibana 部署改变状态时，输入删除和重新创建收集器 daemonset 的循环。在这个版本中，Operator 状态处理中会解决这个问题。(LOG-3157)
  • 在此次更新之前，Kibana 有一个固定的 24h OAuth cookie 过期时间，当 accessTokenInactivityTimeout 字段被设置为小于 24h 的值时，会导致 Kibana 中的 401 错误。在这个版本中，Kibana 的 OAuth cookie 过期时间与 accessTokenInactivityTimeout 同步，默认值为 24h。(LOG-3129)
  • 在此次更新之前，协调资源的 Operator 常规模式是在尝试获取或更新前尝试和创建，这会导致创建后持续的 HTTP 409 响应。在这个版本中，Operator 会首先尝试检索对象，仅在缺少或未指定对象时创建或更新它。(LOG-2919)
  • 在此次更新之前，Fluentd 中的 .level 和'.structure.level 字段可能包含不同的值。在这个版本中，每个字段的值都相同。(LOG-2819)
  • 在此次更新之前，Operator 不会等待可信 CA 捆绑包填充，并在更新捆绑包后再次部署收集器。在这个版本中，Operator 会在继续收集器部署前，等待简要查看捆绑包是否已填充。(LOG-2789)
  • 在此次更新之前，日志记录遥测信息在检查指标时会出现两次。在这个版本中，日志记录遥测信息会如预期显示。(LOG-2315)
  • 在此次更新之前，Fluentd pod 日志会在启用 JSON 解析添加后包含警告信息。在这个版本中，不会显示警告信息。(LOG-1806)
  • 在此次更新之前，must-gather 脚本无法完成，因为 oc 需要具有写入权限的文件夹来构建其缓存。在这个版本中，oc 对文件夹有写入权限，must-gather 脚本可以成功完成。(LOG-3446)
  • 在此次更新之前，日志收集器 SCC 可以替换为集群上的其他 SCC，从而导致收集器不可用。在这个版本中，设置日志收集器 SCC 的优先级，使其优先于其他 SCC。(LOG-3235)
  • 在此次更新之前，向量缺少字段 sequence，它被添加到 fluentd 中，作为处理缺少实际纳秒精度的方法。在这个版本中，字段 openshift.sequence 已添加到事件日志中。(LOG-3106)
1.2.14.5. CVE

1.3. Logging 5.5

注意

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

1.3.1. Logging 5.5.18

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

1.3.1.1. 程序错误修复

无。

1.3.1.2. CVE

1.3.2. Logging 5.5.17

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

1.3.2.1. 程序错误修复
  • 在此次更新之前，事件路由器中未使用的指标会导致容器因为过量内存用量而失败。在这个版本中，通过删除未使用的指标来减少事件路由器的内存用量。(LOG-4688)
1.3.2.2. CVE

1.3.3. Logging 5.5.16

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

1.3.3.1. 程序错误修复
  • 在此次更新之前，LokiStack 网关会广泛缓存授权请求。因此，这会导致错误的授权结果。在这个版本中，Loki 网关缓存以更精细的方式缓存来解决这个问题。(LOG-4434)
1.3.3.2. CVE

1.3.4. Logging 5.5.14

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

1.3.4.1. 程序错误修复
  • 在此次更新之前，向量收集器偶尔会在日志中出现以下错误信息：thread 'vector-worker' panicked at 'all branch are disabled, no else branch', src/kubernetes/reflector.rs:26:9。在这个版本中，在 Vector 收集器中不会显示这个错误。(LOG-4279)
1.3.4.2. CVE

1.3.5. Logging 5.5.13

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

1.3.5.1. 程序错误修复

无。

1.3.5.2. CVE

1.3.6. Logging 5.5.11

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

1.3.6.1. 程序错误修复
  • 在此次更新之前，无法通过点击并在日志直方图上拖动，在 OpenShift Container Platform Web 控制台中选择时间范围。在这个版本中，可以使用单击和拖动来成功选择时间范围。(LOG-4102)
  • 在此次更新之前，点 OpenShift Container Platform Web 控制台中的 Show Resources 链接不会产生任何影响。在这个版本中，通过修复 Show Resources 链接的功能来解决这个问题，以切换每个日志条目的资源显示。(LOG-4117)
1.3.6.2. CVE

1.3.7. Logging 5.5.10

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

1.3.7.1. 程序错误修复
  • 在此次更新之前，OpenShift Web 控制台的日志记录视图插件在 LokiStack 无法访问时只显示一个错误文本。在这个版本中，插件会显示正确的错误消息，其中包含如何修复不可访问 LokiStack 的详细信息。(LOG-2874)
1.3.7.2. CVE

1.3.8. Logging 5.5.9

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

1.3.8.1. 程序错误修复
  • 在此次更新之前，Fluentd 收集器的问题会导致它不会捕获存储在 /var/log/auth-server/audit.log 中的 OAuth 登录事件。这会导致 OAuth 服务中的登录事件集合不完整。在这个版本中，Fluentd 收集器通过从 OAuth 服务捕获所有登录事件来解决这个问题，包括存储在 /var/log/auth-server/audit.log 中的登录事件。(LOG-3730)
  • 在此次更新之前，当启用结构化解析且消息转发到多个目的地时，它们不会被深度复制。这会导致一些接收的日志，包括结构化消息，而其他日志则没有。在这个版本中，在 JSON 解析前，配置生成已被修改为深度复制信息。因此，所有收到的日志现在都包含结构化消息，即使它们被转发到多个目的地。(LOG-3767)
1.3.8.2. CVE

1.3.9. Logging 5.5.8

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

1.3.9.1. 程序错误修复
  • 在此次更新之前，systemd 日志中缺少 priority 字段，因为收集器如何设置 level 字段出错。在这个版本中，这些字段会被正确设置，从而解决了这个问题。(LOG-3630)
1.3.9.2. CVE

1.3.10. Logging 5.5.7

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

1.3.10.1. 程序错误修复
  • 在此次更新之前，LokiStack Gateway Labels Enforcer 会在使用带有布尔值表达式的组合标签过滤器时为有效的 LogQL 查询生成解析错误。在这个版本中，LokiStack LogQL 实现支持带有布尔值表达式的标签过滤器，并解决这个问题。(LOG-3534)
  • 在此次更新之前，ClusterLogForwarder 自定义资源(CR)不会将 syslog 输出的 TLS 凭证传递给 Fluentd，从而导致转发过程中出现错误。在这个版本中，凭证可以正确地传递给 Fluentd，从而解决了这个问题。(LOG-3533)
1.3.10.2. CVE

CVE-2021-46848CVE-2022-3821CVE-2022-35737CVE-2022-42010CVE-2022-42011CVE-2022-42012CVE-2022-42898CVE-2022-43680

1.3.11. Logging 5.5.6

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

1.3.11.1. 程序错误修复
  • 在此次更新之前，Pod 安全准入控制器会将标签 podSecurityLabelSync = true 添加到 openshift-logging 命名空间中。这会导致我们指定的安全标签被覆盖，因此 Collector pod 不会启动。在这个版本中，标签 podSecurityLabelSync = false 可保留安全标签。收集器 Pod 按预期部署。(LOG-3340)
  • 在此次更新之前，Operator 会安装 console 视图插件，即使在集群中没有启用它。这会导致 Operator 崩溃。在这个版本中，如果集群的帐户没有启用 console 视图，Operator 会正常运行，且不会安装 console 视图。(LOG-3407)
  • 在此次更新之前，以前的一个用于支持部署没有被更新时进行回归的修复会导致 Operator 崩溃，除非部署了 Red Hat Elasticsearch Operator。在这个版本中，这个问题已被恢复，Operator 现在会稳定，但重新引入了以前的与报告状态相关的问题。(LOG-3428)
  • 在此次更新之前，Loki Operator 只部署 LokiStack 网关的一个副本，而不考虑所选的堆栈大小。在这个版本中，根据所选大小正确配置副本数。(LOG-3478)
  • 在此次更新之前，如果多个标签键具有相同的前缀，一些键包含点，则写入 Elasticsearch 的记录将失败。在这个版本中，下划线替换标签键中的点，从而解决了这个问题。(LOG-3341)
  • 在此次更新之前，日志记录视图插件包含与特定版本的 OpenShift Container Platform 不兼容的功能。在这个版本中，插件的正确发行版本流可以解决这个问题。(LOG-3467)
  • 在此次更新之前，ClusterLogForwarder 自定义资源的协调会错误地报告一个或多个管道的降级状态，从而导致收集器 pod 每 8-10 秒重启。在这个版本中，ClusterLogForwarder 自定义资源进程的协调可以正确地解决这个问题。(LOG-3469)
  • 在此更改 ClusterLogForwarder 自定义资源的 outputDefaults 字段的 spec 之前，会将设置应用到每个声明的 Elasticsearch 输出类型。这会变化可以更正行为，使其与设置专门用于默认受管 Elasticsearch 存储的增强规格匹配。(LOG-3342)
  • 在此次更新之前，OpenShift CLI (oc) must-gather 脚本没有完成，因为 OpenShift CLI (oc)需要一个具有写入权限来构建其缓存的文件夹。在这个版本中，OpenShift CLI (oc) 对文件夹有写入权限，must-gather 脚本可以成功完成。(LOG-3472)
  • 在此次更新之前，Loki Operator Webhook 服务器会导致 TLS 错误。在这个版本中，Loki Operator Webhook PKI 由 Operator Lifecycle Manager 的动态 webhook 管理来管理，从而解决了这个问题。(LOG-3511)
1.3.11.2. CVE

1.3.12. Logging 5.5.5

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

1.3.12.1. 程序错误修复
  • 在此次更新之前，Kibana 有一个固定的 24h OAuth cookie 过期时间，当 accessTokenInactivityTimeout 字段被设置为小于 24h 的值时，会导致 Kibana 中的 401 错误。在这个版本中，Kibana 的 OAuth cookie 过期时间与 accessTokenInactivityTimeout 同步，默认值为 24h。(LOG-3305)
  • 在此次更新之前，当启用 JSON 解析时向量解析消息字段，而不定义 structuredTypeKey 或 structuredTypeName 值。在这个版本中，在将结构化日志写入 Elasticsearch 时，structuredTypeKey 或 structuredTypeName 所需的值。(LOG-3284)
  • 在此次更新之前，当出现从此警报表达式返回的一组标签时，FluentdQueueLengthIncreasing 警报可能无法触发。在这个版本中，减少了标签，使其只包含警报所需的标签。(LOG-3226)
  • 在此次更新之前，Loki 不支持连接到断开连接的集群中的外部存储。在这个版本中，容器镜像中包含代理环境变量和代理可信 CA 捆绑包来支持这些连接。(LOG-2860)
  • 在此次更新之前，OpenShift Container Platform Web 控制台用户无法选择包含 Loki 的 CA 证书的 ConfigMap 对象，从而导致 pod 在没有 CA 的情况下运行。在这个版本中，Web 控制台用户可以选择配置映射，从而解决了这个问题。(LOG-3310)
  • 在此次更新之前，CA 密钥用作将 CA 挂载到 Loki 中的卷名称，从而导致 CA 密钥包含非格式字符（如点）时出现错误状态。在这个版本中，卷名称标准化为一个内部字符串，用于解决这个问题。(LOG-3332)
1.3.12.2. CVE

1.3.13. 日志记录 5.5.4

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

1.3.13.1. 程序错误修复
  • 在此次更新之前，日志记录视图插件的查询解析程序中的错误会导致日志查询的部分部分（如果查询包含大括号 {} ）消失。这会导致查询无效，从而导致为有效查询返回错误。在这个版本中，解析器可以正确地处理这些查询。(LOG-3042)
  • 在此次更新之前，Operator 可以在 Elasticsearch 或 Kibana 部署改变状态时，输入删除和重新创建收集器 daemonset 的循环。在这个版本中，Operator 状态处理中会解决这个问题。(LOG-3049)
  • 在此次更新之前，不会实施警报来支持 Vector 的收集器实现。这个更改会添加 Vector 警报并部署单独的警报，具体取决于所选收集器的实现。(LOG-3127)
  • 在此次更新之前，Elasticsearch Operator 的 secret 创建组件会持续修改的内部 secret。在这个版本中，现有 secret 会被正确处理。(LOG-3138)
  • 在此次更新之前，日志 must-gather 脚本的前重构删除了工件的预期位置。在这个版本中，恢复将工件写入 /must-gather 文件夹的更改。(LOG-3213)
  • 在此次更新之前，在某些集群中，Prometheus exporter 会使用 IPv4 上而不是 IPv6。在这个版本中，Fluentd 会检测 IP 版本，并使用 0.0.0.0 (IPv4) 或 [::] 用于 IPv6。(LOG-3162)
1.3.13.2. CVE

1.3.14. 日志记录 5.5.3

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

1.3.14.1. 程序错误修复
  • 在此次更新之前，带有结构化消息的日志条目包含原始消息字段，该字段使条目更大。在这个版本中，删除了结构化日志的 message 字段，以减少增大的大小。(LOG-2759)
  • 在此次更新之前，收集器配置排除了来自 收集器、default-log-store 和 visualization pod 的日志，但无法在 .gz 文件中排除存档的日志。在这个版本中，作为 collector, default-log-store, 和 visualization pod 的 .gz 存储的归档日志也会被排除。(LOG-2844)
  • 在此次更新之前，当请求通过网关发送对不可用 pod 的请求时，不会警告中断。在这个版本中，如果网关在完成写入或读取请求时遇到问题，则单个警报将生成。(LOG-2884)
  • 在此次更新之前，pod 元数据可以被流畅的插件更改，因为通过管道传递的值通过引用。此更新可确保每个日志消息接收 pod 元数据的副本，以便每个消息进程都可以独立使用。(LOG-3046)
  • 在此次更新之前，在 OpenShift Console Logs 视图中选择 unknown severity 排除了 level=unknown 值的日志。在这个版本中，根据未知严重性进行过滤时，可以查看没有级别以及带有 level=unknown 的日志。(LOG-3062)
  • 在此次更新之前，发送到 Elasticsearch 的日志记录有一个名为 write-index 的额外字段，其中包含发送日志所需的索引名称。此字段不是数据模型的一部分。在这个版本中，这个字段将不再发送。(LOG-3075)
  • 随着新的内置 Pod Security Admission Controller 的推出，根据全局或命名空间级别定义的强制安全标准没有配置 Pod。在这个版本中，Operator 和收集器允许特权执行并运行，而不出现安全审计警告或错误。(LOG-3077)
  • 在此次更新之前，Operator 在使用 LokiStack 作为默认日志存储时删除了 ClusterLogForwarder 自定义资源中定义的任何自定义输出。在这个版本中，Operator 会在处理 ClusterLogForwarder 自定义资源时将自定义输出与默认输出合并。(LOG-3095)
1.3.14.2. CVE

1.3.15. 日志记录 5.5.2

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

1.3.15.1. 程序错误修复
  • 在此次更新之前，Fluentd 收集器的警报规则不遵循 OpenShift Container Platform 监控风格的准则。此更新会修改这些警报，使其包含命名空间标签，从而解决了这个问题。(LOG-1823)
  • 在此次更新之前，索引管理滚动脚本会在索引名称中有多个连字符时生成新的索引名称。在这个版本中，索引名称会正确生成。(LOG-2644)
  • 在此次更新之前，Kibana 路由会在没有证书的情况下设置 caCertificate 值。在这个版本中，不会设置 caCertificate 值。(LOG-2661)
  • 在此次更新之前，收集器依赖项的更改会导致它为未使用的参数发出警告消息。在这个版本中，删除未使用的配置参数可以解决这个问题。(LOG-2859)
  • 在此次更新之前，为 Loki Operator 创建的部署创建的 pod 被错误地调度到没有 Linux 操作系统的节点（如果这些节点已在运行 Operator 的集群中可用）。在这个版本中，Operator 将额外的 node-selector 附加到 pod 定义，该定义仅允许将 pod 调度到基于 Linux 的节点上。(LOG-2895)
  • 在此次更新之前，OpenShift 控制台日志视图不会根据严重性过滤日志，因为 LokiStack 网关中存在 LogQL 解析器问题。在这个版本中，解析器修复了这个问题，OpenShift Console Logs 视图可以根据严重性进行过滤。(LOG-2908)
  • 在此次更新之前，重构 Fluentd 收集器插件会删除事件的时间戳字段。在这个版本中，恢复从事件收到的时间提供的 timestamp 字段。(LOG-2923)
  • 在此次更新之前，审计日志中没有 level 字段会导致向量日志出现错误。在这个版本中，在审计日志记录中添加 level 字段可以解决这个问题。(LOG-2961)
  • 在此次更新之前，如果您删除了 Kibana 自定义资源，OpenShift Container Platform Web 控制台将继续显示到 Kibana 的链接。在这个版本中，删除 Kibana 自定义资源也会删除该链接。(LOG-3053)
  • 在此次更新之前，当 ClusterLogForwarder 自定义资源定义了 JSON 解析时，每个 rollover 任务都会创建空索引。在这个版本中，新的索引不为空。(LOG-3063)
  • 在此次更新之前，当用户在 Loki Operator 5.5 更新后删除了 LokiStack 时，最初由 Loki Operator 5.4 创建的资源仍保留。在这个版本中，资源的 owner-references 指向 5.5 LokiStack。(LOG-2945)
  • 在此次更新之前，用户无法查看其有权访问的命名空间的应用程序日志。在这个版本中，Loki Operator 会自动创建一个集群角色和集群角色绑定，允许用户读取应用程序日志。(LOG-2918)
  • 在此次更新之前，具有 cluster-admin 特权的用户无法使用日志记录控制台正确查看基础架构和审计日志。在这个版本中，授权检查已被扩展，还可将 cluster-admin 和 dedicated-admin 组中的用户识别为 admins。(LOG-2970)
1.3.15.2. CVE

1.3.16. Logging 5.5.1

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

1.3.16.1. 功能增强
  • 当日志记录控制台（Logging Console）插件被使用时，此增强会将 Aggregated Logs 选项卡添加到 OpenShift Container Platform Web 控制台的 Pod Details 页面中。此功能增强仅适用于 OpenShift Container Platform 4.10 及更新的版本。(LOG-2647)
  • 此功能增强将 Google Cloud Logging 添加为日志转发的输出选项。(LOG-1482)
1.3.16.2. 程序错误修复
  • 在此次更新之前，Operator 无法确保 pod 就绪，这会导致集群在集群重启过程中达到可操作的状态。在这个版本中，Operator 会在重启过程中进入新 pod 前将新 pod 标记为 ready，这会解决这个问题。(LOG-2745)
  • 在此次更新之前，Fluentd 有时无法识别 Kubernetes 平台轮转日志文件，且不会读取日志消息。在这个版本中，通过设置上游开发团队所推荐的配置参数修正。(LOG-2995)
  • 在此次更新之前，添加多行错误检测会导致内部路由更改并将记录转发到错误的目的地。在这个版本中，内部路由正确。(LOG-2801)
  • 在此次更新之前，更改 OpenShift Container Platform Web 控制台的刷新间隔会在 Query 字段为空时造成错误。在这个版本中，当 Query 字段为空时，更改间隔不是可用的选项。(LOG-2917)
1.3.16.3. CVE

1.3.17. Logging 5.5.0

此发行版本包括：OpenShift Logging 程序错误修复 5.5.0。

1.3.17.1. 功能增强
  • 在这个版本中，您可以将来自同一 pod 的不同容器的结构化日志转发到不同的索引。要使用此功能，您必须使用多容器支持配置管道并注解 pod。(LOG-1296)
重要

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

  • 在这个版本中，您可以使用 Kubernetes 的普通标签，app.kubernetes.io/component, app.kubernetes.io/managed-by, app.kubernetes.io/part-of, 和 app.kubernetes.io/version 来过滤 Elasticsearch 输出的日志。非 Elasticsearch 输出类型可以使用 kubernetes.labels 中包含的所有标签。(LOG-2388)
  • 在这个版本中，启用了 AWS Security Token Service (STS) 的集群可能会使用 STS 验证将日志转发到 Amazon CloudWatch。(LOG-1976)
  • 在这个版本中，Loki Operator 和 Vector 收集器从技术预览变为正式发行 (GA)。与之前版本相关的全部仍处于会待处理的状态，一些 API 仍为技术预览。详情请参阅 带有 LokiStack 的日志记录部分。
1.3.17.2. 程序错误修复
  • 在此次更新之前，配置为将日志转发到 Amazon CloudWatch 的集群会将拒绝的日志文件写入到临时存储，从而导致集群变得不稳定。在这个版本中，所有存储选项的块备份已被禁用，从而解决了这个问题。(LOG-2746)
  • 在此次更新之前，Operator 使用的一些 API 的版本已弃用，并计划在以后的 OpenShift Container Platform 版本中删除。在这个版本中，依赖项被移到受支持的 API 版本。(LOG-2656)
  • 在此次更新之前，为多行错误检测配置了多个 ClusterLogForwarder 管道，会导致收集器进入 crashloopbackoff 错误状态。在这个版本中解决了这个问题，多个配置部分具有相同的唯一 ID。(LOG-2241)
  • 在此次更新之前，收集器无法将非 UTF-8 符号保存到 Elasticsearch 存储日志中。在这个版本中，收集器对非 UTF-8 符号进行编码，从而解决此问题。(LOG-2203)
  • 在此次更新之前，非拉丁字符在 Kibana 中无法正确显示。在这个版本中，Kibana 可以正确地显示所有有效的 UTF-8 字符。(LOG-2784)
1.3.17.3. CVE

1.4. Logging 5.4

注意

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

1.4.1. Logging 5.4.14

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

1.4.1.1. 程序错误修复

无。

1.4.1.2. CVE

1.4.2. Logging 5.4.13

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

1.4.2.1. 程序错误修复
  • 在此次更新之前，Fluentd 收集器的问题会导致它不会捕获存储在 /var/log/auth-server/audit.log 中的 OAuth 登录事件。这会导致 OAuth 服务中的登录事件集合不完整。在这个版本中，Fluentd 收集器通过从 OAuth 服务捕获所有登录事件来解决这个问题，包括存储在 /var/log/auth-server/audit.log 中的登录事件。(LOG-3731)
1.4.2.2. CVE

1.4.3. Logging 5.4.12

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

1.4.3.1. 程序错误修复

无。

1.4.3.2. CVE

1.4.4. Logging 5.4.11

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

1.4.4.1. 程序错误修复
1.4.4.2. CVE

1.4.5. Logging 5.4.10

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

1.4.5.1. 程序错误修复

无。

1.4.5.2. CVE

1.4.6. 日志记录 5.4.9

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

1.4.6.1. 程序错误修复
  • 在此次更新之前，Fluentd 收集器会警告未使用的配置参数。在这个版本中，删除了这些配置参数及其警告信息。(LOG-3074)
  • 在此次更新之前，Kibana 有一个固定的 24h OAuth cookie 过期时间，当 accessTokenInactivityTimeout 字段被设置为小于 24h 的值时，会导致 Kibana 中的 401 错误。在这个版本中，Kibana 的 OAuth cookie 过期时间与 accessTokenInactivityTimeout 同步，默认值为 24h。(LOG-3306)
1.4.6.2. CVE

1.4.7. 日志记录 5.4.8

此发行版本包括 RHSA-2022:7435-OpenShift Logging 程序错误修复 5.4.8。

1.4.7.1. 程序错误修复

无。

1.4.7.2. CVE

1.4.8. 日志记录 5.4.6

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

1.4.8.1. 程序错误修复
  • 在此次更新之前，Fluentd 有时无法识别 Kubernetes 平台轮转日志文件，且不会读取日志消息。在这个版本中，通过设置上游开发团队所推荐的配置参数修正。(LOG-2792)
  • 在此次更新之前，当 ClusterLogForwarder 自定义资源定义了 JSON 解析时，每个 rollover 任务都会创建空索引。在这个版本中，新的索引不为空。(LOG-2823)
  • 在此次更新之前，如果您删除了 Kibana 自定义资源，OpenShift Container Platform Web 控制台将继续显示到 Kibana 的链接。在这个版本中，删除 Kibana 自定义资源也会删除该链接。(LOG-3054)
1.4.8.2. CVE

1.4.9. 日志记录 5.4.5

此发行版本包括 RHSA-2022:6183-OpenShift Logging Bug Fix 5.4.5。

1.4.9.1. 程序错误修复
  • 在此次更新之前，Operator 无法确保 pod 就绪，这会导致集群在集群重启过程中达到可操作的状态。在这个版本中，Operator 会在重启过程中进入新 pod 前将新 pod 标记为 ready，这会解决这个问题。(LOG-2881)
  • 在此次更新之前，添加多行错误检测会导致内部路由更改并将记录转发到错误的目的地。在这个版本中，内部路由正确。(LOG-2946)
  • 在此次更新之前，Operator 无法使用带引号的布尔值值解码索引设置 JSON 响应，并导致错误。在这个版本中，Operator 可以正确解码这个 JSON 响应。(LOG-3009)
  • 在此次更新之前，Elasticsearch 索引模板定义了带有错误类型的标签的字段。这会更新这些模板以匹配日志收集器所转发的预期类型。(LOG-2972)
1.4.9.2. CVE

1.4.10. Logging 5.4.4

此发行版本包括 RHBA-2022:5907-OpenShift Logging Bug Fix 5.4.4。

1.4.10.1. 程序错误修复
  • 在此次更新之前，非拉丁字符在 Elasticsearch 中无法正确显示。在这个版本中，Elasticsearch 可以正确显示所有有效的 UTF-8 符号。(LOG-2794)
  • 在此次更新之前，非拉丁字符在 Fluentd 中无法正确显示。在这个版本中，Fluentd 可以正确地显示所有有效的 UTF-8 字符。(LOG-2657)
  • 在此次更新之前，收集器的指标服务器尝试使用通过环境值公开的值绑定到地址。在这个更改中，将配置修改为绑定到任何可用接口。(LOG-2821)
  • 在此次更新之前，cluster-logging Operator 依赖于集群来创建 secret。OpenShift Container Platform 4.11 中更改了集群行为，这会导致日志记录部署失败。在这个版本中，cluster-logging Operator 会根据需要创建 secret 来解决这个问题。(LOG-2840)
1.4.10.2. CVE

1.4.11. Logging 5.4.3

此发行版本包括 RHSA-2022:5556-OpenShift Logging Bug Fix 5.4.3。

1.4.11.1. Elasticsearch Operator 弃用通知

在日志记录 5.4.3 中，Elasticsearch Operator 已被弃用，计划在以后的发行版本中删除。红帽将在当前发行生命周期中提供对这个功能的程序漏洞修复和支持，但这个功能将不再获得改进，并将被删除。作为使用 Elasticsearch Operator 管理默认日志存储的替代选择，您可以使用 Loki Operator。

1.4.11.2. 程序错误修复
  • 在此次更新之前，OpenShift Logging 仪表板会显示活跃主分片的数量，而不是所有活跃分片。在这个版本中，仪表板显示所有活跃分片。(LOG-2781)
  • 在此次更新之前，elasticsearch-operator 使用的库中的有一个程序错误，它包含一个拒绝服务攻击的安全漏洞。在这个版本中，库已更新至不包含此漏洞的版本。(LOG-2816)
  • 在此次更新之前，当将 Vector 配置为将日志转发到 Loki 时，无法设置自定义 bearer 令牌，如果 Loki 启用了 TLS，则无法使用默认的令牌。在这个版本中，Vector 可以使用启用了 TLS 的令牌将日志转发到 Loki。(LOG-2786
  • 在此次更新之前，Elasticure Operator 在选择 oauth-proxy 镜像时省略 ImageStream 自定义资源的 referencePolicy 属性。这导致 Kibana 部署在特定环境中失败。在这个版本中，使用 referencePolicy 解决了这个问题，Operator 可以成功部署 Kibana。(LOG-2791)
  • 在此次更新之前，ClusterLogForwarder 自定义资源的警报规则不会考虑多个转发输出。这个版本解决了这个问题。(LOG-2640)
  • 在此次更新之前，配置为将日志转发到 Amazon CloudWatch 的集群会将拒绝的日志文件写入到临时存储，从而导致集群变得不稳定。在这个版本中，CloudWatch 的块备份已被禁用，从而解决了这个问题。(LOG-2768)
1.4.11.3. CVE

1.4.12. Logging 5.4.2

此发行版本包括 RHBA-2022:4874-OpenShift Logging Bug Fix 5.4.2

1.4.12.1. 程序错误修复
  • 在此次更新之前，使用 oc edit 编辑 Collector 配置非常困难，因为它对空格的使用不一致。这个更改引入了在 Operator 更新前对配置进行规范化和格式化的逻辑，以便使用 oc edit 轻松编辑配置。(LOG-2319)
  • 在此次更新之前，FluentdNodeDown 警报无法正确在 message 部分中提供实例标签。在这个版本中，通过修复警报规则来在部分实例失败时提供实例标签，从而解决了这个问题。(LOG-2607)
  • 在此次更新之前，在文档中声明支持的几个日志级别（如`critical`）实际并不支持。在这个版本中，相关的日志级别已被支持。(LOG-2033)
1.4.12.2. CVE

1.4.13. Logging 5.4.1

此发行版本包括 RHSA-2022:2216-OpenShift Logging 程序错误修复 5.4.1。

1.4.13.1. 程序错误修复
  • 在此次更新之前，日志文件指标 exporter 仅报告在导出器运行期间创建的日志，从而造成日志增长数据不准确。此次更新通过监控 /var/log/pods 解决了这个问题。(LOG-2442)
  • 在此次更新之前，收集器会被阻断，因为它在将日志转发到 fluentd 转发接收器时不断尝试使用过时的连接。在这个版本中，keepalive_timeout 值被设置为 30 秒(30s)，以便收集器回收连接并重新尝试在合理的时间内发送失败消息。(LOG-2534)
  • 在此次更新之前，网关组件强制租期中的错误，用于读取带有 Kubernetes 命名空间的日志的有限访问会导致 "audit" 以及一些 "infrastructure" 日志不可读取。在这个版本中，代理可以正确地检测到具有 admin 访问权限的用户，并允许在没有命名空间的情况下访问日志。(LOG-2448)
  • 在此次更新之前，system:serviceaccount:openshift-monitoring:prometheus-k8s 服务帐户将集群级别权限作为 clusterrole 和 clusterrolebinding。在这个版本中，服务帐户使用角色和 rolebinding 限制到 openshift-logging 命名空间。(LOG-2437)
  • 在此次更新之前，Linux 审计日志时间解析依赖于键/值对的正序位置。此更新会将解析更改为使用正则表达式来查找时间条目。(LOG-2321)
1.4.13.2. CVE

1.4.14. Logging 5.4

以下公告可用于日志记录 5.4 ：{logging-title-uc} 版本 5.4

1.4.14.1. 技术预览

OpenShift Container Platform 中提供了以下功能。

1.4.14.1.1. Vector 收集器

Vector 是一个日志收集器，作为日志记录的当前默认收集器的技术预览替代。

Vector 收集器支持以下输出：

  • elasticsearch.一个外部 Elasticsearch 实例。elasticsearch 输出可以使用 TLS 连接。
  • kafka.Kafka 代理。kafka 输出可以使用不安全的或 TLS 连接。
  • loki。Loki，一个可横向扩展的、高可用性、多租户日志聚合系统。
重要

向量不支持 FIPS 启用集群。

默认不启用向量。要在 OpenShift Container Platform 集群上启用向量，您必须将 logging.openshift.io/preview-vector-collector: enabled 注解添加到 ClusterLogging 自定义资源(CR)中，并将 vector 添加为集合类型：

ClusterLogging CR 示例

  apiVersion: "logging.openshift.io/v1"
  kind: "ClusterLogging"
  metadata:
    name: "instance"
    namespace: "openshift-logging"
    annotations:
      logging.openshift.io/preview-vector-collector: enabled
  spec:
    collection:
      logs:
        type: "vector"
        vector: {}

1.4.14.1.2. Loki 日志存储

Loki 是一个可横向扩展的、高度可用且多租户的日志聚合系统，目前作为日志记录的日志存储提供。有关安装 Loki 的更多信息，请参阅 "Logging using LokiStack" 文档。

1.4.14.2. 程序错误修复
  • 在此次更新之前，cluster-logging-operator 使用集群范围的角色和绑定来建立 Prometheus 服务帐户的权限，以提取指标。这些权限在使用控制台界面部署 Operator 时创建，但在从命令行部署时缺失。在这个版本中，通过使角色和绑定命名空间范围解决了这个问题。(LOG-2286)
  • 在此次更新之前，修复仪表板协调在命名空间间引入一个 ownerReferences 字段。因此，在命名空间中不会创建配置映射和仪表板。在这个版本中，删除了 ownerReferences 字段可以解决这个问题，OpenShift Logging 仪表板在控制台中可用。(LOG-2163)
  • 在此次更新之前，对指标仪表板的更改不会部署，因为 cluster-logging-operator 无法正确比较包含仪表板的现有和修改后的配置映射。在这个版本中，为对象标签添加唯一的散列值可解决这个问题。(LOG-2071)
  • 在此次更新之前，OpenShift Logging 仪表板没有正确显示表中的 pod 和命名空间，这会显示在最后 24 小时收集的生成容器。在这个版本中，pod 和命名空间会被正确显示。(LOG-2069)
  • 在此次更新之前，当 ClusterLogForwarder 设置为 Elasticsearch OutputDefault 且 Elasticsearch 输出没有结构化键时，生成的配置包含身份验证的错误值。在这个版本中，修正了使用的 secret 和证书。(LOG-2056)
  • 在此次更新之前，OpenShift Logging 仪表板会显示一个空的 CPU 图形，因为引用无效指标。在这个版本中，选择了正确的数据点来解决此问题。(LOG-2026)
  • 在此次更新之前，Fluentd 容器镜像包含在运行时不需要的构建程序工具。这个版本从镜像中删除这些工具。(LOG-1927)
  • 在此次更新之前，在 5.3 版本中部署的收集器的名称更改会导致日志记录收集器生成 FluentdNodeDown 警报。在这个版本中，修复 Prometheus 警报的作业名称解决了这个问题。(LOG-1918)
  • 在此次更新之前，日志收集器因为重构组件名称更改而收集自己的日志。这可能会导致收集器处理自己的日志的潜在反馈循环，这可能会导致内存和日志消息大小问题。在这个版本中解决了这个问题，它会从集合中排除收集器日志。(LOG-1774)
  • 在此次更新之前，Elasticsearch 会生成错误 Unable to create PersistentVolumeClaim due to forbidden: exceeded quota: infra-storage-quota.（如果 PVC 已存在）。在这个版本中，Elasticsearch 会检查现有的 PVC，从而解决了这个问题。(LOG-2131)
  • 在此次更新之前，当 elasticsearch-signing secret 被删除时，Elasticsearch 无法返回 ready 状态。在这个版本中，Elasticsearch 能够在删除该 secret 后返回 ready 状态。(LOG-2171)
  • 在此次更新之前，收集器读取容器日志的路径的更改会导致收集器将一些记录转发到错误的索引。在这个版本中，收集器使用正确的配置来解决这个问题。(LOG-2160)
  • 在此次更新之前，带有大量命名空间的集群会导致 Elasticsearch 停止服务请求，因为命名空间列表达到最大标头大小限制。在这个版本中，标头只包括命名空间名称列表，从而解决了这个问题。(LOG-1899)
  • 在此次更新之前，OpenShift Container Platform Logging 仪表板显示分片"x"数量大于 Elasticsearch 具有 'x' 节点时的实际值。出现这个问题的原因是，它会输出每个 Elasticsearch pod 的所有主分片，并计算出整个 Elasticsearch 集群的总和。在这个版本中，分片数量会被正确计算。(LOG-2156)
  • 在此次更新之前，如果 secret kibana 和 kibana-proxy 被删除，则不会重新创建它们。在这个版本中，elasticsearch-operator 会监视资源，并在删除时自动重新创建这些资源。(LOG-2250)
  • 在此次更新之前，调整缓冲区块大小可能会导致收集器生成超过事件流字节限制的块大小警告。在这个版本中，您还可以调整读行限制，并解决问题。(LOG-2379)
  • 在此次更新之前，OpenShift WebConsole 中的日志记录控制台链接不会被 ClusterLogging CR 删除。在这个版本中，删除 CR 或卸载 Cluster Logging Operator 会删除链接。(LOG-2373)
  • 在此次更新之前，对容器日志路径的更改会导致集合指标始终为零，且使用原始路径配置旧版本。在这个版本中，插件会公开有关收集日志的指标，支持从任一路径中读取来解决这个问题。(LOG-2462)
1.4.14.3. 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. 不支持的配置

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

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

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

明确不支持的情形包括：

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

2.2. 非受管 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.3. 为红帽支持收集日志记录数据

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

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

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

注意

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

2.3.1. 关于 must-gather 工具

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

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

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

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

2.3.2. 收集 OpenShift Logging 数据

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

流程

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

  1. 进入要存储 must-gather 信息的目录。

  2. 针对 OpenShift Logging 镜像运行 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 集群健康状态 green、yellow 或 red。
    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 中的 ingestionBurstSize 和 ingestionRate 字段： 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 16 1
        ingestionRate: 8 2
# ...
    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，列在 failed、notReady 或 ready 状态下。
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

reason 和 type 类型字段指定不受支持的更改类型：

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-cert、admin-key、logging-es.crt 或 logging-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 日志存储，或将日志转发到额外的外部日志存储。

注意

OpenShift Elasticsearch Operator 已被弃用，计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持，但此功能将不再获得改进。您可以使用 Loki Operator 作为 OpenShift Elasticsearch Operator 的替代方案来管理默认日志存储。

视觉化

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

注意

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

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

应用程序日志
由集群中运行的用户应用程序生成的容器日志（基础架构容器应用程序除外）。
基础架构日志
由基础架构命名空间生成的容器日志： openshift*、kube* 或 default，以及来自节点的 journald 信息。
审计日志
由 auditd 生成的日志，节点审计系统存储在 /var/log/audit/audit.log 文件中，以及 auditd、kube-apiserver、openshift-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 控制台中，点击 Operators → OperatorHub。
  2. 在 Filter by keyword 框中键入 OpenShift Logging。
  3. 从可用的 Operator 列表中选择 Red Hat OpenShift Logging，然后点 Install。
  4. 确定在 Installation mode 下选择了 A specific namespace on the cluster。
  5. 确定在 Installed Namespace 下的 Operator recommended namespace 是 openshift-logging。

  6. 选择 Enable operator recommended cluster monitoring on this namespace。

    这个选项在 Namespace 对象中设置 openshift.io/cluster-monitoring: "true" 标签。您必须选择这个选项，以确保集群监控提取 openshift-logging 命名空间。

  7. 选择 stable-5.y 作为 更新频道。

    注意

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

  8. 选择一个 Update approval。

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

验证

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

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

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

  • 进入 Operators → Installed Operators 页面，检查 Status 列中是否有任何错误或故障。
  • 进入 Workloads → Pods 页面，检查 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 部分中，选择一个类型。

    注意

    OpenShift Elasticsearch Operator 已被弃用，计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持，但此功能将不再获得改进。您可以使用 Loki Operator 作为 OpenShift Elasticsearch 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: openshift-operators-redhat 1
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true" 2

    1
    您必须指定 openshift-operators-redhat 命名空间。为了防止可能与指标（metrics）冲突，您应该将 Prometheus Cluster Monitoring 堆栈配置为从 openshift-operators-redhat 命名空间中提取指标数据，而不是从 openshift-operators 命名空间中提取。openshift-operators 命名空间可能包含社区 Operator，这些 Operator 不被信任，并可能会发布与 OpenShift Container Platform 指标相同的名称，从而导致冲突。
    2
    字符串.您必须按照所示指定该标签，以确保集群监控提取 openshift-operators-redhat 命名空间。

  2. 运行以下命令来应用 Namespace 对象： 

    $ oc apply -f <filename>.yaml

  3. 为 Red Hat OpenShift Logging Operator 创建一个 Namespace 对象：

    Namespace 对象示例

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

  4. 运行以下命令来应用 Namespace 对象： 

    $ oc apply -f <filename>.yaml

  5. 以 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
    您必须将 openshift-logging 指定为命名空间的名称。

  6. 运行以下命令来应用 OperatorGroup 对象： 

    $ oc apply -f <filename>.yaml

  7. 创建一个 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
    您必须将 openshift-logging 指定为命名空间的名称。
    2
    指定 stable 或 stable-x.y 作为频道。
    3
    指定 redhat-operators。如果 OpenShift Container Platform 集群安装在受限网络中（也称为断开连接的集群），请指定配置 Operator Lifecycle Manager (OLM) 时创建的 CatalogSource 对象的名称。

  8. 运行以下命令来应用订阅： 

    $ 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.7.0-202007012112.p0         OpenShift Logging          5.7.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。
注意

OpenShift Elasticsearch Operator 已被弃用，计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持，但此功能将不再获得改进。您可以使用 Loki Operator 作为 OpenShift Elasticsearch 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
    指定日志存储类型。这可以是 lokistack 或 elasticsearch。
    2
    Elasticsearch 日志存储的可选配置选项。
    3
    指定冗余类型。这个值可以是 ZeroRedundancy、SingleRedundancy、MultipleRedundancy 或 FullRedundancy。
    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
    要用于日志记录的日志收集器类型。这可以是 vector 或 fluentd。

  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
    要用于日志记录的可视化工具类型。这可以是 kibana 或 ocp-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 为默认 Container Network Interface（CNI）网络供应商（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-redhat、openshift-monitoring 和 openshift-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

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

先决条件

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

流程

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

验证

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

6.4. 更新 Loki Operator

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

先决条件

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

流程

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

验证

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

6.5. 更新 OpenShift Elasticsearch Operator

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

注意

OpenShift Elasticsearch Operator 已被弃用，计划在以后的发行版本中删除。红帽将在当前发行生命周期中将提供对这个功能的 bug 修复和支持，但此功能将不再获得改进。您可以使用 Loki Operator 作为 OpenShift Elasticsearch 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 控制台中，点击 Operators → Installed Operators。
  2. 选择 openshift-operators-redhat 项目。
  3. 点 OpenShift Elasticsearch Operator。
  4. 点 Subscription → Channel。
  5. 在 Change Subscription Update Channel 窗口中，选择 stable-5.y 并点 Save。注意 elasticsearch-operator.v5.y.z 版本。
  6. 等待几秒钟，然后点 Operators → Installed Operators。验证 OpenShift Elasticsearch Operator 版本是否与最新的 elasticsearch-operator.v5.y.z 版本匹配。

  7. 在 Operators → Installed Operators 页面中，等待 Status 字段报告 Succeeded。

    1. 在 Web 控制台中，点 Operators → Installed Operators。

验证

  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-00000x、infra-00000x、audit-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
    要用于日志记录的可视化工具类型。这可以是 kibana 或 ocp-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 控制台中，导航到 Workloads → Pods，或通过您要调查的资源导航到 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 视角中，进入 Operators → Installed Operators。
  2. 点 Red Hat OpenShift Logging。这会进入 Operator Details 页面。
  3. 在 Details 页面中，为 控制台插件选项点 Disabled。
  4. 在控制台插件启用对话框中，选择 Enable。
  5. 点击 Save。
  6. 验证 控制台插件选项现在显示 Enabled。
  7. 应用更改后，web 控制台会显示一个弹出窗口。窗口提示您重新加载 Web 控制台。当您看到弹出窗口以应用更改时，刷新浏览器。

7.3. 查看集群仪表板

OpenShift Container Platform web 控制台中的 Logging/Elasticsearch Nodes 和 Openshift 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 Nodes 和 OpenShift Logging 仪表板。

流程

启动仪表板：

  1. 在 OpenShift Container Platform web 控制台中点 Observe → Dashboards。

  2. 在 Dashboards 页面中，从 Dashboard 菜单中选择 Logging/Elasticsearch Nodes 或 OpenShift Logging。

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

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

  3. 可选：从 Time Range 和 Refresh 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 中查看 infra 和 audit 索引。默认 kubeadmin 用户具有查看这些索引的权限。

    如果可以查看 default、kube- 和 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. 点 Management → Index Patterns → Create index pattern 创建 Kibana 索引模式:

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

7.4.2. 在 Kibana 中查看集群日志

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

先决条件

  • 必须安装 Red Hat OpenShift Logging 和 Elasticsearch Operator。
  • Kibana 索引模式必须存在。

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

    如果可以查看 default、kube- 和 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. 从左上角的下拉菜单中选择您创建的索引模式： app、audit 或 infra。

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

  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=30s 和 RateLimitBurst=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.11.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=30s 和 RateLimitBurst=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, INFO 和 DEBUG 日志同步到磁盘上前等待的超时时间。systemd 在接收到 CRIT, ALERT 或 EMERG 日志后会立即进行同步。默认值为 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 用户名/密码

✓

✓

Cloudwatch keys

✓

✓

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. 可见性
功能