存儲：自帶了一個 graphite
分析：沒有
可視化：專門定制了一個
前端
評價：
涉及技術多，雜合在一起，認知和維護負擔大。其涉及的技術包括但不限于：vagrant, salt, django, graphite ,node, diamond。就安裝過程來說，我花了兩天左右，然后成功發現其所有涉及倉庫的 master 版本無法一起跑起來。首先，Github Release 只有 Ubuntu 的包，還是 15 年 10 月上傳的，我們系統是CentOS 7.2，因此我只能照著
這個教程 從源碼編譯打包安裝。安裝過程中 salt 安裝包時包文件沖突，rpm build 時找不到文件。它的前端
romana 從 Release 下載后放到對應目錄，發現有些前端文件找不到，必須去改它 Django 的 view，Django 沒學過，改時不太有底，終于讓前端頁面顯示之后，發現前端請求的一個 API 后端沒有實現。
項目已停滯，開發資源轉向 ceph-mgr。從
該項目 Github Insights 可以看出 2017 年后 commit 較少，commit 較多的人有兩個，排第一的 [jcsp] 目前主要在開發 ceph-mgr。
cephmetrics
cephmetrics。基本原理是基于 collectd 插件，從 admin socket 中采數據發往 graphite，用 grafana 做圖。
評價：
項目劃分比 calamari 清晰，各組件都用了業界主流解法。collectd （采集） graphite（存儲和計算） grafana（可視化）。比較看好這種解法。
collectd 插件是部署到每臺機器上的，解決了采集的負載均衡問題，但插件的部署、升級、管理相對麻煩，并且可能影響目標主機，問題不是太大，可以采納。
Dashboard 不大好，冗余代碼多。其提供的 Dashboard 中選擇的數據，以及數據的擺放，Dashboard 之間的關聯考慮的不是太好，例如沒有把相關數據放到一起，沒有根據一個目的在做圖表，有堆砌數據的感覺。冗余代碼是指包含了 ansible 部署代碼，collectd 關于 cpu 等系統數據的采集的配置等與 Ceph 本身無關的代碼，增加了認知負擔。
ceph_exporter
ceph_exporter?；驹硎抢?librados，從 ceph monitor 中取數據，通過 http 協議把指標以 prometheus 規定的格式暴露出來。
評價：
是個純采集組件，只需部署一處，和 ceph monitor 通信，模式簡單易理解，非?？春?。
一個缺點是 prometheus 系統本身具有的。其插件是通過 exporter 的形式分散到各個倉庫里，分別部署，那么多 exporter，每個都是獨立的進程，怎么管理它們是個大問題。管理就包括部署，監控，升級，配置管理，啟動和停止，每一個都是問題。相比之下，collectd 做為一個采集框架，為所有插件的實現提供了共有基礎功能，使得插件的實現變得非常簡單：
為插件提供了運行環境。插件只需提供 read （input 插件），write（output 插件），無需啟動進程，無需處理信號。
為插件提供了配置系統。插件無需擔心如何如何配置自己，用戶只要在 collectd 配置文件中按統一格式傳入，插件就可以以統一的方式拿到。
為插件提供了 Log 機制。插件可以使用 collectd 的日志機制，從而無需擔心如何支持 level，輸出到不同地方等。
為插件提供了數據通道。插件之間的數據是打通的，插件無需關心輸出到哪，是 graphite，influxdb，還是 opentsdb。只需實現 read 回調來采集數據，然后配置不同的 output 插件，就能實現輸出到不同地方。
ceph-mgr
在以上背景下，ceph 官方開發了 ceph-mgr，主要目標實現 ceph 集群的管理，為外界提供統一的入口。要深入了解 ceph-mgr，就得了解 ceph-mgr 是如何跑起來的。
由
官方文檔 可知，ceph-mgr 是通過可執行文件
ceph-mgr 跑起來的，在源碼
src/CMakeLists.txt 搜索
ceph-mgr 可以搜到
add_executable(ceph-mgr ${mgr_srcs}...，從中可以看出 ceph-mgr 主要由
src/mgr 里的文件編譯出來（猜也猜的出來），main 函數在
src/ceph_mgr.cc。以上就是相關文件，有需要深入的人可以去讀，這里介紹整理之后的 ceph-mgr 工作原理。
ceph-mgr 工作的模式是事件驅動型的，意思就是等待事件，事件來了則處理事件返回結果，又繼續等待。其主要運行的線程包括：
messenger 線程。這是事件驅動主線程，監聽某一端口，由外界給輸入事件，messenger 收到事件后分派給各個處理者。通過向 monitor 訂閱某一個 topic 的消息，例如
mgrmap,
osdmap，monitor 會在這些數據發生變化時把事件通知到 messenger 監聽的端口。事件處理器包括：
MgrStandby。Mgr 通過 standby 實現高可用，每一個運行的 ceph-mgr 都包含一個 MgrStandby，MgrStandby 并沒有運行的線程，它存在于 messenger 收到消息時的回調，以及通過定時器線程運行的定時任務，并且管理著其他實體。其處理的唯一消息是
mgrmap，就是當主掛掉時要頂上來，當自己不是主時要退回去。什么時候切主由 monitor 管理，所以 MgrStandby 里切主邏輯比較簡單，有一個
Mgr 實例，當收到 mgrmap 時生成該實例，存到 MgrStandby 屬性里，就完了。因為在收到消息時，MgrStandby 如果看到有
Mgr 實例，就會把消息發到它那處理，在定時函數里，也會調用 mgr 的定時函數，這樣，實際上，MgrStandby 就擔起了主的任務。
Mgr。如上段所述，Mgr 依附于 MgrStandby 存在，也沒有單獨線程。它通過處理
mon_map，
fs_map，
osd_map等事件，在內存中維護了集群成員信息，它管理 ceph-mgr 插件，為插件提供了所有數據的來源，也在特定事件發生時通知給 ceph-mgr 的插件，例如插件的
notify 函數，就是被 Mgr 回調的。
DaemonServer。獨立線程，和主 messenger 監聽同一端口(待確認)。是 cluster 指標數據的主要維護者，并且負載執行對集群的操作，例如吩咐 OSD 進行
pg scrub等。
plugin 線程。plugin 是 Python 寫的，每個 plugin 都跑在單獨線程里，線程調用的函數是 python 類的
serve。plugin 可以在 serve 里跑個 http server 來提供對外服務，ceph-mgr 為 plugin 提供了
get，
get_server 等函數，這些函數返回關于集群的指標等數據。例如 prometheus 插件，就把 ceph 內部指標通過 http 協議以 prometheus 格式暴露出來，使得監控 ceph 集群變得較為簡單。ceph 是 c 寫的，ceph 會調用 python plugin 定義的方法（例如 serve），python plugin 可以調用 c 定義的函數（例如
get)，python/c 的互調是 python 提供的機制，其基本原理是：
c 調 python。python 的實體在 c 里類型都是
PyObject，模塊，函數、類、數據都是。cpython 提供了
PyImport_Import 用于通過名字得到 m模塊對象對應的 PyObject，類可以通過
PyObject_GetAttrString 取模塊的屬性得到，以此類推，cpython 還提供了由 c 類型的值生成對應 python 類型的值的PyObject 的方法，例如
PyObject* PyString_FromString(char *)。有函數對象，有參數對象，就可以通過
PyObject * PyObject_CallObject() 調用函數，將得到的 PyObject* 再轉回 c 類型就 OK 了。
python 調用 c 。在 c 里定義
PyObject* ceph_state_get(PyObject *self, PyObject *args)，在函數里里面通過
PyArg_ParseTuple(args, ss:ceph_state_get, &handle, &what) 把參數解析為 c 類型，就實現了一個 Python 函數。通過
PyMethodDef CephStateMethods[] = {{get, ceph_state_get, METH_VARARGS,Get a cluster object}} 把 Python 函數加入到一個注冊表里。通過
Py_InitModule(ceph_state, CephStateMethods)，將注冊表里的函數定義為
ceph_state 模塊的屬性，并把該模塊注入到 python sys.path 里，python 就可以通過
ceph_state.ceph_state_get 調用該函數了。
作者：李逸超【資深軟件開發工程師】
為研發提效，全是技術干貨的滴滴云技術沙龍報名中！
馬上關注滴滴云公眾號：
回復「上課」獲取免費報名資格
回復「服務器」免費獲得云服務器入門1個月體驗
更多關于云服務器，域名注冊，虛擬主機的問題，請訪問三五互聯官網：m.shinetop.cn