Prometheus（一）监控基础

监控简介

Prometheus是一个开源的监控系统，它从应用程序中实时获取时间序列数据，然后通过功能强大的规则引擎，帮助你识别监控环境所需的信息。

本书将指导你使用Prometheus来构建监控系统，重点将放在**动态云环境、Kubernetes环境和容器环境的监控。**同时，我们还将研究如何从应用程序获取数据并将这些数据用于警报和可视化。

什么是监控

从技术角度来看，监控（monitoring）是衡量和管理技术系统的工具和流程。但监控远不止于此，监控将系统和应用程序生成的指标转换为对应的业务价值。你的监控系统会将这些指标转换为衡量用户体验的依据，该依据为业务提供反馈，以确保为客户提供了所需的产品。

监控系统的两个客户：技术、业务

技术作为客户

可以通过监控来了解技术环境状况，还可以帮助检测、诊断和解决技术环境中的故障和问题（尤其是在影响用户之前）。监控提供了大量的数据，帮助洞察关键的产品和技术决策，并衡量这些项目是否成功。监控也是产品管理生命周期以及与内部客户关系的基础，有助于验证项目资金是否得到充分利用。

业务作为客户

监控系统是为了支持业务，并确保业务持续开展。监控可以提供报告，使企业能够进行良好的产品和技术投资，还有助于企业衡量技术带来的价值。

监控基础知识

监控是管理基础设施和业务的核心工具。监控也是必需的，应该和应用程序一起构建和部署。没有监控，你将无法了解你的系统环境、进行诊断故障、制定容量计划，也无法向组织提供系统的性能、成本和状态等信息。

Google服务层次结构图

事后监控

对于任何应用程序开发方法，在构建之前确定要构建的内容都是个好主意。遗憾的是，有一种常见的反模式，即将监控和其他运维工作（比如安全性）视为应用程序的增值组件而非核心功能。与安全性一样，监控也应该是应用程序的核心功能。如果你要为应用程序构建规范或用户故事，那么务必先把应用程序每个组件的监控指标考虑进来，千万不要等到项目结束或部署之前再做这件事情。

机械式监控

许多环境都会为所有应用程序建立货物崇拜式的监控系统**。团队始终复用他们过去使用的检查机制，而不会为新系统或应用程序进行更新。一个常见的例子是监控每台主机上的CPU、内存和磁盘**，但不监控可以指示主机上应用程序是否正常运行的关键服务。如果应用程序在你没有注意到的情况下发生故障，那么即使进行了监控，你也需要重新考虑正在监控的内容是否合理。

根据服务价值设计自上而下的监控系统是一个很好的方式，这会帮助明确应用程序中更有价值的部分，并优先监控这些内容，再从技术堆栈中依次向下推进。

不够准确的监控

这个反模式的一个常见形式是虽然监控了主机上的服务状态，但不够准确。例如，通过检查HTTP 200状态码可以监控Web应用程序是否正常运行，它会告诉你应用程序正在响应请求，但并不会反映出是否返回了正确的数据。因此需要找准服务监控的内容——例如，监控业务事务的内容或速率，而不是监控它运行的Web服务器的运行时间。你会获得两种好处：如果服务因配置错误、程序bug或受损而导致内容不正确，你会及时查看到；而如果内容因底层Web服务而出现错误，你同样也会知道。

静态监控

另一种反模式是使用静态阈值——例如**，如果主机的CPU使用率超过80%就发出警报**。这种检查通常是不灵活的布尔逻辑或者一段时间内的静态阈值，它们通常会匹配特定的结果或范围，这种模式没有考虑到大多数复杂系统的动态性。阈值的匹配或许很重要，但它可能由异常事件触发，甚至可能是自然增长的结果。

为了更好地监控，我们需要查看数据窗口，而不是静态的时间点，需要使用更智能的技术来分析指标和阈值。

不频繁的监控

对于许多监控工具来说，设定监控周期都是一项挑战，一般默认检查周期设置了一个较大的值——例如，每隔5～15分钟仅检查一次应用程序。这通常会导致检查之间发生的关键事件丢失。你应该频繁地监控应用程序，以获得以下好处：

• 识别故障或异常。
• 满足响应时间预期——你绝对希望在用户报告故障之前找到问题。
• 提供更细颗粒度的数据，以识别性能的问题和趋势。

缺少自动化或自服务

监控系统很差或者没能正确实施的常见原因是它很难实现。如果你让应用程序开发人员觉得监测应用程序、收集数据或可视化很难完成，那么他们可能就不会去做这些事。如果监控的基础设施是手动维护的，或者过于复杂，那么由此产生的问题将导致监控系统落后或者发生故障，然后你会花费更多的时间来修复和维护监控系统，而不是监控这件事本身。

应尽可能使监控系统的实施和部署自动化：

• 应该由配置管理进行部署。
• 主机和服务的配置应该通过自动发现或自助提交来进行，这样可以自动监控新的应用程序，而不需要人为添加。
• 添加检测应该很简单，并且是基于插件模式，开发人员应该能够把它放置到库中，而不必自己配置它。
• 数据和可视化应该是自服务的。每个需要查看监控输出的人都应该能够查询和可视化这些内容。

监控模式总结

一个良好的监控系统应该能提供以下内容：

• 全局视角，从最高层（业务）依次展开。
• 协助故障诊断。
• 作为基础设施、应用程序开发和业务人员的信息源。
• 同时它也应该是：
  • 内置于应用程序设计、开发和部署的生命周期中。
  • 尽可能自动化，并提供自服务。