轻松筹监控系统实现方案

目前对日志切分的需求只有2个：按天切分和删除切出来的多余日志。logrotate就能很好的满足这些需求，logrotate是基于cron来运行的，其脚本是/etc/cron.daily/logrotate，默认放在/etc/cron.daily下，每天执行一次。

有的时候程序异常或者请求激增会导致日志量暴增，有可能在短时间内打满整个磁盘。可以在logrotate的配置文件里加上maxsize来限制日志文件的大小，并且将logrotate的执行频率调高至每小时甚至每分钟，及时切分并删除超过rotate数量的日志，来防止异常情况下磁盘被打满的情况发生。

//?logrotate?config?of?sample//?rotate?every?day,?and?keep?for?3?days/var/log/sample.log?{dailyrotate?3maxsize?1Gmissingoksharedscriptspostrotate????#?在切分时向程序发送SIGHUP信号????killall?-SIGHUP?bin_sampleendscript}

主动采集

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

被动接收

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

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

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

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:?afteroutput: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在控制台打印。

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?}}}

根据 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倍。这种写入速度的差距随着数据量的增大保持相对一致。

详细的比较说明参见：InfluxDB Markedly Outperforms Elasticsearch in Time-Series Data & Metrics Benchmark（http://t.cn/RS1S4ih）。

Elasticsearch强在全文搜索，InfluxDB擅长时序数据，所以还是具体需求具体分析。如果需要保存日志并经常查询的，Elasticsearch比较合适；如果只依赖日志做状态展示，偶尔查询，InfluxDB比较合适。

轻松筹的业务各有特点，单一选择Elasticsearch或者InfluxDB都不能很好的查询日志和指标展示，所以有必要InfluxDB和Elasticsearch共存。在 Logstash 里配置2个输出，同一条日志输出2份，一份保留全部字段输出至 Elasticsearch；另一份过滤文本性的字段保留指标性的字段，然后输出至 InfluxDB。

//?业务日志输出时时间戳格式化到微秒：2006-01-02T15:04:05.999999Z07:00//?Logstash的filter根据时间戳转换filter?{ruby?{????code?=>?"event.set('time',(Time.parse(event.get('time')).to_f*1000000).to_i)"}}

比较Kibana和Grafana，Kibana在图表展示上没有Grafana美观，而且Grafana的配置更加简单灵活。既然在日志存储中决定InfluxDB和Elasticsearch共存，展示上就也需要Kibana和Grafana共同协作，Kibana从Elasticsearch中检索日志，Grafana从InfluxDB和Elasticsearch中获取展示数据。下面2张图片展示了Grafana在轻松筹业务监控上的应用：

报警的服务有很多，但是数据展示的Grafana自带报警功能，功能也能满足我们的报警需求，而且配置简单，所以规则简单的报警可以采用Grafana的报警服务。不过Grafana的报警只支持部分数据库，分别是Graphite, Prometheus, InfluxDB 和 OpenTSDB，所以在Elasticsearch中的日志报警还需要Elastic Stack的X-Pack。

Condition

如上图所示，可以设置报警检查的频率，报警条件是最近的5分钟内指定指标的平均值是否大于70，如果这个条件为True则触发报警。这种报警条件还比较单一，像错误数在十分钟内超过几次才报警，当前订单数与昨天同一时间的订单数比较跌了超过百分之几就报警，控制报警通知发送的频率，等等，Grafana就不能满足了，针对这种报警规则我们自己实现了一个报警引擎，用来满足这些比较复杂的报警规则。

Notification

Grafana的报警通知只有在状态转换时才会触发，即报警状态的时候会发送告警通知，如果到恢复之前的一段时间里条件一直是满足报警条件的，Grafana不会一直发送通知，直到恢复的时候再发送一次恢复的通知。如果触发报警，Grafana支持4中通知方式：Email、Slack、Webhook 和 PagerDuty。其中Slack是国外的一种协作工具，类似钉钉，PagerDuty是一个收费的告警平台，所以可选的只剩下Email和Webhook了。下面简单的介绍如何配置Email和Webhook。

Email

Grafana的邮件配置很简单，可以利用QQ企业邮箱的smtp服务来发送报警邮件，邮件内容是配置的报警，配置比较简单：

[smtp]enabled?=?truehost?=?smtp.exmail.qq.com:465user?=?alert@qingsongchou.compassword?=?********from_address?=?alert@qingsongchou.comfrom_user?=?Grafana

Webhook 就是在触发报警时，Grafana主动调用配置的http服务，以POST或者PUT方式传递json数据。这样就可以在我们自己开发的http服务里增加额外的通知方式，例如短信、微信甚至电话。

Reception

配置了报警通知，不接收不去看也是白搭。一方面我们尽量实现多种通知途径，比如邮件、微信和短信。另一方面需要项目负责人接到报警及时响应，查看问题。

Q：如果类似于Nginx、MySQL这种日志，类型增加需要解析每增加一个就要去改Logstash的grok吗？

Q：这个lostash日志格式转换怎么学习？

Q：据说Logstash比较吃内存，fluentd作为EFK组合也经常出现，请问你们有没有做过选型呢？

Q：日志的完整性怎么保证的？怎么知道没丢日志，或丢失了多少日志？

Q：请问监控系统需要考虑高可用吗？

轻松筹，一亿用户信赖的全民众筹平台！（https://m2.qschou.com）