在工作流中进行状态检查

在工作流中，状态检查可对外部系统（比如业务应用系统、监控系统）执行指定的操作来获得系统的状态，并当检查到系统不健康时可以自动地终止工作流，其概念类似于 Kubernetes 中的 Container Probes。本文介绍如何通过 YAML 的方式在工作流中进行状态检查。

注意

当前 StatusCheck 节点还不支持在 Dashboard 上创建，只能通过 YAML 方式进行创建。

状态检查类型

目前，只支持 HTTP 一种方法来进行状态检查。

定义一个 HTTP 类型的 StatusCheck 节点

StatusCheck 节点支持对指定的 URL 执行 HTTP GET 或 POST 请求，可携带自定义的 HTTP headers 和 body，并通过 criteria 中的条件来判断请求是否成功。

- name: workflow-status-check
  templateType: StatusCheck
  deadline: 20s
  statusCheck:
    mode: Continuous
    type: HTTP
    intervalSeconds: 1
    timeoutSeconds: 1
    http:
      url: http://123.123.123.123
      method: GET
      criteria:
        statusCode: '200'

在这个配置文件中，可以看到定义了一个 HTTP 类型的 StatusCheck 节点。deadline 字段指定了该节点最多执行 20 秒。mode 字段指定了该 StatusCheck 节点会持续性的执行状态检查。intervalSeconds 字段指定了重复间隔为 1 秒。timeoutSeconds 字段指定了每次执行的超时时间。

当工作流运行到这个节点时，每隔 1 秒会执行一次指定的状态检查行为：使用 GET 方法向 http://123.123.123.123 这个 URL 进行 HTTP 请求，如果该请求在 1 秒内响应，且状态码为 200，则此次执行成功，反之失败。

检查结果

每次执行状态检查都将获得一个“执行结果”，Success（成功）或 Failure（失败）。因为单次“执行结果”可能会因为某些条件的波动，并不能反映系统的真实情况，所以最终的“状态检查结果”并不根据单次的“执行结果”来决定。

StatusCheck 节点中有 failureThreshold（失败阈值） 和 successThreshold（成功阈值） 两个字段：

• 当出现连续的失败“执行结果”次数超过失败阈值时，则认为“状态检查结果”为失败。当“状态检查结果”为失败时，会直接结束当前 StatusCheck 节点的执行。
• 当出现连续的成功“执行结果”次数超过成功阈值时，则认为“状态检查结果”为成功。

- name: workflow-status-check
  templateType: StatusCheck
  deadline: 20s
  statusCheck:
    mode: Continuous
    type: HTTP
    successThreshold: 1
    failureThreshold: 3
    http:
      url: http://123.123.123.123
      method: GET
      criteria:
        statusCode: '200'

在这个配置文件中，StatusCheck 节点会持续性地执行状态检查：

• 当出现连续 1 次及以上“执行结果”为“成功”时，认为“状态检查结果”为成功
• 当出现连续 3 次及以上“执行结果”为“失败”时，认为“状态检查结果”为失败

注意

下文中，当提到“状态检查失败”时，都指的是“状态检查结果”为失败，而不是单次的“执行结果”为失败。

当状态检查不成功时，终止工作流

注意

目前，StatusCheck 节点只支持当状态检查失败时，自动终止工作流。不支持暂停工作流和恢复工作流的功能。

当执行混沌实验时，应用系统可能会变得“不健康”，如果在某些情况下，想通过快速结束混沌实验来恢复应用系统，则可以使用这个功能。在 StatusCheck 节点上将 abortWithStatusCheck 字段设置为 true，那么当状态检查失败时，就会自动的终止工作流。

- name: workflow-status-check
  templateType: StatusCheck
  deadline: 20s
  abortWithStatusCheck: true
  statusCheck:
    mode: Continuous
    type: HTTP
    http:
      url: http://123.123.123.123
      method: GET
      criteria:
        statusCode: '200'

当符合以下任意条件时，就认为是状态检查不成功：

• 状态检查失败
• 当达到 StatusCheck节点超时时间时，状态检查结果不是“成功”。比如 successThreshold 为 1，failureThreshold 为 3，而当达到超时时间时，当前连续出现 2 次失败，0 次成功，虽然不符合状态检查失败的条件，但在这种情况下也被认为状态检查不成功。

执行模式

持续性的状态检查

当 mode 字段为 Continuous 时，代表这个 StatusCheck 节点会持续性地执行状态检查，直到节点超时退出或者状态检查失败。

- name: workflow-status-check
  templateType: StatusCheck
  deadline: 20s
  statusCheck:
    mode: Continuous
    type: HTTP
    intervalSeconds: 1
    successThreshold: 1
    failureThreshold: 3
    http:
      url: http://123.123.123.123
      method: GET
      criteria:
        statusCode: '200'

在这个配置文件中，StatusCheck 节点每隔 1 秒会执行一次状态检查，当符合以下任意条件时退出：

• 状态检查失败，即出现连续 3 次及以上失败的“执行结果”
• 20 秒后触发节点超时

一次性的状态检查

当 mode 字段为 Synchronous 时，代表这个 StatusCheck 节点会在明确状态检查结果时立即退出，或当节点超时时退出。

- name: workflow-status-check
  templateType: StatusCheck
  deadline: 20s
  statusCheck:
    mode: Synchronous
    type: HTTP
    intervalSeconds: 1
    successThreshold: 1
    failureThreshold: 3
    http:
      url: http://123.123.123.123
      method: GET
      criteria:
        statusCode: '200'

在这个配置文件中，StatusCheck 节点每隔 1 秒会执行一次状态检查，当符合以下任意条件时退出：

• 状态检查成功，即出现连续 1 次及以上成功的“执行结果”
• 状态检查失败，即出现连续 3 次及以上失败的“执行结果”
• 20 秒后触发节点超时

Status Check vs HTTP Request Task

相同点：

• StatusCheck 节点和 HTTP Request Task 节点（用来执行 HTTP 请求的 Task 节点）都属于工作流的一种节点类型
• StatusCheck 节点和 HTTP Request Task 节点都可以通过 HTTP 请求来获得外部系统的信息

不同点：

• HTTP Request Task 节点只能发送一次请求，而不能持续性的发送请求
• HTTP Request Task 节点在请求失败时，无法对工作流的执行状态产生影响（比如终止工作流）

字段说明

Workflow 和 Template 字段说明参考创建 Chaos Mesh 工作流。

StatusCheck 字段说明

HTTPStatusCheck 字段说明

HTTPCriteria 字段说明