发送源(Senders)的主要作用是将 Parser 后的数据发送至 Sender 支持的各类服务，目前支持发送到的服务包括： Pandora、ElasticSearch、File、InfluxDB、MongoDB 五种服务。

1. Pandora Sender: 发送到 Pandora 智能日志管理平台。
2. ElasticSearch Sender: 发送到 ElasticSearch。
3. File Sender: 发送到本地文件。
4. InfluxDB Sender: 发送到 InfluxDB。
5. MongoDB Accumulate Sender: 聚合后发送到 MongoDB。
6. Kafka Sender: 发送到 Kafka。
7. KODO sender: 发送到七牛云存储。

发送规则与功能特点

错误处理与等待

遇到弱网环境或者服务端偶尔出现一些异常是很正常的事情，此时logkit-pro会针对服务端不同的错误码进行分类处理，不会因为某个错误而导致程序出错，某些错误如数据不合法类型等会将原始数据保留发送到服务端，有些错误如网络不通会进行重试。

另外一方面，一旦发现出错，我们会设定一个对服务端友好的变长错误等待机制。会采用随着连续错误出现递增等待时间的方法，如一开始等待1s后重试，持续出错每次多等待一秒，直到一个最顶峰（如10s），就不再增加，当服务端恢复后再取消等待时间，持续发送。这样的错误等待机制有利于服务端的恢复，也避免不必要的带宽和资源浪费。

通常情况下，出错的数据会报错到磁盘队列中异步处理，不会阻塞正常的发送进程，而磁盘队列我们也会设置上限，默认为10GB，超过上限则不再追加数据进入，以免磁盘爆满出现额外的故障。磁盘队列到达上限后，读取会相应变慢，只有发送成功后才会再次读取。

对于出现此类异常的情况，agent也会上报心跳给服务端，服务端可以通过界面观察到异常并作出报警提示。

数据二分发送

数据二分发送指发送时遇到某些错误时，将数据拆分为2份，分别重试。这种机制大大减少了数据重试的次数，快速精准的筛选出具体的某一条错误数据，让其余数据得到正常发送。对于筛选出的单条错误数据，则根据具体情况处理，通常将原始数据发送到日志平台，当原始数据仍然超过规定大小时，则再次拆分，并分别打上同样的唯一ID和顺序，方便快速定位和聚拢数据。

另外一方面，二分发送的功能也解决了当单次发送的数据量过大导致服务端接收出错的问题，logkit-pro遇到此类错误，可以快速拆分成两份，分别发送，避免了盲目的重试。

数据压缩发送

带宽是非常珍贵的资源，通常服务端都会提供gzip压缩的数据接收接口，而只要服务端支持，logkit-pro的发送就会利用这些接口，将数据压缩后发送，能节省大量带宽成本。

带宽限流

通常情况下数据收集工具只是机器上的一个附属程序，主要资源如带宽还是要预留给主服务，所以限制发送的带宽用量也是非常重要的功能，logkit-pro 采用令牌桶算法进行限流。

多线程发送

除了限制，有时候也会希望开放机器资源，让读取发送尽可能快，而发送端的多线程功能，可以充分利用CPU多核的能力，提升发送效率。这一点我们设计三种多线程发送方式。

• 纯并发发送，不经过任何队列，纯开启多线程并发发送。对于发送的CPU是性能瓶颈的情况下尤为有效。
• 磁盘队列并发，先保存到磁盘队列，再并发发送，使用磁盘队列主要便于读取和发送异步化，有利于发送需要大批量发，读取快的情况，发送可以攒一批数据发送。
• 内存队列，原理类似磁盘队列，但是在程序被强行中断时存在数据丢失风险，性能上比磁盘队列更优。

字段填充(UUID/timestamp)

通常情况下收集的数据信息可能不是完备的，需要填充一些信息进去，如全局唯一的UUID、代表收集时间的timestamp等字段，提供这些字段自动填充的功能，有利于用户对其数据做唯一性、时效性等方面的判断。所以 logkit-pro 会可选择的填充进这些字段，通常在高级选项中开启。

同时发送到多个端

logkit-pro 也支持将一份数据发送到多个发送端，但需要手动进行配置。

典型配置如下

"senders":[{
        "name":"pandora_sender",
        "sender_type":"pandora",
        "pandora_ak":"",
        "pandora_sk":"",
        "pandora_host":"https://pipeline.qiniuapi.com",
        "pandora_repo_name":"yourRepoName",
        "pandora_region":"nb",
        "ft_save_log_path":"./ft_log",
        "ft_write_limit":"1",
        "ft_strategy":"always_save",
        "ft_procs":"2"
},{
        "name":"file_sender",
        "sender_type":"file",
        "fault_tolerant":"false",
        "file_send_path":"./myapp-%Y-%m-%d.txt"
}]

重要字段说明

1. ft_strategy：容错发送策略，该选项默认设置为backup_only，数据 不经过 队列直接发送到下游，但是出错的数据会保存到磁盘队列不断重试；选concurrent的时候会直接并发发送，不经过队列；设为always_save时则所有数据会先发送到本地队列，再并发发送。无论该选项设置什么，失败的数据都会加入到重试队列中异步循环重试。
2. ft_save_log_path: 可以指定磁盘队列数据的存放路径，该路径必须为文件夹，该文件夹会作为本地磁盘队列，存放数据，进行异步容错发送。默认情况下会保存在运行目录的meta文件夹下。
3. ft_write_limit：为了避免速率太快导致磁盘压力加大，可以根据系统情况自行限定写入本地磁盘的速率，单位MB/s。默认10MB/s
4. ft_procs ：该选项表示从本地队列获取数据点并向下游发送的并发数，默认并发数为1, 即不并发，1.2.1开始不再需要设置，直接使用logkit主配置中的并发参数。
5. ft_memory_channel: 默认不启用。开启该选项会使用内存队列使得发送和数据读取解析变为异步，加速整个发送的过程。该功能适合与 ft_procs 连用，利用内存队列，异步后，在发送端多并发加速。
6. ft_memory_channel_size: 选填，默认为"100"，指的是批次数量，也就是 100 代表 100 个待发送的批次，当ft_memory_channel启用时有效，设置 memory channel 的大小。 注意：该选项设置的大小表达的是队列中可存储的元素个数，并不是占用的内存大小
7. ft_discard_failed_data: 默认false，配置此选项之后会丢弃发送错误的数据，仅在数据只有一条时才会丢弃，多余一条会不断二分。注意：配置此选项之后发送失败的数据将不会再被保存到pandora_stash字段中（只在有必要时配置）

补充说明

• 如果 ft_procs 增加已经不能再加大发送日志速度，那么使用的磁盘队列，考虑加大ft_write_limit限制，为 logkit-pro 的队列提升磁盘的读写速度。
• senders支持多个sender配置，但是我们不推荐在senders中加入多个sender，因为一旦某个sender发送缓慢，就会导致其他 sender 等待这个 sender 发送成功后再发。简单来说，配置多个 sender 会互相有一定影响。