我這篇文章[裡寫過的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畢竟是模板化的工具，在使用上比之自行開發會存在一些限制，但勝在部署方便、快速，也基本能滿足需求。
關於監控系統的一些想法心得
我這篇文章 裡寫過的kairosdb，那是我開始接觸監控系統的第一步，它幫助我了解了時序資料庫在監控端的優秀表現。kairosdb算是相當優秀的監控系統儲存後端，並且支援使用grafana 一款視覺化效果極佳的資料視覺化軟體 作為資料展示端。同時也支援使用tcollector opentsdb專用的...
關於推薦系統的一些想法
如何有效的利用使用者資訊來提公升推薦的精度和使用者體驗是乙個尚待解決的問題 大致可以總結下以後大的研究方向，有時間再進一步深挖！1 深度復合模型 deep composite models 2 使用者和物品的深度理解 3 temporal dynamics 4 cross domain recomm...
關於檔案系統的一些想法
最近試了一些檔案系統，jffs2，yaffs2，ramdisk，單獨使用。同時還測試了組合使用，也就是雙檔案系統。yaffs2 jffs2 和 ramdisk yaffs2.個人覺得，單檔案系統和雙檔案系統各有利弊。針對目前客戶的情況，以及目前我手頭的硬體測試結論，雙檔案系統 ramdisk yaf...