（十九）使用InfluxDB搭建报警系统

以下内容来自 尚硅谷，写这一系列的文章，主要是为了方便后续自己的查看，不用带着个PDF找来找去的，太麻烦！

第 19 章 使用InfluxDB搭建报警系统

19.1 什么是监控

1、监控其实每隔一段时间对数据计算一下。比如，我有一个一氧化碳浓度传感器， 每 1分钟我就算一下这 1 分钟内室内一氧化碳浓度的平均值。将这个结果跟一个写死的标准值做比较，如果超过了就报警。这就是监控的基本逻辑。

2、所以，InfluxDB中的监控其实也是一个FLUX脚本写的定时任务。只不过，不管是在HTTP API还是在Web UI上，InfluxDB都把它和定时任务分离区别对待了。

19.2 认识检查、报警终端和报警规则

1、在Web UI的左侧工具栏中，点击Alerts按钮，会打开一个报警的配置页面。上方的选项栏中显示着 CHECKS（检查）、NOTIFICATION ENDPOINTS（报警终端）和NOTIFICATION RULES（报警规则）分别对应着InfluxDB进行报警所需要的 3 个组件。

2、三个组件的功能分别如下：

• CHECKS（检查）：它其实也是一种定时任务，我们可以称之为检查任务。检查任务会从目标存储桶中读取部分数据然后进行阈值检查，并最终出 4 类信号。CRIT（严重）、 WARN（警戒）、INFO（信息）和OK（良好）。

• NOTIFICATION ENDPOINTS（报警终端）：是一个向指定地址发送报警信号的组件。
• NOTIFICATION RULES（报警规则）：它可以指定哪些 Check出问题了发送微信报警，哪些Check出问题了可以发邮件通知。它相当于Check与报警终端之间的路由。

19.3 示例：模拟对一氧化碳浓度的报警

19.3.1 需求

1、假设我们现在有一个可以采集一氧化碳浓度的传感器，这个传感器通过物联网网络每隔一段时间就向我们部署在服务器上的InfluxDB插入一条数据，格式如下。

co,code=01 value=0.001 1664851126000

2、现在，我们希望使用InfluxDB能够完成下述的报警功能。

• 当CO浓度大于 0 .04的时候发出CRIT（严重）级别的通知信号。
• 当CO浓度介于 0 .04和 0 .01之间的时候发出WARN（警戒）级别的通知信号。
• 当CO浓度低于 0 .01的时候发出OK（良好）级别的通知信号。

3、最终，当 CO浓度超标时，我们希望相关的工作人员能够收到一通电话，以便对事故做出快速响应。

19.3.2 辅助工具

1、为了方便验证报警终端的效果，这里写了一个很简单的仅支持POST请求的HTTP服务。直接使用下面的命令即可开启一个监听本地 8080 端口的POST HTTP服务。

./simpleHttpPostServer-linux-x64

2、这个命令执行后会阻塞终端，当它接收到 POST请求后，会自动将请求体中的内容打印到终端。如果 0.0.0.0不是你想绑定的host或者 8080 端口已经被占用。你可以使用下面的两个参数来修改。

• h 指定绑定的host
• p 指定绑定的port

3、例如：

  ./simpleHttpPostServer-linux-x64 - h localhost -p 8080

4、具体可以参考项目地址： https://github.com/realdengziqi/simpleHttpPostServer

19.3.3 创建一个新的存储桶

1、为了避免我们将本示例的数据同之前的示例搞混，此处我们先创建一个新的名为example_alert的存储桶，如下图所示：

19.3.4 准备数据模板

1、在本示例中，我们会自己手动一条条地向InfluxDB中插入数据，所以可以打开一个文本编辑器（本教程使用vs code）先编写一个 InfluxDB行协议的数据模板，后面可以直接复制数据，稍微改一下数值然后接着插入。 数据模板如下：

co,code=01 value=0.001

19.3.5 事先插入一两条数据

1、这一步操作是为了后面进行创建检查的操作时，查询构造器中有东西可选。所以为了 顺利创建检查，这一步的操作不可以省略。此处，我们在Web UI导入行协议数据的窗口上，分两次各导入一条数据。如图所示：

2、数据如下：

• 第一次

co,code=01 value=0.0015

