用于报警的监控系统不同于测量数据采集系统，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/).
