海量日志分析系统实践,新浪DBA

基于MySql的日志分析系统设计

漆兴beidou77@

主要内容 日志分析系统查询需求分析 访问特点分析 基于性能考虑的系统体系架构 基于需求的mysql优化及表设计 基于需求的memcache使用 其他开源工具的使用 总结

系统简介 分析各大产品线的访问情况，以图形和图表的方式，提供各种监控及访问信息，为决策者提供可靠的数据 支持 系统目前支持的分析指标有，Hits、带宽、UIP(独立 用户IP)、下载速度、下载时长、响应时间、受访

URL、受访域名、来路URL、来路域名、全国用户分布统计、运营商分布统计、受访文件大小、文件类型、 Squid命中率、请求响应类型、异常用户统计 系统基础工作:各业务部门统一web服务器的日志格式

系统需求特点 海量数据 实时性 写多读少 系统现状:天表每天增量千万级,每天入库上1亿条。 数据库增量400G,www日志存储增量近2TB

系统部分需求展示1

系统部分需求展示2

系统整体架构

系统架构说明 该系统架构根据功能模块可分为如下节点 :

A(Agent) B(Bee)

D(Data) M(Manger)

R(Relay)

系统执行流程

采集节点功能：负责推送日志到B点 实现过程：利用Rsync实现推送，以接口方式访 问M点获取Rsync的目标地址

动作：在每五分钟内切割完日志并推送。每小时 获取M点更新的配置完成自更新

数据格式：压缩后的统一规范定义的标准日志格 式

运算节点功能：根据需求分析日志并推送到D点

运算机制：逐行分析日志 + 多进程 工具:使用FaceBook的HipHop加快运算速度

频率：每两分钟调度分析脚本

分析结果：保存为文本，格式为sql语句。如 insert into table values ( ),( ),( )

Relay点存在的意义 :

保障数据传输的速度及效率，减少网络问题导致的 数据阻塞及不完整性

问题重现 :电信和网通之间的互相访问问题，导致日 志传输丢失或不能在规定时间内到达指定节点

解决方法 :电信服务器访问电信，网通服务器则访问 网通

数据节点功能：负责将接收到的sql文本入库 动作：在每两分钟运行入库脚本。每天定时创建分 钟表(m_表),每小时将分钟表中过去一小时的数据 聚合,即h_表，每天聚合前一天的小时表数据，即天 表d_,以及触发器及存储过程的调用。将最近三天 的分钟表，最近三个月的小时表，定义为热数据， 并定期创建为merge类型，方便程序的编写。

展示节点数据访问接口:通过增加数据中心层来封装对数据库 及缓存等数据的读取，方便程序员编写代码，减少 业务逻辑 数据库代理:Amoeba 展示方式: 图形+报表+Flash 使用工具: Mysql5.1+Php5.3+Amoeba+Fushionchart+Apache +Memcache等

管理节点功能: 掌握各大节点的系统运行状况，资源使用情况 任务列表:负责管理调度系统其他节点,管理各节点的 Rsync地址，分析B点的运算结果，健康检查，日志 传送数据的完整性及过期信息处理等工作 工具:Gearman 好处:Gearman使任务的分发变的更加灵活，避免登 录多个节点获取信息，提高运维效率,方便多服务器 管理 。

Gearman介绍Gearman流: Client:请求的发起者 Job:请求调度人，负责把Client的请求转发给相关的Worker Worker:请求的处理人，

Gearman实例具体实例: 在各大分析点起守护进程worker.php监听指定的端 口

在M点命令行下运行client.php cmd 来执行各种工 作cmd 相关安全性检查

数据节点—瓶颈分析1.Vmstat下bo,wa的值都很大，磁盘随机访问量大

2. IO瓶颈:insert 频繁且量大，造成磁盘写IO增大3. cpu瓶颈:sum,order by,group by操作比较多，cpu容易出现瓶颈

4. select:量大sending data比较耗时，索引失效，全表遍历造成 磁盘读IO量大，造成读等待5.累积伤害值:cpu过度使用造成大量进程的等待，系统响应变 慢进程数累积增加，导致内存使用增加，内存耗尽则导致虚 拟内存的使用，最终又导致磁盘IO和cpu的超负荷使用，其他 系统开销增多，系统平衡被打破

数据节点-展示相关表引擎:使用MyISAM,Memory 表操作:多为insert,无delete ,update Query分析:Select操作及sum,avg,group by ,order by,limit Where定向:多为时间粒度及产品线等多角度混合查询。

时间粒度:最近五分钟,最近一小时，最近25小时等查询条件:按产品线,运营商，城市，机房，服务器