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

见贤思齐

作者：datonli，腾讯WXG后台开发工程师背景开发在定位问题时需要查找日志，但企业微信业务模块日志存储在本机磁盘，这会造成以下问题：日志查找效率低下：一次用户请求涉及近十个模块，几十台机器，查找日志需要登录机器grep日志文件。这一过程通常需要耗费10分钟以上，非常低效；日志保存时间短：单机磁盘存储容量有限，为保存最新日志，清理脚本周期清理旧日志文件腾出磁盘空间，比如：现网一核心存储7天日志占用了90%的磁盘空间，7天前日志都会被清理，用户投诉因日志被清理而得不到解决；日志缺失：虽然现网保留7天最新日志，但是由于某些模块请求量大或日志打印不合理，我们也会限制一个小时日志打印量，超过阈值后不再保存，比如：现网一核心存储前10分钟打了10G日志达到阈值，后50分钟日志不再保存了，用户投诉因日志缺失无法得到解决。我们希望有这样一个日志系统：存储全量日志：由于ToB业务的特殊性，至少需要保存30天的全量日志（数PB日志量，日志达数万亿条），方便回查日志定位问题；日志快速定位：根据模块+时间段+关键字或用户请求信息快速定位日志；实时性：日志峰值达数亿条每秒，需要做到秒级入库、秒级可查；支持日志模糊匹配和统计：单机日志查询常用到模糊匹配以及awk/uniq/sort等复杂统计，在新日志系统同样希望能够支持；支持模块级全量日志查询：日常运营中有些用户投诉的问题并不确定具体发生时间，需要对模块进行全量日志（日志量达TB级别）查询。业界方案对比公司内外有很多日志系统方案，根据是否对日志做全文检索可以分为两类：全文检索的日志系统：对日志内容切分词和建倒排，通过查询关键词的倒排取交集支持模糊匹配，这类系统一般入库资源消耗较多，也不支持日志统计，典型实现有：ELK、Hermes以及腾讯云日志服务(CloudLogService,CLS)等系统；部分字段检索的日志系统：只对部分字段建索引，支持特定字段的快速检索，入库资源消耗较低，但是这类系统对模糊匹配未能很好支持，也不支持日志统计，不支持模块级全量日志查询，如wxlog、LogTrace等系统。我们新设计的检索系统在资源消耗较小的前提下，很好满足背景所提的所有检索需求。方案设计的考虑保存时间短和日志缺失的问题单机存储空间的限制导致日志丢失，日志也没法长时间保存，如何突破单机存储空间限制呢？嗯，是的，使用分布式文件系统替换单机文件系统就可以了！在可水平扩展的分布式文件系统支撑下，存储空间无限大，日志不再因存储空间而丢失了。日志查找效率低下问题日志查找效率低下，其根源是日志散落到多台机器，需要登录到机器做日志grep。引入了分布式文件系统存储全网日志后，我们看到的仍然是一个一个不相关的日志文件，快速定位日志仍然困难。如何提高日志定位的效率呢？索引！就像是利用索引提升数据库表查询效率一样，我们对日志数据建立索引，快速定位到所需日志。那么，需要构建怎样的索引呢？先看看面临的两种问题定位场景：开发收到模块告警，通过告警信息结合代码找到关键字，使用关键字查找模块告警时间段内的日志；根据用户投诉找到用户请求信息，使用用户请求信息查找所有关联模块的日志。从以上场景看出，我们通常根据模块+时间段+关键字或者用户请求信息查找日志。所以，对模块、时间、用户请求信息建索引提升日志查找效率。入库资源消耗问题为了支持模糊查询，业界方案一般都会对日志内容分词建索引，这会消耗大量资源。日志查询系统有两个特点：每天只有数百次查询请求，日志存储模块（分布式文件系统）IO密集、CPU利用率低。为了支持用户模糊查询请求，入库时不对日志内容分词建索引。用户查询时，日志存储模块使用关键字对日志内容正则匹配过滤（利用本机空闲CPU）。这样既解决了入库资源消耗高的问题，又解决了存储机CPU低利用率的问题。面临的挑战我们通过分布式文件系统和索引解决了目前的问题，同时也带来了新的挑战：高性能：目前企业微信日志量月级数PB，日志数万亿条，天级数百TB，面对如此海量日志，如何做到入库和查询的高性能？可靠性：引入了分布式文件系统以及索引带来更大的复杂性，如何保证整个日志系统可靠性？支持灵活多变的用户查询需求：通过调研发现，用户主要有以下4种日志查询使用场景：a)一次用户请求关联的所有模块日志查询；b)模块一段时间内日志模糊查询；c)模块全量日志模糊查询；d)查询日志统计（如：awk/uniq/sort指令等）。如何支持如此灵活多变的用户查询需求？名词解释在介绍系统前，先对使用的名词进行解释：callid：唯一标识一次用户请求，每条日志中都会携带callid信息；模糊查询：根据用户输入模块、时间段和关键字查询日志；全链路查询：根据callid查询一次用户请求所有关联的模块日志。系统架构企业微信日志检索系统主要分为6个模块：LogAgent：和业务模块同机部署，对模块内日志进行聚集，数据批量写分布式文件系统，callid索引批量发送到LogMergeSvr聚集；LogMergeSvr：对一段时间内的callid索引进行模块间聚集，批量写分布式文件系统；存储模块(分布式文件系统)：存储原始日志数据、时间索引和callid索引数据；LogIdxSvr：对callid索引进行全网聚合，底层存储用的是Rocksdb；WebSvr：接收用户网页请求，并发查询QuerySvr。QuerySvr：查询执行模块，支持全链路查询、模糊查询、awk统计等。接下来分别阐述系统设计和实现中面临的挑战点以及解决办法。如何实现系统高性能日志入库高性能目前，企业微信全网日志入库峰值qps数亿条每秒，而分布式文件系统数据节点仅仅20台（单台12块SATA盘，单盘IOPS约100左右），我们如何使用少量数据节点支撑如此高峰值的日志秒级入库呢？数据入库高性能在模糊查询场景下，用户使用模块/机器+时间段+关键字进行查询。为提升数据入库性能，我们以每台机器的IP作为分布式文件系统的目录，机器上模块打印的日志写入小时粒度的日志文件，这样不同机器写入自己独占的日志数据文件，相互间数据写入无竞争，入库性能最佳。与此同时，目录结构就相当于一个快速区分不同模块/机器的索引，这也能提升日志查询效率。为了进一步提升数据入库性能，LogAgent使用缓冲队列缓存日志数据，累积8MB数据后批量顺序写入日志文件中，写qps降低为原本的4万分之一。同时为了快速查找日志数据，对8MB日志数据的时间戳采样，批量写入同目录下的时间索引文件中。callid索引入库高性能同一callid索引散落在不同模块不同机器，为了全链路查询，需要对数亿条/秒的callid索引做秒级聚合，以支持秒级入库、秒级可查，这无疑是一个技术难题。为了解决这一难题，我们通过三重聚合减少callid索引写入压力，最终达到qps减少到千万分之一、一次IO读取callid所有日志位置的效果：模块内聚合：LogAgent聚合模块内callid索引，批量写入LogMergeSvr，qps约减少到万分之一；模块间聚合：LogMergeSvr聚合模块间一段时间内的callid索引，批量写分布式文件系统，qps约减少到千分之一；全网聚合：callid索引文件不利于高效读取，LogIdxSvr利用Rocksdb的Merge聚合全网的callid索引，一次IO可读取callid所有日志位置。日志查询高性能增加索引提升查询性能开发通常依据模块、时间段、callid这3个维度查询日志，为了加快查询性能也对这3个维度分别增加索引：模块：一个模块包含若干机器，每台机器在分布式文件系统中拥有独占的日志目录（用IP区分），用于保存机器小时粒度日志文件。通过模块找到所有机器IP后，可快速找到该模块的日志在分布式文件系统中的日志目录。时间段：日志数据保存在机器目录的小时粒度文件中，通过对日志时间采样保存为相应时间索引文件。当按照时间段查找日志时，可根据时间索引文件快速找到该时间段的日志位置范围。callid：解析日志建立callid到日志位置的索引，散落在多个模块的callid索引通过LogAgent、LogMergeSvr以及LogIdxSvr三重聚合后，最终存储在LogIdxSvr的Rocksdb中。全链路日志查询可通过读取一次Rocksdb获取所有相关日志位置，快速读取到所需日志。模糊查询高性能原始版本：并发检索WebSvr接收用户模糊查询请求（模块+时间段+关键字），依据模块获取机器列表后，按机器列表并发请求到多台QuerySvr执行机器粒度日志查询：通过机器IP找到机器日志目录，根据时间段拉取时间索引文件，确定日志数据范围，并发拉取日志到本机用关键字做模糊匹配。最终将匹配后的日志返回给WebSvr聚合展示给用户。通过并发检索的优化手段，模糊查询一个模块一小时日志（12台机器，7.95GB日志量）耗时从1分钟降到5.6秒。优化版本：模糊匹配下沉分布式文件系统在系统压测时我们发现QuerySvr带宽和cpu存在性能瓶颈，原因是QuerySvr读取大量未模糊匹配的日志数据，打满了网络带宽，并且在QuerySvr做模糊匹配也会消耗大量cpu资源。我们需要进行性能优化。考虑到分布式文件系统是重IO操作，cpu利用率很低，将模糊匹配逻辑下沉到分布式文件系统，这样既解决了QuerySvr带宽和cpu性能瓶颈问题，又充分利用了文件系统的cpu，避免资源浪费。通过模糊匹配下沉的优化手段，模糊查询一个模块一小时日志（12台机器，7.95GB日志量）耗时从5.6秒降到2.5秒。全链路查询高性能全链路查询和模糊查询类似，同样利用了并发提升查询性能，稍有不同的是全链路查询根据callid读取LogIdxSvr确定日志位置列表，按照位置列表并发读取日志数据，聚合后将日志返回给用户。如何保证系统可靠性我们通过引入了分布式文件系统和索引服务解决了日志丢失、保存时间短和快速定位问题，但系统复杂性导致的可靠性问题，是我们面临的第二大挑战。数据可靠性保证日志数据缓冲队列（共享内存+本机磁盘文件）LogAgent负责将日志数据和时间索引写入分布式文件系统，当分布式文件系统抖动时，为了不丢弃待写日志数据，LogAgent使用缓冲队列（共享内存+本机磁盘文件）缓存日志数据，待抖动恢复后读出缓存数据写入文件系统。索引可靠性保证服务抖动LogIdxSvr使用Rocksdb作为底层存储聚合全网callid索引，但是Rocksdb在高并发写入时容易出现写入抖动进而导致索引丢失，为了保证callid索引可靠性，LogMergeSvr先将callid索引写入分布式文件系统保存，LogIdxSvr从分布式文件系统拉，分布式文件系统当做queue使用起到削峰填谷作用，保证callid索引可靠性。机器坏盘LogIdxSvr出现坏盘会导致已聚合到本机的callid索引数据丢失，新起的LogIdxSvr重新拉取分布式文件系统的callid索引文件，可以重建Rocksdb的callid索引，保证系统可靠性。如何支持灵活多变的用户查询请求通过前面的设计，目前可以根据模块+时间段+关键字或者callid查找到日志了，但是还不够，用户往往还需要对日志做任意维度模糊匹配、日志统计（如：uniq/sort/awk等）以及模块级全量日志查询。支持任意维度模糊匹配如前所述，通过在分布式文件系统实现模糊匹配逻辑，系统支持对日志做任意维度模糊匹配的需求。通过对比，选择性能最优的RE2正则匹配库实现模糊匹配逻辑。支持awk/uniq/sort等统计指令支持统计指令用户不仅需要对日志做模糊匹配，还需要对匹配后的日志执行awk/uniq/sort等统计指令，其中涉及到指令相互嵌套执行，非常复杂，难以调用相关库实现。我们通过子进程调用系统shell支持这一需求。QuerySvr从分布式文件系统拉取日志数据到本机后，子进程shell调用用户传入统计指令处理日志数据，最终结果返回给WebSvr。子进程处理超时父进程将kill掉子进程，防止用户统计任务耗光QuerySvr资源。安全考虑由于用户指令可由用户自定义输入，指令执行的安全问题需要重点考虑。通过两个方法确保执行指令的安全：changeroot：使用Linux的changeroot避免用户指令操作系统重要目录；沙盒限制：使用Linux支持的沙盒隔离技术，只允许执行特定指令。支持模块级全量日志查询——异步任务模块级全量日志查询通常涉及TB级别日志量，因为涉及的数据量过大，查询耗时一般较长，无法给用户提供实时返回，我们通过提供异步任务功能支持这一需求。用户异步任务请求通过WebSvr转发到QuerySvr，为避免QuerySvr宕机导致异步任务丢失，QuerySvr会将异步任务写入一致性锁服务中存储，空闲的QuerySvr会从一致性锁服务抢锁，抢锁成功后执行该异步任务。QuerySvr根据异步任务的模块信息读取机器列表，按照机器列表并发读取匹配的日志数据，按顺序写入本机磁盘中，在查询结束后更新一致性锁服务状态（存储机ip和路径），用户页面刷新会拉取到异步任务最新状态。