导语：Prometheus是一个开源的监控系统，它从应用程序中实时获取时间序列数据，然后通过功能强大的规则引擎，帮助你识别监控环境所需的信息。在学习Prometheus之前，你需要先了解一些监控的基础知识，本文将循序渐进地介绍什么是监控、以及通用的监控方法。
一、 监控的客户
从技术角度来看，监控是衡量和管理技术系统的工具和流程。但监控远不止于此，监控将系统和应用程序生成的指标转换为对应的业务价值。你的监控系统会将这些指标转换为衡量用户体验的依据，该依据为业务提供反馈，以确保为客户提供了所需的产品。同时该依据还提供了对技术的反馈，指出哪些组件不起作用或者导致服务质量下降。
实际上，监控系统有以下两个“客户”：
- 技术
- 业务
1 技术作为客户
监控系统的第一个客户是技术。这是你、你的团队以及其他管理和维护技术环境的同事（可能被称为运维工程师、DevOps或是SRE）。你可以通过监控来了解技术环境状况，还可以帮助检测、诊断和解决技术环境中的故障和问题（尤其是在影响用户之前）。监控提供了大量的数据，帮助洞察关键的产品和技术决策，并衡量这些项目是否成功。监控也是产品管理生命周期以及与内部客户关系的基础，有助于验证项目资金是否得到充分利用。如果没有监控，最好的情况是没有问题发生，最糟糕的是问题发生了但没有被发现。
2 业务作为客户
业务是监控系统的第二个客户。监控系统是为了支持业务，并确保业务持续开展。监控可以提供报告，使企业能够进行良好的产品和技术投资，还有助于业务衡量技术带来的价值。
二 监控基础知识
监控是管理基础架构和业务的核心工具。监控也是必需的，应该和应用程序一起构建和部署。没有监控，你将无法了解你的系统环境、进行诊断故障、制定容量计划，也无法向组织提供系统的性能、成本和状态的信息。
关于监控，Google服务层次结构图就是一个很好的的阐述。
图1 服务层级
但是监控没有那么容易实施，如果你监控了错误的东西或者使用错误的方式，那监控系统的价值将大大降低，这里列举一些关于监控的反模式和解决方案。
1 事后监控
对于任何应用程序开发方法，在构建之前确定要构建的内容都是个好主意。遗憾的是，有一种常见的反模式，即将监控和其他运维工作，比如安全性，视为应用程序的增值组件而非核心功能。与安全性一样，监控也应该是应用程序的核心功能。如果你要为应用程序构建规范或用户故事，务必先把应用程序每个组件的监控指标考虑进来，千万不要等到项目结束或部署之前再做这件事情。我保证你会错过一些需要监控的东西。
2 机械式监控
许多环境会为所有应用程序建立货物崇拜（Cargo Cult）式的监控系统。团队始终复用他们过去使用的检查机制，而不会为新系统或应用程序进行更新。一个常见的例子是监控每台主机上的CPU、内存和磁盘，但不监控可以指示主机上的应用程序是否正常运行的关键服务。如果应用程序在你没有注意到的情况下发生故障，即使进行了监控，你也需要重新考虑你正在监控的内容是否合理。
根据服务价值设计自上而下的监控系统是一个很好的方式，这会帮助明确应用程序中更有价值的部分，并优先监控这些内容，再从技术堆栈中依次向下推进。
图2 监控设计
从业务逻辑和业务输出开始，向下到应用程序逻辑，最后到基础架构。这并不意味着你不去收集基础架构或操作系统指标 - 它们在诊断和容量规划中很有帮助 - 但你不太可能使用这些来报告应用程序的价值。
注： 如果无法从业务指标开始，则试着从靠近用户侧的地方开始监控。因为他们才是最终的客户，他们的体验是推动业务发展的动力，了解他们的体验并发现他们何时遇到问题本身就很有价值。
3 不够准确的监控
这个反模式的一个常见形式是虽然监控了主机上的服务状态，但不够准确。例如，通过检查HTTP的200状态码可以监控Web应用程序是否正常运行，它会告诉你应用程序正在响应请求，但是它并不会反映出是否返回了正确的数据。
因此需要找准服务监控的内容 - 例如，监控业务事务的内容或速率，而不是监控它运行的Web服务器的运行时间。你会这两种好处：如果服务因为配置错误、程序bug或受损导致内容不正确，你会及时查看到；如果是因为底层Web服务出现故障，你同样也会知道。
4 静态监控
另一种反模式是使用静态阈值 - 例如，如果主机的CPU使用率是否超过80％就发出警报。这种检查通常是不灵活的布尔逻辑或者一段时间内的固定阈值，它们通常会匹配特定的结果或范围，这种模式没有考虑到大多数复杂系统的动态性。阈值的匹配或许很重要，它可能由异常事件触发 - 或者甚至可能是自然增长的结果。
静态阈值几乎总是错误的。数据库性能分析供应商VividCortex首席执行官Baron Schwartz对此评论道：
它们比一个停摆的时钟更糟糕，至少时钟每天还会有两次准的时候。任何给定系统的阈值都是错误的，因为所有系统都略有不同，并且在任何给定时刻也都是错误的，因为系统在经历不断变化的负载和其他情况。
为了更好地监控，我们需要查看数据窗口，而不是静态的时间点，我们需要使用更智能的技术来分析指标和阈值。
5 不频繁的监控
对于许多监控工具来说，设定监控周期都是一项挑战，一般默认检查周期设置了一个较大的值 - 例如，每隔5到15分钟仅检查一次应用程序。这通常会导致检查之间发生的关键事件丢失。你应该频繁地监控应用程序，以获得以下好处：
识别故障或异常
满足响应时间预期 - 你绝对希望在用户报告故障之前找到问题
提供更细颗粒度的数据，以识别性能的问题和趋势
始终记住存储足够多的历史数据可以有效地帮助识别性能的问题和趋势。在很多情况下，这可能只需要数天或数周的数据 - 但如果丢弃了这些数据，则可能无法识别出趋势或发现重复出现的问题。
6 监控模式总结
一个良好的监控系统应该能提供以下内容：
全局视角，从最高层（业务）依次展开
协助故障诊断
作为基础架构、应用程序开发和业务人员的信息源
同时它也应该是：
内置于应用程序设计、开发和部署的生命周期中
尽可能自动化，并提供自服务
注： 这种对监控系统“良好”的定义与另一个新出现的术语 - 可观察性 - 是交叉重叠的。你可以在Cindy Sridharan的精彩博客文章中了解更多相关信息，了解两者之间的差异。
7 警报和通知
警报和通知是监控工具的主要输出。那么警报和通知之间有什么区别呢？警报是当某些事件发生了，如指标达到阈值时。然而，这并不意味着有人被告知此事件发生，这是通知的来源。通知接收警报并告知某人或某事：通过发送电子邮件、发送短信或者创建工单等。看起来这应该是一个非常简单的领域，但它通常包含很多复杂因素，并且很难实施和管理。
要建立一个出色的通知系统，需要考虑以下基础信息：
哪些问题需要通知
谁需要被告知
如何告知他们
多久告知他们一次
何时停止告知，何时升级到其他人。
如果配置不当导致生成了过多通知，那么人们将无法对它们采取任何行动，甚至可能将它们忽略掉。我们都有过这样的故事：收件箱中充满了来自监控系统的成千上万封通知邮件。有时你会因为收到很多通知，而出现警报疲劳忽略它们（或者更糟糕的是，对通知邮件直接全选 -> 删除）。因此，你可能会错过真正的重要通知。
最重要的是，你需要考虑通知内容。通常当出现问题或者有事件需要你注意时，通知是唯一的途径。它们需要简洁、清晰、准确，易于理解并且可操作。设计有价值、有意义的通知至关重要。让我们通过一个示例，看看通知内容为什么很重要。以下是Nagios关于磁盘空间的通知。
代码清单1.1 Nagios通知样例
想象一下，你刚刚在凌晨3点36分收到这条通知。它都告诉了你哪些信息？首先，这是一个主机磁盘空间警报，并且/data目录存储已达到91％。乍一看这很有价值，但实际上并没有那么实用。首先，这是一个存储空间突增导致的？还是逐渐增长的结果？增常速度是多少？（1 GB分区上9％的可用磁盘空间与1 TB磁盘上9％的可用磁盘空间完全不同）你可以忽略或静音这类通知嘛？还是需要立即采取行动？如果没有其他上下文，采取的行动就会受到限制，你需要投入相当多的时间来收集上下文。
在我们的框架中，将重点关注以下内容：
使通知清晰、准确、可操作。使用由人而不是计算机编写的通知在清晰度和实用性方面有显著差异
为通知添加上下文。通知应包含组件的其他相关信息
仅发送有意义的通知
提示： 在这里给出的最简单的建议是记住：通知是供人而不是计算机阅读的，请用心地设计它们。Datadog团队也发布了一篇关于可视化时间序列数据的文章，同样值得一读。
在本章中，我们介绍了现代监控方法，列举了几种监控实现的细节。我们讨论了监控的最佳实践和反模式，以及如何避免反模式的设计。
我们还详细地介绍了时间序列数据和指标，细分并讲解了不同的指标类型。此外，本章还演示了一些应用在指标上的常见数学函数和聚合操作。
三 小结
在本文中，我们介绍了现代监控方法，列举了几种监控实现的细节。我们讨论了监控的最佳实践和反模式，以及如何避免反模式的设计。
以上内容摘自《Prometheus监控实战》一书，经出版方授权发布。
文章来源：微信公众号Linux云计算网络
