轻松筹监控系统实现方案

缺点：日志收集需要依赖额外的采集服务，过滤和存储可能还需要额外配置。

被动接收

优点：业务程序直接将日志发送至存储，灵活性强，存储内容可在业务代码里控制。

缺点：日志存储不稳定的话会影响业务程序的正常运行；反之，日志量大的话也会压垮日志存储。

但是在建设监控系统初期，日志存储还不是很稳定的情况下，还是用主动采集的方式比较稳妥，不影响服务稳定性为主。

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

4 . 日志过滤

Logstash 自2009年诞生经过多年发展，已经是很成熟并且流行的日志处理框架。Logstash使用管道方式进行日志的搜集处理和输出。有点类似*NIX系统的管道命令 input | filter | output，input 执行完了会执行 filter，然后执行 output。在 Logstash 中，包括了三个阶段：输入input → 处理filter（不是必须的）→ 输出output。每个阶段都由很多的插件配合工作，比如 file、elasticsearch、redis 等等。每个阶段也可以指定多种方式，比如输出既可以输出到elasticsearch中，也可以指定到stdout在控制台打印。

Codec 是 Logstash 从 1.3.0 版开始新引入的概念（Codec 来自 Coder/decoder两个单词的首字母缩写）。在此之前，Logstash 只支持纯文本形式输入，然后以过滤器处理它。但现在，我们可以在输入 期处理不同类型的数据，这全是因为有 Codec 设置。所以，这里需要纠正之前的一个概念。Logstash 不只是一个 input | filter | output 的数据流，而是一个 input | decode | filter | encode | output 的数据流！Codec 就是用来 decode、encode 事件的。Codec 的引入，使得 Logstash 可以更好更方便的与其他有自定义数据格式的运维产品共存，比如 graphite、fluent、netflow、collectd，以及使用msgpack、json、edn 等通用数据格式的其他产品等。

Logstash 提供了非常多的插件（Input plugins、Output plugins、Filter plugins、Codec plugins），可以根据需求自行组合。其中 Filter 插件 Grok 是 Logstash 最重要的插件。Grok 通过正则表达式匹配日志内容，并将日志结构化，所以理论上只要正则掌握的够娴熟，就能解析任何形式的日志，非常适合用来解析第三方服务产生的非结构化日志。但是如果是自己写的服务，就没必要将日志输出成非结构的，增加写正则的负担，所以在上述日志打印一节中才规定线上的日志输出成json形式，方便 Logstash 解析，Logstash 提供 json 的 Filter 插件。

Logstash 的配置文件默认放在 /etc/logstash/conf.d 目录下，如果需要采集多个项目的日志，每个项目的 Logstash 配置可能不一样，那就会在 conf.d 里存放多个配置文件，以每个项目命名方便管理。但是这样会带来一个问题，因为 Logstash 会将所有配置文件合并为一个，即一条日志通过input进入到Logstash后，会经过每个配置文件里的filter和output插件，造成对日志错误的处理和输出。解决方式是在Filebeat的fileds配置项里增加区分不同项目的field，如果日志路径就能区分不同项目的话也可以不用额外加field，用 Filebeat 自带的source字段就可以，然后在每个项目对应的 Logstash 配置文件里通过IF标识项目，项目各自的日志进各自的配置，互不干扰。

input {
beats {
port => “5044”
}
}
// The filter part of this file is commented out to indicate that it is
// optional.
filter {
if [beat] and [source] =~ “sample” {
json {
source => “message”
}
ruby {
code => “event.set(‘time’,(Time.parse(event.get(‘time’)).to_f*1000000).to_i)”
}
}
}
output {
if [beat] and [source] =~ “sample” {
stdout { codec => rubydebug }
}
}

5 . 日志存储