今天分享的内容主要分为以下三个方面：

这次的分享主要是从具体的案例出发，希望通过细粒度的讲解为大家使用Promethus提供一些启发。如果当中有存疑的地方，也欢迎大家和我交流。

Prometheus最常用的架构图

根据这个架构图，我来说说Prometheus核心的工作流程：

接下来介绍一下我们在Prometheus上做的一些工作。因为原生的Prometheus上几乎都是单点的部署，不足以保证数据的可靠性，为此我们通过开发服务注册的方式来实现Prometheus的高可用性。

右下角的配置文件基本上展示了HA软件的功能：

这个程序的功能主要防止三种情况：

如果不使用自研HA的方式，也可以使用官方的方法，即用两台一模一样的Prometheus的程序去监控相同的目标。

1）Prometheus的远端存储

由于Prometheus本身存储结构的原因，官方不建议存储较多的数据，默认保存15天。使用本地存储方式就不太能满足要求情况，这可以引入Remote storage。

Prometheus定义了和远端存储的读写接口。如果存储系统要支持Prometheus的话，就要自己去实现图上的IP层，将Prometheus的读写请求转化为内部的格式来处理。

而我们使用InfluxDB作为remote的存储，主要是因为以下的原因：

图中有两个例子：

我们对后端存储的要求不是那么的高，而且也已经对Prometheus做了一次HA、因此在InfluxDB上做备份，也能满足我们需求，也保证出现故障也可以迅速恢复数据。

我对监控的定义是这样的：如果监控目标的可用性可能是4个9，那么后端监控系统的级别一定是与它持平或者更低，但绝不会高于它。我们只要做到基本把监控目标暴露出来就好，而这种后端存储可能是比较辅助的数据，所以不做过度设计。

2）对Prometheus的优化

通过配置queue conflg的参数，可以控制写入InfluxDB的性能：为了提高写入效率，Prometheus在将采集到的的samples写入远程存储之前，会先缓存在内存队列中，然后打包发给远端存储。

其中最主要的是这两个配置：

min_shards配置Prometheus使用的分片的最小数量，是远程写入启动时使用的分片的数量。如果远程写迟滞，Prometheus将自动增加分片的数量，这样大多数用户就不必调整这个参数。然而，增加最小分片可以让Prometheus在开始计算所需分片数量时避免迟滞。

每次发送的最大采样数量可以根据使用的后端进行调整。许多系统在不显著增加延迟的情况下发送更多的批处理采样而工作得非常好。如果试图在每个请求中发送大量采样，其他后端将会出现问题。足够小的默认值，适用于大多数系统。

作为目前最流行的缓存服务器，也是后端体系中比较重要的一环，几乎所有的后端都会用到Redis来进行缓存，所以这也是Redis必须实时监控的原因。掌握了Redis的方法，再去监控其他服务也能做到触类旁通。

在Prometheus中，负责数据汇报的程序统一叫做exporter，而不同的exporter负责不同的业务，并且它们具有统一的命名规范。

这里建议优先使用官方提供的exporter，如果不满足需求再进行改造。

图中左边是官方链接里Redis在数据库层面的列表，支持大部分常用的数据库，我们这边也使用社区的redis_exporter作为自己的监控。

因为Redis工作的方式是单进程多路复用，只在一台物理服务器上部署一个节点并不能发挥多核CPU的性能，所以一般我们会在单机上启动多个Redis实例来提高利用率。

但这种方式会导致给每个实例部署一个exporter监控相对来说比较麻烦，所以我们选择使用一个exporter去监控多个Redis实例的办法。

图中的例子是：使用两个redis exporter，分别是redisStandalone和redisCluster，它们按照监控redis的类型来区分。

如果发现单个exporter监控出现性能瓶颈，可以通过拆分监控增加exporter，以此来提高性能。

这个图的配置就是官方给的一个多实例监控的静态方式的一个方法，大家可以看一下。这里把监控目标全写在这个static_configs里面的。比如我有四个Redis的实例，就可以全都写上去。

