简单的promql和Prometheus rule的获取

前言

各种exporter和开源软件metrics端点通常有特别多的指标，也会随着版本进行持续的更新，我们往往也不能逐一而全面地进行了解，本文分享笔者另辟蹊径（实则偷懒），考虑通过直观的dashboard和一些开源的分享来获取自己想要的promQL表达式（主要是用于做alett后续的Prometheus rule）的过程。

dashboard

既然已经集成了exporter或metrics，可以直接拿官方或者社区支持对应的dashboard先对现有的指标项进行分析。

来源1 grafana dashboard shop

找到对应的模板在grafana导入即可，不做赘述

Dashboards | Grafana Labs

这里是图上排名第一的NodeExporter的dashboard

NodeExporter

我们查看它的配置文件，找到对应的promQL表达式，也可以在dashboard web下载了json文件进行检索

需要修改占位方式和格式才能正常使用，因为grafana的模板有一定的格式和dashboard自己的聚合

拿这个promQL拿给GPT/大模型/AI进行调整，主要的调整有去除很多的/以及一些占位符$，daoshboard的聚合变量，以及grafana的动态变量，读者如果熟悉promQL当然可以自己进行调整

“expr”: “(sum by(instance) (irate(node_cpu_seconds_total{instance=“node”,job=“job”, mode!=“idle”}[__rate_interval])) / on(instance) group_left sum by (instance)((irate(node_cpu_seconds_total{instance=“node”,job=“job”}[__rate_interval])))) * 100”,

到Prometheus进行验证，我再次去除了instance的筛选

(sum by(instance) (irate(node_cpu_seconds_total{job=“node-exporter”, mode!=“idle”}[5m]))) / on(instance) group_left sum by (instance) (irate(node_cpu_seconds_total{job=“node-exporter”}[5m])) * 100

由于开源的exporter和dashboard有时候不会完全同步，如现在的grafana dashboard有一些应用已经停止更新了很久，如cilium和hubble相关，但实际上exporter和metrics依然在发展，此时需要我们去跟踪变化和自定义dashboard了

来源2 exporter github中的dashboard或者部分博客分析的自用dashboard

这种就看社区和维护/开发者是否有提供帮助了，如果已经有了。

来源3 kube-Prometheus提供的默认Prometheus rule和runbook

在安装使用kube-Prometheus时，有一些默认的规则，具体的告警项和说明可以在github上查到
链接：https://github.com/prometheus-operator/runbooks/tree/main/content/runbooks

awesome-Prometheus-alerts项目

github star很多，但部分指标名可能需要重新确认。如下面提到的JVM exporter指标在笔者使用的版本有不同，尚未求证哪边版本新。
https://samber.github.io/awesome-prometheus-alerts/rules
sum by (instance)(jvm_memory_bytes_used{area=“heap”}) / sum by (instance)(jvm_memory_bytes_max{area=“heap”}) * 100网页上的对不上（吐槽一下jvm_memory_bytes_used和jvm_memory_used_bytes就改个单词顺序为什么要改呢）

优点是各种常见的metrics和exporter指标都有，包括oliver006/redis_exporter ,prometheus/mysqld_exporter ,Kubernetes : kube-state-metrics 等，具体的查看下面从github上获取的列表

??Rules

Basic resource monitoring

Prometheus self-monitoring
Host/Hardware
Docker Containers
Blackbox
Windows
VMWare
Netdata

Databases and brokers

MySQL
PostgreSQL
SQL Server
Patroni
PGBouncer
Redis
MongoDB
RabbitMQ
Elasticsearch
Cassandra
Zookeeper
Kafka
Pulsar
Nats
Solr
Hadoop

Reverse proxies and load balancers

Nginx
Apache
HaProxy
Traefik

Runtimes

PHP-FPM
JVM
Sidekiq

Orchestrators

Kubernetes
Nomad
Consul
Etcd
Linkerd
Istio
ArgoCD

Other

Thanos
Loki
Promtail
Cortex
Jenkins

noalert

中文支持的，主要是node exporter和Prometheus自身
https://prometheus.noalert.cloud/zh

大模型

由于promQL的语法结构相对没有特别复杂，且其实很多的开源项目和技术博客也会分享其使用的promQL，就比如上面提到的这两个，大模型的语料库应该还是很多很靠谱的，只要描述清楚，通常也是可以直接拿来使用的
问题容易出现的问题是，部分exporter和metrics端点会随着版本的升级更新了对应的指标名，或删除了部分指标，或特性开启才收集的指标，如果不能用的话，需要使用者进一步的去学习使用，所以推荐是使用可联网或者语料库较新的AI如chatGPT4 newbing，如果使用chatGPT3.5，很有可能遇到改过指标名的情况。

我的建议是，去Prometheus查看实际收集的指标名，以及查看官方文档是否有在不同的版本对指标名有做调整

以及查看对应的指标有的标签，以作后续的聚合和筛选

自定义promQL

有些时候用到的东西可能不是开源的，如自定义指标，还有一些新增的dashboard未覆盖的指标，或者一些没有上面的支持的如rocketMQ，cilium,只能自己去琢磨promQL了。

这里建议到Prometheus官网查看promQL教程

Migration | Prometheus

CR PrometheusRule

笔者使用kube-Prometheus方案，链接
所以要对上述的规则进行CR化的处理以挂载到Prometheus中，对应的crd名字是PrometheusRule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: node-context-switching-high-rule
  namespace: monitoring # 根据实际情况指定namespace
spec:
  groups:
  - name: node-performance-rules
    rules:
    - alert: NodeContextSwitchingHigh
      expr: rate(node_context_switches_total[5m])/count without(mode,cpu) (node_cpu_seconds_total{mode="idle"}) > 2000
      for: 0m
      labels:
        severity: warning
      annotations:
        description: "5分钟内平均每核心的上下文切换数超过阈值，value: {{ $value }}"
        summary: " 节点CPU上下文切换高 (Instance: {{ $labels.instance }})"

具体来说，要指明命名空间，promQL，告警级别和分组。参见Prometheus operator对应的文档

一段时间后（由operator获取到CR并刷新Prometheus实例后），能在Prometheus web查看到对应的告警，和直接配置Prometheus不同的是，这种方式的好处在于manifest得到了复用和持久化以及一定的隔离（当然保存一个完整的alert配置也是可以的）

另外，默认的kube-Prometheus安装manifest也有一些默认的对K8S控制面和node的默认Prometheusrule，读者也可以自行apply之后进行查看。

结语

全部拿别人的指标虽然能用，上生产之前，还是需要对告警的promQL有足够的认知。而且别人设置的值是否对我们自己的系统有帮助，是否需要调整，哪些指标是需要关注的点，还是需要考量的。

本文到此结束，下一次，我们将对alertmanager和告警处理，以及指标的告警流程的指定做更加详细的说明。

CodeBuug