网站运维技术与实践之数据采集、传输与过滤

1、采集点的取舍

说到数据分析，首先固然是数据越全面越详细越好。由于这有助于分析得出比较正确的结果，从而作出合理的决策。

1.服务器数据

采集的服务器数据主要围绕着这么几个？

(1)服务器负载

(2)磁盘读写

(3)网卡流量

如何采集这些数据，能够经过zabbix监控获取。

关于zabbix学习，能够参考个人这篇博客:

zabbix学习小结:https://www.cnblogs.com/youcong/p/7887074.html

篇幅虽然很多特别长，可是要点把握的比较好。

 

2.访问日志

访问日志与服务器数据又有何不一样:每条访问日志都是有意义的，并且访问日志一般会在相隔比较久以后被要求重放（由于这时候出现的问题大可能是“偶然”性、不影响服务器自己性能的、难以快速反馈的隐藏Bug,因此在有条件的状况下，应该保留所有的访问日志至少三个月以上）。

记得在上家公司的时候，每隔一段时间服务器都会自动备份最近几天的日志而后传输到专门备份的服务器上。以备不时之需。

 

3.系统日志Syslog

Syslog是介于日志和服务器数据之间的另外一部分。一方面是做为Linux服务器最重要的OS层面的信息集中地，另外一方面Syslog自己做为一种快速传输日志的协议，也常常用于用户应用输出。并由此产生了Syslog-ng、Rsyslog等一系列成规模的Syslog收集分析系统。

这里暂时仅针对Linux自己的Syslog作采样分析介绍。由于大部分状况下，用户程度选择输出到Syslog时，就会针对性地采集分析办法。

对于Syslog协议内容，最权威的天然是RFC文档。涉及Syslog的RFC文档很多，不过最基本并且最重要的内容格式在RFC3164（http://www.ietf.org/rfc/rfc3164.txt）

 

2、收集传输

在实时性要求不是特别高的环境下，一般scp或者rsync定时任务，进行集中收集，是广大Linux运维人员最经常使用的手段。可是一旦有了较高的实时性要求，scp和rsync就不足以很好的完成任务，这时咱们就须要专门的数据传输中间件。

 

1.Rsyslog

Syslog的集中收集，是大规模集群运维中必备的部分。在以往的Syslog介绍中，通常以Syslog-ng和Rsyslog两个系统的出现最为频繁。惋惜Syslog-ng却没有真正成为Syslog的ng-CentOS6中正式替代Syslog出现的是Rsyslog。鉴于Rsyslog已经成为CentOS6的标配，Rsyslog自己也兼容Syslog的配置。

关于Rsyslog安装，建议参考这个网址:https://www.cnblogs.com/redheat/p/7069765.html

 

Rsyslog的模块分布以下:

(1)Input Modules

IM模块是改动最少的，基本上只有File、TCP、UDP、UNIX Socket以及在TCP基础上的TLS和GSSAPI等更安全的协议。

(2)Output Modules

狭义的OM模块，除了最基本的File之外，还有用于中转的FWD，Pipe,Snmptrap，用于存储的MySQL、PgSQL、Libdbi、HDFS、MongoDB等。此外社区还有Redis、ZeroMQ、ElasticSearch和Solr的OM模块补丁。

(3)Parser Modules

这个模块是在5.3.4版本以后新加入的。在以前的Rsyslog中，对Syslog协议格式的解析工做是直接在核心代码中完成，不可变动。不过到目前为止，狭义的概念的PM模块很少，除了RFC解析的意外，只有一个pmlastmsg模块，专门用来解析Syslog中常见的那句“last messages repated in times”。

(4)Message Modification Modules

MM模块其实就是在广义的PM或OM上实现的。目前和Rsyslog代码一块儿分发的MM模块有:Anon模块，用来转换具体的IP地址到A类地址;Normalize模块，用来将Syslog格式的content转换成为CEE/Lumberjack格式，目的也和normalize模块同样，不过由于Lumberjack格式其实就是JSON，因此这个直接就解析为JSON了；Snmptrapd模块，在im的基础上，提供对严重性位数据的替换修改功能。

(5)String Generator Module

SG模块的做用是为Rsyslog的file和forward提供template功能。咱们能够经过template定义本身想要的内容样式。注意这不会影响到Syslog自己的协议信息。

 

2、Message Queue（消息队列）

Syslog虽好，但不是没有缺点，具体以下:

(1)运行在UDP模式下的Syslog是会丢数据的。

(2)即便运行在TCP模式下解决了丢包的问题，Syslog的PRI包括TAG的方式依然没法充分知足大多数状况下对不一样业务不一样数据的隔离需求。

 

