Link Search Menu Expand Document
Time to Awesome

检查和通知

目录

  1. 组件
  2. InfluxDB 中的检查
    1. InfluxDB UI 中的阈值检查
    2. 阈值检查背后的 Flux
    3. InfluxDB UI 中的失效检查
    4. 失效检查背后的 Flux
    5. 创建自定义检查
    6. InfluxDB 检查的常见问题
    7. InfluxDB 检查总结
  3. 状态
    1. 在 InfluxDB UI 中查看状态
  4. 在任务和检查之间取得平衡
  5. InfluxDB 中的通知规则
  6. InfluxDB UI 中的通知端点
  7. InfluxDB UI 中的通知规则
    1. 通知规则背后的 Flux
    2. 创建自定义通知规则
  8. 通知

InfluxDB 2.0 的检查和通知系统可能是目前基于时间序列数据创建警报的最强大、最灵活的系统。为了充分利用该系统，了解不同的部分及其如何组合在一起非常有帮助。阅读本文后，您应该能够使用 InfluxDB 2.0 用户界面 (UI) 创建精确的警报，并且能够扩展和自定义系统以满足您的特定需求。

组件

与功能较弱、灵活性较差的警报系统不同，InfluxDB 2.0 检查和通知系统包含五个组件，这些组件可以组合起来创建您需要的精确功能。

components

检查和通知系统的五个组件概述。这些高度可定制的组件使用户能够以有价值的方式对其时间序列数据采取行动。

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

InfluxDB 中的检查

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

checks diagram

检查使用 Flux 来识别您的时间序列数据是否满足定义的条件，并将状态输出到“_monitoring”桶。状态可以自定义，但通常为“OK”（绿色）、“WARN”（黄色）和“CRIT”（红色）。

您可以通过两种方式创建检查。您可以通过 UI 创建检查，也可以使用 Flux 编写自定义检查。在开始使用 InfluxDB 制作检查的多种方法之前，务必认识到 UI 使用 InfluxDB v2 API，并且所有检查都是用 Flux 编写的。因此，通过 UI 生成的检查与作为任务制作的自定义检查的性能一样好。这就是 InfluxDB 和 Flux 的强大之处——开发人员真正能够根据自己的需要自定义他们的时间序列工作负载。

InfluxDB UI 中的阈值检查

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

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

要定义查询，请选择要创建检查的字段。接下来，将聚合函数应用于您的数据。平均值是根据窗口周期计算的，该窗口周期与“计划每”配置选项匹配。默认情况下，聚合函数应用于您的数据有两个原因。首先，用户更喜欢对数据趋势发出警报，而不是原始时间序列数据。其次，此默认聚合间隔可确保您的检查运行计划与您的聚合数据输出一致。您可以通过更改“计划每”配置选项来配置应用聚合的窗口周期，如下所述。

threshold check

定义查询并应用聚合函数。这里我们正在 usage_system 字段上创建一个名为“CPU 检查”的 CPU 检查。

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

threshold check

配置阈值检查。如果值超过 5，我们将 usage_system 级别设置为“CRIT”。该检查计划每 5 秒运行一次，偏移量为 0 秒，并且当 usage_system 超过阈值时，状态消息将显示“检查：CPU 检查为：CRIT”。

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

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

**状态消息模板**允许您在通知和警报中包含自定义消息。这些状态消息可以帮助用户了解他们的检查内容，它们还可以用于提供与检查或通知端点相关的重要信息，以供将来使用和进一步集成到数据管道中。默认状态消息如下所示

Check: ${ r._check_name } is: ${ r._level }

但是，您可以选择在状态消息中包含“_monitoring”桶中检查输出中任何列的信息。状态中包含的列是

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

additional columns

查询中包含的其他列包括“_time”、“_value”、“_field”、“_measurement”、“cpu”和“host”。

阈值检查背后的 Flux

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

flux behind threshold

“_value”列包含许多有关相应任务的信息，包括 Flux 脚本。使用 taskID 和日志过滤相应的任务。

要通过 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 提交 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 的一种快速方法是在 UI 中编辑检查时查看 URL。

check id

以下是请求的相应数据部分，其中包含通过 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 语法。它使用方括号而不是点来表示成员表达式。无论如何，我们可以看到在 UI 中生成阈值检查的步骤是如何由相应的 Flux 脚本定义的。我们要创建检查的数据被分配给 data 变量。使用 aggregateWindow() 函数自动应用聚合。检查实际上只是一种特殊类型的任务，这一点在聚合后一行的任务选项定义中得到了强调。

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

例如，如果要创建一个同时评估两个字段的检查，只需将上面 Flux 脚本中的 crit 函数更改为 crit = (r) =>r["usage_system"]> 5.0 and r["usage_user"] > 5.0。

before fieldsascol

在应用 v1.fieldsAsCol() 函数之前，过滤两个字段“usage_user”和“usage system”。数据被分成两个表，每个字段一个表。

after fieldsascol

应用 v1.fieldsAsCol() 函数后，数据在一个表中，字段在不同的列中分开。

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

