深入理解监控系统——Prometheus核心特点

)

前言

接触过各式各样的监控，开源的CAT、Zipkin、Pinpoint等等，并深度二次开发过；也接触过收费的听云系APM，对各类监控的亮点与局限有足够的了解。

去年10月我们快速落地了一套易用、合适、有亮点的业务监控平台，其中使用了Prometheus。从技术选型阶段，Prometheus以及它的生态就让我印象深刻，今天就聊聊监控与Prometheus。

通常监控主要分为 采集（源：日志、metrics）、上报数据（协议:http、tcp）、消费聚合、存储、告警模块等。采集上报主要是客户端的核心功能，一般有定期外围探测的（早期的Nagios）、AOP方式手动织入代码的（埋点）、字节码自动织入等方式。

什么是监控

一套产品化的，衡量、管理技术体系的工具或解决方案。

这套产品主要解决两个问题（产品价值）：
1、技术：将系统的各种功能、健康状态等技术数据化、可视化，可查看、告警，及时保证技术体系的稳定、安全等等
2、业务：将各种业务数据化、可视化，以供分析、干预，及时保证业务高效开展等等。

监控的基础原则

• 事前监控：架构设计阶段务必需要考虑监控，而不是等到部署上线才去考虑

• 监控什么：

Created with Raphaël 2.2.0 业务逻辑\算法 应用程序\系统 操作系统

对于一般业务来讲，建议先监控离用户最近的地方，用户的良好体验是推动业务发展的动力，这也是最敏感、重要的地方。

• 易用，易接入，尽可能自动化

• 能够协助故障定位与解决

• 警报与通知：
  哪些问题需要通知？（如：需要人工干预的，今发布有意义的通知）
  通知谁？（如：一线系统负责人）
  如何通知？（如：短信、电话、其他通信工具；信息清晰、准确、可操作）
  多久通知一次？（如：5分钟）
  何时停止通知以及何时升级到其他人？（如：已恢复正常；两个小时问题未恢复，升级通知到其他人）

• 可视化：清晰的显示各类数据，以及告警等信息记录等

Prometheus

Prometheus 灵感来源与Google的Borgmon，主要用于近实时、基于动态云环境、容器的微服务、应用程序的监控。
Prometheus专注于当下正在发生的各类数据，而不是追踪数周以前的数据，因为他们认为“大多数监控查询以及告警等都是一天内的数据”，Facebook相关论文也验证了这一点：85%的时序查询是26小时之内的。

简单来概括，Prometheus是一个监控系统，并自带时序数据能力。

Prometheus架构

简化点的架构图如下：

Prometheus 主要通过pull的方式获取被监控程序（target）中暴漏出来的时序数据。当然也提供了pushgateway进程，一般少量数据也可以push方式发送。push、pull方式各有利弊，prometheus之所以主要使用pull，主要因为：“”

指标收集

Prometheus通过pull的方式拉取外部进程中的时序数据（这些外部进程Prometheus官网称为EndPoint或Exporter）。Prometheus会让用户配置相关信息：如目标进程暴漏方式（http url）、如何连接、连接身份验证等等信息。

关于指标

所谓指标就是软件或硬件多种属性的度量。它是一种数据度量，有别于日志采集的那种ELK监控，Prometheus通过四种指标类型完成：

• 测量型（Gauge）：可增可减的数字（本质上是度量的快照）。常见的如内存使用率。
  

• 计数型（counter）:只增不减，除非重置为0。比如某系统的HTTP请求量。
  

• 直方图（histogram）:通过对监控的指标点进行抽样，展示数据分布频率情况的类型。
  
  上图强调了分布对于理解延迟等指标的重要性。如果我们假设这个指标的SLO（服务等级目标）为150ms，那么137ms的平均延迟看起来是可以接受的;实际上，每10个请求中就有1个在193ms或以上(90%)完成，每100个请求中就有1个需要1个以上!

• 摘要（summary）:与Histogram非常类似，主要区别是summary在客户端完成聚合，而Histogram在服务端完成。因此summary只适合不需要集中聚合的单体指标(如GC相关指标)。
  两条经验法则：
  1、如果需要汇总，请选择直方图。
  2、否则，如果对将要观察的值的范围和分布有所了解，请选择直方图。无论值的范围和分布如何，如果需要准确的分位数，请选择摘要。

服务发现

Prometheus通过pull的方式获取服务的指标数据，那么它是如何发现这些服务的呢？

可以通过多种方式来处理目标资源的发现：

人工的配置文件列表

通过手工方式，添加静态配置，指定需要监控的服务，如下target块：

scrape_configs:
.....

