监控Server，哪些关键KPI？

Question

实际上，我构建了一些“自定义”监控工具来跟踪DMV表中的信息，并将它们存储在某种DataWarehouse中，我每隔5分钟就拍摄一次快照。

我正在检索的数据是：

数据库：

• 文件延迟(ldf和mdf)
• 文件大小和使用
• 交易记录
• 原木生长和冲刷
• 数据库CPU
• 数据库缓冲区MB

服务器：

• SQL CPU /空闲进程/其他进程
• RAM (目标/使用)
• 页预期寿命
• 缓存命中率
• 用户连接/数据库连接

LOCKWAITS:

• 一般锁/死锁/等待信息(网络.Io Latch.)

查询：

在这部分，我有点迷茫..。我希望能够在我的服务器上检测出有问题的查询，因此我需要存储历史信息，因为一些DMV上的信息是累积的，所以如果我想要一些平均值，比如execution_count，我需要对它们进行快照。我不知道一个查询应该达到什么关键的KPIS和阈值才被认为是一个有问题的查询.

此外，我不知道是否应该监控更多的KPI，以检测CPU压力/ RAM压力/磁盘压力。

任何对改进它的帮助都将不胜感激！

Answer 1

如果你不知道，那么你还没有准备好写一个这样的工具。为了回应其他人的评论，这就是为什么人们买一个工具比我们做得更好，而且价格对于极小的几个服务器商店来说是非常合理的。

唯一为自己编写像样工具的人是高技能的专业人士，他们有时在大型商店工作，无法让管理层承担6位数的监控成本。

如果您想要监视查询性能，您需要阅读查询指纹，并通过一些格兰特弗里奇的书籍充分阅读如何缓存计划。这是困难的，甚至他也会犯错，这是MCM的水平。

在那之后，你会明白一点，但即使是付费工具也不会指出什么时候出了问题。他们指出的是顶级查询(在CPU、磁盘、内存中)或奇怪的内存授权或缺少索引。你可以从互联网上轻松地做和存储这些，但它们不是可报警的阈值。他们从来都不是。

就您自己而言，您可能还能够根据指纹和执行细节来确定过于不同的计划重新编译--但这很可能不值得，否则商业工具就会这么做。可能太吵了。

还有一本书叫做“健康SQL”( Healthy )，它涵盖了许多想法和阈值，但它变得模糊起来。

另一个很好的地方是下载性能分析日志工具(PAL)，它有一个SQL计数器列表(以及磁盘IO计数器和类似的东西)，并且在XML中定义了精确计算阈值的方法和原因。这些总体上是有用的，但我不确定我是否会提醒他们，除非作为每日报告。

我认为，一些公司还发布了一份半营销白皮书，阐述了为什么阈值毫无意义，而你真正需要的是基线(并对标准差进行统计分析，但我很确定他们自己并不会这么做)。但是，IMHO没有人共享易于理解的方法来分析和标记快照之间不同的原始基线数据。R看起来是个很有前途的地方，但没有“如何做”。