prometheus api（prometheus api接口）

本篇文章给大家谈谈prometheus api，以及prometheus api接口对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享prometheus api的知识，其中也会对prometheus api接口进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、prometheus如何调取数据
• 2、Prometheus
• 3、prometheus配置详解
• 4、Prometheus学习系列（十三）之配置解析
• 5、【实践】2.Prometheus命令和配置详解
• 6、Prometheus的四大指标类型

prometheus如何调取数据

可以通过查询API请求监控数据。
操作场景当我们有数据查询需求时，可以通过查询API请求监控数据。APPID/Token获取方式托管PrometheusAPI使用需要通过APPID+Token的方式进行鉴权访问。

Prometheus

Prometheus是一个开源系统监控和报警工具包，具有活跃的生态系统。是一个多维数据模型，其中的时间序列数据由指标名称和键/值对识别。它不依赖分布式存储，单个服务器节点是自治的。通过一个中间网关支持推送时间序列，可以通过服务发现或静态配置来发现目标，支持多种模式的图表和仪表盘制作。

Prometheus具体架构图如下：

Prometheus 直接或通过中介推送网关从检测的作业中抓取指标，用于短期作业。 它将所有抓取的样本存储在本地，并对这些数据运行规则，以从现有数据聚合和记录新的时间序列或生成警报。 Grafana 或其他 API 使用者可用于可视化收集的数据。

--config.file="prometheus.yml" Prometheus配置文件路径。

--web.listen-address="0.0.0.0:9090" 用于监听UI、API和遥测的地址。

--web.config.file="" [EXPERIMENTAL] 可以启用TLS或认证的配置文件的路径。

--web.read-timeout=5m 超时读取请求和关闭空闲连接之前的最大持续时间。

--web.max-connections=512 最大同时连接数。

--web.external-url=<URL 外部可访问Prometheus所在的URL（例如，如果Prometheus通过反向代理提供服务）。用于生成返回到Prometheus本身的相对和绝对链接。如果URL有路径部分，它将用于为Prometheus服务的所有HTTP端点添加前缀。如果省略，将自动派生相关的URL组件。

--web.route-prefix=<path Web端点的内部路线的前缀。默认为-web.external-url的路径。

--web.user-assets=<path 静态资源目录的路径，位于 /user。

--web.enable-lifecycle 通过HTTP请求启用关闭和重新加载。

--web.enable-admin-api 启用管理控制行动的API端点。

--web.console.templates="consoles" 控制台模板目录的路径，位于/consoles。

--web.console.libraries="console_libraries" 控制台库目录的路径。

--storage.tsdb.path="data/" 指标存储的基本路径。仅用于server模式。

--storage.tsdb.retention.time = 样本在储存中保留多长时间。设置此标志后，它会覆盖“storage.tsdb.retention”。如果此标志、“storage.tsdb.retention”或“storage.tsdb.retention.size”均未设置，则保留时间默认为15d。支持的单位：y、w、d、h、m、s、ms。仅用于server模式。

--storage.tsdb.retention.size = 块存储的最大字节数。需要一个单位，支持的单位：B、KB、MB、GB、TB、PB、EB。例如：“512MB”。仅用于server模式。

--storage.tsdb.no-lockfile 不在数据目录中创建锁文件。仅用于server模式。

--storage.tsdb.allow-overlapping-blocks 允许重叠块，从而启用垂直压缩和垂直查询合并。仅用于服务器模式。

--storage.agent.path="data-agent/" 指标存储的基本路径。仅用于agent模式。

--storage.agent.wal-compression 压缩代理WAL。仅用于agent模式。

--storage.agent.retention.min-time= 当WAL被截断时，样本在被强行删除之前的最小年龄，仅用于agent模式。

--storage.agent.retention.max-time= 当WAL被截断时，样本在被强行删除之前的最大年龄，仅用于agent模式。

--storage.agent.no-lockfile 不在数据目录中创建锁文件。仅用于agent模式。

--storage.remote.flush-deadline=<duration 在关闭或重新加载配置时等待刷新样本的时间。

--storage.remote.read-sample-limit=5e7 在单个查询中通过远程读取接口返回的最大样本总数。 0 表示没有限制。对于流式响应类型，将忽略此限制。仅用于server模式。

--storage.remote.read-concurrent-limit=10 并发远程读取调用的最大数量。 0 表示没有限制。仅用于server模式。

