Prometheus监控介绍

1. prometheus简介

官网:https://prometheus.io/

首先,Prometheus 是一款时序(time series)数据库,但它的功能却并非止步于 TSDB,而是一款设计用于进行目标(Target)监控的关键组件,
Prometheus是一个开源的系统监控和报警系统,现在已经加入到CNCF基金会,成为继k8s之后第二个在CNCF托管的项目,在kubernetes容器管理系统中,通常会搭配prometheus进行监控,同时也支持多种exporter采集数据,还支持pushgateway进行数据上报,Prometheus性能足够支撑上万台规模的集群。

Prometheus基本原理是通过 HTTP 协议周期性抓取(pull) 被监控组件的状态,这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统,不需要任何SDK或者其他的集成过程。

这样做非常适合虚拟化环境比如 VM 或者 Docker基于 HTTP call,从配置文件中指定的网络端点(endpoint)上周期性获取指标数据

监控分为白盒监控和黑盒监控,白盒监控是一种自醒方式,意味着被监控系统内部自己生成指标,等监控系统来采集的时候吐出即可,这种叫白盒监控。

黑盒监控则是我们对目标系统没有任何侵入性,只是在旁观察监控目标的状态,我们叫做黑盒监控,也叫基于探针的监控

Prometheus 支持多种监控方式,如果采用白盒监控,通过三种类型的途径从目标上抓取(Scrape)指标数据

  • Exporters

  • Instrumetation(测量系统)

  • Pushgateway

Prometheus 同其他 TSDB 相比有一个非常典型的特性:它主动从各 Traget 上“拉取(pull)”数据,而非等待被监控端的“推送(push)”

两个方式各有优劣,其中,Pull 模型的优势在于:

  • 有利于将配置集在 Prometheus Server 上完成,包括指标及采集速率等

  • Prometheus 的根本目标在于收集在 Target 上预先完成聚合的聚合性数据,而非一款由事件驱动的存储系统

2. 时序数据库简介

时序数据,是在一段时间内通过重复测量(measurement)而获得的观测值的聚合,将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴

服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据

3.prometheus特点

  • 多维度数据模型:时间序列数据由metrics名称和键值对来组成 可以对数据进行聚合,切割等操作所有的metrics都可以设置任意的多维标签。

  • 灵活的查询语言(PromQL):可以对采集的metrics指标进行加法,乘法,连接等操作;

  • 可以直接在本地部署,不依赖其他分布式存储;

  • 通过基于HTTP的pull方式采集时序数据;

  • 可通过服务发现或者静态配置来发现目标服务对象(targets)。

  • 有多种可视化图像界面,如Grafana等。

  • 高效的存储,每个采样数据占3.5 bytes左右,300万的时间序列,30s间隔,保留60天,消耗磁盘大概200G。

4. prometheus组件介绍

Prometheus 负责时序型指标数据的采集及存储,但数据的分析、聚合及直观展示以及告警等功能并非由 Prometheus Server 所负责

  • Prometheus Server:收集和存储时间序列数据。

  • Client Library:客户端库,检测应用程序代码,目的在于为那些期望原生提供 Instrumentation 功能的应用程序提供便捷的开发途径。当Prometheus抓取实例的HTTP端点时,客户端库会将所有跟踪的metrics指标的当前状态发送到prometheus server端。

  • Exporters:用于暴露现有应用程序或服务(不支持 Instrumentation)给 Prometheus Server,Pometheus支持多种exporter,通过exporter可以采集metrics数据,然后发送到prometheus server端

  • Alertmanager:从 Prometheus server 端接收到 “告警通知” 后,会进行去重,分组,并路由到相应的接收方,发出报警,常见的接收方式有:电子邮件,微信,钉钉, slack等。

  • Data Visualization:Prometheus Web UI(Prometheus Server 内建)及 Grafana等

  • Pushgateway:接收那些通常由短期作业生成的指标数据的网关,各个目标主机可上报数据到 Pushgateway,然后Prometheus Server统一从 Pushgateway 进行指标拉取操作。

  • Service Discovery:动态发现待监控的Target,从而完成监控配置的重要组件,在容器化环境尤为有用,该组件目前由 Prometheus Server 内建支持。用户提供的静态资源列表,基于文件的发现,例如,使用配置管理工具生成在Prometheus中自动更新的资源列表,自动发现

  • METRIC 集合:为了获取端点,普罗米修斯定义了一个称为目标的配置,称为Scrape(刮刮)

