InfluxDB的检查和通知系统

作者：Anais Dotis-Georgiou / 产品
2021年4月19日

InfluxDB 2.0的检查和通知系统可能是目前最强大、最灵活的系统，用于根据时序数据创建警报。要充分发挥该系统的作用，了解不同的组件以及它们如何协同工作非常有帮助。阅读本文后，您应该能够使用InfluxDB 2.0用户界面（UI）创建精确的警报，并能够扩展和自定义系统以满足您的特定需求。

组件

与功能较弱、灵活性较差的警报系统不同，InfluxDB 2.0的检查和通知系统由五个组件组成，这些组件作为构建块可以组合使用，以创建您需要的精确功能。

检查、通知、通知规则、通知端点和状态是组成InfluxDB 2.0检查和通知系统的五个组件。这些高度可定制的组件使您能够构建警报，以便在时序数据中的复杂条件下采取高级纠正措施。

InfluxDB中的检查

InfluxDB中的检查是一种任务。任务是一个按计划或定义的频率运行的Flux查询。Flux是InfluxDB的功能性数据脚本语言。Flux允许您以几乎任何方式查询、转换和分析您的时序数据。检查查询数据并根据指定的条件对每个数据点应用状态或级别。检查的输出是一个状态，该状态写入“_monitoring”桶。“_monitoring”桶是一个默认内部桶。

创建检查有两种方式。您可以通过UI创建检查，也可以使用Flux编写自定义检查。在探讨使用InfluxDB创建检查的多种方法之前，重要的是要认识到UI使用InfluxDB v2 API，所有检查都使用Flux编写。因此，通过UI生成的检查将具有与自定义任务相同的性能。这正是InfluxDB和Flux的力量所在——开发者真正可以根据自己的需求定制时间序列工作负载。

InfluxDB UI中的阈值检查

创建检查的最简单方法是使用UI。您可以通过UI创建阈值检查或死信检查。要创建阈值或死信检查，请从右侧导航菜单转到UI中的警报页面，点击“+ 创建”，然后在检查面板下选择阈值或死信检查。通过UI创建阈值检查有两个步骤

1. 定义查询
2. 配置检查

要定义查询，请选择要创建检查的字段。接下来，将聚合函数应用于您的数据。平均值从窗口期计算，与“计划每”配置选项相匹配。聚合函数默认应用于数据有两个原因。首先，用户更倾向于关注数据趋势而不是原始时间序列数据。其次，默认的聚合间隔确保您的检查运行计划与聚合数据输出相一致。您可以通过更改下面的“计划每”配置选项来配置应用聚合的窗口期。

要配置阈值检查，您必须指定检查的属性、状态消息模板和阈值。

检查属性包括计划每，运行检查的间隔，和偏移，任务执行的延迟间隔。包括偏移量可以帮助您避免读写冲突并帮助成功缓冲指标。最后，标签属性允许您为检查输出添加自定义标签。此检查属性将为您的指定标签键添加新列，并为行添加标签值。

将标签添加到检查输出可以促进进一步的数据处理。例如，您可能决定仅在多个字段满足某些检查条件时实施纠正措施或安排响应。由于所有检查的输出都写入“_monitoring”存储桶，因此将这些相关字段添加标签将便于在这些检查上编写后续通知和/或任务，因为您可以通过过滤您添加的标签轻松查询所有相关检查状态数据。

状态信息模板允许您在通知和警报中包含自定义消息。这些状态信息可以帮助用户了解他们的检查内容，还可以用于提供与检查或通知端点相关的相关信息，以便将来使用和集成。默认状态信息看起来如下

检查：${ r._check_name } 状态：${ r._level }

然而，您可以选择在状态信息中包含来自“_monitoring”存储桶中检查输出中任何列的信息。状态信息中包含的列有