#监控活动
  - job_name: 'xxxxxxactivity-wap'
    metrics_path: /prometheus/metrics
    static_configs:
    - targets: ['10.xx.xx.xx:8080',
				......  ......]


    #监控优惠券
  - job_name: 'xxxxxxshop-coupon'
    metrics_path: /prometheus/metrics
    static_configs:
    - targets: ['10.xx.xx.xx:8080',
				......  ......]            

    #营销
  - job_name: 'xxxxxx-sales-api'
    metrics_path: /prometheus/metrics
    static_configs:
    - targets: ['10.xx.xx.xx:8080',
                ......  ......
               ]
......

显而易见，这种方式虽然很简单，但是在繁忙的工作中持续维护一长串服务主机列表并不是一个可扩展的优雅方式，动态性、大规模会让这种方式无法继续下去。

基于文件的自动发现

指定加载目录，这些目录文件的变更将通过磁盘监视检测发现，然后Prometheus会立即应用这些变更。作为备用方案，文件内容也将以指定的刷新间隔（refresh_interval）定期被Prometheus重新读取，发现变更后生效。

示例如下：

......
#监控 订单中心OMS-API
scrape_configs:
  - job_name: 'oms-api'
    metrics_path: /prometheus/metrics
    file_sd_configs:
    - files:
     - 'conf/oms-targets.json'
     #默认 5分钟
     refresh_interval:5m
......


##conf/oms-targets.json文件（此文件的变动将被监听，通常这个文件由另一个程序产生，如CMDB源）：

[
  {
    "labels": {
      "job": "oms-api"
    },
    "targets": [
      'ip1:8080','ip2:8080',......
    ]
  }
]    

基于API的自动发现

当前可以用的本机服务发现插件有AmazonEC2、Azure、Consul、Kubernetes等等。
下文以Consul为例，实例启动成功时可以通过脚本（或其他）方式将当前节点信息，注册到Consul上（类似启动后向zk或redis写入当前节点信息）。Prometheus会实时的感知到Consul数据的变动，并自动去做热加载。

#监控 订单中心OMS-API
- job_name: 'oms-api'
    consul_sd_configs:
    #consul 地址,默认监听所有服务地址信息
      - server: 'xxxxxx'
        services: []

注：Consul 是基于 GO 语言开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务发现和配置管理的功能。Consul 提供服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等功能

基于DNS的自动发现

在前几种方式都不适合的情况下，DNS服务发现允许你指定DNS条目列表，然后查询这些条目中的记录，以发现获取目标列表。用的比较少，不赘述。

被监控的目标成功被发现后，可以在自带的web页面上可视化查看，如图（本地模拟环境）：

聚合、查询和报警

内置的PromQL可以快速的支持聚合和多种形式的查询，并可通过自带的可视化界面在浏览器中使用。也可以使用Grafana

配套的AlertManager基于gossip协议，可以管理、过滤各类告警信息。

指标聚合

对于指标的聚合，Prometheus提供了多种函数。以下列聚合为例：

• 平均数
• 中间数
• 百分位数（如下图99线：百分之99的请求要低于12s这个值）
• 标准差（衡量数据集差异情况，0代表与平均数一样，越大表示数据差异越大）
• 变化率

Prometheus 数据模型

Prometheus与其他主流时序数据库一样，在数据模型定义上，也会包含metric name、一个或多个labels（同InfluxDB里的tags含义）以及metric value。

如用JSON表示一个时序数据库中的原始时序数据：

##用JSON表示一个时序数据
{
  "timestamp": 1346846400,            // 时间戳
  "metric": "total_website_visits",  // 指标名
  "tags":{                          // 标签组
    "instance": "aaa",
    "job": "job001"
  },
  "value": 18			          // 指标值
}

metric name加一组labels作为唯一标识来定义time series（也就是时间线）。一旦label改变，则会创建新的时间序列，原有基于这个时间序列的配置将无效。在查询时，支持根据labels条件查找time series，支持简单的条件也支持复杂的条件。
上图是所有数据点分布的一个简单视图，横轴是时间，纵轴是时间线，区域内每个点就是数据点。Prometheus每次接收数据，收到的是图中区域内纵向的一条线。这个表述很形象，因为在同一时刻，每条时间线只会产生一个数据点，但同时会有多条时间线产生数据，把这些数据点连在一起，就是一条竖线。这个特征很重要，影响数据写入和压缩的优化策略。

保留时间

Prometheus专注于短期监控、告警而设计，所以默认它只保存15天的时间序列数据。如果要更长期，建议考虑数据单独存储到其他平台。

高可用方案

后文详述

Prometheus开源生态

Prometheus生态系统包括了提供告警引擎、告警管理的AlertManager，支持push模式数据上报的PushGateWay，提供更优雅美观的可视化界面的Grafana，支持远端存储的RemoteStoreAdapter；log转换为metric的Mtail等等。

除此之外，还有一系列Exporter（可以理解为监控agent），这些Exporter可以直接安装使用。自动监控应用程序、机器、主流数据库、MQ等等。

Prometheus生态中还有一系列客户端库，支持各种主流编程语言Java、C、Python等等。

可以说Prometheus的生态是比较完善的，并且社区足够活跃，未来可期。