GUI 日志¶
TripleO GUI 目前没有持久化日志信息的方式。
问题描述¶
TripleO GUI 是一个 Web 应用程序，没有自己的专用后端。因此，所有客户端错误都会在最终用户重新加载页面或离开应用程序时丢失。当出现问题时，最终用户无法检索客户端日志，因为这些信息没有被持久化。
提议的变更¶
概述¶
我建议我们使用 Zaqar 作为客户端日志的持久化后端。目前，Web 应用程序已经在使用 websocket 与 Zaqar 进行通信。我们可以使用此连接向一个专用的日志队列发布新消息。
Zaqar 消息的 TTL 为一小时。因此，每三十分钟，Mistral 将使用 crontrigger 查询 Zaqar，并检索 tripleo-ui-logging 队列中的所有消息。Mistral 将随后在 Swift 中查找名为 tripleo-ui-log 的文件。如果该文件存在，Mistral 将检查其大小。如果大小超过预定的尺寸（例如 10MB），Mistral 将将其重命名为 tripleo-ui-log-<timestamp>，并在其位置创建一个新文件。然后，该文件将接收来自 Zaqar 的消息，每行一条。一旦达到，比如说，一百个存档（约 1GB），我们可以开始删除数据以防止不必要的数据积累。
要查看日志数据，我们可以要求 Swift 提供 10 个最新的、前缀为 tripleo-ui-log 的消息。这些文件可以在 GUI 中呈现以供下载。如果用户需要，我们可以呈现一个“查看更多”链接，该链接将显示其余收集的文件。
替代方案¶
目前没有
安全影响¶
存在记录敏感数据的风险。我建议我们在将消息存储到 Swift 之前应用一些通用的清理机制。
其他最终用户影响¶
性能影响¶
通过现有的 websocket 连接发送额外消息对 Web 应用程序的性能影响可以忽略不计。同样，在 Mistral 中运行每小时的 cron 任务也不会对 undercloud 机器造成重大负担。
其他部署者影响¶
开发人员影响¶
开发人员也应该受益于一个集中的日志系统，作为提高调试效率的一种手段。
实现¶
负责人¶
- 主要负责人
hpokorny
工作项¶
引入一个中央日志系统（已经在进行中，请参阅 蓝图）
引入一个全局错误处理程序
将所有日志消息转换为使用标准格式的 JSON
配置：用于承载日志数据的 Zaqar 队列的名称
引入一个 Mistral 工作流，用于清空 Zaqar 队列并将获取的数据发布到 Swift 中的一个文件
引入 GUI 元素以下载日志文件
依赖项¶
测试¶
我们可以为处理通过 websocket 连接发送消息的代码编写单元测试。我们也许可以编写一个集成烟雾测试，以确保消息被 undercloud 接收。我们还可以向 tripleo-common 添加一些测试代码，以覆盖清空队列并将日志数据发布到 Swift 的逻辑。
文档影响¶
我们需要记录 Zaqar 队列的默认名称、每个日志文件的最大大小以及最多可以存储多少个日志文件。在最终用户方面，我们应该记录 GUI 相关的日志可用，以及获取它的方式。
