深入理解 ceph mgr

云计算
背景
监控是管理的第一步，所以 ceph-mgr 目前的主要功能是把集群的一些指标暴露给外界使用。监控是什么东西呢？举个例子，例如用户访问网站 5xx 了，那么监控就是这么一个系统：采集网站 5xx 的个数，存起来，然后在 5xx 多的时候通过报警短信报给开发，然后为开发解决该问题提供其他信息（例如日志，指标图表）。所以监控系统是一个数据系统，包含采集，存储，分析（包含报警），可视化，这几个部分。
关于监控，在此之前，ceph 以及社区有不少尝试。
calamari
calamari。calamari 是 ceph 背后的公司 inktank 为 ceph 企业版开发的监控管理程序，在 red hat 收购该公司后开源，目前基本处于停滞状态。其基本原理是利用 salt 远程执行 python 脚本，该脚本通过 ceph 每个守护进程暴露在本地的 admin socket 采集到数据或者执行命令。其主要包含几部分：
采集：
ceph 数据。salt python 脚本
主机数据。
diamond
存储：自带了一个 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 取模

top域名真的不值钱？个人可以注册top域名吗？
关于老域名，你知道多少？
云服务器ecs优惠帮助文档
华为云服务器怎么进远程
不小心将u盘文件删除怎么找回来？
新开通的云服务器怎么配置
怎么注册域名
让电脑键盘打字时发出声音的设置方法