一个百亿级日志系统是怎么设计出来的?( 二 )


Yarn 作为计算资源分配管理的容器,会跟不同业务的日志量级,分配不同的资源处理不同日志模型 。
整个 Spark 任务正式运行起来后,单个批次的任务会将拉取到的所有的日志分别异步的写入到 ES 集群 。
业务接入之前可以在管理台对不同的日志模型设置任意的过滤匹配的告警规则,Spark 任务每个 Excutor 会在本地内存里保存一份这样的规则 。
在规则设定的时间内,计数达到告警规则所配置的阈值后,通过指定的渠道给指定用户发送告警,以便及时发现问题 。
当流量突然增加,ES 会有 bulk request rejected 的日志重新写入 Kakfa,等待补偿 。
日志存储
原先所有的日志都会写到 SSD 盘的 ES 集群,LogIndex 直接对应 ES 里面的索引结构 。
随着业务增长,为了解决 ES 磁盘使用率单机最高达到 70%~80% 的问题,现有系统采用 Hbase 存储原始日志数据和 ElasticSearch 索引内容相结合的方式,完成存储和索引 。
Index 按天的维度创建,提前创建 Index 会根据历史数据量,决定创建明日 Index 对应的 Shard 数量,也防止集中创建导致数据无法写入 。
现在日志系统只存近 7 天的业务日志,如果配置更久的保存时间的,会存到归档日志中 。
对于存储来说,Hbase、ES 都是分布式系统,可以做到线性扩展 。
多租户
随着日志系统不断发展,全网日志的 QPS 越来越大,并且部分用户对日志的实时性、准确性、分词、查询等需求越来越多样 。
 

一个百亿级日志系统是怎么设计出来的?

文章插图
 
 
为了满足这部分用户的需求,日志系统支持多租户的的功能,根据用户的需求,分配到不同的租户中,以避免相互影响 。
 
一个百亿级日志系统是怎么设计出来的?

文章插图
 
 
针对单个租户的架构如下:
  • SDK:可以根据需求定制,或者采用天网的 TrackAppender 或 SkynetClient 。
  • Kafka 集群:可以共用,也可以使用指定 Kafka 集群 。
  • Spark 集群:目前的 Spark 集群是在 Yarn 集群上,资源是隔离的,一般情况下不需要特地做隔离 。
  • 存储:包含 ES 和 Hbase,可以根据需要共用或单独部署 ES 和 Hbase 。
现有问题和未来规划
目前,有赞日志系统作为集成在天网里的功能模块,提供简单易用的搜索方式,包括时间范围查询、字段过滤、NOT/AND/OR、模糊匹配等方式 。
并能对查询字段高亮显示,定位日志上下文,基本能满足大部分现有日志检索的场景 。
【一个百亿级日志系统是怎么设计出来的?】但是日志系统还存在很多不足的地方,主要有:
  • 缺乏部分链路监控:日志从产生到可以检索,经过多级模块,现在采集,日志缓冲层还未串联,无法对丢失情况进行精准监控,并及时推送告警 。
  • 现在一个日志模型对应一个 Kafka Topic,Topic 默认分配三个 Partition 。
由于日志模型写入日志量上存在差异,导致有的 Topic 负载很高,有的 Topic 造成一定的资源浪费,且不便于资源动态伸缩 。
Topic 数量过多,导致 Partition 数量过多,对 Kafka 也造成了一定资源浪费,也会增加延迟和 Broker 宕机恢复时间 。
  • 目前 Elasticsearch 中文分词我们采用 ikmaxword,分词目标是中文,会将文本做最细粒度的拆分,但是日志大部分都是英文,分词效果并不是很好 。
上述的不足之处也是我们以后努力改进的地方,除此之外,对于日志更深层次的价值挖掘也是我们探索的方向,从而为业务的正常运行保驾护航 。
 




推荐阅读