--rules.alert.for-outage-tolerance=1h 为恢复“for”警报状态而容忍Prometheus中断的最长时间。仅用于server模式。

--rules.alert.for-grace-period=10m 警报和恢复“for”状态之间的最短持续时间。这仅适用于配置的“for”时间大于宽限期的警报。仅用于server模式。

--rules.alert.resend-delay=1m 在向 Alertmanager 重新发送警报之前等待的最短时间。仅用于server模式。

--alertmanager.notification-queue-capacity=10000 等待Alertmanager通知的队列容量。仅用于server模式。

--query.lookback-delta=5m 在表达式评估和联合期间，检索指标的最长回溯持续时间。仅用于server模式。

--query.timeout=2m 查询在中止之前可能需要的最长时间。仅用于server模式。

--query.max-concurrency=20 并发执行的最大查询数。仅用于server模式。

--query.max-samples=50000000 单个查询可以加载到内存中的最大样本数。请注意，如果查询尝试将比这更多的样本加载到内存中，查询将失败，因此这也限制了查询可以返回的样本数量。仅用于server模式。

--enable-feature= 逗号分隔的要启用的功能名称。有效选项：agent、exemplar-storage、expand-external-labels、memory-snapshot-on-shutdown、promql-at-modifier、promql-negative-offset、remote-write-receiver。extra-scrape-metrics、new-service-discovery-manager。

--log.level=info 只记录给定严重程度或以上的信息。其中之一：[debug, info, warn, error]。

--log.format=logfmt 日志信息的输出格式。其中之一：[logfmt, json]。

通用占位符定义如下：

全局配置区域：

scrape_config部分指定了一组描述如何抓取它们的目标和参数，目标可以通过static_configs参数静态配置或使用支持的服务发现机制之一动态发现。

Prometheus自身支持basic验证和TLS（将来可能会改变），也可以通过nginx开启basic验证。

Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

一般来说可以将Exporter分为2类：

Prometheus UI提供了快速验证PromQL以及临时可视化支持的能力，而在大多数场景下引入监控系统通常还需要构建可以长期使用的监控数据可视化面板（Dashboard）。这时用户可以考虑使用第三方的可视化工具如Grafana，Grafana是一个开源的可视化平台，并且提供了对Prometheus的完整支持。

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。

Alertmanager 处理客户端应用程序（例如 Prometheus 服务器）发送的警报。 它负责对它们进行重复数据删除、分组和路由到正确的接收器集成，例如Email、PagerDuty 或 OpsGenie。 它还负责警报的静音和抑制。

报警全家桶 https://github.com/feiyu563/PrometheusAlert

prometheus配置详解

本文按照官方文档的相关内容整理整理的配置语法以及实现功能

一个scrape_config 片段指定一组目标和参数， 目标就是实例，指定采集的端点， 参数描述如何采集这些实例， 配置文件格式如下

因为部署在kubernetes环境中所以我只在意基于kubernetes_sd_configs的服务发现和static_configs静态文件的发现

relable_configss是功能强大的工具，就是Relabel可以在Prometheus采集数据之前，通过Target实例的Metadata信息，动态重新写入Label的值。除此之外，我们还能根据Target实例的Metadata信息选择是否采集或者忽略该Target实例。

relabel_configs

配置格式如下：

其中action主要包括:

replace：默认，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组
keep：删除regex与连接不匹配的目标 source_labels
drop：删除regex与连接匹配的目标 source_labels
labeldrop：删除regex匹配的标签
labelkeep：删除regex不匹配的标签
hashmod：设置target_label为modulus连接的哈希值source_labels
labelmap：匹配regex所有标签名称。然后复制匹配标签的值进行分组，replacement分组引用（ {2},…）替代

prometheus中的数值都是key:value格式， 其中replace、keep、drop都是对value的操作， labelmap、labeldrop、labelkeep都是对key的操作

replace是action的默认值， 通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组

上面的列子中 address 的值为 $1:$2 ， 其中 $1 是正则表达式 ([^:]+)(?::\d+)? 从 address 中获取， $2 是正则表达式 (\d+)从(\d+) 中获取， 最后的 address 的数值为192.168.1.1:9100

上面的例子只要匹配__meta_kubernetes_service_annotation_prometheus_io_probe=true数据就保留， 反正source_labels中的值没有匹配regex中的值就丢弃

drop 的使用和keep刚好相反， 还是使用keep的例子:

