企业微信万亿级日志检索系统

作者：datonli，腾讯 WXG 后台开发工程师

背景

开发在定位问题时需要查找日志，但企业微信业务模块日志存储在本机磁盘，这会造成以下问题：

1. 日志查找效率低下：一次用户请求涉及近十个模块，几十台机器，查找日志需要登录机器 grep 日志文件。这一过程通常需要耗费 10 分钟以上，非常低效；

2. 日志保存时间短：单机磁盘存储容量有限，为保存最新日志，清理脚本周期清理旧日志文件腾出磁盘空间，比如：现网一核心存储 7 天日志占用了 90%的磁盘空间，7 天前日志都会被清理，用户投诉因日志被清理而得不到解决；

3. 日志缺失：虽然现网保留 7 天最新日志，但是由于某些模块请求量大或日志打印不合理，我们也会限制一个小时日志打印量，超过阈值后不再保存，比如：现网一核心存储前 10 分钟打了 10G 日志达到阈值，后 50 分钟日志不再保存了，用户投诉因日志缺失无法得到解决。

我们希望有这样一个日志系统：

1. 存储全量日志：由于 To B 业务的特殊性，至少需要保存 30 天的全量日志（数 PB 日志量，日志达数万亿条），方便回查日志定位问题；

2. 日志快速定位：根据模块+时间段+关键字或用户请求信息快速定位日志；

3. 实时性：日志峰值达数亿条每秒，需要做到秒级入库、秒级可查；

4. 支持日志模糊匹配和统计：单机日志查询常用到模糊匹配以及 awk/uniq/sort 等复杂统计，在新日志系统同样希望能够支持；

5. 支持模块级全量日志查询：日常运营中有些用户投诉的问题并不确定具体发生时间，需要对模块进行全量日志（日志量达 TB 级别）查询。

业界方案对比

公司内外有很多日志系统方案，根据是否对日志做全文检索可以分为两类：

1. 全文检索的日志系统：对日志内容切分词和建倒排，通过查询关键词的倒排取交集支持模糊匹配，这类系统一般入库资源消耗较多，也不支持日志统计，典型实现有：ELK、Hermes 以及腾讯云日志服务(Cloud Log Service, CLS)等系统；

2. 部分字段检索的日志系统：只对部分字段建索引，支持特定字段的快速检索，入库资源消耗较低，但是这类系统对模糊匹配未能很好支持，也不支持日志统计，不支持模块级全量日志查询，如 wxlog、LogTrace 等系统。

我们新设计的检索系统在资源消耗较小的前提下，很好满足背景所提的所有检索需求。

方案设计的考虑

保存时间短和日志缺失的问题

单机存储空间的限制导致日志丢失，日志也没法长时间保存，如何突破单机存储空间限制呢？

嗯，是的，使用分布式文件系统替换单机文件系统就可以了！在可水平扩展的分布式文件系统支撑下，存储空间无限大，日志不再因存储空间而丢失了。

日志查找效率低下问题

日志查找效率低下，其根源是日志散落到多台机器，需要登录到机器做日志 grep。引入了分布式文件系统存储全网日志后，我们看到的仍然是一个一个不相关的日志文件，快速定位日志仍然困难。如何提高日志定位的效率呢？

索引！就像是利用索引提升数据库表查询效率一样，我们对日志数据建立