基于spark之上的即席分析-日志分析场景

YDB 场景精选之运维日志、 业务日志、 交易流水日志的搜索与分析

通过方便灵活的日志搜索分析，帮助用户及时发现问题

统一日志查询平台，程序故障定位平台

开发与运维人员经常需要登录线上生产系统， 通过 grep、 tail、 more、 cat 等命令去生产系统里查找故障原因， 排查效率很慢。 且在生产系统运维人员因错误的使用调试命令导致生产系统宕机的情况路见不鲜。

组建一个统一的日志查询管理平台非常重要， 开发人员可以像使用百度那样在日志平台里快速的检索与分析日志，快速定位问题。 日志分析与生产系统分离，即保障了生产系统的安全， 也省去了登录服务器的操作， 提高了运维的效率与质量。

一个大型的系统， 会有多种不同的业务子系统，这些系统的日志散落在不同的机器的每个角落。在统一日志查询平台可以跨越多个业务子系统进行日志的关联分析， 对业务整体进行全局分析。

交易流水搜索

物流系统，网站，运营商，证券交易所，零售商每天有大量的销售，访问日志。 会有客户投诉扣费不准确，或者账户资金丢失的问题，需要客服人员对这些日志进行分析、过滤、筛选 从而追踪真实的扣费细节，在那个环境支付出现了异常，如果账户被盗，资金最终流向了哪里，尽量减少用户的损失。

核心功能根据关键词， ID、时间等快速定位日志

1. 系统问题定位 排查系统故障

2. 根据日志分析，系统性能与网络瓶颈

3. 如果用户投诉可以通过交易号定位用户交易日志，定位哪个环节的支付出现异常

数据量太大，检索成难题

现如日志分析已经不是什么新鲜事，但是数据量特别庞大，普通的传统数据库已经承受不了这么大规模的日志存储，就更别提日志分析了。以笔者成有幸在在腾讯工作期间，研发并设计了腾讯的Hermes 系统， Hermes 当时每天存储的日增量为每天 3600 多亿（截止去年 16 年 10 月，为每天 7000亿），总的数据存储量在万亿规模。

 

转载于:https://my.oschina.net/u/3325078/blog/852744