没有合适的资源?快使用搜索试试~ 我知道了~
10年大数据架构师:日访问百亿级,如何架构并优化日志系统?
1 下载量 28 浏览量
2021-01-27
13:48:50
上传
评论
收藏 706KB PDF 举报
温馨提示
试读
13页
日志数据是最常见的一种海量数据,以拥有大量用户群体的电商平台为例,双 11大促活动期间,它们可能每小时的日志数量达到百亿规模,海量的日志数据暴增,随之给技术团队带来严峻的挑战。本文将从海量日志系统在优化、部署、监控方向如何更适应业务的需求入手,重点从多种日志系统的架构设计对比;后续调优过程:横向扩展与纵向扩展,分集群,数据分治,重写数据链路等实际现象与问题展开。有过项目开发经验的朋友都知道:从平台的最初搭建到实现核心业务,都需要有日志平台为各种业务保驾护航。 如上图所示,对于
资源详情
资源评论
资源推荐
10年大数据架构师:日访问百亿级,如何架构并优化日志系年大数据架构师:日访问百亿级,如何架构并优化日志系
统?统?
日志数据是最常见的一种海量数据,以拥有大量用户群体的电商平台为例,双 11 大促活动期间,它们可能每小时的日志数量
达到百亿规模,海量的日志数据暴增,随之给技术团队带来严峻的挑战。
本文将从海量日志系统在优化、部署、监控方向如何更适应业务的需求入手,重点从多种日志系统的架构设计对比;后续调优
过程:横向扩展与纵向扩展,分集群,数据分治,重写数据链路等实际现象与问题展开。
日志系统架构基准
有过项目开发经验的朋友都知道:从平台的最初搭建到实现核心业务,都需要有日志平台为各种业务保驾护航。
如上图所示,对于一个简单的日志应用场景,通常会准备 master/slave 两个应用。我们只需运行一个 Shell 脚本,便可查看是
否存在错误信息。
随着业务复杂度的增加,应用场景也会变得复杂。虽然监控系统能够显示某台机器或者某个应用的错误。
然而在实际的生产环境中,由于实施了隔离,一旦在上图下侧的红框内某个应用出现了 Bug,则无法访问到其对应的日志,
也就谈不上将日志取出了。
另外,有些深度依赖日志平台的应用,也可能在日志产生的时候就直接采集走,进而删除掉原始的日志文件。这些场景给我们
日志系统的维护都带来了难度。
参考 Logstash,一般会有两种日志业务流程:
正常情况下的简单流程为:应用产生日志→根据预定义的日志文件大小或时间间隔,通过执行 Logrotation,不断刷新出新的
文件→定期查看→定期删除。
复杂应用场景的流程为:应用产生日志→采集→传输→按需过滤与转换→存储→分析与查看。
我们可以从实时性和错误分析两个维度来区分不同的日志数据场景:
实时,一般适用于我们常说的一级应用,如:直接面向用户的应用。我们可以自定义各类关键字,以方便在出现各种 error 或
exception 时,相关业务人员能够在第一时间被通知到。
准实时,一般适用于一些项目管理的平台,如:在需要填写工时的时候出现了宕机,但这并不影响工资的发放。
平台在几分钟后完成重启,我们可以再登录填写,该情况并不造成原则性的影响。因此,我们可以将其列为准实时的级别。
除了直接采集错误与异常,我们还需要进行分析。例如:仅知道某人的体重是没什么意义的,但是如果增加了性别和身高两个
指标,那么我们就可以判断出此人的体重是否为标准体重。
也就是说:如果能给出多个指标,就可以对庞大的数据进行去噪,然后通过回归分析,让采集到的数据更有意义。
此外,我们还要不断地去还原数字的真实性。特别是对于实时的一级应用,我们要能快速地让用户明白他们所碰到现象的真实
含义。
例如:商家在上架时错把商品的价格标签 100 元标成了 10 元。这会导致商品马上被抢购一空。
但是这种现象并非是业务的问题,很难被发现,因此我们只能通过日志数据进行逻辑分析,及时反馈以保证在几十秒之后将库
存修改为零,从而有效地解决此问题。可见,在此应用场景中,实时分析就显得非常有用。
最后是追溯,我们需要在获取历史信息的同时,实现跨时间维度的对比与总结,那么追溯就能够在各种应用中发挥其关联性作
用了。
上述提及的各个要素都是我们管理日志的基准。如上图所示,我们的日志系统采用的是开源的 ELK 模式:
ElasticSearch(后简称 ES),负责后端集中存储与查询工作。
单独的 Beats 负责日志的搜集。FileBeat 则改进了 Logstash 的资源占用问题;TopBeat 负责搜集监控资源,类似系统命令
top 去获取 CPU 的性能。
由于日志服务对于业务来说仅起到了维稳和保障的作用,而且我们需要实现快速、轻量的数据采集与传输,因此不应占用服务
器太多资源。
在方式上我们采用的是插件模式,包括:input 插件、output 插件、以及中间负责传输过滤的插件。这些插件有着不同的规则
和自己的格式,支持着各种安全性的传输。
日志系统优化思路
有了上述日志的架构,我们针对各种实际的应用场景,进一步提出了四个方面的优化思路:
基础优化
内存:如何分配内存、垃圾回收、增加缓存和锁。
网络:网络传输序列化、增加压缩、策略、散列、不同协议与格式。
CPU:用多线程提高利用率和负载。
此处利用率和负载是两个不同的概念:
利用率:在用满一个核后再用下一个内核,利用率是逐步升高的。
负载:一下子把八个核全用上了,则负载虽然是满的,但是利用率很低。即,每核都被占用了,但是所占用的资源却不多,计
算率比较低下。
磁盘:尝试通过文件合并,减少碎片文件的产生,并减少寻道次数。同时在系统级别,通过修改设置,关闭各种无用的服务。
平台扩展
做加减法,或称替代方案:无论是互联网应用,还是日常应用,我们在查询时都增加了分布式缓存,以有效提升查询的效率。
另外,我们将不被平台使用到的地方直接关闭或去除。
纵向扩展:如增加扩展磁盘和内存。
横向扩展:加减/平行扩展,使用分布式集群。
数据分治
根据数据的不同维度,对数据进行分类、分级。例如:我们从日志中区分error、info、和 debug,甚至将 info 和 debug 级别
的日志直接过滤掉。
数据热点:例如:某种日志数据在白天的某个时间段内呈现暴涨趋势,而晚上只是平稳产生。我们就可以根据此热点情况将它
们取出来单独处理,以打散热点。
系统降级
我们在对整体业务进行有效区分的基础上,通过制定一些降级方案,将部分不重要的功能停掉,以满足核心业务。
日志系统优化实践
剩余12页未读,继续阅读
weixin_38570519
- 粉丝: 2
- 资源: 975
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0