Prometheus: Herramienta de formato de reglas.

: +1: *: 100:

Sí, eso sería genial. Conservar los comentarios es el mayor (y básicamente el único) problema. Y acuerdo sobre cómo dividir expresiones en varias líneas.

¿No estamos en medio de agregar esto a promtool?

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

Algunas observaciones:

• Con el formato de regla 2.x (YAML incrustando PromQL), queremos que esto también actúe en archivos YAML.
• Debe conservar tanto los comentarios en YAML como en PromQL.
• La sangría es crucial (no solo los saltos de línea).
• Debe verse si ciertos saltos de línea en la entrada deben conservarse en la salida (cf. cómo lo hace gofmt ).
• Dondequiera que se represente una regla, se debe aplicar el mismo formato, en particular en las pestañas _Alerts_ y _Rules_ de la interfaz de usuario web de Prometheus. Esto implica que el AST necesita mantener comentarios (y posiblemente ciertos saltos de línea, consulte el punto anterior).

Debe conservar ambos comentarios en YAML

Nuestra biblioteca YAML actual no hace esto, pero espera hacerlo "pronto".

Me gustaría incluir esto en mi propuesta de gsoc. @ brian-brazil, ¿puedes vincular a la biblioteca YAML a la que te refieres?

https://github.com/go-yaml/yaml , pero lo limitaría solo al PromQL tal como está.

@ brian-brazil Pero dado que PromQL de las reglas siempre está incrustado en archivos YAML, al menos tiene que preservar los comentarios YAML, ¿verdad? De lo contrario, la herramienta no sería muy útil ya que nadie quiere perder sus comentarios del beneficio del formato.

Sería bueno, pero podemos obtener beneficios sin eso. También prefiero no depender de algo con una línea de tiempo poco clara para un proyecto de gsoc.

Comencemos con la parte de PromQL. La parte YAML debería ser casi trivial una vez que la biblioteca conserva comentarios y cosas como la sugerencia de sangría |2 para cadenas de varias líneas.

¡OK!

v3 de la biblioteca YAML está fuera, lo que debería permitir todo esto.

FYI regla perfectamente legible en configuración