• 第二次

co,code=01 value=0.0025

19.3.6 创建检查（CHECK）

1、在左侧的工具栏中点击Alerts按钮。默认情况下会进入CHECKS的页面，如图所示：

2、将鼠标悬停在右上角CREATE按钮，会弹出一个下拉菜单，其中包括两个按钮:

• THRESHOLD CHECK（阈值检查）：这类检查任务主要是去判断数据有没有超出某种阈值限定。
• Deadman Check（死人检查）：这类检查任务是去判断某个序列下多长时间没有写入新的数据了。你也可以设定一个值，比如一旦超过 30s某个序列还没有数据入库，就发出一个警戒信号。
  

3、此处，我们选择Threshold Check，创建一个阈值检查。后面会弹出一个对话窗口，其布局和 Data Explorer非常像，但是功能上会有一些差异。

• 最上方有一个Name this Check，点击一下可以给当前创建的Check命名。
• 左上角有一个选项卡，默认是选中了DEFINE QUERY（定义查询），也就是上图所示的页面效果。
• 页面的下方是一个查询构造器，需要注意，此处我们无法切换到脚本编辑器，也就是在此处，我们只能使用查询构造器来实现查询。
• 最右边还有一个清单。上面说到为了创建一个阈值检查，你必须选择：
  • 一个字段
  • 一个聚合函数（也就是开窗后的聚合函数）
  • 一个或更多的值域。

4、现在，我们需要构造查询。如下图所示。

• 在存储桶处选择example_alert
• _measurement处选择co
• 注意，虽然我们当前co这个measurement下只有一个序列，但是还是必须将_field=value添加到过滤条件中，否则右上方检查项One Field不会通过。
• 最后将聚合逻辑从默认的mean改为max。
• 点击submit，可以预览数据的查询效果。

5、点击左上方的CONFIGURE CHECK按钮。这会让我们进入一个新的页面，在这个页面中，我们可以对阈值进行配置。首先要注意，只有页面的下半部分发生了改变。

• 最左侧的卡片对应的是查询和调度的进一步配置。这里我们将Schedule Every设为15 s这样，每隔 15 秒就会调用一次检查。
• 中间的STATUS MESSAGE TEMPLATE是状态消息模板。这里支持使用Shell风格的取值语法。${ }。这里r的含义在后面会进行详细的讲解。此处保持默认的模板不做任何修改。
• 最右侧的THRESHOLDS对应的是值域的设定。此处包含 4 种类型的值域，对应着一个检查能够发出的 4 中状态信息。它们分别是：
  • CRIT（critical的前 4 个字母）表示严重紧急。
  • WARN（warning）表示警告、警戒
  • Info（Information）表示普通信息，提醒
  • ok 表示状态良好

6、此时，点击右下角的CRIT按钮，会弹出一个小的设置窗口，如下图所示


7、这里的意思就是，当值大于多少的时候将检查的状态设置为CRIT。此处When value右边的is above就是大于的意思，可以看到这还是一个下拉菜单。我们可以点击一下。会发现它还有更多可选的选项，包括is below（小于）、is inside range（在什么范围之内）等。

8、0 .00125是Web UI 根据我们当前的查询结果自动帮我们填充的。这里，根据我们的需求，co的浓度值大于 0 .04的时候才将状态置为CRIT。效果如下。

9、同理，设置Warn和ok，Info就不设置了。结果如下。

10、最后点击右上角的对号，保存Check。现在，我们回到了最初的CHECKS页面，可以看到，下方的列表里就有一个我们刚才
配置的Check。

19.3.7 测试Check

1、现在，可以回到上传数据的页面，尝试插入两条数据测试一下检查的运行效果。插入的数据如下：

co,code=01 value=0.025

2、这时一氧化碳的浓度为 0 .025，介于 0 .01到 0 .03之间，这个时候我们刚才创建的CHECK应该发出WARN级别的信号。现在，我们可以在左侧的工具栏里，点击Alert History。 可以看到，现在我们的状态记录里面就躺着一条级别为WARN的通知。这里，右面的MESSAGE显示 Check:CO_Alert is : warn 就是我们的消息模板生成的消息。

19.3.8 修改消息模板

