关闭

关闭

关闭

封号提示

内容

首页 海量日志分析系统实践.ppt

海量日志分析系统实践.ppt

海量日志分析系统实践.ppt

上传者: 小水一滴 2012-04-02 评分 0 0 0 0 0 0 暂无简介 简介 举报

简介:本文档为《海量日志分析系统实践ppt》,可适用于IT/计算机领域,主题内容包含基于MySql的日志分析系统设计基于MySql的日志分析系统设计                     漆兴beidougmailcom主要内容主符等。

基于MySql的日志分析系统设计基于MySql的日志分析系统设计                     漆兴beidougmailcom主要内容主要内容日志分析系统查询需求分析访问特点分析基于性能考虑的系统体系架构基于需求的mysql优化及表设计基于需求的memcache使用其他开源工具的使用总结系统简介系统简介分析各大产品线的访问情况以图形和图表的方式提供各种监控及访问信息为决策者提供可靠的数据支持系统目前支持的分析指标有Hits、带宽、UIP(独立用户IP)、下载速度、下载时长、响应时间、受访URL、受访域名、来路URL、来路域名、全国用户分布统计、运营商分布统计、受访文件大小、文件类型、Squid命中率、请求响应类型、异常用户统计系统基础工作:各业务部门统一web服务器的日志格式系统需求特点系统需求特点海量数据实时性写多读少系统现状:天表每天增量千万级,每天入库上亿条。数据库增量Gwww日志存储增量近TB系统部分需求展示系统部分需求展示系统部分需求展示系统部分需求展示系统整体架构系统整体架构系统架构说明系统架构说明该系统架构根据功能模块可分为如下节点:A(Agent)B(Bee)D(Data)M(Manger)R(Relay)系统执行流程系统执行流程采集节点采集节点功能:负责推送日志到B点实现过程:利用Rsync实现推送以接口方式访问M点获取Rsync的目标地址动作:在每五分钟内切割完日志并推送。每小时获取M点更新的配置完成自更新数据格式:压缩后的统一规范定义的标准日志格式运算节点运算节点功能:根据需求分析日志并推送到D点运算机制:逐行分析日志多进程工具:使用FaceBook的HipHop加快运算速度频率:每两分钟调度分析脚本分析结果:保存为文本格式为sql语句。如insertintotablevalues(),(),()Relay点Relay点存在的意义:保障数据传输的速度及效率减少网络问题导致的数据阻塞及不完整性问题重现:电信和网通之间的互相访问问题导致日志传输丢失或不能在规定时间内到达指定节点解决方法:电信服务器访问电信网通服务器则访问网通数据节点数据节点功能:负责将接收到的sql文本入库动作:在每两分钟运行入库脚本。每天定时创建分钟表(m表)每小时将分钟表中过去一小时的数据聚合,即h表每天聚合前一天的小时表数据即天表d以及触发器及存储过程的调用。将最近三天的分钟表最近三个月的小时表定义为热数据并定期创建为merge类型方便程序的编写。展示节点展示节点数据访问接口:通过增加数据中心层来封装对数据库及缓存等数据的读取方便程序员编写代码减少业务逻辑数据库代理:Amoeba展示方式:图形报表Flash使用工具:MysqlPhpAmoebaFushionchartApacheMemcache等管理节点管理节点功能:掌握各大节点的系统运行状况资源使用情况任务列表:负责管理调度系统其他节点,管理各节点的Rsync地址分析B点的运算结果健康检查日志传送数据的完整性及过期信息处理等工作工具:Gearman好处:Gearman使任务的分发变的更加灵活避免登录多个节点获取信息提高运维效率,方便多服务器管理。Gearman介绍Gearman介绍Gearman流:Client:请求的发起者Job:请求调度人负责把Client的请求转发给相关的WorkerWorker:请求的处理人Gearman实例Gearman实例具体实例:在各大分析点起守护进程workerphp监听指定的端口在M点命令行下运行clientphpcmd来执行各种工作cmd相关安全性检查数据节点瓶颈分析数据节点瓶颈分析Vmstat下bowa的值都很大磁盘随机访问量大IO瓶颈:insert频繁且量大造成磁盘写IO增大cpu瓶颈:sum,orderby,groupby操作比较多cpu容易出现瓶颈select:量大sendingdata比较耗时索引失效全表遍历造成磁盘读IO量大造成读等待累积伤害值:cpu过度使用造成大量进程的等待系统响应变慢进程数累积增加导致内存使用增加内存耗尽则导致虚拟内存的使用最终又导致磁盘IO和cpu的超负荷使用其他系统开销增多系统平衡被打破数据节点展示相关数据节点展示相关表引擎:使用MyISAM,Memory表操作:多为insert无delete,updateQuery分析:Select操作及sum,avg,groupby,orderby,limitWhere定向:多为时间粒度及产品线等多角度混合查询。时间粒度:最近五分钟,最近一小时最近小时等查询条件:按产品线,运营商城市机房服务器数据节点表的设计数据节点表的设计考虑到需求上涉及到的操作时间相关,如最近五分钟最近一天最近一小时等,从数据库中读取的数据大且更新频繁所以采用按时间拆表及对时间建立索引的方案,使用引擎MyISAM具体如下:对各种时间粒度建立索引应对复杂的组合查询按天小时每五分钟(一天个点)建立索引。采用整形如选择年月的个五分钟,whereminf=,这种方式虽然增大了字段长度但是对索引的查找及索引的基数的扩大都是有帮助的属于用空间换时间。使用分区特性在每天建立的m分钟表中按小时建子分区在MyISAM表中尽量使用定长类型数据节点表的设计续数据节点表的设计续将IP字段存储为整形大数据量表按时间拆表规范表命名mwwwtoprefere,h,d使用merge表对于过期的只读表进行myisampack使用enum使PROCEDUREANALYSE()根据业务需求将产品线及时间建立联合索引数据节点的优化Mysql架构优化数据节点的优化Mysql架构优化增加数据库节点按产品线分库按时间拆表数据节点的优化单D点的优化数据节点的优化单D点的优化瓶颈:磁盘IO优化方式:初期:将m,h,d表的索引文件及数据文件分布到不同磁盘将数据库指向不同的磁盘禁止系统更新文件的atime属性数据节点的优化单D点的优化数据节点的优化单D点的优化瓶颈:磁盘IO是主要问题优化方式:硬件升级后期:操作系统及文件系统调优raid或lvm条带化修改相关mysql参数sql语句的慢查询分析及索引调优数据节点的优化单D点性能分析数据节点的优化单D点性能分析没优化前:负载比较高时常会超过CPUIdle经常会小于有时Idle为CPUiowait比较大优化后:CPU的负载降了一半左右同时磁盘写入性能比之前提升了一倍之多数据节点的优化特殊需求优化数据节点的优化特殊需求优化使用tmpfs作cache磁盘(ramdisk)优点:内存操作没有磁盘IO消耗不用修改应用程序缺点:cache空间有限Mount–binddevshmvarwwwcache写一个清cache的脚本程序配置在cron中每小时执行一次检查devshm的使用率超过时使用find命令找出太旧的cache文件删除掉数据节点的优化infobright使用数据节点的优化infobright使用采用开源ICE版进行相关日志分析将涉及到跨天及跨小时的非实时数据导入到infobright充分利用列数据的特点提搞了select速度及减少了预处理的量和相关统计报表工作效果:千万级表包含sum,groupby,orderby操作ICE比MyISAM快几倍数据节点的优化infobright特点数据节点的优化infobright特点列存储适合范围查询及群组操作查询高效服务形式及接口跟mysql一样学习成本低高压缩比列减少磁盘空间无需建索引避免索引的维护及增长问题缺点:ICE版无DML操作但支持loaddatainfile数据节点的优化硬件数据节点的优化硬件Scaleup方案目的:增大系统的IO吞吐量Raid或LVM条带化数据节点的优化Mysql应用优化数据节点的优化Mysql应用优化适当的数据冗余尽量避免数据库的join操作几个时间段对比操作使用union的效率高于in和or的连表操作对热数据进行预处理,避免用户引发计算,所有计算结果尽可能提前生成,后台程序生成结果>直接调用频繁更新的表使用Memory表对于不定长的字段类型可指定前缀长度MySQL参数设置MySQL参数设置提高readbuffersize的值高并发插入优化Concurrentinsert=delaykeywritebulkinsertbuffersize,maxallowedpacket关闭querycachekeybuffer及keybuffersize的值增大sortbuffersize并不是越大越好加大maxlengthforsortdata,对于bigresult让其采用改进版的排序算法MySQL相关设置MySQL相关设置增大tmptablesize增大tablecache及threadcache的值避免频繁建立和断开链接用mysqlunbufferedquery取代mysqlquery,用mysqlpconnect取代mysqlconnect使用SQLBIGRESULT来提示mysql优化引擎更好的处理大数据量sql使用MyISAM表可使用索引数据的预加载功能数据节点的优化多D点的架构数据节点的优化多D点的架构展现层向Proxy发起Query请求Proxy将请求分发到多个DB然后将结果合并后返回当单个Proxy负载过高的时候可以启用多个Proxy展现层通过简单的取模来连接不同的Proxy数据节点的优化多D点的设计数据节点的优化多D点的设计启用多个D点(比如分静态池和动态池)单独产品线的从某个D点取数据跨产品线的时候从多个D点取数据并进行合并。测试了如下方案:基于php的MysqlndAmeoba多D点方案测试:mysqlnd多D点方案测试:mysqlnd如图:mysqlnd少了从mysql驱动中复制数据到php扩展这一步。更亮的特点是:异步获取数据的能力多D点方案测试:mysqlnd多D点方案测试:mysqlnd吸引力:除了性能上的提升,mysqlnd支持异步获取数据困难:需要改动应用层的取数据函数因为之前这部分代码不统一所以需要改动不少从测试来看异步取多个数据库的结果时可能会出现返回数据不正确以及执行顺序错误等状况(怀疑是和Apache在一起使用的问题CLI下正常)多D点方案测试:Amoeba多D点方案测试:AmoebaAmoeba测试结果:支持高可用性负载均衡。对多数据库读取的结果只是分别执行然后直接拼接 高并发情况下有时会出现到Amoeba的连接无响应高版本下高并发的性能表现已经改善不少数据节点的优化结果数据节点的优化结果通过上面几个方案的测试,架构调整选择AmoebaProxy是目前比较合适的方案数据切分可以通过XML灵活配置对应用层的改动比较小也相对比较稳定由于磁盘做radio对数据的保护不够所以要加入备份的考虑及产品线增多后数据缓存的利用率数据节点的优化缓存数据节点的优化缓存Memcache客户端缓存数据页面静态化Php级opcode缓存xCache数据节点的优化Memcache数据节点的优化Memcache数据点的优化Memacahe应用数据点的优化Memacahe应用memcache有m限制。如果列表太大,采取拆分数据用key特殊标识来保存整个序列。在获取的时候批量get来一次性得到这个列表。预处理:提前生成需求数据到cache中写库:进行数据的预处理,写入到memcache服务器中读库:根据时间选择应该已在cache中的数据最近生成的数据拼成最新数据展现缺点:维护多个存储操作增加了应用层逻辑复杂度优点:减少从数据库读取海量数据的问题及避免重复计算数据节点的优化Memache应用优化数据节点的优化Memache应用优化Memcache自重启deamontools监控程序让其在挂掉时重启开启数据压缩功能$memcache>setCompressThreshold根据数据量大小修改slab及factor的值提高内存利用率使用类似getmulti方法发送请求减少客户端和服务端的通信使用到的工具使用到的工具Gearman用于分布式节点的管理Memcached缓存数据Amoeba展示层数据库代理PhpFACEBOOK的HIPHOPINFOBRIGHT的ICE版总结对业务需求了解透彻是技术架构的基础标准化减少错误的发生根据业务形态、网络情况选择适合的技术架构方案用合适的数据库做适合的事情以组分布,各组之间架构一致便于横向扩展及管理最大化减少客户端到网络端的网络延时为系统中不同应用选择适合的硬件根据情况选择开发环境、开发语言及工具等总结谢谢

用户评论(0)

0/200

精彩专题

上传我的资料

每篇奖励 +2积分

资料评价:

/45
1下载券 下载 加入VIP, 送下载券

意见
反馈

立即扫码关注

爱问共享资料微信公众号

返回
顶部