上面的例子只要__meta_kubernetes_service_annotation_prometheus_io_probe这个标签的值为true就丢弃， 反之如果__meta_kubernetes_service_annotation_prometheus_io_probe!=true的数据就保留

labelmap的用法和上面说到replace、keep、drop不同， labelmap匹配的是标签名称， 而replace、keep、drop匹配的是value

上面例子中只要匹配到正则表达式 __meta_kubernetes_service_label_(.+) 的标签， 就将标签重写为 (.+) 中的内容， 效果如下：

待续

使用labeldrop则可以对Target标签进行过滤，删除符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签， 删除符合规则的标签， 反之保留不符合规则的

使用labelkeep则可以对Target标签进行过滤，仅保留符合过滤条件的标签，例如：

该配置会使用regex匹配当前target中的所有标签， 保留符合规则的标签， 反之不符合的移除

上面我们说到relabel_config是获取metrics之前对标签的重写， 对应的metric_relabel_configs是对获取metrics之后对标签的操作， metric_relabel_configs能够确定我们保存哪些指标，删除哪些指标，以及这些指标将是什么样子。

metric_relabel_configs的配置和relabel_config的配置基本相同， 如果需要配置相关参数请参考 2.scrape_configs

主要用途为指定exporter获取metrics数据的目标， 可以指定prometheus、 mysql、 nginx等目标

此规则主要是用于抓取prometheus自己数据的配置， targets列表中的为prometheus 获取metrics的地址和端口， 因为没有指定metrics_path所以使用默认的/metrics中获取数据，

简单理解就是， prometheus访问 http://localhost:9090/metrics 获取监控数据

还可以配置指定exporter中的目的地址， 如获取node_exporter的数据

简单理解为分别访问 metrics metrics metrics 获取metrics数据

kubernetes的服务发现可以刮取以下几种数据

通过指定kubernetes_sd_config的模式为endpoints，Prometheus会自动从Kubernetes中发现到所有的endpoints节点并作为当前Job监控的Target实例。如下所示，

该配置是使用kubernetes的发现机制发现kube-apiservers

上面的刮取配置定义了如下信息：

该配置是自动发现kubernetes中的endpoints

可以看到relable_configs中的规则很多， 具体的内容如下

获取的metrics的信息如下：

Prometheus学习系列（十三）之配置解析

Prometheus通过命令行标志和配置文件进行配置。 虽然命令行标志配置了不可变的系统参数（例如存储位置，保留在磁盘和内存中的数据量等），但配置文件定义了与抓取作业及其实例相关的所有内容，以及哪些规则文件 载入。

要查看所有可用的命令行参数，执行 ./prometheus -h

Prometheus可以在运行时重新加载其配置。 如果新配置格式不正确，则不会应用更改。 通过向Prometheus进程发送SIGHUP或向 /-/reload 端点发送HTTP POST请求（启用 --web.enable-lifecycle 标志时）来触发配置重新加载。 这也将重新加载任何已配置的规则文件。

要指定要加载的配置文件，请使用 --config.file 标志。

该文件以YAML格式编写，由下面描述的方案定义。 括号表示参数是可选的。 对于非列表参数，该值设置为指定的默认值。

通用占位符定义如下：

其他占位符是单独指定的。

可以在此处找到有效的示例文件。

全局配置指定在所有其他配置上下文中有效的参数。 它们还可用作其他配置节的默认值。

<scrape_config 部分指定一组描述如何刮除它们的目标和参数。 在一般情况下，一个scrape配置指定单个作业。 在高级配置中，这可能会改变。

目标可以通过 <static_configs 参数静态配置，也可以使用其中一种支持的服务发现机制动态发现。

此外， <relabel_configs 允许在抓取之前对任何目标及其标签进行高级修改。

其中 <job_name 在所有scrape配置中必须是唯一的。

tls_config 允许配置TLS连接。

基于DNS的服务发现配置允许指定一组DNS域名，这些域名会定期查询以发现目标列表。 要联系的DNS服务器从 /etc/resolv.conf 中读取。

此服务发现方法仅支持基本的DNS A，AAAA和SRV记录查询，但不支持RFC6763中指定的高级DNS-SD方法。

在重新标记阶段，元标签 __meta_dns_name 在每个目标上可用，并设置为生成已发现目标的记录名称。

其中 <domain_name 是有效的DNS域名。 其中 <query_type 是SRV，A或AAAA。

Kubernetes SD配置允许从 Kubernetes 的RESTAPI中检索scrape目标，并始终与群集状态保持同步。

