天津台新闻云日志优化方案探索

陈春铭

(天津广播电视台 天津300072)

1 新闻云系统

新闻云制作域使用的是Sobey 公司的MCH 1.2版本，该版本包含了前端客户端编辑软件和后台核心服务hive。通过运行时期的积累摸索，已经基本掌握了其核心组织架构及各模块功能原理，在日常工作中服务出现问题时能够及时判断和解决，并结合实际应用对节点和服务进行相应的改进和扩容。一方面解决了网内服务bug，另一方面提高了系统性能。目前Sobey 已经推出了MCH 2.0 版本，并建议1.2 升级到2.0 以提升系统稳定性，但是该版本在友台实际运行中会产生新问题，比如核心服务和客户端时间一旦有误差可能会影响整个制作。综合考量认为，天津广播电视台暂不升级，继续使用原版本，在此基础上深入排查网内潜在隐患，结合以往经验，重点关注资源性能参数，最大程度提高系统稳定性，保障新闻安全播出。

系统的稳定运行，离不开日常对资源的维护，包括内存、CPU、磁盘使用率等。内存和CPU 可以通过定期重启释放资源，而磁盘空间的增长变化，除了系统软件自身数据外，有一大部分是由日志记录造成，当日志文件不断增长，磁盘空间占用过多，写日志的速度和性能也会随之下降，严重的会导致系统或服务崩溃，因此深究新闻云相关日志是重中之重。

2 日志管理

日志也可称为Log，是指系统所指定对象的某些操作和其操作结果按时间有序的集合，日志记录构成了一个日志文件，它记录了系统运行中的重要信息，方便出现问题快速分析判断，同时需要对日志进行及时清理，来保证正常信息记录和系统稳定运行。对于日志处理目前主要有3 种方式。

2.1 手动清理

由于日志种类较多，记录信息不同，作用也不同，在手动删除之前，需要确定哪些可删除，哪些不能删除，对于重要的日志应当进行备份。对于复杂系统而言，手动删除工作量繁重，而且也会有误删除风险。例如新闻云MySQL 数据库归档日志采用手动删除，按月保留。

2.2 修改日志输出级别

日志输出分为多个级别，如DEBUG＜INFO＜WARN＜ERROR＜FATAL，每个级别输出信息不同。新闻云核心服务多采用Log4j 日志记录工具，程序会打印高于或等于所设置级别的日志，因而根据需求设置合适的级别，会减少日志打印，降低日志空间。但是并不是设置越高越好，新闻云中由于hive 各服务关联性强，对于某些服务需要输出全信息，方便分析问题。

2.3 自动清理

按照需要对服务配置自动删除策略，一是按照时间删除，保留N 天前的日志，二是按照大小删除，也可以采用日志管理工具如logrotate 对日志进行定期切割。相比手动，自动清理更加有效和可靠。新闻云核心服务大多采用自动删除方式，参数配置要根据运行情况进行改进，实现最优化。

3 新闻云日志优化实例

3.1 新闻云主要日志分类

新闻云后台核心是hive，应用服务部署在8 台Linux 虚拟机上，主要有两种日志。一是虚拟机系统日志，该日志默认存放在/var/log/下，记录系统有关事件和信息。系统日志采用logrotate 进行管理，它是一个强大的日志管理工具，基于cron 对日志进行轮循、压缩以及删除旧的日志文件，是系统自动完成的。二是应用服务日志，统一挂载存放到sobeyhive/log，记录hive 各服务运行信息。同时sobeyhive 目录下还存放着应用服务app 及数据文件data。Kafka 服务比较特殊，日志输出到data 文件。由于日常工作通过df-h发现各节点系统空间及前5 个核心节点应用数据空间不足，具有很大安全隐患。使用du -h - -max-depth＝1查出是Linux 系统和应用服务Kafka 日志过大导致，故需要对二者及时进行处理。

3.2 系统日志

