关于构建监控系统的一点感想（四）：监控系统本身应该部署在哪里？

之所以想要写这篇笔记是因为上周我们的监控系统发生了一件我以前遇到的事情，这次虽然没有造成严重后果，但是很值得反思。

先说说发生的事情，也就是背景。

我们的监控是基于Prometheus构建的，然后利用grafana做可视化，都是部署在k8s里面的，这个k8s同时也是业务所在的集群，这应该也是很普遍的做法，而且网上很多教程和博客都是这么写的。

这么做的好处就是监控系统非常接近被监控系统，在采集数据上比较容易，尤其是对prometheus所在的k8s进行监控，如果跨集群监控的话还要做联邦集群。

但是这也有一个致命的问题。由于监控系统的宿主集群和被监控系统的宿主集群是同一个，当集群出问题的时候，监控系统本身也变得不可用了。本来是指望通过监控系统掌握业务系统的健康状况的，结果由于宿主集群挂出问题连带监控系统和业务都挂了。这就是上周发生的问题。

以前也发生过一件类似的事情。那时候监控系统用的是zabbix（是其他同事负责的，我只是协助，但是我了解整个事情的过程），部署在虚拟机上的。但是有一天一个关键业务系统宕机了，但是zabbix没有告警，后来排查发现zabbix也宕机了，因为zabbix和那个业务系统虽然是部署在不同的虚拟机上，但是是在同一台物理机上，宕机的根本原因是物理机硬件设备出故障了。

那监控系统应该部署在哪里呢？

我个人感觉还是应该要独立部署。而且监控系统的可用性要求也要设置的比业务系统更高，毕竟如果监控不可用的时候，那就只能等待用户来找你反馈业务系统不可用了，如果是非常关键的业务，这样的情况是不可接受的。

构建监控系统的时候，除了类似Prometheus这样开源的方案，如果使用了公有云的话，各大公有云厂商往往都有自己的监控方案，可以基于他们的监控工具做改造，比如AWS的CloudWatch等等，而且由于云厂商的监控工具使他们自己为了自家的服务开发的，所以在采集数据方面很可能比开源的共简单，但是目前统一的缺点就是可视化和告警管理做的不够好。

即便是prometheus，公有云厂商现在也开始支持托管的prometheus，AWS和阿里云好像都有，利用托管的prometheus也是一个可行的方案。