TripleO 远程日志记录¶

https://blueprints.launchpad.net/tripleo/+spec/remote-logging

本规范旨在扩展 tripleo-logging 规范，也适用于 queens，以解决日志传输和存储的关键问题，这些问题与容器化进程的日志记录所产生的技术要求是分开的。

问题描述¶

将日志停留在单个超云节点对于大规模部署的现代系统来说不是一个可行的解决方案。但日志聚合在实施和扩展方面都非常复杂。TripleO 应该提供一个健壮、文档完善且可扩展的解决方案，以满足大多数用户的需求，并易于扩展给其他用户。

提议的变更¶

概述¶

除了 triple-logging 规范中定义的容器的 rsyslog 日志记录到 stdout 之外，本规范还详细介绍了如何进行远程目标日志记录。

本质上，这归结为 rsyslog 容器配置的一组选项。其他服务将具有固定的 rsyslog 配置，该配置会将消息转发到 rsyslog 容器以通过 journald 收集。

日志目的地：本地、远程直接或远程聚合器。

远程直接是指直接连接到存储解决方案，在本例中为 Elasticsearch 或磁盘上的纯文本。远程聚合器是一种设计，其中日志的处理、格式化和插入是留给聚合器服务器的任务。使用聚合器，可以在不使存储后端不堪重负的情况下，将日志收集扩展到数百个超云节点，而不会出现低效的连接。

远程目标的日志缓存

对于远程目标，可以设置一个缓存系统，其中日志会暂时存储在本地机器上的可配置磁盘或内存缓存中，直到可以将其上传到聚合器或存储系统。虽然一些内存缓存是强制性的，但用户可以根据保存和存储所有日志的重要性选择磁盘缓存。这允许在网络中断或服务中断期间恢复而不会丢失消息。

传输过程中的日志安全性

在某些情况下，传输过程中的加密可能是必需的。rsyslog 提供基于 ssl 的加密，应该易于部署。

标准且可扩展的格式

默认情况下，日志应按照 Redhat 共同日志记录倡议的规定进行格式化。尽可能标准化日志格式，可以使各种工具和分析更具可移植性。

此标准格式的强制字段包括：

version: 日志记录模板的版本 level: 日志级别 message: 日志消息 tags: 用户特定的标记信息

必须以以下格式添加其他字段：

以下是 rsyslog 存储在 Elasticsearch 中的示例：

@timestamp 2017年11月27日，08:54:40.091 @version 2016.01.06-0 _id AV_9wiWQzdGOuK5_zY5J _index logstash-2017.11.27.08 _score _type rsyslog browbeat.cloud_name openstack-12-noncontainers-beta hostname lorenzo.perf.lab.eng.rdu.redhat.com level info message 停止设备 8:2… 上的 LVM2 PV 扫描 pid 1 rsyslog.appname systemd rsyslog.facility daemon rsyslog.fromhost-ip 10.12.20.155 rsyslog.inputname imptcp rsyslog.protocol-version 1 syslog.timegenerated 2017年11月27日，08:54:40.092 systemd.t.BOOT_ID 1e99848dbba047edaf04b150313f67a8 systemd.t.CAP_EFFECTIVE 1fffffffff systemd.t.CMDLINE /usr/lib/systemd/systemd –switched-root –system –deserialize 21 systemd.t.COMM systemd systemd.t.EXE /usr/lib/systemd/systemd systemd.t.GID 0 systemd.t.MACHINE_ID 0d7fed5b203f4664b0b4be90e4a8a992 systemd.t.SELINUX_CONTEXT system_u:system_r:init_t:s0 systemd.t.SOURCE_REALTIME_TIMESTAMP 1511790880089672 systemd.t.SYSTEMD_CGROUP / systemd.t.TRANSPORT journal systemd.t.UID 0 systemd.u.CODE_FILE src/core/unit.c systemd.u.CODE_FUNCTION unit_status_log_starting_stopping_reloading systemd.u.CODE_LINE 1417 systemd.u.MESSAGE_ID de5b426a63be47a7b6ac3eaac82e2f6f systemd.u.UNIT lvm2-pvscan@8:2.service tags

作为视觉辅助，这里是数据流的快速图表：