1、 当前，我们的消息模板提示的消息还不够精确，我们希望进行报警的时候能够把当前的一氧化碳浓度的值也输出出来。这个时候可以看一下官方文档关于模板的说法，可以发现，官方文档指出，我们是可以通过r.字段名的方式去访问到数据具体值的。

2、这样的话我们就可以重新修改消息模板，最终的消息模板如下图所示：

3、注意，模板中的r.code和r.value。通过这个操作，我们可以直接提取数据中的设备编号和当前的一氧化碳浓度值。

19.3.9 验证消息模板

1、接下来，我们再次插入一条数据。

co,code=01 value=0.0146

2、0.0146在 0 .01和 0 .03之间，我们之前创建的CHECK应该再发出一个WARN级别的信号。现在，还是在左侧的工具栏点击Alter History，查看检查汇报的状态记录。我们发现新的状态记录里面的MESSAGE有所改变，这次在信息中我们可以看到设备编号和当时的一氧化碳浓度了。

19.3.10 创建报警终端（NOTIFICATION ENDPOINT）

1、仅有状态记录还不够，我们还需要将信息发送到外部系统，比如给开发人员发送邮件，或者拨打电话。那么这个负责向外面发送消息的组件就是报警终端。

2、首先点击左侧工作栏中的 Alerts按钮，进入页面后，在上方的工具栏选择NOTIFICATION ENDPOINTS选项卡。

3、点击右上角的CREATE按钮，会弹出一个如下图所示的对话窗。

4、左上角的Destination有个下拉菜单，这个其实是报警终端的类型，可以看到此处为我们提供了 3 种终端，HTTP、Slack和Pagerduty。Slack和Pagerduty是海外开发团队常用的通讯软件，此处我们选择HTTP。

5、选择HTTP后，可以看到窗口中的配置项会发生变化。所谓HTTP终端，其实就是向一个目标地址发送POST请求。

6、我们暂时不向睿象云对接，而是想办法先去观察一下HTTP终端发出数据的数据结构。此处，在资料包中找到我们的辅助工具SimpleHttpPosyServer。将它拷贝的Linux虚拟机后，执行下述命令。

./simpleHttpPostServer-linux-x64

7、执行后，程序会监听 0 .0.0.0:8080地址。当它收到POST请求时，会在终端打印收到的数据。现在，我们可以将InfluxDB中的HTTP终端地址设为http://127.0.0.1:8080。如下图所示：

8、最后点击右下角的CREATE NOTIFICATION ENDPOINT，创建终端。

19.3.11 创建报警规则（NOTIFICATION RULES）

1、报警规则起到报警信息和终端之间的路由作用。报警规则可以指定哪些Check的何种级别的信息发送给哪个终端。

2、注意！创建报警规则的前提是已经创建了至少一个报警终端，否则 Web UI上的创建报警规则按钮会变成灰色，也就是无法创建报警规则。

3、首先在左侧工具栏点击 Alerts按钮，然后在上方的选项卡点击NOTIFICATION。接着点击CREATE按钮。

4、现在可以看到一个设置报警规则的弹窗。如下图所示。

5、最上方可以设置调度时间，看上去就像是一个定时任务。中间Conditions的意思是条件。比如现在默认的条件就是当 InfluxDB中有CHECK的状态为 CRIT时，就使用http_endpoint发送报警信息。需要注意中间的Conditions还有一个按钮叫做tag Filter，也就是按照标签过滤。首先，为了能够更快的看到报警效果，我们将调度的时间设为 15 秒。名字可以自己随便起。效果如下图所示。

6、在中间的Conditions区域，点击一下Tag Filter按钮，然后添加一个标签过滤条件为_check_name == CO_Alert。其中CO_Alert是我们之前创建的检查的名称。后面我们会讲到检查和通知规则的工作原理。此处先这样设置，设置后的效果如下图。

7、窗口最下方的Message区域，因为我们目前只有一个名为http_endpoint的终端，所以这里UI自动帮我们选择的http_enpoint，保持现状就好。

8、最后点击最下方的CREATE NOTIFICATION RULE按钮，创建规则。

19.3.12 测试报警信号发送效果

1、现在，我们要测试一下在InfluxDB里已经搭建好的报警链路。只需插入一条模拟的一氧化碳浓度的数据，让它的值大于 0 .04即可。插入的数据如下：

