《Prometheus监控实战》第1章　监控简介

第1章　监控简介

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

1.1　什么是监控

• 监控将系统和应用程序生成的指标转换为对应的业务价值。你的监控系统会将这些指标转换为衡量用户体验的依据，该依据为业务提供反馈，以确保为客户提供了所需的产品。同时该依据还提供了对技术的反馈，指出哪些组件不起作用或者导致服务质量下降
• 监控系统有以下两个“客户”
  • 技术
  • 业务

1.1.1　技术作为客户

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

1.1.2　业务作为客户

• 监控可以提供报告，使企业能够进行良好的产品和技术投资，还有助于企业衡量技术带来的价值

1.2　监控基础知识

• 监控是管理基础设施和业务的核心工具。监控也是必需的，应该和应用程序一起构建和部署

1.2.1　事后监控

• 对于任何应用程序开发方法，在构建之前确定要构建的内容都是个好主意。遗憾的是，有一种常见的反模式，即将监控和其他运维工作（比如安全性）视为应用程序的增值组件而非核心功能
• 服务层级（图）

1.2.2　机械式监控

• 团队始终复用他们过去使用的检查机制，而不会为新系统或应用程序进行更新。一个常见的例子是监控每台主机上的CPU、内存和磁盘，但不监控可以指示主机上应用程序是否正常运行的关键服务
• 根据服务价值设计自上而下的监控系统是一个很好的方式，这会帮助明确应用程序中更有价值的部分，并优先监控这些内容，再从技术堆栈中依次向下推进
• 监控设计（图）

• 如果无法从业务指标开始，则可试着从靠近用户侧的地方开始监控。因为他们才是最终的客户，他们的体验是推动业务发展的动力，了解他们的体验并发现他们何时遇到问题本身就很有价值

1.2.3　不够准确的监控

• 这个反模式的一个常见形式是虽然监控了主机上的服务状态，但不够准确。例如，通过检查HTTP 200状态码可以监控Web应用程序是否正常运行，它会告诉你应用程序正在响应请求，但并不会反映出是否返回了正确的数据

1.2.4　静态监控

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

1.2.5　不频繁的监控

• 你应该频繁地监控应用程序，以获得以下好处
  • 识别故障或异常
  • 满足响应时间预期——你绝对希望在用户报告故障之前找到问题
  • 提供更细颗粒度的数据，以识别性能的问题和趋势

1.2.6　缺少自动化或自服务

• 监控系统很差或者没能正确实施的常见原因是它很难实现。如果你让应用程序开发人员觉得监测应用程序、收集数据或可视化很难完成，那么他们可能就不会去做这些事
• 应尽可能使监控系统的实施和部署自动化
  1. 应该由配置管理进行部署
  2. 主机和服务的配置应该通过自动发现或自助提交来进行，这样可以自动监控新的应用程序，而不需要人为添加
  3. 添加检测应该很简单，并且是基于插件模式，开发人员应该能够把它放置到库中，而不必自己配置它
  4. 数据和可视化应该是自服务的。每个需要查看监控输出的人都应该能够查询和可视化这些内容。（这并不是说你不应该为人们构建仪表板，而是如果他们想要更多，他们就不应该问你。）

1.2.7　监控模式总结

• 一个良好的监控系统应该能提供以下内容
  1. 全局视角，从最高层（业务）依次展开
  2. 协助故障诊断
  3. 作为基础设施、应用程序开发和业务人员的信息源
  4. 内置于应用程序设计、开发和部署的生命周期中
  5. 尽可能自动化，并提供自服务

1.3　监控机制

• 从单元测试到检查清单（checklist）的所有事情都是监控的某种形式

1.3.1　探针和内省

• 监控应用程序主要有两种方法

探针（probing）

• 探针监控是在应用程序的外部，它查询应用程序的外部特征：监听端口是否有响应并返回正确的数据或状态码

内省（introspection）

• 内省监控主要查看应用程序内部的内容。应用程序经过检测，并返回其状态、内部组件，或者事务和事件性能的度量
• 内省监控可以直接将事件、日志和指标发送到监控工具，也可以将信息发送给状态或健康检查接口，然后由监控工具收集

1.3.2　拉取和推送

• 关于这些优点和缺点，监控领域内部存在相当大的争议，但就许多用户而言，这些辩论没有实际意义。Prometheus主要是一个基于拉取的系统，但它也支持接收推送到网关的事件

1.3.3　监控数据的类型

• 监控工具可以收集各种不同类型的数据，这些数据主要有两种形式：
  1. 指标：大多数现代监控工具都非常依赖指标来帮助我们了解系统的情况。指标存储为时间序列数据，用于记录应用程序度量的状态
  2. 日志：日志是从应用程序发出的（通常是文本的）事件。虽然有助于让你知道发生了什么，但它们通常对故障诊断和调查最有帮助

1.4　指标