(
    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 su representación de basura en la interfaz de usuario 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 Creo que publicaste alguna otra regla de la interfaz de usuario web. también @ beorn7 Estoy empezando a trabajar en este tema.

esto es lo que me muestra para tu regla:

(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 Sí, mezclé dos reglas.

Dado que esto todavía está abierto y agregado en ideas de proyectos para el próximo GSOC (https://github.com/cncf/soc#rule-formatting-tool), me gustaría trabajar en la finalización de esto durante GSOC. Cualquier actualización reciente e información adicional al respecto sería apreciada @codesome @ brian-brazil @juliusv @geekodour @simonpasquier @sylr .
Al leer el comentario y otro enlace de referencia, parece que el siguiente punto de acción es crear un formateador para la expresión promQL con promQL AST.

@haibeey Ya ha habido algunos avances en esa dirección.

Al construir un formateador de este tipo, probablemente sería mejor comenzar con lo que ya está implementado aquí y agregar el espacio en blanco adecuado y el manejo de comentarios.

También sería bueno, cuando tales características pudieran integrarse con el próximo servidor de lenguaje PromQL . Dentro del código del servidor de idiomas, muchas de las cosas que se necesitan para formatear archivos YAML ya están implementadas, y podría tener sentido reutilizar algunas de ellas.

¡bien! Gracias @slrtbtfs . Comenzaré a examinar los enlaces compartidos lo antes posible.

¿Puedo ocuparme de este tema? Me encantaría implementar esto.

Parece que @haibeey de alguna manera ya está planeando trabajar en esto.

@roidelapluie Ya he implementado una parte mucho antes. Es solo que no lo había mencionado aquí.

FYI regla perfectamente legible en configuración

(
    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 su representación de basura en la interfaz de usuario 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

¿Es aceptable este estilo de formato? @codesome @juliusv @ brian-brazil @ beorn7
Estoy escribiendo mi propuesta basándome en este estilo.

La representación final después del formateo se puede discutir y decidir durante el período GSoC (tal vez incluso ahora si algún mantenedor quiere intervenir, pero no tengo el ancho de banda para revisarlo en este momento). Sugeriría (a todos los aspirantes a GSoC) que se concentren en _cómo_ lograrían esto.

https://prometheus.io/docs/practices/rules/ utiliza las mejores prácticas.

Escribí un prototipo aproximado para preservar los comentarios aumentando un poco las reglas gramaticales de goyacc. comete aquí https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

Archivo de reglas
regla de grabación en la interfaz de usuario web

Eso no parece correcto, los operadores no están en su propia línea

Oh si. ese compromiso no hace formmating. es solo para conservar los comentarios en promql expr después de la evaluación para imprimirlos.
las versiones anteriores ignoran todos los comentarios después de la evaluación.

Escribí un prototipo aproximado para preservar los comentarios aumentando un poco las reglas gramaticales de goyacc. comprometerse aquí [haibeey @ 8855667]

Poner los comentarios en el AST parece una idea razonable.

Ahí dejé algunos comentarios sobre la implementación.

https://prometheus.io/docs/practices/rules/ utiliza las mejores prácticas.

Por favor, no haga cumplir:

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

sobre

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

Tener modificadores de agrupación primero es la mejor práctica, y ya es la forma en que lo imprimimos; de lo contrario, es muy difícil leer expresiones no triviales.

Sí, inicialmente tenía fuertes opiniones sobre esto. Al principio, Prometheus solo admitía sum(x) by(y) porque me parecía más en inglés y, por lo tanto, lo prefería mucho, pero para cualquier x no trivial se vuelve realmente difícil ver en qué dimensiones está agregando / mantener. Desearía haberlo hecho sum by(y) (x) desde el principio y haberlo hecho la única variante legal.

Todavía no me gusta el formato exacto sum by (y)(x) y prefiero sum by(y) (x) (tiene mucho más sentido para mí), no estoy seguro de por qué elegimos el último en los documentos.

Creo que todo el mundo tiene derecho a tener su propia opinión al respecto. Personalmente, considero que la "mejor práctica" es espantosa, pero, como todas las sintaxis son legales, no imponga una sobre las demás.

El objetivo de una herramienta promfmt es, si no hacer cumplir, al menos "respaldar" un cierto formato "canónico", muy parecido a gofmt , con toda una serie de argumentos detrás.

Sí, el formato de gofmt no es el favorito de nadie, pero al menos crea un estilo consistente en lugar de muchos diferentes, lo cual es un valor en sí mismo.

Como nota al margen, esto se ha buscado activamente para el GSoC. @haibeey Veo que también estás interesado en GSoC. Si bien aprecio el trabajo inicial que ha realizado ahora, agradecería algunas discusiones abiertas y compartir el diseño, en la propuesta GSoC o de otra manera, para facilitar la coordinación de proyectos en GSoC :)

La conservación de comentarios ya se admite muy bien en la nueva biblioteca go-yamlv3. La implementación es tan impecable que no hay pérdida de comentarios. Por lo tanto, podemos mantener el mecanismo de conservación independiente del código de Prometheus sin preocupaciones.

bien. Supongo que es hora de compartir mi propuesta, el borrador de la propuesta de GSoC .

Se agradecerían las revisiones antes del borrador final. Gracias

@ Harkishen-Singh Hay dos niveles de comentarios: comentarios YAML y comentarios dentro de una expresión PromQL. https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849 estaba hablando de los de PromQL (pero sería bueno conservar los de YAML también).

La conservación de comentarios ya se admite muy bien en la nueva biblioteca go-yamlv3. La implementación es tan impecable que no hay pérdida de comentarios. Por lo tanto, podemos mantener el mecanismo de conservación independiente del código de Prometheus sin preocupaciones.

Durante la evaluación de una expresión PromQL es cuando se eliminan los comentarios.
Dicho esto, creo que el formateo no solo se debe realizar en archivos de reglas, sino también en algunos lugares, como la interfaz de usuario web. ¿Es esto cierto @juliusv ?
Entonces, como lo señaló @slrtbtfs, la mayor parte del formateo y la conservación se realizarían en el módulo Impresora.

En relación con los comentarios de YAML, hay problemas con la v3 que están causando problemas a Cortex, por lo que deberíamos evitar un mayor despliegue de eso hasta que todo esté resuelto.

Dicho esto, creo que el formateo no solo se debe realizar en archivos de reglas, sino también en algunos lugares, como la interfaz de usuario web. Es esto cierto

La interfaz de usuario web es el único lugar donde se realiza.