co,code=01 value=0.05

2、如图所示：

3、接下来，在左侧工具栏点击Alert History，来到报警历史页面，等待大概 15 秒。正常情况下，在检查状态历史记录里应该会出现一个级别为crit的状态信息。

4、点击上方的NOTIFICATIONS按钮，这时应该出现一个通知记录，这个列表里面是InfluxDB向外发送通知的记录。可以看到这条记录的最右边有一个绿色的对号，这说明我们的消息已经成功通过http_endpoint发送出去了。

5、回到之前开启simpleHttpPostServer的终端，看一下里面的内容。如图所示，我们成功收到一个 POST请求，并将它请求体中的数据打印在了控制台。

6、将这条json数据格式化后的效果如下,可以看到，其中包含了数据的时间，报警的消息，报警的级别，事发时的一氧化碳浓度值等等。如果能够在终端看到最终的json，说明InfluxDB的报警配置已经完成并且能够正常工作。

19.3.13 检查和报警规则的工作原理

1、之前我们设置报警规则的时候发现，配置报警规则是需要设置调度的时间间隔的，感觉上有些奇怪，为什么一个规则还需要每隔一段时间去执行一次呢？这要先从检查的工作原理开始讲起。

2、InfluxDB安装好后，会有一个由InfluxDB自动创建的名为_monitoring的存储桶。我们可以用DataExplorer去查询一下其中的内容。查询结果如下：

3、可以看到，查询的结果中，包含了Check任务生成的报警信息。比如有一个字段名为_check_name，值为CO_Alert，这就是我们之前设置的检查名称。也就是我们定时执行的Check，其实是定时从example_alert里面查询数据出来，然后对其进行阈值检查，最终，将检查后的状态信息写入到_monitoring存储桶中。效果如下图所示：

4、其实后面的通知策略也是一个定时任务，它从_monitoring查询最近一段时间的数据，并根据你设置的条件对数据进行过滤，最终如果有符合要求的数据，就使用我们的http_endpoint将数据转成json格式发送出去。最终整个流程如下图所示。

5、这也就是Check、Notification rule和Notification endpoint在一起工作的原理。

19.4 示例：集成睿象云（报警系统的Saas方案）

19.4.1 什么是睿象云

1、睿象云是一个告警平台，它提供五花八门的报警方式。你可以充值，选择电话报警，按照说明进行一下配置，之后你会得到一个API接口。以后，当你的系统需要报警时，只需在代码里想这个API发送一个http请求，睿象云就会按照你配置的电话号码，拨打电话，语音提醒程序员该加班了。

19.4.2 注册睿象云

1、官网地址：https://www.aiops.com/
2、注册过程（略）

19.4.3 创建自己的报警API

19.4.4 在睿象云上创建报警API

1、首先进入睿象云的首页，点击左侧的智能告警平台按钮，进入智能告警平台的工作页面。

2、如下图所示，点击上方选项卡的集成按钮，进入集成的配置页面

3、这个时候，左侧有一个监控工具列表，可以看到睿象云可以和很多监控工具进行集成，但是这个列表里面并没有InfluxDB，这个时候还有一种万能的集成方案，REST API。REST API会向外提供一个URL，只要你的监控工具能够以API要求的数据格式向睿
象云发送POST请求，那就可以同睿象云集成。

4、这时，我们会进入一个配置页面。首先需要设置一个应用名称。再点击下方的蓝色按钮，保存并获取应用key。

5、这个时候页面上会出现一行红字，这个就是Appkey。注意不要把这个key泄漏出去哦。

6、至此，我们的报警API就算是配置完了。

19.4.5 创建分派策略

1、现在外部可以通过接口向睿象云发送报警信息了，但是睿象云平台如何将报警信息发送给具体的个人呢。将报警信息转发给具体的人，这个过程叫做分派。

2、回到报警平台的主页，点击上方的配置按钮，然后再点击下方的右边的新建分派按钮。

3、此时会进入一个新的配置页面，可以按照下图的说明进行操作。注意，如果此处设置分派人的时候啥都不显示，说明你的账户目前还没有绑定邮箱，这个时候请自行绑定邮箱，再进行后面的操作。配置好后，点击保存。

