StackStorm 使用 Rules 和 Workflows 来捕获操作模式并进行自动化。rule将 Triggers 映射到 Actions（或 Workflow），应用匹配条件( Criteria)，并将 Triggers payloads 映射到 Actions 的 Input。

注意

rule不按预期工作吗？请查看rule故障排除文档。其中介绍了rule测试、检查执行、记录和故障排除等内容。

Rule 的配置结构

stackstorm 中的 Rule 是以 YAML 格式来定义。以下是 Rule 定义结构以及 “必需”和 “可选” rule 元素的列表：

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

---
    name: "rule_name"                      # required
    pack: "examples"                       # optional
    description: "Rule description."       # optional
    enabled: true                          # required

    trigger:                               # required
        type: "trigger_type_ref"

    criteria:                              # optional
        trigger.payload_parameter_name1:
            type: "regex"
            pattern : "^value$"
        trigger.payload_parameter_name2:
            type: "iequals"
            pattern : "watchevent"

    action:                                # required
        ref: "action_ref"
        parameters:                        # optional
            foo: "bar"
            baz: "{{ trigger.payload_parameter_1 }}"

上面 yaml 表示一个通用形式 Rule 包括：

  • name: rule 的名称。
  • pack: rule 所属的 pack。如果未指定 pack，则默认为 default。
  • description: 对 rule 的描述。
    • enabled: rule的启用状态（true 或 false）。
  • trigger: 从传感器发出的要监视的 trigger 的类型，以及可选的与该 trigger 相关的参数。
  • criteria: 一个可选的条件集，包括：
    • trigger payload 的属性。
    • criteria 比较的类型。
    • pattern 与之匹配的模式。
  • action：当 rule 匹配时要执行的 action，包括：
    • ref: 要执行的引用 (action/workflow)
    • parameters: 要传递给动作 action 的可选参数。

Criteria

Criteria 的条件是需要匹配的规则（逻辑运算符 AND），rules 中的 criteria 表达为：

yaml
1
2
3
4
5
6
7
8

# more variables
criteria:
    trigger.payload_parameter_name1:
        type: "regex"
        pattern : "^value$"
    trigger.payload_parameter_name2:
        type: "iequals"
        pattern : "watchevent"

通过创建多个独立的 rules （每个 rules 对应一个条件表达式），可以实现逻辑运算符 OR 行为（任何一个条件表达式匹配都会触发 Action 的执行）。

在这里，type 指定要使用哪个条件比较运算符，而 pattern 指定要传递给运算符函数的模式。在正则表达式情况下，pattern 是一个正则表达式模式， trigger 值需要与之匹配。

如果 criteria 包含任何特殊字符（如 -），则请使用字典查找格式来指定 criteria 键。在基于 Webhook 的规则中，通常在发布的事件标头中包含这些值：

yaml
1
2
3
4

criteria:
    trigger.headers['X-Custom-Header']:
        type: "eq"
        pattern : "customvalue"

pattern 值还可以使用 Jinja 变量访问语法引用数据存储的值

yaml
1
2
3
4

criteria:
    trigger.payload.build_number:
        type: "equals"
        pattern : "{{ st2kv.system.current_build_number }}"

由于 PyYAML 中已知的已报告问题，“criteria key”必须是唯一的。这在您希望对相同的 trigger 数据应用不同的运算符（例如 contains 和 ncontains）时有时会变得相关，在下面示例中，仅评估条件中的最后一个重复 key。

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10

criteria:
    trigger.payload.commit.tags:  # 重复的key 忽略
      type: ncontains
      pattern: StackStorm
    trigger.payload.commit.tags:  # 重复的key，需要评估
      type: contains
      pattern: pull request
    trigger.payload.commit.message:  # 唯一key，需要评估
      type: ncontains
      pattern: ST2

在 PyYAML 中，“ncontains” 和 “contains” 是用于规则条件比较的两种不同运算符：

  • contains：表示匹配包含某个特定模式的条件。例如，如果您想要触发某个规则，只要 trigger 数据包含特定的内容，就可以使用 “contains” 运算符。
  • ncontains：表示匹配不包含某个特定模式的条件。与 “contains” 相反，只有当 trigger 数据不包含指定的内容时，规则才会触发。