• _check_id：每个检查都分配一个检查ID。检查ID可以用于调试和重新运行失败的检查
• _check_name：您的检查名称——或者如上例中的“CPU Check”
• _level：UI检查的CRIT、WARN、OK或INFO（或对自定义检查可配置）
• _source_measurement：源数据的测量——或者如上例中的“cpu”
• _type：检查的类型——或者如上例中的“threshold”
• 查询输出中添加的自定义标签
• 查询中包含的列：要查看所有这些列，只需将鼠标悬停在查询中的一个点上。

阈值检查背后的Flux

要查看为您的阈值检查生成的相应Flux脚本，您可以使用InfluxDB v2 API或UI。要查看由UI生成的阈值检查的相应Flux脚本，请查看默认的“_task”系统存储桶。

要通过对UI进行过滤以找到相应的任务，您可以首先执行以下查询

from(bucket: "_tasks")
 |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
 |> filter(fn: (r) => r["_field"] == "name")

滚动查看结果，直到找到您的检查并收集相应的taskID。使用该taskID过滤您的任务，以找到检查的下层Flux。以下查询使用该taskID过滤包含检查下层Flux的日志。

from(bucket: "_tasks")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["taskID"] == "0754bba32a9ae300")
  |> filter(fn: (r) => r["_field"] == "logs")

如果您发现使用UI来揭示底层任务很麻烦，请阅读功能请求#1169并在您认为显示底层任务ID和检查ID对检查名称旁边有用时添加+1或评论。

要使用InfluxDB v2 API获取您由UI生成的检查的相应Flux脚本，请使用检查ID提交带有您的Token作为授权参数的GET请求。以下是一个示例cURL请求

curl -X GET \
  https://us-west-2-1.aws.cloud2.influxdata.com/api/v2/checks/074...my_check_ID...000/query \
  -H 'authorization: Token Oxxx….my_token...xxxBg==' \

快速获取检查ID的一种方法是查看URL，如果您在UI中编辑检查。

以下是请求的数据部分，其中包含通过UI为上述示例生成的检查生成的Flux（原始JSON输出已转义并已清理以供阅读）

package main 
import "influxdata/influxdb/monitor"
import "influxdata/influxdb/v1"

data = from(bucket: "telegraf")
|> range(start: -5s)
|> filter(fn: (r) =>(r["_measurement"] == "cpu"))
|> filter(fn: (r) =>(r["_field"] == "usage_system"))
|> filter(fn: (r) =>(r["cpu"] == "cpu-total"))
|> aggregateWindow(every: 5s, fn: mean, createEmpty: false)

option task = {name: "CPU Check", every: 5s, offset: 0s}
check = {_check_id: "074bba32a48c3000", 
  _check_name: "CPU Check",
  _type: "threshold",
 tags: {},}

crit = (r) =>r["usage_system"] > 5.0
messageFn = (r) =>("Check: ${ r._check_name } is: ${ r._level }")

data
|> v1["fieldsAsCols"]()
|> monitor["check"](data: check, messageFn: messageFn, crit: crit)

首先要注意的是，Flux 脚本使用了一个不太常见的 Flux 语法——用方括号代替点来表示成员表达式。尽管如此，我们可以看到通过这个对应的 Flux 脚本定义了在 UI 中生成阈值检查的步骤。我们想要创建检查的数据被分配给data 变量。使用aggregate Window()函数自动应用了聚合。检查实际上只是一个特殊类型的任务，这一点在聚合后面的行中定义的任务选项中得到强调。

检查参数定义在接下来的行中。创建自定义函数，定义所需字段的临界阈值和状态消息，以便可以将它们传递到最后一行的monitor.check()函数中。monitor.check()函数检查输入数据，为输出分配级别，并将输出写入“_monitoring”存储桶。最后，我们的查询数据data经过v1.fieldsAsCols函数的最后一次转换，然后传递给monitor.check()函数。这个转换函数是pivot()函数的特殊应用，它将数据旋转，使得字段被分隔到多个列中，而不是多个表中。这种形状转换使数据准备就绪，以便 Flux 可以轻松地将多个字段同时映射，以查看是否有任何字段值或字段组合超过阈值。

例如，如果您想同时评估两个字段，可以简单地更改上述 Flux 脚本中的crit 函数为crit = (r) =>r["usage_system"]> 5.0 and r["usage_user"] > 5.0。

