该帖子是有效监视系列文章的一部分。一定要检查本系列的其余部分：提醒重要事项和调查性能问题。
监视数据的形式多种多样-有些系统会不断地倒出数据，而有些系统只会在发生罕见事件时才产生数据。一些数据对于识别问题最有用；有些对调查问题最有价值。更广泛地讲，拥有监视数据是可观察到系统内部工作的必要条件。
这篇文章介绍了要收集哪些数据，以及如何对这些数据进行分类，以便您可以：
- 收到有意义的自动化警报，以解决潜在问题
- 快速调查并深入了解性能问题
无论您的监视数据采用什么形式，统一的主题都是：
收集数据很便宜，但是在需要时没有它会很昂贵，因此您应该检测所有内容，并合理地收集所有有用数据。
本系列文章来自我们为客户监控大型基础架构的经验。它还借鉴了Brendan Gregg，Rob Ewaschuk和Schwartz男爵的作品。
指标
指标捕获在特定时间点与您的系统有关的值，例如，当前登录到Web应用程序的用户数。因此，通常每秒一次，每分钟一次或每隔一个规则的时间间隔收集一次指标，以随时间监视系统。
我们的框架中有两个重要的指标类别：工作指标和资源指标。对于属于您软件基础架构的每个系统，请考虑哪些工作指标和资源指标是合理可用的，并将它们全部收集。
工作指标
工作指标通过衡量有用的输出来指示系统的顶级运行状况。在考虑工作指标时，将它们分为四个子类型通常会很有帮助：
- 吞吐量是系统每单位时间要做的工作量。吞吐量通常记录为绝对数字。
- 成功指标表示成功执行的工作的百分比。
- 错误度量标准捕获错误结果的数量，通常表示为每单位时间的错误率，或者通过吞吐量进行归一化以产生每单位工作的错误。当存在多个潜在错误源时，错误度量通常与成功度量分开捕获，其中某些错误源比其他错误源更严重或更具可操作性。
- 性能指标量化了组件执行工作的效率。最常见的性能指标是等待时间，它表示完成一个工作单元所需的时间。延迟可以表示为平均值或百分数，例如“ 99％的请求在0.1秒内返回”。
这些指标对于可观察性非常重要。它们是一项大范围的措施，可以帮助您快速回答有关系统内部运行状况和性能的最紧迫的问题：系统是否可用并且正在积极地进行构建？生产工作有多快？这项工作的质量如何？
以下是两种常见系统的所有四个子类型的示例工作指标：Web服务器和数据存储。
工作指标示例：Web服务器（UTC时间2015-04-24 08:13:01）
| Subtype | Description | Value |
|---|---|---|
| throughput | requests per second | 312 |
| success | percentage of responses that are 2xx since last measurement | 99.1 |
| error | percentage of responses that are 5xx since last measurement | 0.1 |
| performance | 90th percentile response time in seconds | 0.4 |
工作指标示例：数据存储（UTC时间2015-04-24 08:13:01）
| 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，内存，磁盘和网络接口之类的物理组件。但是，如果另一个系统需要该组件来产生工作，则更高级别的组件（例如数据库或地理位置微服务）也可以视为资源。
资源度量标准可以帮助您重建系统状态的详细信息，从而使其对于调查和诊断问题特别有价值。对于系统中的每个资源，请尝试收集涵盖四个关键领域的指标：
- 利用率是资源繁忙的时间百分比，或正在使用的资源容量的百分比。
- 饱和度是对资源尚无法服务（通常是排队）的请求工作量的度量。
- 错误表示在资源产生的工作中可能无法观察到的内部错误。
- 可用性表示资源响应请求的时间百分比。该指标仅针对可以主动定期检查可用性的资源进行了明确定义。
以下是一些常见资源类型的示例指标：
| 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 |
事件有时被用于生成警报-应当通知某人有关事件的信息，例如上表中的第三个示例，这表明关键工作已失败。但是更多时候，它们被用来调查问题并跨系统关联。通常，请考虑诸如指标之类的事件，它们是在可行的地方都可以收集的有价值的数据。
好的数据看起来像什么
您收集的数据应具有四个特征：
- 非常明白。您应该能够快速确定如何捕获每个指标或事件及其代表的内容。在中断期间，您将不需要花费时间来弄清楚数据的含义。保持度量标准和事件尽可能简单，使用上述标准概念，并明确命名它们。
- 粒状。如果您不经常收集指标或在很长一段时间内收集平均值，则可能会失去准确重建系统行为的能力。例如，如果将平均利用率与较低利用率时段进行平均，则会模糊100％资源利用率周期。以不会掩盖问题的频率收集每个系统的指标，而不必经常收集监视以致对系统造成负担（观察者效应），或者通过采样时间间隔太短而无法包含有意义的数据而在监视数据中产生噪声。
- 由范围标记。每个主机都在多个作用域中同时运行，您可能需要检查这些作用域或其组合的总体运行状况。例如：生产总体如何？美国东北部的生产情况如何？特定角色或服务如何？保留与数据关联的多个作用域非常重要，这样您就可以警告任何作用域中的问题，并迅速调查中断，而不受固定主机层次结构的限制。
- 长寿的。如果丢弃数据的时间过早，或者监视系统在一段时间后汇总了指标以降低存储成本，那么您将丢失有关过去发生的情况的重要信息。将原始数据保留一年或一年以上，可以更轻松地知道“正常”是什么，尤其是在您的指标具有每月，季节性或年度变化的情况下。
警报和诊断数据
下表将本文中描述的不同数据类型映射到随行帖子中概述的不同级别的紧急警报。简而言之，记录是一种低紧急度的警报，它不会自动通知任何人，但是会记录在监视系统中，以防它对以后的分析或调查有用。一个通知是一个中等的紧迫性警报，通知谁可以在非人工方式解决这个问题，如电子邮件或聊天。一个页面是中断收件人的工作，睡眠，或个人时间，不管小时的紧急警报。请注意，根据严重程度，通知可能比页面更合适，反之亦然：
| 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度量标准为秒，能耗为数分钟，等等。
- 为了最大程度地发挥数据的价值，请在多个范围内标记指标和事件，并以完全粒度保留它们至少15个月。
当您将此框架应用于自己的监视实践时，我们想听听您的经验。如果运作良好，请在Twitter上通知我们！有问题，更正，补充，投诉等吗？请在GitHub上告诉我们。
来源：51CTO
作者：randy_shandong
链接：https://blog.51cto.com/dba10g/2473042