Prometheus: 规则格式化工具。

:+1: * :100:

是的，那会很棒。 保留评论是最大的（基本上也是唯一的）问题。 并就如何在多行上拆分表达式达成一致。

我们不是正在将它添加到 promtool 中吗？

相关： https :

一些观察：

• 使用 2.x 规则格式（YAML 嵌入 PromQL），我们也希望它对 YAML 文件起作用。
• 它应该保留 YAML 和 PromQL 中的注释。
• 缩进是至关重要的（不仅仅是换行符）。
• 必须查看输入中的某些换行符是否应保留在输出中（参见gofmt是如何做到的）。
• 无论在何处呈现规则，都应应用相同的格式，特别是在 Prometheus Web UI 的 _Alerts_ 和 _Rules_ 选项卡上。 这意味着 AST 需要保留注释（可能还有某些换行符，请参阅上一点）。

它应该在 YAML 中保留两个注释

我们当前的 YAML 库没有这样做，但希望“很快”。

我想将其包含在我的 gsoc 提案中。 @brian-brazil，您可以链接到您所指的 YAML 库吗？

https://github.com/go-yaml/yaml ，但我将其范围仅限于 PromQL 就这样。

@brian-brazil 但是由于规则中的 PromQL 始终嵌入在 YAML 文件中，因此它至少必须保留 YAML 注释，对吗？ 否则该工具将不会很有用，因为没有人想失去他们的评论格式化的好处。

那会很好，但没有它我们也能得到好处。 我也宁愿不依赖于 gsoc 项目时间表不明确的东西。

让我们从 PromQL 部分开始。 一旦库保留了注释和诸如多行字符串的|2缩进提示之类的内容，YAML 部分应该几乎是微不足道的。

好的！

YAML 库的 v3 版本已经发布，这应该允许所有这些。

仅供参考，配置中的完全可读规则

(
    kube_job_status_failed > 0
    UNLESS kube_job_status_succeeded > 0
)
* on (namespace, job_name) group_left(maintainer) label_replace(kube_job_labels, "maintainer", "$1", "label_maintainer", "(.*)")
* on (namespace, job_name) group_left(pager) label_replace(kube_job_labels, "pager", "$1", "label_pager", "(.*)")
* on (namespace, job_name) group_left(paging) label_replace(kube_job_labels, "paging", "$1", "label_paging", "(.*)")

VS 其在 Web UI 中的垃圾表示

(kube_deployment_status_replicas_available
  / kube_deployment_spec_replicas * 100) * on(namespace, deployment) group_left(maintainer)
  label_replace(kube_deployment_labels, "maintainer", "$1", "label_maintainer",
  "(.*)") * on(namespace, deployment) group_left(pager) label_replace(kube_deployment_labels,
  "pager", "$1", "label_pager", "(.*)") * on(namespace,
  deployment) group_left(paging) label_replace(kube_deployment_labels, "paging",
  "$1", "label_paging", "(.*)") < 100

@sylr我认为您从 Web UI 发布了一些其他规则。 还有@beorn7我开始研究这个问题。

这是它为我显示的规则：

(kube_job_status_failed
  > 0 unless kube_job_status_succeeded > 0) * on(namespace, job_name) group_left(maintainer)
  label_replace(kube_job_labels, "maintainer", "$1", "label_maintainer",
  "(.*)") * on(namespace, job_name) group_left(pager) label_replace(kube_job_labels,
  "pager", "$1", "label_pager", "(.*)") * on(namespace,
  job_name) group_left(paging) label_replace(kube_job_labels, "paging", "$1",
  "label_paging", "(.*)")

@geekodour是的，我混淆了两条规则。

由于这仍然是开放的，并添加到即将到来的 GSOC 的项目想法中（https://github.com/cncf/soc#rule-formatting-tool），我想在 GSOC 期间完成这项工作。 任何关于此的最近更新和附加信息将不胜感激@codesome @brian-brazil @juliusv @geekodour @simonpasquier @sylr 。
从阅读评论和其他参考链接来看，下一个行动点似乎是使用 promQL AST 为 promQL 表达式构建格式化程序？

@haibeey在这个方向上已经取得了一些进展。

在构建这样的格式化程序时，最好从这里已经实现的内容开始，并添加适当的空白和注释处理。

当这些功能可以与即将推出的PromQL 语言服务器集成时，这也很好。 在语言服务器代码中，许多格式化 YAML 文件所需的东西已经实现，重用其中的一些可能是有意义的。

好吧！ 谢谢@slrtbtfs 。 我将开始仔细阅读共享的链接尽快。

我可以处理这个问题吗？ 很想实现这一点。

看起来@haibeey已经以某种方式计划在这方面开展工作。

@roidelapluie我之前已经实现了其中的一部分。 只是这里我没有提到。

仅供参考，配置中的完全可读规则

