正在加载

操作

Elastic Stack Serverless

当监视器的条件满足时，将执行其操作，除非它受到节流。 一个监视器可以执行多个操作。 这些操作一次执行一个，并且每个操作独立执行。 执行操作时遇到的任何失败都将记录在操作结果和监视器历史记录中。

注意

如果未为监视器定义任何操作，则不执行任何操作。 但是，仍然会将 watch_record 写入监视器历史记录。

操作可以访问执行上下文中的有效负载。 它们可以使用它以任何需要的方式支持它们的执行。 例如，有效负载可以用作模板化电子邮件正文的模型。

Watcher 支持以下操作

在监视器执行期间，一旦满足条件，就会针对每个配置的操作做出决定，是否应该对其进行节流。操作节流的主要目的是防止对同一监视器执行太多相同的操作。

例如，假设您有一个监视器，用于检测应用程序的日志条目中的错误。该监视器每五分钟触发一次，并搜索过去一小时内的错误。在这种情况下，如果有错误，则有一段时间会检查监视器，并且会基于相同的错误多次执行其操作。结果，系统管理员会收到有关同一问题的多个通知，这可能会令人烦恼。

为了解决这个问题，Watcher 支持基于时间的节流。您可以定义一个节流周期作为操作配置的一部分，以限制操作的执行频率。当您设置节流周期时，如果该操作已经在节流周期时间范围内（now - throttling period）执行过，则 Watcher 会阻止重复执行该操作。

以下代码段显示了上述场景的监视器 - 将节流周期与 email_administrator 操作相关联

 PUT _watcher/watch/error_logs_alert {
  "metadata" : {
    "color" : "red"
  },
  "trigger" : {
    "schedule" : {
      "interval" : "5m"
    }
  },
  "input" : {
    "search" : {
      "request" : {
        "indices" : "log-events",
        "body" : {
          "size" : 0,
          "query" : { "match" : { "status" : "error" } }
        }
      }
    }
  },
  "condition" : {
    "compare" : { "ctx.payload.hits.total" : { "gt" : 5 }}
  },
  "actions" : {
    "email_administrator" : {
      "throttle_period": "15m",
      "email" : {
        "to" : "sys.admino@host.domain",
        "subject" : "Encountered {{ctx.payload.hits.total}} errors",
        "body" : "Too many error in the system, see attached data",
        "attachments" : {
          "attached_data" : {
            "data" : {
              "format" : "json"
            }
          }
        },
        "priority" : "high"
      }
    }
  }
}
  1. 后续的 email_administrator 操作执行之间至少会有 15 分钟的时间间隔。
  2. 有关更多信息，请参见电子邮件操作。

您还可以在监视器级别定义节流周期。监视器级别的节流周期用作监视器中定义的所有操作的默认节流周期

 PUT _watcher/watch/log_event_watch {
  "trigger" : {
    "schedule" : { "interval" : "5m" }
  },
  "input" : {
    "search" : {
      "request" : {
        "indices" : "log-events",
        "body" : {
          "size" : 0,
          "query" : { "match" : { "status" : "error" } }
        }
      }
    }
  },
  "condition" : {
    "compare" : { "ctx.payload.hits.total" : { "gt" : 5 }}
  },
  "throttle_period" : "15m",
  "actions" : {
    "email_administrator" : {
      "email" : {
        "to" : "sys.admino@host.domain",
        "subject" : "Encountered {{ctx.payload.hits.total}} errors",
        "body" : "Too many error in the system, see attached data",
        "attachments" : {
          "attached_data" : {
            "data" : {
              "format" : "json"
            }
          }
        },
        "priority" : "high"
      }
    },
    "notify_pager" : {
      "webhook" : {
        "method" : "POST",
        "host" : "pager.service.domain",
        "port" : 1234,
        "path" : "/{{watch_id}}",
        "body" : "Encountered {{ctx.payload.hits.total}} errors"
      }
    }
  }
}
  1. 后续操作执行之间至少会有 15 分钟的时间间隔（适用于 email_administrator 和 notify_pager 操作）

如果您未在操作或监视器级别定义节流周期，则将应用全局默认节流周期。最初，此值设置为 5 秒。要更改全局默认值，请在elasticsearch.yml中配置 xpack.watcher.execution.default_throttle_period 设置

xpack.watcher.execution.default_throttle_period: 15m

Watcher 还支持基于确认的节流。您可以使用确认监视器 API来确认监视器，以防止在监视器条件保持 true 的情况下再次执行监视器操作。这实际上告诉 Watcher“我收到了通知并且正在处理它，请不要再次通知我有关此错误”。已确认的监视器操作将保持在 acked 状态，直到监视器的条件评估为 false。发生这种情况时，操作的状态将更改为 awaits_successful_execution。

要确认一个操作，您可以使用确认监视器 API

 POST _watcher/watch/<id>/_ack/<action_ids>

其中 <id> 是监视器的 ID，而 <action_ids> 是要确认的操作 ID 的逗号分隔列表。要确认所有操作，请省略 actions 参数。

下图说明了在执行过程中为监视器的每个操作做出的节流决策

action throttling

由于每个分发者都可以自由选择如何打包 OpenJDK，因此即使是完全相同的版本，OpenJDK 分发版也可能在不同的 Linux 发行版下包含不同的部分。

这可能会导致任何使用 TLS 的操作或输入出现问题，例如 jira、pagerduty、slack 或 webhook 操作，因为缺少 CA 证书。如果您在编写连接到 TLS 端点的监视器时遇到 TLS 错误，则应尝试升级到适用于您的平台的最新可用 OpenJDK 分发版，如果这没有帮助，请尝试升级到 Oracle JDK。

© . All rights reserved.