我這篇文章[http://blog.csdn.net/u014654002/article/details/54345381]裏寫過的kairosdb，那是我開始接觸監控系統的第一步，它幫助我了解了時序數據庫在監控端的優秀表現。
kairosdb算是相當優秀的監控系統存儲後端，並且支持使用grafana（一款可視化效果極佳的數據可視化軟件）作為數據展示端。同時也支持使用Tcollector（openTSDB專用的數據采集工具，集成了大量的數據采集腳本，覆蓋面很廣泛）作為數據采集端，並且在我學習kairosdb的過程中，發現其api很清晰，適合配合各種插件進行二次開發。
如果僅僅是做數據展示，那麽kairosdb無疑是很合適的，但是監控系統往往還需要對監控的數據做告警監控，這樣才是一個完整的監控系統，而在當時我學習kairosdb的過程中，沒有發現有合適的插件能完成這樣一個功能，自己去寫的話無疑會耗費很長的時間。grafana自身也帶有一些告警功能，但是功能很單一，配置起來也不方便，所以也放棄了這個方法。

後來想到可以使用與kairosdb很相似的時序數據庫OpenTSDB，因為OpenTSDB的實際存儲是HBase，可以使用大數據的一些插件完成數據計算從而實現報警。使用OpenTSDB，因為之前沒有接觸過大數據相關的東西，所以Hbase的部署、配置給我帶來不少問題。最後使用OpenTSDB的過程中，發現grafana對OpenTSDB的支持和對接更友好，使用起來很方便，Tcollector更不用說了，這個采集器本身就是為OpenTSDB寫的。所以數據展示這部分實現起來很高效。
在使用OpenTSDB實現報警功能的階段，發現並沒有像想象中那麽簡單···
最後是找到了open-falcon來實現我們監控系統的報警功能。open-falcon是近兩年出現的監控系統，其發展勢頭和功能、架構都很不錯，並且其支持使用 OpenTSDB作為存儲後端，這樣使得我們前面做的事情都沒有白費。我們數據展示端使用原來的Tcollector+OpenTSDB+grafana的形式，本來是想直接使用Tcollector將數據發到open-falcon的數據轉接組件transfer中，但是open-falcon只允許其他插件將數據傳給Falcon-agent，再由agent傳給transfer，所以我們Tcollector需要修改傳輸協議，是的數據格式與agent端對應。
最後形成的結果是Tcollector+agent+OpenTSDB+（grafana、open-falcon），從而構成整個監控系統。
而使用Tcollector+agent兩個采集端，會顯得結果有點冗余，這個只能後面再進行優化。
就目前部署的情況來看，這個系統架構基本能實現對系統、機器、數據庫服務等的監控。但是由於監控需求的不同，需要花費一定的時間去修改Tcollector采集器，需要花費時間去制作grafana的Dashboard。
grafana畢竟是模板化的工具，在使用上比之自行開發會存在一些限制，但勝在部署方便、快速，也基本能滿足需求。

關於監控系統的一些想法心得