可以配置以下 role 类型之一来发现目标：

可用元标签：

此外，节点的 instance 标签将设置为从API服务器检索的节点名称。

可用元标签：

可用元标签：

可用元标签：

可用元标签：

有关Kubernetes发现的配置选项，请参见下文：

其中 <role 必须是 endpoints ， service ， pod ， node 或 ingress 。

有关为Kubernetes配置Prometheus的详细 示例 ，请参阅此示例Prometheus配置文件。

您可能希望查看第三方Prometheus 操作 ，它可以在Kubernetes上自动执行Prometheus设置。

static_config允许指定目标列表和它们的公共标签集。 这是在scrape配置中指定静态目标的规范方法。

重新标记是一种强大的工具，可以在抓取目标之前动态重写目标的标签集。 每个抓取配置可以配置多个重新标记步骤。 它们按照它们在配置文件中的出现顺序应用于每个目标的标签集。

最初，除了配置的每目标标签之外，目标的作业标签设置为相应的scrape配置的 job_name 值。 __address__ 标签设置为目标的 <host：<port 地址。 重新标记后，如果在重新标记期间未设置实例标签，则实例标签默认设置为 __address__ 的值。 __scheme__ 和 __metrics_path__ 标签分别设置为目标的方案和度量标准路径。 __param_ <name 标签设置为名为 <name 的第一个传递的URL参数的值。

在重新标记阶段，可以使用带有 __meta_ 前缀的附加标签。 它们由提供目标的服务发现机制设置，并在不同机制之间变化。

在目标重新标记完成后，将从标签集中删除以 __ 开头的标签。

如果重新标记步骤仅需临时存储标签值（作为后续重新标记步骤的输入），请使用 __tmp 标签名称前缀。 保证Prometheus本身不会使用此前缀。

<regex 是任何有效的RE2正则表达式。 它是 replace ， keep ， drop ， labelmap ， labeldrop 和 labelkeep 操作所必需的。 正则表达式固定在两端。 要取消锚定正则表达式，请使用。 * <regex.* 。

<relabel_action 确定要采取的重新签名行动：

必须小心使用 labeldrop 和 labelkeep ，以确保在删除标签后仍然对指标进行唯一标记。

度量重新标记应用于样本，作为摄取前的最后一步。 它具有与目标重新标记相同的配置格式和操作。 度量标准重新标记不适用于自动生成的时间序列，例如 up 。

一个用途是将黑名单时间序列列入黑名单，这些时间序列太昂贵而无法摄取。

警报重新标记在发送到Alertmanager之前应用于警报。 它具有与目标重新标记相同的配置格式和操作。 外部标签后应用警报重新标记。

这样做的一个用途是确保具有不同外部标签的HA对Prometheus服务器发送相同的警报。

alertmanager_config 部分指定Prometheus服务器向其发送警报的Alertmanager实例。 它还提供参数以配置如何与这些Alertmanagers进行通信。

Alertmanagers可以通过 static_configs 参数静态配置，也可以使用其中一种支持的服务发现机制动态发现。

此外， relabel_configs 允许从发现的实体中选择Alertmanagers，并对使用的API路径提供高级修改，该路径通过 __alerts_path__ 标签公开。

write_relabel_configs 是在将样本发送到远程端点之前应用于样本的重新标记。 在外部标签之后应用写入重新标记。 这可用于限制发送的样本。

有一个如何使用此功能的小型 演示 。

有一个与此功能 集成 的列表。

有一个与此功能 集成 的列表。

Prometheus官网地址： https://prometheus.io/
我的Github： https://github.com/Alrights/prometheus

【实践】2.Prometheus命令和配置详解

Prometheus配置方式有两种：
（1）命令行，用来配置不可变命令参数，主要是Prometheus运行参数，比如数据存储位置
（2）配置文件，用来配置Prometheus应用参数，比如数据采集，报警对接

不重启进程配置生效方式也有两种：
（1）对进程发送信号SIGHUP
（2）HTTP POST请求，需要开启--web.enable-lifecycle选项curl -X POST reload

配置文件格式是yaml格式，说明：
.yml或者.yaml 都是 yaml格式的文件，
yaml格式的好处: 和json交互比较容易
python/go/java/php 有yaml格式库，方便语言之间解析,并且这种格式存储的信息量很大。

命令行可用配置可通过prometheus -h来查看。

配置文件使用yml格式，配置文件中一级配置项如下，说明参考#备注内容。

