我们写了一个监控系统。此监视器由代理程序组成。每个代理程序在不同的服务器上运行，并监视特定的服务器资源（RAM，CPU，SQL Server状态，复制状态，可用磁盘空间，Internet访问，特定业务指标等）。
代理商会将他们采取的所有措施报告给存储这些“观察结果”的中央数据库。
例如，代理每隔几秒就会在中央数据库中存储一个名为“unprocessed_files”的特定业务度量标准及其对应的值：
(unprocessed_files, 41)
这个值是不变的写入我们的数据库（在许多其他人中，如上所述）。
我们现在正在实现一个客户端应用程序，一个屏幕，显示我们监控的每件事情的状态。那么，我们如何计算出什么是“正常”值以及什么是错误值呢？
例如，我们知道如果我们的服务器工作正常，unprocessed_files总是接近0，但也许（我们还不知道），45是可接受的值。
所以问题是，我们是否应该使用标准偏差来了解可接受的值范围是什么？
ACCEPTABLE_RANGE = AVG（值）+ - STDDEV（值）？
当事情进展不顺利时，我们想用红色通知。
答案 0 :(得分：2)
对于您的积压（未处理的文件）指标，使用标准偏差来了解何时发出警报（将某些内容变为红色）会让您发出错误警报。
为什么呢？大部分时间你的积压工作都是零。因此，标准偏差也将非常接近于零。标准偏差会告诉您指标的变化程度。因此，每当您收到非零积压时，它将超出avg + stdev范围。
对于积压，您可能希望在值为＆gt;时将内容变为黄色当值> 1时，红色为1; 10.
如果您有“需要多长时间”指标，标准差可能是识别警报条件的有效方法。例如，您可能有一个Web请求通常需要大约半秒钟，但通常在0.25到0.8秒之间变化。如果他们突然开始花2.5秒，那么你就知道出了什么问题。
取值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"。
答案 1 :(得分：1)
标准偏差只是表征一组值与平均值（即平均值）之间的差异的一种方式。从某种意义上说，它与平均值有平均偏差，虽然比这更复杂一点。确实，与平均值相差多次标准差的值往往很少见，但这并不意味着标准偏差是识别可能表明出现问题的异常值的良好基准。
首先，如果您将可接受的范围设置为平均值加上或减去一个标准偏差，那么您可能会在该范围之外获得非常频繁的结果！您可以使用平均值加上或减去两个标准偏差，或者三个，或者您希望将多少通知/错误条件减少到您想要的范围，但是没有说明这些是否真的可以帮助您识别错误情况。
我认为你的主要问题不是统计数据。您的问题是您不知道哪种结果实际上表明存在错误。因此，在您在任何可接受的范围内进行编程之前，只需让系统运行一段时间并收集一些校准数据，以显示当它正常运行时您看到的值，以及您在看到它时看到的值的类型。没有正常运行。确保你有办法告诉哪些是哪个。一旦你有两个条件的大量数据，你就可以分析它（从一个简单的直方图开始），看看哪种值是正常操作的特征，以及错误条件的特征是什么类型。然后你可以根据它设置你可接受的范围。
如果你想获得幻想，有一种称为likelihood ratio testing的统计技术可以帮助你评估你的系统正常工作的可能性。但我认为这可能是矫枉过正的。监控系统不需要对这些东西非常精确;只要读数开始看起来异常，就会显示警告通知。