这种状况下，消息队列的优点就体现出来了。相似RabbitMQ、ZeroMQ、StoMQ、Q4MQ等，这些已经在业务线上普遍运用的MQ组件，也就顺势进入了运维系统的范畴。

消息队列，是软件工程领域，用以进程间，甚至线程通讯的组件，不少时候都是操做系统或者应用内部在使用。不过咱们这里要说的，是计算机之间、跨网页的、狭义的消息队列中间件。

 

消息队列提供的是一个异步通讯协议，消息生成的一方和消费的一方不要求同步交互，而是将消息内容经过队列来进行转交，也就是说，队列自己就须要具备存储能力。

开源的消息队列中间件有不少，有名的就有，JBoss Messaging、ActiveMQ、Qpid、RabbitMQ、Q4M等等。

 

最先的消息队列中间件，Sun公司的JMS规范只有JAVA的API，可让开发者像写SQL同样使用消息队列，不过目前这种作法再也不主流，当前主流的消息队列中间件标准有三个:

1.AMQP

AMQP和JMS的区别在于，AMQP定义的是以8字节为单位的数据流格式。在AMQP中，数据的基本单位是帧。AMQP中一共有九种帧:open、begin、attach、tranfer、flow、disposition、detach、end和close。

数据传输以attach帧开始，detach帧结束；消息经过transfer帧建连在一个惟一的direction上；flow帧用于管理主题,方便订阅;消息两端的传输状态变化，则经过disposition帧来交互。

上面这5个帧类型都与数据传输相关，其余4个则偏重端点之间的链接。前面说到一个transfer帧是固定在一个direction上的。可是端点和端点之间，能够有多个direction,这些direction合在一块儿叫session,由begin和end帧来控制双向session的初始化和终止。更高一层，多个session,还能够以多路复用的链接形式，各自独立地存在在相同的两个端点之间，这个链接，是由open和close帧控制的。

AMQP的主要实现，有RabbitMQ、Qpid、ActiveMQ等，也是消息队列中间件的主流。

 

2.MQTT

MQTT定义传输的，是遥测型数据，主要用于低带宽的小型设备场合。MQTT的实现中，大多数是IBM等厂商的商业化产品，如WebSphereMQ等。

 

3.STOMP

STOMP是基于文本的消息传输协议。它在TCP层定义了一个相似HTTP的方法，数据传输一共包括十种:

CONNECT、SEND、SUBSCRIBE、UNSUBSCRIBE、BEGIN、COMMIT、ABORT、ACK、NACK、DISCONNECT等。

 

数据传输一样以帧为单位的。不过STOMP的帧，其实就是多行文本。第一行是具体指令名，第二行开始是以Key:value格式存在的headers，和HTTP同样每一个Header一行。

而后一个附加空行后是详细的内容体。最后以一个NULL字符结束。

 

服务器和客户端之间的通讯，则经过另外三种帧完成，它们是MESSAGE、RECEIPT、ERROR。帧格式和数据传输帧格式同样。

 

三种标准的实现都和HTTP工做在同一层面，即TCP基础上。不过也有一些实现，好比Amazon的SQS，是在HTTP协议的基础上完成的。

 

3、日志收集系统框架
做为运维人员，咱们通常均可以经过Shell或者Perl脚原本自动化收集一些信息，我我的用Shell比较多。可是随着数据来源的种类愈来愈多，或者传输后的分析平台愈来愈多，本身动手写脚本会是一件愈来愈不自动化的麻烦事情。这个时候，咱们就须要足够智能的开框架，替代咱们来作这些事情。

事实上，近几年来，各大互联网公司和主要开源组织陆续发布本身的数据收集传输处理框架，好比Storm、KafKa等等。

不过，以上项目大多数由开发人员结合自身环境逐步改进出来的，大多数有如下两个特色，让运维人员难如下手:

(1)使用Java、Scala语言编写。运维人员比较熟悉Python、Perl、PHP等解释性语言；

(2)依赖Hadoop生态环境。这些框架大多须要提供后期的处理分析功能，基本上都采用了HDFS存储数据、Map/Reduce处理、Zookeeper保证高可用的一套解决办法。这致使整个框架结构至关复杂，初始规模也异常庞大，运维成本也比较高。

 

以前我在谈谈运维人员谨慎操做系统环境和管理文章说过，做为运维人员有的时候为了适应将来业务的须要和团队的更好协做有必要了解相关的工做(好比做为运维熟悉开发、测试、产品等等那套),或许在有的朋友看来越界了，可是从我的发展层面看来并无。