配置文件中通用字段值格式
<boolean: 布尔类型值为true和false
<scheme: 协议方式包含http和https

原始配置文件内容：

全局默认的数据拉取间隔

全局默认的单次数据拉取超时，当报context deadline exceeded错误时需要在特定的job下配置该字段。

全局默认的规则(主要是报警规则)拉取间隔

该服务端在与其他系统对接所携带的标签

该字段配置与Alertmanager进行对接的配置
样例：

上面的配置中的 alert_relabel_configs 是指警报重新标记在发送到Alertmanager之前应用于警报。 它具有与目标重新标记相同的配置格式和操作，外部标签标记后应用警报重新标记，主要是针对集群配置。

这个设置的用途是确保具有不同外部label的HA对Prometheus服务端发送相同的警报信息。

Alertmanager 可以通过 static_configs 参数静态配置，也可以使用其中一种支持的服务发现机制动态发现，我们上面的配置是静态的单实例。

此外， relabel_configs 允许从发现的实体中选择 Alertmanager，并对使用的API路径提供高级修改，该路径通过 __alerts_path__ 标签公开。

完成以上配置后，重启Prometheus服务，用以加载生效，也可以使用热加载功能，使其配置生效。然后通过浏览器，访问 alerts 就可以看 inactive pending firing 三个状态，没有警报信息是因为我们还没有配置警报规则 rules 。

这里定义和prometheus集成的alertmanager插件，用于监控报警。后续会单独进行alertmanger插件的配置、配置说明、报警媒介以及route路由规则记录。

此项配置和 scrape_configs 字段中 relabel_configs 配置一样，用于对需要报警的数据进行过滤后发向 Alertmanager

说明
relabel-configs的配置允许你选择你想抓取的目标和这些目标的标签是什么。所以说如果你想要抓取这种类型的服务器而不是那种，可以使用relabel_configs

相比之下，metric_relabel_configs是发生在抓取之后，但在数据被插入存储系统之前使用。因此如果有些你想过滤的指标，或者来自抓取本身的指标（比如来自/metrics页面）你就可以使用metric_relabel_configs来处理。

该项目主要用来配置不同的 alertmanagers 服务，以及Prometheus服务和他们的链接参数。 alertmanagers 服务可以静态配置也可以使用服务发现配置。Prometheus以pushing 的方式向alertmanager传递数据。

alertmanager 服务配置和target配置一样，可用字段如下

这个主要是用来设置告警规则，基于设定什么指标进行报警（类似触发器trigger）。这里设定好规则以后，prometheus会根据全局global设定的evaluation_interval参数进行扫描加载，规则改动后会自动加载。其报警媒介和route路由由alertmanager插件实现。
样例：

"first_rules.yml"样例：

Prometheus 支持两种类型的 Rules ，可以对其进行配置，然后定期进行运算：recording rules 记录规则 与 alerting rules 警报规则，规则文件的计算频率与警报规则计算频率一致，都是通过全局配置中的 evaluation_interval 定义。

不论是recording rules还是alerting rules都要在组里面。

要在Prometheus中使用Rules规则，就必须创建一个包含必要规则语句的文件，并让Prometheus通过Prometheus配置中的rule_files字段加载该文件，前面我们已经讲过了。 其实语法都一样，除了 recording rules 中的收集的指标名称 record: <string 字段配置方式略有不同，其他都是一样的。

配置范例：

recording rules 是提前设置好一个比较花费大量时间运算或经常运算的表达式，其结果保存成一组新的时间序列数据。当需要查询的时候直接会返回已经计算好的结果，这样会比直接查询快，同时也减轻了PromQl的计算压力，同时对可视化查询的时候也很有用，可视化展示每次只需要刷新重复查询相同的表达式即可。

在配置的时候，除却 record: <string 需要注意，其他的基本上是一样的，一个 groups 下可以包含多条规则 rules ，Recording 和 Rules 保存在 group 内，Group 中的规则以规则的配置时间间隔顺序运算，也就是全局中的 evaluation_interval 设置。

配置范例：

上面的规则其实就是根据 record 规则中的定义，Prometheus 会在后台完成 expr 中定义的 PromQL 表达式周期性运算，以 job 为维度使用 sum 聚合运算符 计算 函数rate 对http_requests_total 指标区间 10m 内的增长率，并且将计算结果保存到新的时间序列 job:http_requests_total:rate10m 中， 同时还可以通过 labels 为样本数据添加额外的自定义标签，但是要注意的是这个 lables 一定存在当前表达式 Metrics 中。

