正文
被动接收
优点：业务程序直接将日志发送至存储，灵活性强，存储内容可在业务代码里控制。
缺点：日志存储不稳定的话会影响业务程序的正常运行；反之，日志量大的话也会压垮日志存储。
但是在建设监控系统初期，日志存储还不是很稳定的情况下，还是用主动采集的方式比较稳妥，不影响服务稳定性为主。
Collectd功能确实很强大，它的tail插件也能满足从文件收集日志，但是tail插件配置比较复杂而且说明文档相较于Filebeat来说不是很详细。
Collectd的其他插件可以采集的数据确实很多，而且也有插件支持将数据发送到Logstash和InfluxDB，但是多数插件的功能我们用不到，而且Elastic Stack中的Beats也能够很好的收集系统参数等数据，而且跟ELK能很好的兼容。
所以在分别试用了Filebeat和Collectd这2个采集服务后，综合上述分析决定采用Filebeat来负责从日志文件中采集日志。如下所示，Filebeat的配置简单易懂：
filebeat:
spool_size: 1024 # 最大可以攒够 1024 条数据一起发送出去
idle_timeout: "5s" # 否则每 5 秒钟也得发送一次
registry_file: "registry" # 文件读取位置记录文件，会放在当前工作目录下。
config_dir: "path/to/configs/contains/many/yaml" # 如果配置过长，可以通过目录加载方式拆分配置
prospectors: # 有相同配置参数的可以归类为一个 prospector
-
fields:
log_source: "sample" # 类似 logstash 的 add_fields，此处的"log_source"用来标识该日志来源于哪个项目
paths:
- /var/log/system.log # 指明读取文件的位置
- /var/log/wifi.log
include_lines: ["^ERR", "^WARN"] # 只发送包含这些字样的日志
exclude_lines: ["^OK"] # 不发送包含这些字样的日志
-
document_type: "apache" # 定义写入 ES 时的 _type 值
ignore_older: "24h" # 超过 24 小时没更新内容的文件不再监听。
scan_frequency: "10s" # 每 10 秒钟扫描一次目录，更新通配符匹配上的文件列表
tail_files: false # 是否从文件末尾开始读取
harvester_buffer_size: 16384 # 实际读取文件时，每次读取 16384 字节
backoff: "1s" # 每 1 秒检测一次文件是否有新的一行内容需要读取
paths:
- "/var/log/apache/*" # 可以使用通配符
exclude_files: ["/var/log/apache/error.log"]
-
input_type: "stdin" # 除了 "log"，还有 "stdin"
multiline: # 多行合并
pattern: '^[[:space:]]'
negate: false
match: after
output:
logstash:
hosts: ["localhost:5044"] # The Logstash hosts
-
beat.hostname beat 运行的主机名
-
beat.name shipper 配置段设置的 name，如果没设置，等于 beat.hostname
-
@timestamp 读取到该行内容的时间
-
type 通过 document_type 设定的内容
-
input_type 来自 "log" 还是 "stdin"
-
source 具体的文件名全路径
-
offset 该行日志的起始偏移量
-
message 日志内容
-
fields 添加的其他固定字段都存在这个对象里面
Logstash 自2009年诞生经过多年发展，已经是很成熟并且流行的日志处理框架。Logstash使用管道方式进行日志的搜集处理和输出。有点类似*NIX系统的管道命令 input | filter | output，input 执行完了会执行 filter，然后执行 output。在 Logstash 中，包括了三个阶段：输入input → 处理filter（不是必须的）→ 输出output。每个阶段都由很多的插件配合工作，比如 file、elasticsearch、redis 等等。每个阶段也可以指定多种方式，比如输出既可以输出到elasticsearch中，也可以指定到stdout在控制台打印。
