轻松筹监控系统实现方案(3)

发布时间：2021-01-18 08:01 所属栏目：53 来源：网络整理

导读：数据查询：在24h的数据集(8百64万条数据)里随机查询1个小时内的数据,按1分钟的时间间隔聚合,Elasticsearch和InfluxDB分别单进程执行1000次这种查询,算耗时的平均值.Elasticsearch耗时4.98ms(201次查询/秒),InfluxDB

数据查询：在24h的数据集(8百64万条数据)里随机查询1个小时内的数据,按1分钟的时间间隔聚合,Elasticsearch和InfluxDB分别单进程执行1000次这种查询,算耗时的平均值.Elasticsearch耗时4.98ms(201次查询/秒),InfluxDB耗时1.26ms(794次查询/秒),查询速度是Elasticsearch的4倍.随着数据集的增大,查询速度之间的差距逐渐拉大,最大相差10倍之多.而且随着执行查询的进程数增加,InfluxDB的查询速度增幅显著,而且在不同数据集之间的查询速度基本一致,但是Elasticsearch增幅就不大,而且随着数据集的增大查询速度是递减的.

详细的比较说明参见：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.

InfluxDB如果作为Logstash的输出,有个坑需要注意,就是Logstash的InfluxDB插件支持的时间戳精度太粗,不能精确到纳秒,会导致同一个值的时间戳在插入InfluxDB的时候出现异常.因为InfluxDB用measurement名、tag集和时间戳来唯一标识一条记录.如果插入InfluxDB的一条记录与已经存在的一条记录measurement名、tag集和时间戳都相同,那么filed会是新老两条记录的集合,相同field的值会被新记录覆盖. 解决方式有2种,一种是增加一个tag来标识新记录.另一种是手动提升时间戳的精度,提升至微秒,理论上每天可以支持86,400,000,000条不重复的日志,可以很大程度避免时间戳的重叠,配置如下所示：

//?业务日志输出时时间戳格式化到微秒：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)”
}
}

6 . 数据展示

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

7 . 异常报警

即使上述6个环节都建立了,如果没有报警一切都是没有意义的,因为不可能每时每刻都盯着曲线看,所以需要设置异常阈值,让监控系统定时检查,发现异常立即发送报警通知.

报警的服务有很多,但是数据展示的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.

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

[smtp]
enabled?=?true
host?=?smtp.exmail.qq.com:465
user?=?alert@qingsongchou.com
password?=?********
from_address?=?alert@qingsongchou.com
from_user?=?Grafana

Webhook

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

Reception

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

（编辑：ASP站长网）