【AICon】 如何构建高效的 RAG 系统?RAG 技术在实际应用中遇到的挑战及应对策略?>>> 了解详情
写点什么

亿级业务日志系统演变过程

  • 2019-05-24
  • 本文字数:3163 字

    阅读完需:约 10 分钟

亿级业务日志系统演变过程

当线上出现问题时,我们可能无法快速准确的排查定位问题。为了解决这个问题,我们建立了一套业务日志系统。

痛点

你是否遇到过如下情况:线上偶尔出现一个问题,但我们并不能快速准确的排查定位该问题!


为了解决这个问题,快速准确的排查定位问题,我们建立了一套业务日志系统。

业务日志系统模块

我们业务日志系统模块主要分 4 个模块:


  • 日志集中查询

  • 业务编码配置

  • 日志异步记录

  • 日志存储

日志集中查询

由于你没有线上环境的权限,所以还需要运维帮你取一些日志。通常情况下,你是无法知道具体执行方法的代码位于集群中的哪台机器上,可能需要一台一台登录进行查询。为了避免这种情况,我们需要把所有日志统一到一个地方,提供统一的查询入口,供相应人员进行查询。



备注:登录系统,时间范围为当前时间-3 天 到当前时间 默认仅需要输入搜索条件即可进行搜索查询,如果需要调整时间,选择相应时间即可。

业务编码配置

由于每一个业务逻辑不一样,需要处理的数据也不一样,我们定义了一个下面类似的页面,每新加一个业务处理,添加一个业务,需要设置相应位置的字段的内容。



备注:定义完这个业务编码之后,我们输出的时候会在每个字段前面加上相应的解释,比如 ip 地址:123.145.33.25,而不是一些没有解释的直接输出的内容。

日志异步记录

如果记录日志慢,就会影响正常的业务流程,那么这个记录就是失败的!所以记录日志必须要走异步。


这里经历了 3 个大版本的演变,后续慢慢说明!

日志存储

对记录的日志进行处理,存储到相应地方,提供接口供统一查询进行调用。


这里也经历了 3 个大版本的演变,后续慢慢说明!

那些坑和演变过程

演变的过程,在我看来就是不断挖坑、填坑的过程!


上面提到业务日志系统的 4 个模块分别是:


  • 日志集中查询

  • 业务编码配置

  • 日志异步记录

  • 日志存储


其中关于日志异步记录、日志存储经历了一些坑,下面我们分别来谈谈。

日志异步记录的坑和演变过程

我们写一个通用工具类,通过在业务代码中间穿插发送日志代码



调用 sendMessage 方法发送日志如下:


String[] param = { ip, operStatus, result, errorMessage, userId,……等等的一些其他参数 };MessageLogsTempate.sendMessage("123456", param);
复制代码


sendMessage 内部实现日志异步记录经历了三个过程:


  • 走 activemq 记录日志

  • 走 nginx 记录日志

  • 走队列,异线程取队列走 nginx 记录日志


备注:记录日志的逻辑不能影响正常业务!!!


记录日志的逻辑不能影响正常业务!!!这个也很容易理解,但是我们以前就经历过这个坑。


大概在 2012-2013 年左右,我们当时讨论选择的框架就是走 mq,那样异步不会影响业务。当时就选择了 activemq。


做法思路就是 sendMessage 往 activemq 里面写数据,另外消费者消费 activemq 里面的数据。


思路也很简单,修改做起来也很简单,一直都挺好,有次业务高峰期,忽然整个系统很慢,最后排查定位发现是写 activemq 阻塞了。(具体原因很多,在这里就不详细说明了 )。



使用 activemq 记录日志,出现阻塞,导致影响业务!问题很严重,后来我们就选择了通过走 nginx 记录日志了。


谈谈当时的想法,为什么没有继续选择其他 mq 呢?


  • 时间紧迫,nginx 简单,并且用过 nginx 类似功能。

  • mq 学习成本较大,同时也怕再次遇到类似 activemq 问题 。


由于上面的 2 个原因,最后我们选择了 nginx。



就变成了 sendMessage 方法通过调用 http 发送 nginx。


