本文阐述了 Netflix 的系统监控实践：自研 Telltale，成功运行并监控着 Netflix 100 多个生产应用程序的运行状况。
核心要点
- Netflix 构建 Telltale 的直接动机，是减少过多告警、过多仪表盘、过多配置和过多维护带来的值班压力。
- Telltale 不依赖单一阈值判断应用是否健康，而是把时序指标、实时流数据、基础架构变更、Canary、上下游服务、QoE 和告警事件组合成应用健康评估模型。
- 智能告警的重点不是“更快发通知”，而是把上下文、原因、路由、生命周期和反馈机制一起做好，避免告警风暴。
- Telltale 会在异常事件中保存快照，持续追加新监控信息，并为事后复查提供总停机时间、MTTR 等关键指标。
- Netflix 还把 Telltale 用到部署监控中，通过持续监控新版本实例状态来缩小问题部署的影响半径。
难忘的经历
相信很多运维人都有过这样的经历：监控系统某个指标超过阈值，触发告警。大半夜里，你被紧急召唤。
半睁着眼，你满脸疑惑：“系统真出问题了吗，还是仅仅需要调整下告警？上一次有人调整我们的告警阈值是在什么时候？有没有可能是上游或者下游的服务出现了问题？”
鉴于这是一次非常重要的应用告警，因此你不得不从床上爬起来，迅速打开电脑，然后浏览监控仪表盘来追踪问题源头。
忙了半天，你还没确认这个告警是来自于系统的问题，但也意识到，从海量数据中寻找线索时，时间正在流逝。你必须尽快定位告警的原因，并祈祷系统稳定运行。
对我们的用户来讲，稳健的 Netflix 服务至关重要。当你坐下来看《养虎为患》时，你肯定希望它能顺利播放。
多年来，我们从经常在深夜被召唤的工程师那里了解到应用程序监控的痛点：
- 过多的告警
- 太多滚动浏览的仪表盘
- 太多的配置
- 过多的维护
Telltale
我们的流媒体团队需要一个全新的监控系统，可以让团队成员快速地诊断和修复问题；因为在系统告警的紧急情况下，每一秒都至关重要！
我们的 Node 团队 需要一个仅需一小撮人就能运维大型集群的系统。因此，我们构建了 Telltale。
Telltale 的特性如下：
汇集监控数据源，创建整体监控视图：Telltale 汇集了各种监控数据源，从而能创建关于应用程序运行状况的整体监控视图。
多维度判断应用程序的健康状况：Telltale 可以通过多个维度判断一个应用程序的健康情况，而无需根据单一指标频繁调整告警阈值。
及时告警：因为我们知道应用程序在什么情况下是正常的，所以能在应用程序有异常趋势时及时通知应用程序的所有者。
显示关键数据：指标是了解应用程序运行状态的关键。但很多时候，你拥有太多的指标、太多的图表以及太多的监控仪表盘。而 Telltale 仅显示应用程序中有用的相关数据及其上游和下游服务的数据。
用颜色区分问题的严重程度：我们使用不同的颜色来表示问题的严重程度（除选择颜色之外，还可以让 Telltale 显示不同的数字），以便运维人员一眼就能判断出应用程序的运行状况。
高亮提示：我们还会对一些监控事件进行高亮提示，比如局部区域的网络流量疏散及就近的 服务部署，这些信息对于全面了解服务的健康情况至关重要，尤其是在真正发生系统故障的情况下。
这就是我们的 Telltale 监控。它现已成功运行并提供监控服务，监控着 Netflix 100 多个生产应用程序的运行状况。
从产品能力看，Telltale 解决的是应用监控的四个核心问题：
| 问题 | Telltale 的处理方式 | 对值班人员的价值 |
|---|---|---|
| 数据太分散 | 汇集多个监控数据源，形成应用健康视图 | 减少在多个仪表盘之间来回切换 |
| 阈值难维护 | 用多个维度判断应用健康度 | 降低频繁调阈值带来的误报和漏报 |
| 告警缺上下文 | 告警中带出上下游、事件和可能原因 | 更快判断问题是否由本服务引起 |
| 事件难复盘 | 创建异常快照并记录事件生命周期 | 支撑事后审查和模式分析 |
应用程序健康评估模型
微服务并非是孤立存在和运行的。它需要特定的依赖，与其他服务进行数据交互，甚至位于不同的 AWS 区域。
上面的调用图是一个相对简单的图，其中涉及许多服务，实际的调用链可能会更深更复杂。
一个应用程序是系统生态的一部分，它的运行状态可能会受到相关属性变化的微弱影响，也有可能会受到区域范围内某些事件的影响从而发生根本性改变。
canary 的启动可能会对应用程序产生一定影响。在一定程度上，上游或下游服务的部署同样也可以带来一定的影响。
Telltale 通过使用多个维度的数据源构建一个不断自我优化的模型来监控应用程序的健康度：
- Atlas 时序指标
- 区域网络流量疏散
- Mantis 实时流数据
- 基础架构变更事件
- Canary 部署及使用
- 上、下游服务的运行状况
- 表征 QoE 的相关指标
- 告警平台发出的报警
这些数据源的作用并不相同。Telltale 的重点，是把不同信号放到同一个应用健康评估框架里，而不是把所有指标平铺到仪表盘上。
| 数据源 | 主要提供的信息 | 对健康评估的作用 |
|---|---|---|
| Atlas 时序指标 | 延迟、错误率、吞吐等时间序列变化 | 识别应用运行趋势和异常波动 |
| 区域网络流量疏散 | 不同 AWS 区域的流量变化 | 判断区域级事件对服务的影响 |
| Mantis 实时流数据 | 实时事件和流式数据 | 补充更及时的异常信号 |
| 基础架构变更事件 | 部署、配置、基础设施变化 | 解释异常发生前后的环境变化 |
| Canary 部署及使用 | 新版本灰度相关状态 | 判断问题是否与发布有关 |
| 上、下游服务状态 | 依赖服务的健康信息 | 区分本服务问题和依赖问题 |
| QoE 相关指标 | 用户体验质量信号 | 把系统指标和用户体验连接起来 |
| 告警平台报警 | 已触发的异常事件 | 作为模型判断和通知链路的一部分 |
不同的数据源对应用程序健康度的影响权重不同。例如，与错误率增加相比，响应时间的增加对应用程序的影响要小很多。
错误代码有很多，但是某些特定的错误代码的影响要比其他错误代码的影响大。在服务下游部署 canary 可能不如在上游部署带来的效果明显。
区域网络流量转移意味着某个区域的网络流量降为零而另一个区域的网络流量会加倍。
你可以感受下不同的指标对于监控的影响。监控指标的具体含义决定了我们应该如何科学有效地使用它来进行监控。
在构建应用程序健康状况视图时，Telltale 考虑了所有这些因素。应用程序健康评估模型是 Telltale 的核心。
这里的关键结论是：微服务健康度不是单点指标，而是拓扑、依赖、区域、部署和用户体验共同作用的结果。一个监控系统如果只盯单个阈值，就很难在复杂生产环境中给出可信判断。
智能监控
每个服务运维人员都知道告警阈值调整的难度。将阈值设置得太低，你会收到大量虚假告警。
如果过度补偿并放宽告警阈值，就会错过重要的异常警告。这样导致的最终结果是对告警缺乏信任。Telltale 可以帮助你免除不断调整相关配置的繁琐工作。
通过提供准确的和严格管理的数据源，我们能让应用程序所有者的设置和配置过程变得更加容易。
这些数据源通过按照一定的组合应用到程序的配置中，以实现最常见的服务类型配置。
Telltale 可以自动追踪服务之间的依赖关系，以构建应用程序健康评估模型中的拓扑。
通过数据源管理以及拓扑监测，在不用付出很大的努力情况下就能使配置保持最新状态。那些需要手动实践的一些场景仍然支持手动配置和调整。
没有任何一个独立的算法可以适用我们所有的监控场景。因此，我们采用了混合算法，包括统计算法、基于规则的算法和机器学习算法。
不久后，我们将在 Netflix Tech Blog 上发表一篇针对我们监控算法的文章。
Telltale 还具有分析器，可用于趋势探测或内存泄漏监测。智能监控意味着我们的用户可以信赖我们的监控结果。
这表明故障发生时，用户能更快地定位和解决系统异常问题。
Telltale 的智能监控不是完全依赖某一种算法。原文提到 Netflix 采用混合算法，包括统计算法、基于规则的算法和机器学习算法。这说明在复杂监控场景中，单一算法很难覆盖所有服务形态，模型、规则和工程经验需要共同工作。
智能告警
智能监控必然会促进智能告警。当 Telltale 检测到应用程序中的运行异常时，就会产生异常事件。
团队可以选择通过 Slack、电子邮件或 PagerDuty（均由我们的内部告警系统提供支持）进行告警。
如果该异常问题是由上游或下游系统引起的，则 Telltale 的上下文感知路由会提醒服务对应的维护团队。
智能告警还意味着运维团队针对特定异常只会收到一个通知，也就是说，告警风暴已经成为过去式。
在系统出现问题时，掌握准确的信息至关重要。我们的 Slack 告警程序还会启动一个包含有关事件上下文信息的线程，提供 Telltale 识别到的异常问题信息及问题产生的原因。
正确的上下文可以方便我们了解应用程序的当前状态，以便值班运维的工程师能有针对性的定位和修复问题。
异常告警事件会不断发展而且拥有自己的生命周期，因此及时更新事件状态至关重要。告警异常是好转了还是恶化了？是否要考虑新的监控信息或事件？
Telltale 在当前事件发生改变时会更新 Slack 线程。系统返回正常状态后，该线程将被标记为“已解决”，因此用户一眼就能知道哪些异常事件正在处理中，哪些异常事件已成功修复。
这些 Slack 线程不仅仅适用于 Telltale。团队还可以用它们来共享有关事件的其他数据，方便进一步观察、理论分析和讨论。
异常信息数据和讨论全部集中在一个线程中，方便达成针对当前异常的共识，有利于更快提出问题的解决方案以及异常事件的事后分析。
我们致力于提高 Telltale 告警的质量。一种方法是向我们的用户学习。因此，我们在 Slack 消息中提供了反馈按钮。
用户可以告诉我们以后某些情况不需要再发生告警，或提供某些告警不合理的原因。智能告警意味着用户可以信赖我们的告警。
为什么我的应用服务运行状态欠佳？各种类型的监控数据、应用程序相关知识以及跨多种服务数据的相关性，有助于 Telltale 检测分析应用程序运行健康度降低的原因。
这些原因包括实例异常、相关依赖的监测和部署异常、数据库异常或者网络流量高峰等。突出高亮显示这些可能的原因可以帮助运维人员节省大量宝贵的时间。
智能告警的核心，是让通知本身带着调查入口。Telltale 的 Slack 线程把异常描述、原因、上下文、状态更新、团队讨论和反馈按钮放在同一个位置，减少了告警之后的信息分散。
| 告警能力 | 解决的问题 | 预期效果 |
|---|---|---|
| 上下文感知路由 | 上下游问题容易通知错团队 | 把告警发给更可能负责的维护团队 |
| 单异常单通知 | 告警风暴导致值班人员疲劳 | 降低重复通知和噪音 |
| Slack 线程 | 异常信息、讨论和状态分散 | 形成事件上下文聚合点 |
| 生命周期更新 | 异常好转或恶化不易同步 | 让响应者看到事件是否仍在处理中 |
| 反馈按钮 | 告警质量无法持续改进 | 从用户反馈中优化后续告警 |
异常事件管理
当 Telltale 发送告警时，它还会创建一个快照，其中引用了不正常的监控信号数据。随着新监控信息的到来，会将其添加到此快照中。
这简化了团队的很多事后审查流程。当需要复查过去的异常问题时，“应用程序事件摘要”功能可以从各个方面显示当前的问题，包括一些关键指标，比如总停机时间和 MTTR（平均解决时间）。
我们希望帮助我们的团队了解更多的异常事件的模式，以便提高我们服务的整体可用性。
异常事件管理补齐的是监控闭环。告警触发只是开始，真正有价值的是记录异常信号、持续追加证据、沉淀事件摘要，并在事后从模式中学习。这样监控系统才不只是“发现问题”，还可以帮助团队改善下一次响应。
部署监控
可以看出，Telltale 的应用程序健康评估模型及其智能监控功能非常强大，所以我们也会将其应用于安全部署方面。我们从开放源码交付平台 Spinnaker 开始测试。
随着 Spinnaker 逐渐推出新版本，我们使用 Telltale 连续监监控运行新版本实例的运行状态。
持续监控意味着新部署在问题出现时能自行停止并进行回滚操作。这意味着部署存在问题时的影响半径较小，持续时间更短。
把 Telltale 用于部署监控，说明应用健康模型不仅可以用于事故响应，也可以前移到变更风险控制。对复杂微服务系统来说，发布过程中的持续监控和自动停止，比发布后等待告警更符合风险控制逻辑。
持续优化
在复杂的系统中，运行微服务非常具有挑战性。Telltale 的智能监控和告警功能可以帮助我们运维人员提高系统可用性、降低运维人员的劳动强度并减少工作人员大半夜被叫醒的频率。
我们为 Telltale 做到的这些功能提升感到高兴。但是远没有结束，我们仍在不断探索新算法，以提高告警的准确性。
我们将在以后的 Netflix Tech Blog 文章中详细介绍我们的工作进展。我们仍然在对应用程序健康评估模型进行进一步评估和改进。
我们相信服务运行日志和跟踪数据中会包含更多有价值的信息，这样我们就能采集到更有用的指标数据。我们很期待与平台其他团队进行合作，共同开发这些新功能。
将新应用监控引入 Telltale 可以享受到很好的服务体验，但是无法很好的进行扩展，所以我们绝对可以优化和提高自服务的用户界面。
我们确信，有更好的启发式方法能帮助用户找出影响服务健康度的一些因素。Telltale 简化了应用程序的监控。
FAQ
Q1：Telltale 和普通监控仪表盘有什么区别？ A：普通仪表盘主要展示数据，Telltale 更强调应用健康评估模型、上下文告警、异常事件生命周期和部署监控。它的目标是减少值班人员在多个数据源中手工寻找线索的时间。
Q2：为什么 Telltale 不只依赖阈值告警？ A：微服务健康度会受到上下游依赖、区域流量、基础架构变更、Canary、QoE 和历史事件等多种因素影响。单一阈值很容易误报或漏报。
Q3：Telltale 的智能告警重点是什么？ A：重点是把告警和上下文绑定，包括可能原因、上下游影响、Slack 线程、状态更新、团队路由和反馈机制，而不是简单增加通知渠道。
Q4：这篇文章对其他团队有什么借鉴意义？ A：可以借鉴三点：用多维度健康模型替代孤立阈值；让告警携带调查上下文；把事件管理和部署监控纳入同一套可观测性闭环。
