1.2.11.4. 程序错误修复

  • 在以前的版本中,Elasticsearch 会拒绝 HTTP 请求,其标头超过默认的最大标头大小 8 KB。现在,最大标头大小为 128 KB,Elasticsearch 不再拒绝超过最大标头大小的 HTTP 请求。(BZ#1845293)
  • 在以前的版本中,节点无法从 Pending 状态恢复,因为一个软件漏洞导致无法在 Elasticsearch 自定义资源(CR)中正确更新其状态。当前发行版本解决了这个问题,节点可在从 Pending 状态中进行恢复。(BZ#1887357)
  • 在以前的版本中,当 Cluster Logging Operator(CLO)将 clusterlogging CR 中的 Elasticsearch 节点数量缩减为三个节点时,它会忽略之前创建的具有唯一 ID 的节点。OpenShift Elasticsearch Operator 会拒绝更新,因为它有一个保护机制来防止带有唯一 ID 的节点被删除。现在,当 CLO 缩减节点数量并更新 Elasticsearch CR 时,它会将具有唯一 ID 的节点标记为 count 0,而不是省略它们。因此,用户可以使用 clusterlogging CR 将集群缩减到 3 个节点。(BZ#1879150)
注意

在 OpenShift Logging 5.0 及更高版本中,Cluster Logging Operator 称为 Red Hat OpenShift Logging Operator。

  • 在以前的版本中,当 ClusterLogForwarder 具有错误配置的 secret 时,Fluentd 收集器 Pod 会进入崩溃循环。当前发行版本解决了这个问题。现在,ClusterLogForwarder 会验证 secret,并报告其 status 字段中的任何错误。因此,它不会导致 Fluentd 收集器 Pod 出现崩溃。(BZ#1888943)
  • 在以前的版本中,如果您将 clusterlogging 实例中的 Kibana 资源配置更新为 resource{},则生成的 nil 映射会导致 panic,并将 OpenShift Elasticsearch Operator 的状态改为 CrashLoopBackOff。当前发行版本通过初始化映射解决了这个问题。(BZ#1889573)
  • 在以前的版本中,当 ClusterLogForwarder 使用相同的 secret 具有多个输出时,fluentd 收集器 Pod 会进入崩溃循环。当前发行版本解决了这个问题。现在,多个输出可以共享一个 secret。(BZ#1890072)
  • 在以前的版本中,如果您删除了 Kibana 路由,Cluster Logging Operator(CLO)将无法恢复或重新创建它。现在,CLO 会监视路由,如果删除了路由,OpenShift Elasticsearch Operator 可以协调或重新创建路由。(BZ#1890825)
  • 在以前的版本中,Cluster Logging Operator(CLO)会尝试协调 Elasticsearch 资源,这依赖于红帽提供的 Elastic 自定义资源定义(CRD)。试图列出未知类型会导致 CLO 退出其协调循环。这是因为 CLO 试图协调其所有受管资源,无论资源是否被定义。当前发行版本解决了这个问题。如果用户定义了受管存储,则 CLO 只会协调 OpenShift Elasticsearch Operator 提供的类型。因此,用户可以通过部署 CLO 来创建仅收集器集群日志记录的部署。(BZ#1891738)
  • 在以前的版本中,因为 RFC 3164 的 LF GA syslog 实现,发送到远程 syslog 的日志与旧行为不兼容。当前发行版本解决了这个问题。AddLogSource 在"message" 字段中添加有关日志源详情的详细信息。现在,发送到远程 syslog 的日志与旧行为兼容。(BZ#1891886)
  • 在以前的版本中,Elasticsearch 滚动 pod 失败,并显示 resource_already_exists_exception 错误。在 Elasticsearch 滚动 API 中,当创建下一个索引时,*-write 别名没有更新来指向它。因此,当下次为该特定索引触发滚动 API 端点时,它会收到资源已存在的错误。

    当前发行版本解决了这个问题。现在,当在 indexmanagement cronjobs 中进行滚动时,如果创建了新索引,它会验证别名指向新的索引。这个行为可防止错误。如果集群已经收到这个错误, cronjob 会修复这个问题,以便后续运行可以正常工作。现在,执行滚动不再会产生异常。(BZ#1893992

  • 在以前的版本中,Fluent 会在日志堆栈功能正常的情况下停止发送日志。即使端点已可以使用,在一段时间内日志也无法发送到端点。如果最大的 backoff 时间过长且端点下线,会出现这种情况。当前的发行版本解决了这个问题,缩短了 max backoff 时间,因此日志会更早发布。(BZ#1894634)
  • 在以前的版本中,省略 Elasticsearch 节点的存储大小会在 OpenShift Elasticsearch Operator 代码中造成 panic。这个 panic 在日志中被记录为:Observed a panic: "invalid memory address or nil pointer dereference"。panic 发生的原因是,存储大小是一个必需的字段,但在代码中没有对其进行检查。当前的发行版本解决了这个问题,在省略存储大小,不会出现 panic。相反,存储被默认为临时存储,并为用户生成一个相关的日志信息。(BZ#1899589
  • 在以前的版本中,elasticsearch-rolloverelasticsearch-delete pod 会处于 Invalid JSON:ValueError: No JSON object could be decoded 的错误状态中。产生这个异常的原因是,无效的 JSON 输入没有异常处理程序。当前发行版本解决了这个问题,为无效 JSON 输入提供处理程序。因此,处理器会输出错误消息而不是异常 traceback,而且 elasticsearch-rolloverelasticsearch-delete 作业不会保留在这些错误状态。(BZ#1899905)
  • 在以前的版本中,当将 Fluentd 部署为单机时,即使 replicas 值为 0,也会创建一个 Kibana Pod。这是因为即使没有 Elasticsearch 节点,Kibana 也会默认为 1 个 pod。当前发行版本解决了这个问题。现在,仅在有一个或多个 Elasticsearch 节点时,Kibana 才会被默认为 1。(BZ#1901424)
  • 在以前的版本中,如果您删除了 secret,它无法被重新创建。虽然证书存在于 Operator 的一个本地磁盘,但是它们并没有被重新写入,因为它们还没有改变。也就是说,只有在证书有变化时才会被写入。当前发行版本解决了这个问题。如果证书有变化或未找到证书,它会重写 secret。现在,如果删除了 master-certs,它们会被替换。(BZ#1901869)
  • 在以前的版本中,如果集群有多个同名自定义资源,则当 API 组没有完全限定时,资源会按字母顺序进行选择。因此,如果您同时安装了红帽的 OpenShift Elasticsearch Operator 和 OpenShift Elasticsearch Operator,您会在通过 must-gather 报告收集数据时看到失败。当前,通过确保 must-gathers 现在在收集集群自定义资源信息时使用完整的 API 组解决了这个问题。(BZ#1897731)
  • 解决与证书生成相关的问题的早期程序错误修复会出现一个错误。尝试读取证书会导致重新生成证书,因为它们被认为没有存在。然后,这会触发 OpenShift Elasticsearch Operator 对 Elasticsearch 集群执行滚动升级,并可能具有不匹配的证书。此程序漏洞是因为 operator 错误地在工作目录中写入证书造成的。当前发行版本解决了这个问题。现在,operator 会持续将证书读取并写入同一工作目录,证书仅在需要时重新生成。(BZ#1905910)
  • 在以前的版本中,查询根端点以检索 Elasticsearch 版本会收到 403 响应。403 响应会破坏之前版本中使用这个端点的所有服务。发生此错误的原因是,非管理员用户没有查询根端点并检索 Elasticsearch 版本所需的 monitor 权限。现在,非管理员用户可以查询 Elasticsearch 部署的根端点。(BZ#1906765)
  • 在以前的版本中,在某些批量插入的情况下,Elasticsearch 代理在 fluentd 和 Elasticsearch 之间的连接可能会出现超时问题。因此,fluentd 无法发送信息,并在日志中记录一个 Server returned nothing (no headers, no data) 错误。当前发行版本解决了这个问题:它将 Elasticsearch 代理中的默认 HTTP 读写超时时间从 5 秒增加到一分钟。它还在 Elasticsearch 代理中提供命令行选项来控制字段中的 HTTP 超时。(BZ#1908707)
  • 在以前的版本中,在一些情况下,OpenShift Container Platform 监控仪表板中没有 Red Hat OpenShift Logging/Elasticsearch 仪表板,因为仪表板配置资源指向不同的命名空间所有者,并导致 OpenShift Container Platform 垃圾回收该资源。现在,所有权引用已从 OpenShift Elasticsearch Operator 协调器配置中删除,日志记录仪表板会出现在控制台中。(BZ#1910259
  • 在以前的版本中,使用环境变量替换 Kibana 配置文件中值的代码不会考虑注释行。这导致用户无法覆盖 server.maxPayloadBytes 的默认值。当前发行版本解决了这个问题,方法是取消对默认值 server.maxPayloadBytesin 的注释。现在,用户可以使用环境变量覆盖值,如相关文档所述。(BZ#1918876
  • 在以前的版本中,增大 Kibana 日志级别不会绕过删除无法迁移的索引的说明,这也会导致在包含 Kibana 用户电子邮件地址和 OAuth 令牌的 INFO 级别显示 GET 请求。当前发行版本解决了这个问题,它伪装这些字段,因此 Kibana 日志不会显示它们。(BZ#1925081