尧图网站建设 
Prometheus Mixin 实战指南用 Jsonnet 构建可复用的告警规则与 Grafana 仪表盘【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheusPrometheus Mixin 是 Prometheus 仓库内置的一套「可配置、可复用、可扩展」的告警规则与 Grafana 仪表盘模板通过 Jsonnet 声明式描述一条命令即可编译为可直接加载的prometheus_alerts.yaml与一组 Grafana 仪表盘 JSON。本文基于仓库documentation/prometheus-mixin/目录的实际实现讲清 Mixin 的目录结构、构建流程、核心配置项、告警规则清单与面板设计思路读完你可以直接在自己的监控栈中落地这套官方「监控自身的 Prometheus」方案。一、Mixin 是什么、在仓库中位于何处Mixin 的定位在 README 中一句话给出一套面向 Prometheus 的、可配置、可复用、可扩展的告警与仪表盘集合。整个实现位于 documentation/prometheus-mixin 目录包含 8 个文件文件职责README.md安装与构建步骤说明Makefile定义fmt、prometheus_alerts.yaml、dashboards_out、lint、jb_install、clean等构建目标jsonnetfile.json声明 Mixin 的外部依赖Grafonnet 库config.libsonnet用户可覆写的_config配置对象mixin.libsonnet将 config dashboards alerts 三个模块合并的入口alerts.libsonnet全部 Prometheus 自身告警规则的定义alerts.jsonnet告警编译入口输出 YAML 文档dashboards.libsonnet两个 Grafana 仪表盘的完整定义dashboards.jsonnet仪表盘编译入口按字段拆分输出为独立 JSON 文件入口文件 mixin.libsonnet 只有三行体现了 Mixin 的模块化合并方式(import config.libsonnet) (import dashboards.libsonnet) (import alerts.libsonnet)三个模块通过对象字段扩展符::字段修饰符注入到同一个对象上最终合并为prometheusAlerts与grafanaDashboards两个顶层字段再分别由两个编译入口消费。二、环境准备jsonnet、jsonnetfmt 与 jbREADME 要求安装jsonnetv0.13与jbjsonnet-bundler。若已具备可用的 Go 开发环境README 给出的最简安装方式是$ go install github.com/google/go-jsonnet/cmd/jsonnetlatest $ go install github.com/google/go-jsonnet/cmd/jsonnetfmtlatest $ go install github.com/jsonnet-bundler/jsonnet-bundler/cmd/jblatestREADME 特别提醒make lint与make fmt目标依赖jsonnetfmt二进制它从 Go 版 jsonnet 的 v0.16.0 起可用若本地 jsonnet 版本低于 0.16.0需要升级或改用 C 版 jsonnet 的jsonnetfmt否则这两个目标无法工作。在documentation/prometheus-mixin/目录下安装依赖$ jb installjsonnetfile.json 声明了唯一的运行时依赖——Grafana 官方的 Grafonnet 库gen/grafonnet-latest子目录jb install会把它拉入本目录的vendor/供仪表盘定义中import github.com/grafana/grafonnet/...使用。三、构建产物告警 YAML 与仪表盘 JSON依赖安装完成后即可执行 README 中的两个构建命令$ make prometheus_alerts.yaml $ make dashboards_out从 Makefile 可以看到它们背后的具体动作prometheus_alerts.yaml: mixin.libsonnet config.libsonnet alerts.libsonnet—— 依赖三个源文件执行jsonnet -S alerts.jsonnet $。编译入口 alerts.jsonnet 只有一行std.manifestYamlDoc((import mixin.libsonnet).prometheusAlerts)即把prometheusAlerts对象序列化为标准 Prometheus 规则文件 YAML。dashboards_out: ...—— 先mkdir -p dashboards_out再执行jsonnet -J vendor -m dashboards_out dashboards.jsonnet。入口 dashboards.jsonnet 对grafanaDashboards对象的每个字段分别渲染因此dashboards_out/下会得到一个字段对应一个 JSON 文件prometheus.json与prometheus-remote-write.json。make lint会先校验所有.libsonnet/.jsonnet文件的格式用jsonnetfmt -n 2 --max-blank-lines 2 --string-style s --comment-style s做 diff随后运行promtool check rules prometheus_alerts.yaml用官方命令行工具验证编译出的告警规则本身合法。这一目标也说明该目录的产物预期被promtool直接消费与 docs/command-line/promtool.md 中描述的规则检查能力对应。四、核心配置项config.libsonnet详解config.libsonnet 定义了一个_config私有字段对象是所有告警与面板查询模板化的变量来源。逐项说明prometheusSelector默认jobprometheus作为标签选择器拼接到所有 PromQL 查询中用于识别哪些被采集实例是 Prometheus 服务器自身。若你的监控中 Prometheus 的job标签不是prometheus覆写此值即可全局生效。prometheusHAGroupLabels默认空字符串逗号分隔的标签串标识同一高可用组同构配置的 Prometheus 集群内的实例且这些标签会保留在 HA 组级别告警的结果中。置空则完全不生成 HA 相关告警——这一点在 alerts.libsonnet 中有直接体现规则列表末尾用if $._config.prometheusHAGroupLabels then self.rulesWithoutHA else self.rulesWithHA做条件分支。prometheusName默认{{$labels.instance}}插入告警 annotations 中用于称呼受影响的实例。注释给出 Prometheus Operator 场景的推荐写法{{$labels.namespace}}/{{$labels.pod}}。prometheusHAGroupName默认{{$labels.job}}插入 annotations 用于称呼 HA 组其中使用的标签必须同时出现在prometheusHAGroupLabels中否则告警渲染时取不到值。nonNotifyingAlertmanagerRegEx默认空标记「不属于生产通知集群」的 Alertmanager 实例的正则匹配alertmanager标签例如http://test-alertmanager\..*。它专用于PrometheusErrorSendingAlertsToAnyAlertmanager告警避免一个仍在运行的测试/审计 Alertmanager 把「生产 Alertmanager 全部挂掉」的故障掩盖掉。grafanaPrometheus子对象prefix: Prometheus / 仪表盘标题前缀、tags: [prometheus-mixin]Grafana 标签、refresh: 60s默认刷新间隔。showMultiCluster默认true与clusterLabel默认cluster控制仪表盘是否为多集群场景生成cluster变量与按集群分组的查询单集群环境可将其覆写为false查询会退回纯prometheusSelector形式。从源码结构看_config使用::私有且可外部扩展修饰符定义这正是 Jsonnet Mixin 的标准做法下游消费者例如你自己的监控仓库只需import该 Mixin 并在对象上扩展同名字段即可完成本地化定制无需修改 Mixin 源码。五、告警规则全览alerts.libsonnetalerts.libsonnet 在prometheus规则组中定义了 19 条常驻告警 按 HA 配置条件追加 14 条。全部表达式都通过% $._config把prometheusSelector等配置值格式化注入。按主题分组梳理配置与服务发现告警表达式核心持续严重度PrometheusBadConfigmax_over_time(prometheus_config_last_reload_successful[5m]) 010mcriticalPrometheusSDRefreshFailureincrease(prometheus_sd_refresh_failures_total[10m]) 020mwarningPrometheusKubernetesListWatchFailuresincrease(prometheus_sd_kubernetes_failures_total[5m]) 015mwarningPrometheusTargetSyncFailureincrease(prometheus_target_sync_failed_total[30m]) 05mcriticalPrometheusBadConfig与若干其他告警的表达式前都带有注释说明为何要对 gauge 使用max_over_time包裹——否则 scrape 失败会造成假阴性源文件注释引用了 Robust Perception 关于 gauge 告警的最佳实践。通知链路AlertmanagerPrometheusNotificationQueueRunningFull用predict_linear(prometheus_notifications_queue_length[5m], 60*30) min_over_time(prometheus_notifications_queue_capacity[5m])预测 30 分钟内队列将满for: 15mwarning。PrometheusErrorSendingAlertsToSomeAlertmanagers发往某个Alertmanager 的告警中错误率超过 1%for: 15mwarning。PrometheusNotConnectedToAlertmanagersmax_over_time(prometheus_notifications_alertmanagers_discovered[5m]) 1完全没连上任何 Alertmanagerfor: 10mwarning。PrometheusErrorSendingAlertsToAnyAlertmanager两条变体min ... 错误率 * 100 3表示所有 Alertmanager 都在出错。无 HA 时用min without (alertmanager)启用 HA 时改用min by (HAGroupLabels)按组判断。critical。存储TSDB与摄入PrometheusTSDBReloadsFailing3 小时内increase(prometheus_tsdb_reloads_failures_total) 0for: 4h。PrometheusTSDBCompactionsFailing3 小时内压缩失败计数增长for: 4h。PrometheusNotIngestingSamplessum without(type) (rate(prometheus_tsdb_head_samples_appended_total[5m])) 0且存在目标元数据或规则即「本应有数据却一条没进」。PrometheusDuplicateTimestamps/PrometheusOutOfOrderTimestamps分别基于prometheus_target_scrapes_sample_duplicate_timestamp_total与prometheus_target_scrapes_sample_out_of_order_total的 5m 速率大于 0。采集限额与目标PrometheusTargetLimitHit、PrometheusLabelLimitHit、PrometheusScrapeBodySizeLimitHit、PrometheusScrapeSampleLimitHit四条均基于对应的prometheus_target_scrape_pool_exceeded_*/prometheus_target_scrapes_exceeded_*计数器 5m 内增长用于提示目标数、标签数、响应体大小、样本数超出 scrape config 中配置的限额而被丢弃。规则引擎与查询引擎PrometheusRuleFailurescritical与PrometheusMissingRuleEvaluationswarning规则组迭代超时丢失评估。PrometheusHighQueryLoadavg_over_time(prometheus_engine_queries[5m]) / max_over_time(prometheus_engine_queries_concurrent_max[5m]) 0.8即查询引擎并发容量低于 20% 可用for: 15m。Remote WritePrometheusRemoteStorageFailurescritical失败样本率超过 1%。表达式中用or同时兼容新旧两套指标名prometheus_remote_storage_failed_samples_total与prometheus_remote_storage_samples_failed_total等这是 Mixin 保持跨版本兼容的典型手法。PrometheusRemoteWriteBehindcritical队列最高时间戳与已发送最高时间戳之差超过 120 秒。PrometheusRemoteWriteDesiredShardswarning期望分片数超过shards_max配置上限annotations 里还嵌套了一次| query查询以直接展示配置的最大分片值。HA 组专属告警仅当配置 prometheusHAGroupLabels 时PrometheusHAGroupNotIngestingSamples整个 HA 组都没有摄入样本critical。PrometheusHAGroupDown组内超过半数实例在过去 5 分钟内 up 时间不足一半critical。PrometheusHAGroupCrashlooping超过半数实例「1 小时内不干净重启 2 次以上」或「30 分钟内重启 5 次以上」critical。源码注释明确指出后两条 critical 告警针对的是整个 HA 组不健康的场景前提是你对单个实例的宕机/崩溃循环已经另有普通告警。六、仪表盘设计dashboards.libsonnetdashboards.libsonnet 定义了两个仪表盘均带固定 UIDOverview9fa0d141-...Remote Writecb079f93-...因此导入 Grafana 后不会冲突或产生重复副本。1. Prometheus Overview标题为Prometheus / Overview由grafanaPrometheus.prefix拼出时间范围now-1h面板按 5 个折叠行组织Prometheus Stats表格面板基于count by (cluster, job, instance, version) (prometheus_build_info)展示实例版本并用time() - process_start_time_seconds计算运行时长。DiscoveryTarget Syncprometheus_target_sync_length_seconds速率单位 ms与Targetsprometheus_sd_discovered_targets堆叠面积图。Retrieval平均抓取间隔偏差prometheus_target_interval_length_seconds的 sum/count 比值对比配置 interval、Scrape failuresbody size limit / sample limit / 重复时间戳 / out of bounds / out of order 五类速率、Appended Samplesprometheus_tsdb_head_samples_appended_total速率。StorageHead Series、Head Chunks两个 gauge 趋势。Query查询速率prometheus_engine_query_duration_seconds_count{sliceinner_eval}速率与各执行阶段 p90 耗时prometheus_engine_query_duration_seconds{quantile0.9}按slice分组。变量系统包含datasource、cluster多集群时、job、instance四个其中cluster变量通过label_values(clusterLabel, prometheus_build_info{...})从prometheus_build_info的标签中动态发现集群名——这就是clusterLabel配置项的作用点。每个面板都有showMultiCluster的两个分支多集群分支的查询与图例都带上cluster维度单集群分支则退化为直接对job/instance聚合。2. Prometheus Remote Write围绕 remote write 队列的完整可观测面变量为datasource、cluster、instance、url面板按行分组Timestamps队列最高入队时间戳与最高已发送时间戳之差及其 5m 速率即「写入延迟」。Samples进入速率与成功 − 丢弃速率的对比表达式同样用or兼容新旧指标名。ShardsCurrent / Max / Min / Desired 四个分片数面板 Shard Capacity、Pending Samples可直接观察自适应分片算法的行为。SegmentsTSDB 当前 WAL 段prometheus_tsdb_wal_segment_current与 remote write 队列消费到的段prometheus_wal_watcher_current_segment对照可判断 remote write 是否落后于 WAL 写入。Misc. RatesDropped / Failed / Retried 样本与 Enqueue Retries 速率。Latencies发送批处理耗时的 p95/p99经典直方图用histogram_quantile(... _bucket)同时额外给出基于原生直方图指标prometheus_remote_storage_sent_batch_duration_seconds的对应查询源码注释说明原生直方图含 NHCB不暴露_bucket序列两组成对的查询对任一采集配置恰好只有一对有数据。七、在自己的仓库中复用这套 MixinMixin 模式的落地方式与 README 尾部指向的 monitoring-mixins 文档一致的惯例在自己的监控仓库中声明对 Prometheus 仓库 Mixin 目录的 jsonnet 依赖然后覆写_config。例如local prometheusMixin import github.com/prometheus/prometheus/documentation/prometheus-mixin/mixin.libsonnet; (import github.com/grafana/grafonnet/gen/grafonnet-latest/main.libsonnet) prometheusMixin { _config:: { prometheusSelector: job~prometheus.*, prometheusHAGroupLabels: cluster,job, prometheusName: {{$labels.namespace}}/{{$labels.pod}}, showMultiCluster: false, }, }上述写法为基于 mixin.libsonnet 与 config.libsonnet 字段扩展语义的示例_config::允许下游对象扩展同名字段。之后复用 Makefile 中的同款命令jsonnet -S ...、jsonnet -J vendor -m dashboards_out ...生成告警 YAML 与仪表盘 JSON并可用promtool check rules prometheus_alerts.yaml做格式校验。八、适用前提与限制工具链前提Go 版 jsonnetv0.13跑make fmt/make lint需 v0.16 的jsonnetfmt与jb依赖通过jb install引入vendor/。该 Mixin 监控的对象是Prometheus 服务器自身的指标prometheus_*前提是 Prometheus 实例已被自身或同组其他实例采集并且jobprometheus选择器与实际标签匹配——否则所有告警都不会触发。README 自称 “work in progress”目标是成为告警与仪表盘的范例但尚未完全定型make clean会删除dashboards_out/与prometheus_alerts.yaml两个生成产物仓库中默认不包含这些编译结果需自行构建。HA 相关告警默认关闭需要显式配置prometheusHAGroupLabels才会生成annotations 中引用的标签必须与该字段声明一致。以上所有文件均可在仓库documentation/prometheus-mixin/目录下逐一查看构建与校验流程完全由 Makefile 声明可复制、可复现。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Prometheus Mixin 实战指南：用 Jsonnet 构建可复用的告警规则与 Grafana 仪表盘
Prometheus Mixin 实战指南用 Jsonnet 构建可复用的告警规则与 Grafana 仪表盘【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheusPrometheus Mixin 是 Prometheus 仓库内置的一套「可配置、可复用、可扩展」的告警规则与 Grafana 仪表盘模板通过 Jsonnet 声明式描述一条命令即可编译为可直接加载的prometheus_alerts.yaml与一组 Grafana 仪表盘 JSON。本文基于仓库documentation/prometheus-mixin/目录的实际实现讲清 Mixin 的目录结构、构建流程、核心配置项、告警规则清单与面板设计思路读完你可以直接在自己的监控栈中落地这套官方「监控自身的 Prometheus」方案。一、Mixin 是什么、在仓库中位于何处Mixin 的定位在 README 中一句话给出一套面向 Prometheus 的、可配置、可复用、可扩展的告警与仪表盘集合。整个实现位于 documentation/prometheus-mixin 目录包含 8 个文件文件职责README.md安装与构建步骤说明Makefile定义fmt、prometheus_alerts.yaml、dashboards_out、lint、jb_install、clean等构建目标jsonnetfile.json声明 Mixin 的外部依赖Grafonnet 库config.libsonnet用户可覆写的_config配置对象mixin.libsonnet将 config dashboards alerts 三个模块合并的入口alerts.libsonnet全部 Prometheus 自身告警规则的定义alerts.jsonnet告警编译入口输出 YAML 文档dashboards.libsonnet两个 Grafana 仪表盘的完整定义dashboards.jsonnet仪表盘编译入口按字段拆分输出为独立 JSON 文件入口文件 mixin.libsonnet 只有三行体现了 Mixin 的模块化合并方式(import config.libsonnet) (import dashboards.libsonnet) (import alerts.libsonnet)三个模块通过对象字段扩展符::字段修饰符注入到同一个对象上最终合并为prometheusAlerts与grafanaDashboards两个顶层字段再分别由两个编译入口消费。二、环境准备jsonnet、jsonnetfmt 与 jbREADME 要求安装jsonnetv0.13与jbjsonnet-bundler。若已具备可用的 Go 开发环境README 给出的最简安装方式是$ go install github.com/google/go-jsonnet/cmd/jsonnetlatest $ go install github.com/google/go-jsonnet/cmd/jsonnetfmtlatest $ go install github.com/jsonnet-bundler/jsonnet-bundler/cmd/jblatestREADME 特别提醒make lint与make fmt目标依赖jsonnetfmt二进制它从 Go 版 jsonnet 的 v0.16.0 起可用若本地 jsonnet 版本低于 0.16.0需要升级或改用 C 版 jsonnet 的jsonnetfmt否则这两个目标无法工作。在documentation/prometheus-mixin/目录下安装依赖$ jb installjsonnetfile.json 声明了唯一的运行时依赖——Grafana 官方的 Grafonnet 库gen/grafonnet-latest子目录jb install会把它拉入本目录的vendor/供仪表盘定义中import github.com/grafana/grafonnet/...使用。三、构建产物告警 YAML 与仪表盘 JSON依赖安装完成后即可执行 README 中的两个构建命令$ make prometheus_alerts.yaml $ make dashboards_out从 Makefile 可以看到它们背后的具体动作prometheus_alerts.yaml: mixin.libsonnet config.libsonnet alerts.libsonnet—— 依赖三个源文件执行jsonnet -S alerts.jsonnet $。编译入口 alerts.jsonnet 只有一行std.manifestYamlDoc((import mixin.libsonnet).prometheusAlerts)即把prometheusAlerts对象序列化为标准 Prometheus 规则文件 YAML。dashboards_out: ...—— 先mkdir -p dashboards_out再执行jsonnet -J vendor -m dashboards_out dashboards.jsonnet。入口 dashboards.jsonnet 对grafanaDashboards对象的每个字段分别渲染因此dashboards_out/下会得到一个字段对应一个 JSON 文件prometheus.json与prometheus-remote-write.json。make lint会先校验所有.libsonnet/.jsonnet文件的格式用jsonnetfmt -n 2 --max-blank-lines 2 --string-style s --comment-style s做 diff随后运行promtool check rules prometheus_alerts.yaml用官方命令行工具验证编译出的告警规则本身合法。这一目标也说明该目录的产物预期被promtool直接消费与 docs/command-line/promtool.md 中描述的规则检查能力对应。四、核心配置项config.libsonnet详解config.libsonnet 定义了一个_config私有字段对象是所有告警与面板查询模板化的变量来源。逐项说明prometheusSelector默认jobprometheus作为标签选择器拼接到所有 PromQL 查询中用于识别哪些被采集实例是 Prometheus 服务器自身。若你的监控中 Prometheus 的job标签不是prometheus覆写此值即可全局生效。prometheusHAGroupLabels默认空字符串逗号分隔的标签串标识同一高可用组同构配置的 Prometheus 集群内的实例且这些标签会保留在 HA 组级别告警的结果中。置空则完全不生成 HA 相关告警——这一点在 alerts.libsonnet 中有直接体现规则列表末尾用if $._config.prometheusHAGroupLabels then self.rulesWithoutHA else self.rulesWithHA做条件分支。prometheusName默认{{$labels.instance}}插入告警 annotations 中用于称呼受影响的实例。注释给出 Prometheus Operator 场景的推荐写法{{$labels.namespace}}/{{$labels.pod}}。prometheusHAGroupName默认{{$labels.job}}插入 annotations 用于称呼 HA 组其中使用的标签必须同时出现在prometheusHAGroupLabels中否则告警渲染时取不到值。nonNotifyingAlertmanagerRegEx默认空标记「不属于生产通知集群」的 Alertmanager 实例的正则匹配alertmanager标签例如http://test-alertmanager\..*。它专用于PrometheusErrorSendingAlertsToAnyAlertmanager告警避免一个仍在运行的测试/审计 Alertmanager 把「生产 Alertmanager 全部挂掉」的故障掩盖掉。grafanaPrometheus子对象prefix: Prometheus / 仪表盘标题前缀、tags: [prometheus-mixin]Grafana 标签、refresh: 60s默认刷新间隔。showMultiCluster默认true与clusterLabel默认cluster控制仪表盘是否为多集群场景生成cluster变量与按集群分组的查询单集群环境可将其覆写为false查询会退回纯prometheusSelector形式。从源码结构看_config使用::私有且可外部扩展修饰符定义这正是 Jsonnet Mixin 的标准做法下游消费者例如你自己的监控仓库只需import该 Mixin 并在对象上扩展同名字段即可完成本地化定制无需修改 Mixin 源码。五、告警规则全览alerts.libsonnetalerts.libsonnet 在prometheus规则组中定义了 19 条常驻告警 按 HA 配置条件追加 14 条。全部表达式都通过% $._config把prometheusSelector等配置值格式化注入。按主题分组梳理配置与服务发现告警表达式核心持续严重度PrometheusBadConfigmax_over_time(prometheus_config_last_reload_successful[5m]) 010mcriticalPrometheusSDRefreshFailureincrease(prometheus_sd_refresh_failures_total[10m]) 020mwarningPrometheusKubernetesListWatchFailuresincrease(prometheus_sd_kubernetes_failures_total[5m]) 015mwarningPrometheusTargetSyncFailureincrease(prometheus_target_sync_failed_total[30m]) 05mcriticalPrometheusBadConfig与若干其他告警的表达式前都带有注释说明为何要对 gauge 使用max_over_time包裹——否则 scrape 失败会造成假阴性源文件注释引用了 Robust Perception 关于 gauge 告警的最佳实践。通知链路AlertmanagerPrometheusNotificationQueueRunningFull用predict_linear(prometheus_notifications_queue_length[5m], 60*30) min_over_time(prometheus_notifications_queue_capacity[5m])预测 30 分钟内队列将满for: 15mwarning。PrometheusErrorSendingAlertsToSomeAlertmanagers发往某个Alertmanager 的告警中错误率超过 1%for: 15mwarning。PrometheusNotConnectedToAlertmanagersmax_over_time(prometheus_notifications_alertmanagers_discovered[5m]) 1完全没连上任何 Alertmanagerfor: 10mwarning。PrometheusErrorSendingAlertsToAnyAlertmanager两条变体min ... 错误率 * 100 3表示所有 Alertmanager 都在出错。无 HA 时用min without (alertmanager)启用 HA 时改用min by (HAGroupLabels)按组判断。critical。存储TSDB与摄入PrometheusTSDBReloadsFailing3 小时内increase(prometheus_tsdb_reloads_failures_total) 0for: 4h。PrometheusTSDBCompactionsFailing3 小时内压缩失败计数增长for: 4h。PrometheusNotIngestingSamplessum without(type) (rate(prometheus_tsdb_head_samples_appended_total[5m])) 0且存在目标元数据或规则即「本应有数据却一条没进」。PrometheusDuplicateTimestamps/PrometheusOutOfOrderTimestamps分别基于prometheus_target_scrapes_sample_duplicate_timestamp_total与prometheus_target_scrapes_sample_out_of_order_total的 5m 速率大于 0。采集限额与目标PrometheusTargetLimitHit、PrometheusLabelLimitHit、PrometheusScrapeBodySizeLimitHit、PrometheusScrapeSampleLimitHit四条均基于对应的prometheus_target_scrape_pool_exceeded_*/prometheus_target_scrapes_exceeded_*计数器 5m 内增长用于提示目标数、标签数、响应体大小、样本数超出 scrape config 中配置的限额而被丢弃。规则引擎与查询引擎PrometheusRuleFailurescritical与PrometheusMissingRuleEvaluationswarning规则组迭代超时丢失评估。PrometheusHighQueryLoadavg_over_time(prometheus_engine_queries[5m]) / max_over_time(prometheus_engine_queries_concurrent_max[5m]) 0.8即查询引擎并发容量低于 20% 可用for: 15m。Remote WritePrometheusRemoteStorageFailurescritical失败样本率超过 1%。表达式中用or同时兼容新旧两套指标名prometheus_remote_storage_failed_samples_total与prometheus_remote_storage_samples_failed_total等这是 Mixin 保持跨版本兼容的典型手法。PrometheusRemoteWriteBehindcritical队列最高时间戳与已发送最高时间戳之差超过 120 秒。PrometheusRemoteWriteDesiredShardswarning期望分片数超过shards_max配置上限annotations 里还嵌套了一次| query查询以直接展示配置的最大分片值。HA 组专属告警仅当配置 prometheusHAGroupLabels 时PrometheusHAGroupNotIngestingSamples整个 HA 组都没有摄入样本critical。PrometheusHAGroupDown组内超过半数实例在过去 5 分钟内 up 时间不足一半critical。PrometheusHAGroupCrashlooping超过半数实例「1 小时内不干净重启 2 次以上」或「30 分钟内重启 5 次以上」critical。源码注释明确指出后两条 critical 告警针对的是整个 HA 组不健康的场景前提是你对单个实例的宕机/崩溃循环已经另有普通告警。六、仪表盘设计dashboards.libsonnetdashboards.libsonnet 定义了两个仪表盘均带固定 UIDOverview9fa0d141-...Remote Writecb079f93-...因此导入 Grafana 后不会冲突或产生重复副本。1. Prometheus Overview标题为Prometheus / Overview由grafanaPrometheus.prefix拼出时间范围now-1h面板按 5 个折叠行组织Prometheus Stats表格面板基于count by (cluster, job, instance, version) (prometheus_build_info)展示实例版本并用time() - process_start_time_seconds计算运行时长。DiscoveryTarget Syncprometheus_target_sync_length_seconds速率单位 ms与Targetsprometheus_sd_discovered_targets堆叠面积图。Retrieval平均抓取间隔偏差prometheus_target_interval_length_seconds的 sum/count 比值对比配置 interval、Scrape failuresbody size limit / sample limit / 重复时间戳 / out of bounds / out of order 五类速率、Appended Samplesprometheus_tsdb_head_samples_appended_total速率。StorageHead Series、Head Chunks两个 gauge 趋势。Query查询速率prometheus_engine_query_duration_seconds_count{sliceinner_eval}速率与各执行阶段 p90 耗时prometheus_engine_query_duration_seconds{quantile0.9}按slice分组。变量系统包含datasource、cluster多集群时、job、instance四个其中cluster变量通过label_values(clusterLabel, prometheus_build_info{...})从prometheus_build_info的标签中动态发现集群名——这就是clusterLabel配置项的作用点。每个面板都有showMultiCluster的两个分支多集群分支的查询与图例都带上cluster维度单集群分支则退化为直接对job/instance聚合。2. Prometheus Remote Write围绕 remote write 队列的完整可观测面变量为datasource、cluster、instance、url面板按行分组Timestamps队列最高入队时间戳与最高已发送时间戳之差及其 5m 速率即「写入延迟」。Samples进入速率与成功 − 丢弃速率的对比表达式同样用or兼容新旧指标名。ShardsCurrent / Max / Min / Desired 四个分片数面板 Shard Capacity、Pending Samples可直接观察自适应分片算法的行为。SegmentsTSDB 当前 WAL 段prometheus_tsdb_wal_segment_current与 remote write 队列消费到的段prometheus_wal_watcher_current_segment对照可判断 remote write 是否落后于 WAL 写入。Misc. RatesDropped / Failed / Retried 样本与 Enqueue Retries 速率。Latencies发送批处理耗时的 p95/p99经典直方图用histogram_quantile(... _bucket)同时额外给出基于原生直方图指标prometheus_remote_storage_sent_batch_duration_seconds的对应查询源码注释说明原生直方图含 NHCB不暴露_bucket序列两组成对的查询对任一采集配置恰好只有一对有数据。七、在自己的仓库中复用这套 MixinMixin 模式的落地方式与 README 尾部指向的 monitoring-mixins 文档一致的惯例在自己的监控仓库中声明对 Prometheus 仓库 Mixin 目录的 jsonnet 依赖然后覆写_config。例如local prometheusMixin import github.com/prometheus/prometheus/documentation/prometheus-mixin/mixin.libsonnet; (import github.com/grafana/grafonnet/gen/grafonnet-latest/main.libsonnet) prometheusMixin { _config:: { prometheusSelector: job~prometheus.*, prometheusHAGroupLabels: cluster,job, prometheusName: {{$labels.namespace}}/{{$labels.pod}}, showMultiCluster: false, }, }上述写法为基于 mixin.libsonnet 与 config.libsonnet 字段扩展语义的示例_config::允许下游对象扩展同名字段。之后复用 Makefile 中的同款命令jsonnet -S ...、jsonnet -J vendor -m dashboards_out ...生成告警 YAML 与仪表盘 JSON并可用promtool check rules prometheus_alerts.yaml做格式校验。八、适用前提与限制工具链前提Go 版 jsonnetv0.13跑make fmt/make lint需 v0.16 的jsonnetfmt与jb依赖通过jb install引入vendor/。该 Mixin 监控的对象是Prometheus 服务器自身的指标prometheus_*前提是 Prometheus 实例已被自身或同组其他实例采集并且jobprometheus选择器与实际标签匹配——否则所有告警都不会触发。README 自称 “work in progress”目标是成为告警与仪表盘的范例但尚未完全定型make clean会删除dashboards_out/与prometheus_alerts.yaml两个生成产物仓库中默认不包含这些编译结果需自行构建。HA 相关告警默认关闭需要显式配置prometheusHAGroupLabels才会生成annotations 中引用的标签必须与该字段声明一致。以上所有文件均可在仓库documentation/prometheus-mixin/目录下逐一查看构建与校验流程完全由 Makefile 声明可复制、可复现。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考