1.23. OpenShift Logging 5.3.0
此发行版本包括 RHSA-2021:4627 OpenShift Logging 程序错误修复 5.3.0
1.23.1. 新功能及功能增强
- 在这个版本中,Log Forwarding 的授权选项已被扩展。输出现在可以配置 SASL、用户名/密码或 TLS。
1.23.2. 程序错误修复
- 在此次更新之前,如果您使用 syslog 协议转发日志,请串行化 ruby 哈希编码的键/值对,使其包含"归档"字符,并使用"#11"替换制表符。在这个版本中解决了这个问题,日志消息被正确序列化为有效的 JSON。(LOG-1494)
- 在此次更新之前,应用程序日志没有被正确配置,以转发到启用了多行错误检测的正确的 Cloudwatch 流。(LOG-1939)
- 在此次更新之前,5.3 发行版中部署的收集器的名称更改会导致生成警报 'fluentnodedown'。(LOG-1918)
- 在此次更新之前,以前的发行配置中引入的回归会导致收集器在关闭前清除其缓冲区信息,从而造成终止并重启收集器 Pod。在这个版本中,fluentd 不再在关闭时清除缓冲区,从而解决了这个问题。(LOG-1735)
- 在此次更新之前,在以前的版本中会有意禁用 JSON 消息解析。这个版本重新启用 JSON 解析。它还根据解析 JSON 消息中的"level"字段设置日志条目"level"字段,或者使用 regex 从消息字段中提取匹配项。(LOG-1199)
-
在此次更新之前,
ClusterLogging
自定义资源(CR)将totalLimitSize
字段的值应用到 Fluentdtotal_limit_size
字段,即使所需的缓冲空间不可用。在这个版本中,CR 会将两个totalLimitSize
或 'default' 值的 lesser 应用到 Fluentdtotal_limit_size
字段,从而解决这个问题。(LOG-1776)
1.23.3. 已知问题
如果您将日志转发到外部 Elasticsearch 服务器,然后在管道 secret 中更改配置的值,如用户名和密码,Fluentd forwarder 会加载新 secret,但使用旧值连接到外部 Elasticsearch 服务器。出现这个问题的原因是,Red Hat OpenShift Logging Operator 当前不会监控 secret 的内容更改。(LOG-1652)
作为临时解决方案,如果更改了 secret,您可以强制重新部署 Fluentd Pod:
$ oc delete pod -l component=collector
1.23.4. 弃用和删除的功能
之前版本中的一些功能已被弃用或删除。
弃用的功能仍然包含在 OpenShift Logging 中,并且仍然被支持。但是,这个功能会在以后的发行版本中被删除,且不建议在新的部署中使用。
1.23.4.1. 使用旧的 Fluentd 和旧的 syslog 方法转发日志已被删除
在 OpenShift Logging 5.3 中,将日志转发到 Syslog 和 Fluentd 的传统方法已被删除。错误修复和支持在 OpenShift Logging 5.2 生命周期结束时提供。之后,不会进行新的功能增强。
反之,使用以下非传统方法:
1.23.4.2. 已删除旧转发方法的配置机制
在 OpenShift Logging 5.3 中,日志转发的传统配置机制已被删除: 您不能使用旧的 Fluentd 方法和旧的 Syslog 方法转发日志。使用标准日志转发方法。
1.23.5. CVE
例 1.14. 点击以展开 CVE
- CVE-2018-20673
- CVE-2018-25009
- CVE-2018-25010
- CVE-2018-25012
- CVE-2018-25013
- CVE-2018-25014
- CVE-2019-5827
- CVE-2019-13750
- CVE-2019-13751
- CVE-2019-14615
- CVE-2019-17594
- CVE-2019-17595
- CVE-2019-18218
- CVE-2019-19603
- CVE-2019-20838
- CVE-2020-0427
- CVE-2020-10001
- CVE-2020-12762
- CVE-2020-13435
- CVE-2020-14145
- CVE-2020-14155
- CVE-2020-16135
- CVE-2020-17541
- CVE-2020-24370
- CVE-2020-24502
- CVE-2020-24503
- CVE-2020-24504
- CVE-2020-24586
- CVE-2020-24587
- CVE-2020-24588
- CVE-2020-26139
- CVE-2020-26140
- CVE-2020-26141
- CVE-2020-26143
- CVE-2020-26144
- CVE-2020-26145
- CVE-2020-26146
- CVE-2020-26147
- CVE-2020-27777
- CVE-2020-29368
- CVE-2020-29660
- CVE-2020-35448
- CVE-2020-35521
- CVE-2020-35522
- CVE-2020-35523
- CVE-2020-35524
- CVE-2020-36158
- CVE-2020-36312
- CVE-2020-36330
- CVE-2020-36331
- CVE-2020-36332
- CVE-2020-36386
- CVE-2021-0129
- CVE-2021-3200
- CVE-2021-3348
- CVE-2021-3426
- CVE-2021-3445
- CVE-2021-3481
- CVE-2021-3487
- CVE-2021-3489
- CVE-2021-3564
- CVE-2021-3572
- CVE-2021-3573
- CVE-2021-3580
- CVE-2021-3600
- CVE-2021-3635
- CVE-2021-3659
- CVE-2021-3679
- CVE-2021-3732
- CVE-2021-3778
- CVE-2021-3796
- CVE-2021-3800
- CVE-2021-20194
- CVE-2021-20197
- CVE-2021-20231
- CVE-2021-20232
- CVE-2021-20239
- CVE-2021-20266
- CVE-2021-20284
- CVE-2021-22876
- CVE-2021-22898
- CVE-2021-22925
- CVE-2021-23133
- CVE-2021-23840
- CVE-2021-23841
- CVE-2021-27645
- CVE-2021-28153
- CVE-2021-28950
- CVE-2021-28971
- CVE-2021-29155
- lCVE-2021-29646
- CVE-2021-29650
- CVE-2021-31440
- CVE-2021-31535
- CVE-2021-31829
- CVE-2021-31916
- CVE-2021-33033
- CVE-2021-33194
- CVE-2021-33200
- CVE-2021-33560
- CVE-2021-33574
- CVE-2021-35942
- CVE-2021-36084
- CVE-2021-36085
- CVE-2021-36086
- CVE-2021-36087
- CVE-2021-42574