用于报警的测量监控系统不同于测量数据采集系统，Nagios就是数据一个常常和测量数据采集系统配合使用的监控报警工具。

测量数据采集系统专注于数据采集的加入机制谷歌优化师好处，是测量有能力发现那些相关点(Integrationpoints)，对这些点的数据异常值进行报警。Flickr使用Ganglial作为测量数据采集系统，加入机制Nagios作为监控及报警系统。测量在某些情况下，数据将两者紧密结合起来，加入机制以建立复杂的测量报警条件。使Nagios.感知 Ganglia采集的数据数据，就可以具有更为高级的加入机制监控手段，这样，测量谷歌优化师不仅单点达到阈值(threshold)时会产生异常，数据在满足多值亚阈值模式(multiple-value subthresholdpattem)的加入机制情况下，也会产生异常。



例如，假设一个运行 Apache的Web服务器集群，这些Web服务器访问运行MYSQL或Poster的后端数据库，获取信息生成页面。一个经常发生的情况是数据库查询运行时间太长，且原因不明，这样，由于连接不能尽快关闭，数据库总的活动连接数就会增加。结果是，在这些连接上等待的 Apache进程也会增加。由于Web服务器和数据库的进程数都有最大值的限制，所以要分别设置Web服务器和数据库的警告(warning)和紧急(critical)阈值，将阈值分别设置为最大值的某个合适的百分比。

对Web服务器和数据库集群中的每个节点的每个值(Apache的忙碌进程和数据库的打开连接)有异常都要报警吗?假如这种异常只发生在一台数据库(或一个数据库集群)，或一部分Web服务器上，会怎么样呢? Flickr的做法是将Ganglia采集的各种数据集成到Nagios，我们就能够做灵活的报警设置，即忙碌的Web服务器(指忙碌的 Apache进程数达到紧急阈值的Web服务器)的数量达到一定百分比时，才报警，也仅在忙碌的数据库服务器(指忙碌的连接数达到紧急國值的数据库服务器)的数量达到一定百分比时，才报警。

能够处理这些甚至更复杂的系统与数据的耦合，意味着降低了报警的噪声，只在发生众所周知而又复杂的情况时，呼机才会在半夜三更响起来。

另一个例子是对值的飙升进行报警，报警系统不像采集系统那样记录了历史数据的细节。例如，如果应用程序提供了照片或视频上载的功能，使用模式也相对正常(如每日的波峰和波谷)，而且对高低线上的变化能够报警，在美国东海岸进入梦乡时，你可能会料想到照片上载量会下降，日峰和日谷之间的变化可能会达到40%。但你会想到一小时之内上载量会下降409%吗?不是下降到0，而是短时间之内的剧烈下降!这种情况就值得报警。

这种将网站建设监控系统和采集系统集成起来的做法很常见，这方面有大量的开放源代码项目和文档 ：

集成Nagios (http://www.monitoringexchangeorg/inventory/check-plugins Software/Misc/check ganglia) 

Nagios和 Cacti(http://trac2.assemblacom/npc/) 

Nagios和munin (ht://munin-monitoring.org/wiki/Howtocontactnagios

开放源代码GroundWork(集成Nagios、Ganglia、Cacti，http//www.groundwork-pensource.com/community/open-source/).

本文地址：https://www.hy755.cn//article/3312.htmlhttp://cwhd.osvso.com/html/46c699950.html