重要提示：v1.fieldsAsCol() 函数是schema.fieldsAsCols()函数的已弃用版本。该问题#1114已记录，要求 UI 生成的检查使用 schema.fieldsAsCols() 函数。

InfluxDB UI 中的 Deadman Check

通过 InfluxDB UI 创建 Deadman Check 几乎与创建阈值检查相同。然而，在步骤 2）配置检查中，而不是指定阈值，您必须在检查属性下指定死信信号的持续时间。

死信检查背后的 Flux

要查看为您的死信检查生成的相应 Flux 脚本，您可以使用 InfluxDB v2 API 或 UI。获取死信检查相应 Flux 脚本的过程几乎与上述阈值检查相同。只需确保收集死信检查 ID。生成的死信 Flux 脚本与阈值检查也非常相似。

package main 
import "influxdata/influxdb/monitor"
import "experimental"
import "influxdata/influxdb/v1"

data = from(bucket: "telegraf") 
|> range(start: -15s) 
|> filter(fn: (r) =>  (r["_measurement"] == "cpu")) 
|> filter(fn: (r) =>  (r["_field"] == "usage_system")) 
|> filter(fn: (r) =>  (r["cpu"] == "cpu-total"))
option task = {name: "Deadman", every: 1m, offset: 0s}
check = { _check_id: "074bdadac4429000", 
     _check_name: "Deadman", 
     _type: "deadman", 
     tags: {deadman: "deadman"}}
crit = (r) => (r["dead"])
messageFn = (r) => (  "Check: ${r._check_name} is: ${r._level}")

data 
|> v1["fieldsAsCols"]() 
|> monitor["deadman"](t: experimental["subDuration"](from: now(), d: 5s)) 
|> monitor["check"](data: check, messageFn: messageFn, crit:crit)}

死信 Flux 脚本中与阈值 Flux 脚本明显不同的一行是倒数第二行。 monitor.deadman() 函数用于检测一个组何时停止报告数据。它接收一系列表，并报告自时间 t 以来是否观察到了数据。 experimental.subDuration() 函数嵌入在 monitor.deadman() 函数中，用于从当前时间值中减去一段时间，并评估信号是否已经停止了指定的时间范围。

创建自定义检查

InfluxDB UI 界面使得创建简单的死信和阈值检查变得非常容易，但它无法突出显示 InfluxDB 中检查系统的复杂性。Flux 允许您以任何您认为合适的方式转换数据，并定义自定义条件。编写自定义检查使您能够将任何 Flux 转换和自定义条件纳入您的检查。创建自定义检查的步骤与 UI 中的检查创建步骤类似。首先，查询您的数据并将该查询分配给一个变量。将变量分配给初始查询不是必需的，只是建议。接下来，实施检查的级别。如上所述，在 阈值检查背后的 Flux 部分，您可以通过更改级别的函数定义来分配自定义条件：crit = (r) => r["usage_system"] > 5.0 and r["usage_user"] > 5.0。

接下来，使用 monitor.check()  函数分配一个级别并将状态写入 “_monitoring”。您只能使用 monitor.check() 函数将 “CRIT”，“WARN”，“INFO” 和 “OK” 级别分配给您的时间序列数据。我们建议使用默认级别作为任何自定义级别的占位符。您可以在消息函数中包含有关默认级别如何与实际级别相关联的额外信息。例如，假设您想根据电池数据的斜率确定电池是在充电（“CH”）还是放电（“DH”）。您可以选择将自定义级别“CH”关联到“OK”，将“DH”关联到“CRIT”，并在您的状态消息中包含这种关联，以实现清晰和组织。在这种情况下，自定义检查可能看起来像这样

solarBatteryData = from(bucket: "solar")
|> range(start: -task.every)
|> filter(fn: (r) => r["_measurement"] == "battery")
|> filter(fn: (r) => r["_field"] == "kWh")
|> derivative(unit: 3s, nonNegative: false, columns: ["_value"], timeColumn: "_time")
option task = {name: "CPU Check", every: 5s, offset: 0s}
check = {_check_id: "0000000000000001", //alphanumeric, 16 characters  
    _check_name: "CPU Check",
    _type: "threshold",
    tags: {},}

