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