Prometheus介绍

Prometheus

Prometheus是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的。成立于2012年,之后许多公司和组织接受和采用prometheus,他们便将它独立成开源项目,并且有公司来运作.该项目有非常活跃的社区和开发人员,目前是独立的开源项目,任何公司都可以使用它,2016年,Prometheus加入了云计算基金会,成为kubernetes之后的第二个托管项目.google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中,通常会搭配Prometheus进行监控。

特性

prometheus的主要特点

  • 自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)
  • 非常高效的存储 平均一个采样数据占 ~3.5 bytes左右,320万的时间序列,每30秒采样,保持60天,消耗磁盘大概228G。
  • 在多维度上灵活且强大的查询语言(PromQl)
  • 不依赖分布式存储,支持单主节点工作
  • 通过基于HTTP的pull方式采集时序数据
  • 可以通过push gateway进行时序列数据推送(pushing)
  • 可以通过服务发现或者静态配置去获取要采集的目标服务器
  • 多种可视化图表及仪表盘支持

pull方式

Prometheus采集数据是用的pull也就是拉模型,通过HTTP协议去采集指标,只要应用系统能够提供HTTP接口就可以接入监控系统,相比于私有协议或二进制协议来说开发、简单。

push方式

对于定时任务这种短周期的指标采集,如果采用pull模式,可能造成任务结束了,Prometheus还没有来得及采集,这个时候可以使用加一个中转层,客户端推数据到Push Gateway缓存一下,由Prometheus从push gateway pull指标过来。(需要额外搭建Push Gateway,同时需要新增job去从gateway采数据)

prometheus适用于监控所有时间序列的项目

目前其生态中已经有很多exporter实现,例如:

  • Node/system metrics exporter
  • AWS CloudWatch exporter
  • Blackbox exporter
  • Collectd exporter
  • Consul exporter
  • Graphite exporter
  • HAProxy exporter
  • InfluxDB exporter
  • JMX exporter
  • Memcached exporter
  • Mesos task exporter
  • MySQL server exporter
  • SNMP exporter
  • StatsD exporter

组成及架构

Prometheus生态系统由多个组件组成。其中许多组件都是可选的

  • Prometheus server

    主要负责数据采集和存储,提供PromQL查询语言的支持

  • 客户端sdk官方提供的客户端类库:

    go、java、scala、python、ruby,其他还有很多第三方开发的类库,支持nodejs、php、erlang等

  • Push Gateway

    支持临时性Job主动推送指标的中间网关

  • PromDash

    使用rails开发的dashboard,用于可视化指标数据

  • exporters

    支持其他数据源的指标导入到Prometheus,支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等

  • alertmanager

    实验性组件、用来进行报警

  • prometheus_cli

    命令行工具

  • 其他辅助性工具

prometheus大多数组件都是用Go编写的,他们可以非常轻松的基于二进制文件部署和构建

它的服务过程是这样的 Prometheus Server 负责定时去目标上抓取 metrics(指标) 数据,每个抓取目标需要暴露一个http服务的接口给它定时抓取。
Prometheus支持通过配置文件、kubernetes、zookeeper、Consul、DNS SRV lookup等方式指定抓取目标。
Alertmanager 是独立于Prometheus的一个组件,可以支持Prometheus的查询语句编写规则,提供十分灵活的报警方式。
Prometheus支持很多方式的图表可视化,例如十分精美的Grafana,自带的Promdash,以及自身提供的模版引擎等等,还提供HTTP API的查询方式,自定义所需要的输出。
PushGateway这个组件是支持Client主动推送 metrics 到PushGateway,而Prometheus只是定时去Gateway上抓取数据。

如果有使用过statsd的用户,则会觉得这十分相似,只是statsd是直接发送给服务器端,而Prometheus主要还是靠进程主动去抓取。

概念

Prometheus 的数据模型

Prometheus 从根本上所有的存储都是按时间序列去实现的,相同的 metrics(指标名称) 和 label(一个或多个标签) 组成一条时间序列,不同的label表示不同的时间序列。为了支持一些查询,有时还会临时产生一些时间序列存储。

