Prometheus: Инструмент форматирования правил.

: +1: *: 100:

Ага, было бы здорово. Сохранение комментариев - самая большая (и в основном единственная) проблема. И соглашение о том, как разбивать выражения на несколько строк.

Разве мы не добавляем это в promtool?

Связанный: https://github.com/prometheus/prometheus/pull/1779

Некоторые наблюдения:

• С форматом правил 2.x (YAML встраивание PromQL) мы хотим, чтобы это действовало и на файлы YAML.
• Он должен сохранять оба комментария в YAML и в PromQL.
• Отступы имеют решающее значение (а не только разрывы строк).
• Необходимо видеть, должны ли определенные разрывы строк во входных данных сохраняться в выходных (см. Как это делает gofmt ).
• Везде, где отображается правило, должно применяться одинаковое форматирование, в частности, на вкладках _Alerts_ и _Rules_ веб-интерфейса Prometheus. Это означает, что AST должен сохранять комментарии (и, возможно, определенные разрывы строк, см. Предыдущий пункт).

Он должен сохранить оба комментария в YAML

Наша текущая библиотека YAML этого не делает, но надеется «скоро».

Я хотел бы включить это в свое предложение по gsoc. @ brian-brazil, можете ли вы сделать ссылку на библиотеку YAML, о которой говорите?

https://github.com/go-yaml/yaml , но я бы ограничил это только PromQL в нынешнем виде.

@ brian-brazil Но поскольку PromQL из правил всегда встраивается в файлы YAML, он, по крайней мере, должен сохранять комментарии YAML, верно? В противном случае инструмент не был бы очень полезным, так как никто не хочет терять свои комментарии из-за форматирования.

Было бы неплохо, но и без этого мы можем получить выгоду. Я бы также предпочел не зависеть от чего-то с нечеткими сроками для проекта gsoc.

Начнем с части PromQL. Часть YAML должна быть почти тривиальной, если библиотека сохраняет комментарии и такие вещи, как подсказка об отступах |2 для многострочных строк.

Ok!

v3 библиотеки YAML отсутствует, что должно позволять все это.

К вашему сведению, прекрасно читаемое правило в конфигурации

(
    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 его представление мусора в веб-интерфейсе

(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 Я думаю, вы разместили другое правило из веб-интерфейса. также @ 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 @ @juliusv @geekodour @simonpasquier @sylr .
После прочтения комментария и другой справочной ссылки кажется, что следующим шагом будет создание средства форматирования для выражения promQL с помощью promQL AST?

@haibeey В этом направлении уже есть прогресс.

При создании такого средства форматирования, вероятно, было бы лучше начать с того, что уже реализовано здесь, и добавить правильные пробелы и обработку комментариев.

Было бы также хорошо, если бы такие функции могли быть интегрированы с готовящимся к выпуску языковым сервером PromQL . Внутри кода языкового сервера уже реализовано множество вещей, необходимых для форматирования файлов YAML, и может иметь смысл повторно использовать некоторые из них.

хорошо! Спасибо @slrtbtfs . Я начну просматривать ссылки, которыми поделились, как можно скорее.

Могу я заняться этим вопросом? Хотел бы реализовать это.

Похоже, @haibeey уже как-то планирует над этим работать.

@roidlapluie Я уже реализовал часть этого раньше. Просто я здесь не упомянул.

К вашему сведению, прекрасно читаемое правило в конфигурации

(
    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 его представление мусора в веб-интерфейсе

(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 @
Я пишу свое предложение исходя из этого стиля.

Окончательное представление после форматирования можно обсудить и принять решение в течение периода GSoC (может быть, даже сейчас, если кто-либо из сопровождающих захочет вмешаться, но у меня нет пропускной способности, чтобы просмотреть его в данный момент). Я бы посоветовал (всем кандидатам GSoC) сосредоточиться на том, как бы вы этого достигли.

https://prometheus.io/docs/practices/rules/ использует лучшие практики.

Я написал черновой прототип, чтобы сохранить комментарии, немного дополнив правила грамматики гояцкого языка. совершить здесь https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

Файл правил
правило записи в веб-интерфейсе

Это выглядит неправильно, операторы не на своей линии

о, да. этот коммит не выполняет форматирование. это просто сохранить комментарии в выражении promql после оценки для печати.
предыдущие версии игнорируют все комментарии после оценки.

Я написал черновой прототип, чтобы сохранить комментарии, немного дополнив правила грамматики гояцкого языка. совершить здесь [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 - это когда комментарии удаляются.
Тем не менее, я думаю, что форматирование должно выполняться не только в файлах правил, но и в некоторых местах, например, в веб-интерфейсе. это правда @juliusv ?
Итак, как указано в @slrtbtfs, большая часть форматирования и сохранения будет выполняться в модуле принтера.

Что касается комментариев YAML, есть проблемы с v3, которые вызывают проблемы для Cortex, поэтому нам следует избегать дальнейшего развертывания этого, пока все не будет решено.

Тем не менее, я думаю, что форматирование должно выполняться не только в файлах правил, но и в некоторых местах, например, в веб-интерфейсе. Это правда

Веб-интерфейс - единственное место, где это делается.