- 常见方式是通过拉取方式采集数据
- 也可通过中间网关支持推送方式采集数据
- 通过服务发现或者静态配置来发现监控目标
- 支持多种图形界面展示方式
1.3 架构
下面这张图描述了 Prometheus 的整体架构，以及其生态中的一些常用组件。
Prometheus Server 采用拉取方式从监控目标直接拉取数据，或者通过中间网关间接地拉取监控目标推送给网关的数据。它在本地存储抓取的数据，通过一定规则进行清理和整理数据，然后把得到的结果存储起来，各种 Web UI 使用 PromQL 查询语言来从 Server 里获取数据。当 Server 监测到有异常时会推送告警给 Alertmanager，Alertmanager 负责去通知相关人。
二、Prometheus 跟其它监控系统对比
=========================================================================================
2.1 Prometheus vs Zabbix
- Zabbix 使用的是 C 和 PHP，Prometheus 使用 Golang ，整体而言 Prometheus 运行速度更快一点。
- Zabbix 属于传统主机监控，主要用于物理主机、交换机、网络等监控，Prometheus 不仅适用主机监控，还适用于 Cloud、SaaS、Openstack、Container 监控。
- Zabbix 在传统主机监控方面，有更丰富的插件。
- Zabbix 可以在 WebGui 中配置很多事情，Prometheus 需要手动修改文件配置。
2.2 Prometheus vs. Nagios
- Nagios 数据不支持自定义 Labels，不支持查询，告警也不支持去噪、分组，没有数据存储，如果想查询历史状态，需要安装插件。
- Nagios 是上世纪 90 年代的监控系统，比较适合小集群或静态系统的监控。Nagios 太古老，很多特性都没有，Prometheus 要优秀很多。
2.3 Prometheus vs Sensu
- Sensu 广义上讲是 Nagios 的升级版本，它解决了很多 Nagios 的问题，如果你对 Nagios 很熟悉，使用 Sensu 是个不错的选择。
- Sensu 依赖 RabbitMQ 和 Redis，数据存储上扩展性更好。
2.4 Prometheus vs InfluxDB
- InfluxDB 是一个开源的时序数据库，主要用于存储数据，如果想搭建监控告警系统，需要依赖其他系统。
- InfluxDB 在存储水平扩展以及高可用方面做的更好，毕竟核心是数据库。
三、Prometheus 核心概念
====================================================================================
3.1 数据模型
Prometheus 从根本上存储的所有数据都是时间序列数据（Time Serie Data，简称时序数据）。时序数据是具有时间戳的数据流，该数据流属于某个度量指标（Metric）和该度量指标下的多个标签（Label）。除了提供存储功能，Prometheus 还可以利用查询表达式来执行非常灵活和复杂的查询。
3.2 度量指标和标签
每个时间序列（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 字符，包括中文。
3.3 采样值（Sample）
时序数据其实就是一系列采样值。每个采样值包括：
- 一个 64 位的浮点数值
- 一个精确到毫秒的时间戳
3.4 注解（Notation）
一个注解由一个度量指标和一组标签键值对构成。形式如下：
[metric name]{[label name]=[label value], ...}例如，度量指标为 api_http_requests_total，标签为 method=“POST”、handler=“/messages” 的注解表示如下：
api_http_requests_total{method="POST", handler="/messages"}四、度量指标类型
===========================================================================
Prometheus 里的度量指标有以下几种类型：
4.1 计数器（Counter）
计数器是一种累计型的度量指标，它是一个只能递增的数值。计数器主要用于统计类似于服务请求数、任务完成数和错误出现次数这样的数据。
4.2 计量器（Gauge）
计量器表示一个既可以增加，又可以减少的度量指标值。计量器主要用于测量类似于温度、内存使用量这样的瞬时数据。
4.3 直方图（Histogram）
直方图对观察结果（通常是请求持续时间或者响应大小这样的数据）进行采样，并在可配置的桶中对其进行统计。有以下几种方式来产生直方图（假设度量指标为 ）：
- 按桶计数，相当于
<basename>_bucket{le="<upper inclusive bound>"} - 采样值总和，相当于
<basename>_sum - 采样值总数，相当于
<basename>_count，也等同于把所有采样值放到一个桶里来计数<basename>_bucket{le="+Inf"}
4.4 汇总（Summary）
类似于直方图，汇总也对观察结果进行采样。除了可以统计采样值总和和总数，它还能够按分位数统计。有以下几种方式来产生汇总（假设度量指标为 <basename>）：
- 按分位数，也就是采样值小于该分位数的个数占总数的比例小于 φ，相当于
<basename>{quantile="<φ>"} - 采样值总和，相当于
<basename>_sum - 采样值总数，相当于
<basename>_count
五、 任务（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
