轻松筹监控系统实现方案

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

被动接收

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

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

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

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 . 日志存储