度量采集军备竞赛中搭救的采样方法

MarketsAndMarkets在去年的一份报告中，预测IT运营分析（ITOA）市场将从2015年的21.7亿美元增长到2020年的9.79亿美元，2015年至2020年的年复合增长率（CAGR）为35.2％。这再加上每GB硬盘的成本下降（如下图所示）和数据收集技术的成熟，似乎在度量收集方面产生了“军备竞赛”。

来源

下面的摘录反映了上述度量收集的军备竞赛：

• “......将其扩展到大约两百万个不同的时间序列。”（Netflix）
• “由于我们有数百个系统暴露多个数据项，写入速率可能很快超过每秒数千万个数据点。”（Facebook）
• “......我们正在进行数百亿次测量 ......”（谷歌）
• “......有超过一百万的度量不断流入 ......”（Etsy）
• “可观察性堆栈收集了1.7亿个单独的度量（时间序列）......”（Twitter）
• “......服务超过5000万个不同的时间系列。”（Spotify）

在Velocity Santa Clara '16和Monitorama '16 的回顾中，Mehdi Daoudi分享如下：

“IT监控的一个有趣趋势是出现了”规模竞赛“。人们因每秒能够收集数百万个度量，并监控PB级别大小的数据库而感到非常自豪“

当且仅当将度量标准用于随后的分析时，收集大量度量才可能是有必要的。现实情况是，在大多数情况下，收集到的度量超过95％从未被读取用来作任何分析！这对Opex有直接的影响——无论是对于数据中心的存储成本还是AWS的S3成本和维护成本。基于上述情况，回顾梅赫迪早些时候说过的话是合适的：

“我们需要停止对监测系统和数据库规模的比较，并开始讨论监控项目或工具部署如何节省时间，资金和业务投入，增加收入，扩大品牌影响，并帮助工程师和技术员更快更高效地工作，晚上睡得更好！“

度量标准的“浪费”不仅限于CPU利用率，延迟时间，新生代GC时间等传统度量标准。多数情况下，为了缩短TTR（解决问题的时间），可以使用派生的度量标准，例如设置99/95/90个百分点的延迟存储，而不是即时计算派生度量。对派生指标的选择通常是特定的。此外，大多数这些派生指标不是被用来读取后作任何分析。

其实，利用海量的运营数据进行数据中心的优化在早前就有过应用迹象。比如，Google在2004年发布了一份研究报告，称他们开发了一个神经网络框架，可从实际运行数据中学习，对工厂绩效进行建模，并预测PUE（电源使用效率），误差范围在0.004 + / 0.005（这意味平均绝对误差与标准偏差+ / - 1），对于PUE为1.1有0.4％的误差。

上述“浪费”指标对监测服务有直接影响。鉴于成本/节点的急剧衰减（可参考去年在Monitorama 2016上的Adrian Cockcroft说明），监测成本必须相应下降。但是，鉴于收集的度量数量的剧增，这很难实现。

来源

除了收集的大量度量之外，还需要关注度量收集的速度。对应于后者的频度例如从两天粒度跨越到每日粒度。以精细的粒度来进行度量收集已经开始流行。然而，很少有关于细粒度收集如何帮助缩短TTD（检测时间）和/或TTR（解决时间）的讨论。随着物联网的出现，数据流的数量将会大幅增长——按照ABI Research的预测，到2020年，物联网连接设备捕获的数据量将超过1.6 ZB。此外，为了存储或进一步分析而捕获的数据仅占正在生成的数据的一小部分，但也通常按照尧字节来排序，因此，确定收集速度的“最佳”水平应该是很重要的。

在实际用户监控（RUM）的情况下，网页每天可能拥有数百万的页面浏览量。监视每个页面视图的典型度量标准是TDNS，TConnect，TResponse时间，TOnload和#JS错误。下表列出了通常在页面视图中收集的其他度量的子集。表中的第二列对应于每个度量的对应数值的最大值（最大的值的当然是正在使用监测服务的函数）。

通常会监控多个度量标准，例如每个页面视图，以帮助定位可用性或性能问题。例如，在纽约的美国运通客户可能会遇到很高的响应时间，而在洛杉矶的美国运通客户可能会有非常流畅的体验。然而，在需要大量页面访问量的人口稠密地区，是否需要对每一个页面视图都收集度量呢？

为了解决上述问题，通常通过采样方法来满足存储需求。一个简单而有效的方法是根据度量的“重要性”来改变采样率。低采样率的定期采样降低了存储要求，并且在通常情况下，不会对根本原因的分析造成严重的影响。

我们观察下面的图，它对应于美国运通移动网页的网页响应时间，这些数据每五分钟收集一次。

粒度：5分钟。

从上面的图中我们注意到，在网页响应时间序列中有五个异常——这些都是超过七秒的网页响应时间。及早发现此类异常对于最大限度地减少对最终用户体验的影响至关重要。根据上面的讨论，如果数据每10分钟采样一次，时间序列是怎样的？从下面的图中，我们注意到，当采样率为10分钟时，在前面的图中观察到的五个异常中有两个被掩盖。

粒度：10分钟。

对于更低的采样率，时间序列会是怎样的呢？下面的图对应于30分钟的采样率。从下图中我们注意到，当采样率为30分钟时，第一个图中观察到的五个异常没有一个出现。

粒度：30分钟。

由于异常情况分布稀疏，因此低采样率会掩盖异常情况，因此上述情况也在意料之中。话虽如此，在高吞吐量系统的情况下，异常的稀疏性会大大减小，因此可以使用低采样率来处理数据集。事实上，采样方法已经用于大型系统，如Dapper。研究报告的作者说：

...我们发现采样是低开销中必需的，特别是在高度优化的Web服务中，这些服务往往对延迟敏感。

在Dapper中，同时采用了均匀和自适应采样率。具体而言，作者对采样率的应用分享了以下几点：

这个简单的方案对于我们的高吞吐量在线服务是有效果的，因为绝大多数值得注意的事件仍然很可能经常出现而足以被捕获。但是，流量较低的工作量时可能会因为低采样率而丢失重要事件，而接受更高的采样率伴随着高的性能开销。

同样，作者分享了以下有关使用自适应采样概率的内容：

...不是通过统一的采样率进行参数化，而是通过单位时间内所需的采样率曲线进行参数化。这样，流量较低的工作负载会自动提高采样率，而流量较大的工作负载会降低采样率，从而使开销得到控制。

将度量标准的采样率降低好像在对产生的数据流的新近性打折扣。探索新近性是使那些目前或最近一段时间会影响用户体验问题表面化的关键。为此，在Catchpoint，我们绝对不会对过去的三天进行抽样，或者为三天以前的数据采样。

总而言之，采样最大的利弊如下。

优点：

• 减少Opex与存储的联系。
• 帮助过滤掉噪声并捕捉潜在的趋势。
• 样本汇总要比总体汇总速度快——在如今的运营世界里存在大量度量时，这一点尤其重要——这有助于加快决策的制定。

缺点：

• 发生采样错误。由于样本不包括全部总体，样本统计中如方法和分位点通常与总体的特征不同。这可能会导致漏报，从而可能对用户体验产生负面影响。抽样误差可以通过从总体中抽取足够大的随机样本得到。样本统计的精度可以通过使用可用数据的子集来估计（这被称为jackknifing算法）或者用一组数据点的替换来随机抽样（这被称为bootstrapping算法）。
• 确定“最佳”采样技术和采样率是至关重要的。