Skip to content

Commit

Permalink
Add translation for 5.8.1 know issues regarding audit log
Browse files Browse the repository at this point in the history
  • Loading branch information
Meggielqk committed Oct 18, 2024
1 parent 709207c commit 4705d55
Show file tree
Hide file tree
Showing 2 changed files with 11 additions and 5 deletions.
10 changes: 5 additions & 5 deletions en_US/changes/known-issues-5.8.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,21 +29,21 @@
- **Kafka Disk Buffer Resume (since 5.8.0)**

If `disk` mode buffer is used, Kafka (Azure EventHubs, Confluent Platform) producers will not automatically start sending data from disk to Kafka after node restart. The sending will be triggered only after there is a new message to trigger the dynamic add of a topic producer.
This will be fixed in 5.8.2.
This issue will be fixed in 5.8.2.

<!-- https://emqx.atlassian.net/browse/EMQX-13242 -->

- **Limitation in SAML-Based SSO (since 5.3)**

EMQX Dashboard supports Single Sign-On based on the Security Assertion Markup Language (SAML) 2.0 standard and integrates with Okta and OneLogin as identity providers. However, the SAML-based SSO currently does not support a certificate signature verification mechanism and is incompatible with Azure Entra ID due to its complexity.

- **Performance degradation viewing Audit events (since 5.4.0)**
- **Performance Degradation When Viewing Audit Events (since 5.4.0)**

When Audit log is enabled and specific Audit events are recently logged, in rare cases an attempt to view Audit events in the dashboard may cause a severe performance degradation, or even a crash of the EMQX node in exceptional situations, e.g. when the node is memory-constrained. Events that are known to cause this issue are Backup and Restore API requests, and commands evaluated in the EMQX remote console manipulating particularly large data structures. Nodes may also take longer to start and become responsive in these situations.
This will be fixed in 5.8.2.
Enabling the audit log and viewing specific events in the Dashboard can, in rare cases, cause significant performance degradation or even crash the EMQX node in exceptional situations, particularly on memory-constrained nodes. Events known to cause this issue include Backup and Restore API requests and commands executed in the EMQX remote console that manipulate large data structures. Nodes may also take longer to start and become responsive in these situations.
This issue will be fixed in 5.8.2.

> **Workaround:**
> Change the _Max Dashboard Record Size_ setting either through the Dashboard or by setting the `log.audit.max_filter_size` to a particularly low number, eventually the offending events should be cleared from the Audit log once enough new events are logged.
> Adjust the **Max Dashboard Record Size** through the Dashboard, or lower the `log.audit.max_filter_size` setting. Over time, problematic events will be cleared from the Audit log as new events are recorded.
## e5.8.0

Expand Down
6 changes: 6 additions & 0 deletions zh_CN/changes/known-issues-5.8.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,6 +30,12 @@

EMQX Dashboard 支持基于安全断言标记语言(SAML)2.0标准的单点登录(SSO),并与 Okta 和OneLogin 作为身份提供商集成。然而,基于 SAML 的 SSO 目前不支持证书签名验证机制,并且由于其复杂性,无法与 Azure Entra ID 兼容。

- **查看审计事件时性能下降(始于 5.4.0)**

启用审计日志并在 Dashboard 中查看特定事件时,可能会在极少数情况下导致显著的性能下降,甚至在极端情况下(尤其是内存受限的节点)导致 EMQX 节点崩溃。已知会引发此问题的事件包括备份和恢复 API 请求,以及在 EMQX 远程控制台中执行操作大型数据结构的命令。在这些情况下,节点启动和响应时间可能也会变长。该问题将在 5.8.2 版本中修复。

> **解决方法:** 通过 Dashboard 调整**最大 Dashboard 记录数**,或将 `log.audit.max_filter_size` 设置为较低的值。随着新事件的记录,问题事件将逐渐从审计日志中清除。
## e5.8.0

- **节点崩溃竞态条件(始于 5.0,已在 5.8.1 中修复)**
Expand Down

0 comments on commit 4705d55

Please sign in to comment.