Chinaunix首页 | 论坛 | 博客
  • 博客访问: 7093296
  • 博文数量: 3857
  • 博客积分: 6409
  • 博客等级: 准将
  • 技术积分: 15948
  • 用 户 组: 普通用户
  • 注册时间: 2008-09-02 16:48
个人简介

迷彩 潜伏 隐蔽 伪装

文章分类

全部博文(3857)

文章存档

2017年(5)

2016年(63)

2015年(927)

2014年(677)

2013年(807)

2012年(1241)

2011年(67)

2010年(7)

2009年(36)

2008年(28)

分类: 系统运维

2014-04-21 09:36:55

一、采集点取舍
        对于业务数据分析来说,当然是越全面越好,但随之而来的是分析复杂度也水涨船高,所以需要权衡,针对不同的数据来确定采样点。
1、服务器数据
        服务器数据一般会采集到CPU负载、磁盘I/O、网卡流量等。
        这些指标衡量的粒度通常是不一样的,因此,采样频率也应该差异化,比如:
        (1)CPU的平均负载loadavg,输出粒度是1、5、15分钟,因此,采样频率应该要大于或等于1分钟。
        (2)I/O操作,大多数异常都是瞬时操作,采样频率就不能用5分钟甚至15分钟了,这样有可能会漏采。
2、访问日志
        访问日志是Web服务器监控非常重要的途径,因此,建议保留访问日志至少3个月以上,以备排查问题。
        主流的Web服务器都有自己默认的访问日志记录项,比如:Apache的LogFormat、Nginx的log_format。
        访问日志中一般会记录时间、rerfer、url、cookie等信息。
3、系统日志
        Syslog是介于访问日志和服务器之间的另一部分。
        一方面是作为Linux服务器最重要的OS层面的信息集中地,另一方面Syslog本身作为一种快速传输日志的协议,也经常用于用户应用输出。
        Syslog主要用于数据采集,后文还会介绍收集分析系统,当然衍生的Syslog-ng、Rsyslog等也能堪当大任。
        Syslog协议规范参见RFC3164。

二、收集传输
        采集到本地的数据需要收集到数据分析服务器来进行处理。在实时性要求不高的系统中,可以通过scp或者rsync定时任务来进行集中收集,这也是最常用的收集手段。但是如果实时性要求高就需要用专门的数据传输中间件了。
1、Rsyslog
        Rsyslog已经成为CentOS的标准配置,而且兼容Syslog的配置,其处理流程如下:
 
图1 Rsyslog处理流程
        从上图可以看出,Rsyslog主要由以下几部分组成:
        (1)Input Modules:这个模块相对固定,用于接收输入数据,可以基于File、TCP、UDP、UINX Socket等。
        (2)Output Modules:这个模块比较开发,社区有基于MySQL、HDFS、MongoDB、Redis、ZeroMQ、Solr等的支持。
        (3)Parser Modules:这个模块顾名思义是用来解析数据用的。
        Apache和Nginx都支持通过Syslog或者Pipe方式收集数据,只需要做好配置即可。
2、message queue
        消息队里其实也能完成收集任务,甚至更漂亮。
        开源消息队列中间件有很多,重头的有基于AMQP实现的RabbitMQ、Qpid、ActiveMQ,简单高效的有ZeroMQ、Redis,当然还有很多,这里不一一列出。
3、RPC
        在基于RPC协议的设计场景中通常会使用Thirft一类的服务开发框架,用户只需要定义好统一的数据结构,Thirft会自动生成和网络通信相关的代码,而在各自节点上,可以使用绝大多数开发语言,它就像一个水管多用转接头一样。

图2 Thrift整体架构
4、Gearman
        Gearman是一套分布式程序框架,与Hadoop相比其更偏向于任务分发。
        一个Gearman请求的处理过程涉及三个角色:Client->Job->Worker。
        对于Client和Worker并不限制使用一样的语言,所以有利于多语言系统集成。

图3 Gearman处理流程
        在海量日志实时处理方面,Gearman最简单也最常见的一个运用是实时的访问排行,其使用流程如下:

图4 Gearman日志处理流程

三、日志收集系统框架
        比较有名的数据收集传输处理框架有Twitter的Storm、Linkedin的kafka、Facebook的Scribe、Cloudera的Flume和Hadoop的Chukwa等。这些框架总体来说都比较重,接下来会介绍两个简单但功能丰富的类似系统。
1、Flume-ng
        Flume-ng主要包括source、sink和channel三部分。
        Flume-ng依据source与sink和channel的对应关系可以构造集中式日志收集系统,也可以构造日志分发系统,比如:
        (1)当source来自多个源地址或者服务时,sink作为中继,跨越网络一级一级地把数据流串联起来,这就是集中式日志收集系统的典型案例。
        (2)如果是单一的source对应多个channel和sink,那么就可以把一份素具复制到多个目的地址或者服务上,以完成不同目的的分析处理。

2、logstash
        Logstash由JRuby语言编写,与Flume-bg或者Rsyslog类似,Logstash同样由input、filter和output三个部件组成。
        Logstash社区非常活跃,运维人员可以从庞大的插件库中挑选自己熟悉的来搭建系统。
        Logstash最典型的使用场景,是通过Logstash收集应用集群的日志到专用服务器上,并进行过滤和处理。
        只要同时有input和output插件,都可以作为broker运行,官方推荐使用redis来构建,处理模型如下:

图5 Logstash处理流程


阅读(916) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~