mysql - 标准偏差 (STDDEV) 是否适合这项工作？

Question

我们写了一个监控系统。这个监视器是由代理组成的。每个代理在不同的服务器上运行，并监控特定的服务器资源(RAM、CPU、SQL Server 状态、复制状态、可用磁盘空间、Internet 访问、特定业务指标等)。

代理将他们采取的每项措施报告给存储这些“观察结果”的中央数据库。

例如，代理每隔几秒就会在中央数据库中存储一个名为“unprocessed_files”的特定业务指标及其相应的值:

(unprocessed_files, 41)

该值不断写入我们的数据库(以及许多其他值，如上所述)。

我们现在正在实现一个客户端应用程序，一个屏幕，显示我们监控的每一件事的状态。那么，我们如何才能计算出什么是“正常”值，什么是错误值呢？

例如，我们知道如果我们的服务器正常工作，unprocessed_files 将始终接近于 0，但也许(我们还不知道)45 是一个可接受的值。

所以问题是，我们是否应该使用标准差来了解可接受的值范围是多少？

ACCEPTABLE_RANGE = AVG(值)+- STDDEV(值)？

当事情不顺利时，我们想用红色通知。

Answer 1

对于您的积压(未处理的文件)指标，使用标准偏差来了解何时发出警报(将某些东西变成红色)会让您因误报而发疯。

为什么？大多数时候，您的积压订单将为零。因此，标准偏差也将非常接近于零。标准偏差告诉您指标的变化程度。因此，无论何时你得到一个非零积压，它都会在 avg + stdev 之外。范围。

对于积压工作，您可能希望在值 > 1 时将内容变为黄色，在值 > 10 时将内容变为红色。

如果您有一个“花了多长时间”的指标，标准偏差可能是识别警报条件的有效方法。例如，您可能有一个通常需要大约半秒的 Web 请求，但通常在 0.25 到 0.8 秒之间变化。如果他们突然开始花 2.5 秒，那么您就知道出了问题。

S tandard deviation is a measurement that makes most sense for a normal distribution (bell curve distribution) .当您按照钟形曲线来处理您的测量值时，您就在隐含地假设每个测量值完全独立于其他测量值。该假设对于计算系统的典型指标(积压、交易时间、平均负载等)效果不佳。所以，使用 stdev 是可以的，但不是很好。您可能很难理解 stdev 数字:那是因为它们实际上没有多大意义。

如@duffymo 建议的那样，查看第 95 个百分位数(性能最差的操作)会更好。但是 MySQL 本身并不计算这些类型的分布。 postgreSQL does . Oracle Standard Edition and higher也是如此.

如何确定越界指标？这取决于指标，以及您要执行的操作。如果它是积压测量，并且它每分钟都在增长，那么您就有问题需要调查了。如果它是一个交易时间，并且它比平均时间长得多(例如 avg + 3 x stdev，那么您就有问题了。open source monitoring system Nagios 已经针对各种指标解决了这个问题。

阅读a book by N. N. Taleb called "The Black Swan"如果您想知道假设现实世界符合正态分布如何导致全局经济崩溃。