【第7期】云计算监控——Prometheus监控系统

本文摘自于《Prometheus监控技术与实战》一书，从云计算时代的业务特点出发，探讨了云计算监控的目标和挑战，梳理了云资源监控的范围及监控系统实现的一般方式。接着从开源监控软件的演进出发，简单介绍了Zabbix、OpenTSDB等常用监控系统。最后详细介绍Prometheus云原生监控系统的产生、发展、特点，以及成功部署可获得的运营优势。

   

1　云计算监控的目标和挑战

1. 1　云计算监控目标

监控系统的目标是：提供对复杂信息系统的全面监控，反映云资源池的健康状况和可用性情况，得到一个可控制、可预测的云环境，支持云业务安全、稳定、高效、持续地运行；同时，有效地控制管理成本，规范管理工作，实现运行管理的智能化和高效性，提高整体的维护水平；及时掌握各种资源现状和运行信息，为决策提供支持。

监控是运维团队眼睛的延伸。监控系统应当解决三个问题：“出问题了吗？”“哪里出了问题？”“是什么问题？”

在《SRE：Google运维解密》一书中指出，监控系统需要有效地支持白盒监控和黑盒监控。通过白盒监控能够了解其内部的实际运行状态，观察监控指标能够预判可能出现的问题，从而对潜在的不确定因素进行优化。而黑盒监控，常见的如HTTP探针、TCP探针等，可以在系统或者服务发生故障时快速通知相关人员进行处理。通过建立完善的监控体系，可以达到以下目的。

• 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。

• 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过监控能够方便地对系统进行跟踪和比较。

• 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速处理或者提前预防问题的发生，避免对业务产生影响。

• 故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对比分析不同监控数据与历史数据，能够找到并解决根源问题。

• 数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况，以及服务运行状态等直观的信息。

网站可靠性工程SRE（Site Reliability Engineer）的终极责任是确保该服务可以正常运转。为达成这个目标，SRE定义了一套服务可靠性层级模型，需要完成开发监控系统、规划容量、处理紧急事件、确保事故根源被跟踪修复等一系列工作。

 服务可靠性层级模型

 

监控系统是服务可靠性层级中的最底层。离开了监控系统，就没有能力辨别一个系统是否在正常提供服务。没有一套设计周全的监控体系就如同蒙着眼睛狂奔。作为一个合格的系统运维人员，需要先于用户发现系统中存在的问题。没有监控的支持，上层应急事件处理、事后总结/问题根因分析、测试+发布、容量规划、软件开发、产品设计也就没有了根基。

 

1.2　云计算监控挑战

要对基于现代基础设施的应用系统进行监控，将面临DevOps实践和基础架构代码化，监控系统将会迎接若干重大挑战。

挑战1：持续变更。

在运维中需要监测偏离正常行为的信号，这里所说的“正常行为”是假设系统已经稳定运行了很长时间。然而，在一个大型复杂环境中，变更是常态。这些变更来自于：

• 云计算的弹性，使得基础设施资源变得更灵活。

• 自动化的DevOps运维，触发很多零散的运维操作（例如升级、重配置、备份），零散的运维、持续部署和部署实践使得软件变更更加频繁。

• 持续变更中，监控的参数频繁变更，监控系统参数也经常需要随着变更。

• 系统基础设施和系统本身的持续变更使得监控参数的设置变得复杂。即使向相同的虚拟机提交请求，仍然存在巨大的性能差别。这些差别来自于你无法控制的因素，如你得到的CPU的类型。你的监控可能需要调整以适应这种变化，或者你可以配置缩放控制器，以便用新的虚拟机来代替性能下降或提升的虚拟机。

• 自动化设置警报、告警和阈值。监控配置过程是另一个DevOps过程，应该实现自动化。当提供一台新服务器时，应该在监控系统中自动注册这台服务器；当服务器停止使用时，应该自动触发注销流程。

挑战2：自下而上还是自上而下

监控的主要目的是尽可能快地发现缺陷、错误或小规模的故障，以便能够尽早做出反应。我们很自然地采用了自下而上的方式进行监控：根据聚合值，低层中的错误和单个模块中的错误，可以在它们传播和影响到上层应用服务器或者应用本身之前被发现。这里要面临两个挑战：

• 需要监控越来越多的模块级别和其他低级别的内容。一个应用由多个组件组成，可能部署在上百台服务器上，依赖于网络和存储组件的支持。在实际环境中，把这些监控信息相关联并找到根源是非常困难的。

• 在云中，低层基础设施和服务器之间有正常和异常的分配，例如，服务器漂移的终止操作、伸缩以及滚动升级，或者实例失效或者资源共享不稳定等，导致监控服务器非常复杂。

采取自上而下的方法来监控基于云的和高度复杂的系统是解决以上问题的一种尝试，通过监控上层或者聚合数据，从顶层问题出发再以智能的方式深入低层数据。仍然必须收集低层数据，但不会系统化地监控错误。这种方式也面临挑战：

• 发现问题时可能为时已晚。当在上层注意到有错误时，阻止影响的扩大可能已经来不及了。

• 如何深入到低层数据。现代分布式系统有内置的容错机制来掩盖故障和错误，防止在系统层面出现问题直接影响用户体验，因此，检测到上层问题距离低层根本故障原因出现，可能已经过去相当长的一段时间了。