Prometheus 如何用 concurrent-rule-eval 特性并发评估组内独立规则

Prometheus 如何用 concurrent-rule-eval 特性并发评估组内独立规则【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus当一个 Prometheus 规则文件里塞了很多条互不依赖的 recording rule而它们又被放在同一个 rule group 中时默认情况下这个组内的规则是一条接一条按顺序执行的。concurrent-rule-eval特性开关的作用就是改变这一点开启后Prometheus 会检测组内规则之间的依赖关系把没有依赖的规则并发评估从而降低规则组的评估延迟。本文给出从启用特性、调整并发上限到确认生效的完整操作路径。前提条件在 server 模式默认模式下运行 Prometheus。--rules.max-concurrent-evals是仅 server 模式可用的参数Agent 模式本身不执行规则评估不在本文范围内。特性开启前后规则的执行方式根据 feature flags 文档默认情况下规则组之间并发执行但组内规则串行执行——因为某条规则可能引用前面规则的输出作为输入若组内规则之间检测不到依赖关系就没有理由串行执行。启用concurrent-rule-eval后组内不依赖其他规则的规则会被并发评估文档给出的预期收益与代价有潜力改善规则组评估延迟和资源利用率代价是带来更多并发查询负载more concurrent query load。从实现代码可以确认更细的执行顺序见 rules/manager.go 与 rules/group.go加载规则组时AnalyseRules会构建组内规则的依赖关系图每个评估周期把组内规则切分为批次无依赖的规则组成第一批并发执行既有依赖又有被依赖的规则按原顺序逐条串行无被依赖方的规则组成最后一批并发执行当前批次全部完成后才会进入下一批次wg.Wait()卡住批与批之间的推进因此依赖顺序不会被破坏并发数量由一个加权信号量控制上限即--rules.max-concurrent-evals拿不到并发槽位的规则会退化为同步执行。CHANGELOG 中也有对应的行为说明例如 Rules: Do not run rules concurrently if uncertain about dependencies. #15560无法确定依赖时不会并发执行以及 Rules: Support concurrent evaluation for rules queryingALERTSandALERTS_FOR_STATE. #17064。启用特性在启动参数中加入 feature flag。--enable-feature接受逗号分隔的特性名列表concurrent-rule-eval是有效选项之一见 命令参考。在你现有的启动命令上追加该参数即可例如prometheus \ --config.fileprometheus.yml \ --enable-featureconcurrent-rule-eval其中prometheus.yml替换为你自己的配置文件路径。如果同时启用其他特性用逗号拼接在同一个--enable-feature里即可。注意docs/feature_flags.md对这类 feature flag 的总说明这些特性默认关闭因为它们是破坏性变更或处于实验阶段行为可能随版本变化变化会通过 release changelog 通告。调整并发上限特性启用后并发评估数量由独立参数控制--rules.max-concurrent-evals8默认值为4feature flags 文档 与 命令参考 两处一致该参数是全局并发上限不是按规则组划分的命令参考对它的原文说明是Global concurrency limit for independent rules that can run concurrently. When set, query.max-concurrency may need to be adjusted accordingly. Use with server mode only.——也就是说调大规则评估并发后如果整体查询压力顶到 PromQL 引擎的并发上限需要相应检查query.max-concurrency。验证特性已生效1. 通过 features API 确认开关状态API 文档 提供了GET /api/v1/features端点返回当前实例启用/禁用的特性特性按api、promql、rules等类别组织curl http://localhost:9090/api/v1/features响应中rules类别包含concurrent_rule_eval字段。未启用时该值为false启用后为true。以下结构摘自仓库中的测试数据示例features.json仅作字段结构参考不是固定输出{ rules: { concurrent_rule_eval: false, keep_firing_for: true, query_offset: true } }2. 通过规则指标观察评估耗时rules 包会注册一组规则评估相关指标包括prometheus_rule_group_last_duration_seconds、prometheus_rule_group_last_rule_duration_sum_seconds、prometheus_rule_evaluation_failures_total等指标名清单可见 rules/manager_test.go 中的注册断言。启用特性后可对照规则组评估时长类指标观察组内多条独立规则的执行时间变化同时关注查询侧的负载是否如文档所说有所上升。限制与适用边界只有组内互不依赖的规则才会并发跨组本来就是并发的特性不改变这一点存在依赖链的规则仍按串行批次处理评估顺序与不开启特性时保持一致代价是更高的并发查询负载文档明确要求在调整--rules.max-concurrent-evals时可能需要相应调整query.max-concurrency该特性属于默认关闭的 feature flag行为可能随版本变化升级前建议查看 release changelog 中 Rules 相关的条目。如果验证后/api/v1/features返回concurrent_rule_eval: true且规则组评估时长符合预期该特性即可保持启用若发现查询并发压力过高优先手段是把--rules.max-concurrent-evals调回默认值4或更小而不是直接关闭特性。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考