測量數據采集系統專注于數據采集的好處，是有能力發現那些相關點(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/).
本文地址：http://m.knowyourextract.com//article/3312.html
