Flume_Source_flume 的 syslog source 默认情况下会将 syslog 报文中的各个字段全部解析出

source的生命周期

source被命名为像其他任何部件一样通过配置文件进行配置的组件。配置系统一旦验证通过一个source，就会实例化并且由configurationProvider进行配置。source一旦成功配置，flume的生命周期管理系统将会尝试启动source。只有agent自身停止或被杀死、或者agent被用户重新配置，source才会停止。

Avro Source

Flume主要的RPC Source是Avro Source，Avro Source和Avro Sink的组合代表了Flume内部的通信原理。Avro Source的可扩展性结合Channel担当了缓冲期的角色，使得Flume能够处理重要的负载峰值。

Flume的Avro Source使用Netty-Avro inter-process的通信（IPC）协议来通信。因此可以用Java或jvm语言发送数据到Avro Source。如果想从应用使用Avro Source发送事件给一个Agent，可以利用flume SDK或者嵌入试agent。

Avro Source可以配置用来从配置好输出压缩事件的Avro Sink中接收压缩的事件；也可以配置来确保接收任何客户端或Sink发送的使用SSL加密的数据。

Avro Source使用Netty服务器来处理传入的请求，Netty服务器使用Java的非阻塞I/O（NIO），这保证了Netty服务器使用相对较少的线程来处理请求的高性能。

Avro Sink和Flume RPC客户端可以配置用于在发送数据给Avro Source之前压缩数据。如果数据在广域网或数据中心之间传输时，这能减少使用的带宽。发送数据端和接收数据端均需要做压缩相关配置。

Thrift Source

Avro Source不能接收非JVM语言的数据，而Thrift Source支持跨语言通信。简单说Thrift Source就是多线程、高性能的Thrift服务器。

Thrift Source目前不支持压缩和SSL，因此Thrift Source只能用来从非JVM语言系统推送数据到Flume中，或者从用于别的用途的Thrift的写数据的应用推送数据到Flume。对于Flume Agent到Flume Agent的通信，推荐使用Avro Sink-Avro Source

RPC Sources的失败处理

Avro Source和Thrift Source中失败的处理都有些棘手，因为RPC Source尽管看起来像是本地方法的调用，但实际是被另一边网络链路上的客户端或Sink调用。

HTTP Source

Flume自带的HTTP Source可以通过HTTP POST接收事件。从客户端角度来看，HTTP Source表现得像web服务器一样能接收flume事件。HTTP Source支持SSL。

HTTP Source可以接收从客户端发来的能被处理程序处理的任何格式的数据。HTTP Source处理程序是一个继承自简单接口HTTPSourceHandler的类：

public interface HTTPSourceHandler extents Configurable{
    public List<Event> getEvents(HttpServletRequest request) throws HTTPBadRequestException,Exception;
}
1
2
3

Spooling Directory Source

Spooling Directory Source监视读取事件的目录，尽管新文件可以被实时地添加到该目录，source还是期望目录中的文件是不变的。文件一旦被移入到该目录，它不应该被写入。source也期望文件名是不重名的。如果这两种情况发生一种，source将会抛出异常并终止。这时重启source的唯一方式是重启agent自身。

Spooling Directory Source是使用tail -F的Exec Source的一种好的替换方案，因为这类source能保证数据传送，通常比tail -F的Exec Source更加可靠。唯一的缺点是数据不是实时跟踪的，并且只能在文件关闭或移入到相关目录时才能读取文件。文件一旦被source完全使用完且所有的事件被成功写入source的channel中，source就可以基于配置重命名或删除文件。

Spooling Directory Source使用追踪器持久化到磁盘，以定位每个文件在哪个位置成功将事件写入channel，这样如果agent或机器失败和重启，source就能从这个位置开始读取数据。这也能保证source定位任一位置的处理，并且保证当source重启时，处理是接着上次处理的位置。这正是source不允许文件名重用的原因之一。

Spooling Directory Source的性能：
Spooling Directory Source是I/O密集型的。为了避免复杂的反序列化器实现，source被专门设计成单线程的。这意味这有可能通过使用多个线程读取数据、更多的使用可用的CPU来提高性能。提高文件读取性能的一种方法是轮流写文件到不同的目录，并由一个Spooling Directory Source处理每一个目录。

Syslog Source

flume提供了两种Syslog Source：Syslog UDP Source和Multiport Syslog Source。Syslog UDP Source用UDP接收syslog消息，而Multiport Syslog Source可以在多个端口用TCP接收syslog消息。Syslog UDP Source认为整个UDP数据报文是一个syslog事件，并将其转换为一个flume事件，而Multiport Syslog Source每次遇到一个换行符字符就创建一个新的消息。这些source创建两个header，facility和serverity，在每个flume事件的header中指明每个消息的facility和serverity。这可以用于分桶或多路复用channel选择器。

