Prometheus: Ferramenta de formatação de regra.

: +1: *: 100:

Sim, isso seria ótimo. Preservar comentários é o maior (e basicamente o único) problema. E acordo sobre como dividir expressões em várias linhas.

Não estamos no meio de adicionar isso ao promtool?

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

Algumas observações:

• Com o formato de regra 2.x (YAML incorporando PromQL), queremos que isso atue em arquivos YAML também.
• Deve preservar os comentários em YAML e em PromQL.
• O recuo é crucial (não apenas as quebras de linha).
• Deve-se verificar se certas quebras de linha na entrada devem ser preservadas na saída (cf. como gofmt faz isso).
• Sempre que uma regra é processada, a mesma formatação deve ser aplicada, em particular nas guias _Alerts_ e _Rules_ da IU da Web do Prometheus. Isso implica que o AST precisa manter os comentários (e possivelmente certas quebras de linha, consulte o ponto anterior).

Deve preservar ambos os comentários em YAML

Nossa biblioteca YAML atual não faz isso, mas espera fazer isso "em breve".

Eu gostaria de incluir isso na minha proposta gsoc. @ brian-brazil, você pode fazer um link para a biblioteca YAML de que está se referindo?

https://github.com/go-yaml/yaml , mas eu definiria apenas o PromQL como está.

@ brian-brazil Mas como o PromQL das regras está sempre embutido nos arquivos YAML, ele pelo menos tem que preservar os comentários YAML, certo? Caso contrário, a ferramenta não seria muito útil, pois ninguém quer perder seus comentários o benefício da formatação.

Isso seria bom, mas podemos obter benefícios sem isso. Eu prefiro também não depender de algo com um cronograma incerto para um projeto gsoc.

Vamos começar com a parte do PromQL. A parte YAML deve ser quase trivial, uma vez que a biblioteca preserva comentários e coisas como a dica de indentação |2 para strings de várias linhas.

OK!

A v3 da biblioteca YAML foi lançada, o que deve permitir tudo isso.

Regra perfeitamente legível para a FYI na configuração