ok = (r) =>r["_value"] > 0.0
crit = (r) =>r["_value"] =< 0.0
messageFn = (r) => ("Check: ${r._check_name} is: ${if r._level == "crit" then "DH" else "CH"}")

solarBatteryData
|> v1["fieldsAsCols"]()
|> monitor["check"](data: check, messageFn: messageFn, crit: crit, ok:ok)

通常认为，将所有状态合并到同一“_monitoring”桶中是一种最佳实践，以降低基数并使用monitor.check()函数通过组织数据来保持数据有序。技术上，您可以使用map()函数通过Flux编写具有除“CRIT”、“WARN”、“OK”和“INFO”之外的自定义级别的自定义状态。然而，我们强烈反对这种方法，因为您需要合并大量的模式转换，以便您的输出与“_monitoring”桶相匹配。此外，许多监控包中的有用函数都需要在状态中默认“CRIT”、“WARN”、“INFO”和“OK”级别才能运行。如果您需要为检查定义超过4个自定义级别，我们建议进行多个检查并实现有用的检查命名、自定义标签和消息。

InfluxDB检查的常见问题

通常，用户会创建一个检查，然后发现状态没有被写入“_monitoring”桶。他们还注意到，尽管底层任务运行成功，但检查无法写入状态。这种行为最可能是由于读写冲突引起的。这个障碍可能是InfluxDB检查（和通知）中最常见的陷阱之一，但解决方案很简单。给您的检查添加一个偏移量最有可能解决这个读写冲突。

InfluxDB检查的结论

如果读者能从本文档中吸取的一个要点，那就是所有检查、通知规则和任务都是在预定时间执行的Flux。如果您担心检查和任务之间的性能问题——请不要担心。检查只是底层的一个任务。

就像任何数据分析问题一样，我建议您熟悉Flux的功能并利用它们。使用UI来帮助您学习Flux、构建任务，并验证您的任务是否按预期运行。然后使用API执行、调试和维护这些任务以满足您的监控或物联网应用开发需求。《InfluxDB操作监控模板》（InfluxDB Operational Monitoring Template）是任务调试的优秀工具。

状态

状态是一种包含检查结果的时间序列数据类型。检查成功运行后，状态会被写入“_monitoring”桶。如上文中在“阈值检查”和“创建自定义检查”部分所述，状态包含来自源桶的数据组合和有关检查结果的信息。状态的模式如下

• _time：检查被执行的时间。
• _check_id：每个检查都会分配一个检查ID。检查ID可用于调试和重新运行失败的检查——一个标签。
• _check_name：您的检查名称（例如“CPU检查”）——一个标签。
• _level：对于UI检查是“CRIT”、“WARN”、“OK”或“INFO”（或对于自定义检查可配置）——标签。
• _source_measurement：您的源数据的度量（例如“cpu”）——一个标签。
• _measurement：状态数据（"状态"）的测量 - 一种测量。
• _type：检查的类型（例如，“阈值”） - 一个标签。
• _field：字段键。
  • _message：状态信息。
  • _source_timestamp：正在检查的源字段的时间戳，以ns精度。
  • ${你的源字段}：正在检查的源字段。
  • dead：针对死信检查的特定字段。一个布尔值，表示死信信号是否满足死信检查条件。
• 在检查配置期间添加到查询输出的自定义标签。
• 查询中包含的任何其他标签，由v1.fieldsAsCols函数产生。要查看所有这些标签，只需在数据探索器中悬停在查询的点上。

在InfluxDB UI中查看状态

在InfluxDB UI中有两个地方可以查看状态：通过警报页面和通过数据探索器。要通过对警报页面查看状态，点击检查面板中眼睛图标下的查看历史记录。

要通过对数据探索器查看状态，从“_monitoring”存储桶中选择数据。数据探索器会自动将aggregateWindow()函数应用于您的时间序列数据。状态包括包含字符串值的“状态信息”字段。因此，您可能会遇到以下错误消息

