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

原文：
简单笔记

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

时间：2010-6-29

系统需求特点：

1、  海量数据

2、  实时性

3、  写多读少

4、  系统现状：天表每天增量千万级，每天入库上1亿条。数据库增量400G

 

系统整体架构

 

采集点A

 

运算点B

 

R

 

D

 

说明：

A   Agent

B   Bee

D   Data

M   Manger

R   Relay

 

日志 ---- 分析运算 --- R点再入库到DB

 

日志：负责推送日志到B点

实现过程：利用Rsync实现推送，以接口方式访问M点获取Rsync的目标地址。

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

 

运算节点

运算机制：逐行分析日志 + 多进程

工具：使用了FaceBook的HipHop加快运算速度

频率：每2分钟做一次（我计算每隔五分钟做一次）

分析结果：保存为文本，格式为SQL语句如INSERT INTO TABLES

 

Relay点

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

数据节点：

功能：负责将接收到的SQL文本入库。

每隔两分钟入库一次脚本。每天定时创建分表（PS：这个有用。到时我们一天创建一个分表即可。到时查询的时候也可以依据这个时间进行查询的。）

 

再建立一个路由表。这样的话依据时间就可以准确知道到哪个表里面去查询数据。

 

然后我们还可以把最近三天的数据再放入到一个merge表聚合表。表示的是最新数据。

 

这个可以放在一个事件任务完成掉。

 

 

展示节点

数据库代理：Amoeba

展示方式：图形 + 报表 + FLASH

 

 

 

数据节点瓶颈分析

1、  Vmstat下的bo  wa 值大表示磁盘随机访问量大。

2、  IO瓶颈：INSERT 量非常大的时候磁盘写IO量大

3、  CPU瓶颈。主要是一些运算量大的操作如SUM、ORDER BY 、GROUP BY 等操作

4、  SELECT：量大的时候SENDING DATA比较花时间。索引失效 读IO非常大

5、  累积伤害值：CPU过度使用造成大量进程的等待，系统响应变慢进程数累积增加，导致

内存使用增加、内存耗尽则导致虚拟内存的使用，最终磁盘IP与CPU超负荷使用。