本文为Datadog《[monitoring 101:collecting the right
data](https://www.datadoghq.com/blog/monitoring-101-collecting-
data/)》的中文翻译，有部分删减。原作者：Alexis Le-Quoc
本文是关于有效地监控系统的系列文章之一。敬请关注本系列的其它文章《有关的，才告警》和《调查性能问题》（译注：后续会翻译）。
监控的数据有多种形式—-
有些系统持续地输出数据而另一些是在罕见事件发生时产出数据。有些数据对于定位问题十分有用；而另一些则在调查问题时起主导地位。（译注：分别对应错误日志，性能日志）。本文涵盖了什么数据需要收集，以及如何对数据进行分类，读完后你就能：
- 对于潜在的问题接受有意义的，自动化的警告
- 进行快速调查并追查到性能问题的根源
不管你监控的数据形式如何，不变的主题是
收集的监控数据平时是没啥用，但是如果在你需要的时候你却没收集到，那监控数据就是宝贵且昂贵的，因此你需要尽可能地插手一切系统，收集你能收集到的一切的合理的数据。
监控（Metrics）
监控捕获的是系统在特定时间点上的有关数值—-举个例子，当前登入你web应用的用户总数。因此，监控常常设定在每秒、每分或其它常规间隔时间收集一次数据。
在我们的监控框架中有两个重要的分类：工况监控(work metrics)和资源监控(resource
metrics)。每一个系统都是你软件的基础设施，对工况和资源监控都是合理的需求，请把他们都收集起来。
工况指标
工况通过有意义的输出数据，揭示了系统的顶层健康状况。当你给工况指标分类时，将它们分成4小类会相当有帮助：
- 吞吐量(throughput) 是系统在单位时间内的工作量，常常用绝对值表示。
- 成功(success) 显示所有工作中成功的百分比。
- 失败(error) 捕获了失败的结果，常常是单位时间内的失败率或者是由吞吐量归一化（normalized）。失败的结果常常与成功的分别对待，因为它们是潜在的错误来源，可能是更严重的问题，而且处理起来也比成功的结果更加容易。
- 性能(performance) 监控着组件的工作效率高不高。最常见的性能指标就是完成所有操作需要的时间—-延迟时间（latency）。延迟时间常常用平均数或百分点(percentile)表示，例如：“99%的请求在0.1秒内完成”。
下面是web服务器和数据存储应用中常见的工况指标例子。
Example work metrics: Web server (at time 2015-04-24 08:13:01 UTC)
| Subtype | Description | Value |
|---|---|---|
| throughput | requests per second （每秒请求数） | 312 |
| success | percentage of responses that are 2xx since last measurement（距上次测量时2xx返回值的百分比） | 99.1 |
| error | percentage of responses that are 5xx since last measurement | 0.1 |
| performance | 90th percentile response time in seconds （90%的请求响应时间） | 0.4 |
Example work metrics: Data store (at time 2015-04-24 08:13:01 UTC)
| Subtype | Description | Value |
|---|---|---|
| throughput | queries per second | 949 |
| success | percentage of queries successfully executed since last measurement | 100 |
| error | percentage of queries yielding exceptions since last measurement | 0 |
| error | percentage of queries returning stale data since last measurement | 4.2 |
| performance | 90th percentile query time in seconds | 0.02 |
资源指标
对于其它系统来说，大部分的组件都是你软件基础设施都是它们的资源。有些资源是底层的—-
例如，一台服务器的资源包括的物理组件有CPU，内存，磁盘和网络接口。但是高层组件，如数据库或地理位置服务，也可以看成是其它系统正常工作所需的资源。
资源监控对于调查问题常常是非常有价值的。对于每个资源项，你应该尽力地收集4个关键领域：
- 使用率(utilization) 是资源忙/闲时的百分比或者是资源总量的使用率。
- 饱和量(saturation) 已经请求的、但是尚未处理的工作，通常是队列。
- 错误(errors) 表示的是系统运转过程中也许无法侦测到的内部错误。
- 可用率(availability) 表示请求返回总数中正常的百分比。这个指标仅仅在资源可被定期地检查才可以用。
下面是一个对于常见资源类型的资源监控：
| Resource | Utilization | Saturation | Errors | Availability |
|---|---|---|---|---|
| Disk IO | % time that device was busy | wait queue length | # device errors | % time writable |
| Memory | % of total memory capacity in use | swap usage | N/A (not usually observable) | N/A |
| Microservice | average % time each request-servicing thread was busy | #enqueued requests | # internal errors such as caught exceptions | % time service is reachable |
| Database | average % time each connection was busy | # enqueued queries | #internal errors, e.g. replication errors | % time database is reachable |
其它指标
还有一些指标既不是资源也不是工况，但是对于诊断问题根源很有用。常见的例子有缓存的命中率和数据库的锁数量。有疑问时，收集它们。
事件
对于指标的监控或多或少都是持续地进行的。有些监控系统还可以捕获事件：分离的，无规律的，对于了解什么改变了你系统的行为提供了关键的上下文。一些例子：
- 变更：内部代码发布，构建和构建失败
- 警告：应用内部产生的警告或者第三方通知
- 缩扩容： 添加或者减少服务器
一个事件常常携带了足以能解释自己的信息，不像其它数据指标，只能提供一个大概的环境。合理的事件包含了，发生了什么，在什么时候，附带信息。这里有些例子：
| What happened | Time | Additional information |
|---|---|---|
| Hotfix f464bfe released to production | 2015-05-15 04:13:25 UTC | Time elapsed: 1.2 seconds |
| Pull request 1630 merged | 2015-05-19 14:22:20 UTC | Commits: ea720d6 |
| Nightly data rollup failed | 2015-05-27 00:03:18 UTC | Link to logs of failed job |
事件有时用来生成警告—-像上表中第三行，有人应该收到通知，关键的任务失败了。但更通常的情况下，事件用来调查跨系统的问题。总之，把事件当指标—-
它们有价值，能收集的尽量收集。
好的监控数据长啥样
得有四个特性：
- 易懂 你应当能快速地由数据像分析出指标或者捕获的事件。在系统不可用的时候，你估计已经不想猜测你的数据意味着什么了，所以尽量简单明了地保存这些数据，用刚才的概念来命名你的数据。
- 粒度合适 （granular）如果你设置过长或者过短的收集窗口事件，你很有可能失去关于系统行为的重要数据。例如，平时使用量比较低的系统，在资源100%使用的时候会让你费解。以对系统没有巨大影响的情况下收集数据，否则监控系统就成了"税务"负担（详见observer effect）或者由于过短的收集间隔给数据带来噪音。
- 按域打标签 （Tagged by scope）每一台你的服务器都是同时属于某个特定域的，你很有可能需要按域查检服务的健康情况，或者是综合起来。例如：生产环境现在的健康状况如何？北美的生产环境呢？特定的软硬件组合的情况下呢？保存数据所属的域是重要的，因为你可能会从任意域收到警告，并能按域快速展开服务不可用的调查，而不仅仅限制于特定机器。
- 长时间保存。如果你过早地丢弃的，或者为了节省存储费用丢弃了数据，那么你就失去了关于过去的重要信息。保存一年以内的数据，你能知道系统正常情况下是什么样子的，特别是监控数据有每月、每季度、年度的波动时。
为了告警和诊断的数据
下面有张关于不同等级警告的描述和它们的紧急程度。简单来说，低等级的告警时不需要通知任何人的，只需要记录在案以便不时之需。一个通知（notification）等级的警告算是中等级的，可以通过不打断人工作的方式通知，例如邮件或者聊天室。一个Page（译注：寻呼机）等级的告警是十分紧急的，需要立即有人工参与，不管维护的人是在睡觉还是享受个人时光。
| Data | Alert | Trigger |
|---|---|---|
| Work metric: Throughput | Page | value is much higher or lower than usual, or there is an anomalous rate of change |
| Work metric: Success | Page | the percentage of work that is successfully processed drops below a threshold |
| Work metric: Errors | Page | the error rate exceeds a threshold |
| Work metric: Performance | Page | work takes too long to complete (e.g.,performance violates internal SLA) |
| Resource metric: Utilization | Notification | approaching critical resource limit (e.g., free disk space drops below a threshold) |
| Resource metric: Saturation | Record | number of waiting processes exceeds a threshold |
| Resource metric: Errors | Record | number of errors during a fixed period exceeds a threshold |
| Resource metric: Availability | Record | the resource is unavailable for a percentage of time that exceeds a threshold |
| Event: Work-related | Page | critical work that should have been completed is reported as incomplete or failed |
总结：全收了
- 尽可能多地收集数据，包括工况、资源和各种事件。
- 以合适的粒度收集数据，以便发现波峰或者波谷。这个粒度取决于你要监控的系统，时常变化的数据—-CPU，内存，能量消耗都是典型的要收集的。
- 让你的数据发挥最大化的价值，包括标签，事件，完整地保留至少一年