• 指标似乎始终是任何监控体系结构中最直接的部分。然而，有时候我们并没有投入足够的时间来理解我们正在收集的内容，为什么要收集它们，以及我们对这些指标做了些什么
• Prometheus改变了“指标作为补充”的观念，指标变成了监控工作流程中最重要的部分。Prometheus颠覆了以故障检测为中心的模型，指标用来反映环境的状态、可用性以及性能

1.4.1　什么是指标

• 由于指标和度量对监控框架至关重要
• 指标是软件或硬件组件属性的度量。为了使指标有价值，我们会跟踪其状态，通常记录一段时间内的数据点。这些数据点称为观察点（observation），观察点通常包括值、时间戳，有时也涵盖描述观察点的一系列属性（如源或标签）。观察的集合称为时间序列

1.4.2　指标类型

测量型

• 测量型（gauge），这种类型是上下增减的数字，本质上是特定度量的快照

计数型

• 计数型（counter），这种类型是随着时间增加而不会减少的数字

• 直方图（histogram）是对观察点进行采样的指标类型，可以展现数据集的频率分布。将数据分组在一起并以这样的方式显示，这个被称为“分箱”（binning）的过程可以直观地查看数值的相对大小
• 直方图指标示例

1.4.3　指标摘要

• 通常来说，单个指标对我们价值很小，往往需要联合并可视化多个指标，这其中需要应用一些数学变换。例如，我们可能会将统计函数应用于指标或指标组
  1. 计数：计算特定时间间隔内的观察点数
  2. 求和：将特定时间间隔内所有观察点的值累计相加
  3. 平均值：提供特定时间间隔内所有值的平均值
  4. 中间数：数值的几何中点，正好50％的数值位于它前面，而另外50％则位于它后面
  5. 百分位数：度量占总数特定百分比的观察点的值
  6. 标准差：显示指标分布中与平均值的标准差，这可以测量出数据集的差异程度。标准差为0表示数据都等于平均值，较高的标准差意味着数据分布的范围很广
  7. 变化率：显示时间序列中数据之间的变化程度

1.4.4　指标聚合

• 你可能经常希望能看到来自多个源的指标的聚合视图，例如所有应用程序服务器的磁盘空间使用情况。指标聚合最典型的样式就是在一张图上显示多个指标，这有助于你识别环境的发展趋势

平均值

• 平均值是标准的指标分析方法。实际上，几乎所有曾经监控或分析过网站及应用程序的人都会使用平均值
• 平均值假设事件都是正常的或者说你的数据是正态（或高斯）分布的——例如，在我们的平均响应时间中，假设所有事件以相同的速度运行或响应时间分布大致为钟形曲线，但应用程序很少出现这种情况。事实上，有个古老的统计学笑话，一位统计学家跳进平均深度只有10英寸（约25厘米）的湖中，然后差点被淹死……
• 平均值的缺陷（图）

中间数

• 中间数处在所有数值的正中心：正好50％的数值位于它前面，而另外50％则位于它后面。如果有奇数项个值，则处于中间位置的值即为中间数
• 你可能又发现这里的问题了，就像平均值一样，当数据分布呈钟形曲线时，中间数效果最好，但在真实环境中这是不现实的

标准差

• 标准差衡量数据集的变化或分布。标准差为0表示大部分数据接近平均值，标准差越大意味着数据越分散。标准差由正或负加上sigma符号表示，例如，1 sigma表示与平均值有一个标准差
• 在正态分布中，有一种简单的方式来阐明分布：经验法则，也称为68-95-99.7法则或3 sigma法则（如图1-13所示）。法则指出，一个标准差或1到–1代表平均值两边68.27％的数据，两个标准差或2到–2代表95.45％，而三个标准差则代表99.73％

百分位数

• 百分位数度量的是占总数特定百分比的观察点的值。从本质上讲，它们会展示数据集的分布。例如，一个事务的99百分位数为10毫秒，这很容易理解：99％的事务在10毫秒或更短时间内完成，1％的事务处理时间超过10毫秒
• 百分位数是识别异常值的理想选择。如果响应时间小于10毫秒表示你网站上的一个良好体验，那么99％的用户都是这样的——但其中1％的用户没有。一旦意识到这一点，你就可以专注于解决造成那1％的性能问题

• 然而，百分位数并不是完美的。我们建议绘制几种指标组合，以获得更清晰的数据图。例如，在测量延迟时，最好可以展示以下几项内容
  1. 50百分位数（或中间数）
  2. 99百分位数
  3. 最大值
• 当开始构建检查和收集指标时，我们会应用百分位数和其他聚合指标

1.5　监控方法论

• Brendan Gregg的USE（Utilization、Saturation和Error）方法[1]，侧重于主机级监控
  • resource: all physical server functional components (CPUs, disks, busses, ...)
  • utilization: the average time that the resource was busy servicing work
  • saturation: the degree to which the resource has extra work which it can't service, often queued
  • errors: the count of error events
• Google的四个黄金指标，专注于应用程序级监控
• 结合使用可以获得一个相当全面的环境视图，帮助你解决任何问题

