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

第 1 章 发行注记

1.1. Logging 5.8

注意

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

注意

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

1.1.1. Logging 5.8.5

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

1.1.1.1. 程序错误修复

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

1.1.1.2. CVE

1.1.2. Logging 5.8.4

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

1.1.2.1. 程序错误修复

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

1.1.2.2. CVE

1.1.3. Logging 5.8.3

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

1.1.3.1. 程序错误修复

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

1.1.3.2. CVE

1.1.4. Logging 5.8.2

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

1.1.4.1. 程序错误修复

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

1.1.4.2. CVE

1.1.5. Logging 5.8.1

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

1.1.5.1. 功能增强

1.1.5.1.1. 日志集合
  • 在这个版本中，在将 Vector 配置为收集器时，您可以在 Red Hat OpenShift Logging Operator 中添加逻辑，以使用 secret 中指定的令牌来代替与服务帐户关联的令牌。(LOG-4780)
  • 在这个版本中，BoltDB Shipper Loki 仪表板被重命名为 Index 仪表板。(LOG-4828)

1.1.5.2. 程序错误修复

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

1.1.5.3. CVE

1.1.6. Logging 5.8.0

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

1.1.6.1. 弃用通知

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

1.1.6.2. 功能增强

1.1.6.2.1. 日志集合
  • 在这个版本中，LogFileMetricExporter 不再默认和收集器一起部署。您需要手动创建一个 LogFileMetricExporter 自定义资源 (CR)，从运行容器生成的日志中生成指标。如果没有创建 LogFileMetricExporter CR，您可能会在 OpenShift Container Platform Web 控制台仪表板中看到 Produced Logs 的 No datapoints found 信息。(LOG-3819)

  • 在这个版本中，您可以在任何命名空间中部署多个、隔离和 RBAC 保护的 ClusterLogForwarder 自定义资源(CR)实例。这允许独立组将所需的日志转发到任何目的地，同时将其配置与其他收集器部署隔离。(LOG-1343)

    重要

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

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

1.1.6.3. 已知问题

  • 目前，在升级到 Red Hat OpenShift Logging Operator 版本 5.8 后，Splunk 日志转发可能无法正常工作。这个问题是由从 OpenSSL 版本 1.1.1 转换到 3.0.7 版本造成的。在较新的 OpenSSL 版本中，有一个默认行为更改，如果没有公开 RFC 5746 扩展，则拒绝到 TLS 1.2 端点的连接。

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

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

1.1.6.4. CVE

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.