Prometheus学习笔记（1）Prometheus架构简介
Prometheus简介和架构
Prometheus 是由 SoundCloud 开源监控告警解决方案。架构图如下：
如上图，Prometheus主要由以下部分组成：
- Prometheus Server：用于抓取和存储时间序列化数据
- Exporters：主动拉取数据的插件
- Pushgateway：被动拉取数据的插件
- Altermanager：告警发送模块
- Prometheus web UI：界面化，也包含结合Grafana进行数据展示或告警发送
prometheus本身是一个以进程方式启动，之后以多进程和多线程实现监控数据收集、计算、查询、更新、存储的这样一个C/S模型运行模式。了解以下疑问信息
1、Prometheus是如何存储数据的？？？
prometheus采用time-series(时间序列)方式，存储在本地硬盘
-
prometheus本地T-S数据库以每2小时间隔来分block(块)存储，每个块又分为多个chunk文件，chunk文件用来存放采集的数据的T-S（time-series）数据，metadata和索引文件；
-
index文件是对metrics和labels进行索引之后存储在chunk中，chunk是作为基本存储单位，index和metadata作为子集；
-
prometheus平时采集到的数据先存放在内存之中，对内存消耗大，以缓存的方式可以加快搜索和访问；
-
在prometheus宕机时，prometheus有一种保护机制WAL，可以将数据定期存入硬盘中以chunk来表示，在重新启动时，可以恢复进内存当中。
-
当通过API删除序列时，删除的记录存储在单独的tombstone文件中(而不是立即从块文件中删除数据)。
如下，是在进行数据收集后，在Prometheus中的data目录的数据
[root@prometheus prometheus]# tree data/
data/
├── 01DVRSS47GBRWVCH50GEXXHBQ5
│ ├── chunks
│ │ └── 000001
│ ├── index
│ ├── meta.json
│ └── tombstones
├── 01DVS0MVFHDN6ZS0R0Z3YR94VM
│ ├── chunks
│ │ └── 000001
│ ├── index
│ ├── meta.json
│ └── tombstones
├── 01DVS0MVMFEAAYQSNYHPV86E5T
│ ├── chunks
│ │ └── 000001
│ ├── index
│ ├── meta.json
│ └── tombstones
├── 01DVS7GJQT4GQBHBMX20V9JW4H
│ ├── chunks
│ │ └── 000001
│ ├── index
│ ├── meta.json
│ └── tombstones
├── lock
├── queries.active
└── wal
├── 00000012
├── 00000013
├── 00000014
├── 00000015
└── checkpoint.000011
└── 00000000
这里需要注意的是，本地存储的一个限制是它不是集群的或可复制的。因此，在磁盘或节点宕机时，它也不是任意可伸缩或持久的，对于磁盘可用性，建议使用RAID、备份快照、容量规划等，以提高持久性。应该通过适当的存储持久性和计划在本地存储中存储多年的数据。
2、prometheus集成的服务发现功能？？？
prometheus是通过Consul做的服务发现，和其他开源软件类似，prometheus也是通过配置文件来指定需要监控的项目和被监控的节点。如下面的配置模板：
[root@prometheus ~]# cat /usr/local/prometheus/prometheus.yml
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
external_labels:
monitor: 'codelab-monitor'
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
scrape_interval: 5s
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
3、Prometheus数据采集的方式？？？
prometheus客户端主要由2种数据采集的方式：
- pull：主动拉取形式
- push：被动推送的形式
pull：指的是客户端（被监控主机）先安装各类已有的exporters在系统上，exporters以守护进程的模式运行，并开始采集数据，exporters本身也是一个http_server，可以对http请求作出响应，并返回K/V数据，也就是metrics。prometheus通过用pull的方式（HTTP_GET）去访问每个节点上的exporter并采集回需要的数据。
push：指的是客户端（或服务端）安装官方的pushgateway插件，然后通过我们自行编写的各种脚本，将监控数据组织成K/V的形式（metrics形式）发送给pushgateway，而后pushgateway再推送给prometheus，这里需要注意的是pushgateway不一定要安装在被监控端，也可以安装在服务端，甚至是一台不相关的主机上，换句话来说，它只是一个中间转发的媒介。
4、Prometheus如何实现告警？？？
Prometheus有自带的altermanager模块，配合商业化的pageduty可以实现告警和邮件的发送功能，但是由于该功能模块在国内结合pageduty使用是一件很头疼的事，你懂的。所以一般是将Prometheus的数据集成在Grafana进行展示并进行告警配置。
5、什么是metrics[指标]？？？
一组K/V数据就是metrics，总体上来说metrics是对采集过来的数据的一种统称，并非一个具体的数值或指标。
prometheus的所有监控指标（Metric）被东一定义为
<metric name>{<label name>=<label value>,...}
- metric name：指标名称，用于说明指标的含义，例如http_request_total代表的是HTTP的请求总数。指标名称必须由字面、数值下划线或者冒号组成，符合增则表达式。
- label：标签，可体现指标的维度特征，用于过滤和聚合。可以通过标签名（label name）和标签值（label value）这种键值对形式，形成多种维度。
举个例子：
http_request_total{status="200", method="POST"}表示的是符合请求方法为POST返回状态为200的指标
6、metrics【指标】的类型？？？
-
Gauges：最简单的度量指标，只有一个简单的返回值，或者叫做瞬时状态，比如要采集硬盘容量或内存使用率，就可以用gauges的metrics格式来度量。因为硬盘和内存是随着时间推移不断地变化，没有规则的变化，当前是多少，采集回来的就是多少，既不能肯定是一直持续增长，也不能肯定是一直降低，是多少就是多少，这种就是Gauges使用类型的代表。
-
Counters：Counters就是计数器，从数据量0开始累积计算，理想状态下，只能是永远的增长，绝不会出现降低，比如用户的访问量采样数据，我们的产品被用户访问了一次就是1，过了10分钟后积累到100，过了1天就累积到20000。
-
Histograms：柱状图，用于观察结果采样，分组及统计，如：请求持续时间，响应大小。其主要用于表示一段时间内对数据的采样，并能够对其指定区间及总数进行统计。根据统计区间计算。
-
Summary：类似Histogram，用于表示一段时间内数据采样结果，其直接存储quantile数据，而不是根据统计区间计算出来的。不需要计算，直接存储结果。
7、Pormetheus数据样本
prometheus采集的数据样本都是以时间序列保存的，每个样本由3个部分组成：指标、样本值、时间戳
如上图，一个指标的样本数据保存到一起，横轴代表时间，纵轴代表序列。每一行都代表一个指标组成的时间序列，每个点都代表一个监控数值，这些时序数据首先被保存在内存中，然后被批量刷新到磁盘
8、什么是node-exporter？？？
Prometheus为了支持各种中间件以及第三方的监控提供了exporter，大家可以把它理解成监控适配器，将不同指标类型和格式的数据统一转化为Prometheus能够识别的指标类型。
譬如Node exporter主要通过读取Linux的/proc以及/sys目录下的系统文件获取操作系统运行状态，reids exporter通过Reids命令行获取指标，mysql exporter通过读取数据库监控表获取MySQL的性能数据。他们将这些异构的数据转化为标准的Prometheus格式，并提供HTTP查询接口。
9、什么是pushgateway？？？
通过node-exporter可以收集到各种服务器的相关性指标，但是并没有办法满足我们的定制化需求，比如需要监控某个进程数，某个进程打开的文件数，某个进程消耗的内存等等，这就需要一个定制化的监控项，类似于zabbix的自定义监控项是一个道理。
