监控利器之 Prometheus

作者：xizhibei 编辑：moon 原文：https://github.com/xizhibei/blog/issues/54

一直以来，我们会在项目中，使用 APM 去监控应用的状况，分析性能等，这些工具很有效，而且不侵入业务，不需要埋点。

然而，有些需求，是 APM 的监控满足不了的，比如 *应用业务指标 *。

监控模式

目前，采集指标有两种方式，一种是『推』，另一种就是『拉』：

推的代表有 ElasticSearch，InfluxDB，OpenTSDB 等，需要你从程序中将指标使用 TCP，UDP 等方式推送至相关监控应用，只是使用 TCP 的话，一旦监控应用挂掉或存在瓶颈，容易对应用本身产生影响，而使用 UDP 的话，虽然不用担心监控应用，但是容易丢数据。

拉的代表，主要代表就是 Prometheus，让我们不用担心监控应用本身的状态。而且，可以利用 DNS-SRV 或者 Consul 等服务发现功能就可以自动添加监控。

当然，InfluxDB 加上 collector，或者 ES 加上 metricbeat 也可以变为 『拉』，而 Prometheus 加上 Push Gateway 也可以变为 『推』。

接下来，我们主要介绍下 Prometheus。

Prometheus

『普罗米修斯』，也是希腊之神，取义『先见之明』，应该就是监控的意义所在吧。

它跟 k8s 一样，也是依据 Google 内部的应用原理设计来的，可以看作是 Google 内部监控系统 Borgmon 的一个实现。

架构图如下（来自 Prometheus 官方文档）：

Prometheus 可以从配置或者用服务发现，去调用各个应用的 metrics 接口，来采集数据，然后存储在硬盘中，而如果是基础应用比如数据库，负载均衡器等，可以在相关的服务中安装 Exporters 来提供 metrics 接口供 Prometheus 拉取。

采集到的数据有两个去向，一个是报警，另一个是可视化。

下面将一一介绍。

Metrics 格式

  
  
  

   
<metric name>{
       <label name>=<label value>, ...}
  

各个部分需符合相关的正则表达式

• metric name: [a-zA-Z:][a-zA-Z0-9:]*

• label name: [a-zA-Z0-9_]*

• label value: .* (即不限制)

需要注意的是，label value 最好使用枚举值，而不要使用无限制的值，比如用户 ID，Email 等，不然会消耗大量内存，也不符合指标采集的意义。

Metrics 接口的实现

大部分语言都有提供客户端，比如 Node.js 的客户端 prom-client：

  
  
  

   
npm install prom