未來監控系統發展方向：互操作架構
來自Github的Jason Dixon在羅馬召開的DevOps Days上，發表了關於「當前及未來監控系統發展」的演講。他認為，未來監控系統應當由可替換組件構成，每個組件應當只專註於一種功能。
按照Jason的設想，這樣的系統架構有以下特點：
[*]模塊組合 （明確定義各組件功能、介面以及協議）
[*]富有彈性 （監控系統在架構層面能夠應對中斷的發生）
[*]完全自助 （不需要運維人員的干預，用戶可以自助進行操作）
[*]自動化 （提供自動化功能）
[*]智能關聯 （自動建立服務間的關聯關係）
[*]界面友好（用戶樂於使用這個系統）
這樣一套系統中，各組件通訊方式如下圖所示：
http://pub.chinaunix.net//uploadfile/2012/1101/20121101091640990.png
[*]感測模塊：由無狀態代理組成，負責收集指標數據，並以日誌流格式通過 HTTP、 JSON或直連的方式上傳。
[*]匯聚模塊：負責進行數據轉換、處理、匯總，或者進行指標數據的中轉。
[*]狀態引擎：負責跟蹤事件流的變化，能夠自動根據相關信息分析問題根源並進行預測。
[*]存儲引擎：支持對數據進行轉換和聚合，並能夠接近實時的性能進行查詢或以JSON、XML或SVG等標準格式輸出。
[*]計劃任務模塊：提供計劃任務的管理介面對任務進行管理，並提供擴展介面。
[*]通知模塊:負責根據狀態引擎提供的數據發送報警消息，並對狀態進行跟蹤以用於其他目的。
[*]可視化模塊：通過儀錶板以及其他的用戶介面用於展示各種指標和警報信息。
Jason 強調，為實現細粒度指標的收集，必須進行數據收集規劃和必要的架構調整。這樣就使得系統通過對歷史數據的分析來預測未來變化趨勢以及閾值違例成為可能。
InfoQ談到Jason最近在這個領域的項目，他介紹到：在可視化方面，我在一些如Tasseo、Descartes等這樣的工具上進行研究，以提升在中斷時運維人員的響應能力。最近，我們實現了對各類指標進行實時的關聯分析功能，我認為這是相當重要的。但是，我們發現引起中斷的問題往往是由連鎖故障造成，導致他們無法在一張圖像上展示出來。
另外，我所看好的Graphite項目，但是它缺少對指標命名空間的訪問控制。我計劃在Backstop這個項目中加入令牌訪問驗證。這樣監控系統的管理員可以授權特定程序或開發人員訪問指定的指標命名空間。
本演講以及其它在羅馬DevOps Days上發表的演講，請在這裡觀看。
查看英文原文：The Future of Monitoring: an Interoperable Architecture感謝崔康對本文的審校。來源：InfoQ
本文來自ChinaUnix新聞頻道，如果查看原文請點：http://news.chinaunix.net/opensource/2012/1101/2466241.shtml
《解決方案》
層次太高了，我只能在nagios裡面增加點校本什麼的。
《解決方案》
其實，Nagios這樣的軟體已經將很多部分集成到一起了，既是優點也是缺點
《解決方案》
這個是智能運維吧
