在计划停机期间处理Kapacitor警报

在许多情况下，基础设施停机是进行系统维护所必需的。这种类型的停机通常是提前安排的，但如果受影响的主机由Kapacitor监控，则可能会触发不必要的警报。本指南介绍了如何创建TICKscripts，以优雅地处理计划的停机而不触发警报。

侧载

通过使用sideload节点从文件系统加载信息，避免在计划的停机期间发出不必要的警报，并设置数据点上的字段和标签，这些字段和标签可以在警报逻辑中使用。sideload节点根据来自各种基于文件的源的层次数据为数据点添加字段和标签。

Kapacitor 在指定的文件中搜索给定的字段或标签键。 如果在加载的文件中找到了字段或标签键，它会使用文件中的值来设置数据点上的字段或标签。 如果没有找到字段或标签键，它将把它们设置为在 field 或 tag 属性中定义的默认值。

相关的侧载属性

以下sideload的属性与优雅处理计划停机相关：

来源

source 指定一个源文件所在的目录。

订单

order 指定了加载和搜索的文件以及它们的加载和搜索顺序。文件路径相对于 source 目录。文件应为 JSON 或 YAML 格式。

字段

field 定义了一个字段键，Kapacitor 应该在加载的文件中搜索该字段键，如果找不到匹配的字段键，则使用默认值。

标签

tag 定义了一个标签键，Kapacitor 应该搜索这个标签键，以及如果在加载的文件中找不到匹配的标签键时，它应该使用的默认值。

设置

使用 sideload 函数，您可以创建一个实际上是要在计划停机期间忽略的主机的白名单或黑名单。对于这个例子，假设维护将在单个主机和主机组上进行，这两个都被作为标签包含在数据集的每个点上。

在大多数情况下，这可以简单地通过主机完成，但为了说明order属性是如何工作的，我们将同时使用主机和主机组。

侧载源文件

在运行Kapacitor的主机上，创建一个源目录，用于存放JSON或YAML文件。 例如， /usr/kapacitor/scheduled-maintenance (它可以是任何你想要的，只要kapacitord进程可以访问它).

在此目录中，为每个将在计划停机期间离线的主机或主机组创建一个文件。为了组织管理，创建 hosts 和 hostgroups 目录，并将 YAML 或 JSON 文件存储在每个目录中。每个文件的名称应与将要离线的主机的 host 或 hostgroup 标签的值相匹配。

对于这个例子，假设host1、host2、host3 主机和cluster7 和cluster8 主机组将被下线。
为这些主机和主机组在各自的目录中创建一个文件：

/usr/
└── kapacitor/
    └── scheduled-maintenance/
        │
        ├── hosts/
        │   ├── host1.yml
        │   ├── host2.yml
        │   └── host3.yml
        │
        └── hostgroups/
            ├── cluster7.yml
            └── cluster8.yml

您只需要为将离线的主机或主机组创建文件。

文件的内容应该包含一个或多个键值对。 键是将设置在每个匹配点上的字段或标签键。 值是将在匹配点上设置的字段或标签值。

对于这个例子，将 maintenance 字段设置为 true。每个源文件将如下所示：

host1.yml

maintenance: true

TICKscript

创建一个TICKscript，使用sideload节点来加载所需的维护状态。

定义侧载源

source 应该使用 file:// URL 协议来引用包含应该加载的文件的目录的绝对路径。

|sideload()
  .source('file:///usr/kapacitor/scheduled-maintenance')

定义侧加载顺序

属性 order 可以访问模板数据，这些数据应当用于填充加载文件的文件路径（相对于 source）。这样，Kapacitor 可以根据模板中使用的标签名称动态搜索文件。

在这种情况下，使用 host 和 hostgroup 标签。 Kapacitor 将遍历每个标签的不同值，并在源目录中搜索 匹配的文件。

|sideload()
  .source('file:///usr/kapacitor/scheduled-maintenance')
  .order('hosts/{{.host}}.yml' , 'hostgroups/{{.hostgroup}}.yml')

order 属性中的文件路径模板的顺序定义了检查文件路径的优先级。最左边列出的首先被检查。

定义sideload字段

该field属性需要两个参数：

|sideload()
  // ...
  .field('<key>', <default-value>)

键

Kapacitor在源文件中查找的关键字，以及它在每个数据点上定义值的字段。

默认值

如果在源文件中未找到匹配的文件和键，则使用的默认值。

在这个例子中，使用 maintenance 字段并将默认值设置为 FALSE。这假设主机默认情况下不在维护中。

|sideload()
  .source('file:///usr/kapacitor/scheduled-maintenance')
  .order('hosts/{{.host}}.yml' , 'hostgroups/{{.hostgroup}}.yml')
  .field('maintenance', FALSE)

如果您更喜欢在每个数据点上设置标签而不是字段，则可以使用tag属性代替field。

更新警报逻辑

现在，sideload 节点将在每个由 TICKscript 处理的数据点上设置 maintenance 字段。对于那些具有与源文件名匹配的 host 或 hostgroup 标签，maintenance 字段将被设置为源文件中定义的值。

更新您的 TICKscript 中的警报逻辑，以确保 maintenance 在发送警报之前 不是 true：

stream
  // ...
  |alert()
    .crit(lambda: !"maintenance" AND "usage_idle" < 30)
    .warn(lambda: !"maintenance" AND "usage_idle" < 50)
    .info(lambda: !"maintenance" AND "usage_idle" < 70)

完整的TICKscript示例

stream
  |from()
    .measurement('cpu')
    .groupBy(*)
  // Use sideload to maintain the host maintenance state.
  // By default we assume a host is not undergoing maintenance.
  |sideload()
    .source('file:///usr/kapacitor/scheduled-maintenance')
    .order('hosts/{{.host}}.yml' , 'hostgroups/{{.hostgroup}}.yml')
    .field('maintenance', FALSE)
  |alert()
    // Add the `!"maintenance"` condition to the alert.
    .crit(lambda: !"maintenance" AND "usage_idle" < 30)
    .warn(lambda: !"maintenance" AND "usage_idle" < 50)        
    .info(lambda: !"maintenance" AND "usage_idle" < 70)

准备计划停机

定义一个新的Kapacitor任务，使用您更新的TICKscript。

当你预定的停机时间开始时，更新在适当的maintenance值在主机和主机组源文件中，并重新加载sideload以避免为这些特定的主机和主机组触发警报。