Prometheus: Outil de formatage de règles.

:+1: * :100:

Ouais, ce serait super. La préservation des commentaires est le plus gros (et fondamentalement le seul) problème. Et accord sur la façon de diviser les expressions sur plusieurs lignes.

Ne sommes-nous pas en train d'ajouter ceci à promtool ?

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

Quelques remarques :

• Avec le format de règle 2.x (YAML intégrant PromQL), nous voulons que cela agisse également sur les fichiers YAML.
• Il doit conserver les deux commentaires dans YAML et dans PromQL.
• L'indentation est cruciale (pas seulement les sauts de ligne).
• Il faut voir si certains sauts de ligne en entrée doivent être conservés en sortie (cf. comment le fait gofmt ).
• Partout où une règle est rendue, la même mise en forme doit s'appliquer, en particulier sur les onglets _Alertes_ et _Règles_ de l'interface utilisateur Web de Prometheus. Cela implique que l'AST doit conserver les commentaires (et éventuellement certains sauts de ligne, voir point précédent).

Il devrait conserver les deux commentaires en YAML

Notre bibliothèque YAML actuelle ne le fait pas, mais espère le faire "bientôt".

J'aimerais l'inclure dans ma proposition gsoc. @brian-brazil, pouvez-vous créer un lien vers la bibliothèque YAML à laquelle vous faites référence ?

https://github.com/go-yaml/yaml , mais je limiterais cela au PromQL tel quel.

@brian-brazil Mais comme le PromQL from rules est toujours intégré dans les fichiers YAML, il doit au moins préserver les commentaires YAML, n'est-ce pas ? Sinon, l'outil ne serait pas très utile car personne ne veut perdre ses commentaires au profit du formatage.

Ce serait bien, mais nous pouvons obtenir des avantages sans cela. Je préfère également ne pas dépendre de quelque chose avec un calendrier peu clair pour un projet gsoc.

Commençons par la partie PromQL. La partie YAML devrait être presque triviale une fois que la bibliothèque conserve les commentaires et des choses comme l'indice d'indentation |2 pour les chaînes multilignes.

D'accord!

La v3 de la bibliothèque YAML est sortie, ce qui devrait permettre tout cela.

Pour info règle parfaitement lisible en configuration

