今天给大家来介绍一个报警工具，具体来说，是基于 Elasticsearch 的报警工具，假如你的日志是放在 ES 里面的，这个工具是你不错的选择。

报警系统对于线上服务稳定性的保障作用不用多说，很多情况下，作为监控中最重要的输出环节，假如监控探测到了问题，却无法通知到我们，或者干脆通知错了，通知太过频繁，都容易导致故障的出现。

因此，好的报警系统功能，至少需要达到以下几点：

  1. 及时
  2. 准确
  3. 少

但是现实中，这三点很难全部达到，往往我们做到的也就只是及时：不管什么报警，统统通知给运维与开发人员，导致他们习惯性忽略报警通知。

下面开始正式介绍：

如何配置 ElastAlert

目前，它提供内置的 11 种报警规则，可以直接配置使用，下面以一个常见的类型来做说明：

Frequency
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 规则名称
name: Example frequency rule

# 规则类型
# the frequency rule type alerts when num_events events occur with timeframe time
type: frequency

# Index to search, wildcard supported
index: logstash-*

# Alert when this many documents matching the query occur within a timeframe
num_events: 10

# num_events must occur within this amount of time to trigger an alert
timeframe:
  minutes: 10

# ES 查询，用以过滤
filter:
- query:
    query_string:
      query: level.keyword:"error" AND name.keyword:"api-access"

以上就是个最简单的报警类型，其中这个例子中，当 level 为 error 且 name 为 api-access，然后 10 分钟内发生 10 次的时候，就会报警。

接下来在说几个其它你可能需要的配置：

报警抑制：减少重复报警
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 用来区分报警，跟 realert 配合使用，在这里意味着，
# 5 分钟内如果有重复报警，那么当 name 不同时，会当做不同的报警处理，可以是数组
query_key:
  - name

# 5 分钟内相同的报警不会重复发送
realert:
  minutes: 5

# 指数级扩大 realert 时间，中间如果有报警，
# 则按照 5 -> 10 -> 20 -> 40 -> 60 不断增大报警时间到制定的最大时间，
# 如果之后报警减少，则会慢慢恢复原始 realert 时间
exponential_realert:
  hours: 1
报警聚合：相同报警，聚合为一条
1
2
3
4
5
6
7
# 根据报警的内，将相同的报警安装 name 来聚合
aggregation_key: name

# 聚合报警的内容，只展示 name 与 message
summary_table_fields:
  - name
  - message
报警格式化：突出重要信息

在这里，你可以自定义 alert 的内容，它的内部使用 Python 的 format 来实现的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
alert_subject: "Error {} @{}"
alert_subject_args:
  - name
  - "@timestamp"

alert_text_type: alert_text_only
alert_text: |
  ### Error frequency exceeds
  > Name: {}
  > Message: {}
  > Host: {} ({})
alert_text_args:
  - name
  - message
  - hostname
  - host

其它报警规则

除了上面的 frequency， 这里再举几个常见的报警场景，以及在这个工具中对应的报警类型。

  • any：这个是查到了什么便直接报警，属于自定义选项；
  • spike：API 流量陡然上升并马上恢复的时候；
  • flatline：内存或者 CPU 使用率下降的时候；
  • new_term：某个枚举类型字段，突然出现了未定义的类型；
  • change：应用的状态突然从 UP 转为 DOWN；
  • blacklist or whitelist：昨天的那个疑似爬虫的 IP 地址又出现了；
  • cardinality：线上的 API 服务器突然挂了一台，它是根据唯一值的数量来判定的；

报警通知配置

目前它提供了 10 多种通知的类型，但是目前国内常用的可以是 Email、Slack 或者 JIRA 了，没有微信之类的还是挺可惜的。

不过，不用担心，有第三方的：

你也可以自己根据文档去实现，文档在 这里。

在工具之外

总之，基于 ElasticSearch 的监控报警的需求，基本上都能满足你，并且也支持你自定义大部分内容。

接下来，可能你会觉得，报警工具有了，就可以安枕无忧了，显然，并不是。

你可曾想过，报警通知了之后，谁来处理，怎么处理？工具是为你所在的团队服务的，仅仅使用了这个工具，并不能很明显地提升你们的运维水平。

毕竟，这个过程还是需要人来处理（有些流程形成了后，可以自动化处理，那是你们以后需要做的），与之配套的流程与制度才是关键：

  1. 谁负责报警规则的制定与维护？
  2. 报警了之后，处理流程应该是怎样的？规范吗？有效吗？
  3. 流程中有报警升级？升级成为线上故障之后的流程，又该如何处理？
  4. 值班制度如何？是不是应该有人 24 On-Call ？

在这里，可以参考下有赞的线上故障管理。

相信，在工具之外的东西才是真正最重要的，不然报警系统做得再好也只是浪费时间精力而已，起不了应有的作用。而当你们团队内部行成了这种规范且有效的流程，线上服务的稳定也就有了保障，这个工具的真正价值就会显现出来。

P.S.

这个工具是用来基于 ElasticSearch 日志来报警的，另外，这个名字没错，确实是 Elast 而不是 Elastic。

首发于 Github issues: https://github.com/xizhibei/blog/issues/62 ，欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享（BY-NC-SA）进行许可
作者：习之北 (@xizhibei)
原链接：https://blog.xizhibei.me/zh-cn/2017/11/19/alerting-with-elastalert/