Prometheus: Werkzeug zur Formatierung von Regeln.

:+1: * :100:

Ja, das wäre toll. Kommentare zu speichern ist das größte (und im Grunde einzige) Problem. Und Vereinbarung darüber, wie Ausdrücke auf mehrere Zeilen aufgeteilt werden.

Sind wir nicht gerade dabei, das zu promtool hinzuzufügen?

Verwandte: https://github.com/prometheus/prometheus/pull/1779

Einige Beobachtungen:

• Mit dem 2.x-Regelformat (YAML-Einbettung von PromQL) möchten wir, dass dies auch auf YAML-Dateien wirkt.
• Es sollte sowohl Kommentare in YAML als auch in PromQL beibehalten.
• Einrückung ist entscheidend (nicht nur Zeilenumbrüche).
• Es muss geprüft werden, ob bestimmte Zeilenumbrüche in der Eingabe in der Ausgabe erhalten bleiben sollen (vgl. wie gofmt macht).
• Wo immer eine Regel gerendert wird, sollte die gleiche Formatierung gelten, insbesondere auf den Registerkarten _Alerts_ und _Rules_ der Prometheus-Webbenutzeroberfläche. Dies impliziert, dass die AST Kommentare (und möglicherweise bestimmte Zeilenumbrüche, siehe vorheriger Punkt) aufbewahren muss.

Es sollte beide Kommentare in YAML beibehalten

Unsere aktuelle YAML-Bibliothek tut dies nicht, hofft aber "bald".

Ich würde dies gerne in meinen gsoc-Vorschlag aufnehmen. @brian-brazil, können Sie auf die YAML-Bibliothek verlinken, auf die Sie sich beziehen?

https://github.com/go-yaml/yaml , aber ich würde dies nur auf PromQL beschränken, wie es aktuell ist.

@brian-brazil Aber da die PromQL von Rules immer in YAML-Dateien eingebettet ist, muss sie zumindest YAML-Kommentare beibehalten, oder? Andernfalls wäre das Tool nicht sehr nützlich, da niemand seinen Kommentaren den Vorteil der Formatierung verlieren möchte.

Das wäre schön, aber wir können auch ohne Vorteile profitieren. Ich würde mich auch lieber nicht auf etwas mit unklarem Zeitplan für ein gsoc-Projekt verlassen.

Beginnen wir mit dem PromQL-Teil. Der YAML-Teil sollte fast trivial sein, sobald die Bibliothek Kommentare und Dinge wie den |2 Einrückungshinweis für mehrzeilige Zeichenfolgen beibehält.

Okay!

v3 der YAML-Bibliothek ist da, was all dies ermöglichen sollte.

Zu Ihrer Information perfekt lesbare Regel in der Konfiguration