模板是在警报中使用时间序列标签和值展示的一种方法，可以用于警报规则中的注释（annotation）与标签（lable）。模板其实使用的go语言的标准模板语法，并公开一些包含时间序列标签和值的变量。这样查询的时候，更具有可读性，也可以执行其他PromQL查询 来向警报添加额外内容，ALertmanager Web UI中会根据标签值显示器警报信息。

{{ $lable.<lablename}} 可以获取当前警报实例中的指定标签值

{{ $value }} 变量可以获取当前PromQL表达式的计算样本值。

调整好rules以后，我们可以使用 curl -XPOST http://localhost:9090/-/reload 或者 对Prometheus服务重启，让警报规则生效。

这个时候，我们可以把阈值调整为 50 来进行故障模拟操作，这时在去访问UI的时候，当持续1分钟满足警报条件，实际警报状态已转换为 Firing，可以在 Annotations中看到模板信息 summary 与 description 已经成功显示。

规则检查

拉取数据配置，在配置字段内可以配置拉取数据的对象(Targets)，job以及实例

定义job名称，是一个拉取单元。每个job_name都会自动引入默认配置如

这些也可以在单独的job中自定义

服务端拉取过来的数据也会存在标签，配置文件中也会有标签，这样就可能发生冲突。

true就是以抓取数据中的标签为准
false就会重新命名抓取数据中的标签为“exported”形式，然后添加配置文件中的标签

切换抓取数据所用的协议

定义可选的url参数

每次抓取数据请求的认证信息

password和password_file互斥只可以选择其一

bearer_token和bearer_token_file互斥只可以选择其一

抓取ssl请求时证书配置

通过代理去主去数据

Prometheus支持多种服务现工具，详细配置这里不再展开

更多参考官网： https://prometheus.io/docs/prometheus/latest/configuratio n/configuration/

服务发现来获取抓取目标为动态配置，这个配置项目为静态配置，静态配置为典型的targets配置，在改配置字段可以直接添加标签

采集器所采集的数据都会带有label，当使用服务发现时，比如consul所携带的label如下:

这些lable是数据筛选与聚合计算的基础。

抓取数据很繁杂，尤其是通过服务发现添加的target。所以过滤就显得尤为重要，我们知道抓取数据就是抓取target的一些列metrics，Prometheus过滤是通过对标签操作操现的，在字段relabel_configs和metric_relabel_configs里面配置，两者的配置都需要relabel_config字段。该字段需要配置项如下

target配置示例

target中metric示例

target中metric示例

使用示例
由以上可知当使用服务发现consul会带入标签__meta_consul_dc，现在为了表示方便需要将该标签变为dc

需要做如下配置，这里面action使用的replacement

过滤采集target

为了防止Prometheus服务过载，使用该字段限制经过relabel之后的数据采集数量，超过该数字拉取的数据就会被忽略

Prometheus可以进行远程读/写数据。字段remote_read和remote_write

（1）Prometheus 配置详解
https://www.dazhuanlan.com/2019/12/12/5df11ada207ce/
（2）Prometheus配置文件prometheus.yml 四个模块详解
http://yunwei.com/archives/7321
（3）官方文档说明
https://prometheus.io/docs/prometheus/latest/configuration/configuration/
（4）Prometheus监控神器-Rules篇
https://zhuanlan.zhihu.com/p/179295676
（5）Prometheus监控神器-Alertmanager篇(1)
https://zhuanlan.zhihu.com/p/179292686
（6）Prometheus监控神器-Alertmanager篇(2)
https://zhuanlan.zhihu.com/p/179294441

Prometheus的四大指标类型

Prometheus有4大指标类型（Metrics Type）prometheus api，分别是Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）和Summary（摘要）。

这是在Prometheus客户端（目前主要有Go、Java、Python、Ruby等语言版本）中提供prometheus api的4种核心指标类型，但是Prometheusprometheus api的服务端并不区分指标类型，而是简单地把这些指标统一视为无类型的时间序列。

注意：