InfluxDB UI 中的失效检查

通过 InfluxDB UI 创建失效检查与创建阈值检查几乎相同。但是，您无需指定阈值，而必须在步骤 2) **配置检查** 中的检查属性下指定失效信号的持续时间。

deadman

在“配置检查”页面的右侧面板中指定失效配置选项。失效配置包括失效信号的持续时间以及在信号失效该持续时间后何时停止执行检查。

失效检查背后的 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() 函数使数据保持井然有序。从技术上讲，您可以使用 Flux 通过使用 map() 函数来编写具有“CRIT”、“WARN”、“OK”和“INFO”以外的自定义级别的自定义状态。但是，我们强烈**警告**不要使用这种方法，因为您需要合并许多架构转换，以便您的输出与“_monitoring”桶的输出匹配。此外，监控包中的许多有用函数都需要状态中的默认级别“CRIT”、“WARN”、“INFO”和“OK”才能运行。如果需要为检查定义 4 个以上的自定义级别，我们建议进行多次检查并实现有用的检查命名、自定义标签和消息。

InfluxDB 检查的常见问题

用户经常会创建一个检查，却发现没有状态写入“_monitoring”桶。他们还注意到，即使底层任务运行成功，检查也未能写入状态。这种行为很可能是由读/写冲突引起的。这个障碍可能是 InfluxDB 检查（和通知）中最常见的陷阱，但解决方案很简单。向检查添加偏移量很可能会解决此读/写冲突。

offset

配置检查的“计划每”和“偏移”参数。

InfluxDB 检查的结论

如果读者应该从本文档中得到一个结论，那就是所有检查、通知规则和任务都只是按计划执行的 Flux。如果您担心检查和任务之间的性能问题，请不要担心。检查只是底层的一个任务。

checks final diagram

InfluxDB 中的检查是一种任务。具体来说，UI 生成的检查是一个任务，其中包含定义阈值级别或失效条件的生成函数。然后将这些函数传递给 monitoring.check() 函数，检查的输出是一个状态，该状态被写入系统“_monitoring”桶。自定义检查通常会镜像 UI 生成的检查，但不一定局限于该代码模式。

与任何数据分析问题一样，我建议您熟悉 Flux 的功能并利用它们来发挥自己的优势。使用 UI 来帮助您学习 Flux、制作任务并验证您的任务是否按预期运行。然后使用 API 执行、调试和维护这些任务，以满足您的监控或物联网应用程序开发需求。InfluxDB 运行监控模板 是一个优秀的任务调试工具。

状态

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

  • _time：执行检查的时间。
  • _check_id：每个检查都分配有一个检查 ID。检查 ID 可用于调试和重新运行失败的检查 - 一个标签。
  • _check_name：检查的名称（例如“CPU 检查”）- 一个标签。
  • _level：对于 UI 检查，为“CRIT”、“WARN”、“OK”或“INFO”（或对于自定义检查可配置）- 标签
  • _source_measurement：源数据的度量（例如“cpu”）- 一个标签。
  • _measurement：状态数据的度量（“status”）- 一个度量。
  • _type：检查的类型（例如“threshold”）- 一个标签。
  • _field：字段键。
    • _message：状态消息。
    • _source_timestamp：正在检查的源字段的时间戳（纳秒精度）
    • ${your source field}：正在检查的源字段。
    • dead：失效检查特有的附加字段。一个布尔值，表示失效信号是否已满足失效检查条件。
  • 在检查配置期间添加到查询输出的自定义标签。
  • 查询中包含的任何其他标签，由 v1.fieldsAsCols 函数生成。要查看所有这些标签，只需将鼠标悬停在**数据资源管理器**中查询中的某个点上。

additional tags

Additional columns included in the query include “cpu” and “host”.

在 InfluxDB UI 中查看状态

在 InfluxDB UI 中有两个位置可以查看状态：通过**警报**页面和**数据资源管理器**。要通过**警报**页面查看状态，请单击**检查**面板中**眼睛图标**下的**查看历史记录**。

statuses alerts

要通过数据资源管理器查看状态，请选择“_monitoring”桶中的数据。数据资源管理器会自动将 aggregateWindow() 函数应用于您的时间序列数据。状态包含一个状态消息字段，其中包含字符串值。因此，您可能会遇到以下错误消息

statuses with aggreagate window

在 UI 中查看状态。数据资源管理器会自动应用 aggregationWindow() 函数，该函数不支持字符串或状态消息字段值。

如果是这种情况，并且您尚未过滤掉字符串字段，请导航至脚本编辑器并注释掉 (⌘ + /) 或删除 aggregationWindow() 函数。

statuses monitoring without aggregate window

注释掉或删除 aggregateWindow() 函数以绕过上述错误消息。

注释掉 aggregateWindow() 函数后，您就可以在 InfluxDB UI 中可视化您的状态。

平衡任务和检查

