1.2.11.4. 程序错误修复
- 在以前的版本中，Elasticsearch 会拒绝 HTTP 请求，其标头超过默认的最大标头大小 8 KB。现在，最大标头大小为 128 KB，Elasticsearch 不再拒绝超过最大标头大小的 HTTP 请求。(BZ#1845293)
-
在以前的版本中，节点无法从
Pending状态恢复，因为一个软件漏洞导致无法在 Elasticsearch 自定义资源（CR）中正确更新其状态。当前发行版本解决了这个问题，节点可在从Pending状态中进行恢复。(BZ#1887357) -
在以前的版本中，当 Cluster Logging Operator（CLO）将
clusterloggingCR 中的 Elasticsearch 节点数量缩减为三个节点时，它会忽略之前创建的具有唯一 ID 的节点。OpenShift Elasticsearch Operator 会拒绝更新，因为它有一个保护机制来防止带有唯一 ID 的节点被删除。现在，当 CLO 缩减节点数量并更新 Elasticsearch CR 时，它会将具有唯一 ID 的节点标记为 count 0，而不是省略它们。因此，用户可以使用clusterloggingCR 将集群缩减到 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-rollover和elasticsearch-deletepod 会处于Invalid JSON:或ValueError: No JSON object could be decoded的错误状态中。产生这个异常的原因是，无效的 JSON 输入没有异常处理程序。当前发行版本解决了这个问题，为无效 JSON 输入提供处理程序。因此，处理器会输出错误消息而不是异常 traceback，而且elasticsearch-rollover和elasticsearch-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）
