我们的第一个问题是“有问题吗”。如前所述，这种监控指标并不多，大约三到七种，它们既能提供预测性的指标，又能提供当前的指标，用于说明即将有问题或现在已经有问题了。由于我们要跟踪的项目数量较少，所以数据保留应该不是个大问题。最好能每分钟或每小时绘制一次这种数据，并至少与前两周中相似时间内的数据进行对比。如果今天是周二，那么我们可能需要前两个周二的有价值的数据。也许我们只需保留前两周的数据即可，但在我们汇总数据之前，也可以把范围扩展到保留一个月的数据。从长远来看，这些数据不会占用大量空间。此外，在预测与确定是否要发生问题或已经发生了问题方面，这些数据会给我们节省很多时间。
接下来我们要问的问题是“哪里有问题”。我们的金字塔表明，尽管问题的具体程度在缩小，但数据量却在增长。这应该弓起我们的注意，因为我们要实现这一点，就需要更多的监控指标。这种监控指标的数量可能在10到100之间，远远多于我们原始的监控指标。在非常大型的复杂的分布式系统中，监控指标的数量可能更多。我们仍然需要与以前相似日期中的数据进行比较，理想状况是分层对比。但在我们的汇总和归档/删除策略中，我们需要激进得多。理想的做法是，我们首先按照小时汇总数据，然后把数据纳人均线的计算。也许我们会绘制和保留图形，而随着时间逐渐删除原始数据。我们当然不想无限制地保存原始数据，因为它们中的大多数再被用到的可能性很低，因而价值很低，成本却很高。
最后，我们要问的是“什么问题”。我们所需的网站建设监控指标数比上一个监控方案又至少提高了一个数量级。我们会加上原始输出日志、错误日志以及其他数据。这类数据增加得很快，尤其是在一个对话多的环境中。我们可能希望保留两周的数据，这里假设了从两周的数据中能抓住大部分问题。也许对于保留什么和删除什么你有更好的信息，但我们要强调的是，你不能要求随时随地都可以检查任何指标，这会有损股东价值，因为这种要求几乎需要无穷多的花费，而得到的回报却非常非常低。
本文地址：//cosda.cn//article/3907.html