除了公共参数，syslog UDP Source只有一个另外的参数：

Multiport Syslog Source可以在主机上绑定多个端口，除了公共参数，Multiport Syslog Source还定义了以下参数：

Source使用一个名为Apache MINA的框架来接收消息。MINA服务器使用一个内部缓冲区读取网络中的数据，同时MINA对并行性支持良好。

Syslog通常被认为是一个“fire and forget”协议。RFCs没有定义从接收方到发送方应答的方法，也没有指定超时后重新发送消息的方法。如果Flume source无法往channel写事件，或者网络中断导致信息丢失，那么对于Flume没有实际的方式通知发送方，或者告知发送发有错误情况并且重新发送消息。这实际上将导致数据无声的丢失，且没有恢复丢失数据的可能性。因此，如果没有其他选择，并且Flume RPC客户机或嵌入式Agent不能使用，才建议使用syslog。

Exec Source

Exec Source执行用户配置的命令，且基于命令的标准输出来生成事件，它还可以从命令中读取错误流，将事件转换为Flume事件。接着，输出流中的每一行将被编码为字节数组，每个字节数组用作flume事件的body。

Exec Source在flume中最常用来追踪文件。利用tail -F命令使用Exec Source追踪文件，近乎实时地将数据放入flume，但存在数据丢失的风险。因为tail命令只会拉取新写入到文件中的数据，任何agent死亡和source启动期间的写入文件的数据都会丢失。因此，建议使用Spooling Directory Source处理写入文件的数据，尽管更严格一些，但因为它追踪的是正在从文件中读取的数据，所以source不会丢失数据。
即使使用其他一些命令，Exec Source在将事件写入channel之前，也能缓冲和batch大小尽可能多的事件。如果agent或机器重启，这些事件也可能会在批处理超时或达到batch最大容量之前丢失。

JMS Source

使用JMS Source可以接受支持JMS的消息传递系统中的消息。

编写自定义source

source每次生成一个事件，调用channel处理器的processEvent方法将事件写入channel处理器，或者使用channel处理器的processEventBatch方法来发送事件。使用processEventBatch方法来处理一批事件总是更好的。processEvent只为一个事件创建事务，这可能会导致严重的开销，影响channel的性能。要访问source的channel处理器，source可以调用AbstractSource类中定义的getChannelProcessor方法。
每个Source在称为SourceRunner的自身线程上运行。source运行器运行单独的线程来操作source。flume有两种类型的source：Event-driven source和pollable source。

① 开发pollable source：
pollable source不运行它们自己的线程：它们受flume框架的控制，即Flume框架会循环调用source的process方法。pollable source运行一个循环来生成数据或轮询外部系统来接收数据，而不是运行一个服务器。一旦配置提供者实例化并且配置了一个Pollable Source，flume框架会创建一个PollableSourceRunner来运行Source。

Flume框架通过重复调用process方法，为每个pollable source运行一个线程。每次调用process方法，source“生成”事件并将它们传递到channel处理器。source负责通知框架能否成功生成数据。如果source能够成功生成事件，就会返回PollableSource.Status.READY给调用它的运行线程，该线程将立即再次调用process方法。否则，source返回PollableSource.Status.BACKOFF.这种情况下，flume框架只能在短暂超时后利用被调用的process方法发起一个补救措施，即每次source返回失败时增加1/2的超时时间。pollable source将生成自己的数据，或者轮询其他的source。

如果processEventBatch方法抛出异常，source可以捕获异常然后报告错误给恢复数据的系统。对于JMS Source，这可能会导致JMS事务回滚。否则，成功会被报告给外部系统，例如JMS事务的提交。

② 创建Event-driven source：
当flume框架调用start方法，Event-driven source通常会运行它们自己的线程。这类source控制了它们写数据到channel的速率。

例如flume自带的HTTP Source就是一个Event-driven source，它运行一个web监听特定端口的服务器。它基于发送给HTTP请求的事件来生成flume的事件，并将这些事件写入与之关联的channel。Event-driven source通常运行它们自己的线程或线程池，用来处理事件生成和事件写入到channel。因为这些source要对一些外部刺激做反应，flume框架创建一个新的EventDriven SourceRunner，通过在新线程调用start方法来启动这些source，并允许它们自己来管理。当agent停止或重新配置时，调用stop方法来停止source。

Event-driven source响应外部事件来产生数据。大多数从外部实体来接收数据的source都属于这一类。Event-driven source运行自己的线程用于接收数据并生成事件。大部分flume自带的source，例如Avro Source、HTTP Source、Exec Source等，都是Event-driven source。
Event-driven source比Pollable Source稍微复杂一些，因为source必须追踪产生数据的外部程序，并且不借助flume框架处理传入的数据。