1.5　沉默是金

对于任何监控系统而言，监控项目必须保持一个合适的粒度，不能太多也不能太少。技术分支中，如系统管理员，常常获得太多的错误通知。比如5台主机上的20个服务，多数系统管理员会监控所有的内容并获得所有的通知，无论这些通知信息是否表示系统存在问题。

对于系统管理员来说，这不算什么，他们应该尽可能开发一个有机体以便深入了解他们的环境，而通知只是一种可见性的信息，或者作为事件相关的援助信息。比如，从工作站1发出网络流量过高的通知，同时包含了路由器12的CPU高峰值、服务器3的磁盘利用率异常，系统管理员可能因此认为会计Ted提前结束休假返回公司了。而勤奋的系统管理员可能会对这个波峰情况探究到底，以确认是Ted真回来了，而不是某个为了出名的年轻骇客（cracker）占用了Ted的工作站。然而，而对于非系统管理员来说，很可能把这些通知当做“误报”（false alarm）。

通常，监控系统使用静态阈值来判断服务的状态。比如说服务器1的CPU利用率阈值可能设置为95%，当CPU利用率超过阈值时，监控系统将会发送通知或执行一些自动化的中止/修复操作。但当部署监控系统到某个环境中时，实施人员会犯的最大错误之一就是没有花时间研究服务器上的正常操作参数是什么。比如因为服务器1在12:00～14:00之间执行批处理，所以其CPU利用率值在此时段内通常为98%，那么就会产生误报。

对于误报，应当有计划地发现并根除。对于羽翼未丰的监控系统而言，让大家收到无用的误报很可能削弱其可信度，没有什么比这更糟了，甚至会减弱对其支持。在监控系统配置通知发送功能前，应当进行为期几周的试运行，至少完成对关键系统的数据收集，来决定这些系统正常操作的参数是什么。这些数据都可以归类为基线数据（baseline），这是确定服务器静态阈值的唯一合理且负责的方式。

这并不是说系统管理员们在收到告警的时候不用去查看系统的状态，他们应当收到告警时及时地关注这些信息。我只是建议能够将一些过滤器落实到位，以确保没人会遭到监控系统的骚扰。本章前面所介绍的过程方法中，有一件很棒的事情就是：在配置阈值和联系人之前，能够考虑组织需求，比如某个特定主机上的特殊服务。如果DBA Alice不需要理会服务器1上CPU利用率过高的问题，那么就无须将此事件发送给他。

在不使用告警管理或非官方插件的情况下，Nagios提供了大量的功能使系统管理员只在“关注事件”发生时才会收到通知。它内置两个阈值级别（警告和严重）以及一系列的升级、分组及轮询选项，相对简单地就可以设置“时间和频率”样式的通知以满足某些怪咖们的需要，而保持其他人“及时跟进问题”。这种分层通知方式是系统早先的设计目标，也是被高度推荐的。

优秀的监控系统是专注的而非泛泛的。它们可能监控了许多服务以满足历史趋势数据分析的目的，但却很少发送通知，而且只发送给想知道的那群人。而对于某些求知欲望很强的人而言，为了避免他们全天关机，只能每天定时给他们发送汇总或者摘要。Nagios内置的报告功能非常不错，使用它可以很容易获取历史可用性信息并将报表发送给预定义的人群。