数据监控-Prometheus/Grafana

原创 已于 2024-02-02 11:12:18 修改 · 1.4k 阅读 · 13 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#prometheus #grafana

于 2024-01-27 13:40:12 首次发布
本文详细介绍了如何使用Prometheus和Grafana进行数据监控，从Prometheus的特点、主要功能、基础架构、组件及其作用，到Grafana的安装与密码修改，再到Prometheus与Grafana的实操，包括安装、配置、集成Node_exporter、PushGateway、Flink和Clickhouse。此外，还讲解了Pushgateway的配置以及Flink和Clickhouse与Prometheus的集成，提供了一站式的监控解决方案。

一、数据监控Prometheus

1、什么是Prometheus

    Prometheus是由SoundCloud开源监控告警解决方案，从2012年开始编写代码，到2015年github上开源以来，吸引不少用户以及公司的使用。Prometheus作为新一代的开源解决方案，很多理念与Google SRE的运维之道不谋而合。

2、Prometheus特点

1.Prometheus是按照Google SRE运维之道的理念构建的，具有实用性和前瞻性的特点。
2.Prometheus一直在优化和巩固
3.Prometheus基于Go语言，性能不错，安装和部署简单，可以实现多平台部署的兼容性。
4.丰富的数据收集客户端，而且官方提供了各种常用的exporter
5.丰富强大的查询能力

3、Prometheus主要功能

1.多维数据模型
2.灵活的查询语句
3.无以来存储，支持local和remote不同类型
4.次啊用http，使用pull（拉）模式，简单移动
5.监控目标，可以采用服务发现或静态配置的方式。
6.支持多种统计数据模型，图形化友好

4、Prometheus基础架构

5、工作流程

指标采集：Prometheus server通过pull形式采集监控指标，可以直接拉取监控指标，也可以通过pushgateway作为中间环节，监控目标首先通过push操作将数据上传到pushgateway。
指标处理：Prometheus server 将次啊及到的数据存储在自身的DB或者第三方的DB上。
指标展示：Prometheus server 通过提供HTTP接口，提供自带或者第三方展示系统，例如Grafana。
指标警告：Prometheus server 通过push告警信息到AlertManager，AlertManager通过静默-抑制-整合-下发这四个阶段处理后通知观察者结果。

支持多种exporter 采集指标数据，还支持 PushGateway 进行数据上报。Prometheus性能足够支撑上万台规模的集群。


6、组件

  • PushGateway（推送网关）

可选，作为数据采集的中间系统，监控目标可以先通过push将数据上传到PushGateway,然后Prometheus server再通过pull的方式将数据采集到

  • Prometheus Server

Prometheus服务器的实例

  • Grafana

可选，这里建议使用，这是第三方的展示工具，可以编写Prom QL的查询语句，通过HTTP协议与Prometheus集成

  • Alter Manager

prometheus的Alerting模块，负责接收告警，例如Prometheus server发送的警告信息，并且通过提供静默-抑制-整合-下发等操作。

7、重点组件介绍

7.1 pushgateway

  • 拓扑图

监控目标通过脚本或者其他的程序push日志到pushgateway中，prometheus通过pull的方式拉取pushgateway的日志

  • pushgateway的重要性

因为Prometheus是以pull的形式采集监控的指标，这样的话就会存在两个这样的问题：

1、每次新增监控目标就需要修改Prometheus的配置

2、如果监控目标所在网络和Prometheus所在网络不通，就无法通过Prometheus的pull形式采集指标

  • Prometheus的缺点

1.pushgateway存在单点问题，如果pushgateway出现故障，所有监控目标都将失败。当然也可以借助LSB来解决单点问题

2.丢失Prometheus对实例健康状态的检查功能

3.取消监控一个服务，需要手动删除pushgateway上对应的持久化数据

  • 单点故障

这里的pushgateway就是进程中的一个单点，这个点如果出现问题的话，就会引起单点问题。

  • API

所有的监控指标的push都通过HTTP接口

7.2 Alert Manager

  • 分组

将警告信息分组，方便应用于当大量报警信息涌入时的通知

  • 静默

安装一定的规则，在一定时间内不进行通知下发，在达到一定的阈值之后，统一下发

  • 抑制

一个告警信息被另一个告警信息抑制后，另一种告警发送之后，该告警不再发送

prometheus正应用于离线数仓中采集监控功能，通过与grafana联合使用，实现采集监控主要监控，通过openstry采集用户行为日志。

二、数据监控之grafana

1、Grafana安装