(
    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 sa représentation des ordures dans l'interface utilisateur Web

(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 Je pense que vous avez publié une autre règle de l'interface utilisateur Web. aussi @beorn7 je commence à travailler sur ce problème.

voici ce que cela me montre pour votre règle :

(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 Oui, j'ai confondu deux règles.

comme cela est toujours ouvert et ajouté dans les idées de projet pour le prochain GSOC (https://github.com/cncf/soc#rule-formatting-tool), j'aimerais travailler sur l'achèvement de cela pendant le GSOC. Toute mise à jour récente et informations supplémentaires à ce sujet seraient appréciées @codesome @brian-brazil @juliusv @geekodour @simonpasquier @sylr .
À la lecture du commentaire et de l'autre lien de référence, il semble que le prochain point d'action consiste à créer un formateur pour l'expression promQL avec l'AST promQL ?

@haibeey Il y a déjà eu des progrès dans cette direction.

Lors de la construction d'un tel formateur, il serait probablement préférable de commencer par ce qui est déjà implémenté ici et d'ajouter un espace blanc et une gestion des commentaires appropriés.

Ce serait également bien, lorsque de telles fonctionnalités pourraient être intégrées au prochain serveur de langage PromQL . Dans le code du serveur de langue, de nombreux éléments nécessaires au formatage des fichiers YAML sont déjà implémentés et il peut être judicieux d'en réutiliser une partie.

bien! Merci @slrtbtfs . Je vais commencer à parcourir les liens partagés dès que possible.

Puis-je aborder ce problème ? J'adorerais mettre en œuvre cela.

Il semble que @haibeey envisage déjà de travailler dessus.

@roidelapluie J'en ai déjà implémenté une partie bien avant. C'est juste que je n'avais pas mentionné ici.

Pour info règle parfaitement lisible en configuration

(
    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 sa représentation des ordures dans l'interface utilisateur Web

(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

Ce style de formatage est-il acceptable ? @codesome @juliusv @brian-brazil @beorn7
J'écris ma proposition sur la base de ce style.

La représentation finale après le formatage peut être discutée et décidée pendant la période GSoC (peut-être même maintenant si un mainteneur veut intervenir, mais je n'ai pas la bande passante pour l'examiner pour le moment). Je suggérerais (à tous les aspirants GSoC) de se concentrer sur _comment_ pourriez-vous y parvenir.

https://prometheus.io/docs/practices/rules/ utilise les meilleures pratiques.

J'ai écrit un prototype approximatif pour préserver les commentaires en augmentant un peu les règles de grammaire goyacc. s'engager ici https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

Fichier de règles
règle d'enregistrement dans l'interface utilisateur Web

Ça n'a pas l'air bien, les opérateurs ne sont pas sur leur propre ligne

Oh oui. ce commit ne fait pas de formatage. c'est juste pour conserver les commentaires dans promql expr après évaluation pour l'impression.
les versions précédentes ignorent tous les commentaires après évaluation.

J'ai écrit un prototype approximatif pour préserver les commentaires en augmentant un peu les règles de grammaire goyacc. s'engager ici [haibeey@8855667]

Mettre les commentaires dans l'AST semble être une idée raisonnable.

J'ai laissé quelques commentaires sur la mise en œuvre là-bas.

https://prometheus.io/docs/practices/rules/ utilise les meilleures pratiques.

Veuillez ne pas appliquer :

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

plus de

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

Avoir des modificateurs de regroupement en premier est la meilleure pratique, et c'est déjà la façon dont nous l'imprimons - il est très difficile de lire des expressions non triviales autrement.

Oui, j'avais des opinions bien arrêtées à ce sujet au départ. Au début, Prometheus ne prenait en charge que sum(x) by(y) parce qu'il se lisait plus comme de l'anglais pour moi et donc je le préférais de loin, mais pour tout x non trivial, il devient vraiment difficile de voir sur quelles dimensions vous agrégez / en gardant. J'aurais aimé en faire sum by(y) (x) depuis le début et en faire la seule variante légale.

Je n'aime toujours pas du tout le formatage exact sum by (y)(x) et préfère sum by(y) (x) loin

Je pense que chacun a droit à sa propre opinion à ce sujet, je trouve personnellement que la "meilleure pratique" est hideuse, mais, comme toutes les syntaxes sont légales, veuillez ne pas en imposer l'une sur les autres.

L'intérêt d'un outil promfmt est, sinon d'appliquer, au moins "d'approuver" un certain formatage "canonique", très semblable à gofmt , avec toute une chaîne d'arguments derrière.

Oui, le formatage de gofmt n'est le préféré de personne, mais au moins il crée un style cohérent plutôt que plusieurs styles différents, ce qui est une valeur en soi.

En passant, cela est activement recherché pour le GSoC. @haibeey Je vois que vous êtes également intéressé par GSoC. Bien que j'apprécie le travail initial que vous avez effectué maintenant, j'apprécierais des discussions ouvertes et un partage de conception, dans la proposition GSoC ou autre, pour une coordination plus facile des projets dans GSoC :)

La préservation des commentaires est déjà très bien prise en charge dans la nouvelle bibliothèque go-yamlv3. La mise en œuvre est si irréprochable qu'il n'y a aucune perte de commentaires. Par conséquent, nous pouvons conserver le mécanisme de préservation indépendant du code Prometheus sans aucun souci.

bien. Je suppose qu'il est temps de partager ma proposition de projet de proposition de GSoC .

Des critiques seraient appréciées avant la version finale. Merci

@Harkishen-Singh Il existe deux niveaux de commentaires : les commentaires YAML et les commentaires dans une expression PromQL. https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849 parlait de ceux de PromQL (mais ceux de YAML seraient également bons à préserver).

La préservation des commentaires est déjà très bien prise en charge dans la nouvelle bibliothèque go-yamlv3. La mise en œuvre est si irréprochable qu'il n'y a aucune perte de commentaires. Par conséquent, nous pouvons conserver le mécanisme de préservation indépendant du code Prometheus sans aucun souci.

Lors de l'évaluation d'une expression PromQL, les commentaires sont supprimés.
Cela dit, je pense que le formatage ne doit pas seulement être effectué dans les fichiers de règles, mais aussi dans certains endroits, comme l'interface utilisateur Web. est-ce vrai @juliusv ?
Ainsi, comme l'a souligné @slrtbtfs, la plupart du formatage et de la préservation seraient effectués dans le module Imprimante.

En ce qui concerne les commentaires YAML, il y a des problèmes avec la v3 qui causent des problèmes à Cortex, nous devrions donc éviter tout déploiement supplémentaire jusqu'à ce que tout soit résolu.

Cela dit, je pense que le formatage ne doit pas seulement être effectué dans les fichiers de règles, mais aussi dans certains endroits, comme l'interface utilisateur Web. Est-ce vrai

L'interface utilisateur Web est le seul endroit où cela est fait.