(
    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 sua representação de lixo na IU da 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 Acho que você postou alguma outra regra da IU da web. também @ beorn7 estou começando a trabalhar nessa questão.

aqui está o que mostra para mim para sua regra:

(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 Sim, confundi duas regras.

uma vez que ainda está aberto e adicionado em ideias de projeto para o próximo GSOC (https://github.com/cncf/soc#rule-formatting-tool), gostaria de trabalhar na conclusão disso durante o GSOC. Qualquer atualização recente e informações adicionais sobre isso seriam apreciadas @codesome @ brian-brazil @juliusv @geekodour @simonpasquier @sylr .
Ao ler o comentário e outro link de referência, parece que o próximo ponto de ação é construir um formatador para a expressão promQL com o promQL AST?

@haibeey Já houve algum progresso nessa direção.

Ao construir tal formatador, provavelmente seria melhor começar com o que já está implementado aqui e adicionar espaço em branco adequado e tratamento de comentários.

Também seria bom, quando tais recursos pudessem ser integrados ao servidor de linguagem PromQL que está por vir . Dentro do código do servidor de linguagem, muito do que é necessário para formatar arquivos YAML já está implementado e pode fazer sentido reutilizar parte dele.

tudo bem! Obrigado @slrtbtfs . Vou começar a ler os links compartilhados o mais rápido possível.

Posso abordar esse problema? Adoraria implementar isso.

Parece que @haibeey já está planejando trabalhar nisso.

@roidelapluie Eu já implementei parte disso antes. É que eu não tinha mencionado aqui.

Regra perfeitamente legível para a FYI na configuração

(
    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 sua representação de lixo na IU da 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

Este estilo de formatação é aceitável? @codesome @juliusv @ brian-brazil @ beorn7
Estou escrevendo minha proposta com base neste estilo.

A representação final após a formatação pode ser discutida e decidida durante o período GSoC (talvez até agora se algum mantenedor quiser intervir, mas não tenho largura de banda para revisá-la no momento). Eu sugeriria (a todos os aspirantes ao GSoC) que se concentrassem em _como_ você alcançaria isso.

https://prometheus.io/docs/practices/rules/ usa as melhores práticas.

escrevi um protótipo bruto para preservar os comentários, aumentando um pouco as regras da gramática goyacc. comprometa-se aqui https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

Arquivo de regras
regra de gravação na interface do usuário da web

Isso não parece certo, os operadores não estão em sua própria linha

Ai sim. esse commit não faz o formmating. é apenas para preservar os comentários no promql expr após a avaliação para impressão.
as versões anteriores ignoram todos os comentários após a avaliação.

escrevi um protótipo bruto para preservar os comentários, aumentando um pouco as regras da gramática goyacc. comprometa-se aqui [haibeey @ 8855667]

Colocar os comentários no AST parece uma ideia razoável.

Deixei alguns comentários sobre a implementação lá.

https://prometheus.io/docs/practices/rules/ usa as melhores práticas.

Por favor, não imponha:

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

sobre

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

Ter modificadores de agrupamento primeiro é a melhor prática, e já é assim que imprimimos - é muito difícil ler expressões não triviais de outra forma.

Sim, inicialmente tive opiniões fortes sobre isso. No início, o Prometheus suportava apenas sum(x) by(y) porque era mais parecido com o inglês para mim e, portanto, eu o preferia, mas para qualquer x não trivial, torna-se realmente difícil ver sobre quais dimensões você está agregando / guardando. Eu gostaria de tê-lo tornado sum by(y) (x) desde o início e torná-lo a única variante legal.

Ainda não gosto da formatação exata sum by (y)(x) e prefiro muito mais sum by(y) (x) (faz muito mais sentido para mim), não tenho certeza por que optamos pela última nos documentos.

Acho que todos têm o direito de ter sua própria opinião sobre isso. Pessoalmente, considero a "melhor prática" hedionda, mas, como todas as sintaxes são legais, por favor, não imponha uma sobre as outras.

O objetivo de uma ferramenta promfmt é, se não forçar, pelo menos "endossar" uma certa formatação "canônica", muito parecida com gofmt , com uma série de argumentos por trás dela.

Sim, a formatação de gofmt não é a favorita, mas pelo menos cria um estilo consistente em vez de muitos estilos diferentes, o que é um valor em si.

Como observação lateral, isso tem sido procurado ativamente para o GSoC. @haibeey , vejo que você também está interessado no GSoC. Embora eu aprecie o trabalho inicial que você colocou agora, gostaria de algumas discussões abertas e compartilhamento de design, na proposta GSoC ou de outra forma, para facilitar a coordenação de projetos no GSoC :)

A preservação de comentários já é muito bem suportada na nova biblioteca go-yamlv3. A implementação é tão perfeita que não há perda de comentários. Portanto, podemos manter o mecanismo de preservação independente do código do Prometheus sem nenhuma preocupação.

tudo bem. Acho que é hora de compartilhar meu rascunho de proposta de proposta GSoC .

As revisões serão apreciadas antes da versão final. Obrigado

@ Harkishen-Singh Existem dois níveis de comentários: comentários YAML e comentários dentro de uma expressão PromQL. https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849 estava falando sobre os do PromQL (mas os YAML também deveriam ser preservados).

A preservação de comentários já é muito bem suportada na nova biblioteca go-yamlv3. A implementação é tão perfeita que não há perda de comentários. Portanto, podemos manter o mecanismo de preservação independente do código do Prometheus sem nenhuma preocupação.

Durante a avaliação de uma expressão PromQL é quando os comentários são removidos.
Dito isso, acho que a formatação não deve ser feita apenas em arquivos de regras, mas também em alguns lugares, como a interface do usuário da web. isso é verdade @juliusv ?
Como apontado por @slrtbtfs, a maior parte da formatação e preservação seria feita no módulo Impressora.

Em relação aos comentários YAML, há problemas com a v3 que estão causando problemas para o Cortex, portanto, devemos evitar novas implementações até que esteja tudo resolvido.

Dito isso, acho que a formatação não deve ser feita apenas em arquivos de regras, mas também em alguns lugares, como a interface do usuário da web. isso é verdade

A interface do usuário da web é o único lugar onde isso ocorre.