metrics name & label 指标名称和标签

每条时间序列是由唯一的 指标名称 和 一组 标签 (key=value)的形式组成。

  • 指标名称

    一般是给监测对像起一名字,例如 http_requests_total 这样,它有一些命名规则,可以包字母数字之类的的。通常是以应用名称开头监测对像数值类型单位这样。例如:

      - push_total
      - userlogin_mysql_duration_seconds
      - app_memory_usage_bytes
    
  • 标签
    就是对一条时间序列不同维度的识别了,例如 一个http请求用的是POST还是GET,它的endpoint是什么,这时候就要用标签去标记了。最终形成的标识便是这样了

      http_requests_total{method="POST",endpoint="/api/tracks"}
    

记住,针对http_requests_total这个metrics name 无论是增加标签还是删除标签都会形成一条新的时间序列。
查询语句就可以跟据上面标签的组合来查询聚合结果了。
如果以传统数据库的理解来看这条语句,则可以考虑 http_requests_total是表名,标签是字段,而timestamp是主键,还有一个float64字段是值了。(Prometheus里面所有值都是按float64存储)

Prometheus 的四种数据类型

Counter

  • Counter 用于累计值,例如 记录 请求次数、任务完成数、错误发生次数。

  • 一直增加,不会减少。

  • 重启进程后,会被重置。

      例如:http_response_total{method="GET",endpoint="/api/tracks"} 10
      10秒后抓取 http_response_total{method="GET",endpoint="/api/tracks"} 100
    

Gauge

  • Gauge 常规数值,例如 温度变化、CPU,内存,网络使用变化。

  • 可变大,可变小。

  • 重启进程后,会被重置

      例如: memory_usage_bytes{host="master-01"} 100 < 抓取值
      memory_usage_bytes{host="master-01"} 30
      memory_usage_bytes{host="master-01"} 50
      memory_usage_bytes{host="master-01"} 80 < 抓取值
    

Histogram

Histogram 可以理解为柱状图的意思,常用于跟踪事件发生(通常是请求持续时间或响应大小)的规模,例如:请求耗时、响应大小。它特别之处是可以对记录的内容进行分组,提供 count 和 sum 全部值的功能。

例如:{小于10=5次,小于20=1次,小于30=2次},count=7次,sum=7次的求和值

Summary

Summary和Histogram十分相似,常用于跟踪事件(通常是要求持续时间和响应大小)发生的规模,例如:请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。
例如:count=7次,sum=7次的值求值
它提供一个quantiles的功能,可以按%比划分跟踪的结果。例如:quantile取值0.95,表示取采样值里面的95%数据。

Jobs and Instances

在prometheus中,任何被采集的目标被称为instance,通常对应于单个进程,而相同类型(可扩展性和可靠性的复制)的instance集合被称为Job。例如:Api server job由4个复制instance组成:

- job: api-server
    - instance1: 1.2.3.4:5670
    - instance2: 1.2.3.4:5671
    - instance3: 5.6.7.8:5670
    - instance3: 5.6.7.8:5671

自动生成标签和时间序列

当prometheus采集目标时,它会自动附加某些标签,用于识别被采集的目标。

  • job: 配置目标所属的job名称
  • instance: 目标 HTTP URL<host>:<port>部分

如果任何一个标签已经存在于采集的数据中,则此行为依赖honor_labels 配置选项。

对于每个被采集的instance,prometheus存储如下的时间序列样本:

  • up{job="<job-name>",instance="<instance-id>"}:1 如果实例处于health,为1,否则为0
  • scrape_duration_seconds{job="<job-name>",instance="<instance-id>"} 持续采集时间

“up”时间序列metric对于instance可用性监控是有效的。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,456评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,763评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,265评论 0 238
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,716评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,071评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,435评论 1 212
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,751评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,437评论 0 195
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,148评论 1 239
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,411评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,912评论 1 257
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,281评论 2 252
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,913评论 3 234
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,020评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,776评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,462评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,350评论 2 262

推荐阅读更多精彩内容