# 背景

监控是管理的第一步，所以 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` 调用该函数了。

ITPub博客

深入理解 ceph mgr

最新文章