另外，作为一种解决方法，可以使用 “criteria tags” 来多次引用相同的 “criteria key” 。“criteria tags” 使 key 变得唯一，并可以为条件提供上下文。要创建 “criteria tags”，请在 “criteria key” 的末尾包含一个 # 符号和一些文本。在评估时，# 和 # 后面的文本将被忽略。例如：trigger.payload.level#upper 和 trigger.payload.level#lower，如下面示例

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10

criteria:
    trigger.payload.commit.tags#1:
      type: ncontains
      pattern: StackStorm
    trigger.payload.commit.tags#2:
      type: contains
      pattern: pull request
    trigger.payload.commit.message:
      type: ncontains
      pattern: ST2

在这个例子中，由于 “criteria key” 都是唯一的，所有这些条件都将被评估，即使 trigger.payload.commit.tags#1 和 trigger.payload.commit.tags#2 在 trigger 数据中指定了相同的值。使用 “criteria tag” 是为了克服 PyYAML 中 “criteria key” 必须唯一的问题，使得可以在同一 key 上多次引用并且能够指定不同的运算符和模式，从而更灵活地定义规则。

Criteria Comparison

Criteria Comparison 这部分描述了在 Criteria 中可以使用的所有可用运算符。

运算符描述
equals值相等（适用于任意类型的值）。
nequals值不相等（适用于任意类型的值）。
lessthantrigger 值小于提供的值。
greaterthantrigger 值大于提供的值。
matchwildcardtrigger 值与提供的通配符字符串匹配。此运算符支持类似于 Unix shell 的通配符，您可以使用字符如 * 和 ?。对于简单的字符串匹配，此运算符比正则表达式更可取。
regextrigger 值与提供的正则表达式模式匹配。此运算符的行为类似于 re.search('pattern', trigger_value)。
iregextrigger 值与提供的正则表达式模式不区分大小写地匹配。此运算符的行为类似于 re.search('pattern', trigger_value, re.IGNORECASE)。
matchregextrigger 值与提供的正则表达式模式匹配。此运算符已弃用，推荐使用 regex 和 iregex。
iequals字符串 trigger 值不区分大小写地等于提供的值。
containstrigger 值包含提供的值。请注意， trigger 值可以是字符串或数组（列表）。
ncontainstrigger 值不包含提供的值。请注意， trigger 值可以是字符串或数组（列表）。
icontains字符串 trigger 值不区分大小写地包含提供的值。
incontains字符串 trigger 值不区分大小写地不包含提供的字符串值。
startswith字符串 trigger 值的开头与提供的字符串值匹配。
istartswith字符串 trigger 值的开头与提供的字符串值不区分大小写地匹配。
endswith字符串 trigger 值的结尾与提供的字符串值匹配。
iendswith字符串 trigger 值的结尾与提供的字符串值不区分大小写地匹配。
timediff_lttrigger 值与当前时间的时间差小于提供的值。
timediff_gttrigger 值与当前时间的时间差大于提供的值。
exists在 payload 中存在键。
nexists在 payload 中不存在键。
inside触发 payload 在提供的值内部（例如，测试是否“trigger.payload 在 provided_value 中”）。与 contains 的相反操作（其中 contains 会测试“trigger.payload 包含 provided_value”）。
ninside触发 payload 不在提供的值内部（例如，测试是否 “trigger.payload 不在 provided_value 中”）。与 ncontains 的相反操作（其中 contains 会测试“trigger.payload 不包含 provided_value”）。
search在触发 payload 中搜索与子条件匹配的数组（列表）。有关更多信息和示例，请参阅高级比较部分。

高级比较运算符

“搜索运算符” 比其他运算符稍微复杂一些。它接受一个额外的条件参数以及应用于搜索列表每个元素的额外嵌套条件。