如果这种情况发生，并且您没有过滤掉字符串字段，请导航到脚本编辑器并取消注释(? + /)或删除聚合窗口()函数。

取消注释聚合窗口()函数允许您在InfluxDB UI中可视化状态。

在任务和检查之间取得平衡

在本文档的这一部分，希望您已经认识到检查只是底层的一个任务，但也认识到检查已在InfluxDB API中隔离。您可能还会想知道为什么在UI中查找底层任务很麻烦，以及为什么存在这种模糊化。这个决定是为了尝试鼓励用户在单独的任务中执行转换工作，并阻止他们将转换和数据分析工作放入检查中。换句话说，尽量保持您的自定义任务简单。

例如，假设您想创建一个基于两次测量之间两个字段差异的阈值检查。最佳实践是首先创建一个任务，使用join()函数将两个测量中的字段连接起来，使用map()函数计算它们之间的差异，并使用to()函数将输出写入新的测量或存储桶。然后创建一个简单的阈值检查，查询新数据。将数据处理工作隔离在单独的任务中提供了您对系统的更多可见性，并减少了检查的复杂性。

最后，如果您对将方法中提到的写入和基数增加到InfluxDB表示担忧，您始终可以将任务的输出写入具有小型保留策略的桶。特别是如果您正在检查中使用这些数据，可以将保留策略减少到每两次或三次“计划每”间隔。此设计建议也适用于下面的通知规则。

InfluxDB中的通知规则

InfluxDB中的通知规则是一种任务，类似于检查。通知规则查询“_monitoring”桶中的检查状态，将通知规则应用于状态，将通知记录到“_monitoring”桶中，并将通知消息发送到通知端点。通知是一种时间序列数据。与状态一样，通知也被写入“_monitoring”桶，是Flux任务的输出。虽然状态是检查的输出，但通知是通知规则的输出。通知端点是通知规则中的元数据，它使通知消息能够发送到第三方服务，如HTTP、Slack或PagerDuty。总结来说，将通知规则视为警报的同义词可能是有帮助的。然而，在InfluxDB API和InfluxDB UI中，这些任务被称为通知规则。

创建通知规则有两种方法。您可以通过UI创建通知规则，或者使用Flux编写自定义通知规则。在开始使用InfluxDB创建通知规则的各种方式之前，重要的是要认识到InfluxDB UI使用InfluxDB v2 API，并且所有通知规则都是用Flux编写的。因此，通过UI生成的通知规则将具有与自定义通知规则相同的性能。这正是InfluxDB和Flux的强大之处——开发者真正有权根据需要自定义他们的时间序列工作负载。

InfluxDB UI中的通知端点

在InfluxDB UI中创建通知规则的第一个步骤是配置通知端点。通知端点是您希望发送通知消息的第三方服务。配置通知规则的通知端点最简单的方法是通过InfluxDB UI。要创建通知端点，从右侧导航菜单导航到UI中的“警报”页面，然后单击“+ 创建”。通过UI创建通知端点有两个步骤

1. 指定您的目标
2. 指定选项

您可以通过InfluxDB UI配置HTTP、Slack和PagerDuty端点。以下示例中，我们创建一个名为“Slack Endpoint”的Slack通知端点。

InfluxDB UI中的通知规则

在InfluxDB UI中创建通知规则的第二个步骤是配置通知规则条件。这些用户定义的条件描述了哪些状态应转换为通知，以及类似地，哪些通知消息应发送到通知端点。

配置通知规则条件和创建通知规则的最简单方法是使用InfluxDB UI。要创建通知规则，请从右侧导航菜单转到UI中的“警报”页面，点击“+ 创建”。通过UI创建通知端点有三个步骤

1. 包括“关于”信息。
2. 指定通知规则的条件。
3. 配置通知消息选项。