文件名称都是以小时来生成的,不同的情况会有不同的后缀,处理完成之后会修改文件名为 bak。


下面是测试环境类似日志:



有次我们通宵模拟的时候,发现如果 nginx 服务器特别卡顿的时候,会导致类似 activemq 一样的情况,会阻塞。



所以 sendMessage 方法继续修改:



最终我们的日志发送就变成:



日志发送完全异步,不管什么情况都不会影响业务!!!

日志存储的坑和演变过程

日志存储也同样经历了三个过程:


  • 走 DB 存储

  • 走 solrcloud 存储

  • 走 es 集群存储


现在我们讨论后半段,之前不管是走 activemq 还是后面的异步 nginx 过程,开始的时候我们都是把数据存储在 DB 里。2012-2013 年的时候,数据不是特别多,也没发现特别大的问题,虽然搜索不太方便,但是还是可以搜索的(需要输入业务编码 ,相应属性输入值)



从上图可以发现,搜索不是特别方便,并且各个业务编码之间也不能相互搜索,一次只能搜索一个编码!但是还是可以使用,并且解决了很多问题!随着业务发展,日志越来越多,慢慢的数据入 DB 就跟不上了,就会面临一个问题:有时候一个日志生产了,但需要很久才可以查询的到。所以,我们就开始考虑解决这个问题,将单条插入修改为批量插入,性能提高了 n 倍,勉强做到了:日志产生后,5 分钟内可以处理入 DB。但是还是会有其它问题出现:


  • 查询速度越来越慢!

  • 跨业务编码间的搜索诉求越来越大!

  • 模糊搜索很不理想!


针对这些问题,我们进行了专门的调研,SolrCloud 就进入了我们的视线了,solr 具备高级全文搜索能力:由 Lucene ™提供支持,Solr 可实现强大的匹配功能,包括短语、通配符、联接、分组以及任何数据类型 。


通过对 solr 的研究,我们用 solr 替换掉了 db,从而达到了下面的搜索情况:



不管搜索体验,还是搜索效率,都提高了很多,引入 SolrCloud 算是质的飞跃!并且还具备高亮,通过关键词、人员相关字段都可以进行匹配搜索到,如下:



选择一条记录点击,出现明细如下:



字段的解释名也会出现在行的左侧(这个就是之前配置的业务编码,不同的业务编码对应的字段是不一样的),后面是对应的值!


如果搜索条件在各个编码里面,如下,并且搜索的条件是红色的:



到这里之后,我们如果有什么问题,可以通过搜索这套日志系统,就可以快速准确的排查定位问题。这套系统不仅仅给开发查询问题,在周末、节假日值班的时候,我们的维护也通过可以通过这套系统进行查询,初步定位问题,解决 90%的问题。剩余的 10%的问题再到相应开发人员定位解决,提高了处理问题的响应速度,给用户一个好的体验!


本以为到这里很完美了,那里知道又要经历一波折磨人的时刻!


由于引入了 SolrCloud,业务发展迅速,日志量越来越多,1 天 2-3 亿的日志数据,查询速度在 1s 左右可以返回,但是 SolrCloud 忽然变的不稳定。



很早之前的测试环境


经常出现 SolrCloud OOM,需要重启,每次开发人员、维护人员都在喊:日志查不了!!!每次都需要重启之后补数据,特别节假日,晚上非常麻烦(solrcloud 太复杂当时没有想着看代码解决,曲线解决问题,我们定时 2 小时执行一次 FGC)经过执行 FGC 之后,出现频率问题低很多了,但是偶然还是会出现 OOM。


针对 SolrCloud 的问题很头疼,后来搜索发现 elasticsearch 和 solr 类似,并且互联网很多公司都用的是 es,决定研究下 es,看看是否可以采用!


通过研究 elasticsearch 发现和 solr 基本类似,替代也比较简单,就给替换了。



目前 elasticsearch 运行时间 2 年多了,并没有像 solr 那样的出现过 oom 等情况,非常稳定,这段期间也对 elasticsearch 进行过一些方面的优化(以后可以和大家分享)!


