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