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

在许多情况下，基础设施停机对于执行系统维护是必要的。如果受影响的主机受到 Kapacitor 的监控，则这种类型的停机通常是预先计划好的，但可能会触发不必要的警报。本指南将引导您完成创建 TICKscript 的过程，该脚本可以优雅地处理计划停机而不会触发警报。

Sideload

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

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

相关的 sideload 属性

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

source

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

order

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

field

field 定义 Kapacitor 应搜索的字段键，以及如果在加载的文件中找不到匹配的字段键时应使用的默认值。

tag

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

设置

使用 sideload 功能，您可以创建本质上是白名单或黑名单的主机，以在计划停机期间忽略。在此示例中，假设维护将在单个主机和主机组上进行，这两者都作为标签包含在数据集中的每个点上。

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

Sideload 源文件

在运行 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 节点加载维护状态，无论它在哪里需要。

定义 sideload 源

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

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

定义 sideload 顺序

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>)

key

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

default-value

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

在此示例中，使用 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)

为计划停机做准备

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

当您的计划停机开始时，更新相应主机和主机组源文件中的 maintenance 值，并重新加载 sideload 以避免为这些特定主机和主机组触发警报。