Kibana 与 Elasticsearch中的警报功能
警报是Elastic Stack的一个重要组成部分。你可以使用存储在Elasticsearch中的数据，在满足特定条件时触发警报。警报动作可能涉及发送电子邮件或Slack消息，将数据写入Elasticsearch的索引，调用并传递数据给外部网络服务，等等。
在Elastic Stack中，有两种类型的警报框架。Kibana Alert和Elasticsearch Watcher。Kibana Alert与Kibana中应用程序集成，如Observability、机器学习和Maps。另一方面，Elasticsearch Watcher允许你直接根据索引数据创建警报。
在本文中，我们将讨论Alerts和Watch的基础知识，并提供简单的指导以让您可以为一个用例确定正确的警报类型
使用Elastic Stack的警报功能
在Elastic Stack中，有很多方法可以创建和管理警报。Kibana将Alert与许多应用程序集成，包括Observability、堆栈监控、地图、机器学习和安全。定义警报的最佳方式是在这些应用程序的上下文中进行。例如，如果你对在过去5分钟内的错误数量感兴趣，并期望在超过一个给定的阈值时收到通知，你可以在Kibana的Logs应用程序中启动警报创建。
在日志应用程序的背景下创建的警报规则（conditions和actions）是指来自各个日志相关索引中包含的日志数据。Logs应用程序已经被配置为使用来自这些特定索引的数据，并以统一的方式将其视为日志条目。日志应用希望日志索引符合 Elastic Common Schema，因此希望所有索引中都有某些基本字段，例如@timestamp。
Kibana应用程序不能支撑你的用例，或者当Kibana应用程序不支持从其UI上创建你所需的警报时，你仍然可以使用Kibana中的Rules and Connectors功能创建警报。在这个页面上，你可以创建和管理所有Kibana级别的警报。例如，如果你想在实体
进入地图上定义的地理空间区域时收到通知，例如，城市公交车进入施工区，你可以创建一个电子围栏告警：
当Rules and Connectors中的规则类型都不支持你的用例时，你仍然可以尝试使用Advance Watcher来创建一个警报。Watcher
是索引级别的警报，完全构建在Elasticsearch后端运行。（注意，这与Kibana Alert的不同，Kibana Alert完全由Kibana来提供告警的调度，检查，和运行）尽管它们可以使用Kibana用户界面进行部分定义，但最好使用Dev Tools控制台的特定领域语言（DSL）和_watcher API。当规则条件需要来自高级DSL查询或聚合的结果时，或者当你想对数据进行更进一步的原酸以用于下一步的动作时，你可以使用Watcher。例如，你可以使用Elasticsearch查询和聚合来跟踪复杂的SLA，当SLA达到阈值或任何其他条件被满足时，使用Watcher来通知你。
另一个与Kibana Alert的重要不同是，Watcher也可以用来调度Elasticsearch的任务。两个常见的用途是调度报告的定时生成和发送电子邮件，或运行Elasticsearch任务，如重新索引。
何时使用 Alert 或 Watcher
大多数情况下，我们优先选择Kibana Alert，特别是当你需要告警的场景与以下场景之一吻合时，请选择开箱即用的Kibana Alert，会让你事半功倍：
APM AND USER EXPERIENCE
- Anomaly 当一个服务的延迟、吞吐量或失败的交易率出现异常时，发出警报
- Error count threshold 当服务中的错误数量超过定义的阈值时告警。
- Failed transaction rate threshold 当服务中的事务错误率超过定义的阈值时告警。
- Latency threshold 当服务中特定事务类型的延迟超过定义的阈值时告警。
LOGS
- 日志阈值当日志聚合超过阈值时告警。
MACHINE LEARNING
- 异常检测作业运行状况 异常检测作业有运行问题时发出告警。为极其重要的作业启用合适的告警。
- 异常检测告警 异常检测作业结果匹配条件时告警。
METRICS
- 库存 当库存超过定义的阈值时告警。
- 指标阈值 当指标聚合超过阈值时告警。
STACK RULES
- Elasticsearch 查询 匹配 Elasticsearch 查询时告警。
- 索引阈值 聚合查询达到阈值时告警。
- 跟踪限制 实体包含在地理边界内时告警。
- 转换运行状况 转换出现运行问题时发出告警。
UPTIME
- Uptime TLS 运行时间监测的 TLS 证书即将过期时告警。
- Uptime TLS (Legacy) 运行时间监测的 TLS 证书即将过期时告警。未来的版本将弃用此告警。
- 运行时间监测状态 监测关闭或超出可用性阈值时告警。
堆栈监测
- CCR read exceptions 检测到任何 CCR 读取异常时告警。
- Cluster health 集群的运行状况发生变化时告警。
- CPU Usage 节点的 CPU 负载持续偏高时告警。
- Disk Usage 节点的磁盘使用率持续偏高时告警。
- Elasticsearch version mismatch 当集群包含多个版本的 Elasticsearch 时告警。
- Kibana version mismatch 当集群包含多个版本的 Kibana 时告警。
- License expiration集群许可证即将到期时告警。
- Logstash version mismatch集群包含多个版本的 Logstash 时告警。
- Memory Usage (JVM)节点报告高的内存使用率时告警。
- Missing monitoring data监测数据缺失时告警。
- Nodes changed添加、移除或重新启动节点时告警。
- Shard size平均分片大小大于配置的阈值时告警。
- Thread pool search rejections当搜索线程池中的拒绝数目超过阈值时告警。
- Thread pool write rejections当写入线程池中的拒绝数量超过阈值时告警。
如果你想创建一个不属于Kibana提供的应用级规则的警报规则，而数据级的Stack规则又不能为你的需求提供足够的表达能力，你可以使用Watcher。
Watcher允许你根据你可以在Elasticsearch查询DSL中编写的任何查询和聚合来创建规则。高级表还有其他用途，如报告或进程调度，
Watcher最重要的最佳实践是只有在Kibana Alert不能解决问题的时候才使用它们。因为，Watcher是出了名的难写，因为它们需要有JSON语法、DSL查询和聚合以及Painless脚本的知识。更复杂的是，Watcher不能与Kibana Alert的连接器一起工作。Watcher连接器必须在每个节点的yaml中配置，而不是像我们对Kibana级连接器那样通过Kibana UI配置。此外，并不是每个Kibana级别的连接器都有对应的Watcher。最后，开发Watcher开发任何其他类型的代码是一样的。它必须经过适当的测试，而且必须被管理。特别是，当升级堆栈时，必须对所有的Watcher进行测试，并在必要时进行更新。考虑到所有这些，请尽力先使用Kibana Alert，而不是试图编写一个Watcher规则。
