条件
在事件驱动自动化中，条件决定了规则是否触发（运行其动作）。
示例
condition: event.status == "enabled"
- 每个条件可以使用来自以下方面的信息
接收到的事件
规则内先前保存的事件
关于系统的长期事实
用户在启动时提供的并保存为 vars 的变量
- 编写条件时
访问当前事件的数据时，使用 event 前缀
访问 rulebook 中 set_facts 动作的数据时，使用 fact 前缀
在规则内分配变量并访问数据时，使用 events 前缀
在规则内分配变量并访问数据时，使用 facts 前缀
访问通过 –vars 和 –env-vars 传入的变量时，使用 vars 前缀
注意
在访问从命令行传入的变量时，条件 不能 包含 Jinja 风格的替换，否则我们会丢失数据类型信息，且规则引擎将无法处理该条件。相反，请使用 vars 前缀来访问从命令行传入的数据
- 条件可以包含
一个条件
所有条件都必须满足的多条件情况
满足任一条件即可的多条件情况
并非所有条件都必须满足的多条件情况
支持的数据类型
数据类型对规则引擎非常重要。支持以下类型
整数
strings
布尔值
浮点数（点号表示法和科学计数法）
null
支持的运算符
条件支持以下运算符
Name |
描述 |
|---|---|
== |
用于字符串和数字的相等运算符 |
!= |
用于字符串和数字的不相等运算符 |
> |
用于数字的大于运算符 |
< |
用于数字的小于运算符 |
>= |
用于数字的大于等于运算符 |
<= |
用于数字的小于等于运算符 |
+ |
用于数字的加法运算符 |
- |
用于数字的减法运算符 |
* |
用于数字的乘法运算符 |
and (与) |
合取与，用于构建复合表达式 |
或 |
析取或 |
in |
检查左侧的值是否存在于右侧的列表中 |
not in |
检查左侧的值是否不存在于右侧的列表中 |
contains |
检查左侧的列表是否包含右侧的值 |
not contains |
检查左侧的列表是否不包含右侧的值 |
is defined |
检查变量是否已定义 |
is not defined |
检查变量是否未定义，请参阅下面列出的注意事项 |
is match(pattern,ignorecase=true) |
检查模式是否存在于字符串的开头。支持正则表达式 |
is not match(pattern,ignorecase=true) |
检查模式是否不存在于字符串的开头。支持正则表达式 |
is search(pattern,ignorecase=true) |
检查模式是否存在于字符串中的任何位置。支持正则表达式 |
is not search(pattern,ignorecase=true) |
检查模式是否不存在于字符串中的任何位置。支持正则表达式 |
is regex(pattern,ignorecase=true) |
检查正则表达式模式是否存在于字符串中 |
is not regex(pattern,ignorecase=true) |
检查正则表达式模式是否不存在于字符串中 |
is select(operator, value) |
检查列表中是否存在满足由运算符和值定义的测试的项目 |
is not select(operator, value) |
检查列表中是否没有项目满足由运算符 and 值定义的测试 |
is selectattr(key, operator, value) |
检查列表中是否存在满足由键、运算符和值定义的测试的对象 |
is not selectattr(key, operator, value) |
检查列表中是否没有对象满足由键、运算符和值定义的测试 |
<< |
赋值运算符，用于保存带有 events 或 facts 前缀的匹配事件或事实 |
not |
否定运算符，用于否定布尔表达式 |
示例
单一条件
name: An automatic remediation rule condition: event.outage == true action: run_playbook: name: remediate_outage.yml
当事件带有的 outage 属性为 true 时，将执行指定的 playbook。
单一布尔值
name: An automatic remediation rule condition: event.outage action: run_playbook: name: remediate_outage.yml
如果 outage 属性是布尔值，您可以在条件中单独使用它。这是前一个示例的简化版本。如果值为 true，则条件通过并触发动作。
所有条件都必须满足的多条件情况
name: All conditions must match condition: all: - event.target_os == "linux" - event.tracking_id == 345 action: debug:
当我们从源插件接收事件时，我们会将它们发送到规则引擎中运行的相应规则集会话。在多条件情况下，规则引擎将跟踪已匹配的条件，并等待下一个可能匹配其他条件的事件到来。一旦所有条件都满足，它将向您返回所有匹配的事件，这些事件可在动作中使用。
警告
请注意，在此情况下，引擎将考虑 所有不同的事件，直到满足条件，无论这些事件是来自单个源还是多个源。具有
all的多条件不等于具有and运算符的单一条件。如果您想使用多个属性仅匹配一个事件，规则必须使用具有
and运算符的单一条件name: One condition combining attributes condition: event.target_os == "linux" and event.tracking_id == 345 action: debug:
具有内部引用且所有条件都必须满足的多条件情况
如果规则具有带有 all 的多条件，则所有条件都必须满足。
您可以安全地引用同一规则中其他条件的匹配事件有效负载
在相同的规则中。如果其他事件尚未到达，规则引擎将缓存
这些事件，并在新事件到达时将它们作为一个整体重新评估。
--- - name: Delayed comparison hosts: all sources: - eda.builtin.generic: payload: - friend_list: names: - fred - barney - request: type: Delete friend_name: fred rules: - name: r1 condition: all: - event.request.type == "Delete" - event.friend_list.names is select("search", events.m_0.request.friend_name) action: print_event: pretty: true
上述示例使用了通用源插件，该插件允许在 rulebook 中定义
事件有效负载以方便测试。
在此示例中，event.request.type 为 Delete 是注入到系统的
第二个事件。传入的第一个事件是 event.friends_list，当对其进行评估时，
来自第二个事件的 events.m_0.request.friend_name 尚未
定义。规则引擎将把这个事件保存在缓存中，当第二个事件
到来且满足 event.request.type == “Delete” 匹配时，已缓存的第一个事件
将被重新评估。
另一个关键点是，如果多个事件匹配，部分匹配将被存储，
直到整个集合都匹配，并且将使用正确的匹配事件集
执行动作。
--- - name: multiple conditions caching hosts: all sources: - eda.builtin.generic: payload: - request: type: Delete friend_name: fred - request: type: Delete friend_name: wilma - friend_list: names: - fred - barney - friend_list: names: - betty - wilma rules: - name: r1 condition: all: - event.request.type == "Delete" - event.friend_list.names contains events.m_0.request.friend_name action: print_event:
上述示例使用了通用源插件，该插件允许在 rulebook 中定义
事件有效负载以方便测试。
在此示例中，第一个条件与前 2 个事件匹配，
这会导致 2 个部分匹配的规则，然后带有 friend_list 有效负载的
第 3 和第 4 个事件到达，并匹配第 2 个条件。这将导致
该规则被满足两次，且 print_event 将使用正确的事件
运行两次。
满足任一条件即可的多条件情况
name: Any condition can match condition: any: - event.target_os == "linux" - event.target_os == "windows" action: debug:注意
请注意，在此情况下，引擎将考虑 所有不同的事件，直到其中一个事件满足其中一个条件，无论这些事件是来自单个源还是多个源。具有
any的多条件不等于具有or运算符的单一条件。如果您想使用多个属性仅匹配一个事件，规则必须使用具有
or运算符的单一条件name: One condition combining attributes condition: event.target_os == "linux" or event.target_os == "windows" action: debug:
包含事实和事件的多条件情况，且其中之一的所有条件都必须满足
name: Condition using both a fact and an event condition: all: - fact.meta.hosts == "localhost" - event.target_os == "windows" action: debug:
包含事实和事件的条件
name: Condition using a set_fact fact and an event condition: all: - facts.first << fact.custom.expected_index is defined - event.i == facts.first.custom.expected_index action: debug:
在上述示例中，custom.expected_index 是在运行 rulebook 时通过 set_fact 动作
设置的。您不能在同一个条件中直接比较事实和事件。
首先必须将事实分配给本地变量（在上述示例中为 facts.first），
然后可以将该本地变量与 event.i 进行比较。当您使用
事实和事件时，它始终必须处于使用 all 的多条件上下文中。
包含变量和事件的条件
name: Condition using a passed in variable and an event condition: all: - event.year == vars.person.year - event.age == vars.person.age action: debug:
在上述示例中，person.year 和 person.age 是在命令行中通过
--vars 传入 ansible-rulebook 的变量文件中传递的。使用 vars 允许我们保留数据类型。环境变量值始终被视为字符串，
您必须在 playbook 或作业模板中进行类型转换。
name: Single condition comparing vars and event condition: event.name == vars.name action: debug:
变量可以用于如上所示的单一条件规则，因为在将规则集传递给规则引擎之前，
加载规则集时就会解析 vars。如果缺少 vars，
ansible-rulebook 会报告错误。
在评估单个事件时，您可以使用 and 或 or
比较来自该事件的多个属性/特征
逻辑与 (and)
name: Multiple Attribute match from a single event condition: event.target_os == "linux" and event.version == "1.1" action: debug:
逻辑或 (or)
name: Match any one attribute from a single event condition: event.version == "2.0" or event.version == "1.1" action: debug:
“and” 和 “or” 关键字是区分大小写的。您不能使用
“AND” 或 “OR” 作为逻辑运算符。
组合逻辑运算符
您可以组合多个 and 运算符
name: Combining and operators condition: event.version == "2.0" and event.name == "example" and event.alert_count > 10 action: debug:
如果您组合使用 and 和 or 运算符，它们必须用圆括号括起来
name: Combining and -and- or operators condition: ((event.i > 100 and event.i < 200) or (event.i > 500 and event.i < 600)) action: debug:name: Combining and -and- or operators condition: (event.i > 100 and event.i < 200) or event.i > 1000 action: debug:
带赋值的多条件情况
当条件被评估时，如果条件通过，匹配的事件将存储在名为 m_0、m_1、m_2 等常用属性中。第一个条件将存储在 m_0 中，第二个条件存储在 m_1 中……这是基于条件在列表中的位置，因此您可以预见地在其他条件中使用它。您还可以选择使用 << 运算符为这些属性设置别名。例如
name: multiple conditions condition: all: - events.first << event.i == 0 - events.second << event.i == 1 - events.third << event.i == events.first.i + 2 action: debug: msg: - "first: {{ events.first }}" - "second: {{ events.second }}" - "third: {{ events.third }}"
使用赋值运算符时，属性名称应具有
events. 或 facts. 前缀。在上述示例中，我们将
每个条件匹配的事件保存为 events.first、events.second 和 events.third。
在第三个条件中，我们正在访问 events.first 中保存的事件以进行
比较。events 和 facts 具有规则作用域，在规则之外
不可用。它们可用于赋值，并在条件或动作中访问已保存
的值。
上述示例使用的是默认赋值
name: multiple conditions using default assignments condition: all: - event.i == 0 - event.i == 1 - event.i == events.m_0.i + 2 action: debug: msg: - "first: {{ events.m_0 }}" - "second: {{ events.m_1 }}" - "third: {{ events.m_2 }}"
带默认赋值的多条件情况
name: multiple conditions condition: all: - event.i == 1 - event.i == 2 - event.i == events.m_0.i + 3 action: debug: msg: - "first: {{ events.m_0 }}" - "second: {{ events.m_1 }}" - "third: {{ events.m_2 }}"
第一个匹配项存储为 m_0，后续匹配项存储为 m_1、m_2 等……
单一条件赋值（不支持）
name: assignment ignored condition: event.first << event.i == 0 action: debug: msg: - "event: {{event}}"
赋值 不能 用于包含单一条件的规则，
匹配事件将始终被称为 event。在上述示例中，event.first
被忽略，匹配的事件被存储为 event。请将此与多条件
规则进行对比，在多条件规则中，匹配的事件被存储为 events。
否定示例
name: negation condition: not (event.i > 50 or event.i < 10) action: print_event:
在此示例中，先评估布尔表达式，然后将其否定。
注意
当值为单个逻辑语句时，not 运算符可以在没有圆括号的情况下工作
如果存在多个带有 or 或 and 的逻辑语句，请像上面所示那样使用圆括号。
为多条件规则添加时间限制
name: Condition with timeout condition: all: - event.x == 5 - event.y == 99 timeout: 10 seconds action: debug:
在上述示例中，event.x 和 event.y 是在不同时间处理的
2 个独立事件。不保证哪个事件先到来的顺序。
当两个条件都满足时，将触发规则中的动作。条件中的 timeout 属性
允许您对等待这些多个条件得到满足的时间
施加时间限制。
超时单位为 milliseconds、seconds、minutes、hours、days。
在上述示例中，如果在 10 秒内未满足条件，则该规则将被跳过。
规则的计时器在任何一个条件匹配时启动。此 timeout 字段将覆盖
您在规则集级别设置的任何 default_events_ttl。
当“并非所有”条件都满足时为规则添加时间限制
name: Not all conditions met with timeout condition: not_all: - event.msg == "Applying Maintenance" - event.msg == "Server Rebooted" - event.msg == "Application Restarted" timeout: 5 minutes action: run_playbook: name: notify_delays.yml
在某些场景中，您可能只想在一组条件中的 部分
条件（not_all）满足时触发动作。在上述示例中，
我们正在跟踪 3 个独立的事件，如果它们都满足，则一切
正常，但如果在时间窗口内只有部分条件匹配，那么
环境中就存在异常情况，我们希望触发一个动作。
在上述示例中，当时间窗口内未满足所有条件时，
它会触发 notify_delays playbook。计时器在其中一个条件匹配时启动。
超时单位为 milliseconds、seconds、minutes、hours、days。
限制动作以应对事件风暴：反应式
name: Throttle example reactive condition: event.code == "error" throttle: once_within: 5 minutes group_by_attributes: - event.meta.hosts - event.code action: run_playbook: name: notify_outage.yml
当我们在短时间内遇到太多事件（事件风暴）且条件
匹配时，我们将在此时间段内多次触发动作。
这将导致 playbook 在该短时间内运行多次。
您可以通过在规则的 throttle 节点下使用 once_within
属性来指定时间窗口，从而限制这种行为。当条件
首次匹配时，我们触发该动作，然后抑制进一步的动作，直到
时间窗口过期。
在上述示例中，我们一看到 code 属性设置为 error 的
事件，就会立即（反应式）触发动作。然后在接下来的 5 分钟内，我们会
抑制进一步的动作。在 5 分钟窗口过期后，如果条件匹配，
我们将再次运行该动作。
throttle 节点中的 group_by_attributes 允许您指定一个事件有效负载中的
属性数组，以创建唯一事件。在上述示例中，
我们使用的是 event.meta.hosts 和 event.code。如果我们收到 2 个独立的事件，一个具有
event.code=warning，另一个具有 event.code=error，它们将被视为不同的
事件，并且每一个都将被单独处理并触发动作。在使用 once_within 选项时，
必须指定 group_by_attributes。
超时单位为 milliseconds、seconds、minutes、hours、days。
once_within 仅适用于单一条件，不支持多条件。
规则的计时器在任何一个唯一事件匹配条件时启动。
once_within 提供了事件级别的粒度，而下面描述的 once_after
则提供了包含多个匹配事件的时间窗口级别的粒度。
限制动作以应对事件风暴：被动式
name: Throttle example passive condition: event.code == "warning" throttle: once_after: 5 minutes group_by_attributes: - event.meta.hosts - event.code action: run_playbook: name: notify_outage.yml
这与前面描述的 once_within 类似。这更像是一种被动的方法，
适用于像在 once_within 情况下您不想立即做出反应的
情况。使用 once_after，您将进行等待，
然后收集所有唯一事件，直到时间窗口过期。
然后在上述示例中的 5 分钟结束时触发动作以运行
playbook。
throttle 节点中的 group_by_attributes 允许您指定一个事件有效负载中的
事件有效负载中创建唯一事件对的属性。在上述示例中，
我们使用的是 event.meta.hosts 和 event.code。如果我们得到 2 个独立的事件，一个具有
event.code=warning，另一个具有 event.code=error，它们将被视为不同的
事件，并在动作被触发时导致匹配多个事件。
在使用 once_after 选项时，必须指定 group_by_attributes。
once_after 的优点之一是您可以收集所有
匹配条件的唯一事件，并基于多个匹配事件触发单个动作，
从而允许您组合主机信息。
超时单位为 milliseconds、seconds、minutes、hours、days。
once_after 仅适用于单一条件，不支持多条件。
在评估单个事件时，您可以使用 and 或 or
比较来自该事件的多个属性/特征
限制动作，直到接收到特定数量的事件
name: Throttle with threshold condition: event.code == "warning" throttle: accumulate_within: 5 minutes threshold: 10 group_by_attributes: - event.meta.hosts - event.code action: run_playbook: name: notify_outage.yml
这将在一个时间窗口内收集事件，并在达到阈值时
立即触发动作。如果我们在此时间窗口内没有获得足够的事件，
事件将被丢弃。在上述示例中，我们期望
在 5 分钟的时间窗口内至少获得 10 个事件。如果这 10 个事件在 2 分钟内
到达，我们将立即触发规则，因为已达到阈值。
在上述示例中，如果我们在这 5 分钟窗口内仅获得 7 个事件，则所有事件都将被
丢弃，因为阈值是 10。
throttle 节点中的 group_by_attributes 允许您指定一个事件有效负载中的
事件有效负载中创建唯一事件对的属性。在上述示例中，
我们使用的是 event.meta.hosts 和 event.code。如果我们得到 2 个独立的事件，一个具有
event.code=warning，另一个具有 event.code=error，它们将被视为不同的
事件，并在动作被触发时导致匹配多个事件。
在使用 accumulate_within 选项时，必须指定 group_by_attributes。
accumulate_within 的优点之一是您可以收集所有
匹配条件的唯一事件，并基于多个匹配事件触发单个动作，
匹配的事件。
超时单位为 milliseconds、seconds、minutes、hours、days。
accumulate_within 仅适用于单一条件，不支持多条件。
在评估单个事件时，您可以使用 and 或 or
比较来自该事件的多个属性/特征
字符串搜索
name: string search example condition: event.url is search("example.com", ignorecase=true) action: print_event:
在字符串中的任何位置搜索模式。在上述示例中，我们检查
event.url 值的任何位置是否包含 “example.com”。该选项控制
这是一种不区分大小写的搜索
name: string not search example condition: event.url is not search("example.com", ignorecase=true) action: print_event:
在上述示例中，我们检查 event.url 值的任何位置是否不包含 “example.com”
并且该选项控制这是一种不区分大小写的搜索。
字符串匹配
name: string match example condition: event.url is match("http://www.example.com", ignorecase=true) action: print_event:
name: string not search example condition: event.url is not match("http://www.example.com", ignorecase=true) action: print_event:
在上述示例中，我们检查 event.url 是否不以 “http://www.example.com” 开头
并且该选项控制这是一种不区分大小写的搜索。
字符串正则表达式
name: string regex example condition: event.url is regex("example\.com", ignorecase=true) action: print_event:
在字符串中搜索正则表达式模式。在上述示例中，我们检查
event.url 的值中是否包含 “example.com”。该选项控制这
这是一种不区分大小写的搜索
name: string not regex example condition: event.url is not regex("example\.com", ignorecase=true) action: print_event:
在上述示例中，我们检查 event.url 的值中是否不包含 “example.com”
并且该选项控制这是一种不区分大小写的搜索。
检查列表是否存在某个项目
以下示例展示了如何使用 in、not in、contains 和 not contains 运算符来检查列表是否存在某个项目
# variables file expected_levels: - "WARNING" - "ERROR"name: check if an item exist in a list condition: event.level in vars.expected_levels action: debug: msg: matched!name: check if an item does no exist in a list condition: event.level not in ["INFO", "DEBUG"] action: debug: msg: matched!name: check if a list contains an item condition: event.affected_hosts contains "host1" action: debug: msg: matched!name: check if a list does not contain an item condition: vars.expected_levels not contains "INFO" action: debug: msg: This will match always for every event because INFO is not in the list!
基于测试检查列表是否存在某个项目
name: check if an item exist in list condition: event.levels is select('>=', 10) action: debug: msg: The list has an item with the value greater than or equal to 10
在上述示例中，“levels” 是一个整数列表，例如 [1,2,3,20]，测试说明是
检查列表中是否存在值 >= 10 的任何项目。该测试通过，因为
列表中存在 20。如果 “levels” 的值是 [1,2,3]，那么
测试将产生 False。
基于测试检查列表是否不存在某个项目
name: check if an item does not exist in list condition: event.levels is not select('>=', 10) action: debug: msg: The list does not have item with the value greater than or equal to 10
在上述示例中，“levels” 是一个整数列表，例如 [1,2,3]，测试说明是
检查是否没有任何项目的值 >= 10。该测试通过，因为列表中没有任何项目
大于或等于 10。如果 “levels” 的值是 [1,2,3,20]，那么
由于列表中存在 20，测试将产生 False。
select 条件的结果是 True 或 False。它不返回项目或多个项目。
select 接受 2 个由逗号分隔的参数：operator 和 value。
我们支持的不同运算符有 >、>=、<、<=、==、!=、match、search、regex
value 基于所使用的运算符，如果运算符是 regex，则 value 是一个模式。
如果运算符是 >、>=、<、<= 之一，则 value 是整数或浮点数
您还可以在关于循环和列表推导式的 Ansible playbook 文档中找到有关 select 条件的更多信息。
基于测试检查列表是否存在某个对象
name: check if an object exist in list condition: event.objects is selectattr('age', '>=', 20) action: debug: msg: An object with age greater than 20 found
在上述示例中，“objects” 是一个具有多个属性的对象列表。其中一个
属性是 age，测试说明是检查列表中是否存在 age >= 20 的任何对象。
基于测试检查列表是否不存在某个对象
name: check if an object does not exist in list condition: event.objects is not selectattr('age', '>=', 20) action: debug: msg: No object with age greater than 20 found
在上述示例中，“objects” 是一个具有多个属性的对象列表。其中一个
属性是 age，测试说明是检查列表中是否没有任何对象的 age >= 20。
selectattr 条件的结果是 True 或 False。它不返回
匹配的对象或多个对象。
selectattr 接受 3 个由逗号分隔的参数：key、operator 和 value。
key 是对象中的有效键名。
我们支持的不同运算符有 >、>=、<、<=、==、!=、match、search、regex、in、not in、
contains、not contains。
value 基于所使用的运算符，如果运算符是 regex，则 value 是一个模式。
如果运算符是 >、>=、<、<= 之一，则 value 是整数或浮点数。
如果运算符是 in 或 not in，则 value 是整数、浮点数或字符串的列表。
您还可以在关于循环和列表推导式的 Ansible playbook 文档中找到有关 selectattr 条件的更多信息。
常见问题解答 (FAQ)
问：在多条件场景中，当 1 个事件匹配而其余事件不匹配时，
规则引擎会将先前的事件保留多久？
答：部分匹配的事件将根据在规则级别定义的超时时间保留在内存中。
如果规则没有超时设置，我们会查看规则集属性 default_events_ttl，如果该属性
缺失，我们会将事件保留 2 小时。一旦所有条件都匹配或达到超时时间，
事件就会被清除。
问：Ansible rulebook 何时停止处理？
答：当从源插件生成 Shutdown 事件、调用了 shutdown 动作或进程被终止时。
问：如果变量缺失，条件会被评估吗？
答：如果条件引用的 object.attribute 不存在，那么该条件
将被跳过且不进行处理。
- 示例
name: send to debug condition: event.payload.eventType != 'GET' action: debug:
在上述情况下，如果 event.payload.eventType 未定义，则该条件将被忽略，不匹配任何内容。
问：当一个 rulebook 有多个规则集且其中一个关闭时，所有的规则集都会被终止吗？
答：是的，因此如果其他规则集中有任何正在运行的 playbook，需要特别注意。
问：如何检查条件中引用的对象中的属性是否存在？
答：使用 is defined
- 示例
name: rule1 condition: event.msg is defined action: retract_fact: fact: msg: "{{event.msg}}"
问：如何检查条件中引用的对象中的属性是否不存在？
答：使用 is not defined
- 示例
name: rule2 condition: fact.msg is not defined action: set_fact: fact: msg: Hello World
问：使用 is not defined 的注意事项是什么？
答：is not defined 应谨慎使用，用于：
a. 初始化变量
b. 紧随 retract fact 动作之后
如果规则只有一个带有 is not defined 的条件，那么
该规则的位置非常重要。如果该规则首先
定义在 rulebook 中，它将一直被执行，直到
该变量被定义，这可能会导致令人误解的结果，并
跳过其他规则。您通常应该将
is not defined 与另一个比较结合使用。在条件中使用属性之前，
检查它是否存在并不重要。规则引擎
会先检查其是否存在，然后才进行比较。如果缺失，
比较将失败。
问：如果条件字符串中嵌入了冒号，且冒号后紧跟一个空格，该如何转义？
答：在解析 rulebook 期间，您会看到以下错误消息
ERROR - Terminating mapping values are not allowed here.
要解决此错误，您必须用引号引起来整个条件字符串，或者使用 > 或 | 并
将整个条件移动到新行。
- 示例
name: rule1 condition: 'event.abc == "test: 1"'
name: rule1 condition: > event.abc == "test: 1"
name: rule1 condition: | event.abc == "test: 1"