• 前言
• 什么是监控
• • 监控的基础原则
• Prometheus
• • Prometheus架构
  • • 指标收集
    • • 关于指标
    • 服务发现
    • • 人工的配置文件列表
      • 基于文件的自动发现
      • 基于API的自动发现
      • 基于DNS的自动发现
    • 聚合、查询和 警
    • • 指标聚合
  • Prometheus 数据模型
  • • 保留时间
  • 高可用方案
  • Prometheus开源生态

)

前言

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

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

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

什么是监控

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

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

监控的基础原则

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

• 监控什么：

Created with Rapha2.2.0 业务逻辑算法 应用程序系统 操作系统

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

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

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

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

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

Prometheus

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

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

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

服务发现

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

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

人工的配置文件列表

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

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

基于文件的自动发现

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

示例如下：

基于API的自动发现

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

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

基于DNS的自动发现

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

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

Prometheus 数据模型

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

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

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的生态是比较完善的，并且 区足够活跃，未来可期。