## 下载grafana的安装包
[root@cdh01 grafana]# wget https://dl.grafana.com/oss/release/grafana-7.5.7-1.x86_64.rpm

## 安装本地的grafana
[root@cdh01 grafana]# yum install grafana-7.5.7-1.x86_64.rpm 

## 启动grafana服务

[root@cdh01 grafana]# systemctl start grafana-server

## Web UI 查看 默认密码 admin/admin
${IP}:3000/login

  • 启动登录页面：

  • 启动成功界面

2、修改密码

三、Prometheus/Grafana实操

1、Prometheus安装

官网：https://prometheus.io/
下载地址：https://prometheus.io/download/
下载linux安装包 prometheus-2

最低0.47元/天 解锁文章
K8S篇之实现利用Prometheus监控pod的实时数据指标
小橙子的笔记屋
11-16 1万+
Prometheus实时监控k8s集群中pod信息指标
K8s（十二）：监控与报警（163邮箱+钉钉）-Prometheus + Grafana + Alertmanager（超详细）
热门推荐
✨ 欢迎来到【Seal ^_^ 的优快云博客】！✨
04-08 3万+
🔴 K8s（十二）：监控与报警（163邮箱+钉钉）-Prometheus + Grafana + Alertmanager（超详细）
Prometheus 和 Grafana科普介绍
weixin_52236586的博客
03-18 1189
是监控和可视化领域的黄金组合。它们广泛应用于系统监控、应用性能监控、Kubernetes 监控、数据库监控和业务监控等场景。• 支持 Prometheus、Elasticsearch、InfluxDB、Graphite、MySQL、PostgreSQL 等多种数据源。• 提供丰富的客户端库（如 Go、Java、Python）和导出器（Exporters），支持多种应用和系统的监控。：监控服务器、虚拟机、容器的 CPU、内存、磁盘、网络等性能指标。• 支持多种图表类型（如折线图、柱状图、饼图、热力图等）。
《数据监控-Prometheus/Grafana》Prometheus/Grafana详细入门教程
https://blog.datasource.space
05-24 2485
Prometheus是由SoundCloud开源监控告警解决方案，从2012年开始编写代码，到2015年github上开源以来，吸引不少用户以及公司的使用。Prometheus作为新一代的开源解决方案，很多理念与Google SRE的运维之道不谋而合。拓扑图监控目标通过脚本或者其他的程序push日志到pushgateway中，prometheus通过pull的方式拉取pushgateway的日志pushgateway的重要性。
Prometheus 指标监控
weixin_46136610的博客
10-24 1012
全面覆盖：支持从底层基础设施（服务器、容器、网络）到上层应用（接口、数据库、缓存）的全链路指标监控；多维度分析：通过标签实现精细化筛选，比如按 “地区、集群、应用、实例” 拆分指标；实时性强：拉取周期可配置（秒级），能快速捕捉系统状态变化；可扩展性高：支持自定义指标（比如在应用中嵌入 Prometheus 客户端，上报业务指标如 “订单支付成功数”），适配复杂业务场景。用可量化的数据，把系统 “看不见的状态” 变成 “看得见的图表”，把 “事后排查” 变成 “事前告警”。
Prometheus和Grafana
qq_35368296的博客
12-24 1万+
1.首先简单介绍Prometheus和Grafana Prometheus是由SoundCloud开发的开源监控报警系统和时间序列数据库（TSDB），它是一个监控采集与数据存储框架（监控服务器端），具体采集什么数据依赖于Exporter（监控客户端），例如：采集MySQL的数据需要使用mysql_exporter，当Prometheus调用mysql_expoter采集到MySQL的监控指标之后，把采集数据存放到Prometheus所在服务器的磁盘数据文件中。它的各个组件基本都是用Golang编写的，对编译
Prometheus+Grafana
记忆的博客
12-19 1624
Prometheus
十七、监控与度量-Prometheus/Grafana/Actuator
princemilo的博客
12-04 1108
系统监控‌在企业级的应用中，系统监控至关重要，可以帮助我们预防故障，预测变化趋势，在达到阈值的时候报警，为排查生产问题提供更多的信息。同时也能看到系统问题，早做优化，避免更大的事故发生。Spring Boot包含了很多附加功能帮助我们监控和管理我们的应用，可以使用HTTP或者JMX等方式通过端点(endpoint)获取应用的健康状态以及其他指标收集。Spring Boot Actuator模块就是Spring Boot提供的集成了上面所述的监控和管理的功能。
《数据监控-Prometheus/Grafana》Prometheus + Grafana + node_exporter实现多台服务器性能监控
https://blog.datasource.space
04-14 9928
Prometheus + Grafana + node_exporter实现多台服务器监控 1 Prometheus安装 ##1. 安装 [root@zxy_master software]# tar -zxvf prometheus-2.17.1.linux-amd64.tar.gz -C /opt/apps/ [root@zxy_master apps]# mv prometheus-2.17.1.linux-amd64/ prometheus-2.17.1 ## 环境变量 [root@zxy_mast
性能监控之prometheus+grafana搭建
weixin_50464533的博客
04-29 2583
Prometheus和Grafana是两个流行的开源工具，用于监控和可视化系统和应用程序的性能指标。它们通常一起使用，提供了强大的监控和数据可视化功能。
day58-liunx监控之prometheus
爪蛙毁一生的博客
08-20 361
今日学习目标: 能够安装prometheus服务器 能够通过安装node_exporter监控远程linux 能够通过安装mysqld_exporter监控远程mysql数据库 能够安装grafana 能够在grafana添加prometheus数据源 能够在grafana添加监控cpu负载的图形 能够在grafana图形显示mysql监控数据 能够通过grafana+onealert实现报警 普罗米修斯 Prometheus(由go语言(golang)开
基于 prometheus 的微服务指标监控
我心飞翔
11-02 864
基于prometheus的微服务指标监控 服务上线后我们往往需要对服务进行监控，以便能及早发现问题并做针对性的优化，监控又可分为多种形式，比如日志监控，调用链监控，指标监控等等。而通过指标监控能清晰的观察出服务指标的变化趋势，了解服务的运行状态，对于保证服务稳定起着非常重要的作用 prometheus是一个开源的系统监控和告警工具，支持强大的查询语言PromQL允许用户实时选择和汇聚时间序列数据，时间序列数据是服务端通过HTTP协议主动拉取获得，也可以通过中间网关来推送时间序列数据，可以通过静态配置文件或服
Prometheus -- 01 -- 什么是Prometheus
Gene Xu
04-15 516
Prometheus 是由前 Google 工程师从 2012 年开始在 SoundCloud 以开源软件的形式进行研发的系统监控和告警工具包，自此以后，许多公司和组织都采用了 Prometheus 作为监控告警工具。Prometheus 的开发者和用户社区非常活跃，它现在是一个独立的开源项目，并且独立于任何公司进行维护。为了证明这一点，Prometheus 于 2016 年 5 月加入 CNC...
prometheus+grafana
zy1207757535的博客
03-04 1652
Prometheus 是使用 Golang 开发的开源监控系统，被人称为下一代监控系统，是为数不多的适合 Docker、Mesos 、Kubernetes 环境的监控系统之一 。 Grafana 是一个开源的图表可视化系统，简言之，其特点在于图表配置比较方便、生成的图表漂亮。 Prometheus + Grafana 监控系统的组合中，前者负责采样数据并存储这些数据；后者则侧重于形象生动的展示...
prometheus
2201_75912662的博客
08-18 2851
无人驾驶车辆运行中要记录的经度，纬度，速度，方向，旁边物体的距离等等。大都为插入操作较多且无更新的需求，插入数据多，每秒钟插入数据可到达千万甚至是上亿条。分析过去时序数据可以做成多纬度报表，揭示其趋势性、规律性、异常性。分析时序数据趋势可以做大数据分析，机器学习，实现预测和预警。按照时间顺序记录系统、设备状态变化的数据被称为时序数据。不依赖分布式存储，单个服务器节点是自主的。数据带有时间属性，且数据量随着时间递增。某一个地区的各车辆的行驶轨迹数据。模型拉去时间序列数据。可以查看到监控的数据。
prometheus与grafana
m0_74158670的博客
09-02 656
它们是独立运行的程序，负责从第三方服务（如 MySQL、Redis）采集原始数据，并将其转换为 Prometheus 要求的格式，通过一个 HTTP 端点（通常是。: Prometheus 自带的一个简单的Web界面，主要用于执行 PromQL 查询和调试。最主流的可视化工具，可以接入 Prometheus 作为数据源，创建丰富、炫酷的监控大盘。时序数据库**中，再通过灵活的查询语言实现监控和告警。它现在是云原生监控领域的事实标准。不仅能查询数据，还能进行丰富的聚合、计算和预测，是告警和可视化的基础。
Prometheus与Grafana的完美结合：打造强大的监控与可视化平台
gjjumin的专栏
10-05 4991
Prometheus是基于Go语言开发的一套开源的监控、告警和时间序列数据库的组合，是由 SoundCloud公司开发（2012年）的开源监控系统。Prometheus于2016年加入CNCF（Cloud Native Computing Foundation ，云原生计算基金会），2018年8月9日Prometheus成为CNCF继Kubernetes之后毕业的第二个项目，它可以监控主机，服务，容器，支持多种exporter采集数据，还支持 pushgateway进行数据上报。
Prometheus
qq_51574973的博客
07-17 1412
每个被监控的主机都可以通过专用的 exporter 程序提供输出监控数据的接口，它会在目标处收集监控数据，并暴露出一个 HTTP 接口供 Prometheus server 查询，Prometheus 通过基于 HTTP 的 pull 的方式来周期性的采集数据。●一些短期运行的作业的生命周期过短，难以有效地将必要的指标数据供给到 Server 端，它们一般会采用推送（Push）方式输出指标数据， Prometheus 借助于 Pushgateway 接收这些推送的数据，进而由 Server 端进行抓取。
( sum( rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [5m]) ) / sum( rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[5m]) ) ) * 100 查询当天的
最新发布
11-20
<think> 我们面对的是一个PromQL查询需求，用户希望计算一个比例：错误日志占总日志的百分比，并且要求查询当天的数据。 原始表达式：(sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [5m])) / sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[5m])))*100 但是，这个表达式没有时间范围限制，用户要求的是“当天的结果”。在Prometheus/Loki中，我们通常有两种方式来处理时间范围： 1. 在PromQL中使用范围向量选择器，但这里我们使用的是rate函数，它已经是一个范围向量（[5m]）的聚合，但返回的是瞬时向量。所以我们需要在查询时指定一个时间范围（即当天）。 2. 在Grafana中，我们通常会设置面板的时间范围，或者在查询时使用相对时间或绝对时间。 然而，用户要求的是在PromQL中查询当天的结果。这意味着我们需要将整个查询放在一个子查询中，并设置一个时间范围（例如1天）的分辨率。 但是，请注意，原始表达式计算的是瞬时错误率（最近5分钟的错误率百分比）。如果我们要计算当天（0点到24点）的每个时间点的错误率，那么我们可以直接使用这个表达式，并在Grafana等面板中设置时间为当天即可。 如果用户想要一个当天的整体错误率（即整个一天内错误日志条数占总日志条数的百分比），那么我们需要重新构造查询。因为rate函数计算的是每秒的速率，然后我们求和，再相除。如果我们想要整天的错误率，我们可以这样： 总错误日志条数 / 总日志条数 * 100 但是，在Prometheus/Loki中，我们通常用count_over_time来统计一段时间内的日志条数（注意：Loki中count_over_time计算的是指定时间范围内每个时间序列的采样点个数，但是这里我们只有一个文件，所以可以认为是一个时间序列？实际上，由于日志是动态增加的，所以我们需要考虑时间范围）。 然而，用户使用的是Loki（因为使用的是{filename=...}这样的日志选择器），所以我们可以这样： 错误日志总数 = count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1d]) 总日志数 = count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1d]) 然后计算：(错误日志总数/总日志数)*100 但是，请注意：用户原来的表达式是计算错误日志的速率占总日志速率的比例，也就是错误日志出现的频率（每秒错误日志条数占总每秒日志条数的比例）。而用count_over_time是计算整天的总条数，然后相除。这两种计算方式在一天内如果日志速率变化不大时可能接近，但如果日志速率波动大，则不同。 用户原来的表达式更关注瞬时错误率，而用户现在要求“当天的结果”，我们需要明确用户想要什么： a) 当天每5分钟的错误率（即时间序列）？ b) 当天整体的错误率（一个单一数值）？ 根据用户的问题描述，他要求的是“在当天的结果”，这个表述可能指两种情况。但通常，如果用户想要一个单一数值（即当天整体的错误百分比），我们可以用上述count_over_time的方法。 然而，用户原来的表达式是使用rate（即速率）来计算的。如果我们想保持和原来表达式一样的含义（即平均错误率），我们可以这样：计算当天的平均错误率。 但是，平均错误率可以有两种方式： 方式1：先分别计算整天的错误日志总数和总日志数，然后相除。即： (sum(count_over_time({filename=...}|~"ERROR"[1d])) / sum(count_over_time({filename=...}[1d]))) * 100 方式2：将每个5分钟的错误率进行平均（但这样会丢失权重，因为每个5分钟的日志量不同）。 方式1更合理，因为它考虑了每个时间段的日志量权重。 因此，我建议： 如果用户想要当天的整体错误率（一个数值）： (sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1d])) / sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1d]))) * 100 如果用户想要当天内每5分钟的错误率（即时间序列），那么用户原来的表达式就足够，只需要在查询时指定时间范围为当天（在Grafana中设置，或者在Prometheus/Loki的API中传入start和end参数）。 但是，用户要求的是在PromQL中查询当天的结果。所以我们需要在表达式中体现时间范围？实际上，PromQL本身不支持在表达式中指定绝对时间范围（如今天），通常我们通过查询时传入的时间范围参数来确定。所以，如果用户想要的是时间序列，那么原来的表达式就可以，只要查询时设置时间为当天即可。 然而，用户的问题明确要求“在当天的结果”，并且要求写在PromQL中。所以，如果用户想要一个单一数值（整体错误率），我们可以用上述count_over_time的方法。如果用户想要时间序列，那么原来的表达式就可以，但需要配合查询时间范围。 由于问题没有明确，我提供两种方案： 方案一（当天整体错误率，返回一个数值）： 表达式： ( sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1d])) / sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1d])) ) * 100 方案二（当天内每5分钟的错误率，返回时间序列）： 表达式保持不变，即为： (sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [5m])) / sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[5m])))*100 但是，在查询时，我们需要设置时间范围为一整天（例如：start=当天0点，end=当天24点，或者使用相对时间范围如1d）。 由于用户要求的是“在PromQL中查询当天的结果”，并且没有明确要求是单一数值还是时间序列，我倾向于认为用户可能想要的是当天内每5分钟的错误率（即时间序列），因为原来的表达式就是为此设计的。但是，如果我们只返回时间序列，那么当天的结果就是多个点。而如果用户想要一个当天的汇总值，那么方案一更合适。 考虑到用户的问题中使用了rate和5m，我推测用户可能想要监控的是当天内错误率的变化情况（即时间序列），所以方案二更符合原始意图。但是，用户特别强调“当天的结果”，这可能是想要一个汇总值。 为了明确，我们可以询问用户，但这里我们只能根据问题猜测。 另外，在Loki中，我们还可以使用子查询来实现：在一天的时间范围内，每5分钟计算一次错误率，这样返回的是当天每5分钟一个点的错误率序列。这其实就是方案二，而且不需要修改表达式，只需要在查询时设置时间范围。 因此，我建议用户： 如果是在Grafana中，设置面板的时间范围为“今天”，然后使用原来的表达式即可。 如果是通过HTTP API查询，那么在请求参数中设置start和end为当天的开始和结束时间戳，然后使用原来的表达式。 但是，如果用户坚持要在PromQL中表达时间范围（即当天的整体错误率），那么我们可以使用方案一。 所以，我提供两种方式： 1. 查询当天整体错误率（单一数值）： ( sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1d])) / sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1d])) ) * 100 2. 查询当天内每5分钟的错误率（时间序列）： (sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [5m])) / sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[5m])))*100 （注意：查询时设置时间范围为当天） 另外，注意：在Loki中，我们可能需要处理标签。这里我们只有一个文件，所以没有标签问题。但如果日志流有多个标签，那么我们需要用sum来聚合所有匹配的日志流。 由于用户原始表达式已经使用了sum，所以这里我们保持不变。 最后，我注意到用户使用的是Loki，而Loki的PromQL风格查询（LogQL）中，rate和count_over_time等函数的使用与Prometheus类似。 因此，根据用户的需求选择对应的表达式。 由于问题没有明确，我提供两种可能，并解释它们的区别。 注意：方案一中的[1d]是固定范围，表示过去1天。如果用户执行查询的时间不是当天的结束（比如在当天中午执行），那么[1d]会包括从昨天同一时间到现在的数据，可能不是完整的当天。所以，为了精确的当天，我们需要使用绝对时间范围（即指定当天的0点到24点）？但PromQL中无法直接指定绝对时间，所以通常我们依赖查询时间。 因此，如果我们用方案一，那么它计算的是从当前时间往前推1天（24小时）的错误率。而用户要求的是“当天”（即从0点到24点），所以可能不精确。为了解决这个问题，我们可以在查询时使用当天的开始和结束时间，然后使用count_over_time，并设置范围为[1d]（但这样还是相对时间）？这并不合适。 实际上，在Loki中，我们可以使用range vector selector配合绝对时间范围（通过查询的start和end参数）来指定count_over_time的范围就是查询的时间范围。但是，在PromQL表达式中，范围向量选择器（如[1d]）是相对当前时间点的。所以，为了得到当天的完整数据，我们必须在查询时设置start和end为当天的0点和24点，然后使用方案一，但将[1d]改为[end-start]这样的区间，但PromQL不支持。 因此，我们可能需要另一种方法：使用子查询，并指定步长。在Loki 2.0及以上，LogQL支持子查询。我们可以这样： (sum by () (count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1d]))) / (sum by () (count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1d]))) * 100 然后在查询时指定时间为当天的0点到24点，这样[1d]会被解释为覆盖整个查询范围（因为查询范围是1天，所以[1d]就是整个范围）。但是，如果查询范围大于1天，那么[1d]只会覆盖最近1天，所以不精确。 所以，更准确的做法是使用查询范围作为区间，但PromQL/LogQL中没有直接表示查询范围区间的语法。不过，在查询时，我们可以将区间设置为大于等于查询范围（比如设置为大于1天，但这样会多取数据）。或者，我们可以使用一个技巧：将范围向量选择器设置为一个很大的值（比如大于一天），然后在count_over_time中，实际计算时会使用整个查询时间范围（因为数据点不会超过查询时间范围）。但是，这样效率可能不高。 考虑到这些，如果用户想要精确的当天（0点到24点）的整体错误率，最好在查询时设置start和end为当天的0点和24点，然后使用以下表达式： ( sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1000d])) # 使用一个足够大的区间，确保覆盖整个查询范围 / sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1000d])) ) * 100 这样，因为查询范围就是当天，所以count_over_time会计算整个查询范围（即当天）的日志条数。 因此，总结如下： 如果用户想要当天的整体错误率（一个数值）： 使用上述表达式（区间用1000d）并在查询时设置start为当天0点，end为当天24点（或第二天0点）。 如果用户想要当天内每5分钟的错误率（时间序列）： 使用原始表达式，并在查询时设置start为当天0点，end为当天24点（或第二天0点），步长（step）设为5m（或其他合适值）。 由于问题复杂，我建议用户根据实际需求选择合适的方案。 最后，由于用户要求的是在PromQL中查询，且用户的问题可能是在Grafana中，所以： 对于方案一（整体错误率）： 在Grafana中，可以创建一个Stat类型的面板，设置时间范围为“今天”，然后使用如下查询： ( sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1000d])) / sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1000d])) ) * 100 这里用1000d是为了覆盖整个查询范围（即今天）。 对于方案二（时间序列）： 在Grafana中，创建一个Graph面板，设置时间范围为“今天”，然后使用原始表达式。 注意：在Loki中，count_over_time和rate等函数支持查询范围自动裁剪，所以即使我们写[1000d]也会被自动限制在查询的时间范围内。 因此，我提供两种方案供用户选择。 </think>### 在PromQL中查询当天错误率百分比 根据您的需求，要查询给定表达式在当天的结果，需要使用 Grafana 的相对时间范围或绝对时间范围功能结合子查询。以下是具体实现方法： #### 方案一：使用 Grafana 时间范围（推荐） 1. **保持原表达式不变**： ```promql (sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [5m])) / sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[5m]))) * 100 ``` 2. **在 Grafana 中设置时间范围**： - 选择 `Today`（今天）作为仪表板时间范围 - 或手动设置绝对时间范围：当天 00:00 至 23:59 #### 方案二：使用子查询（精确到天的聚合） ```promql avg_over_time(( sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [5m])) / sum(rate({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[5m])) )[1d:5m] ) * 100 ``` **说明**： 1. `[1d:5m]`：表示以5分钟为步长，回溯1天的数据 2. `avg_over_time()`：计算一天内的平均值 3. 结果：返回当天错误率的平均值（百分比） #### 方案三：全天错误总数占比（整点统计） ```promql 100 * sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"} |~ "ERROR" [1d])) / sum(count_over_time({filename="/home/hwj/home/grafana_loki/grafana-12.2.1/bin/test.log"}[1d])) ``` **说明**： 1. `count_over_time([1d])`：统计24小时内的总日志量 2. 结果：当天错误日志占总日志的百分比（单一数值） ### 使用建议 1. **监控面板**：方案一最适合在 Grafana 仪表板中显示时间序列 2. **日报统计**：方案三适合生成每日错误率报告 3. **性能优化**：如日志量过大，可增加 `[5m]` 为 `[15m]` 降低精度提升查询速度[^1]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值