<font color=red上面这句话应该这么理解，四个指标类型，实际上就是客户端采集数据的四个维度，采集这四个维度的指标数据，但是最终汇总到服务端那里，则是对这四个维度无感的，只是简单的作为时间序列存储起来。</font

 计数器表示一种单调递增的指标，除非发生重置的情况下下只增不减，其样本值应该是不断增大的。例如，可以使用Counter类型的指标来表示服务的请求数、已完成的任务数、错误发生的次数等。

 但是，计数器计算的总数对用户来说大多没有什么用，大家千万不要将计数器类型应用于样本数据非单调递增的指标上，比如当前运行的进程数量、当前登录的用户数量等应该使用仪表盘类型。

为prometheus api了能够更直观地表示样本数据的变化情况，往往需要计算样本的增长速率，这时候通常使用PromQL的rate、topk、increase和irate等函数，如下所示：

如上所示，速率的输出rate（v range-vector）也应该用仪表盘来承接结果。

在上面的案例中，如果有一个标签是Device，那么在统计每台机器每秒接受的HTTP请求数时，可以用如下的例子进行操作。

补充

 这背后与rate()的实现方式有关，rate()在设计上假定对应的指标是一个计数器，也就是只有<font color=redincr（增加）和reset（归零）</font两种行为。而执行了sum()或其prometheus api他聚合操作之后，得到的就不再是一个计数器了。举个例子，比如sum()的计算对象中有一个归零了，那整体的和会下降，而不是归零，这会影响rate()中判断reset（归零）的逻辑，从而导致错误的结果。

 increase（v range-vector）函数传递的参数是一个区间向量，increase函数获取区间向量中的第一个和最后一个样本并返回其增长量。下面的例子可以查询Counter类型指标的增长速率，可以获取http_requests_total在最近5分钟内的平均样本，其中300代表300秒。

 rate和increase函数计算的增长速率容易陷入<font color=red长尾效应中</font。比如在 某一个由于访问量或者其他问题导致CPU占用100%的情况中，通过计算在时间窗口内的平均增长速率是无法反映出该问题的 。

 为什么监控和性能测试中，我们更关注p95/p99位？就是因为长尾效应。由于个别请求的响应时间需要1秒或者更久，<font color=red传统的响应时间的平均值就体现不出响应时间中的尖刺了</font，去尖刺也是数据采集中一个很重要的工序，这就是所谓的长尾效应。p95/p99就是长尾效应的分割线，如表示99%的请求在XXX范围内，或者是1%的请求在XXX范围之外。99%是一个范围，意思是99%的请求在某一延迟内，剩下的1%就在延迟之外了。只是正推与逆推而已，是一种概念的两种不同描述。

 irate（v range-vector）是PromQL针对长尾效应专门提供的灵敏度更高的函数。irate同样用于计算区间向量的增长速率，但是其反映出的是瞬时增长速率。irate函数是通过区间向量中最后两个样本数据来计算区间向量的增长速率的。这种方式可以避免在时间窗口范围内的“长尾问题”，并且体现出更好的灵敏度。通过irate函数绘制的图标能够更好地反映样本数据的瞬时变化状态。irate的调用命令如下所示。

 irate函数相比于rate函数提供了更高的灵敏度，不过分析长期趋势时或者在告警规则中，irate的这种灵敏度反而容易造成干扰。因此，在长期趋势分析或者告警中更推荐使用rate函数。

 仪表盘类型代表一种<font color=red样本数据可以任意变化的指标，即可增可减</font。它可以理解为状态的快照，Gauge通常用于表示温度或者内存使用率这种指标数据，也可以表示能随时增加或减少的“总数”，例如当前并发请求的数量node_memory_MemFree（主机当前空闲的内容大小）、node_memory_MemAvailable（可用内存大小）等。在使用Gauge时，用户往往希望使用它们<font color=red求和、取平均值、最小值、最大值</font等。

 以Prometheus经典的Node Exporter的指标node_filesystem_size_bytes为例，它可以报告从node_filesystem_size_bytes采集来的文件系统大小，包含device、fstype和mountpoint等标签。如果想要对每一台机器上的总文件系统大小求和（sum），可以使用如下PromQL语句。

 without可以让sum指令根据相同的标签进行求和，但是忽略without涵盖的标签。如果在实际工作中需要忽略更多标签，可以根据实际情况在without里传递更多指标。

补充 ：

node_filesystem_size_bytes指标查询

device, fstype, mountpoint都是他的标签。

