目前，我们的监控团队使用一个 KPI - 比客户先发现的事件百分比。虽然这个 KPI 可以很好地反映监控系统的核心性能，但我认为我们必须将其扩展到其他方面，例如误报数量或监控系统的主动性。
有人可以分享他的经验吗——您使用哪些 KPI 来衡量您的监控系统性能？（以及您如何收集这些数据）。
答案1
在我部署的系统中，KPI 通常与业务目标相关，例如：
- 处理的交易数量
- 系统中的总资源量（例如 SAN 的 TB 数、机器数量）
- 应用程序正常运行时间
- 申请响应时间
- 呼叫中心的平均呼叫等待时间
我在这方面取得的最大成功是与高管开会，我们就如何将他们的业务目标转化为 KPI 达成一致，而不是先由运营部门提出。确保 KPI 既涵盖业务目标，也涵盖员工实现这些目标的效率。为此，跟踪以下事项也是不错的选择：
- 内部问题单/错误的平均解决时间
- 服务离线的平均时间/“宕机”的资源量
- 紧急事件值班响应时间
- NOC/值班人员响应的事件数量（可能与实际需要的工作数量相对）
对于报告，我发现最好是完全自动化显示/报告这些内容。我使用了一个脚本，将 rrds/db 查询（特定服务）聚合为单个 rrd，我们可以在“仪表板”中将其显示给 NOC/高管。高管们喜欢图表，而随时间变化的 KPI 可以帮助他们了解事情的执行情况。我以前使用过 rrdtool/drraw 来构建仪表板。最近我开始使用 OpenNMS 进行 SLA 报告，它有一些很棒的功能，使它们易于创建和高管使用。在某些环境中，我还发现从两个来源生成此类报告很有用，例如使用 Gomez 或 Keynote 报告。这有助于保持人们的诚实，并增加人们对报告的尊重程度。
您提到了错误警报，这对于 KPI 来说是一个有趣的观点。在我合作过的大多数团队中，错误警报要么是由于监控设计/实施不当，要么是由于监控显示人们认为“低于”实际问题阈值”的故障。我很好奇您看到的是哪种错误警报，以及为什么允许它们在系统中持续存在（如果它们是测试失败，那么用户是否看不到它们，随后应在监控系统中设置为重试，等等）？
答案2
我认为将网站性能数据“仅仅”用于触发警报是一种浪费。我们将性能数据（使用实际浏览器应用程序监控测量）与购物车放弃率和其他网站统计数据相匹配——目标是优化我们的整体用户体验。这里的 KPI 显然是我们网站的整体转化率当然棘手的是，网站性能只是影响因素之一。