概述
官方网站:https://prometheus.io/git
Github:https://github.com/prometheus/prometheusgithub
Prometheus 是一个开源监控系统,它前身是 SoundCloud 的告警工具包。从 2012 年开始,许多公司和组织开始使用 Prometheus。该项目的开发人员和用户社区很是活跃,愈来愈多的开发人员和用户参与到该项目中。目前它是一个独立的开源项目,且不依赖于任何公司。为了强调这点和明确该项目治理结构,Prometheus 在 2016 年继 Kurberntes 以后,加入了 Cloud Native Computing Foundation。web
主要特性
- 多维度数据模型
- 灵活的查询语言
- 不依赖任何分布式存储
- 常见方式是经过拉取方式采集数据
- 也可经过中间网关支持推送方式采集数据
- 经过服务发现或者静态配置来发现监控目标
- 支持多种图形界面展现方式
架构
Servicediscovery正则表达式
pagerdutyapi
Short-lived网络
jobs架构
ile_sd分布式
kubernetessvg
AIertmanager工具
pushmetrics
atexit
discover
notify
targets
Pushgateway
Prometheusserver
push
alerts
HTTP
pull
Retrieval
TSDB
server
metrics
Prometheus
webUi
Grafana
Node
HDD/SSD
Jobs/
exporters
APIclients
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
表示一个度量指标和一组键值对标签,须要使用如下符号:
例如,度量指标名称是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的任务有四个相同的实例。
当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
本文同步分享在 博客“羊羽”(other)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。