(
    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 seine Mülldarstellung in der Web-Benutzeroberfläche

(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 Ich glaube, Sie haben eine andere Regel über die Web-Benutzeroberfläche gepostet. auch @beorn7 Ich

Folgendes zeigt es für mich für Ihre Regel:

(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 Ja, ich habe zwei Regeln

Da dies noch offen ist und in Projektideen für das kommende GSOC (https://github.com/cncf/soc#rule-formatting-tool) aufgenommen wurde, möchte ich während des GSOC an der Fertigstellung arbeiten. Jedes aktuelle Update und zusätzliche Informationen diesbezüglich wären willkommen @codesome @brian-brazil @juliusv @geekodour @simonpasquier @sylr .
Nach dem Lesen des Kommentars und anderer Referenzlinks scheint der nächste Aktionspunkt darin zu bestehen, einen Formatierer für den promQL-Ausdruck mit dem promQL-AST zu erstellen?

@haibeey Es gab bereits einige Fortschritte in diese Richtung.

Beim Erstellen eines solchen Formatierers ist es wahrscheinlich am besten, mit dem zu beginnen, was hier bereits implementiert ist, und die richtige Leerraum- und Kommentarbehandlung hinzuzufügen.

Schön wäre es auch, wenn solche Features mit dem kommenden PromQL-Sprachserver integriert werden könnten. Im Code des Sprachservers sind viele Dinge, die zum Formatieren von YAML-Dateien erforderlich sind, bereits implementiert, und es kann sinnvoll sein, einige davon wiederzuverwenden.

in Ordung! Danke @slrtbtfs . Ich werde anfangen, die freigegebenen Links so schnell wie möglich zu lesen.

Kann ich dieses Thema aufgreifen? Würde dies gerne umsetzen.

Es sieht so aus, als ob @haibeey bereits irgendwie plant, daran zu arbeiten.

@roidelapluie Einen Teil davon

Zu Ihrer Information perfekt lesbare Regel in der Konfiguration

(
    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 seine Mülldarstellung in der Web-Benutzeroberfläche

(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

Ist dieser Formatierungsstil akzeptabel? @codesome @juliusv @brian-brazil @beorn7
Ich schreibe meinen Vorschlag basierend auf diesem Stil.

Die endgültige Darstellung nach der Formatierung kann während der GSoC-Periode diskutiert und beschlossen werden (vielleicht sogar jetzt, wenn sich ein Betreuer einmischen möchte, aber ich habe im Moment nicht die Bandbreite, um sie zu überprüfen). Ich würde (allen GSoC-Anwärtern) vorschlagen, sich darauf zu konzentrieren, _wie_ Sie dies erreichen würden.

https://prometheus.io/docs/practices/rules/ verwendet die Best Practices.

Ich habe einen groben Prototyp geschrieben, um Kommentare zu erhalten, indem ich die Goyacc-Grammatikregeln ein wenig erweitert habe. Commit hier https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

Regeldatei
Aufzeichnungsregel in der Weboberfläche

Das sieht nicht richtig aus, die Betreiber sind nicht auf eigener Leitung

Oh ja. dieser Commit macht keine Formatierung. es dient nur dazu, Kommentare in promql expr nach der Auswertung für den Druck zu erhalten.
vorherige Versionen ignorieren alle Kommentare nach der Auswertung.

Ich habe einen groben Prototyp geschrieben, um Kommentare zu erhalten, indem ich die Goyacc-Grammatikregeln ein wenig erweitert habe. Begib dich hier [haibeey@8855667]

Es scheint eine vernünftige Idee zu sein, die Kommentare in den AST zu setzen.

Ich habe dort einige Kommentare zur Implementierung hinterlassen.

https://prometheus.io/docs/practices/rules/ verwendet die Best Practices.

Bitte nicht erzwingen:

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

Über

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

Die Gruppierungsmodifikatoren zuerst zu verwenden, ist die beste Methode, und wir drucken sie bereits aus - es ist sonst sehr schwierig, nicht triviale Ausdrücke zu lesen.

Ja, ich hatte anfangs eine starke Meinung dazu. Anfangs unterstützte Prometheus nur sum(x) by(y) weil es sich für mich eher wie Englisch las und ich es daher sehr vorzog, aber für jedes nicht-triviale x wird es wirklich schwer zu sehen, über welche Dimensionen Sie aggregieren / halten. Ich wünschte, ich hätte es einfach von Anfang an sum by(y) (x) und das zur einzigen legalen Variante gemacht.

Ich mag die genaue Formatierung sum by (y)(x) immer noch überhaupt nicht und bevorzuge sum by(y) (x) (macht für mich viel mehr Sinn), nicht sicher, warum wir uns für letzteres in den Dokumenten entschieden haben.

Ich denke, jeder hat ein Recht auf seine eigene Meinung dazu, ich persönlich finde die "Best Practice" abscheulich, aber da alle Syntaxen legal sind, erzwingen Sie bitte nicht eine über die anderen.

Der Sinn eines promfmt Tools besteht darin, eine bestimmte "kanonische" Formatierung, sehr ähnlich wie gofmt , mit einer ganzen Reihe von Argumenten dahinter zu "befürworten", wenn nicht sogar zu erzwingen.

Ja, die Formatierung von gofmt ist niemandes Favorit, aber es erzeugt zumindest einen konsistenten Stil statt vieler verschiedener, was an sich schon ein Wert ist.

Als Randnotiz wird dies für die GSoC aktiv angestrebt. @haibeey Ich sehe, dass du dich auch für GSoC interessierst. Während ich die Vorarbeit, die Sie jetzt geleistet haben, schätze, würde ich mich über einige offene Diskussionen und Designfreigaben im GSoC-Vorschlag oder auf andere Weise freuen, um die Koordination von Projekten in GSoC zu erleichtern :)

Die Kommentarerhaltung wird in der neuen go-yamlv3-Bibliothek bereits sehr gut unterstützt. Die Umsetzung ist so einwandfrei, dass keine Kommentare verloren gehen. Daher können wir den Erhaltungsmechanismus bedenkenlos unabhängig vom Prometheus-Code halten.

in Ordung. Ich denke, es ist an der Zeit, meinen Vorschlagsentwurf für den GSoC-Vorschlag zu teilen.

Bewertungen werden vor dem endgültigen Entwurf geschätzt. Vielen Dank

@Harkishen-Singh Es gibt zwei Ebenen von Kommentaren: YAML-Kommentare und Kommentare innerhalb eines PromQL-Ausdrucks. https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849 sprach über die PromQL-Dateien (aber YAML-Dateien wären auch gut zu bewahren).

Die Kommentarerhaltung wird in der neuen go-yamlv3-Bibliothek bereits sehr gut unterstützt. Die Umsetzung ist so einwandfrei, dass keine Kommentare verloren gehen. Daher können wir den Erhaltungsmechanismus bedenkenlos unabhängig vom Prometheus-Code halten.

Bei der Auswertung eines PromQL-Ausdrucks werden die Kommentare entfernt.
Trotzdem denke ich, dass die Formatierung nicht nur in Regeldateien erfolgen muss, sondern auch an einigen Stellen wie der Web-Benutzeroberfläche. ist das wahr @juliusv ?
Wie von @slrtbtfs erwähnt, würde der größte Teil der Formatierung und Beibehaltung im

In Bezug auf YAML-Kommentare gibt es Probleme mit v3, die Cortex Probleme bereiten, daher sollten wir weitere Rollouts vermeiden, bis das alles gelöst ist.

Trotzdem denke ich, dass die Formatierung nicht nur in Regeldateien erfolgen muss, sondern auch an einigen Stellen wie der Web-Benutzeroberfläche. Ist das wahr

Die Web-UI ist der einzige Ort, an dem es getan wird.