前言
监控数据有多种形式--有些系统会持续地输出数据，而其他系统只会在发生罕见事件时生成数据。有些数据能够直接定位问题，有些数据能帮助调查问题。更宽泛的说，拥有监控数据是观察系统工作状况的必要条件。
无论采集什么形式的监控数据，核心要点都是一样的：
采集数据的开销很小，但是如果在需要的时候没有数据，代价可就大了。所以有必要检测所有内容，并且合理地收集所有有用的数据。
指标
指标是在特定时间捕获的与系统相关的值 -- 比如当前登陆到Web应用程序的用户数量。因此，通常以固定时间间隔收集指标，比如每秒采集一次，每分钟采集一次。
我们把指标主要分成两类：工作指标和资源指标。对于软件依赖的每个系统，应该考虑哪些工作指标和资源指标是合理的，并且将其全部收集。
工作指标
工作指标通过系统的输出来获取系统的运行状况。在考虑采集工作指标时，通常可以将这些指标分成四类：
- 吞吐量：系统在单位时间内完成的工作量。吞吐量通常用绝对数值（非百分比这样的相对数）记录。
- 成功率：成功执行的工作占总工作量的百分比
- 错误率：产生错误结果的工作，通常表示为每单位时间内的错误率。可以用1减去成功率得到错误率，但是在实际操作中，错误率和成功率通常分开采集；尤其当存在多个潜在的错误来源，并且有些来源比其他其他来源更重要时，分开采集更是必要的。
- 性能：软件的工作效率。最常见的性能指标是延迟，延迟表示一个工作单元所需的时间。延迟可以表示为平均值或百分比，例如，“99%的请求在0.1秒内返回”。
上面讲的指标对于观察系统的运行状况非常重要。采集到了这些数据可以快速回答关于系统内部健康和性能最紧迫的问题：系统现在可用吗？系统现在性能如何？
以下是两种常见系统的所有四种子类型的工作指标示例。
Web服务器
| 子类型 | 描述 | 值 |
|---|---|---|
| 吞吐量 | 每秒请求数 | 312 |
| 成功率 | 两次测量间2xx的响应百分比 | 99.1 |
| 错误率 | 两次测量间5xx的响应百分比 | 0.1 |
| 性能 | 百分之90的请求的响应时间（秒） | 0.4 |
数据存储服务
| 子类型 | 描述 | 值 |
|---|---|---|
| 吞吐量 | 每秒查询次数 | 949 |
| 成功率 | 两次测量间成功执行的查询百分比 | 100 |
| 失败率 | 两次测量间成功执行的查询百分比 | 0 |
| 失败率 | 两次测量见返回过时数据的查询百分比 | 4.2 |
| 性能 | 百分之90的查询时间（秒） | 0.02 |
资源指标
软件基础架构的大多数组件都成为其他系统的资源。有一些资源是底层的，比如CPU，内存，磁盘和网络接口之类的物理组件。如果另外一些组件，比如数据库或者地理定位微服务也可以被看成是资源，因为其他的系统需要这些组件来完成工作。
资源指标有助于了解系统的详细状态，这在调查问题和诊断问题的时候是特别有价值的。资源指标可以分为四类：
- 利用率：资源繁忙时间的百分比，或者资源容量正在使用的百分比
- 饱和度：当前系统无法提供服务的请求的数量，通常会把这些请求存在队列中后续处理
- 错误：在工作过程中资源产生的内部错误
- 可用性：资源响应请求的时间百分比。仅对可以主动和定期检查的资源可以定义可用性
下面是几种常见的资源类型的指标示例
| 资源 | 利用率 | 饱和度 | 错误 | 可用性 |
|---|---|---|---|---|
| 磁盘 IO | 设备繁忙时间的百分比 | 等待队列长度 | 设备错误 | 可写的时间的百分比 |
| 内存 | 已使用的内存百分比 | swap使用率 | （通常观测不到） | 通常观测不到 |
| 微服务 | 每个请求服务线程忙的平均时间百分比 | 请求数量 | 服务抛出异常 | 服务可用时间的百分比 |
| 数据库 | 每个连接繁忙的平均时间百分比 | 排队中的查询 | 内部错误，比如复制错误 | 服务可访问的时间百分比 |
其他指标
还有一些指标，既不是工作指标，也不是资源指标，但这些指标同样有助于观察复杂的系统。比较常见的例子是缓存命中数或者数据库锁。
事件
除了可以连续收集的指标外，一些监控系统还可以捕获事件，这些事件往往是频繁的，离散的，但对整个系统的理解是有帮助的。比如：
- 变更：代码的发布，构建和构建失败
- 告警：内部或第三方的通知
- scale事件：增减或减少主机
事件通常带有足够的信息，可以单独解释，而不像单个数据点通常只有在上下文中才有意义。
事件会记录在特定时间点发生的事情，比如
| 时间 | 时间 | 附加信息 |
|---|---|---|
| Hotfix f464bfe发布到生产环境了 | 2015-05-15 04:13:25 UTC | 时间：1.2秒 |
| Pull request 1630被合并了 | 2015–05–19 14:22:20 UTC | commit：ea720d6 |
| 每夜数据汇总失败 | 2015–05–27 00:03:18 UTC | 失败任务的链接 |
事件有时候用来生成告警--通知负责人事情的发生，比如上面的第三个例子。不过这些事件更常用的用法是调查问题。一般来说，最好像指标一样考虑这样的事件--尽可能地收集它们。
收集正确的数据
需要收集的数据应该有四个特征：
- 好理解，并且能快速确定其含义和收集方式。尽量让指标和事件保持简单。
- 采集粒度。如果采集指标的周期过长，得到的数据可能无法正确衡量系统的状况。比如，对低使用率的时段和高使用率的时段进行平均，则这些时段的利用率就估计错了。因此采集的频率不能太低；当然也不能太高以至于降低系统的性能。
- 按范围标记。每个主机在多个范围内同时运行，可能需要检查这些范围或其组合的总体运行状况。比如：服务总体状况如何？美国东北地区的服务状况如何？某单个服务状况怎么样呢？保留与数据关联的多个范围非常重要，这样就可以对任何范围的问题发出告警，并快速调查中断，且不受主机层次结构的限制。
- 长时间存储。如果过早丢弃数据，或者在一段时间后汇总指标以降低存储成本，那么将会丢失有关过去发生事情的重要信息。保留一年或更长时间的原始数据可以更容易地了解“正常”是什么，特别是指标会随着月度，季度或年度变化的时候。
结论
- 尽可能多地收集工作指标，资源指标和事件。观测复杂系统需要全面指标
- 收集具有足够粒度的指标，以显示重要的峰值和下降。具体的粒度和监控的系统，采集的成本和指标变化之间的持续时间有关。不同的指标可能有不同的采集粒度，内存或CPU可以以秒为粒度统计，能耗可以用分钟为粒度统计。
- 要最大化数据的价值，需要标记具有多个范围的指标和事件，并将其保留至少15个月