4、现在，我们的TICK_TEST API一旦接收到报警信息，就会通知到具体的人了。

19.4.6 InfluxDB尝试与睿象云进行对接

1、现在，我们可以尝试与睿象云进行对接了，现在看来，只要让InfluxDB发出的通知数据符合睿象云API的要求就好了。我们可以回看一下刚才在睿象云创建的API的说明文档（在集成->右侧应用列表->找到你自己创建的REST API应用->点击编辑->页面下方可见）如下图所示，这里说明了我们应该发送什么格式的数据。

19.4.7 报警终端的不足

1、现在我们回到Web UI 的Alerts页面，并点击到http_endpoint的编辑页面。会发现，没有地方可以修改发送数据的格式。不错，InfluxDB的报警终端就是没法去设置发送的数据格式的。所以到这一步，我们前功尽弃了。但是这里还有一个方案，下一节我们会直接接触检查与报警的底层。

19.5 示例：Notebook与报警的底层

1、在之前，我们说过使用 Notebook也可以创建报警任务，但是之后就再也没有接触过Notebook。这一节，我们直接借助Notebook，走进报警的底层。

19.5.1 使用Notebook创建报警任务

1、首先，在左侧点击 Notebooks按钮，来到 Notebooks的配置页面。然后，点击Set an Alert模板，创建一个新的notebook。

2、进入Notebook后，会发现第一个Cell是一个查询构造器。此处，我们将存储桶设为example_alert，_measurement设为co，_field设为value。效果如下图所示：

3、点击上方的RUN按钮，查看执行效果。可以看到下方的两个 cell，一个cell是将查询出来的数据原样展示了出来，另一个是
将数据绘制成了折线图。

4、最后，下面还有一个cell，左上角有这个cell的名称，New Alert。也就是说明这个cell是用来配置报警的。

5、上方有两块，一个是用来设置报警条件的，另一个是用来设置调度间隔的。此处，我们还是按照需求，将报警阈值设为 0 .04。大家可能发现，我们此处的报警阈值只能设置一种，少了crit、warn、info和ok，这个问题我们后面会提到。设置好后的效果如下图所示。

6、再看到这个cell的底部，这是报警终端的配置。此处，我们还是选择http终端。并将目标URL设置为http://host1:8080。

7、上面的操作都完成后，点击右下方的EXPORT ALERT TASK按钮。

8、我们会惊喜地发现Notebook直接为我们生成了一个很长的FLUX脚本。如下图所示。现在，建议大家先将脚本复制出来，粘贴到Data Explorer里。稍后，我们自己研读这段脚本。

19.5.2 脚本解读

1、脚本如下：

import "strings"import "regexp"
import "influxdata/influxdb/monitor"
import "influxdata/influxdb/schema"
import "influxdata/influxdb/secrets"
import "experimental"
import "http"
import "json"
option task = {name: "Notebook Task for local_8dc089398e53-41532537902f", every: 10m, offset: 0s} - f5df-447e-

