企业微信万亿级日志检索系统.docx
《企业微信万亿级日志检索系统.docx》由会员分享,可在线阅读,更多相关《企业微信万亿级日志检索系统.docx(13页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、企业微信万亿级日志检索系统datonli腾讯WXG后台开发工程师背景开发在定位问题时需要查找日志但企业微信业务模块日志存储在本机磁盘这会造成以下问题日志查找效率低下一次用户恳求涉及近十个模块几十台机器查找日志需要登录机器grep日志文件。这一经过通常需要消耗10分钟以上非常低效日志保存时间短单机磁盘存储容量有限为保存最新日志清理脚本周期清理旧日志文件腾出磁盘空间比方现网一核心存储7天日志占用了90%的磁盘空间7天前日志都会被清理用户投诉因日志被清理而得不到解决日志缺失固然现网保存7天最新日志但是由于某些模块恳求量大或者日志打印不合理我们也会限制一个小时日志打印量超过阈值后不再保存比方现网一核心
2、存储前10分钟打了10G日志到达阈值后50分钟日志不再保存了用户投诉因日志缺失无法得到解决。我们祈望有这样一个日志系统存储全量日志由于ToB业务的特殊性至少需要保存30天的全量日志数PB日志量日志达数万亿条方便回查日志定位问题日志快速定位根据模块时间段关键字或者用户恳求信息快速定位日志实时性日志峰值达数亿条每秒需要做到秒级入库、秒级可查支持日志模糊匹配以及统计单机日志查询常用到模糊匹配和awk/uniq/sort等复杂统计在新日志系统同样祈望可以支持支持模块级全量日志查询日常运营中有些用户投诉的问题并不确定详细发生时间需要对模块进展全量日志日志量达TB级别查询。业界方案比照公司内外有很多日志系
3、统方案根据是否对日志做全文检索可以分为两类全文检索的日志系统对日志内容切分词以及建倒排通过查询关键词的倒排取交集支持模糊匹配这类系统一般入库资源消耗较多也不支持日志统计典型实现有ELK、Hermes和腾讯云日志效劳(CloudLogService,CLS)等系统局部字段检索的日志系统只对局部字段建索引支持特定字段的快速检索入库资源消耗较低但是这类系统对模糊匹配未能很好支持也不支持日志统计不支持模块级全量日志查询如wxlog、LogTrace等系统。我们新设计的检索系统在资源消耗较小的前提下很好知足背景所提的所有检索需求。方案设计的考虑保存时间短以及日志缺失的问题单机存储空间的限制导致日志丧失日
4、志也没法长时间保存怎样打破单机存储空间限制呢嗯是的使用分布式文件系统交换单机文件系统就可以了在可程度扩展的分布式文件系统支撑下存储空间无限大日志不再因存储空间而丧失了。日志查找效率低下问题日志查找效率低下其根源是日志散落到多台机器需要登录到机器做日志grep。引入了分布式文件系统存储全网日志后我们看到的仍然是一个一个不相关的日志文件快速定位日志仍然困难。怎样进步日志定位的效率呢索引就像是利用索引提升数据库表查询效率一样我们对日志数据建立索引快速定位到所需日志。那么需要构建如何的索引呢先看看面临的两种问题定位场景开发收到模块告警通过告警信息结合代码找到关键字使用关键字查找模块告警时间段内的日志根
5、据用户投诉找到用户恳求信息使用用户恳求信息查找所有关联模块的日志。从以上场景看出我们通常根据模块时间段关键字或用户恳求信息查找日志。所以对模块、时间、用户恳求信息建索引提升日志查找效率。入库资源消耗问题为了支持模糊查询业界方案一般都会对日志内容分词建索引这会消耗大量资源。日志查询系统有两个特点每天只有数百次查询恳求日志存储模块分布式文件系统IO密集、CPU利用率低。为了支持用户模糊查询恳求入库时不对日志内容分词建索引。用户查询时日志存储模块使用关键字对日志内容正那么匹配过滤利用本机空闲CPU。这样既解决了入库资源消耗高的问题又解决了存储机CPU低利用率的问题。面临的挑战我们通过分布式文件系统以
6、及索引解决了目前的问题同时也带来了新的挑战高性能目前企业微信日志量月级数PB日志数万亿条天级数百TB面对如此海量日志怎样做到入库以及查询的高性能可靠性引入了分布式文件系统和索引带来更大的复杂性怎样保证整个日志系统可靠性支持灵敏多变的用户查询需求通过调研发现用户主要有以下4种日志查询使用场景a)一次用户恳求关联的所有模块日志查询b)模块一段时间内日志模糊查询c)模块全量日志模糊查询d)查询日志统计如awk/uniq/sort指令等。怎样支持如此灵敏多变的用户查询需求名词解释在介绍系统前先对使用的名词进展解释callid唯一标识一次用户恳求每条日志中都会携带callid信息模糊查询根据用户输入模块
7、、时间段以及关键字查询日志全链路查询根据callid查询一次用户恳求所有关联的模块日志。系统架构企业微信日志检索系统主要分为6个模块LogAgent以及业务模块同机部署对模块内日志进展聚集数据批量写分布式文件系统callid索引批量发送到LogMergeSvr聚集LogMergeSvr对一段时间内的callid索引进展模块间聚集批量写分布式文件系统存储模块(分布式文件系统)存储原始日志数据、时间索引以及callid索引数据LogIdxSvr对callid索引进展全网聚合底层存储用的是RocksdbWebSvr接收用户网页恳求并发查询QuerySvr。QuerySvr查询执行模块支持全链路查询、
8、模糊查询、awk统计等。接下来分别阐述系统设计以及实现中面临的挑战点和解决方法。怎样实现系统高性能日志入库高性能目前企业微信全网日志入库峰值qps数亿条每秒而分布式文件系统数据节点仅仅20台单台12块SATA盘单盘IOPS约100左右我们怎样使用少量数据节点支撑如此顶峰值的日志秒级入库呢数据入库高性能在模糊查询场景下用户使用模块/机器时间段关键字进展查询。为提升数据入库性能我们以每台机器的IP作为分布式文件系统的目录机器上模块打印的日志写入小时粒度的日志文件这样不同机器写入自己独占的日志数据文件互相间数据写入无竞争入库性能最正确。与此同时目录构造就相当于一个快速区分不同模块/机器的索引这也能提
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 企业 万亿 日志 检索系统
限制150内