作为“关于”信息配置的一部分，您必须命名您的通知规则，指定每多长时间运行一次间隔，并指定偏移间隔。在上面的示例中，我们命名我们的通知规则为“CPU Notification Rule”，每10分钟运行一次。对于通知条件，您必须定义要创建通知并发送通知消息的状态类型。在上面的示例中，我们仅在状态级别等于“CRIT”时创建通知。我们还为此通知规则添加了一个标签；此标签将此通知规则限制为单个检查 - “CPU检查”。此标签是可选的。如果没有添加，则我们的通知规则将为所有具有“_level”为“CRIT”的状态发送警报。

最后，指定通知消息选项，包括我们希望发送通知消息的端点和消息内容。我们选择了我们刚刚创建的通知端点，“Slack Endpoint”。默认通知消息如下

Notification Rule: ${ r._notification_rule_name } triggered by check: ${ r._check_name }: ${ r._message }

但是，您可以选择包括通知规则输出中包含在“_monitoring”存储桶中的任何列的信息。通知的架构在下面的“通知”部分中描述。

通知规则背后的Flux

要查看生成的相应Flux脚本，您可以使用InfluxDB v2 API或UI。要查看由UI生成的通知规则的相应Flux脚本，请遵循“阈值检查背后的Flux”部分下的说明，因为过程是相同的。

要使用InfluxDB v2 API 获取由UI生成的通知规则的相应Flux脚本，请使用通知规则ID提交带有您的Token作为授权参数的GET请求。以下是一个cURL请求示例

curl -X GET \
  https://us-west-2-1.aws.cloud2.influxdata.com/api/v2/notificationRules/075...my_cnotification_rule_id...000/query \
  -H 'authorization: Token Oxxx….my_token...xxxBg==' \

快速获取通知规则ID的方法是查看您在UI中编辑通知规则时的URL。

以下是请求的数据部分，其中包含生成上述示例通知规则的UI的Flux（原始JSON输出已被转义并清理以提高可读性）

package main
//CPU Notification Rule 
import "influxdata/influxdb/monitor"
import "slack"
import "influxdata/influxdb/secrets"
import "experimental"
option task = {name: "CPU Notification Rule ", 
               every: 10m, 
               offset: 0s}
slack_endpoint = slack["endpoint"](url: "https:hooks.slack.com/services/xxx/xxx/xxx")
notification = {_notification_rule_id: "0758afea09061000",
                _notification_rule_name: "CPU Notification Rule ",
                _notification_endpoint_id: "0754bad181a5b000",
                _notification_endpoint_name: "My slack",}
statuses = monitor["from"](start: -10s, fn: (r) = r["_check_name"] == "CPU Check")
crit = statuses 
       |> filter(fn: (r) => r["_level"] == "crit")
all_statuses = crit 
               |> filter(fn: (r) => (r["_time"] >= experimental["subDuration"](from: now(), d: 10m)))

all_statuses 
|> monitor["notify"](data: notification, 
                     endpoint: slack_endpoint(mapFn: (r) = (
{channel: "", 
 text: "Notification Rule: ${ r._notification_rule_name } triggered by     check: ${ r._check_name }: ${ r._message }", 
 color: if r["_level"] == "crit" then "danger" else if r["_level"] == "warn" then "warning" else "good"})))

我们可以看到通过此相应的Flux脚本定义了在UI中生成通知规则的步骤。任务选项被分配给包含通知规则名称、每多长时间运行一次间隔和偏移间隔的option task 变量。使用slack.endpoint() 函数来配置Slack通知端点。Flux中的每个通知端点包都包含一个消息和一个端点函数

• 消息函数向目标发送单个消息。
• 端点函数是一个工厂函数，它输出另一个函数。

输出函数需要一个mapFn参数。然后mapFn构建用于生成POST请求的对象。虽然消息函数可以向您的目标发送通知消息，但端点函数还会将通知写入“_monitoring”存储桶，并将附加的额外通知数据附加到您的通知中，具体是存储在notification 变量中的数据。

