Prometheus的基本原理与开发指南
导读
本文由梯度科技云管研发部高级工程师周宇明撰写，共分为7章，紧密围绕prometheus的基本原理与开发指南展开介绍：
监控系统概述
prometheus入门
promql入门
promql高级实战
告警引擎深度解析
本地存储与远程存储
梯度运维管理平台监控模块架构
01监控系统概述
导读：本章从监控的作用、架构分类、指标监控发展史、指标监控典型架构等4个方面介绍监控系统的相关概念。
1.1．监控的作用 ★
为了构建稳定性保障体系，核心就是在干一件事：减少故障。
减少故障有两个层面的意思，一个是做好常态预防，不让故障发生；另一个是如果故障发生，要能尽快止损，减少故障时长，减小故障影响范围。监控的典型作用就是帮助我们发现及定位故障。
监控的其他作用：日常巡检、性能调优的数据佐证、提前发现一些不合理的配置。
之所以能做到这些，是因为所有优秀的软件，都内置了监控数据的暴露方法，让用户可以对其进行观测，了解其健康状况：比如各类开源组件，有的是直接暴露了 prometheus metrics 接口，有的是暴露了 http json 接口，有的是通过 jmx 暴露监控数据，有的则需要连上去执行命令。另外，所有软件都可以使用日志的方式来暴露健康状况。
因此，可被监控和观测，也是我们开发软件时必须考虑的一环。
1.2．监控架构分类 ★
1.1.1. metrics（指标）
定义：可进行聚合计算的原子型数据，通常通过多个标签值来确定指标唯一性。
特点：指标数据仅记录时间戳和对应的指标数值，通常存储在时间序列数据库中（tsdb），存储成本低，可用于渲染趋势图或柱状图，可灵活配置告警规则，对故障进行快速发现和响应；但是不适合用于定位故障原因。
实现方案：zabbix、open-falcon、prometheus
1.1.2. logging（日志）
定义：离散事件，是系统运行时发生的一个个事件的记录。
特点：日志数据可以记录详细的信息（请求响应参数、自定义文字描述、异常信息、时间戳等），一般用于排查具体问题；日志通常存储在文件中，数据非结构化，存储成本高，不适合作为监控数据的来源。
实现方案：elk、loki
1.1.3. tracing（链路）
定义：基于特定请求作用域下的所有调用信息。
特点：一般需要依赖第三方存储，在微服务中一般有多个调用信息，如从网关开始，a服务调用b服务，调用数据库、缓存等。在链路系统中，需要清楚展现某条调用链中从主调方到被调方内部所有的调用信息。不仅有利于梳理接口及服务间调用的关系，还有助于排查慢请求或故障产生的原因。
实现方案：jaeger、zipkin、skywalking
1.3. 指标监控发展史
1.3.1. zabbix
企业级的开源解决方案，擅长设备、网络、中间件的监控。
优点：
平台兼容性好，可运行在 windows、linux、solaris、aix、os x等平台上；
架构简单，易于维护、备份。
缺点：
使用数据库存储，无法水平扩展，容量有限；
面向资产管理的逻辑，使得监控指标的数据结构固化，没有灵活的标签设计，无法适应云原生架构下动态多变的环境。
1.3.2. open-falcon
open-falcon 最初来自小米，14 年开源，当时小米有 3 套 zabbix，1 套业务性能监控系统 perfcounter。open-falcon 的初衷是想做一套大一统的方案，来解决这个乱局。
优点：
比zabbix容量大得多，不仅可以处理设备、中间件层面监控，还可以处理应用层面监控；
go语言开发，易于二次开发。
缺点：
组件拆分比较散，部署相对比较麻烦；
生态不够庞大，开源软件的治理架构不够优秀。
1.3.3. prometheus
prometheus 的设计思路来自borgmon，就像 borgmon 是为 borg 而生的，而 prometheus 就是为 kubernetes 而生的。提供了多种服务发现机制，大幅简化了 kubernetes 的监控。
prometheus2.0版本开始，重新设计了时序库，性能和可靠性都大幅提升。
优点：
对 kubernetes 支持很好，prometheus 是云原生架构下监控的标配；
生态庞大，有各种各样的 exporter，支持各种各样的时序库作为后端的备用存储，也有很好的支持多种不同语言的 sdk，供业务代码嵌入埋点。
缺点：
设置数据采集和告警策略需要修改配置文件，协同起来比较麻烦。
exporter 参差不齐，通常是一个监控目标一个 exporter，管理成本较高。
1.4. 指标监控典型架构 ★
1.4.1. 采集器 ★
有两种典型的部署方式，一种是跟随监控对象部署，比如所有的机器上都部署一个采集器，采集机器的 cpu、内存、硬盘、io、网络相关的指标；另一种是远程探针式，比如选取一个中心机器做探针，同时探测很多个机器的 ping 连通性，或者连到很多 mysql 实例上去，执行命令采集数据。
telegraf：
influxdata 公司的产品，主要配合 influxdb 使用。telegraf 也可以把监控数据推给 prometheus存储；
telegraf 是指标领域的 all-in-one 采集器，支持各种采集插件，只需要使用这一个采集器，就能解决绝大部分采集需求；
telegraf 采集的很多数据都是字符串类型，但如果把这类数据推给 prometheus 生态的时序库，比如 victoriametrics、m3db、thanos 等，它就会报错
exporter：
exporter是专门用于prometheus 生态的采集器，但是比较零散，每个采集目标都有对应的 exporter 组件，比如 mysql 有 mysqld_exporter，redis 有 redis_exporter，jvm 有 jmx_exporter。
exporter 的核心逻辑，就是去这些监控对象里采集数据，然后暴露为 prometheus 协议的监控数据。比如 mysqld_exporter，就是连上 mysql，执行一些类似于 show global status 、show global variables 、show slave status 这样的命令，拿到输出，再转换为 prometheus 协议的数据；
很多中间件都内置支持了 prometheus，直接通过自身的 /metrics 接口暴露监控数据，不用再单独伴生 exporter；比如 kubernetes 中的各类组件，比如 etcd，还有新版本的 zookeeper、 rabbitmq；
不管是exporter还是支持prometheus协议的各类组件，都是提供 http 接口（通常是 /metrics ）来暴露监控数据，让监控系统来拉，这叫做 pull 模型。
grafana-agent：
grafana 公司推出的一款 all-in-one 采集器，不但可以采集指标数据，也可以采集日志数据和链路数据。
如何快速集成各类采集能力的呢？grafana-agent 写了个框架，方便导入各类 exporter，把各个 exporter 当做 lib 使用，常见的 node-exporter、kafka-exporter、elasticsearch-exporter、mysqld-exporter 等，都已经完成了集成。对于默认没有集成进去的 exporter，grafana-agent 也支持用 pull 的方式去抓取其他 exporter 的数据，然后再通过 remote write 的方式，将采集到的数据转发给服务端。
很多时候，一个采集器可能搞不定所有业务需求，使用一款主力采集器，辅以多款其他采集器是大多数公司的选择。
1.4.2. 时序库
prometheus tsdb
prometheus本地存储经历过多个迭代：v1.0（2012年）、v2.0（2015年）、v3.0（2017年）。最初借用第三方数据库leveldb，1.0版本性能不高，每秒只能存储5w个样本；2.0版本借鉴了facebook gorilla压缩算法，将每个时序数据以单个文件方式保存，将性能提升到每秒存储8w个样本；2017年开始引入时序数据库的3.0版本，并成立了prometheus tsdb开源项目，该版本在单机上提高到每秒存储百万个样本。
3.0版本保留了2.0版本高压缩比的分块保存方式，并将多个分块保存到一个文件中，通过创建一个索引文件避免产生大量的小文件；同时为了防止数据丢失，引入了wal机制。
influxdb
influxdb 针对时序存储场景专门设计了存储引擎、数据结构、存取接口，国内使用范围比较广泛，可以和 grafana、telegraf 等良好整合，生态是非常完备的。
不过 influxdb 开源版本是单机的，没有开源集群版本。
m3db
m3db 是 uber 的时序数据库，m3 在 uber 抗住了 66 亿监控指标，这个量非常庞大。其主要包括4个组件：m3db、m3 coordinator、m3 query、m3 aggregator，我们当前产品中prometheus的远程存储就是通过m3db实现的。
1.4.3. 告警引擎 ★
用户会配置数百甚至数千条告警规则，一些超大型的公司可能要配置数万条告警规则。每个规则里含有数据过滤条件、阈值、执行频率等，有一些配置丰富的监控系统，还支持配置规则生效时段、持续时长、留观时长等。
告警引擎通常有两种架构，一种是数据触发式，一种是周期轮询式。
数据触发式，是指服务端接收到监控数据之后，除了存储到时序库，还会转发一份数据给告警引擎，告警引擎每收到一条监控数据，就要判断是否关联了告警规则，做告警判断。因为监控数据量比较大，告警规则的量也可能比较大，所以告警引擎是会做分片部署的，这样的架构，即时性很好，但是想要做指标关联计算就很麻烦，因为不同的指标哈希后可能会落到不同的告警引擎实例。
周期轮询式，通常是一个规则一个协程，按照用户配置的执行频率，周期性查询判断即可，做指标关联计算就会很容易。像 prometheus、nightingale、grafana 等，都是这样的架构。
生成事件之后，通常是交给一个单独的模块来做告警发送，这个模块负责事件聚合、收敛，根据不同的条件发送给不同的接收者和不同的通知媒介。
1.4.4. 数据展示
监控数据的可视化也是一个非常通用且重要的需求，业界做得最成功的是grafana，采用插件式架构，可以支持不同类型的数据源，图表非常丰富，基本是开源领域的事实标准。
02prometheus入门
导读：本章首先介绍了prometheus主要特点，然后根据特点对其局限性及架构进行剖析。读完本章，可以让读者清晰地了解如何运用prometheus。
2.1．主要特点
promql多维度数据模型的灵活查询；
定义了开放指标数据的标准，自定义探针（exporter等）；
go语言编写，拥抱云原生；
数据采集方式以pull为主、push为辅；
二进制文件直接启动、也支持容器镜像化部署；
支持多种语言客户端；
支持本地和第三方远程存储、高效的存储；
可扩展，功能分区+联邦集群；
结合grafana可以做到出色的可视化功能；
精确告警：基于promql可以进行告警设置、预测等；另外还提供了分组、抑制、静默等功能防止告警风暴；
支持动态发现机制：kubernetes；
2.2. 局限性
主要针对性能和可用性监控，不适用日志、事件、调用链等监控；
关注近期发生的事，而不是跟踪数周或数月的数据，监控数据默认保留15天；
本地存储有限，存储大量历史数据需要对接第三方远程存储；
采用联邦集群方式时，没有提供统一的全局视图。
2.3. 架构剖析 ★
job/exporter
prometheus监控探针，共收录有上千种exporter，用于对第三方系统进行监控，方式是获取第三方系统的监控数据然后按照prometheus的格式暴露出来；没有exporter探针的第三方系统也可以自己定制开发。
不过exporter种类繁多会导致维护压力大，也可以考虑用influx data公司开源的telegraf统一进行管理。使用telegraf集成prometheus比单独使用prometheus拥有更低的内存使用率和cpu使用率。
pushgateway
是支持临时性job主动推送指标的中间网关。
使用场景：临时/短作业、批处理作业、应用程序与prometheus之间有防火墙或不在同一个网段；
不过该解决方案存在单点故障问题、必须使用pushgateway的api从推送网关中删除过期指标。
service discovery（服务发现机制）
可以使用kubernetes的api获取容器信息的变化来动态更新监控对象；
prometheus server（核心监控服务）
i. retrieval（抓取）
从job、exporter、pushgateway3个组件中通过http轮询的形式拉取指标数据；
ii. storage（存储）
本地存储：直接保存到本地磁盘，从性能上考虑，建议使用ssd且不要保存超过一个月的数据；
远程存储：适用于存储大量监控数据，支持的远程存储包括opentsdb、influxdb、m3db、postgresql等；需要配合中间层适配器进行转换；
iii. promql（查询）
多维度数据模型的灵活查询。
dashboard（可视化）
实际工作中使用grafana，也可以调用http api发送请求获取数据；
alertmanager（告警引擎）
独立的告警组件，可以将多个alertmanager配置成集群，支持集群内多个实例间通信；
03promql入门
导读：本章围绕promql基本概念、4大选择器、4大指标类型及13种聚合操作等展开介绍，帮助读者轻松理解promql相关知识。
3.1. 初识promql ★
3.1.1. 时间序列 ★
按照一定的时间间隔产生的一个个数据点，这些数据点按照时间戳和值的生成顺序存放，得到了向量（vector）。
每条时间序列是通过指标名称和一组标签集来命名的。
矩阵中每一个点都可以称之为一个样本（sample），主要有3方面构成：
指标（metrics）：包括指标名称（__name__）和一组标签集名称；
时间戳（timestamp）：默认精确到毫秒；
样本值（value）：默认使用64位浮点类型。
3.1.2. 指标 ★
时间序列的指标可以基于bigtable设计为key-value存储的方式：
prometheus的metrics可以有两种表现方式（指标名称只能由ascii字符、数字、下划线、冒号组成，冒号用来表示用户自定义的记录规则）：
分别对应的查询形式（以下两个查询语句等价）：
3.2. 4大选择器
3.2.1. 匹配器
相等匹配器（=）：对于不存在的标签可以使用label=的形式查询
不等匹配器（!=）：相等匹配器的否定
正则表达式匹配器（=~）：前面或者后面加上.*
所有promql语句必须包含至少一个有效表达式（至少一个不会匹配到空字符串的标签过滤器），因此，以下三种示例是非法的：
正则表达式相反匹配器（!~）：正则表达式匹配器的否定
3.2.2. 瞬时向量选择器
用于返回在指定时间戳之前查询到的最新样本的瞬时向量。
3.2.3. 区间向量选择器
高级应用：
3.2.4. 偏移量修改器
瞬时偏移向量
高级应用：
3.3. 4大指标类型 ★
3.3.1. 计数器（counter）★
只增不减，一般配合rate（统计时间区间内增长速率）、topk（统计top n的数据）、increase等函数使用；
increase(v range-vector)获取区间向量的第一个和最后一个样本并返回其增长量：
为什么increase函数算出来的值非33？真实计算公式：(360 - 327) / (1687922987 - 1687922882) * 120 = 37.71428571428571
irate(v range-vector)是针对长尾效应专门提供的用于计算区间向量的增长速率的函数，反应的是瞬时增长率，敏感度更高。长期趋势分析或告警中更推荐rate函数。
rate(v range-vector) 求取的是每秒变化率，也有数据外推的逻辑，increase 的结果除以 range-vector 的时间段的大小，就是 rate 的值。
rate(jvm_memory_used_bytes{id=ps eden space}[1m]) 与 increase(jvm_memory_used_bytes{id=ps eden space}[1m])/60.0 是等价的
3.3.2. 仪表盘（gauge） ★
表示样本数据可任意增减的指标；实际更多用于求和、取平均值、最大值、最小值。
without可以让sum函数根据相同的标签进行求和，但是忽略掉without函数覆盖的标签；如上图，可以忽略掉id，只按照堆/非堆的区别进行内存空间求和。
3.3.3. 直方图（histogram） ★
用于描述数据分布，最典型的应用场景就是监控延迟数据，计算 90 分位、99 分位的值。
有些服务访问量很高，每秒几百万次，如果要把所有请求的延迟数据全部拿到，排序之后再计算分位值，这个代价就太高了。使用 histogram 类型，可以用较小的代价计算一个大概值。
prometheus的histogram类型计算原理：bucket桶排序+假定桶内数据均匀分布。
histogram 这种做法性能有了巨大的提升，但是要同时计算成千上万个接口的分位值延迟数据，还是非常耗费资源的，甚至会造成服务端 oom。
数据解析：http://ip:9090/metrics prometheus_http_request_duration_seconds
3.3.4. 汇总（summary） ★
在客户端计算分位值，然后把计算之后的结果推给服务端存储，展示的时候直接查询即可。
summary 的计算是在客户端计算的，也就意味着不是全局（整个服务）的分位值，分位值延迟数据是进程粒度的。
负载均衡会把请求均匀地打给后端的多个实例。一个实例内部计算的分位值，理论上和全局计算的分位值差别不会很大。另外，如果某个实例有故障，比如硬盘问题，导致落在这个实例的请求延迟大增，我们在实例粒度计算的延迟数据反而更容易发现问题。
数据解析：http://ip:9090/metrics go_gc_duration_seconds
3.4. 13种聚合操作
without 和 by 用来保留不同维度的可选操作符，其余11个聚合操作都是用于瞬时向量，使用相同的分组逻辑：
sum
min
max
avg
count
count_values（对value进行计数）
stddev（标准差）
stdvar（标准差异）
bottomk（样本值最小k个元素）
topk（样本值最大k个元素）
quantile（分布统计）
3.4.1. without、by ★
上述两个查询是等价的；同一个聚合语句中不可同时使用by和without，by的作用类似于sql语句中的分组（group by），without语义是：除开xx标签，对剩下的标签进行分组。
3.4.2. stdvar
数学中称为方差，用于衡量一组数据的离散程度：数据分布得越分散，各个数据与平均数的差的平方和越大，方差就越大。
3.4.3. stddev
标准差：用方差开算术平方根。
3.4.4. count、count_values
count：对分组中时间序列的数目进行求和
count_values：表示时间序列中每一个样本值（value）出现的次数，实践中一般用于统计版本号。
3.4.5. quantile
用于计算当前样本数据值的分布情况，例如计算一组http请求次数的中位数：
3.5. 3种二元操作符
3.5.1. 算术运算符（加减乘除模幂）
3.5.2. 集合/逻辑运算符
仅用于瞬时向量之间，and（并且）、or（或者）、unless（排除）
内置函数absent扮演了not的角色；
absent应用场景，配置告警规则：
3.5.3. 比较运算符（== != > = 0, tf 3
4.1.6. 时间聚合函数
4.2. http api ★
4.2.1. api响应格式
调用成功会返回2xx状态码
resulttype: matrix(区间向量) | vector(瞬时向量) | scalar | string
4.2.2. 表达式查询
/api/v1/query（瞬时数据查询）
入参：promql表达式、时间戳、超时设置（可全局设置）
/api/v1/query_range（区间数据查询）
入参：promql表达式、起始时间戳、结束时间戳、查询时间步长（不能超过11000）、超时设置（可全局设置）
4.2.3. 其他拓展
/api/v1/targets（获取监控对象列表）
/api/v1/rules（获取告警规则数据）
/api/v1/alerts（获取告警列表）
/api/v1/alertmanagers（获取关联的告警引擎）
/api/v1/targets/metadata（获取监控对象元数据）
/api/v1/metadata（获取指标元数据）
/status（prometheus配置、版本等数据）
tsdb管理api
启动参数带上--web.enable-admin-api
执行以下命令可对数据库进行备份：
curl -x post http://your_ip:9090/api/v1/admin/tsdb/snapshot
备份目录：/prometheus/data/snapshot
删除序列：
http://your_ip:9090/api/v1/admin/tsdb/delete_series
释放空间：http://your_ip:9090/api/v1/admin/tsdb/clean_tombstones
4.3. 可定期执行的规则
4.3.1. 记录规则
预先计算经常需要用到的或计算量较大的表达式，并将结果保存为一组新的时间序列。
4.3.2. 告警规则
4.4. 指标的抓取与存储 ★
抓取前依赖服务发现，通过relabel_configs的方式自动对服务发现的目标进行重新标记；
抓取后主要指标保存在存储系统之前，依赖作业内的metrics_relabel_configs实现。
4.4.1. 用relabel_configs抓取指标 ★
重写instance实现告警同时显示服务名+ip端口
4.4.2. 用metrics_relabel_configs抓取指标将监控不需要的数据直接丢掉，不在prometheus保存，配置方法类似。
05告警引擎深度解析
导读：本章拓展了alertmanager架构解析、alertmanager配置文件、告警应用与问题处理等众多知识点。
5.1. alertmanager架构解析 ★
从左上开始，prometheus 发送的警报到 alertmanager;
警报会被存储到 alertprovider 中，alertmanager 的内置实现就是包了一个 map，也就是存放在本机内存中，这里可以很容易地扩展其它 provider;
dispatcher 是一个单独的 goroutine，它会不断到 alertprovider 拉新的警报，并且根据 yaml 配置的 routing tree 将警报路由到一个分组中;
分组会定时进行 flush (间隔为配置参数中的 group_interval), flush 后这组警报会走一个 notification pipeline 链式处理;
notification pipeline 为这组警报确定发送目标，并执行抑制逻辑，静默逻辑，发送与重试逻辑，实现警报的最终投递;
5.2. alertmanager配置文件解读 ★
全局配置（global）：定义一些全局的公共参数，如全局smtp设置、slack配置等；
模板（template）：定义告警通知的模板，如html模板、邮件模板；
告警路由（route）：告警的分组聚合，根据自定义标签匹配，确定当前告警应该如何处理；
接收者（receivers）：邮箱、webhook等，一般配合告警路由使用；
抑制规则（inhibit_rules）：减少垃圾告警产生；
5.3. 关于告警的应用与问题处理 ★
关键配置参数：
prometheus.yml
scrape_interval：prometheus从采集器抓取数据间隔，默认1分钟；
scrape_timeout：数据抓取超时时间，默认10秒钟；
evaluation_interval：评估告警规则的时间间隔（即多长时间计算一次告警规则是否触发），默认1分钟；
alertmanager.yml
group_wait：初始等待时间，一组告警消息第一次发送前的等待时间，在这个时间内允许为同一组告警收集更多初始告警，此参数的作用是防止短时间内出现大量告警的情况下，接收者被消息淹没。【此参数建议设置为0到5分钟】。
group_interval：睡眠/唤醒周期，一组告警消息被成功发送后，会进入睡眠/唤醒周期，此参数是睡眠状态将持续的时间，在睡眠状态下该组消息可能会有明细内容变化。睡眠结束后进入唤醒状态，如果检查到有明细内容存在变化，则发送新告警消息；如果没有变化，则判断是否达到“重复发送间隔时间”来决定是否发送。【此参数建议设置为5到30分钟】。
repeat_interval：重复发送间隔时间，此参数是指同一个消息组在明细内容不变的情况下，连续多长时间不发送告警消息。不过此参数值并不代表告警的实际重复间隔，因为在上一次发送消息后并等待了“重复发送间隔时间”的时刻，该消息组可能处在睡眠状态；所以实际的告警间隔应该大于“重复发送间隔时间”且小于“重复发送间隔时间”与“睡眠/唤醒周期”之和。【此参数建议设置为3小时以上】。
06本地存储与远程存储
导读：本章主要分析了压缩算法、本地存储文件结构、存储原理、m3db远程存储技术，并对使用过程中可能出现的问题给出了指导和建议。
6.1. 压缩算法
lprometheus本地存储经历过多个迭代：v1.0（2012年）、v2.0（2015年）、v3.0（2017年）。最初借用第三方数据库leveldb，1.0版本性能不高，每秒只能存储5w个样本；2.0版本借鉴了facebook gorilla压缩算法，将每个时序数据以单个文件方式保存，将性能提升到每秒存储8w个样本；2017年开始引入时序数据库的3.0版本，并成立了prometheus tsdb开源项目，该版本在单机上提高到每秒存储百万个样本。
3.0版本保留了2.0版本高压缩比的分块保存方式，并将多个分块保存到一个文件中，通过创建一个索引文件避免产生大量的小文件；同时为了防止数据丢失，引入了wal机制。
6.2. 本地存储文件结构解析
6.3. 存储原理解析
按时间顺序生成多个block文件，其中第一个block称为head block，存储在内存中且允许被修改，其它block文件则以只读的方式持久化在磁盘上。
抓取数据时，prometheus周期性的将监控数据以chunk的形式添加到head block中，同时写日志。会按2小时一个block的速率进行磁盘持久化。
崩溃后再次启动会以写入日志的方式实现重播，从而恢复数据。
2小时的block会在后台压缩成更大的block，数据被压缩合并成更高级别的block文件后删除低级别的block文件。
6.4. m3db远程存储技术
6.4.1. m3特性
主要包括4个组件：m3db、m3 coordinator、m3 query、m3 aggregator
m3db：分布式时序库，为时间序列数据和反向索引提供了可伸缩、可扩展的存储。
m3 coordinator：辅助服务，用于协调上游系统（如prometheus和m3db）之间的读写操作，是用户访问m3db的桥梁。
m3 query：分布式查询引擎，可查询实时和历史指标，支持多种不同的查询语言（包括promql）。
m3 aggregator：聚合层，作为专用度量聚合器运行的服务。
6.4.2. m3db特性
分布式时间序列存储，单个节点使用wal提交日志并独立保存每个分片的时间窗口。
集群管理建立在etcd之上（分布式服务注册中心）。
内置同步复制功能，具有可配置的持久性和读取一致性。
自定义压缩算法m3tsz float64。
6.4.3. m3db限制
m3db主要是为了减少摄取和存储数十亿个时间序列的成本并提供快速可伸缩的读取，因此存在一些限制，不适合用作通用时序库。
m3db旨在尽可能避免压缩，目前m3db仅在可变压缩时间序列窗口内执行压缩，因此乱序写入仅限单个压缩时间序列窗口的大小。
m3db针对float64值的存储和检索进行优化，无法将其用作包含任意数据结构的通用时序库。
6.4.4. m3db分布式架构
coordinator：m3coordinator用于协调群集中所有主机之间的读取和写入。这是一个轻量级的过程，不存储任何数据。该角色通常将与prometheus实例一起运行。
storage node：在这些主机上运行的m3dbnode进程是数据库的主力，它们存储数据，并提供读写功能。
seed node：首先，这些主机本身就是存储节点。除了该职责外，他们还运行嵌入式etcd服务器。这是为了允许跨集群运行的各种m3db进程以一致的方式推断集群的拓扑/配置。
07梯度运维管理平台监控模块架构 ★
人工智能怎样进军心理学领域
物联网解决方案可以为餐馆业务带来哪些便利
热敏电阻介绍及应用
终于有本书讲清了ChatGPT和AIGC的前世今生！
直线模组3D打印技术助力生产电动汽车电池
Prometheus的基本原理与开发指南
广州大气候农业科技有限公司宣布即将上线垂直农业电商平台：农眼溯源店
传感器改善货运的4种惊人方式
认识变压器、电抗器
液冷集装箱式储能系统设计
安森美电感式位置感测新方法加快上市时间
4k算什么？听说蓝相LCD技术让VR分辨率更进一步
以太坊创造者推出最小分片协议可以帮助区块链扩大容量
直流屏的安装及其调试步骤教程
思博伦提供完整LTE定位测试方案
中国集成电路与国外发展的三大差距
基于PLC控制的新型手持操作器设计 支持无线遥控操作
VR设备的主要三种传感器类型
单键低功耗触摸芯片VKD233HH介绍
瑞萨电子通过数字控制器来简化工业控制的电源设计
本文由梯度科技云管研发部高级工程师周宇明撰写，共分为7章，紧密围绕prometheus的基本原理与开发指南展开介绍：
监控系统概述
prometheus入门
promql入门
promql高级实战
告警引擎深度解析
本地存储与远程存储
梯度运维管理平台监控模块架构
01监控系统概述
导读：本章从监控的作用、架构分类、指标监控发展史、指标监控典型架构等4个方面介绍监控系统的相关概念。
1.1．监控的作用 ★
为了构建稳定性保障体系，核心就是在干一件事：减少故障。
减少故障有两个层面的意思，一个是做好常态预防，不让故障发生；另一个是如果故障发生，要能尽快止损，减少故障时长，减小故障影响范围。监控的典型作用就是帮助我们发现及定位故障。
监控的其他作用：日常巡检、性能调优的数据佐证、提前发现一些不合理的配置。
之所以能做到这些，是因为所有优秀的软件，都内置了监控数据的暴露方法，让用户可以对其进行观测，了解其健康状况：比如各类开源组件，有的是直接暴露了 prometheus metrics 接口，有的是暴露了 http json 接口，有的是通过 jmx 暴露监控数据，有的则需要连上去执行命令。另外，所有软件都可以使用日志的方式来暴露健康状况。
因此，可被监控和观测，也是我们开发软件时必须考虑的一环。
1.2．监控架构分类 ★
1.1.1. metrics（指标）
定义：可进行聚合计算的原子型数据，通常通过多个标签值来确定指标唯一性。
特点：指标数据仅记录时间戳和对应的指标数值，通常存储在时间序列数据库中（tsdb），存储成本低，可用于渲染趋势图或柱状图，可灵活配置告警规则，对故障进行快速发现和响应；但是不适合用于定位故障原因。
实现方案：zabbix、open-falcon、prometheus
1.1.2. logging（日志）
定义：离散事件，是系统运行时发生的一个个事件的记录。
特点：日志数据可以记录详细的信息（请求响应参数、自定义文字描述、异常信息、时间戳等），一般用于排查具体问题；日志通常存储在文件中，数据非结构化，存储成本高，不适合作为监控数据的来源。
实现方案：elk、loki
1.1.3. tracing（链路）
定义：基于特定请求作用域下的所有调用信息。
特点：一般需要依赖第三方存储，在微服务中一般有多个调用信息，如从网关开始，a服务调用b服务，调用数据库、缓存等。在链路系统中，需要清楚展现某条调用链中从主调方到被调方内部所有的调用信息。不仅有利于梳理接口及服务间调用的关系，还有助于排查慢请求或故障产生的原因。
实现方案：jaeger、zipkin、skywalking
1.3. 指标监控发展史
1.3.1. zabbix
企业级的开源解决方案，擅长设备、网络、中间件的监控。
优点：
平台兼容性好，可运行在 windows、linux、solaris、aix、os x等平台上；
架构简单，易于维护、备份。
缺点：
使用数据库存储，无法水平扩展，容量有限；
面向资产管理的逻辑，使得监控指标的数据结构固化，没有灵活的标签设计，无法适应云原生架构下动态多变的环境。
1.3.2. open-falcon
open-falcon 最初来自小米，14 年开源，当时小米有 3 套 zabbix，1 套业务性能监控系统 perfcounter。open-falcon 的初衷是想做一套大一统的方案，来解决这个乱局。
优点：
比zabbix容量大得多，不仅可以处理设备、中间件层面监控，还可以处理应用层面监控；
go语言开发，易于二次开发。
缺点：
组件拆分比较散，部署相对比较麻烦；
生态不够庞大，开源软件的治理架构不够优秀。
1.3.3. prometheus
prometheus 的设计思路来自borgmon，就像 borgmon 是为 borg 而生的，而 prometheus 就是为 kubernetes 而生的。提供了多种服务发现机制，大幅简化了 kubernetes 的监控。
prometheus2.0版本开始，重新设计了时序库，性能和可靠性都大幅提升。
优点：
对 kubernetes 支持很好，prometheus 是云原生架构下监控的标配；
生态庞大，有各种各样的 exporter，支持各种各样的时序库作为后端的备用存储，也有很好的支持多种不同语言的 sdk，供业务代码嵌入埋点。
缺点：
设置数据采集和告警策略需要修改配置文件，协同起来比较麻烦。
exporter 参差不齐，通常是一个监控目标一个 exporter，管理成本较高。
1.4. 指标监控典型架构 ★
1.4.1. 采集器 ★
有两种典型的部署方式，一种是跟随监控对象部署，比如所有的机器上都部署一个采集器，采集机器的 cpu、内存、硬盘、io、网络相关的指标；另一种是远程探针式，比如选取一个中心机器做探针，同时探测很多个机器的 ping 连通性，或者连到很多 mysql 实例上去，执行命令采集数据。
telegraf：
influxdata 公司的产品，主要配合 influxdb 使用。telegraf 也可以把监控数据推给 prometheus存储；
telegraf 是指标领域的 all-in-one 采集器，支持各种采集插件，只需要使用这一个采集器，就能解决绝大部分采集需求；
telegraf 采集的很多数据都是字符串类型，但如果把这类数据推给 prometheus 生态的时序库，比如 victoriametrics、m3db、thanos 等，它就会报错
exporter：
exporter是专门用于prometheus 生态的采集器，但是比较零散，每个采集目标都有对应的 exporter 组件，比如 mysql 有 mysqld_exporter，redis 有 redis_exporter，jvm 有 jmx_exporter。
exporter 的核心逻辑，就是去这些监控对象里采集数据，然后暴露为 prometheus 协议的监控数据。比如 mysqld_exporter，就是连上 mysql，执行一些类似于 show global status 、show global variables 、show slave status 这样的命令，拿到输出，再转换为 prometheus 协议的数据；
很多中间件都内置支持了 prometheus，直接通过自身的 /metrics 接口暴露监控数据，不用再单独伴生 exporter；比如 kubernetes 中的各类组件，比如 etcd，还有新版本的 zookeeper、 rabbitmq；
不管是exporter还是支持prometheus协议的各类组件，都是提供 http 接口（通常是 /metrics ）来暴露监控数据，让监控系统来拉，这叫做 pull 模型。
grafana-agent：
grafana 公司推出的一款 all-in-one 采集器，不但可以采集指标数据，也可以采集日志数据和链路数据。
如何快速集成各类采集能力的呢？grafana-agent 写了个框架，方便导入各类 exporter，把各个 exporter 当做 lib 使用，常见的 node-exporter、kafka-exporter、elasticsearch-exporter、mysqld-exporter 等，都已经完成了集成。对于默认没有集成进去的 exporter，grafana-agent 也支持用 pull 的方式去抓取其他 exporter 的数据，然后再通过 remote write 的方式，将采集到的数据转发给服务端。
很多时候，一个采集器可能搞不定所有业务需求，使用一款主力采集器，辅以多款其他采集器是大多数公司的选择。
1.4.2. 时序库
prometheus tsdb
prometheus本地存储经历过多个迭代：v1.0（2012年）、v2.0（2015年）、v3.0（2017年）。最初借用第三方数据库leveldb，1.0版本性能不高，每秒只能存储5w个样本；2.0版本借鉴了facebook gorilla压缩算法，将每个时序数据以单个文件方式保存，将性能提升到每秒存储8w个样本；2017年开始引入时序数据库的3.0版本，并成立了prometheus tsdb开源项目，该版本在单机上提高到每秒存储百万个样本。
3.0版本保留了2.0版本高压缩比的分块保存方式，并将多个分块保存到一个文件中，通过创建一个索引文件避免产生大量的小文件；同时为了防止数据丢失，引入了wal机制。
influxdb
influxdb 针对时序存储场景专门设计了存储引擎、数据结构、存取接口，国内使用范围比较广泛，可以和 grafana、telegraf 等良好整合，生态是非常完备的。
不过 influxdb 开源版本是单机的，没有开源集群版本。
m3db
m3db 是 uber 的时序数据库，m3 在 uber 抗住了 66 亿监控指标，这个量非常庞大。其主要包括4个组件：m3db、m3 coordinator、m3 query、m3 aggregator，我们当前产品中prometheus的远程存储就是通过m3db实现的。
1.4.3. 告警引擎 ★
用户会配置数百甚至数千条告警规则，一些超大型的公司可能要配置数万条告警规则。每个规则里含有数据过滤条件、阈值、执行频率等，有一些配置丰富的监控系统，还支持配置规则生效时段、持续时长、留观时长等。
告警引擎通常有两种架构，一种是数据触发式，一种是周期轮询式。
数据触发式，是指服务端接收到监控数据之后，除了存储到时序库，还会转发一份数据给告警引擎，告警引擎每收到一条监控数据，就要判断是否关联了告警规则，做告警判断。因为监控数据量比较大，告警规则的量也可能比较大，所以告警引擎是会做分片部署的，这样的架构，即时性很好，但是想要做指标关联计算就很麻烦，因为不同的指标哈希后可能会落到不同的告警引擎实例。
周期轮询式，通常是一个规则一个协程，按照用户配置的执行频率，周期性查询判断即可，做指标关联计算就会很容易。像 prometheus、nightingale、grafana 等，都是这样的架构。
生成事件之后，通常是交给一个单独的模块来做告警发送，这个模块负责事件聚合、收敛，根据不同的条件发送给不同的接收者和不同的通知媒介。
1.4.4. 数据展示
监控数据的可视化也是一个非常通用且重要的需求，业界做得最成功的是grafana，采用插件式架构，可以支持不同类型的数据源，图表非常丰富，基本是开源领域的事实标准。
02prometheus入门
导读：本章首先介绍了prometheus主要特点，然后根据特点对其局限性及架构进行剖析。读完本章，可以让读者清晰地了解如何运用prometheus。
2.1．主要特点
promql多维度数据模型的灵活查询；
定义了开放指标数据的标准，自定义探针（exporter等）；
go语言编写，拥抱云原生；
数据采集方式以pull为主、push为辅；
二进制文件直接启动、也支持容器镜像化部署；
支持多种语言客户端；
支持本地和第三方远程存储、高效的存储；
可扩展，功能分区+联邦集群；
结合grafana可以做到出色的可视化功能；
精确告警：基于promql可以进行告警设置、预测等；另外还提供了分组、抑制、静默等功能防止告警风暴；
支持动态发现机制：kubernetes；
2.2. 局限性
主要针对性能和可用性监控，不适用日志、事件、调用链等监控；
关注近期发生的事，而不是跟踪数周或数月的数据，监控数据默认保留15天；
本地存储有限，存储大量历史数据需要对接第三方远程存储；
采用联邦集群方式时，没有提供统一的全局视图。
2.3. 架构剖析 ★
job/exporter
prometheus监控探针，共收录有上千种exporter，用于对第三方系统进行监控，方式是获取第三方系统的监控数据然后按照prometheus的格式暴露出来；没有exporter探针的第三方系统也可以自己定制开发。
不过exporter种类繁多会导致维护压力大，也可以考虑用influx data公司开源的telegraf统一进行管理。使用telegraf集成prometheus比单独使用prometheus拥有更低的内存使用率和cpu使用率。
pushgateway
是支持临时性job主动推送指标的中间网关。
使用场景：临时/短作业、批处理作业、应用程序与prometheus之间有防火墙或不在同一个网段；
不过该解决方案存在单点故障问题、必须使用pushgateway的api从推送网关中删除过期指标。
service discovery（服务发现机制）
可以使用kubernetes的api获取容器信息的变化来动态更新监控对象；
prometheus server（核心监控服务）
i. retrieval（抓取）
从job、exporter、pushgateway3个组件中通过http轮询的形式拉取指标数据；
ii. storage（存储）
本地存储：直接保存到本地磁盘，从性能上考虑，建议使用ssd且不要保存超过一个月的数据；
远程存储：适用于存储大量监控数据，支持的远程存储包括opentsdb、influxdb、m3db、postgresql等；需要配合中间层适配器进行转换；
iii. promql（查询）
多维度数据模型的灵活查询。
dashboard（可视化）
实际工作中使用grafana，也可以调用http api发送请求获取数据；
alertmanager（告警引擎）
独立的告警组件，可以将多个alertmanager配置成集群，支持集群内多个实例间通信；
03promql入门
导读：本章围绕promql基本概念、4大选择器、4大指标类型及13种聚合操作等展开介绍，帮助读者轻松理解promql相关知识。
3.1. 初识promql ★
3.1.1. 时间序列 ★
按照一定的时间间隔产生的一个个数据点，这些数据点按照时间戳和值的生成顺序存放，得到了向量（vector）。
每条时间序列是通过指标名称和一组标签集来命名的。
矩阵中每一个点都可以称之为一个样本（sample），主要有3方面构成：
指标（metrics）：包括指标名称（__name__）和一组标签集名称；
时间戳（timestamp）：默认精确到毫秒；
样本值（value）：默认使用64位浮点类型。
3.1.2. 指标 ★
时间序列的指标可以基于bigtable设计为key-value存储的方式：
prometheus的metrics可以有两种表现方式（指标名称只能由ascii字符、数字、下划线、冒号组成，冒号用来表示用户自定义的记录规则）：
分别对应的查询形式（以下两个查询语句等价）：
3.2. 4大选择器
3.2.1. 匹配器
相等匹配器（=）：对于不存在的标签可以使用label=的形式查询
不等匹配器（!=）：相等匹配器的否定
正则表达式匹配器（=~）：前面或者后面加上.*
所有promql语句必须包含至少一个有效表达式（至少一个不会匹配到空字符串的标签过滤器），因此，以下三种示例是非法的：
正则表达式相反匹配器（!~）：正则表达式匹配器的否定
3.2.2. 瞬时向量选择器
用于返回在指定时间戳之前查询到的最新样本的瞬时向量。
3.2.3. 区间向量选择器
高级应用：
3.2.4. 偏移量修改器
瞬时偏移向量
高级应用：
3.3. 4大指标类型 ★
3.3.1. 计数器（counter）★
只增不减，一般配合rate（统计时间区间内增长速率）、topk（统计top n的数据）、increase等函数使用；
increase(v range-vector)获取区间向量的第一个和最后一个样本并返回其增长量：
为什么increase函数算出来的值非33？真实计算公式：(360 - 327) / (1687922987 - 1687922882) * 120 = 37.71428571428571
irate(v range-vector)是针对长尾效应专门提供的用于计算区间向量的增长速率的函数，反应的是瞬时增长率，敏感度更高。长期趋势分析或告警中更推荐rate函数。
rate(v range-vector) 求取的是每秒变化率，也有数据外推的逻辑，increase 的结果除以 range-vector 的时间段的大小，就是 rate 的值。
rate(jvm_memory_used_bytes{id=ps eden space}[1m]) 与 increase(jvm_memory_used_bytes{id=ps eden space}[1m])/60.0 是等价的
3.3.2. 仪表盘（gauge） ★
表示样本数据可任意增减的指标；实际更多用于求和、取平均值、最大值、最小值。
without可以让sum函数根据相同的标签进行求和，但是忽略掉without函数覆盖的标签；如上图，可以忽略掉id，只按照堆/非堆的区别进行内存空间求和。
3.3.3. 直方图（histogram） ★
用于描述数据分布，最典型的应用场景就是监控延迟数据，计算 90 分位、99 分位的值。
有些服务访问量很高，每秒几百万次，如果要把所有请求的延迟数据全部拿到，排序之后再计算分位值，这个代价就太高了。使用 histogram 类型，可以用较小的代价计算一个大概值。
prometheus的histogram类型计算原理：bucket桶排序+假定桶内数据均匀分布。
histogram 这种做法性能有了巨大的提升，但是要同时计算成千上万个接口的分位值延迟数据，还是非常耗费资源的，甚至会造成服务端 oom。
数据解析：http://ip:9090/metrics prometheus_http_request_duration_seconds
3.3.4. 汇总（summary） ★
在客户端计算分位值，然后把计算之后的结果推给服务端存储，展示的时候直接查询即可。
summary 的计算是在客户端计算的，也就意味着不是全局（整个服务）的分位值，分位值延迟数据是进程粒度的。
负载均衡会把请求均匀地打给后端的多个实例。一个实例内部计算的分位值，理论上和全局计算的分位值差别不会很大。另外，如果某个实例有故障，比如硬盘问题，导致落在这个实例的请求延迟大增，我们在实例粒度计算的延迟数据反而更容易发现问题。
数据解析：http://ip:9090/metrics go_gc_duration_seconds
3.4. 13种聚合操作
without 和 by 用来保留不同维度的可选操作符，其余11个聚合操作都是用于瞬时向量，使用相同的分组逻辑：
sum
min
max
avg
count
count_values（对value进行计数）
stddev（标准差）
stdvar（标准差异）
bottomk（样本值最小k个元素）
topk（样本值最大k个元素）
quantile（分布统计）
3.4.1. without、by ★
上述两个查询是等价的；同一个聚合语句中不可同时使用by和without，by的作用类似于sql语句中的分组（group by），without语义是：除开xx标签，对剩下的标签进行分组。
3.4.2. stdvar
数学中称为方差，用于衡量一组数据的离散程度：数据分布得越分散，各个数据与平均数的差的平方和越大，方差就越大。
3.4.3. stddev
标准差：用方差开算术平方根。
3.4.4. count、count_values
count：对分组中时间序列的数目进行求和
count_values：表示时间序列中每一个样本值（value）出现的次数，实践中一般用于统计版本号。
3.4.5. quantile
用于计算当前样本数据值的分布情况，例如计算一组http请求次数的中位数：
3.5. 3种二元操作符
3.5.1. 算术运算符（加减乘除模幂）
3.5.2. 集合/逻辑运算符
仅用于瞬时向量之间，and（并且）、or（或者）、unless（排除）
内置函数absent扮演了not的角色；
absent应用场景，配置告警规则：
3.5.3. 比较运算符（== != > = 0, tf 3
4.1.6. 时间聚合函数
4.2. http api ★
4.2.1. api响应格式
调用成功会返回2xx状态码
resulttype: matrix(区间向量) | vector(瞬时向量) | scalar | string
4.2.2. 表达式查询
/api/v1/query（瞬时数据查询）
入参：promql表达式、时间戳、超时设置（可全局设置）
/api/v1/query_range（区间数据查询）
入参：promql表达式、起始时间戳、结束时间戳、查询时间步长（不能超过11000）、超时设置（可全局设置）
4.2.3. 其他拓展
/api/v1/targets（获取监控对象列表）
/api/v1/rules（获取告警规则数据）
/api/v1/alerts（获取告警列表）
/api/v1/alertmanagers（获取关联的告警引擎）
/api/v1/targets/metadata（获取监控对象元数据）
/api/v1/metadata（获取指标元数据）
/status（prometheus配置、版本等数据）
tsdb管理api
启动参数带上--web.enable-admin-api
执行以下命令可对数据库进行备份：
curl -x post http://your_ip:9090/api/v1/admin/tsdb/snapshot
备份目录：/prometheus/data/snapshot
删除序列：
http://your_ip:9090/api/v1/admin/tsdb/delete_series
释放空间：http://your_ip:9090/api/v1/admin/tsdb/clean_tombstones
4.3. 可定期执行的规则
4.3.1. 记录规则
预先计算经常需要用到的或计算量较大的表达式，并将结果保存为一组新的时间序列。
4.3.2. 告警规则
4.4. 指标的抓取与存储 ★
抓取前依赖服务发现，通过relabel_configs的方式自动对服务发现的目标进行重新标记；
抓取后主要指标保存在存储系统之前，依赖作业内的metrics_relabel_configs实现。
4.4.1. 用relabel_configs抓取指标 ★
重写instance实现告警同时显示服务名+ip端口
4.4.2. 用metrics_relabel_configs抓取指标将监控不需要的数据直接丢掉，不在prometheus保存，配置方法类似。
05告警引擎深度解析
导读：本章拓展了alertmanager架构解析、alertmanager配置文件、告警应用与问题处理等众多知识点。
5.1. alertmanager架构解析 ★
从左上开始，prometheus 发送的警报到 alertmanager;
警报会被存储到 alertprovider 中，alertmanager 的内置实现就是包了一个 map，也就是存放在本机内存中，这里可以很容易地扩展其它 provider;
dispatcher 是一个单独的 goroutine，它会不断到 alertprovider 拉新的警报，并且根据 yaml 配置的 routing tree 将警报路由到一个分组中;
分组会定时进行 flush (间隔为配置参数中的 group_interval), flush 后这组警报会走一个 notification pipeline 链式处理;
notification pipeline 为这组警报确定发送目标，并执行抑制逻辑，静默逻辑，发送与重试逻辑，实现警报的最终投递;
5.2. alertmanager配置文件解读 ★
全局配置（global）：定义一些全局的公共参数，如全局smtp设置、slack配置等；
模板（template）：定义告警通知的模板，如html模板、邮件模板；
告警路由（route）：告警的分组聚合，根据自定义标签匹配，确定当前告警应该如何处理；
接收者（receivers）：邮箱、webhook等，一般配合告警路由使用；
抑制规则（inhibit_rules）：减少垃圾告警产生；
5.3. 关于告警的应用与问题处理 ★
关键配置参数：
prometheus.yml
scrape_interval：prometheus从采集器抓取数据间隔，默认1分钟；
scrape_timeout：数据抓取超时时间，默认10秒钟；
evaluation_interval：评估告警规则的时间间隔（即多长时间计算一次告警规则是否触发），默认1分钟；
alertmanager.yml
group_wait：初始等待时间，一组告警消息第一次发送前的等待时间，在这个时间内允许为同一组告警收集更多初始告警，此参数的作用是防止短时间内出现大量告警的情况下，接收者被消息淹没。【此参数建议设置为0到5分钟】。
group_interval：睡眠/唤醒周期，一组告警消息被成功发送后，会进入睡眠/唤醒周期，此参数是睡眠状态将持续的时间，在睡眠状态下该组消息可能会有明细内容变化。睡眠结束后进入唤醒状态，如果检查到有明细内容存在变化，则发送新告警消息；如果没有变化，则判断是否达到“重复发送间隔时间”来决定是否发送。【此参数建议设置为5到30分钟】。
repeat_interval：重复发送间隔时间，此参数是指同一个消息组在明细内容不变的情况下，连续多长时间不发送告警消息。不过此参数值并不代表告警的实际重复间隔，因为在上一次发送消息后并等待了“重复发送间隔时间”的时刻，该消息组可能处在睡眠状态；所以实际的告警间隔应该大于“重复发送间隔时间”且小于“重复发送间隔时间”与“睡眠/唤醒周期”之和。【此参数建议设置为3小时以上】。
06本地存储与远程存储
导读：本章主要分析了压缩算法、本地存储文件结构、存储原理、m3db远程存储技术，并对使用过程中可能出现的问题给出了指导和建议。
6.1. 压缩算法
lprometheus本地存储经历过多个迭代：v1.0（2012年）、v2.0（2015年）、v3.0（2017年）。最初借用第三方数据库leveldb，1.0版本性能不高，每秒只能存储5w个样本；2.0版本借鉴了facebook gorilla压缩算法，将每个时序数据以单个文件方式保存，将性能提升到每秒存储8w个样本；2017年开始引入时序数据库的3.0版本，并成立了prometheus tsdb开源项目，该版本在单机上提高到每秒存储百万个样本。
3.0版本保留了2.0版本高压缩比的分块保存方式，并将多个分块保存到一个文件中，通过创建一个索引文件避免产生大量的小文件；同时为了防止数据丢失，引入了wal机制。
6.2. 本地存储文件结构解析
6.3. 存储原理解析
按时间顺序生成多个block文件，其中第一个block称为head block，存储在内存中且允许被修改，其它block文件则以只读的方式持久化在磁盘上。
抓取数据时，prometheus周期性的将监控数据以chunk的形式添加到head block中，同时写日志。会按2小时一个block的速率进行磁盘持久化。
崩溃后再次启动会以写入日志的方式实现重播，从而恢复数据。
2小时的block会在后台压缩成更大的block，数据被压缩合并成更高级别的block文件后删除低级别的block文件。
6.4. m3db远程存储技术
6.4.1. m3特性
主要包括4个组件：m3db、m3 coordinator、m3 query、m3 aggregator
m3db：分布式时序库，为时间序列数据和反向索引提供了可伸缩、可扩展的存储。
m3 coordinator：辅助服务，用于协调上游系统（如prometheus和m3db）之间的读写操作，是用户访问m3db的桥梁。
m3 query：分布式查询引擎，可查询实时和历史指标，支持多种不同的查询语言（包括promql）。
m3 aggregator：聚合层，作为专用度量聚合器运行的服务。
6.4.2. m3db特性
分布式时间序列存储，单个节点使用wal提交日志并独立保存每个分片的时间窗口。
集群管理建立在etcd之上（分布式服务注册中心）。
内置同步复制功能，具有可配置的持久性和读取一致性。
自定义压缩算法m3tsz float64。
6.4.3. m3db限制
m3db主要是为了减少摄取和存储数十亿个时间序列的成本并提供快速可伸缩的读取，因此存在一些限制，不适合用作通用时序库。
m3db旨在尽可能避免压缩，目前m3db仅在可变压缩时间序列窗口内执行压缩，因此乱序写入仅限单个压缩时间序列窗口的大小。
m3db针对float64值的存储和检索进行优化，无法将其用作包含任意数据结构的通用时序库。
6.4.4. m3db分布式架构
coordinator：m3coordinator用于协调群集中所有主机之间的读取和写入。这是一个轻量级的过程，不存储任何数据。该角色通常将与prometheus实例一起运行。
storage node：在这些主机上运行的m3dbnode进程是数据库的主力，它们存储数据，并提供读写功能。
seed node：首先，这些主机本身就是存储节点。除了该职责外，他们还运行嵌入式etcd服务器。这是为了允许跨集群运行的各种m3db进程以一致的方式推断集群的拓扑/配置。
07梯度运维管理平台监控模块架构 ★
人工智能怎样进军心理学领域
物联网解决方案可以为餐馆业务带来哪些便利
热敏电阻介绍及应用
终于有本书讲清了ChatGPT和AIGC的前世今生！
直线模组3D打印技术助力生产电动汽车电池
Prometheus的基本原理与开发指南
广州大气候农业科技有限公司宣布即将上线垂直农业电商平台：农眼溯源店
传感器改善货运的4种惊人方式
认识变压器、电抗器
液冷集装箱式储能系统设计
安森美电感式位置感测新方法加快上市时间
4k算什么？听说蓝相LCD技术让VR分辨率更进一步
以太坊创造者推出最小分片协议可以帮助区块链扩大容量
直流屏的安装及其调试步骤教程
思博伦提供完整LTE定位测试方案
中国集成电路与国外发展的三大差距
基于PLC控制的新型手持操作器设计 支持无线遥控操作
VR设备的主要三种传感器类型
单键低功耗触摸芯片VKD233HH介绍
瑞萨电子通过数字控制器来简化工业控制的电源设计