Elastic Stack 中的告警
告警是 Elastic 各种用例的基础。自从于 2015 年推出 Watcher（Elasticsearch 最初的告警功能套件）以来，我们收到了大量反馈，这些反馈帮助我们更清晰地理解了告警系统应该是什么样子，以及用户体验需要包括哪些内容。本文的目的有三：总结一下我们学到的一些主要内容；说明这些内容对我们 2019 年的工作有何影响；并指出 Elastic Stack 中的告警未来会如何发展。
我们学到了什么？
Elastic 过去四年间一直在从事告警方面的工作，在这一过程中收获了有关告警系统的丰富知识。我尝试将我们所学到的内容浓缩成三个瞻望性的发现：我们在每个用例中都会用到告警；我们需要结合各种用例来理解告警；告警的检测和响应正在变得越来越完善。学到的这些内容会影响我们如何看待告警未来的发展。
告警无处不在
我们的所有产品和用例都离不开告警。如果您拥有实时数据，那就肯定会有告警用例。因此，我们才构建了 Watcher；也正因为这样，Watch 才取得了成功。然而，如果看一下各种用例，我们可以清晰看到并没有放之四海而皆准的告警系统。
从诸如 Elastic Logs、SIEM、APM、Uptime、Infrastructure 和 Maps 等产品，到诸如 Monitoring 和 Machine Learning 等功能，再到丰富的 Kibana 仪表板，虽然告警和通知都发挥着关键作用，但各项在检测条件、如何表达以及如何参考上下文进行显示方面，都有着独特的需求。如需实现有效的告警和监测，必须与产品进行深度集成。随着堆栈和其使用领域的不断发展，有一点越来越清晰，即 Elasticsearch 告警需要一个辅助工具来允许在各个用例中提供紧密集成且表达丰富的告警。
理解告警
“告警无处不在”的必然后果就是：随着这些不同的用例生成告警，这些告警会变成它们自身的数据源，让您有机会理解系统及各自的状态。或者，正如站点可靠性工程 (SRE) 社区所说，提供了一个机会来改善整体系统的可观测性。
每个用例都会用独有方式来解读数据，而告警则会显示情况的不同侧面。要想正确应对事件，通常需要从多个来源收集数据，还需要将不同类型的告警和事件进行关联分析以理解情况。在某些领域，例如 SIEM，较高级别的告警需由较低级别告警中的模式来触发。
随着人们越来越热衷于使用 Elastic Stack 来完成越来越多的用例，如果告警系统设置得当的话，其不仅能生成告警，还能够帮助您理解它们在各种用例之中的涵义。例如，Uptime 告警可能表示服务中断，APM 告警则解释了是哪项事务引发的，而监测告警则可以精准确定发生原因。告警系统应该提供上下文，帮助进行关联分析，并提高认识——同时服务于真人和机器。
检测和行动
“理解告警”的必然结果就是：通过一套可观测性更佳的系统，您能检测到更复杂的条件并采取更完善的行动。这一点越来越超出了我们对告警的传统认识。
告警通常专注于检测一个条件，然后引起人们的注意，一般到此为止。然而将眼界放大一点的话，我们可以将告警系统看做下面这个控制或反馈回路的一部分：观测，检测条件，采取行动，再次观测。
当前，“行动”通常涉及通知，亦即将人员加入回路当中以控制系统并尝试加以纠正。但是，随着系统洞见的提升，“行动”可以拥有更多控制权（通常在人的监督之下）。这可能是一个由双向对话系统（例如聊天机器人）管治的半自动系统，也可能是全自动系统，正如我们在朝着自动扩展、自动修复和自动优化应用程序发展的趋势中所看到的那样。
告警系统需要支持完善的检测和行动，并承认下边两点：“检测”不局限于向 Elasticsearch 发送一条查询；“行动”也不再只是发送一封电子邮件或调用一个 Webhook。
应用我们所学的内容
我们在 2018 年秋季已下定决心：我们的告警系统需要支持上面的三个发现。
我们还确定了达成下列目标的最佳方式，那就是将告警作为 Kibana 中的一级实体：
- 告警无处不在：在插件、API 和 UI 层面，针对我们的所有产品提供丰富的告警集成选项
- 理解告警：针对所有告警类型提供直观的界面
- 检测和行动：通过 Kibana 插件打造完善的检测和行动机制
我们从 Watcher 中还知道：告警系统必须能扩展至生产级告警负载，而且必须拥有卓越的可用性和可靠性。对于支持这三大发现的 API、UI 和插件/库协定，我们必须在坚固的可扩展基础上进行构建。总结一下，我们将 Elastic 告警系统分为四个层级：
我们 2019 年一直在为 Kibana 中崭新的告警系统打基础。
1 月份，我们在 6.7 版本中添加了 Task Manager（任务管理器）。这能够持续为 Kibana 的后台调度提供可在多个 Kibana 实例之间进行分配的任务，从而实现可扩展性和可用性。Task Manager 等告警基础层组件不只支持告警。举例说明，Task Manager 可以在 Kibana 中提供更佳的定期报告体验。
然后在 6 月，我们向 Kibana 中添加了两个 API 集合：告警 API 和行动 API。
行动 API 能够让 Kibana 注册并实施行动，还提供了一个简单协定来帮您定义自己的协定，从而简化自定义过程。初始版本还有一些针对日志、Slack 和电邮通知的示例行动。
告警 API 允许 Kibana 将检测形式注册为“告警类型”，然后使用任务管理系统按计划运行这些检查。和行动一样，也有一个简单的告警协定：如果您可以使用 Kibana 服务器上所运行的 JavaScript 函数将协定表达出来，它就可以支持告警。
Elastic Stack 7.4 专注于告警系统较低层面的工作：我们强化了 API；新增了针对安全和空间的支持；还另外添加了几项内置行动，例如索引、Webhook 和 PagerDuty。
后续工作计划
过去几个月我们一直在全力开发 Kibana 的告警系统，而且在 7.x 的版本周期中我们将会继续这一方面的努力。我们的计划是分三阶段推出此系统。
第一阶段在 2019 年的很长时间内一直都在进行：奠定基础。此阶段专注于可扩展的任务管理和调度、针对告警和行动的协定，以及 API。
我们现在已进入第二阶段，在 API 和库层面为不同用例集成告警系统。还包括在 Kibana 中设计和构建 UI，以便理解告警并通过具体用例（例如监测、Uptime 或 SIEM）进行验证。
第三阶段则会继续拓展“告警无处不在”和“检测和行动”这两个主题，具体方法是允许在整个 Kibana 中使用用户定义告警，无论是通过模板式告警，还是通过使用 Canvas 表达式等开发的基于表达式的告警。
最终目标是此系统能够实现我们对于 Elastic Stack 中告警的愿景：
- 告警无处不在：告警是 Kibana 中具有空间意识的一级实体。这使得我们能够针对各组来细分告警的创建和查看过程，并允许在 SIEM、Monitoring 和 Uptime（不予一一列举）等产品中进行丰富集成。告警旨在作为 Watcher 的辅助功能与其一起发挥作用，并非要取而代之。
- 理解告警：在提供丰富集成选项的同时，我们还会推出 Kibana UI，以提供有关各种告警类型的综合视图，以及用于关联分析和理解告警历史的工具。
- 检测和行动：API 和插件都经过精心设计，以便不限制检测或行动机制的形式，只要可以用 Kibana 服务器上运行的 JavaScript 表达出来就可以。这为通过诸如 SIEM 等产品或者我们的可观测性解决方案在 Kibana 中打造完善的检测和行动留出了足够多的自由空间。