创建日志阈值规则

可用于条件的比较器取决于所选字段。可用的组合是
数值字段:**大于**、**大于或等于**、**小于**或**小于或等于**。
可聚合字段:**是**或**不是**。
不可聚合字段:**匹配**、**不匹配**、**匹配短语**、**不匹配短语**。
- **匹配** 查询输入值的某些或全部内容,无论顺序如何。 例如,`WITH message MATCHES your example message` 查找包含 `your` 和 `example` 和 `message` 这些词的消息,并返回包含其中某些或所有这些词的结果。
- **匹配短语** 查询输入值的确切内容。 例如,`WITH message MATCHES PHRASE your example message` 查找短语 `your example message` 并返回包含该确切短语的结果。
有几个关键的支持用例。您可以基于包含或匹配文本模式的字段、基于数值字段和算术运算符创建规则,或者创建具有多个条件的单个规则。
不同的 Elasticsearch 查询类型支持这些比较器,在某些情况下,了解这些查询类型很重要,以便您可以正确配置规则。 上面列出的比较器映射到以下 Elasticsearch 查询类型
- **大于**:使用 **gt** 的 **range**
- **大于或等于**:使用 **gte** 的 **range**
- **小于**:使用 **lt** 的 **range**
- **小于或等于**:使用 **lte** 的 **range**
- **是** 和 **不是**:**term**
- **匹配** 和 **不匹配**:**match**
- **匹配短语** 和 **不匹配短语**:**match_phrase**
可以为日志阈值规则设置**分组依据**。您可以设置一个或多个分组。
设置**分组依据**时,将对所选字段执行复合聚合。当这些组中的任何一个匹配所选规则条件时,将**针对每个组**触发告警。
在选择多个分组的情况下,组名用逗号分隔。
例如,如果选择 `host.name` 和 `host.architecture` 作为分组依据字段,并且有两个主机(`Host A` 和 `Host B`)和两个架构(`Architecture A` 和 `Architecture B`),则复合聚合形成多个组。我们将重点关注 `Host A, Architecture A` 和 `Host B, Architecture B` 组。
如果组 `Host A, Architecture A` 匹配规则条件,但 `Host B, Architecture B` 不匹配,则会触发一个告警。
同样,如果只选择一个分组依据,例如 `host.name`,并且 Host A 匹配条件,但 Host B 不匹配,则会为 Host A 触发一个告警。如果两个组都匹配条件,则会触发两个告警。
如果选择了分组依据字段,但在告警触发的给定时间范围内,没有文档包含所选字段,则无法确定组。当规则条件对一定数量的文档敏感时,并且该数量可能为 `0` 时,这一点很重要。例如,当查询主机是否具有少于五个匹配条件的文档时,由于主机在查询期间未报告日志,因此不会触发告警。

要确定有多少日志条目会匹配配置的每个部分,您可以查看每个条件的图表预览。这对于确定有多少日志条目会匹配配置的每个部分非常有用。设置分组依据后,图表会为每个组显示一个条形图。要查看预览,请选择条件旁边的箭头。

阴影区域表示已选择的阈值。
要了解一个查询与另一个查询的比较情况,请创建比率规则。当比率值满足特定阈值时,将触发此类规则。比率阈值是第一个查询(查询 A)的文档计数除以第二个查询(查询 B)的文档计数。
以下示例在错误日志数量是警告日志数量的两倍时触发告警。

由于不可能除以 0,因此当查询 A 或查询 B 的文档计数为 0 时,会导致未定义/不确定的比率。在这种情况下,不会触发告警。
通过将规则连接到使用以下支持的内置集成的操作来扩展您的规则。
- D3 Security
- 电子邮件
- IBM Resilient
- 索引
- Jira
- Microsoft Teams
- 可观测性 AI 助手连接器
- Opsgenie
- PagerDuty
- 服务器日志
- ServiceNow ITOM
- ServiceNow ITSM
- ServiceNow SecOps
- Slack
- Swimlane
- Torq
- Webhook
- xMatters
某些连接器类型是付费商业功能,而另一些则是免费的。有关 Elastic 订阅级别的比较,请访问 订阅页面。
选择连接器后,必须设置操作频率。您可以选择在每个检查间隔或自定义间隔上创建告警摘要。或者,您可以设置操作频率,以便选择操作的运行频率(例如,在每个检查间隔、仅在告警状态更改时或在自定义操作间隔)。在这种情况下,您还必须选择影响操作运行时间的特定阈值条件:`已触发` 或 `已恢复`。

