日志采集——架构分类

角色

Agent

消息收集点，运行于消息产生源，分为三个角色：

• Adaptor，他从物理文件、sock、unixsock、标准输入等抽取原始消息，处理
• Filter，对不同的消息类型对消息进行不同的格式化，
• Agent，负责将消息传送出去出

从进程模型上可能是三个进程或者一个进程有多个角色

Collector

采集点。汇集某类型消息，对某类型信息集中加工，比如将高频小写改适合HDFS低频大写，输出store。分为两个角色：

• collector，汇集消息
• filter，消息格式化

Store

存储，物理文件，HDFS，数据库，邮件系统，Sock, Prod等。这些跟我们的agent输入是有重叠了，因此在这里再加一个agent，转到下一轮的消息处理逻辑来，以这样级联的方式继续往下处理。

Broker

中介者，这里主要指的是是消息队列。有些agent和collector之间是直连，有些则是通过broker进行消息流动

Manager

中控系统，对消息流调度和节点伸缩控制

消息流

发射型

发起端是collector, 它向Agent端发起信息收集命令，比如func,rpc,http,snmpwalker,shell 命令,然后将得到的结果写入存储。早些年最流行的cacti就是这种方式。这种方式的好处就是架构简单直观，变化点都集中到colletor（易实现，少bug），在collector上配置采集点和采集的要采集的对象。缺点同样明显，异构网络无法工作，无法横向扩展，网络出问题会导致漏采，设计不好时，网络的堵塞和目标机器的宕机都会引起连锁反应。

M2N型

多个Agent根据消息的类型和级别直连一个或多个采集端进行消息推送 ，采集端汇总消息，然后进行持久化、入库、邮件等。部分系统通过manager来进行消息流和节点的管理。这种架构的代表包括了rsyslog,flume,chukwa,scribe等。这种架构支持横向扩展，更复杂的处理流程，消息流量大。

MBN型

类似MTON，Agent和Collector之间不再是直连，而是通过一个消息队列对接起来起来，这样的好处是可以大大简化网络的topology结构，管理信息更加简洁，而且对节点的编程也更加简单,毕竟依赖消息队列的可伸缩性架构比基于级联的简单多，缺点是不适合消息流量太大的场景。使用这种架构包括了Logstash，kafka等。

特性

容错性

节点的容错，就是一个失败了通过调度另外一个补上；通讯通道的容错，根据不同的策略对不同级别和目标的通讯通道做不同的容错机制，先存后发，storeonfail，不存等。

消息的分类分级

像syslog分了十个系统类别和7个用户自定义类别。通过消息的分类分级，我们可以对信息进行差异性的的容错机制，消息分发也可以通过消息的类型进行路由准确推送，比如重要级别的除了入库还要发邮件通知。通过消息的分类分级，我们才可以进行柔性可用、降级服务、系统解耦等设计。

中控中心

随着节点越来越多，网络拓扑越来越复杂，包括业务类型也越来越复杂。中控可以进行消息流调度和节点伸缩管理，必要时可以批量管理节点。减少越多的人工参与，或者参与操作越简单，出错的几率就越小。