1.5.1　USE方法

• USE是使用率（Utilization）、饱和度（Saturation）和错误（Error）的缩写，该方法是由Netflix的内核和性能工程师Brendan Gregg开发的。USE方法建议创建服务器分析清单，以便快速识别问题
• USE方法可以概括为：针对每个资源，检查使用率、饱和度和错误。该方法对于监控那些受高使用率或饱和度的性能问题影响的资源来说是最有效的
  1. 资源：系统的一个组件。在Gregg对模型的定义中，它是一个传统意义上的物理服务器组件，如CPU、磁盘等，但许多人也将软件资源包含在定义中
  2. 使用率：资源忙于工作的平均时间。它通常用随时间变化的百分比表示
  3. 饱和度：资源排队工作的指标，无法再处理额外的工作。通常用队列长度表示
  4. 错误：资源错误事件的计数
• 我们将这些定义结合起来创建一份资源清单，并采用一种方法来监控每个要素：使用率、饱和度和错误
• 在这个示例中，我们将从CPU开始

CPU

• CPU使用率随时间的百分比
• CPU饱和度，等待CPU的进程数
• 错误，通常对CPU资源不太有影响

内存

• 内存使用率随时间的百分比
• 内存饱和度，通过监控swap测量
• 错误，通常不太关键，但也可以捕获
• 检查清单：http://www.brendangregg.com/USEmethod/use-linux.html

1.5.2　Google的四个黄金指标

• Google的四个黄金指标来自Google SRE手册，它们采用与USE类似的方法，指定要监控的一系列通用指标类型
• 主要关注的不是系统级的时间序列数据，更多是针对应用程序或面向用户的部分：
  • 延迟：服务请求所花费的时间，需要区分成功请求和失败请求。例如，失败请求可能会以非常低的延迟返回错误结果
  • 流量：针对系统，例如，每秒HTTP请求数，或者数据库系统的事务
  • 错误：请求失败的速率，要么是HTTP 500错误等显式失败，要么是返回错误内容或无效内容等隐式失败，或者基于策略原因导致的失败——例如，强制要求响应时间超过30ms的请求视为错误
  • 饱和度：应用程序有多“满”，或者受限的资源，如内存或IO。这还包括即将饱和的部分，例如正在快速填充的磁盘
• Weaveworks团队开发了一个名为RED（Rate、Error和Duration）的相关框架，你可能也会对此感兴趣（https://rancher.com/red-method-for-prometheus-3-key-metrics-for-monitoring/）

1.6　警报和通知

• 要建立一个出色的通知系统，需要考虑以下基础信息
  1. 哪些问题需要通知
  2. 谁需要被告知
  3. 如何告知他们
  4. 多久告知他们一次
  5. 何时停止告知以及何时升级到其他人
• 如果配置不当，导致生成了过多通知，那么人们将无法对它们采取任何行动，甚至可能将它们忽略掉
• 最重要的是，你需要考虑通知内容。通常当出现问题或者有事件需要你注意时，通知是唯一的途径。它们需要简洁、清晰、准确，易于理解并且可操作。设计有价值、有意义的通知至关重要
• 在我们的框架中，将重点关注以下内容
  1. 使通知清晰、准确、可操作。使用由人而不是计算机编写的通知在清晰度和实用性方面有显著差异
  2. 为通知添加上下文。通知应包含组件的其他相关信息
  3. 仅发送有意义的通知
• 在这里给出的最简单的建议是记住“通知是供人而不是计算机阅读的”，请用心地设计它们

1.7　可视化

• 数据可视化既是一门非常强大的分析和解释技术，也是一种令人惊叹的学习工具。指标及其可视化通常很难解释
• 理想的可视化应该能够清晰地显示数据，突出重点而不仅是提高视觉效果。我们会按照以下规则进行构建
  1. 清晰地显示数据
  2. 引发思考（而不是视觉效果）
  3. 避免扭曲数据
  4. 使数据集保持一致
  5. 允许更改颗粒度而不影响理解

1.8　另一本关于监控的书

• 《The Art of Monitoring》

1.9　本书内容

• 本书会介绍关于监控的方法，然后使用Prometheus来实例化这些监控方法。在本书的最后，你应该可以搭建出一个高度可扩展的监控平台

1.10　小结

• 我们介绍了现代监控方法，列举了几种监控实现的细节。我们讨论了监控的最佳实践和反模式，以及如何避免反模式的设计

资料

• 《The Packer Book》
• 《The Terraform Book》
• 《The Art of Monitoring》
• 《The Docker Book》
• 《The Logstash Book》
• 《Pro Puppet》
• 《Pulling Strings with Puppet》
• 《Pro Linux System Administration》
• 《Pro Nagios 2.0》
• 《Hardening Linux》
• 《The Visual Display of Quantitative Information》
• 文章 https://www.datadoghq.com/blog/timeseries-metric-graphs-101/
• 代码：https://github.com/turnbullpress/prometheusbook-code