介绍
1、Prometheus 是一个开源的服务监控系统和时序数据库,其提供了通用的数据模型和快捷数据采集、存储和查询接口。它的核心组件Prometheus server会定期从静态配置的监控目标或者基于服务发现自动配置的自标中进行拉取数据,当新拉取到的数据大于配置的内存缓存区时,数据就会持久化到存储设备当中。
2、每个被监控的主机都可以通过专用的exporter 程序提供输出监控数据的接口,它会在目标处收集监控数据,并暴露出一个HTTP接口供Prometheus server查询,Prometheus通过基于HTTP的pull的方式来周期性的采集数据。
3、任何被监控的目标都需要事先纳入到监控系统中才能进行时序数据采集、存储、告警和展示,监控目标可以通过配置信息以静态形式指定,也可以让Prometheus通过服务发现的机制进行动态管理。
Prometheus 具有以下特点:
• 多维数据模型:由度量名称和键值对标识的时间序列数据
• PromSQL:一种灵活的查询语言,可以利用多维数据完成复杂的查询
• 不依赖分布式存储,单个服务器节点可直接工作
• 基于HTTP的pull方式采集时间序列数据
• 推送时间序列数据通过PushGateway组件支持
• 通过服务发现或静态配置发现目标
• 多种图形模式及仪表盘支持
Prometheus适用于以机器为中心的监控以及高度动态面向服务架构的监控。
Prometheus生态组件组成
-
Prometheus server Prometheus服务器,用于抓取和存储时间序列数据。Prometheus server 由三个部分组成:Retrival,Storage,PromQL
-
Retrieval:负责在活跃的target 主机上抓取监控指标数据。
-
Storage:存储,主要是把采集到的数据存储到磁盘中。默认为15天(可修改)。
-
PromQL:是Prometheus提供的查询语言模块。
-
-
client libraries 客户端库,用于检测应用程序代码的客户端库。Prometheus本身提供了支持多种语言的SDK,用于对接 Prometheus Server, 可以查询和上报数据。目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径。
-
push gateway 支持短期工作的推送网关。类似一个中转站,可以理解成目标主机可以上报短期任务的数据到Pushgateway,然后Prometheus server 统一从Pushgateway拉取数据。
-
exporters 指标暴露器,负责收集不支持内建Instrumentation的应用程序或服务的性能指标数据,并通过HTTP接口供Prometheus Server获取。用于暴露已有的第三方服务的 metrics 给 Prometheus。
-
alertmanager 是一个独立的告警模块,从Prometheus server端接收到“告警通知”后,会进行去重、分组,并路由到相应的接收方,发出报警。
-
Service Discovery:服务发现,用于动态发现待监控的Target,Prometheus支持多种服务发现机制,例如文件、DNS、Consul、Kubernetes等等。
-
Grafana:是一个跨平台的开源的度量分析和可视化工具,可以将采集的数据可视化的展示,并及时通知给告警接收方。其官方库中具有丰富的仪表盘插件。
-
various support tools 各种支持工具
简单地说,Prometheus 的实现架构也并不复杂。其实就是收集数据、处理数据、可视化展示,再进行数据分析进行报警处理。 但其珍贵之处在于提供了一整套可行的解决方案,并且形成了一整个生态,能够极大地降低我们的研发成本。
数据类型
介绍
Prometheus 存储的是时序数据, 即按照相同时序(相同的名字和标签),以时间维度存储连续的数据的集合
Prometheus 中,每个时间序列都由指标名称(Metric Name)和标签(Label)来唯一标识格式为:{=,…}
-
指标名称:通常用于描述系统上要测定的某个特征
例如,prometheus_http_requests_total表示接收到的HTTP请求总数
-
标签:键值型数据,附加在指标名称之上,从而让指标能够支持多纬度特征;可选项
例如,如下代表着两个不同的时间序列
prometheus_http_requests_total{code=“200”}
prometheus_http_requests_total{code=“302”}
双下划线的标签是Prometheus系统默认标签,是不会显示在/metrics页面里面的;
系统默认标签在target页面中也是不显示的,需要鼠标放到Labels字段上才会显示。
常见的系统默认标签:
__address:当前target 实例的套接字地址:
__scheme:采集当前target 上指标数据时使用的协议(http或https)
__metrics_path:采集当前target 上的指标数据时使用URI路径,默认为/metrics
___param:传递的URL参数中第一个名称为的参数的值
__name:此标签是标识指标名称的预留标签,能够使用标签选择器对指标名称进行过滤
时序样本
按照某个时序以时间维度采集的数据,称之为样本,其值包含:
-
一个 float64 值
-
一个毫秒级的 unix 时间戳
Metrics指标类型
Counter
Counter类型的指标其工作方式和计数器一样,只增不减(除非系统发生重置)。
通常借助于 rate、topk、increase 和 irate 等函数来生成样本数据的变化状况(增长率)
例如,通过rate()函数获取HTTP请求量的增长率:
rate(http_requests_total[5m])
Gauge
Gauge类型的指标侧重于反应系统的当前状态。因此这类指标的样本数据可增可减。(例如CPU使用率、队列数)
常用于进行求和、取平均值、最小值、最大值等聚合计算;也会经常结合 PromQL 的 delta、deriv 和 predict_linear 函数使用
Histogram和Summary
Histogram和Summary主用用于统计和分析样本的分布情况。
例如,统计延迟在 0~10 ms 之间的请求数有多少,而 10~20 ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram和Summary都是为了能够解决这样问题的存在,通过 Histogram 和 Summary 类型的监控指标,我们可以快速了解监控样本的分布情况。
Summary和Histogram的异同:
-
相似之处在于Histogram类型的样本同样会反应当前指标的记录的总数(以count作为后缀)以及其值的总量(以sum作为后缀)
-
不同在于Histogram指标直接反应了在不同区间内样本的个数,区间通过标签len进行定义
同时对于Histogram的指标,我们还可以通过histogram_quantile()函数计算出其值的分位数。不同在于Histogram通过histogram_quantile函数是在服务器端计算的分位数。 而Sumamry的分位数则是直接在客户端计算完成。因此对于分位数的计算而言,Summary在通过PromQL进行查询时有更好的性能表现,而Histogram则会消耗更多的资源。反之对于客户端而言Histogram消耗的资源更少。
标签:入门,标签,Histogram,指标,Prometheus,监控,数据 From: https://www.cnblogs.com/yjh1995/p/18395299