条件参数控制搜索运算符如何匹配列表。对于 any 条件，如果 trigger payload 列表中至少有一项匹配所有子条件，搜索运算符将返回成功匹配。对于 all 条件， trigger payload 列表中的每一项都必须与所有子条件匹配，搜索运算符才会返回成功匹配。any2any 条件在任何 payload 项匹配任何条件项时返回成功匹配。最后，all2any 条件在所有 payload 项匹配任何条件项时返回成功匹配。

以下是使用 “搜索运算符” 和 any 条件的示例条件：

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

---
criteria:
  trigger.issue_fields:
    type: "search"
    # Controls whether all items in the trigger payload must match the child criteria,
    # or if any single item matching the child criteria is sufficient
    condition: any  # <- *At least one* item must match all child patterns
    pattern:
      # Here our context is each item of the list
      # All of these patterns must match the item for the item to be considered a match
      # These are simply other operators applied to each item of the list
      item.field_name:
        type: "equals"
        pattern: "Status"

      item.to_value:
        type: "equals"
        pattern: "Approved"

下面内容，这个条件将匹配以下 trigger payload，因为“Status”字段已更改为“Approved”：

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "issue_fields": [
    {
      "field_type": "Custom",
      "field_name": "Status",
      "to_value": "Approved"
    }, {
      "field_type": "Custom",
      "field_name": "Signed off by",
      "to_value": "Stanley"
    }
  ]
}

以下是另一个示例，其中 condition 参数为 all，在这种情况下，列表中的所有项都必须匹配所有的子模式：

yaml
1
2
3
4
5
6
7
8
9

---
criteria:
  trigger.issue_fields:
    type: "search"
      condition: all  # <- *All* items must match all patterns
      pattern:
        item.field_type:
          type: "equals"
          pattern: "Custom"

该条件也将与上述 trigger payload 匹配。

然而，以下 trigger payload 不会与 all 条件匹配，因为 “Summary” 字段不是 “Custom” 字段：

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

{
  "issue_fields": [
    {
      "field_type": "Built-in",
      "field_name": "Summary",
      "to_value": "Lorem Ipsum"
    }, 
    {
      "field_type": "Custom",
      "field_name": "Status",
      "to_value": "Approved"
    }, 
    {
      "field_type": "Custom",
      "field_name": "Signed off by",
      "to_value": "Stanley"
    }
  ]
}

以下示例是 参数 condition 为 any2any 的示例。在任何 payload 项匹配模式的任何部分的情况下，这将返回 true。此示例使用上面 “condition” 部分中描述的条件标签。

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

---
criteria:
  trigger.body.data.tank:
    type: "search"
    condition: any2any
    pattern:
      item.chemicalLevel#1:
        type: "lessthan"
        pattern: 40
      item.chemicalLevel#2:
        type: "greaterthan"
        pattern: 50

Payload

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "tanks": [
    {
      "id": 1,
      "chemicalLevel": 43
    }, {
      "id": 2,
      "chemicalLevel": 55
    }
  ]
}

上面示例中，由于第二个 chemicalLevel 值超过了50，因此此条件解析为 true，并且将触发操作，例如向操作员发送通知。如果第二个chemicalLevel 为45，则条件解析为 false，不会发生任何操作。

以下是条件参数为 all2any 的示例。在所有 payload 都与所有的 condition pattern 匹配的情况下，这将返回 true

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

---
criteria:
  trigger.body.data.equipment:
    type: "search"
    condition: all2any
    pattern:
      item.latitude.value#1:
        type: "lessthan"
        pattern: 40
      item.latitude.value#2:
        type: "greaterthan"
        pattern: 50
      item.longitude.value#1:
        type: "lessthan"
        pattern: -100
      item.longitude.value#2:
        type: "greaterthan"
        pattern: -90

payload 如下：

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{

  "equipment": [
    {
      "latitude": {
        "value": 43
      }
      "longitude": {
        "value": -95
      }
    }, {
      "latitude": {
        "value": 44
      }
      "longitude": {
        "value": -96
      }
    }
  ]
}

在这个例子中，所有设备的值都在条件指定的范围内，因此不会执行任何操作。即使将第一个 latitude 设置为 53，仍然不会有任何操作。假设第二个 longitude 值设置为 -106，那么操作将触发，因为所有设备将违反 contition 中的至少一个部分。这可以在最后一个 equipment 离开区域时触发通知。