您还可以通过指定操作仅在它们匹配 KQL 查询或告警发生在特定时间范围内时运行来进一步细化操作运行的条件。
- **如果告警匹配查询**:输入一个 KQL 查询,该查询定义了必须满足的字段-值对或查询条件才能发送通知。该查询仅搜索规则指定的索引中的告警文档。
- **如果告警是在时间范围内生成的**:设置时间范围详细信息。只有在您定义的时间范围内生成告警时才会发送通知。

使用默认的通知消息或自定义它。您可以通过单击消息文本框上方的图标并从可用变量列表中进行选择来向消息添加更多上下文。

以下变量特定于此规则类型。 您还可以指定 所有规则通用的变量。
context.alertDetailsUrl
- 指向告警问题排查视图的链接,以获取更多上下文和详细信息。如果未配置 `server.publicBaseUrl`,则这将是一个空字符串。
context.interval
- 满足告警条件的时间段的长度和单位。
context.reason
- 告警原因的简明描述。
context.serviceName
- 创建告警的服务。
context.threshold
- 高于此值的任何触发值都会导致触发告警。
context.transactionName
- 创建告警的事务名称。
context.transactionType
- 创建告警的事务类型。
context.triggerValue
- 违反阈值并触发告警的值。
context.viewInAppUrl
- 指向告警源的链接。
在设置**分组依据**时,我们建议对阈值使用**大于**比较器 - 这允许我们的查询应用主动过滤,从而显着提高性能。 否则,我们建议使用基数(可能性数量)最低的**分组依据**字段。
当执行规则检查时,会根据规则的配置构建查询。在绝大多数情况下,没有必要了解这些查询是什么。然而,为了确定最佳配置或帮助调试,查看这些查询的结构可能会很有用。以下是针对以下配置的 Elasticsearch 查询示例:

{
"index":"filebeat-*",
"allowNoIndices":true,
"ignoreUnavailable":true,
"body":{
"track_total_hits":true,
"query":{
"bool":{
"filter":[
{
"range":{
"@timestamp":{
"gte":1600771280862,
"lte":1600774880862,
"format":"epoch_millis"
}
}
},
{
"term":{
"log.level":{
"value":"error"
}
}
}
],
"must_not":[
{
"term":{
"log.file.path":{
"value":"/nginx"
}
}
}
]
}
},
"size":0
}
}
- 取自日志索引设置
- 取自时间戳设置

{
"index":"filebeat-*",
"allowNoIndices":true,
"ignoreUnavailable":true,
"body":{
"query":{
"bool":{
"filter":[
{
"range":{
"@timestamp":{
"gte":1600768208910,
"lte":1600779008910,
"format":"epoch_millis"
}
}
}
]
}
},
"aggregations":{
"groups":{
"composite":{
"size":40,
"sources":[
{
"group-0-host.name":{
"terms":{
"field":"host.name"
}
}
}
]
},
"aggregations":{
"filtered_results":{
"filter":{
"bool":{
"filter":[
{
"range":{
"@timestamp":{
"gte":1600771808910,
"lte":1600775408910,
"format":"epoch_millis"
}
}
},
{
"term":{
"log.level":{
"value":"error"
}
}
}
],
"must_not":[
{
"term":{
"log.file.path":{
"value":"/nginx"
}
}
}
]
}
}
}
}
}
},
"size":0
}
}
- 取自日志索引设置
- 取自时间戳设置
对于日志阈值规则,无法在配置中设置显式索引模式。索引模式而是从 Stack Management(堆栈管理) → Advanced settings(高级设置)下的 Log sources(日志源)中的 Observability(可观测性)推断。
每次执行规则检查时,都会检查日志索引设置,但在创建规则时不会存储它。
在Settings(设置)下设置的Timestamp(时间戳)字段确定了查询中使用哪个字段作为时间戳。