服务监控 - Prometheus——概述 - 《Microservice》

概述
核心概念
最佳实践
参考

概述

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

主要特性

多维度数据模型
灵活的查询语言
不依赖任何分布式存储
常见方式是通过拉取方式采集数据
也可通过中间网关支持推送方式采集数据
通过服务发现或者静态配置来发现监控目标
支持多种图形界面展示方式
架构

Prometheus Server 采用拉取方式从监控目标直接拉取数据，或者通过中间网关间接地拉取监控目标推送给网关的数据。它在本地存储抓取的数据，通过一定规则进行清理和整理数据，然后把得到的结果存储起来，各种 Web UI 使用 PromQL 查询语言来从 Server 里获取数据。当 Server 监测到有异常时会推送告警给 Alertmanager，Alertmanager 负责去通知相关人。

缺陷

普罗米修斯值的可靠性。您始终可以查看有关系统的可用统计信息，即使在故障情况下也是如此。如果您需要100%的准确性，比如根据每次请求计费，Prometheus不是一个好的选择，因为收集的数据可能不够详细和完整。在这种情况下，您最好使用其他系统来收集和分析用于计费的数据，使用Prometheus来完成其他的监控工作。

核心概念

数据模型

Prometheus从根本上存储的所有数据都是时间序列: 具有时间戳的数据流只属于单个度量指标和该度量指标下的多个标签维度。除了存储时间序列数据外，Prometheus也可以利用查询表达式存储5分钟的返回结果中的时间序列数据

度量指标(Metric names)和标签(labels)

每个时间序列Time Serie，简称时序）由度量指标和一组标签键值对唯一确定。
量指标名称指定监控目标系统的测量特征（如：http_requests_total- 接收http请求的总计数）. metric度量指标命名ASCII字母、数字、下划线和冒号，他必须配正则表达式[a-zA-Z_:][a-zA-Z0-9_:]*。
标签开启了Prometheus的多维数据模型：对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。(例如：所有包含度量名称为/api/tracks的http请求，打上method=POST的标签，则形成了具体的http请求)。这个查询语言在这些度量和标签列表的基础上进行过滤和聚合。改变任何度量上的任何标签值，则会形成新的时间序列图
标签label名称可以包含ASCII字母、数字和下划线。它们必须匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*。带有__下划线的标签名称被保留内部使用。
标签labels值包含任意的Unicode码。

采样值Samples

有序的采样值形成了实际的时间序列数据列表。每个采样值包括：

一个64位的浮点值
一个精确到毫秒级的时间戳
注解Notation
表示一个度量指标和一组键值对标签，需要使用以下符号：

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

例如，度量指标名称是api_http_requests_total，标签为method="POST", handler="/messages" 的示例如下所示：

api_http_requests_total{method=“POST”, handler=“/messages”}

metrics类型

Prometheus客户库提供了四个核心的metrics类型。

Counter/计数器

counter 是一个累计度量指标，它是一个只能递增的数值。计数器主要用于统计服务的请求数、任务完成数和错误出现的次数等等。计数器是一个递增的值，也就是只能只能增加不能减少。重启进程后，会被重置。

Gauge/测量器

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

Histogram/柱状图

histogram，是柱状图，在Prometheus系统中的查询语言中，有三种作用：

对每个采样点进行统计，打到各个分类值中(bucket)
对每个采样点值累计和(sum)
对采样点的次数累计和(count)

度量指标名称: [basename]的柱状图, 上面三类的作用度量指标名称

[basename]_bucket{le=“上边界”}, 这个值为小于等于上边界的所有采样点数量
[basename]_sum
[basename]_count

常用于跟踪事件发生的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供 count 和 sum 全部值的功能。

Summary/总结

类似histogram柱状图，summary是采样点分位图统计，(通常的使用场景：请求持续时间和响应大小)。它也有三种作用：

对于每个采样点进行统计，并形成分位图。（如：正态分布一样，统计低于60分不及格的同学比例，统计低于80分的同学比例，统计低于95分的同学比例）
统计班上所有同学的总成绩(sum)
统计班上同学的考试总人数(count)

带有度量指标的[basename]的summary 在抓取时间序列数据展示。

观察时间的φ-quantiles (0 ≤ φ ≤ 1), 显示为[basename]{分位数="[φ]"}
[basename]_sum，是指所有观察值的总和
[basename]_count, 是指已观察到的事件计数值

任务(Jobs)和实例(Instances)

就Prometheus而言，pull拉取采样点的端点称之为instance。为了性能扩展而复制出来的多个这样的实例形成了一个任务。
例如, 下面的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: 目标所属的配置任务名称api-server。

instance: 采样点所在服务: host:port 如果以上两个标签二者之一存在于采样点中，这个取决于honor_labels配置选项。
对于每个采样点所在服务instance，Prometheus都会存储以下的度量指标采样点：

up{job=”[job-name]“, instance=“instance-id”}: up值=1，表示采样点所在服务健康; 否则，网络不通, 或者服务挂掉了
scrape_duration_seconds{job=”[job-name]“, instance=”[instance-id]“}: 尝试获取目前采样点的时间开销
scrape_samples_scraped{job=”[job-name]“, instance=”[instance-id]“}: 这个采样点目标暴露的样本点数量

up度量指标对服务健康的监控是非常有用的。

最佳实践

官方还给出一些最佳实践，可以简单浏览一下。主要是一些指标命名建议、监控指标类型的选择、告警策略、采用Recording rules提前生成监控指标、何时部署Pushgateway。

参考

https://prometheus.io/docs/introduction/overview/
https://github.com/1046102779/prometheus
https://prometheus.io/docs/practices/naming/
https://github.com/PierreVincent/prom-http-simulator/blob/master/cmd/main.go

Prometheus——概述

概述