【Ceph】Ceph集群的监控和告警系统的想法

Ceph 很复杂，虽然官方文档已经很努力了，但是我觉得官方文档还没有体现出他的复杂，要等你真正搭建和运维的时候才会见识到 Ceph 的复杂，在组里帮忙运维 Ceph 集群已经有差不多半年了，期间因为各种告警和事故也经常被折磨得寝食难眠，究其原因除了本身对 Ceph 了解不够之外，就是因为一些监控和告警的基础设施没有跟上，随着集群规模的逐渐增大，不可预测的情况越来越多，处理起来越来越棘手，本文就简单的总结一下过去半年的经验，以及也抒发一下对 Ceph 集群监控和告警系统搭建的一些思路。

首先我认为 Ceph 的监控已经分为内外两个部分，内很容易理解，就是 Ceph 本身的一些指标和告警，至少从 Luminous 开始，Ceph 已经集成了 Prometheus 的监控了，通过开启 Mgr 上的 Promethues 模块可以 export 出几百上千个指标，从 Mon/Mgr/Mds/Osd/Rgw 几乎所有的组件的指标都有。当然官方也提供了 Grafana 的 Dashboard 来快速搭建 Ceph 的内部监控系统，甚至通过 Ceph 自身的 Dashboard 也能观察到很多指标，这就是从内在的角度去分析 Ceph 的一些性能指标了，也有利于用户快速搭建 Ceph 的监控系统。但是单单依赖 Promethues 的指标还是不足够监控整个 Ceph 集群的（因为他实在太重要了，涉及到存储，都要相当留神），很简单的一个就是关于 Ceph Health 的描述，Prometheus 只能输出数值型的健康情况，比如1是 HEALTH_OK， 2是WARNNING，但是就 WARNNING 来说，情况就是十几甚至几十种情况了，如何有效的通过告警系统暴露出这些信息呢？单从 Promethues 去做这个事情还是很难的，如果运维在接到告警的时候只是看到 WARNNING，但是很多时候 WARNNING 还不会影响集群的读写，但是故障情况无法预测，最后也可能会导致更加严重的后果，阻塞用户的读写，那这个时候麻烦就大了。

外部分就是关于 Ceph 组件进程的监控，Ceph 组件很多，比如说 Osd，部署的时候甚至可以一个磁盘分区部署一个相应的进程，虽然 Ceph 本身的容错和自动恢复的机制能够拉起有问题的进程，但是如果这种情况频繁发生，我们还是需要一个系统去稳定记录这些情况，方便我们监控集群的健康程度，有时候可能是机器性能到达瓶颈了，有时候可能是磁盘故障了，这些原因最好能有一个外部系统去记录下来，方便以后复盘和定期的检查，已达到及早采取合适的措施。这里简单来说可以利用 Ceph Mon 暴露的 Restful API 或者是 go-ceph 等库去写一个外部的 Monitor，把每次 Ceph Health 变化的情况记录下来，同时还可以通过 Ceph Health 暴露的一些文字类的信息，来丰富告警系统的信息，来达到让运维随时都可以知道 Ceph 集群的健康情况，这为故障修复争取了时间。

今天没有讲太多技术细节的事情，至于 Monitor 怎么实现，用什么去做，我觉得没有一个标准的答案，像这种进程的监控，一般大公司都会有完备的 Agent 等去做，是要自己做还是结合公司已有的组件去做来避免重复造轮子，完全取决于你了。