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