我们想要创建通知的状态被分配给statuses 变量。函数monitor.from()检索存储在“_monitoring”存储桶中的状态测量中的检查状态。我们的标签将通知规则的范围限定在我们的“CPU Check”检查的状态上，在monitor.from()函数中应用。状态级别条件存储在crit 变量中，它对具有“CRIT”级别的状态进行过滤，这些状态来自statuses。变量all_statuses 使用实验性的subDuration()函数过滤出用“Schedule Every”间隔写入的“CRIT”级别状态。最后，将all_statuses 输出输入到monitor.notify()函数。此函数有两个必需参数：数据和endpoint。数据参数包括您想要附加到通知中的附加信息。endpoint参数指定构建和发送通知的函数，即slack_endpoint。

创建自定义通知规则

InfluxDB UI使创建简单的通知规则变得非常容易，但它无法突出显示InfluxDB中通知系统的复杂性。Flux允许您以您喜欢的几乎任何方式转换数据。创建自定义通知规则的分步方法与UI中定义的步骤类似。可以将相同的逻辑应用于创建自己的自定义通知规则。虽然UI允许您配置HTTP、Slack和PagerDuty的通知端点，但Flux有许多更多可以利用的通知端点包。

对于我们的自定义通知规则，我们将使用Telegram Flux Package将通知发送到Telegram，而不是Slack。在编写自定义通知规则时，请确保导入正确的通知端点包，import "contrib/sranka/telegram"。然后配置端点函数。Telegram.endpoint()函数需要您指定您的Telegram机器人令牌。在这个自定义通知规则中，我们将在我们状态级别是“CRIT”或“WARN”时发送通知。这个额外的过滤被分配给critOrWarn变量。最后，请确保包含一个_notification_rule_id和一个_notification_endpoint_id。这些ID必须是16个字符长，且是字母数字。

package main
//CPU Notification Rule for Telegram 
import "influxdata/influxdb/monitor"
// import the correct package
import "contrib/sranka/telegram"
import "influxdata/influxdb/secrets"
import "experimental"
option task = {name: "CPU Notification Rule for Telegram ", 
               every: 10m, 
               offset: 0s}
telegram_endpoint = telegram["endpoint"](
  url: "https://api.telegram.org/bot",
  token: "S3crEtTel3gRamT0k3n",
)

notification = {_notification_rule_id: "0000000000000002", //alphanumeric, 16 characters 
                _notification_rule_name: "CPU Notification Rule for Telegram",
                _notification_endpoint_id: "0000000000000002", //alphanumeric, 16 characters 
                _notification_endpoint_name: "My slack",}
statuses = monitor["from"](start: -10s, fn: (r) = r["_check_name"] == "CPU Check")
critOrWarn = statuses 
       |> filter(fn: (r) => r["_level"] == "crit" or r["_level"] == "warn") //altered to include two levels
all_statuses = critOrWarn 
               |> filter(fn: (r) => (r["_time"] >= experimental["subDuration"](from: now(), d: 10m)))

all_statuses 
|> monitor["notify"](data: not

规则化，端点：slack_endpoint(mapFn: (r) = ( {channel: “”，text: “通知规则：${ r._notification_rule_name } 由检查：${ r._check_name }：${ r._message } 触发”，color: if r[“_level”] == “crit” then “danger” else if r[“_level”] == “warn” then “warning” else “good”})))</code></pre> 最后，请注意，您还可以使用其他 Flux 函数来进一步自定义您的通知规则和 监控状态

• stateDuration()：允许您确定 状态持续的时间。
• stateCount()：允许您 计算连续状态的数量。

此外，Flux InfluxDB 监控包不仅仅包含monitor.notify()和monitor.from()函数。使用以下函数可以增加您自定义通知规则的复杂性

• monitor.stateChanges()：允许您检测'_level'列从一个级别到另一个特定级别的变化。
• monitor.stateChangesOnly()：允许您检测'_level'列中任何级别到任何其他级别的所有变化。

通知

通知是通知规则的输出时间序列数据。了解状态和通知之间的平行关系是有帮助的。状态是检查的，就像通知是通知规则的一样。因此，通知紧密匹配状态，并包含以下架构

