关于开源协议:一些由-Prometheus-引出的闲言碎语

普罗米修斯是谁？

From Wikipedia：在希腊神话中，是泰坦神族的神明之一，名字的意思是“先见之明”。普罗米修斯与智慧女神雅典娜独特发明了人类，普罗米修斯负责用泥土雕塑出人的形态，雅典娜则为泥人灌注灵魂，并教会了人类很多常识。

Prometheus 是什么？

Prometheus 是一个由 SoundCloud 公司开发并开源的监控和告警工具。次要性能包含监控指标的收集，存储，查问以及以此为根底的告警治理，其外部蕴含一个用来存储指标的单机时序数据库。它的开发受到了 Google 外部监控零碎 Borgmon 的启发。

Borgman 的特点是不应用特定的脚本来判断零碎是否失常工作，而是依附一种规范数据分析模型进行报警。这使得批量、大规模、低成本的数据收集变得可能，而不须要执行简单的子过程以及建设非凡的网络链接。

利用 Prometheus 和主动服务发现，咱们能够采纳 pull mode 而不是 push mode 来收集服务的指标，pull mode 对于服务端的实现老本更低。

闲言：一个零碎是采纳 pull mode 还是 push mode 是很值得思考的问题。pull mode 的实现可能更简略，数据的提供方只须要被动的期待数据的需求方来拉取数据就能够了，缩小了很多 sync 的工作，然而因为会在 pipeline 产生 bubble，性能可能会不好。而 push mode 会使 pipeline 开足马力运行，会带来更好的性能，但同时会减少零碎设计的复杂度，比方 sync，retry 等工作。

为什么要监控

Google SRE 这本书中介绍次要有四个起因：

1. 剖析长期趋势
2. 跨工夫范畴的比拟
3. 构建监控页面
4. 临时性的回溯剖析（在线调试）

四个黄金指标

同样来自 Google SRE 一书：

1. 提早

​ 服务解决某个申请所须要的工夫。须要辨别胜利申请和失败申请很重要。2

2. 流量

​ 应用零碎中的某个高层次的指标针对零碎负载进行的度量。

3. 谬误

​ 申请失败的频率，能够是显示失败（例如 HTTP 500），隐式失败（例如 HTTP 200 然而蕴含了谬误内容）或者是某种策略起因导致的失败（例如响应超时）

4. 饱和度

​ 掂量服务容量有多“满”，通常是零碎中最为受限的某种资源的某个具体指标的度量（比方内存，IO）。

碎语：一本好书

Prometheus 的数据模型

Prometheus 将收集的监控指标数据作为时序数据进行存储，一条时序数据流（stream）由指标名称（metric name）和标签（label）以及被打赏工夫戳的数据组成：

<metric name>{<label name>=<label value>, ...}

例如用来记录一个 API 网关中注册的一台服务器的衰弱状态（1 代表衰弱）：

api_gray_gateway_upstream_health{usptream="product-test",id="0",name="192.168.152.194:8000",backup="false"} 1
api_gray_gateway_upstream_health{usptream="product-test",id="1",name="192.168.152.195:8000",backup="false"} 0

通过这种简略的数据模型咱们能够组合出四种典型的指标类型。

1. Counter：一种累加的指标，这种指标只能减少或者在重启时重置为 0。能够用来记录申请数。联合 rate 函数能够计算出申请速率
2. Gauge：一种可增可减的指标，通常用来记录零碎的某种状态，比方记录 CPU 使用率
3. Histogram：柱状图，某一指标的区间散布状况：这是一个复合的指标，由 total sum，count 以及不同的 bucket 组成，例如：

1. Summary：分位数，某一指标的 50% 分位数（中位数），90% 分位数和 99% 分位数等，分位数还能够应用 histogram_quantile 函数由 histogram 近似计算失去，区别是会有肯定的误差，然而 histogram 计算在服务端的开销更小（服务端只须要统计次数，而不须要计算分位数），例如：

一些理论利用

利用 Prometheus 展现 HTTP 网关托管的后端服务器衰弱状态

咱们的 HTTP 网关是应用 OpenResty 实现的，具备良好的扩展性。实现这一个性，只须要在 /metrics 接口中减少查问后端服务器状态的逻辑（应用 lua-upstream-nginx-module 模块的 API），并应用 Gauge 类型的指标记录衰弱状态，而后将后果返回给 Prometheus，如：

最初在 Grafana 中（Prometheus 作为数据源）建设图表，还能够通过设置一些变量不便业务方查问不同的 Upstream 中 Server 的衰弱状态，当然这里的图表还能够更好看一些（我用的 Grafana 版本有点老）并且集成到其余 WEB 页面中，下图中状态 1 示意 Server 衰弱，0 示意不衰弱。

在这个利用中，我利用了 Prometheus 简略的编程模型和查问能力，以及 Grafana 的图表生成能力，疾速构建了监控零碎。

TiDB Peer 迁徙限速模块中的指标设计的改良

背景：TiDB 是一个由 Pingcap 公司主导的开源分布式 NewSQL 数据库，TiDB 应用 TiKV 作为存储。TiKV 一个由 Pingcap 公司主导的开源分布式 Key-value 数据库。Raft 是 一个工业畛域内罕用的分布式一致性算法，而 TiKV 应用的正是 Raft 算法，更具体的是一种 Multi Raft Group。下图的示例中，每个 Store 是一个理论的存储节点（一个过程），因为性能的起因数据会分成多个 Region 存储（不同 Region 存储不同 Key 范畴的数据），为了实现高可用同一个 Region 的数据在不同的 Store 中会有多个正本（Peer），同一个 Region 的不同 Peer 形成一个 Raft 共识：

当咱们须要对系统进行扩容时，能够增加一个 Store，并由 PD（Placement Driver for TiKV）实现 Region 的 Peer 在 Store 中散布的调整。这些调整是在线调整的，如果 Peer 的迁徙速度过快会影响零碎的性能，因此须要对速度进行限度，PD 中采纳了令牌桶算法实现了限速的个性。

为了监控限速模块的工作状态，须要设计一些监控指标。我在 https://github.com/pingcap/pd/pull/2404 这个 PR 中实现了对限速模块监控指标的改良。

改良后的指标有：

1. storeLimitAvailableGauge：记录以后限速器中的可用令牌数
2. storeLimitRateGauge：记录以后设置的速率
3. storeLimitCostCounter：记录累计的 Peer 迁徙的开销

指标收集的机会：

1. storeLimitAvailableGauge 和 storeLimitRateGauge：应用协程周期性地更新
2. storeLimitCostCounter：在零碎产生 Region 迁徙时更新

这里咱们须要关注的是须要依据指标的含意抉择指标类型，须要正当利用不同指标类型，收集与之相适应的监控数据。

思考：在工作之余参加其余开源我的项目（比方 TiDB，Kubernetes）能够开辟视线，播种行业内的一些先进经验，防止思维的僵化。

总结

本文介绍了 Prometheus 的特定，数据模型，指标类型以及监控指标设计方面的准则，以及一些闲言碎语。最初介绍了两个理论工作和业余参加的开源我的项目中的理论利用。

本文作者：

王任铮 UCloud 后盾研发工程师