到目前为止，您应该已经认识到检查本质上就是一个任务，但也了解到检查在 InfluxDB API 中已被隔离。您可能还会想知道，为什么在 UI 中查找底层任务很麻烦，以及为什么存在这种模糊性。做出这一决定的目的是为了鼓励用户在单独的任务中执行转换工作，并阻止他们在检查中塞入转换和分析工作。换句话说，尽量保持自定义任务的简单性。

例如，假设您要对来自不同测量的两个字段之间的差值创建阈值检查。最佳实践是首先创建一个任务，使用 join() 将两个测量值中的字段连接起来，使用 map() 计算它们之间的差值，然后使用 to() 函数将输出写入新的测量值或桶。然后创建一个简单的阈值检查来查询新数据。将数据处理工作隔离在一个单独的任务中，可以提高您对系统的可见性，并降低检查的复杂性。

最后，如果这里提到的方法让您担心会增加 InfluxDB 的写入量和基数，您可以随时将任务的输出写入具有较短保留策略的桶中。特别是如果您在检查中使用该数据，您可以将保留策略减少到“计划每”间隔的 2 或 3 倍。此设计建议也适用于下文讨论的通知规则。

InfluxDB 中的通知规则

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

notifications diagram

通知规则从“_monitoring”桶中查询状态。通知规则检查是否满足状态条件，将通知记录到“_monitoring”桶，并将通知消息发送到通知端点。

创建通知规则有两种方法。您可以通过 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 通知端点，并将其命名为“Slack 端点”。

notification endpoint

指定 Slack 作为目标，并为通知端点配置 Slack 选项。阅读以下博客，了解有关如何 收集 Slack Incoming Webhook URL 的更多信息。

InfluxDB UI 中的通知规则

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

notification rule diagram

通知规则使用 Flux 来识别您的状态是否满足用户定义的条件，并将通知输出到“_monitoring”桶。例如，当状态的级别为“WARN”（黄色）和“CRIT”（红色）时，通知将记录到“_monitoring”中，并且通知消息将发送到通知端点。

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

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

notification rule gif

创建通知规则。配置通知规则、指定条件并创建通知消息。

作为关于信息配置的一部分，您必须命名您的通知规则，指定计划每间隔，并指定偏移间隔。在上面的示例中，我们将通知规则命名为“CPU 通知规则”，并将“计划每”间隔设置为 10 分钟。对于通知条件，您必须定义要为其创建通知并将通知消息发送到的状态类型。在上面的示例中，我们仅在状态级别等于“CRIT”时才创建通知。我们还为此通知规则添加了一个标签；该标签将此通知规则的作用域限定为单个检查——“CPU 检查”。此标签是可选的。如果未添加，则我们的通知规则将为每个“_level”为“CRIT”的状态发送警报。

最后，指定通知消息选项，包括要将通知消息发送到的通知端点以及您希望消息读取的内容。我们选择刚刚创建的通知端点“Slack 端点”。默认通知消息如下所示

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 提交 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。

notification rule id

以下是请求的相应数据部分，其中包含通过 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 中的每个通知端点包都包含一个 message 函数和一个 endpoint 函数

  • message 函数向目标发送单个消息。
  • endpoint 函数是一个输出另一个函数的工厂函数。

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

我们要创建通知的状态被分配给 statuses 变量。monitor.from() 函数检索存储在“_monitoring”桶中 statuses 度量中的检查状态。我们的标签，它将通知规则的作用域限定为来自我们检查“CPU Check”的状态，在 monitor.from() 函数中应用。状态级别条件存储在 crit 变量中，该变量过滤 statuses 的输出，以获取级别为“CRIT”的状态。all_statuses 变量使用 experimental.subDuration() 函数来过滤以**计划每**个间隔写入的“CRIT”级别状态。最后，all_statuses 输出被馈送到 monitor.notify() 函数。此函数有两个必需参数：data 和 endpoint。data 参数包含要附加到通知的附加信息。endpoint 参数指定构造并发送通知的函数，即 slack_endpoint。

创建自定义通知规则

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

custom notification rule

Flux 提供了广泛的通知端点包，包括 Discord、Telegram、Opsgenie、VictorOps、bigpanda、Sensu 等。

对于我们的自定义通知规则，我们将使用 Telegram Flux 包 将通知发送到 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: 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 函数来进一步自定义您的通知规则和监控状态。

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

通知

通知是作为通知规则输出的时间序列数据。识别状态和通知之间的并行关系很有帮助。状态之于检查，如同通知之于通知规则。因此，通知与状态紧密匹配，并包含以下架构：

  • _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：通知规则应用于的检查类型（例如“threshold”）- 一个标签。
  • _level：相应检查的级别（例如“CRIT”）- 一个标签。
  • _field：字段键。
    • _message：通知消息。
    • _status_timestamp：分配给来自已检查源字段的状态的时间戳，以纳秒精度。
    • _source_timestamp：正在检查的源字段的时间戳，以纳秒精度。
    • ${您的源字段}：正在检查的源字段值。
  • 在通知配置期间添加到查询输出的自定义标签。
  • 查询中包含的任何其他列，来自相应检查的 v1.fieldsAsCols 函数的结果。

下一节