【生产环境K8S从搭建到运维的实录（三）】Monitoring System监控系统

1.前述

当用户抱怨系统反映迟缓，可能是某台机器负荷过高，可能是某个服务进程被挂起，也可能是某个磁盘空间被占满，到底是什么原因呢？如果没有监控系统，对于运维人员来说是件多么可怕的事情，我们需要在几十台或者几百台服务器中去寻找原因。相反，如果有一套全面的可视化监控系统帮助我们实时地掌握整个系统的运行状态，那么我们就可以准确预测以及防止故障的发生。所以，监控系统是我们整个k8s系统中非常重要的一个子系统。

2.监控系统（Monitoring System）的构成

这次我们的监控系统主要分为三个部分，分别用到以下三个工具。

可视化数据展示模块：Grafana
监控系统的核心模块：Prometheus
监控数据存储模块：InfluxDB

当然市面上可以用来监控的工具还有很多，其中Prometheus就是近几年来非常流行并且适合k8s环境监控的工具之一，免费开源也是它被相中的一个重要原因。毕竟我们只选最对的，不选最贵的。

在我们的监控系统中，上面提到的三个工具都是以Docker容器的形式运行在同一台Linux环境的虚拟服务器中，这台服务器被我们称为监控服务器。这里需要注意一下，这台虚拟机是独立于k8s集群的，这台服务器以及服务器上运行的所有容器都是不受k8s集群管理的。

下面是我们这次监控系统的大致构成图，其中监控系统的核心Prometheus，从k8s集群中抓取各种metrics，然后将这些metrics存储到数据库InfluxDB中，再通过Grafana将情报可视化展示给运维者。
在这里插入图片描述

2-1优美的可视化数据展示模块 Grafana

Grafana 是一款go 语言编写的跨平台开源应用，主要用于大规模指标数据的可视化展现以及时通知，但是这次我们的Grafana仅仅用于优美的可视化展现数据，通知功能是通过Prometheus来实现的。关于Grafana的众多优点，网上详细描述的文章有很多，我就不再赘述了，这里我想跟大家分享的是我在开发和运用中感受到的几个优点。

支持各种数据源
大部分市面上存在的各种类型数据源，包括Time series databases，SQL，Logging & document databases，Cloud等等，Grafana都支持（当然有一些数据源需要安装插件），而且支持混合数据源。这样我们就避免了不同子系统因为不同数据源不能在同一个可视化界面展示的尴尬了。
快速配置
Grafana对于新手来说非常友好，操作简单方便，不需要设计者有很强的专业知识也能快速上手，尤其是提示补全功能实在是太方便了。

还能将仪表盘以JSON文件的形式导入导出。试想一下你在检证环境做了十个仪表盘，在生产环境中我们要把同样的配置再做一遍吗？很幸运，我们不需要，我们只需两步就能轻松完成。第一步，检证环境仪表盘JSON文件导出，第二步，将JOSN文件导入生产环境中，是不是很方便。
灵活炫酷的界面
Grafana提供了各种形式的仪表盘用来可视化展示，官网上也提供了很多模板可以直接拿来用。根据个人审美水平，展示界面可以被设计的很炫酷。不过因为本人天生没什么审美，所以这次的仪表盘设计的比较单一，这里就不给大家展示了。

2-2监控系统的核心模块 Prometheus

Prometheus作为监控系统的核心模块，主要起到了以下三个作用。当然除了这三个作用以外它还有其他功能。比如可视化，但是因为Prometheus的可视化较为单一，所以我们这次选择了Grafana作为替代。

Metrics抓取
Prometheus和上面架构图中提到的blackbox-export，fluentd等工具配合可以实现从k8s集群中抓取例如虚拟机，Pod的CPU，Memory等各种Metrics的功能。这次我们不仅仅用到文中提到的这些指标值抓取工具，还有很多类似工具就就不一一列出，可以根据自己系统需要选择。
Metrics存储
Prometheus自身也是一个时间序列数据库，所以抓取来的Metrics数据可以存贮在自带的数据库中。
监控告警
监控系统最重要的一个功能就是告警，Prometheus通过配置各种规则来实现不同需求条件的告警。告警的方式也有很多，比如邮件，PagerDuty和HipChat，这次我们用到的是邮件方式。

2-3监控数据存储模块 InfluxDB

为什么有Prometheus，我们还要用InfluxDB呢？

这个问题一定会有人问到，既然Prometheus自带时间序列数据库，我们为什么还要导入InfluxDB这个数据库呢？原因很简单，Prometheus的缺陷，它自身无法将大量的metrics持久化保存。这也是我们在系统开发后期遇到的一个课题，如何将metrics长期保存。
我们是怎么解决数据长期保存问题的呢？

还好，上帝关上一扇门，必定会为你打开一扇窗。prometheus虽然没有自己实现集群存储，但是提供了远程读写的接口，让用户自己选择合适的时序数据库来实现Prometheus的扩展性。所以最终我们选择了InfluxDB这个数据库来实现metrics持久化保存。
我们又是如何防止数据丢失的呢？

数据长期保存的方法解决了，那么问题又来了，metrics数据是存储在InfluxDB数据库中的，前面我也提到过InfluxDB是以容器形式运行在监控服务器上的，如果服务器故障导致容器被删除，那么存储在InfluxDB数据库中的数据都会丢失。为了解决这个问题，我们用到了NAS存储，也就是说将InfluxDB容器中，数据存储的路径带到容器以外的NAS上，这样我们定期对NAS进行备份，就不会担心数据丢失的问题了。

3.结束语

我们的监控系统在设计的时候有很多不完善的地方，因为是第一次从0开始，最初的设计很多地方考虑的不是很全面，这些问题在运用的过程中慢慢暴露出来，我们也在不断发现问题，改进问题。之后有机会我会把这些问题点整理出来和大家分享，希望能提醒或者帮助到正在做着同样监控系统的你们。

作者：rm * 小组
日期：2020/9/6