单一 payload 模式

如果 payload 中只需要一个元素，则如果 payload 是字典，则搜索参数仍然可以用于测试规则的条件，例如下面示例，payload 还是和上面相同，但是实际内容不同

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

---
criteria:
  trigger.body.data:
    type: "search"
    condition: all2any
    pattern:
      item.latitude.value#1:
        type: "lessthan"
        pattern: 40
      item.latitude.value#2:
        type: "greaterthan"
        pattern: 50
      item.longitude.value#1:
        type: "lessthan"
        pattern: -100
      item.longitude.value#2:
        type: "greaterthan"
        pattern: -90

payload

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "data": {
    "latitude": {
      "value": 43
    }
    "longitude": {
      "value": -95
    }
  }
}

在使用 single payload 时，all2any 和 any2any 具有相同的结果，因为选择所有与选择任何一件相同。

condition 参数

  • count
  • count_gt
  • count_gte
  • count_lt
  • count_lte
  • any
  • all
  • any2any
  • all2any

搜索运算符的注意事项

首先，它将规则引擎转变为一个 “递归下降解析器”，这可能会降低规则引擎的性能。因此，如果有一个规则必须保持快速响应，不受系统负载影响，建议尽量避免使用 “搜索运算符”。

其次，“搜索运算符” 的认知复杂性使其一眼难以理解。如果你与他人共享代码，可能需要详细记录规则和模式，以更清晰地解释你的意图。

最后，“搜索运算符” 的算法复杂性与其他运算符大不相同，下面是算法的复杂度：

  • O($n_{patterns}$) 是指 $n_{patterns}$，即子模式的数量。这表示算法的运行时间（复杂度）与子模式的数量成正比。当子模式数量增加时，运行时间也会相应增加。
  • O($n_{payloads}$) 是指 $n_{payloads}$，即 “trigger payload” 字段的数量。同样，这表示算法的运行时间与 “trigger payload” 字段的数量成正比。增加 “trigger payload” 字段的数量也会导致运行时间增加。

其中，O 表示的是算法的渐进复杂度，即算法的运行时间与输入规模的增长关系。因此，如果有大量 “子条件” 或者在 “trigger payload” 中搜索长列表，使用搜索运算符很容易编写出慢规则。

总结：使用 “搜索运算符” 应主要限制在尝试匹配 “少量的子条件” 和 ”少量预期 payload“ 列表项的情况下。尽管搜索运算符可能使规则引擎变慢，但与无条件运行工作流并在那里进行过滤相比，在规则中使用搜索运算符仍然更快且更轻量。

在Rule中配置Actions的执行

这一部分描述了在 ”tigger“ 成功匹配并满足一组可选条件时要执行的后续 ”actions/workflows“。至少，Rules 应指定要执行的 Actions。Rules 还可以指定在执行 Actions 时提供给 Actions 的参数。

下面是一个 Actions 的示例

yaml
1
2
3
4
5

action:                                # required
    ref: "action_ref"
    parameters:                        # optional
        foo: "bar"
        baz: 1

偶尔情况下，在规则 Rules 时，将 Tigger 的上下文传递给 Actions 可能是必要的。 Rule 引擎能够通过利用 Jinja 模板语法插值变量。如下所示：

yaml
1
2
3
4
5

action:
    ref: "action_ref"
    parameters:
        foo: "bar"
        baz: "{{ trigger.payload_parameter_1 }}"

触发器属性的值可以是 null 和 None。这也是相关 Actions 参数的有效值。您需要使用 use_none Jinja 模板过滤器，以确保在调用操作时正确序列化 null/None 值。

yaml
1
2
3
4
5

action:
    ref: "action_ref"
    parameters:
        foo: "bar"
        baz: "{{ trigger.payload_parameter_1 | use_none }}"

Notes: 当使用 Jinja 模板插值时，null 或 None 的值可能会导致一些序列化问题。使用 “use_none” 过滤器可以帮助规避这些问题，确保 null 或 None 值在序列化时被正确处理。

