sql sentry需手动配置windows性能计数器processor(_total)\% processor time告警，推荐15秒采样、动态基线2.5标准差，并注意实例名与通知扩展。
SQL Sentry 里怎么设置 CPU 使用率超阈值实时告警
SQL Sentry 默认不自动触发 CPU 异常告警，必须手动绑定性能计数器 + 配置告警策略。它监控的是 Windows 性能计数器 Processor(_Total)\% Processor Time，不是 SQL Server 内部的 sys.dm_os_ring_buffers 数据。
- 在
Alerts → New Alert → Performance Counter Alert中选择该计数器，采样间隔建议设为15秒（太短易误报，太长漏告） - 阈值别直接填
80——基线波动大时，固定值会频繁抖动；改用「动态基线」：勾选Use baseline deviation，设为2.5标准差（比默认2.0更稳） - 注意计数器实例名：虚拟机或 NUMA 节点多时，
_Total可能掩盖局部过载，必要时要单独配Processor(0)、Processor(1)等实例 - 告警触发后，SQL Sentry 默认只发邮件；若需企业微信/钉钉，得走
Alert Action → Execute Program调外部脚本，别指望内置集成
SolarWinds DPA 的 SQL Server 基线是怎么算出来的
DPA 的「基线」不是简单取 7 天平均值，而是基于历史负载模式自动聚类：按小时、工作日/周末、是否节假日分段建模，再对每段拟合趋势+周期项。这意味着周一早 9 点的基线，和周五晚 9 点的基线，完全独立。
- 基线更新频率默认是
24小时一次，但只有当新数据与当前模型残差持续超3σ达 3 次，才会触发重训练——所以突发流量不会立刻拉高基线，这是优点也是坑点 -
Baseline Deviation告警里的2.0并非标准差倍数，而是 DPA 自定义的「偏离强度」，实际对应约1.8–2.2σ，不同版本有浮动，不能直接套统计学理解 - 如果数据库刚上线不到
14天，DPA 会用「冷启动基线」：取前 3 天最高值 ×0.7作为初始参考，此时告警极容易误触发
两个工具都报「内存压力」但指标对不上怎么办
SQL Sentry 看的是 Windows 层 Memory\Available MBytes，DPA 看的是 SQL Server 层 SQLServer:Memory Manager\Total Server Memory (KB) 和 Page Life Expectancy 的加权组合。两者根本不在同一抽象层级，硬对比等于拿油表读数比发动机转速。
- 当
Available MBytes1024 且Total Server Memory接近 max server memory 配置时，才是真内存争用；单看一个指标就开火，90% 是虚警 - DPA 的
Memory Pressure评分含内部权重，你无法调整。但 SQL Sentry 的Memory\Pages/sec>20持续 5 分钟，比 DPA 的评分更早暴露换页风暴 - 若两者结论冲突，优先信
sys.dm_os_memory_clerks里single_pages_kb + multi_pages_kb的实时增长趋势，工具只是代理，不是真相
告警太多刷屏，怎么快速过滤掉维护窗口的噪音
SQL Sentry 支持按「Maintenance Window」静音，DPA 需靠「Scheduled Maintenance」，但二者逻辑不同：前者是时间范围屏蔽，后者是对象+时间双重匹配，漏配一个数据库就照常告警。
- SQL Sentry 的维护窗口必须提前在
Configuration → Maintenance Windows里创建，且告警规则要显式勾选Suppress during maintenance windows——不勾没用 - DPA 的维护计划必须关联到具体实例（不是实例组），且起止时间得精确到分钟；它不识别 SQL Agent 维护作业的运行时间，别想自动同步
- 最稳妥的做法：在维护开始前，用 SQL Sentry 的
Alert SuppressionAPI 或 DPA 的/api/v1/maintenance接口发一次性静音，比界面点更可靠
基线不是贴在墙上的参考线，它是活的模型，会随你删库、加索引、切版本悄悄偏移。最常被忽略的，是告警响应时没顺手查下基线本身的稳定性——比如 DPA 的基线健康度低于 60%，那所有偏离告警都该打个问号。