• _time：通知规则执行的日期和时间。
• _check_id：每个检查都会分配一个检查ID。检查ID可以用于调试和重新运行失败的检查 - 一个标记。
• _check_name：您的检查名称（例如“CPU检查”） - 一个标记。
• _notification_rule_id：每个通知规则都会分配一个通知规则ID。通知规则ID可以用于调试和重新运行失败的通知规则 - 一个标记。
• _notification_rule_name：您的通知规则名称（例如“CPU检查通知规则”） - 一个标记。
• _notification_endpoint_id：每个通知端点都会分配一个通知端点ID。通知端点ID可以用于调试和重新运行失败的通知规则 - 一个标记。
• _source_measurement：您的源数据度量（例如“cpu”） - 一个标记。
• _measurement：通知规则数据（'notifications'）的度量 - 一个度量。
• _sent：表示通知消息是否已发送到通知端点的布尔值 - 一个标记
• _type：您的通知规则应用到的检查类型（例如“阈值”） - 一个标记。
• _level：相应检查的级别（例如“CRIT”） - 一个标记。
• _field：字段键。
  • _message：通知消息。
  • _status_timestamp：分配给您的源字段的状态的时间戳，精确到纳秒。
  • _source_timestamp：正在检查的源字段的时间戳，精确到纳秒。
  • ${your source field}：正在检查的源字段值。
• 在通知配置期间添加到查询输出的自定义标签。
• 查询中包含的任何其他列，这些列来自相应检查的 v1.fieldsAsCols 函数。

关于InfluxDB检查和通知系统的进一步阅读和资源

虽然本文旨在全面概述InfluxDB中检查和通知系统的功能，但以下资源也可能引起您的兴趣

1. TL;DR InfluxDB技术技巧 - 监控任务和找到卡迪纳尔性失控的源头：本文描述了应用操作监控模板的优势。此模板可以帮助您确保任务运行成功。例如，假设您已将自定义标签作为UI生成的检查的一部分，并且这些标签包含在状态消息中。如果负责添加这些标签的底层任务失败，则检查将失败。应用 操作监控模板 可以帮助您发现自定义任务或检查失败的根本原因。
2. TL;DR InfluxDB技术技巧 - 使用任务和检查进行InfluxDB监控：本文详细描述了创建UI生成的检查的基本知识及其局限性，以防您需要。
3. TL;DR InfluxDB技术技巧 - 如何使用InfluxDB监控状态：本文描述了 Flux InfluxDB 监控包 的某些复杂性和功能，这对于任何希望使用InfluxDB执行有意义任务的开发者来说是必要的工具。
4. TL;DR InfluxDB技术技巧：配置InfluxDB的Slack通知：本文展示了如何通过UI创建Slack通知。具体来说，如何启用Slack集成和收集Slack Webhook URL。
5. 自定义检查：来自文档的另一个自定义检查示例。使用此自定义检查作为模板，帮助您使用Flux制作自定义检查。
6. Telegram Flux包：本教程演示了如何设置Telegram机器人并使用Telegram Flux包进行自定义通知规则。
7. 贡献第三方Flux包：Discord端点Flux函数：本文描述了如何贡献您自己的第三方Flux包。具体来说，它描述了如何贡献Discord端点包。如果所需的Flux通知端点包不可用，请考虑贡献一个自己编写的包！

InfluxDB检查和通知系统的结论

InfluxDB的检查和通知系统高度可定制，并允许用户对其时序数据进行操作。所有检查和通知都是在底层作为Flux任务执行的。检查和通知与其他任务的主要区别在于，它们会读取和写入到‘_monitoring’桶中的数据。它们还使用专门的Flux包，如Flux InfluxDB监控包和通知端点包。

希望这篇帖子能激发您利用InfluxDB的检查和通知系统，并构建自己的自定义检查和通知。请在评论区域、我们的社区网站或我们的Slack频道分享您的想法、担忧或问题。我们非常乐意听取您的反馈并帮助您解决遇到的问题！而且，像往常一样，我们鼓励您分享您的经历，并让我们了解您使用InfluxDB开发的项目。