轻松筹监控系统实现方案(2)
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标识项目,项目各自的日志进各自的配置,互不干扰.
5 . 日志存储根据 DB-ENGINES 的排名,InfluxDB和Elasticsearch在各自专攻的领域都是NO.1,InfluxDB统治Time Series DBMS,Elasticsearch制霸Search engine,关于它们的原理和使用,各自都有非常详细的文档和资料,这里就不再赘述. 在时序数据方面,InfluxDB表现强劲,Elasticsearch在主要的指标上均远落于下风: 数据写入:同时起4个进程写入8百64万条数据,Elasticsearch平均为 115,422 条/秒,InfluxDB平均 926,389 条/秒,写入速度是Elasticsearch的8倍.这种写入速度的差距随着数据量的增大保持相对一致. 磁盘存储:存储相同的8百64万条数据,使用默认配置的Elasticsearch需要2.1G,使用针对时序数据配置的Elasticsearch需要517MB,而InfluxDB只需要127MB,压缩率分别是前两者的16倍和4倍. (编辑:ASP站长网) |