收集 IPA 中的系统日志¶
https://bugs.launchpad.net/ironic/+bug/1587143
此规范增加了从 IPA 检索部署系统日志的支持。
问题描述¶
我们目前没有自动从 IPA 部署 ramdisk 检索系统日志的机制。访问日志可能非常有用，尤其是在排查部署失败时。目前，有几种方法可以访问 ramdisk 中的日志，但它们是手动操作的，有时在生产环境中不希望启用它们。以下几点描述了其中的两种
为正在部署的节点启用控制台会话。
虽然这可行，但很棘手，因为操作员需要弄清楚调度器选择了哪个节点并为其启用控制台。此外，并非所有驱动程序都支持控制台。
禁用在部署失败时关闭节点电源。
操作员可以 禁用在部署失败时关闭节点电源，但这有一些影响
它不能与 Nova 协同工作。当实例未能配置成功时，nova 将调用 destroy()，Ironic virt 驱动程序将强制关闭该节点电源。
在某些部署中，在失败后让节点保持通电是不希望的。
提议的变更¶
建议的实现方式是让 Ironic 通过其 API 从部署 ramdisk (IPA) 检索系统日志，然后将其上传到 Swift 或保存到该 conductor 的本地文件系统（对于独立模式用户）。
IPA 中的更改¶
IPA 将添加一个新的 log 扩展。此扩展将引入一个新的同步命令，称为 collect_system_logs。通过调用此命令，IPA 将对系统日志进行 tar、gzip 和 base64 编码，并将结果字符串返回给调用者。
由于我们支持 IPA 的不同基础操作系统（例如 Tiny Core Linux、Fedora、Debian），因此我们需要根据系统使用不同的方法来查找日志。此规范提出了两种方法，应该足以满足今天大多数发行版的需求
对于使用
systemd的发行版，所有系统日志都可以通过journald访问。IPA 将调用journalctl命令并从那里获取日志。对于其他发行版，此规范建议保留来自 /var/log 的所有日志以及
dmesg命令的输出。
所有发行版的日志，无论初始化系统如何，还将包含以下命令文件的输出：ps、df 和 iptables。
Ironic 中的更改¶
将在 Ironic 的 [agent] 组下添加新的配置选项
deploy_logs_collect(字符串)：Ironic 是否应该收集部署日志。有效选项为：“always”、“on_failure”或“never”。默认值为“on_failure”。deploy_logs_storage_backend(字符串)：存储响应文件的存储后端名称。两者之一：“local”或“swift”。默认值为“local”。deploy_logs_local_path(字符串)：日志应存储到的目录的路径，当deploy_logs_storage_backend配置为 local 时使用。默认值为/var/log/ironic/deploy。deploy_logs_swift_container(字符串)：用于存储日志的 Swift 容器的名称，当deploy_logs_storage_backend配置为 swift 时使用。默认值为 ironic_deploy_logs_container。deploy_logs_swift_days_to_expire(整数)：日志对象在 Swift 中 标记为过期 之前的天数。如果为 None，则日志将永久保留或直到手动删除。当deploy_logs_storage_backend配置为 swift 时使用。默认值为 30 天。
注意
在将日志存储到本地文件系统时，Ironic 不会负责在一段时间后删除日志。如果需要，由操作员配置外部作业来执行此操作。
根据 deploy_logs_collect 的值，Ironic 将在节点部署过程中（在关闭或重新启动节点之前）调用 log.collect_system_logs。例如，如果 deploy_logs_collect 设置为 always，Ironic 将独立于部署成功或失败来收集日志；如果设置为 on_failure，Ironic 将在部署失败时收集日志；如果设置为 never，Ironic 将从不收集部署日志。
收集到日志后，Ironic 应解码 base64 编码的 tar.gz 文件并根据 deploy_logs_storage_backend 配置存储它。所有日志对象都将按照以下模式命名：<node-uuid>[_<instance-uuid>]_<timestamp yyyy-mm-dd-hh:mm:ss>.tar.gz。请注意，当 Ironic 配置为以 standalone 模式使用时，部署节点不需要 instance_uuid 字段，因此如果存在，它将被附加到名称中。
在使用 Swift 时，操作员可以将容器中的对象与 Ironic 中的节点关联起来，并使用 prefix 参数搜索特定节点的日志，例如
$ swift list ironic_deploy_logs_container -p 5e9258c4-cfda-40b6-86e2-e192f523d668
5e9258c4-cfda-40b6-86e2-e192f523d668_0c1e1a65-6af0-4cb7-a16e-8f9a45144b47_2016-05-31_22:05:59
5e9258c4-cfda-40b6-86e2-e192f523d668_db87f2c5-7a9a-48c2-9a76-604287257c1b_2016-05-31_22:07:25
注意
此实现要求网络设置正确，否则 Ironic 将无法联系 IPA API。在调试此类问题时，唯一可能的动作是查看节点的控制台以查看一些日志。此方法有一些注意事项：请参阅 问题描述 以获取更多信息。
注意
Ironic 或 IPA 不会负责在存储日志之前对其进行清理。首先，因为此规范仅限于收集部署日志，并且此时租户尚未使用该节点。其次，生成日志的服务应负责在其日志中屏蔽机密信息（就像我们在 Ironic 中所做的那样），否则应将其视为错误。
备选方案¶
由于我们已经提供了通过访问控制台或禁用节点故障时关闭电源来执行此操作的方法，因此这项工作的替代方案不多了。
当前提出的解决方案可以扩展到超出此规范范围的更多用例。例如，与其将其上传到 Swift 或存储在本地文件系统中，Ironic 还可以将其上传到 HTTP/FTP 服务器。
如 IPA 中的更改 中简要描述的那样，收集日志的方法可以扩展到包括更多日志和不同命令的输出，这些输出对于故障排除很有用。
数据模型影响¶
无
状态机影响¶
无
REST API 影响¶
无
客户端 (CLI) 影响¶
无
RPC API 影响¶
无
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
无
Ramdisk 影响¶
无
安全影响¶
无。
需要注意的是，凭据 不 会从 Ironic 传递到部署 ramdisk。已经持有 Swift 凭据的 ironic-conductor 服务负责将日志上传到 Swift。
其他最终用户影响¶
无
可扩展性影响¶
无
性能影响¶
如果启用了日志收集，节点将在 deploying 置备状态下停留更长时间，而 IPA 正在收集日志。
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
lucasagomes <lucasagomes@gmail.com>
其他贡献者
工作项¶
在 IPA 中添加新的
log扩展和collect_system_logs方法。添加在 Ironic 中的更改 部分中描述的新配置选项。
在部署过程中调用 IPA 中的新
log.collect_system_logs方法，并根据deploy_logs_storage_backend配置选项（如果启用）存储响应文件。
依赖项¶
无
测试¶
将添加单元测试。
升级和向后兼容性¶
无。
需要注意的是，当使用不支持新的 log.collect_system_logs 命令的旧 IPA ramdisk 时，Ironic 应处理此异常并向操作员记录警告消息，如果 deploy_logs_collect 设置为 always 或 on_failure。
文档影响¶
将提供关于如何配置 Ironic 以从部署 ramdisk 收集系统日志的文档。
参考资料¶
无。