5.prometheus架构图

Prometheus整个生态圈组成主要包括prometheus server,Exporter,pushgateway,alertmanager,grafana,Web ui界面

Prometheus server由三个部分组成,Retrieval,Storage,PromQL

  • Retrieval负责在活跃的target主机上抓取监控指标数据

  • Storage存储主要是把采集到的数据存储到磁盘中

  • Prometheus服务器也提供了内置的查询语言PromQL;一个表达式浏览器;以及一个图形界面,您可以使用它来查看服务器上的数据。

prometheus工作流程是

  • 1). Prometheus server可定期从活跃的(up)目标主机上(target)拉取监控指标数据,目标主机的监控数据可通过配置静态job或者服务发现的方式被prometheus server采集到,这种方式默认的pull方式拉取指标;也可通过pushgateway把采集的数据上报到prometheus server中;还可通过一些组件自带的exporter采集相应组件的数据;

  • 2). Prometheus server 把采集到的监控指标数据保存到本地磁盘或者数据库;

  • 3). Prometheus 采集的监控指标数据按时间序列存储,通过配置报警规则,把触发的报警发送到 alertmanager

  • 4). Alertmanager 通过配置报警接收方,发送报警到邮件,微信或者钉钉等

  • 5). Prometheus 自带的web ui界面提供PromQL查询语言,可查询监控数据

  • 6).Grafana 可接入 prometheus 数据源,把监控数据以图形化形式展示出

Prometheus 的局限性

  • 1)Prometheus 是一款指标监控系统,不适合存储事件及日志等;它更多地展示的是趋势性的监控,而非精准数据

  • 2)Prometheus 认为只有最近的监控数据才有查询的需要,其本地存储的设计初衷只是保存短期(例如一个月)的数据,因而不支持针对大量的历史数据进行存储,若需要存储长期的历史数据,建议基于远端存储机制将数据保存于 InfluxDB 或 OpenTSDB等系统中

  • 3)Prometheus 的集群机制成熟度不高,即便基于 Thanos 同样如此

6. Prometheus 数据模型

Prometheus 仅用于以 “键值”形式存储时序式的聚合数据,它并不支持存储文本信息

  • 其中的键称为指标(Metric),它通常意味着 CPU 速率、内存使用率或分区空闲比例等

  • 同一指标可能会适配多个目标或设备,因此它使用标签作为元数据,从而为 Metric 添加更多的信息描述维度

  • 这些标签还可以作为过滤器进行指标过滤及聚合运算

1)Metric 名字

时间序列的名称通常描述收集的时间序列数据的一般性质,例如,website_visits_total作为网站访问总数。 名称可以包含ASCII字母、数字、下划线和冒号。

2)标签(Labels)

以 __为前缀的标签名称保留给普罗米修斯内部使用。

3)时间序列元素

4)Metric 保留时长

普罗米修斯是为短期监视和警报需求而设计的。默认情况下,它在本地数据库中保存了15天的时间序列。如果您希望保留更长时间的数据,建议的方法是将所需的数据发送到远程的第三方平台。普罗米修斯具有向外部数据存储写入的能力。

5)安全模型

普罗米修斯可以通过多种方式进行配置和部署。它对信任做了两个宽泛的假设:

  • 不受信任的用户将能够访问普罗米修斯服务器的HTTP API,从而访问数据库中的所有数据。

  • 只有受信任的用户才能访问Prometheus及其组件的命令行、配置文件、规则文件和运行时配置。

由于Prometheus 2.0, HTTP API的一些管理元素默认会被禁用。 因此,普罗米修斯及其组件不提供任何服务器端身份验证、授权或加密。如果您在一个更安全的环境中工作,您将需要实现额外的控制——例如,通过使用反向代理提前终止Prometheus服务器,或者代理您的exporter。

7. 指标类型(Metric Types)