由于当前的 Jinja 模板系统不支持非字符串类型，因此需要此解决方法。在调用操作之前，我们被迫根据操作参数定义执行类型转换。

Rules 的管理

添加rule

如果只为了部署部署一条 rule，可以使用 st2 命令：st2 rule create ${PATH_TO_RULE}，例如：

bash
1

st2 rule create /usr/share/doc/st2/examples/rules/sample_rule_with_webhook.yaml

完成后记得要重新加载所有规则，请使用 st2ctl reload --register-rules

如果 rule name 已经存在将会出现下面的提示：

yaml
1
2

ERROR: 409 Client Error: Conflict
MESSAGE: Tried to save duplicate unique keys (E11000 duplicate key error index: st2.rule_d_b.$uid_1  dup key: { : "rule:examples:sample_rule_with_webhook" })

更新rule

要更新一条规则，编辑规则定义文件并运行命令：st2 rule update，如下例所示：

bash
1

st2 rule update examples.sample_rule_with_webhook /usr/share/doc/st2/examples/rules/sample_rule_with_webhook.yaml

获取rule

要查看所有规则或获取单个规则，请使用以下命令：

bash
1
2

st2 rule list
st2 rule get examples.sample_rule_with_webhook

要取消部署一条规则，运行命令：st2 rule delete ${RULE_NAME_OR_ID}。例如，要取消部署之前部署的名为 examples.sample_rule_with_webhook 的规则，运行：

bash
1

st2 rule delete examples.sample_rule_with_webhook

rule的放置位置

自定义规则可以放置在本地系统上的任何可访问文件夹中。自定义规则通常放置在 /opt/stackstorm/packs/<pack_name>/rules 目录中。

测试rule

为了更方便地测试规则，我们提供了一个 st2-rule-tester 工具，它可以在不运行任何 StackStorm 组件的情况下评估规则与触发器实例的匹配。

该工具通过接受包含规则定义的文件路径和包含触发器实例定义的文件路径来实现：

bash
1
2

st2-rule-tester --rule=${RULE_FILE} --trigger-instance=${TRIGGER_INSTANCE_DEFINITION} --config-file=/etc/st2/st2.conf
echo $?

两个文件都需要以YAML或JSON格式包含定义。对于规则，您可以使用计划部署的相同文件。

对于触发器实例，定义文件需要包含以下键：

  • trigger：触发器的完整引用（例如，core.st2.IntervalTimer，slack.message，irc.pubmsg，twitter.matched_tweet等）。
  • payload：Trigger payload。负载本身是特定于所讨论触发器的。要了解触发器结构，您可以查看包的 README 或查找位于 packs/<pack_name>/sensors/ 目录中的 sensor 元数据文件中的 trigger_types 部分。

如果触发器实例匹配，将打印 === RULE MATCHES === 并且该工具将以 0 的状态代码退出。如果规则不匹配，将打印 === RULE DOES NOT MATCH === 并且该工具将以 1 的状态代码退出。

以下是如何使用该工具的一些示例：

rule.yaml

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

---
  name: "relayed_matched_irc_message"
  pack: "irc"
  description: "Relay IRC message to Slack if the message contains word StackStorm"
  enabled: true

  trigger:
    type: "irc.pubmsg"
    parameters: {}

  criteria:
      trigger.message: # 触发器的message值
          type: "icontains" # 不区分大小写包含 pattern 的值
          pattern: "StackStorm"

  action:
    ref: "slack.post_message"
    parameters:
        message: "{{ trigger.source.nick }} on {{ trigger.channel }}: {{ trigger.message }}"
        channel: "#irc-relay"

trigger_instance_1.yaml :

yaml
1
2
3
4
5
6
7
8
9

---
    trigger: "irc.pubmsg"
    payload:
      source:
          nick: "Kami_"
          host: "gateway/web/irccloud.com/x-uvv"
      channel: "#stackstorm"
      timestamp: 1419166748,
      message: "stackstorm is cool!"

trigger_instance_2.yaml

