一、采集点的取舍
说到数据分析，首先当然是数据越全面越详细越好。因为这有助于分析得出比较正确的结果，从而做出合理的决策。
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）
二、收集传输
在实时性要求不是特别高的环境下，通常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本身的协议信息。
二、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协议的基础上完成的。
三、日志收集系统框架
作为运维人员，我们一般都可以通过Shell或者Perl脚本来自动化收集一些信息，我个人用Shell比较多。但是随着数据来源的种类越来越多，或者传输后的分析平台越来越多，自己动手写脚本会是一件越来越不自动化的麻烦事情。这个时候，我们就需要足够智能的开框架，替代我们来做这些事情。
事实上，近几年来，各大互联网公司和主要开源组织陆续发布自己的数据收集传输处理框架，比如Storm、KafKa等等。
不过，以上项目大多数由开发人员结合自身环境逐步改进出来的，大多数有以下两个特点，让运维人员难以下手:
(1)使用Java、Scala语言编写。运维人员比较熟悉Python、Perl、PHP等解释性语言；
(2)依赖Hadoop生态环境。这些框架大多需要提供后期的处理分析功能，基本上都采用了HDFS存储数据、Map/Reduce处理、Zookeeper保证高可用的一套解决办法。这导致整个框架结构相当复杂，初始规模也异常庞大，运维成本也比较高。
之前我在谈谈运维人员谨慎操作系统环境和管理文章说过，作为运维人员有的时候为了适应未来业务的需要和团队的更好协作有必要了解相关的工作(比如作为运维熟悉开发、测试、产品等等那套),或许在有的朋友看来越界了，但是从个人发展层面看来并没有。