通过配置采集的Redis实例的静态配置redis_exporter的地址，以及监控的Redis的实际地址, 两种采集地址的组合就可以监控到多实例Redis。启动的时候, 使用参数redis.addr= 来防止去启动endpoint去抓取本地的Redis。这种添加的方式缺陷是如果有新的监控目标就需要去修改prometheus配置文件。

当然，前面使用这种静态方式、每次启动服务器的方式，会有很多不太方便的地方，就是因为你每次监控的时候都会需要去重启服务器，或者是reload，这样不是很优雅。

另外一种方式就是通过file_sd_configs的方式去监控json文件的变化，来实现Redis的监控目标。它的使用的例子就是这样（如上图）,targets的json文件编写Redis列表:”targers”:{“redis://redis-host-01:6379”,”redis://redis-host-02:6379”}，”;labels”:{ }都写在list列表里面。这样能发现json里的监控目标，做到一个文件监控。当然这种文件也可以使用正则匹配的方式，可以写成*.json的形式，这样就可以把目录下*.json的格式的监控目标通过file_sd_configs服务发现，自动添加监控, 避免重启Prometheus服务。

但是，这两种其实对于大规模的使用和维护都会有一些缺点，因为你不管是给这种静态文件还是动态文件都需要去改文件，还是比较繁琐。下面介绍下使用consul的实现。

consul是基于GO语言开发的开源工具，主要面向分布式、服务化的系统提供服务注册、服务发现和配置管理的功能。它提供了服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等功能。前面我们也说过通过Prometheus实现监控，当新增一个Target时，需要变更服务器上的配置文件，这样会给运维人员带来很大的负担。

相对于使用这种静态配置，如果使用consul的服务发现的方式，我们通过Prometheus就可以主动地去感知到系统增加或者删除以及更新服务，然后自动地把目标加入到监控目标中，使得Prometheus相对于其他的传统监控解决方案更适用于经常变化的监控需求，包括对接外围的一些自动化系统的话，使用这种方式也是比较简单的，比如说你去维护一个文件的话，去写这种API都会比较麻烦，如果你只是去对接一个consul的API的话是非常方便的。

下面我介绍使用consul方式动态监控的流程。

首先就是通过自定义程序与数据库自动化平台进行交互自动抓取监控targets，然后就是通过在consul注册服务或注销服务（PUT请求监控targets数据给consul）,然后Prometheus会一直监控（watch）consul服务，当发现consul中符合要求的服务有新变化就会更新Prometheus的监控对象。

上图中我们的流程有一个采集程序，会定时地采集redis元数据，然后把数据同步给consul，就是复制给consul，然后Prometheus会不停地watch consul中的Redis的服务内容，然后去更新自己的监控对象，这样就能做到自动化地发现服务目标，同时也可以和我们的数据库运维平台去关联起来。

当然如果你的环境中没有这样的运维平台，这个采集程序中的抓取也可以直接去抓取Redis的master，或者redis cluster的集群节点去发现集群的其他节点，也是可以的。

上图是往consul去注册一个监控目标的方法，大家可以看一下。我们去Put的json数据，包含ID、name、address、tags、以及checks数据。右边是consul的Web页面。当我们添加如红色框里的数据后，在consul中是按照Services来分组的，这里的Services对应的就是我们添加数据中的name，然后点击其中的一个Services分组后，就可以看到这个分组下所有的监控服务了。这里我们可以看到是对应前面我们提交的数据，对应ID，Services name对应name，Tags对应我们刚刚传入的一些标签。

上面这张图就是Prometheus中关于consul的相关配置的部分。

首先是这个scrape_configs，下面配置的是数据源，像我们这里的配置的一个job_name叫做redis_exporter_targets，每5秒抓取一次，然后下面是consul_sd_configs，是consul服务发现配置的地方。这里特别重要的是一个relabel_configs，重新打标功能，这个配置非常重要，它的作用就是把数据中的一些标签做一些替换。

当我们做完前面的配置后可以看到，在consul中获取的元数据，就是上图黑色的部分框里面的内容，比如说这里我们使用的是_meta_consul_tags，用表达式,(.*),(.*),正则 ,{IP:PORT},{mastername},的形式，这个其实就是我们需要监控目标的一个mastername，通过正则表达式我们就可以提取出最终的address出来，作为刚刚提到的redis_exporter_targets的一个信息。下面，可以将传入的一个sentinel的一个mastername作为第二参数来替换掉，然后在后面我们去画监控图的时候就可以直接通过这个标签把相同mastername作为一个分组。

当我们完成了前面的配置，就可以在Prometheus的一个Web页面上简单地去看一下我们监控的一个目标，如果这里的状态是UP，就说明我们的配置是正确的，图上的这些数据都已经采集到Prometheus中了。大家可以看一下，这是几个例子。

最后我们可以在Grafana上去配置数据源，然后加载模板就可以看到如上的监控图然后我们可以通过这个mastername去做一个对实例的区分，来选择对应的监控图。

如上图，是Redis中比较关键的指标，比如说它们缓存命中率，还有过期以及驱逐key的数量，以及网络的开销等等。

刚刚这种方式不仅可以监控sentinel也可以去监控redis cluster，跟前面很相似，通过redis cluster的名称进行选择。这里要说明一下，这个cluster name只是我们自己对集群的定义，是放在数据库的元数据平台里的，通过这种方式能比较方便地去管理redis cluster，可以在一个屏幕上就看到这个集群下所有实例的信息非常实用。避免以前用Zabbix的时候每个节点都去登陆一下去看监控。

下面的例子将介绍这个Grafana整合Zabbix和Prometheus数据监控图的方式。我们生产环境Zabbix和Prometheus是都在用的，有时候查找一个问题会登录两个系统，比较费时，然后切换看图也不是非常直观，所以我们用Grafana做了一个事情，把Zabbix和Prometheus整合到一起去。

上面这个图是我们在促销活动中使用的数据库大屏，它主要是给开发人员使用，是从应用的视角来看数据库的性能。因为开发人员和我们后端的运维人员的视角会不太一样，所以我们就根据应用的维度来做了这个监控图。一般在活动开始前, 我们会把这个活动相关应用整理出, 列出相关的Redis和数据库，这样可以清楚看到应用数据库的QPS，连接数指标，在一个页面中看这些指标，研发同学就可以快速定位到具体的问题出现在哪个环节上。我们做完这个后，从开发人员的反馈来看，效果还是比较显著，他们定位问题加快了很多。

在Grafana上如果要展示Zabbix的监控数据，需要把Zabbix的插件给整合进去，可以使用grafana-cli plugins list-remote所有可以装的插件，然后安装好相关的zabbix插件，装完之后还需要进一步的加载。

当我们添加完插件后就可以去添加数据源，上图左边是我们通过Zabbix去添加数据源的一个方法，主要配置的是ZabbixURL以及API的地址，右边就是我们添加Prometheus数据源的一个监控方式，直接去填写Prometheus的地址就可以了。Zabbix有两种方式，一种是通过API的方式去添加数据源，还有一种方式是直接去连接它的DB，我比较推荐的是通过Zabbix连接API的方式而不是直接去连接数据库。

这个就是我们前面的大屏中的Zabbix和Prometheus结合的一个例子，比如的一个应用，它在应用上有一个Redis和MySQL，Redis的数据在Zabbix上，MySQL的数据是在prometheus上的，这样的话我们可以把它们集成到一个图上去，这样就可以把它们的数据整合起来，我们同时可以看到Zabbix和Prometheus上的监控数据。

上图的两个图，大家可以清晰地看到怎么使用Grafana去对应到Zabbix上的监控项，大家可以看一下，比如说我们这里填的groups其实就是对应的Zabbix上的Hosts groups，这里的应用也是对应到Zabbix的Application，这里的host也可以对应zabbix的host，最后的一个监控目标也是可以直接对应到zabbix的item，配置完成后的监控图，就跟在Zabbix上看到的几乎是一样的。

然后这个Prometheus添加这个监控图就比较简单了，通过表达式去画一个Prometheus在Grafana上的监控图。我需要注意的就是这里的变量，就是Grafana的变量要和模板上的变量去做一个匹配，非常方便。

本次分享主要是挑选了我在实践中比较有意义的或者是比较有难点的一个章节，就是希望能够给大家打开思路，做到举一反三。

↓点这里可回看本期直播
阅读原文