一 概述

Prometheus 是一个开源监控系统，它前身是 SoundCloud的告警工具包。从 2012 年开始，许多公司和组织开始使用 Prometheus。该项目的开发人员和用户社区非常活跃，越来越多的开发人员和用户参与到该项目中。目前它是一个独立的开源项目，且不依赖于任何公司。为了强调这点和明确该项目治理结构，Prometheus 在 2016 年继Kurberntes 之后，加入了 Cloud Native Computing Foundation。

1.1 prometheus核心概念

1.1.1 数据模型

Prometheus 从根本上存储的所有数据都是时间序列数据（Time Serie Data，简称时序数据）。时序数据是具有时间戳的数据流，该数据流属于某个度量指标（Metric）和该度量指标下的多个标签（Label）。除了提供存储功能，Prometheus 还可以利用查询表达式来执行非常灵活和复杂的查询。

• 度量指标和标签

每个时间序列（Time Serie，简称时序）由度量指标和一组标签键值对唯一确定。

度量指标名称描述了被监控系统的某个测量特征（比如 http_requests_total 表示 http 请求总数）。度量指标名称由 ASCII 字母、数字、下划线和冒号组成，须匹配正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。

标签开启了 Prometheus 的多维数据模型。对于同一个度量指标，不同标签值组合会形成特定维度的时序。Prometheus 的查询语言可以通过度量指标和标签对时序数据进行过滤和聚合。改变任何度量指标上的任何标签值，都会形成新的时序。标签名称可以包含 ASCII 字母、数字和下划线，须匹配正则表达式 [a-zA-Z_][a-zA-Z0-9_]*，带有 _ 下划线的标签名称保留为内部使用。标签值可以包含任意 Unicode 字符，包括中文。

• 采样值（Sample）

  时序数据其实就是一系列采样值。每个采样值包括：

  • 一个 64 位的浮点数值
  • 一个精确到毫秒的时间戳

• 注解（Notation）

一个注解由一个度量指标和一组标签键值对构成。形式如下：

[metric name]{[label name]=[label value], ...}

例如，度量指标为 api_http_requests_total，标签为 method=“POST”、handler="/messages" 的注解表示如下：

api_http_requests_total{method="POST", handler="/messages"}

1.1.2 度量指标类型

• 计数器（Counter）

计数器是一种累计型的度量指标，它是一个只能递增的数值。计数器主要用于统计类似于服务请求数、任务完成数和错误出现次数这样的数据。

• 计量器（Gauge）

计量器表示一个既可以增加, 又可以减少的度量指标值。计量器主要用于测量类似于温度、内存使用量这样的瞬时数据。

• 直方图（Histogram）

  直方图对观察结果（通常是请求持续时间或者响应大小这样的数据）进行采样，并在可配置的桶中对其进行统计。有以下几种方式来产生直方图（假设度量指标为 <basename>）：

  • 按桶计数，相当于 <basename>_bucket{le="<upper inclusive bound>"}
  • 采样值总和，相当于 <basename>_sum
  • 采样值总数，相当于 <basename>_count ，也等同于把所有采样值放到一个桶里来计数 <basename>_bucket{le="+Inf"}

• 汇总（Summary）

  类似于直方图，汇总也对观察结果进行采样。除了可以统计采样值总和和总数，它还能够按分位数统计。有以下几种方式来产生汇总（假设度量指标为 <basename>）：

  • 按分位数，也就是采样值小于该分位数的个数占总数的比例小于 φ，相当于 <basename>{quantile="<φ>"}
  • 采样值总和，相当于 <basename>_sum
  • 采样值总数，相当于 <basename>_count

1.1.3 任务（Job）和实例（Instance）

在 Prometheus 里，可以从中抓取采样值的端点称为实例，为了性能扩展而复制出来的多个这样的实例形成了一个任务。

例如下面的 api-server 任务有四个相同的实例：

job: api-server
instance 1: 1.2.3.4:5670
instance 2: 1.2.3.4:5671
instance 3: 5.6.7.8:5670
instance 4: 5.6.7.8:5671

Prometheus 抓取完采样值后，会自动给采样值添加下面的标签和值：

• job: 抓取所属任务。
• instance: 抓取来源实例

另外每次抓取时，Prometheus 还会自动在以下时序里插入采样值：

• up{job="[job-name]", instance="instance-id"}：采样值为 1 表示实例健康，否则为不健康
• scrape_duration_seconds{job="[job-name]", instance="[instance-id]"}：采样值为本次抓取消耗时间
• scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}：采样值为重新打标签后的采样值个数
• scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}：采样值为本次抓取到的采样值个数

1.2 prometheus特点

• 多维度数据模型，一个时间序列由一个度量指标和多个标签键值对确定
• 灵活的查询语言，对收集的时许数据进行重组
• 强大的数据可视化功能，除了内置的浏览器，也支持grafana集成
• 高效存储，内存加本地磁盘，可通过功能分片和联盟来拓展性能
• 运维简单，只依赖于本地磁盘，go二进制安装包没有任何其他依赖
• 精简告警
• 非常多的客户端库
• 提供了许多导出器来收集常用系统指标

1.3 altermanager 核心概念

1.3.1 分组

分组将类似性质的警报分类为单个通知。在许多系统一次性失败并且数百到数千个警报可能同时发生的较大中断期间，这尤其有用。

示例：发生网络分区时，群集中正在运行数十或数百个服务实例。一半的服务实例无法再访问数据库。Prometheus中的警报规则配置为在每个服务实例无法与数据库通信时发送警报。结果，数百个警报被发送到Alertmanager。

作为用户，人们只想获得单个页面，同时仍能够确切地看到哪些服务实例受到影响。因此，可以将Alertmanager配置为按群集和alertname对警报进行分组，以便发送单个紧凑通知。

通过配置文件中的路由树配置警报的分组，分组通知的定时以及这些通知的接收器。

1.3.2 抑制

如果某些其他警报已经触发，则抑制是抑制某些警报的通知的概念。示例：正在触发警报，通知无法访问整个集群。Alertmanager可以配置为在该特定警报触发时将与该集群有关的所有其他警报静音。这可以防止数百或数千个与实际问题无关的触发警报的通知。通过Alertmanager的配置文件配置禁止。

1.3.3 沉默

沉默是在给定时间内简单地静音警报的简单方法。基于匹配器配置静默，就像路由树一样。检查传入警报它们是否匹配活动静默的所有相等或正则表达式匹配器。如果他们这样做，则不会发送该警报的通知。在Alertmanager的Web界面中配置了静音。

1.3.4 客户端行为

Alertmanager对其客户的行为有特殊要求。这些仅适用于不使用Prometheus发送警报的高级用例。

1.3.5 高可用

Alertmanager支持配置以创建用于高可用性的集群。这可以使用–cluster- *标志进行配置。重要的是不要在Prometheus和它的Alertmanagers之间加载平衡流量，而是将Prometheus指向所有Alertmanagers的列表。

二 架构

2.1 prometheus架构图



2.2 altermanager架构图