<进程容器中的 rsyslog> -> <journald> -> <rsyslog 容器> -> <rsyslog 聚合器 / Elasticsearch>

在进程容器中，来自应用程序的日志与来自 systemd 和其他组件的元数据一起打包，具体取决于 rsyslog 的配置。journald 充当传输，跨所有容器聚合此输入以供 rsyslog 容器使用，该容器将此数据格式化为可存储的 json，并处理诸如转换字段和添加其他元数据等操作。最后，数据插入到 elasticsearch 中，或者由聚合器进一步保存几秒钟，然后再批量插入到 Elasticsearch 中。

替代方案¶

TripleO 已经具有一定程度的 FluentD 集成，但性能问题使其无法大规模使用。此外，它还没有为容器日志记录做好准备。

理想情况下，FluentD 作为日志记录后端应该得到维护、改进和修改，以使用共同的日志记录格式，以便轻松交换解决方案。

安全影响¶

远程存储数据的安全性和日志存储数据库的安全级别超出了本规范的范围。主要剩余问题是传输过程中的安全性以及 rsyslog 远程发送数据所需的 systemd 的更改。

必须实施新的 systemd 策略，以确保 systemd 能够成功地将日志记录到远程目标。默认情况下，syslog 规则会阻止任何外部访问或端口访问，而这两者都是日志转发所必需的。

为了在传输过程中进行日志加密，必须生成 ssl 证书并安全地分发到云中的所有节点，可能是在部署期间。应特别注意确保任何未正确配置的 rsyslog 实例（在需要证书的情况下没有证书）不会意外地传输日志。

其他最终用户影响¶

理想情况下，用户将阅读一些文档，并将额外的 5-6 个变量传递给 TripleO 以进行部署，并启用日志聚合。日志记录易于设置，具有合理的默认值，并且用户无需实施自己的格式或模板，这一点非常重要。

用户可能还需要设置用于日志存储和聚合器的数据库（如果其部署规模足够大，需要使用这些数据库）。将执行自动执行此操作的 playbook，但可能不属于 TripleO。

必须特别注意为任务调整存储和聚合硬件的大小，虽然 rsyslog 非常高效，但当云每天可以生成 100gb 的日志时，存储很快就会成为一个问题。特别是由于日志存储系统让用户负责实施轮换规则。

性能影响¶

对于小型云，rsyslog 直接连接到 Elasticsearch 即可正常工作。随着规模的扩大，需要一个聚合器（也运行 rsyslog，但配置为接受和格式化输入）。我还没有测试过足够大的云，以至于聚合器受到任何压力。

对于转发日志的超云节点，影响因用户的配置而异。即使在高负载下，CPU 要求也不会超过单个核心的个位数，但如果指定了大型磁盘缓存并且与聚合器或数据库的连接中断了很长时间，存储要求可能会激增。

内存使用量不超过几百 MB，并且大部分是默认的内存日志缓存。用户可以再次扩展它。

其他部署者影响¶

N/A

开发人员影响¶

N/A

实现¶

负责人¶

谁在编写代码？或者这是一个蓝图，您正在将其抛出以查看谁会接受它？

如果有多个人正在进行实现，请指定主要作者和联系人。

主要负责人: jkilpatr
其他贡献者: jaosorior

工作项¶

rsyslog 容器 - jaosorior

rsyslog 模板和部署角色 - jkilpatr

聚合器和存储服务器部署工具 - jkilpatr

依赖项¶

蓝图依赖项

https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog

软件包依赖项

rsyslog, rsyslog-elasticsearch, rsyslog-mmjsonparse

特别是 rsyslog 的第 8 版，这是 rsyslog-elasticsearch 支持的最早版本，这些版本已打包在 Centos 和 rhel 7.4 extras 中。

测试¶

可以通过在任何现有的 CI 作业期间部署它来在 CI 中测试日志聚合。

为了进行额外的验证，请编写一个脚本来检查 Elasticsearch 中的输出。

文档影响¶

需要编写文档，介绍各种日志记录模式和可调参数以及如何部署它们。还需要提供有关日志存储系统和聚合器大小调整的建议（如果需要）。

参考资料¶

https://review.openstack.org/#/c/490047/

https://review.openstack.org/#/c/521083/