前两天我不是发了一篇数据链路追踪的文章嘛,在末尾也遗留了TODO
:运行应用的服务器一般是集群,日志数据会记录到不同的机器上,排查和定位问题只能登录各个服务器查看。
今天来聊聊这个话题。
00、为什么需要分布式日志组件?
在文章正式开始之前,我分享下我以前负责过的一个系统,它的架构如下:
每次当我查问题的时候,我可能能把问题初步定位在逻辑层,但为了能给业务方交代,我需要给证据业务方看(日志信息就是铁证)。
一个请求肯定是被这8台机器内的某一台处理,但具体是哪一台,我不知道。所以,我需要上每台机器上grep
一把日志,然后才能找出对应的日志证明我的分析。
有的时候,可能接入层也需要一起参与进去,就排查一个问题,人都傻了了(翻看日志的时间占用了太久了)。
后来啊,看了同事的骚操作(在item2
编写脚本:快速登录堡垒机(免去输入账号和密码信息),根据应用服务器数量来切割窗口并且切换到对应的日志目录)。说白了就是一键登录多台应用服务器。嗯,这查日志的速度比起以前又快了好多。
再后来,公司运维侧又主力推在Web页面上登录应用服务器(自动登录堡垒机),这能省去编写脚本(支持批量操作)。但从当时的体验上,没有用item2
访问得流畅(总感觉卡卡的)。
不过还有问题,因为我们在很多时候是不知道在info
/warn
/error
哪个文件下。很多时候只能一个一个文件去查,虽然说可以直接通配符一把查,如果日志过大,带来停顿时间也挺烦的。
系统一旦被问到业务问题,查日志的频率实在是太高了。于是我在某个Q规划的时候是想自己把日志信息写入到搜索引擎,顺便学习下搜索引擎的知识。然后这个规划被组内的某个大佬看到了,在底下评论:要不来试试Graylog?
原来组内本身就在维护了一个日志框架,只是我不知道...于是我接入了Graylog
日志,工作效率杠杠提高了,凭借这个事情吹了一个Q。
自从接入了之后,我就没登录过应用服务器了ÿ