(
    kube_job_status_failed > 0
    UNLESS kube_job_status_succeeded > 0
)
* on (namespace, job_name) group_left(maintainer) label_replace(kube_job_labels, "maintainer", "$1", "label_maintainer", "(.*)")
* on (namespace, job_name) group_left(pager) label_replace(kube_job_labels, "pager", "$1", "label_pager", "(.*)")
* on (namespace, job_name) group_left(paging) label_replace(kube_job_labels, "paging", "$1", "label_paging", "(.*)")

VS 其在 Web UI 中的垃圾表示

(kube_deployment_status_replicas_available
  / kube_deployment_spec_replicas * 100) * on(namespace, deployment) group_left(maintainer)
  label_replace(kube_deployment_labels, "maintainer", "$1", "label_maintainer",
  "(.*)") * on(namespace, deployment) group_left(pager) label_replace(kube_deployment_labels,
  "pager", "$1", "label_pager", "(.*)") * on(namespace,
  deployment) group_left(paging) label_replace(kube_deployment_labels, "paging",
  "$1", "label_paging", "(.*)") < 100

这种格式样式可以接受吗？ @codesome @juliusv @brian-brazil @beorn7
我正在根据这种风格写我的提案。

格式化后的最终表示可以在 GSoC 期间讨论和决定（即使现在如果任何维护者想要加入，但我目前没有带宽来审查它）。 我建议（对所有 GSoC 有志者）专注于_如何_实现这一目标。

https://prometheus.io/docs/practices/rules/使用最佳实践。

我编写了一个粗略的原型，通过稍微增加 goyacc 语法规则来保留注释。 在这里提交https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

规则文件
web ui中的录制规则

看起来不对，运营商不在自己的线上

哦是的。 该提交不进行格式化。 它只是在评估打印后保留 promql expr 中的注释。
以前的版本在评估后忽略所有评论。

我编写了一个粗略的原型，通过稍微增加 goyacc 语法规则来保留注释。 在这里提交 [haibeey@8855667]

将注释放在 AST 中似乎是一个合理的想法。

我在那里留下了一些关于实施的评论。

https://prometheus.io/docs/practices/rules/使用最佳实践。

请不要强制执行：

sum without (instance)(instance_path:requests:rate5m{job="myjob"})

超过

sum(instance_path:requests:rate5m{job="myjob"}) without (instance)

首先拥有分组修饰符是最佳实践，并且已经是我们打印它的方式 - 否则很难阅读非平凡的表达式。

是的，我最初对此有强烈的看法。 起初 Prometheus 只支持sum(x) by(y)因为它对我来说读起来更像英语，因此我更喜欢它，但是对于任何非平凡的x很难看出你正在聚合什么维度/ 保持。 我希望我从一开始就让它成为sum by(y) (x)并且使它成为唯一的合法变体。

我仍然完全不喜欢sum by (y)(x)的确切格式，更喜欢sum by(y) (x) （对我来说更有意义），不知道为什么我们选择在文档中选择后者。

我认为每个人都有权对此发表自己的意见，我个人认为“最佳实践”是可怕的，但是，由于所有语法都是合法的，因此请不要强制执行任何一种。

promfmt工具的全部意义在于，如果不强制执行，至少“认可”某种“规范”格式，非常类似于gofmt ，其背后带有一整串参数。

是的， gofmt的格式不是任何人的最爱，但至少它创造了一种一致的风格，而不是许多不同的风格，这本身就是一种价值。

作为旁注，GSoC 正在积极寻求这一点。 @haibeey我看到您也对 GSoC 感兴趣。 虽然我感谢您现在所做的前期工作，但我希望能在 GSoC 提案或其他方面进行一些公开讨论和设计共享，以便更轻松地协调 GSoC 中的项目:)

新的 go-yamlv3 库已经很好地支持注释保留。 实现是如此完美，以至于没有任何评论丢失。 因此，我们可以毫无顾虑地保持独立于 Prometheus 代码的保存机制。

好吧。 我想是时候分享我的提案草案GSoC 提案了。

在最终草案之前，将不胜感激。 谢谢

@Harkishen-Singh 有两个级别的注释：YAML 注释和 PromQL 表达式中的注释。 https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849 正在谈论 PromQL 的（但 YAML 的也可以很好地保留）。

新的 go-yamlv3 库已经很好地支持注释保留。 实现是如此完美，以至于没有任何评论丢失。 因此，我们可以毫无顾虑地保持独立于 Prometheus 代码的保存机制。

在 PromQL 表达式的计算过程中，注释被删除。
也就是说，我认为格式化不仅要在规则文件中完成，而且在某些地方也可以完成，例如 web ui。 这是真的@juliusv吗？
正如@slrtbtfs所指出的那样，大部分格式化和保留将在打印机模块中完成。

关于 YAML 注释，v3 的问题会导致 Cortex 出现问题，因此我们应该避免进一步推出该问题，直到问题全部解决。

也就是说，我认为格式化不仅要在规则文件中完成，而且在某些地方也可以完成，例如 web ui。 这是真的

Web ui 是唯一完成的地方。