yaml
1
2
3
4
5
6
7
8
9

---
    trigger: "irc.pubmsg"
    payload:
      source:
          nick: "Kami_"
          host: "gateway/web/irccloud.com/x-uvv"
      channel: "#stackstorm"
      timestamp: 1419166748,
      message: "blah blah"

下面使用 trigger_instance_1 来评估rules

bash
1
2

st2-rule-tester --rule=./my_rule.yaml --trigger-instance=./trigger_instance_1.yaml
echo $?

trigger_instance_1 输出的结果为

bash
1
2
3
4
5

2015-12-11 14:35:03,249 INFO [-] Connecting to database "st2" @ "0.0.0.0:27017" as user "None".
2015-12-11 14:35:03,318 INFO [-] Validating rule irc.relayed_matched_irc_message for pubmsg.
2015-12-11 14:35:03,331 INFO [-] 1 rule(s) found to enforce for pubmsg.
2015-12-11 14:35:03,333 INFO [-] === RULE MATCHES ===
0

使用 trigger_instance_2 来评估rules

text
1
2

st2-rule-tester --rule=./my_rule.yaml --trigger-instance=./trigger_instance_2.yaml
echo $?

trigger_instance_2 输出的结果为

bash
 1
 2
 3
 4
 5
 6
 7
 8
 9
10

2015-12-11 14:35:57,380 INFO [-] Connecting to database "st2" @ "0.0.0.0:27017" as user "None".
2015-12-11 14:35:57,444 INFO [-] Validating rule irc.relayed_matched_irc_message for pubmsg.
2015-12-11 14:35:57,459 INFO [-] Validation for rule irc.relayed_matched_irc_message failed on -
  key: trigger.message
  pattern: StackStorm
  type: icontains
  payload: blah blah
2015-12-11 14:35:57,461 INFO [-] 0 rule(s) found to enforce for pubmsg.
2015-12-11 14:35:57,462 INFO [-] === RULE DOES NOT MATCH ===
1

st2-rule-tester 进一步提供了一种事后调试的方式，您可以回答一个问题：“为什么我的 Rule 没有与刚刚触发的 Trigger 匹配？” 这表示着已经在 StackStorm 中加载了一个已知引用的 rule，类似地，还有一个带有已知 ID 的 Trigger Instance。

假设我们有规则引用为 my_pack.fire_on_execution 和 Trigger 实例 ID 为 566b4be632ed352a09cd347d：

bash
1
2

st2-rule-tester --rule-ref=my_pack.fire_on_execution --trigger-instance-id=566b4be632ed352a09cd347d --config-file=/etc/st2/st2.conf
echo $?

输出结果为

bash
1
2
3
4
5
6
7
8
9

2015-12-11 15:24:16,459 INFO [-] Connecting to database "st2" @ "0.0.0.0:27017" as user "None".
2015-12-11 15:24:16,527 INFO [-] Validating rule my_pack.fire_on_execution for st2.generic.actiontrigger.
2015-12-11 15:24:16,542 INFO [-] Validation for rule my_pack.fire_on_execution failed on -
  key: trigger.status
  pattern: succeeded
  type: iequals
  payload: failed
2015-12-11 15:24:16,545 INFO [-] 0 rule(s) found to enforce for st2.generic.actiontrigger.
2015-12-11 15:24:16,546 INFO [-] === RULE DOES NOT MATCH ===

输出还标识了不匹配的来源，即是 Trigger 类型不匹配还是其中一个条件不匹配。

如果您正在调试并想要查看发送到 StackStorm 的 Trigger 实例列表，可以使用下面命令：

bash
1

st2 trigger-instance list

还可以按触发器进行触发器实例的过滤：

bash
1

st2 trigger-instance list --trigger=core.f9e09284-b2b1-4127-aedd-dcde7a752819

此外，还可以通过使用 timestamp_gt 和 timestamp_lt 过滤选项，在时间范围内获取触发器实例：

bash
1

st2 trigger-instance list --trigger="core.f9e09284-b2b1-4127-aedd-dcde7a752819" -timestamp_gt=2015-06-01T12:00:00Z -timestamp_lt=2015-06-02T12:00:00Z