sum without(device, fstype, mountpoint)(node_filesystem_size_bytes)查询

 如果要根据Node Exporter的指标node_filesystem_size_bytes计算每台机器上最大的文件安装系统大小，只需要将上述案例中的sum函数改为max函数，如下所示。

 除了求和、求最大值等，利用Gauge的函数求最小值和平均值等原理是类似的。除了基本的操作外，Gauge经常结合PromQL的predict_linear和delta函数使用。

 predict_linear（v range-vector，t scalar）函数可以预测时间序列v在t秒后的值，就是使用线性回归的方式，预测样本数据的Gauge变化趋势。例如，基于2小时的样本数据，预测未来24小时内磁盘是否会满，如下所示：

PromQL还有一个内置函数delta()，它可以获取样本在一段时间内的变化情况，也通常作用于Gauge。例如，计算磁盘空间在2小时内的差异，如下所示。

Histogram是一个对数据分布情况的图形表示，由一系列高度不等的长条图（bar）或线段表示，用于展示单个测度得知的分布。

[图片上传失败...(image-3e55f2-1622153155462)]

上边界、样本值总和、样本总数

例子

这三个查询一起看

所有样本值的总和，命名为<basename_sum。

prometheus_http_request_duration_seconds_sum{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}0.405075955 表示12 次http请求的总响应时间是0.405075955

命名为<basename_count，其值和<basename_bucket{le="+Inf"}相同（所有）。

prometheus_http_request_duration_seconds_count{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}12 表示总共发生了12次请求

 sum函数和count函数相除，可以得到一些平均值，比如Prometheus一天内的平均压缩时间，可由查询结果除以instance标签数量得到，如下所示。

 除了Prometheus内置的压缩时间，prometheus_local_storage_series_chunks_persisted表示Prometheus中每个时序需要存储的chunk数量，也可以用于计算待持久化的数据的分位数。

 Histogram可以用于观察样本数据的分布情况。Histogram的分位数计算需要通过histogram_quantile（φfloat，b instant-vector）函数进行计算，但是histogram_quantile计算所得并非精确值。其中，φ（0<φ<1）表示需要计算的分位数（这个值主要是通过prometheus_http_request_duration_seconds_bucket和prometheus_http_request_duration_seconds_sum两个指标得到的，是一个近似值）。

例子如下。

 与Histogram类型类似，摘要用于表示一段时间内的数据采样的结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而非通过区间来计算（Histogram的分位数需要通过histogram_quantile（φfloat，b instant-vector）函数计算得到）。因此，对于分位数的计算，Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。反之，对于客户端而言，Histogram消耗的资源更少。在选择这两种方式时，用户应该根据自己的实际场景选择。

Histogram是在服务端计算的，Summary是在客户端计算的。

 安装并启动Prometheus后，在访问 http://localhost:9090/metrics 时可以看到Prometheus自带的一些Summary信息，这些信息和Histogram一样在注释中（#HELP和#TYPE）也会显示，如下所示。

 在上述例子中，可以看到基于Go语言编写的Prometheus的gc总次数是1907，耗时0.193642882s，其中中位数（quantile=0.5）计算的耗时为4.8366e-05s，代表1907次中50%的次数是小于4.8366e-05s的。

Summary类型的样本也会提供3种指标，假设指标名称为<basename。

Summary和Histogram的异同

Summary的强大之处就是可以利用除法去计算时间的平均值。如果要从Histogram和Summary中计算最近5分钟内的平均请求持续时间http_request_duration_seconds，可以用如下表达式进行。

count本质上是一个计数器，sum通常情况下也会像计数器那样工作。但是<font color=redSummary和Histogram可能观察到负值，比如温度（-20℃），这种情况下会导致观察的总量下降，无法再使用rate函数</font。

比如下面的例子就可以计算过去5分钟内每次响应中返回的平均字节数。

关于这个例子，我们需要注意几点。

·因为http_response_size_bytes_count和http_response_size_bytes_sum是计数器类型，所以必须在计算前先使用rate等函数。

·因为Prometheus的API会有很多handler，所以可以使用without过滤掉handler的返回值。

·PromQL要先执行rate()再执行sum()，不能先执行sum()再执行rate()。

·在统计学上，尤其是计算平均值时，要先进行sum等求和运算再做除法。对一个平均值再求平均是不正确的，如下所示。

count的例子

案例一：计算所有的实例CPU核心数。

count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode=

"system"}) )

案例二：计算单个实例192.168.1.1的CPU核心数。

count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode="system",

instance="192.168.1.1"})

关于prometheus api和prometheus api接口的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 prometheus api的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于prometheus api接口、prometheus api的信息别忘了在本站进行查找喔。