Prometheus使用 4 种方法来描述监视的指标: Counter, Gauge, Summary,Histogram

7.1 Counter:计算器

用于保存单调递增性的数据,例如站点访问次数等,不能为负值,也不支持减少,但可以重置回 0 ,计数器统计的数据是递增的,不能使用计数器来统计可能减小的指标,计数器统计的指标是累计增加的,如http请求的总数,出现的错误总数,总的处理时间(如cpu累计使用时间),api请求总数,已完成的任务数等

7.2 Gauge:仪表盘

用于存储有着起伏特征的指标数据, 例如用于统计cpu使用率,内存使用率,磁盘使用率,温度等指标,还可统计上升和下降的计数,如并发请求数等,Gauge 是 Counter 的超集,但存在指标数据丢失的可能性时,Counter 能让用户确切了解指标随时间的变化状态,而 Gauge 则可能随时间流逝而精准度越来越低

7.3 Histogram:直方图

它会在一段内对数据进行采样,并将其计入可配置的 bucket 之中;Histogram能够存储更多的信息,包括样本值分布在每个 bucket(bucket自身的可配置)中的数量、所有样本值之和以及总的样本数量,从而 Prometheus 能够使用内置的函数进行如下操作。

  • 计算样本平均值:以值的总和除以值的数量

  • 计算样本分位值:分位值有助于了解符合特定标准的数据个数,例如评估响应时长超过 1 秒钟的请求比例,若超过20%即发送报警等。

Histogram由 <basename>_bucket{le="<upper inclusive bound>"},<basename>_bucket{le="+Inf"}, <basename>_sum,<basename>_count 组成

apiserver_request_latencies_sum、apiserver_request_latencies_count、apiserver_request_latencies_bucket

7.4 Summary:摘要

Histogram的扩展类型,但它是直接由被监控端自行聚合计算出分位数,并将结果响应给 Prometheus Server 的样本采集请求,因而其分位数是由监控端完成。主要用于表示一段时间内数据采样结果(通常是请求持续时间或响应大小之类的东西),还可计算度量值的总和和度量值的分位数以及在一定时间范围内的分位数,由<basename>{quantile="<φ>"},<basename>_sum,<basename>_count 组成

8. 作业(Job)和实例(Instance)

Instance:能够接收 Prometheus Server 数据 Scrape 操作的每个网络端点(endpoint),即为一个 Instance(实例)

通常具有类似功能的 Instance 的结合称为一个 Job,例如一个 MySQL主从复制集群中的所有 MySQL 进程

9. PromQL

Prometheus 提供了内置的数据查询语言 PromQL(Prometheus Query Language)支持用户进行实时的数据查询及聚合操作

PromQL 支持处理两种向量,并内置提供了一组用于数据处理的函数

  • 即时向量:最近一次的时间戳上跟踪的数据指标

  • 时间范围向量:指定时间范围内的所有时间戳上的数据指标

10. Instrumentation(程序仪表)

任何能够支持 Scrape 指标数据的应用程序都首先要具有一个测量系统

在 Prometheus 的语境中,Instrumentation 是指附加到应用程序中的那些用于暴露程序指标数据的客户端库,程序员借助于这些客户端库编写代码生成可暴露的指标数据

11. Exporters

对于那些未内建 Instrumentation ,且也不便于自行添加该类组件以暴露指标数据的应用程序来说,常用的办法是于待监控的目标应用程序外部运行一个独立指标暴露程序,该类型的程序即统称为 Exporter

换句话说,Exporter 负责从目标应用程序上采集和聚合原始格式的数据,并转换或聚合为 Prometheus 格式的指标向外暴露
Prometheus 站点上提供了大量的 Exporter

12. Alerts

抓取到异常值后,Prometheus 支持通过告警(Alert)机制向用户发送反馈或警示,以触发用户能够及时采取应对措施

Prometheus Server 仅负责生成告警指示,具体的告警行为由另一个独立的应用程序 AlertManager 负责

  • 告警指示由 Prometheus Server 基于用户提供的告警规则周期性计算生成

  • AlertManager 接收到 Prometheus Server 发来的告警指示后,基于用于自定义的告警路由(route)向告警接收人(receivers)发送告警信息

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值