Prometheus: ルールフォーマットツール。

：+1：*：100：

うん、それは素晴らしいだろう。 コメントの保存は最大の（そして基本的に唯一の）問題です。 そして、式を複数の行に分割する方法についての合意。

これをpromtoolに追加している最中ではありませんか？

関連： https ：

いくつかの観察：

• 2.xルール形式（PromQLを埋め込んだYAML）では、これがYAMLファイルにも作用するようにします。
• YAMLとPromQLの両方のコメントを保持する必要があります。
• インデントは非常に重要です（改行だけではありません）。
• 入力の特定の改行を出力に保持する必要があるかどうかを確認する必要があります（ gofmt実行方法を参照）。
• ルールがレンダリングされる場合は常に、特にPrometheus WebUIの_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の部分はほとんど簡単になります。

Ok！

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 WebUIでのガベージ表現

(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 WebUIから他のルールを投稿したと思います。 また@ 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はい、2つのルールを混同しました。

これはまだ開いており、今後のGSOC（https://github.com/cncf/soc#rule-formatting-tool）のプロジェクトのアイデアに追加されているので、GSOC中にこれの完了に取り組みたいと思います。 このに関するすべての最新のアップデートおよび追加情報ブライアン・ブラジル@juliusv @geekodour @simonpasquier @sylr @ @codesomeをいただければ幸いです。
コメントやその他の参照リンクを読むと、次のアクションポイントはpromQLASTを使用してpromQL式のフォーマッターを構築することだと思われますか？

@haibeeyその方向にはすでにいくらかの進歩がありました。

このようなフォーマッタを構築するときは、ここですでに実装されて

このような機能を今後のPromQL言語サーバーと統合できると

大丈夫！ @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 WebUIでのガベージ表現

(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

ルールファイル
WebUIでのルールの記録

それは正しく見えません、演算子は彼ら自身のラインにありません

そうそう。 そのコミットはフォーミングを行いません。 印刷の評価後、promqlexprにコメントを保存するだけです。
以前のバージョンでは、評価後にすべてのコメントが無視されます。

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のフォーマットは誰もが好きではありませんが、少なくともそれ自体が価値である多くの異なるスタイルではなく、1つの一貫したスタイルを作成します。

ちなみに、これはGSoCで積極的に求められています。 @haibeeyあなたもGSoCに興味を持っているようです。 あなたが今行った先行作業に感謝しますが、GSoCでのプロジェクトの調整を容易にするために、GSoCの提案などで、いくつかのオープンな議論と設計の共有をいただければ幸いです:)

コメントの保存は、新しいgo-yamlv3ライブラリですでに非常によくサポートされています。 実装は非常に完璧なので、コメントが失われることはありません。 したがって、Prometheusコードから独立したメカニズムを維持することができます。

大丈夫。 私の提案ドラフトGSoC提案を共有する時が来たと思います。

最終ドラフトの前にレビューをいただければ幸いです。 ありがとう

@ Harkishen-Singhコメントには、YAMLコメントとPromQL式内のコメントの2つのレベルがあります。 https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849はPromQLのものについて話していました（ただし、YAMLのものも保存しておくとよいでしょう）。

コメントの保存は、新しいgo-yamlv3ライブラリですでに非常によくサポートされています。 実装は非常に完璧なので、コメントが失われることはありません。 したがって、Prometheusコードから独立したメカニズムを維持することができます。

PromQL式の評価中は、コメントが削除されたときです。
そうは言っても、フォーマットはルールファイルだけでなく、WebUIのような場所でも行われるべきだと思います。 これは本当の@juliusvですか？
したがって、 @ slrtbtfsで指摘されている

YAMLコメントに関連して、Cortexの問題を引き起こしているv3の問題があるため、それがすべて解決されるまで、それ以上のロールアウトを回避する必要があります。

そうは言っても、フォーマットはルールファイルだけでなく、WebUIのような場所でも行われるべきだと思います。 これは本当ですか

WebUIはそれが行われる唯一の場所です。