option v = {timeRangeStart: -24h, timeRangeStop: now()}
check = {_check_id: "local_8dc08939-f5df-447e-8e53-41532537902f",
_check_name: "Notebook Generated Check", _type: "custom", tags:
{}}
notification = {_notification_rule_id: "local_8dc08939-f5df-447e-
8e53Rule", _notification_endpoint_id: "local_8dc08939-41532537902f", _notification_rule_name: "Notebook Generated -f5df-447e-8e53-
41532537902f", _notification_endpoint_name: "Notebook Generated
Endpoint"}
task_data = from(bucket: "example_alert") |> range(start:
v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "co")
|> filter(fn: (r) => r["_field"] == "value")

trigger = (r) => r["undefined"] > 0
messageFn = (r) => "${strings.title(v: r._type)} for
${r._source_measurement} triggered at ${time(v: r._source_timestamp)}!"

task_data
|> schema["fieldsAsCols"](https://pdf2md.morethan.io/)
|> set(key: "_notebook_link", value:
"http://host1:8086/orgs/d2377c7832daa87c/notebooks/0a0bc4b03a6ba0
00")
|> monitor["check"](data: check, messageFn: messageFn, crit:
trigger)
|> monitor["notify"](

data: notification,endpoint: http["endpoint"](url:)( (^)
mapFn: (r) => {
body = {r with _version: 1}
return {headers: {"Content-Type":
"application/json"}, data: json["encode"](v: body)}
},
),
)

接下来，我们就按照从前到后的顺序为大家讲解这段代码。

19.5.2.1 导包

1、最上方的import代码我们直接跳过，不讲解了。

19.5.2.2 option task

1、option task其实就是对定时任务的设置，这一行代码其实也表名了，notebook帮我们生成的报警脚本本质上是一个InfluxDB的定时任务。

19.5.2.3 option v

1、第一行代码option v，声明了一个 record类型的变量，里面有两个键值对，其实分别表名了查询时间范围的开端和末端。这里显示-24h，其实是因为我们直接在notebook里面操作的时候，右上角的时间范围设置了-24h。后面我们会把它改成-15s。

19.5.2.4 check 和 notification两个变量

1、这两行代码分别声明了一个record，它其实是用来给后面的monitor函数做参数用的，因为_moitoring存储桶中需要_check_id和_check_name和_type等字段，所以notebook自动生成的时候自动帮我们安排好了。

19.5.2.5 查询数据

1、上图中的代码完成了对example_alert存储桶的查询。并且查询的表流被赋值给了一个名为task_data的变量。

19.5.2.6 声明阈值函数

1、此处，有一个名为trigger的函数，可见它的主体逻辑就是一个谓词表达式。在这里声明一个函数其实是因为后面有个monitor函数需要传入一个谓词函数。另外，可以看到这个函数的逻辑就是用来判断一氧化碳浓度是否超过 0 .04的。

19.5.2.7 消息模板

1、这也是一个函数，不过它直接返回一个字符串，这里面的内容其实是消息模板。

19.5.2.8 报警逻辑

1、接下来这一大段都是报警的逻辑。

• 首先schema[“fieldAsCols”]函数起到了转换数据结构的作用。效果如下图所示：
  
• set函数为表流添加了一个常量字段
• monitor[“check”]函数起到了检查状态的作用
  
  2、需要注意，data参数传进来的check变量其实就是_check_id，_check_name这些变量。messageFn是消息模板，crit在我们之前的CHECK里是一个报警级别，但是这里变成了函数的形参，传进来的函数值是trigger是我们之前提到过得谓词函数。

3、另外注意，虽然 notebook 帮我们生成的脚本里面值传递了 crit 参数，但是monitor[“check”]函数其实还有其他可传的参数。如下图所示：

4、可以看到，还有info、ok、warn参数。所以其实我们还是可以手动修改脚本把这些值域范围给补上的。

5、monitor[“notify”]函数是用来向外发送数据的，可以看到里面声明了一个http终端。最后，十分需要注意的是有一个名为body的局部变量。

6、这个其实就是我们发送POST请求的请求体。r是我们表流里面的数据，所以说，对接不上睿象云的症结就在这里。我们只需要将body修改成符合睿象云api要求的格式就可以了。

7、为什么我们不直接用if else的逻辑来完成大于小于检查然后直接向外发送请求，而是用两个专门的monitor函数来完成功能呢？主要是因为monitor函数会在我们的Alterhistory里留下痕迹。也就是monitior[“check”]和monitor[“notification”]函数会向_monitoring
存储桶里写检查和通知记录，这是非常重要的。

19.5.3 修改脚本以集成睿象云

1、最后，我们把body这个局部变量做一下修改，让它符合睿象云API要求的格式就好了。

2、修改好的代码如上图所示。

19.5.4 创建定时任务

1、点击左侧Tasks按钮，在点击右上方的CREATE TASK按钮，

2、将方才我们修改好的脚本粘贴到编辑区域，将option task一行代码中的信息写到左侧的设置表单中，并删除原先的option task代码。

3、最后点击右上角的Save按钮，创建这个定时任务

19.5.5 测试报警效果

1、现在，我们上传一条value大于 0 .04的数据，测试一下对接的效果。

2、等待一段时间，可以看到，我们收到了一通电话，这个电话里面就向我们说明了一氧化碳浓度的值超过 0 .04了。

19.6 示例：改进报警系统

19.6.1 当前的报警架构

1、你可以将睿象云视作一个高可用的报警服务，也就是不论如何睿象云 24 小时都能无故障访问。那么结合睿象云，我们的InfluxDB可以设置一个检查数据合理性的定时任务，每隔一段时间就把最近的数据抽出来算一下。如果数据不合适，就发送一个报警信号给睿象云，然后由睿象云向我们具体的技术人员发起通知。

19.6.2 更值得信任的架构

1、上一节的架构有一个问题，如果一晚上过去了，我的 InfluxDB出现异常宕机了。InfluxDB宕机了自然不会向睿象云发送报警信息，所以一夜过去了，你睡了一个好觉，但那真是一个平安夜吗？

2、所以，如果睿象云能够知道InfluxDB还有没有活着就好了。最好是睿象云能够每隔一段时间检查一下我的InfluxDB还在不在、能不能用。这种行为，我们称为业务可用性检查。在这张图中，橘黄色的箭头就是睿象云对InfluxDB的检查。

19.6.3 接下来示例中的架构

1、使用睿象云进行报警，其实是向睿象云购买软件服务，这套软件在睿象云的服务器上，而不是自己企业的服务器上。这种方式我们称为SaaS，软件即服务。这种情况下，想让睿象云能够反过来访问我们的 InfluxDB服务，那就得让InfluxDB服务暴露在公网。这个时候InfluxDB要么本身就在公网，要么利用内网穿透。因为这里的演示环境是内网，所以需要搭建内网传统。最终整体的架构如下。

2、这样，不管内网穿透崩了，还是InfluxDB崩了都会触发报警。

19.6.4 搭建内网穿透

1、本教程采用花生壳提供的内网穿透工具来实现内网穿透。一个新的花生壳账号，有免费的内网穿透额度，而且免费提供的 1 M大小的带宽

19.6.4.1 安装花生壳内网穿透客户端

1、访问官网下载页面：https://hsk.oray.com/download

2、注意选择和自己的系统匹配的安装包，我们演示的是使用的CentOS，所以此处我选择CentOS Linux(x86_64)

3、使用下面的命令安装deb包。

sudo rpm -ivh ./phddns_5.2.0_amd64.rpm

4、安装完成后，会自动开启一个名为Phtunnel的服务，并且你会拥有一个可以控制这项服务的命令行工具，叫做phddns。所有相关的信息，都显示在安装好后的打印出来的提示信息里了。

19.6.4.2 激活SN

1、正常情况下，安装好后，phddns会自动运行。可以使用phddns status命令查看程序的运行状态。

phddns status

2、如果显示ONLINE，那就是正常运行。注意这里的SN码，使我们的设备标识码。另外，这里显示我们有一个远程的管理地址，是http://b.oray.com。在浏览器里访问这个地址。会进入一个登录页面，如下图所示：

3、现在，切换到SN登录，可以看到这里需要输入我们的设备SN码。刚才安装的时候也提示过我们，初始密码是admin。现在输入SN码和密码，点击登录。

4、这里需要注册一个贝瑞账号，进行激活。

19.6.4.3 配置内网穿透

1、激活成功后，看到管理页面，先点击左侧工具栏的内网穿透按钮，进入内网穿透的管理面板，点击新增映射。

2、按照图中顺序先后操作，注意内网主机是指你刚才安装内网穿透所在的主机。试用版最高只能有 1 Mbps带宽，换算上行和下行速度应当在 128kb/s 点击确定后，会回到内网穿透的管理页面。

3、如果能看到下图所示的卡片，那就说明内网穿透已经配置成功。

4、以后我们访问 https://1674b87n99.oicp.vip/就相当是在访问本地的 1 27.0.0.1:8086了

19.6.5 配置业务可用性检测

19.6.5.1 创建监控任务

1、首先回到睿象云的主页，在左侧点击图中标出的业务可用性监测平台。

2、来到监控任务的主页后，点击图中标出的绿色按钮（创建监控）

3、首先完成监控设置，此处我们要把监控地址设成刚才我们配置过内网穿透的地址。地址使用/health，对这个地址发起Get请求，正常情况下会返回一个json格式的数据，它会告诉我们InfluxDB目前是否健康。另外，如果请求成功的话状态码应该为 200 。最后，对这个接口进行get请求，并不需要token加持。

4、响应部分设置如下图所示，解释一下，这里的意思就是如果接口 2 秒内完成响应那说明速度比较满意，如果在2~ 5 秒之间说明比较慢，如果大于 5 秒说明非常缓慢。

5、点击右上角的结果验证，设置响应码为 200 ，也就是说响应码为 200 是我们期望的正常状态。

6、监控频率设置使用 15 分钟，其实免费版最快只能每隔 15 分钟访问一次，充值后可以获得更高的访问频率

7、运营商与监控区域，是指你要使用哪个省份、哪个运营商的网络对你的接口发起访问，因为有的时候一个接口，可能移动的网络可以访问，联通的网就访问不通。最后我们只选择一台主机。如下图所示。

8、上述操作都完成后，点击右上角的保存按钮。

19.6.5.2 配置报警规则

1、回到监控列表后，可以看到页面上已经有一个监控项了。

2、现在点击左侧的告警按钮，我们来配置告警的通道。

3、可以看到，我们面对着 3 个概念：报警规则、报警策略、报警行为。和我们的InfluxDB一样，这里的报警规则对应着检查任务，它将数据翻译为警告、严重和正常三种信号。报警行为相当于报警终端，你可以选择发送邮件还是拨打电话。报警策略就是用来连接报警规则和报警行为的，它相当于InfluxDB中的报警规则。

4、首先我们来配置报警规则首先，点击左侧的报警规则按钮，然后点击+号

5、给规则命名、并在规则类型上选择API监控。

6、点击上方选项卡的报警对象，可以看到这里左边是已经创建的 API监控类型的监控任务，选中左边的InfluxDB健康状况，再点击中间的>> 按钮，将它加到已选列表里来，再点击下一步。

7、可以看到，这里要设置严重条件，这相当于我们在InfluxDB里面设置CRIT的阈值，此处我们设置为，如果过去 15 分钟的可用率不是 1 00%，那么就认为已经发生严重错误。如图所示，再次点击右下角的下一步。

8、这一步叫做警告条件，相当于InfluxDB中的warn。此处我们直接点击蓝色的按钮，从严重条件复制相同条件，然后再右下角点击保存。

9、最后，一切正常的话，我们的报警规则列表中就会多出一条，如下图所示。

19.6.5.3 配置报警行为

1、点击左侧的报警行为按钮，然后点击+号，创建一个新的报警行为。

2、在弹出的窗口上先选好行为类型，此处我们选择 Webhook。可以看到这里需要一个URL，它也相当于我们要向外发送一个请求。所以这个URL指定谁，其实还是应该对接到睿象云来做处理。

3、回到智能告警平台的集成页面，在集成工具中找到睿象云。点一下创建。

4、先命好名，然后直接点击下方的保存并获取应用key。

5、可以看到配置说明上的 url自动补全了一个随机字符串，这个就是key。现在将它复制一下。

6、回到创建报警行为的窗口中，填写 URL，再点击测试，如果测试结果显示为connect success，那就说明我们的配置是正确的。点击右下角的保存。

19.6.5.4 修改分派策略

1、现在我们的告警平台中，已经创建了两个应用了。但是直接我们之前创建过一个分派 策略，它会将 REST API收到的报警通知全部转发给某个用户。但是我们刚才创建的Webhook还尚未包含在这个分派策略中。所以此处，找到我们之前设置的分派策略，点击右边的编辑按钮。

2、进入编辑页面后，点击图中指出的添加按钮。

3、可以看到，此处我们就会展示出来两个应用，也就是这两个接口收到的报警通知都会转发给我们指定的用户。 最后点击保存，分派策略就修改成功了。

19.6.5.5 创建报警策略

1、回到之间的监控平台，告警管理页面。首先点击左侧的报警策略按钮，再点击+ 号，创建一个报警策略。

2、触发策略的配置如下图所示。

3、点击上方的触发行为设置按钮，然后点击右侧的添加按钮。

4、可以看到有一个可以进行选择的选项卡，这是我们之前创建的报警行为，鼠标点一下将它选中，然后点击右下角的选择按钮。

5、如果报警行为成功添加，就点击右下角的保存按钮。至此我们的报警策略就搭建成功了。