请注意，您还可以指定其中一个 timestamp_lt 或 timestamp_gt。您可以使用 get 命令获取有关触发器实例的详细信息：

bash
1

st2 trigger-instance get 556e135232ed35569ff23238

在调试规则时可能很有用的一项功能是将触发器实例重新发送到 StackStorm。您可以使用 re-emit 命令来实现这一点。

bash
1

st2 trigger-instance re-emit 556e135232ed35569ff23238

定时器 - timers

定时器 (Timers) 允许基于定义的时间间隔重复运行特定操作，或在特定日期和时间运行。您可以将它们视为 cron 作业，但具有更多的灵活性，例如仅在提供的日期和时间运行操作一次的能力。

目前，我们支持以下定时器触发器类型：

  • core.st2.IntervalTimer ：在预定义的时间间隔（例如每30秒，每24小时，每周等）运行一个操作。
  • core.st2.DateTimer ：在指定的日期和时间运行一个操作。
  • core.st2.CronTimer ：当前时间匹配在UNIX cron格式中定义的时间约束时运行一个操作。

定时器被实现为 Trigger，这意味着您可以在 Rule 中使用它们。在下面的部分中，您可以找到如何在规则定义中使用定时器的一些示例。

core.st2.IntervalTimer 使用示例

可用的参数有：unit 和 delta。

对于 unit 参数，支持的值包括：seconds、minutes、hours、days、weeks。

每30秒运行一次Action

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
...

trigger:
  type: "core.st2.IntervalTimer"
  parameters:
      unit: "seconds"
      delta: 30

action:
  ...

每24小时运行一次Action

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
...

trigger:
  type: "core.st2.IntervalTimer"
  parameters:
      unit: "hours"
      delta: 24

action:
  ...

每2星期运行一次Action

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
...

trigger:
  type: "core.st2.IntervalTimer"
  parameters:
      unit: "weeks"
      delta: 2

action:
  ...

core.st2.DateTimer

可用参数 timezone, date.

在指定时间运行 action

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
...

trigger:
  type: "core.st2.DateTimer"
  parameters:
      timezone: "UTC"
      date: "2014-12-31 23:59:59"

action:
  ...

core.st2.CronTimer

此定时器支持类似 cron 的表达式。

默认情况下，如果没有为特定参数提供值，则假定为 *，这意味着在每个值上触发。

可用参数 timezone, year, month, day, week, day_of_week, hour, minute, second，注意，时区(timezone ) 使用 pytz 格式 例如 Asia/Shanghai.

每周日午夜运行action

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

---
...

trigger:
  type: "core.st2.CronTimer"
  parameters:
      timezone: "UTC"
      day_of_week: 6 # or day_of_week: "sun"
      hour: 0
      minute: 0
      second: 0

action:
  ...

每天午夜运行action

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

---
...

trigger:
  type: "core.st2.CronTimer"
  parameters:
      timezone: "UTC"
      day_of_week: "*"
      hour: 0
      minute: 0
      second: 0

action:
  ...

如上所述，如果没有为特定参数提供值，则假定为 *，这意味着以下内容等效于上述内容：

yaml
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

---
...

trigger:
  type: "core.st2.CronTimer"
  parameters:
      timezone: "UTC"
      hour: 0
      minute: 0
      second: 0

action:
  ...

周一到周五每天午夜执行，但周六日不执行

bash
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

---
...

trigger:
  type: "core.st2.CronTimer"
  parameters:
      timezone: "UTC"
      day_of_week: "mon-fri"
      hour: 0
      minute: 0
      second: 0

action:
  ...

每小时执行一次

bash
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

---
...

trigger:
  type: "core.st2.CronTimer"
  parameters:
      timezone: "UTC"
      hour: "*"
      minute: 0
      second: 0

action:
  ...

故障排除

rules 不如预期那样工作？或者只是想看看哪些 rules 已经生效？

运行 st2 rule-enforcement list 以查看所有 rules 执行。您可以通过规则对此输出进行过滤以缩小范围。