系统日志文件偏大，有些节点的message 日志文件已经超过10 G。由于该日志占用系统空间，若不及时清理，会造成系统空间不足进而导致该节点应用服务响应缓慢，或无法对外提供服务，严重时会引起系统崩溃或重启，如果集群中超过半数服务器发生该故障，那么整个集群就会瘫痪。按照logrotate 配置，正常情况下每周自动对日志进行切割，并保留4 个备份，但是多个文件例如message、secure 超过一周没转储，日志轮循没有生效。后经排查发现系统日志配置文件syslog 中参数设置错误如图1，在获取root 权限时，只设置了root 用户，没有设置组，该值缺省配置时会出现如下报错，从而造成了日志转储失败。解决方法：使用sed 行编辑器对节点配置文件进行统一更改。

图1 参数设置报错Fig.1 Parameter setting error

①sed -i '/^su/d' /etc/logrotate.d/syslog 将开头是su 的行删除。

②sed -i '1isu root root' /etc/logrotate.d/syslog 在第1 行插入su root root，添加组配置，使用root 用户root 组收集514 端口的syslog 日志。

③重新检查配置文件 logrotate/etc/logrotate.d/sys-log，确认没有报错后，触发配置使其生效logrotate /etc/logrotate.conf，最后重启日志服务systemctl restart rsyslog。

查看/var/log 下日志文件大小，恢复正常。相比维护前，清理了大约14 G 日志，如图2。系统空间得到了释放。

图2 转存前、后的空间比较Fig.2 Comparison of space before and after storage

3.3 应用服务Kafka日志

Kafka 日志过大，使得核心服务节点的应用数据盘空间使用率达到75%，随着时间的推移，数据还在不断增长中，由于hive 核心服务及数据都保存在此盘，若空间不足，虽然不会影响操作系统，但是单个节点应用服务会出现响应缓慢或者无法对外提供服务，一旦有3 个及以上核心节点出现此问题，那么整个集群就会崩溃。另外底层数据库文件都在此盘上，可能会造成数据库无法写入新数据，整个业务系统完全不能服务。

Kafka 是基于zookeeper 协调的分布式消息服务，也称为消息队列，能够实时处理大量数据，为整个平台提供消息订阅功能，具有高吞吐、低延迟、高并发特点。它的日志删除策略有两种：一是按照一定策略删除不符合条件的日志分段(包括时间和大小)；二是对日志进行压缩，对每个消息的key 进行整合。Kafka 包含多个topic，把topic 中一个partion 大文件分成多个小文件段，然后通过多个小文件段，定期从系统删除。新闻云中每个topic 只有一个partion。但是发现有的分段日志文件无法自动删除，导致占用空间越来越大。查看配置文件，没有异常。

log.cleanup.policy＝delete //日志清理策略

log.retention.hours＝168 //日志保存时间为7 天

log.cleaner.enable＝true // 开启日志删除功能

通过脚本get_kafka_topics_info.sh 查看topic 信息，发现个别队列清理策略为compact 压缩模式，如图3，这表明该队列日志会一直保留，7 天删除策略不会对其生效。但若一直保留就会造成空间不断增加，因而需要对配置参数进行优化，将删除策略是compact 的topic 队列设置为delete 模式。

图3 清理策略参数Fig.3 Cleaning policy parameters

解决办法如下：

在每个节点执行delete_kafka_topics_config.sh，该脚本会删除compact 配置，使topic 队列清理策略都成为delete 模式，然后重启kafka 集群，执行完成后，系统开始清理过期的kafka 日志文件，应用数据空间得到了释放。

相比维护前，每个节点大约删除了100 G 的日志，sobeyhive 磁盘空间使用率降低了25%左右，如图4。

图4 清理前、后的空间比较Fig.4 Comparison of space before and after cleaning

4 结 语

日志是把“双刃剑”，一方面它能够为系统维护、优化改造提供信息辅助，另一方面它也能够成为系统运行的安全隐患。在实际工作中，要重点关注日志的变化，根据网络的运行和实际需求，优化日志参数配置，尽可能减少空间的占用。