同一份数据多份去向的处理逻辑修改,由于之前我们的日志数据仅仅是流向到了 elasticsearch 集群,而有些数据特定的业务编码数据可能需要入库,有些需要进行大数据 fsdf,或者 redis 或者 kafka 中供大数据那边分析,所以我们对数据处理进行了修改,支持多种去向,并且做到已经有的处理可以立即配置生效。



由于日志系统太好用,记录的越来越多,我们发现有些日志没有必要,所以就对日志进行了分级(借鉴 log4j 的日志级别),这样很多一些低级别日志就不进入 elasticsearch 了。


我们日志的去向也可以根据业务编码进行动态的调整,控制去哪个维度,从而做到了灵活。

总结

这套业务日志系统经历了很多迭代,集合了很多人的智慧,不仅易用好用,而且可以快速准确的定位问题。希望我们做到的这套日志系统能够对读者有所帮助,我们要的不是屌炸天技术,而是稳定可靠易用,未来这套日志系统可能还会继续进行升级。


2019-05-24 11:588703

评论 4 条评论

发布
用户头像
感觉一般,对新技术的敏感度太低了,es出来多久了
2020-12-03 16:44
回复
用户头像
这方案比较特别,为什么不采取离线收集分析log4j打印出来的日志?
2019-05-25 20:34
回复
log4j也可以,只是我们更期待集中式的,方便管理,目前主流的应该慢慢日志都是集中式的了
2019-07-15 16:45
回复
用户头像
最终的意识就是用了 elasticsearch ?
2019-05-24 17:45
回复
没有更多了
发现更多内容

嘉为蓝鲸连续三年荣登中国信创500强!

嘉为蓝鲸

云计算 移动互联网 蓝鲸

从日志入手,基金公司应该这样实现合规!

嘉为蓝鲸

日志 B2C 平台 基金公司

倒计时 2 天!面向未来的开发者服务 Meetup 即将开始,我们在北京等你 ~

OpenAnolis小助手

开源 操作系统 Meetup 龙蜥社区 开发者服务

打造高性能 IaaS 计算架构,百度智能云 DPU 落地实践

Baidu AICLOUD

DPU

设计模式详解之工厂模式

阿里技术

设计模式 工厂模式

Rocksdb原理简介

天翼云开发者社区

存储 存储结构 存储引擎

英特尔Agilex® 7 FPGA R-Tile为网络、云计算等提供高度灵活解决方案

E科讯

人体识别图像技术在智能安防中的应用

来自四九城儿

人体识别图像技术的原理及分类

来自四九城儿

优质财务共享产品的十大特征

用友BIP

财务共享

【深入浅出Maven开发实战】「入门教程系列」带你零基础学习和开发使用Maven开发工具实战指南(实战技术总结)

洛神灬殇

Java maven 入门指南 技术指南

《中国电信天翼云PON SD-WAN技术白皮书》来了,这份技术指南不要错过!

天翼云开发者社区

云计算 云服务

NFT交易所系统开发跨链技术

薇電13242772558

NFT

教你1分钟搞定2小时字幕

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号 5 月 PK 榜

景区共享电动车合作带动景区新消费

共享电单车厂家

共享电动车投放 景区共享电动车 共享电单车厂家 校内共享电动车

AREX:接口自动化回归测试完全指南

AREX 中文社区

Java Agent 自动化测试 回归测试 流量回放

这届企业出海难?亚马逊云科技的出海合作伙伴让你事半功倍!

Lily

ChatGPT与灰色经济:人工智能带来的无限风险

加入高科技仿生人

人工智能 数智化 openai ChatGPT

现在大火的低代码是怎么回事?浅聊低代码

这我可不懂

低代码 应用开发 JNPF

Dummynet简单部署

天翼云开发者社区

IPFW防火墙 服务驱动 Dummynet

i人事谈AI:既要放眼未来,也要专注当下

ToB行业头条

阿里巴巴内部亿级高并发系统架构设计(全彩版小册开源)

架构师之道

Java 高并发

质赢天下,效领未来!FY23嘉为科技年会盛典隆重举行

嘉为蓝鲸

年会 互联网科技 科技公司

亿级业务日志系统演变过程_语言 & 开发_李仁佐_InfoQ精选文章