# 背景

監控是管理的第一步，所以 ceph-mgr 目前的主要功能是把叢集的一些指標暴露給外界使用。監控是什麼東西呢？舉個例子，例如使用者訪問網站 5xx 了，那麼監控就是這麼一個系統：採集網站 5xx 的個數，存起來，然後在 5xx 多的時候透過報警簡訊報給開發，然後為開發解決該問題提供其他資訊（例如日誌，指標圖表）。所以監控系統是一個資料系統，包含採集，儲存，分析（包含報警），視覺化，這幾個部分。

關於監控，在此之前，ceph 以及社群有不少嘗試。

## calamari

[calamari](http://ceph.com/planet/ceph-calamari-the-survival-guide/)。calamari 是 ceph 背後的公司 Inktank 為 ceph 企業版開發的監控管理程式，在 Red Hat 收購該公司後開源，目前基本處於停滯狀態。其基本原理是利用 salt 遠端執行 python 指令碼，該指令碼透過 ceph 每個守護程式暴露在本地的 admin socket 採集到資料或者執行命令。其主要包含幾部分：

* 採集：
  * ceph 資料。salt + python 指令碼
  * 主機資料。[Diamond](https://github.com/python-diamond/Diamond)
* 儲存：自帶了一個 graphite
* 分析：沒有
* 視覺化：專門定製了一個[前端](https://github.com/ceph/calamari-clients)

評價：

* 涉及技術多，雜合在一起，認知和維護負擔大。其涉及的技術包括但不限於：vagrant, salt, django, graphite ,node, diamond。就安裝過程來說，我花了兩天左右，然後成功發現其所有涉及倉庫的 master 版本無法一起跑起來。首先，Github Release 只有 Ubuntu 的包，還是 15 年 10 月上傳的，我們系統是CentOS 7.2，因此我只能照著 [這個教程](http://ceph.com/planet/ceph-calamari-the-survival-guide/) 從原始碼編譯打包安裝。安裝過程中 salt 安裝包時包檔案衝突，rpm build 時找不到檔案。它的前端 [romana](https://github.com/ceph/romana) 從 Release 下載後放到對應目錄，發現有些前端檔案找不到，必須去改它 Django 的 view，Django 沒學過，改時不太有底，終於讓前端頁面顯示之後，發現前端請求的一個 API 後端沒有實現。
* 專案已停滯，開發資源轉向 ceph-mgr。從 [該專案 Github Insights](https://github.com/ceph/calamari/graphs/contributors) 可以看出 2017 年後 commit 較少，commit 較多的人有兩個，排第一的 [jcsp] 目前主要在開發 ceph-mgr。

## cephmetrics

[cephmetrics](https://github.com/ceph/cephmetrics)。基本原理是基於 collectd 外掛，從 admin socket 中採資料發往 graphite，用 grafana 做圖。

評價：

* 專案劃分比 calamari 清晰，各元件都用了業界主流解法。collectd （採集）+  graphite（儲存和計算） + grafana（視覺化）。比較看好這種解法。
* collectd 外掛是部署到每臺機器上的，解決了採集的負載均衡問題，但外掛的部署、升級、管理相對麻煩，並且可能影響目標主機，問題不是太大，可以採納。
* Dashboard 不大好，冗餘程式碼多。其提供的 Dashboard 中選擇的資料，以及資料的擺放，Dashboard 之間的關聯考慮的不是太好，例如沒有把相關資料放到一起，沒有根據一個目的在做圖表，有堆砌資料的感覺。冗餘程式碼是指包含了 ansible 部署程式碼，collectd 關於 cpu 等系統資料的採集的配置等與 Ceph 本身無關的程式碼，增加了認知負擔。

## ceph_exporter

[ceph_exporter](https://github.com/digitalocean/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 是如何跑起來的。

由 [官方文件](http://docs.ceph.com/docs/master/mgr/administrator/) 可知，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個月體驗

深入理解 ceph mgr

相關文章