Prometheus: Alat pemformatan aturan.

:+1: * :100:

Ya, itu bagus. Mempertahankan komentar adalah masalah terbesar (dan pada dasarnya hanya). Dan kesepakatan tentang cara membagi ekspresi menjadi beberapa baris.

Bukankah kita sedang menambahkan ini ke promtool?

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

Beberapa pengamatan:

• Dengan format aturan 2.x (YAML menyematkan PromQL), kami ingin ini juga berlaku pada file YAML.
• Itu harus mempertahankan kedua komentar di YAML dan di PromQL.
• Indentasi sangat penting (bukan hanya jeda baris).
• Itu harus dilihat apakah jeda baris tertentu dalam input harus dipertahankan dalam output (lih. bagaimana gofmt melakukannya).
• Di mana pun aturan dirender, pemformatan yang sama harus diterapkan, khususnya pada tab _Alerts_ dan _Rules_ pada UI web Prometheus. Ini menyiratkan bahwa AST perlu menyimpan komentar (dan mungkin jeda baris tertentu, lihat poin sebelumnya).

Itu harus mempertahankan kedua komentar di YAML

Pustaka YAML kami saat ini tidak melakukan ini, tetapi berharap untuk "segera".

Saya ingin memasukkan ini ke dalam proposal gsoc saya. @brian-brazil, dapatkah Anda menautkan ke perpustakaan YAML yang Anda maksud?

https://github.com/go-yaml/yaml , tapi saya akan membatasi ini hanya pada PromQL seperti ini.

@brian-brazil Tapi karena PromQL dari aturan selalu tertanam dalam file YAML, setidaknya harus mempertahankan komentar YAML, kan? Jika tidak, alat ini tidak akan sangat berguna karena tidak ada yang ingin kehilangan komentar mereka tentang manfaat pemformatan.

Itu bagus, tapi kita bisa mendapatkan keuntungan tanpa itu. Saya lebih suka juga tidak bergantung pada sesuatu dengan garis waktu yang tidak jelas untuk proyek gsoc.

Mari kita mulai dengan bagian PromQL. Bagian YAML seharusnya hampir sepele setelah perpustakaan menyimpan komentar dan hal-hal seperti petunjuk indentasi |2 untuk string multiline.

Oke!

v3 dari perpustakaan YAML keluar, yang seharusnya memungkinkan untuk semua ini.

FYI aturan yang dapat dibaca dengan sempurna dalam konfigurasi

(
    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 representasi sampahnya di UI 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

@syr Saya pikir Anda memposting beberapa aturan lain dari UI web. juga @ beorn7 Saya mulai mengerjakan masalah ini.

inilah yang ditampilkan untuk saya untuk aturan Anda:

(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 Ya, saya mencampuradukkan dua aturan.

karena ini masih terbuka dan ditambahkan dalam ide proyek untuk GSOC mendatang (https://github.com/cncf/soc#rule-formatting-tool) saya ingin mengerjakan penyelesaian ini selama GSOC. Setiap pembaruan terbaru dan info tambahan mengenai ini akan dihargai @codesome @brian-brazil @juliusv @geekodour @simonpasquier @syr .
Dari membaca komentar dan tautan referensi lainnya, tampaknya titik tindakan selanjutnya adalah membangun formatter untuk ekspresi promQL dengan promQL AST?

@haibeey Sudah ada beberapa kemajuan ke arah itu.

Saat membangun pemformat seperti itu, mungkin akan lebih baik untuk memulai dengan apa yang sudah diterapkan di sini dan menambahkan ruang putih yang tepat dan penanganan komentar.

Alangkah baiknya juga, ketika fitur tersebut dapat diintegrasikan dengan server bahasa PromQL yang akan datang. Di dalam kode server bahasa banyak hal yang diperlukan untuk memformat file YAML sudah diimplementasikan, dan mungkin masuk akal untuk menggunakan kembali sebagian darinya.

Baiklah! Terima kasih @slrtbtfs . saya akan mulai membaca dengan teliti tautan yang dibagikan ASAP.

Bisakah saya mengangkat masalah ini? Akan senang untuk menerapkan ini.

Sepertinya @haibeey entah bagaimana sudah berencana mengerjakan ini.

@roidelapluie Saya sudah mengimplementasikan sebagian darinya sebelumnya. Hanya saja belum saya sebutkan di sini.

FYI aturan yang dapat dibaca dengan sempurna dalam konfigurasi

(
    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 representasi sampahnya di UI 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

Apakah gaya pemformatan ini dapat diterima? @codesome @juliusv @brian-brazil @beorn7
Saya menulis proposal saya berdasarkan gaya ini.

Representasi akhir setelah pemformatan dapat didiskusikan dan diputuskan selama periode GSoC (mungkin bahkan sekarang jika ada pengelola yang ingin bergabung, tetapi saya tidak memiliki bandwidth untuk meninjaunya saat ini). Saya akan menyarankan (untuk semua calon GSoC) untuk fokus pada _bagaimana_ Anda akan mencapai ini.

https://prometheus.io/docs/practices/rules/ menggunakan praktik terbaik.

saya menulis prototipe kasar untuk mempertahankan komentar dengan sedikit menambah aturan tata bahasa goyacc. komit di sini https://github.com/haibeey/prometheus/commit/885566786ac20bfd400b2e7db470c92545919690

File aturan
aturan perekaman di web ui

Itu tidak terlihat benar, operator tidak berada di jalur mereka sendiri

Oh ya. komit itu tidak melakukan pemformatan. itu hanya untuk menyimpan komentar di promql expr setelah evaluasi untuk dicetak.
versi sebelumnya mengabaikan semua komentar setelah evaluasi.

saya menulis prototipe kasar untuk mempertahankan komentar dengan sedikit menambah aturan tata bahasa goyacc. komit di sini [haibeey@8855667]

Menempatkan komentar di AST sepertinya ide yang masuk akal.

Saya telah meninggalkan beberapa komentar tentang implementasi di sana.

https://prometheus.io/docs/practices/rules/ menggunakan praktik terbaik.

Tolong jangan memaksakan:

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

lebih

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

Memiliki pengubah pengelompokan terlebih dahulu adalah praktik terbaik, dan sudah menjadi cara kami mencetaknya - sangat sulit untuk membaca ekspresi non-sepele sebaliknya.

Ya, saya memiliki pendapat yang kuat tentang ini pada awalnya. Pada awalnya Prometheus hanya mendukung sum(x) by(y) karena lebih seperti bahasa Inggris bagi saya dan karenanya saya lebih menyukainya, tetapi untuk x non-sepele apa pun menjadi sangat sulit untuk melihat dimensi apa yang Anda agregasikan / menjaga. Saya berharap saya baru saja membuatnya sum by(y) (x) dari awal dan menjadikannya satu-satunya varian legal.

Saya masih tidak suka sama sekali format sum by (y)(x) dan lebih suka sum by(y) (x) (lebih masuk akal bagi saya), tidak yakin mengapa kami memilih untuk memilih yang terakhir di dokumen.

Saya pikir setiap orang berhak atas pendapatnya sendiri tentang ini, saya pribadi menganggap "praktik terbaik" itu mengerikan, tetapi, karena semua sintaks adalah legal, tolong jangan memaksakan satu di atas yang lain.

Inti dari alat promfmt adalah, jika tidak memaksakan, setidaknya "mendukung" pemformatan "kanonik" tertentu, sangat mirip dengan gofmt , dengan serangkaian argumen di belakangnya.

Ya, pemformatan gofmt 's bukanlah favorit siapa pun, tetapi setidaknya itu menciptakan satu gaya yang konsisten daripada banyak gaya yang berbeda, yang merupakan nilai tersendiri.

Sebagai catatan, ini secara aktif dicari untuk GSoC. @haibeey Saya melihat bahwa Anda juga tertarik dengan GSoC. Sementara saya menghargai pekerjaan awal yang telah Anda lakukan sekarang, saya akan menghargai beberapa diskusi terbuka dan berbagi desain, dalam proposal GSoC atau sebaliknya, untuk koordinasi proyek yang lebih mudah di GSoC :)

Pelestarian komentar sudah didukung dengan sangat baik di perpustakaan go-yamlv3 baru. Implementasinya sangat sempurna sehingga tidak ada komentar yang hilang. Oleh karena itu, kami dapat terus menjaga mekanisme independen dari kode Prometheus tanpa khawatir.

Baiklah. saya rasa sudah saatnya saya membagikan draft proposal GSoC proposal saya .

Ulasan akan dihargai sebelum draft akhir. Terima kasih

@Harkishen-Singh Ada dua tingkat komentar: komentar YAML dan komentar dalam ekspresi PromQL. https://github.com/prometheus/prometheus/issues/21#issuecomment -604213849 berbicara tentang yang PromQL (tetapi yang YAML juga bagus untuk dipertahankan).

Pelestarian komentar sudah didukung dengan sangat baik di perpustakaan go-yamlv3 baru. Implementasinya sangat sempurna sehingga tidak ada komentar yang hilang. Oleh karena itu, kami dapat terus menjaga mekanisme independen dari kode Prometheus tanpa khawatir.

Selama evaluasi ekspresi PromQL adalah saat komentar dihapus.
Yang mengatakan saya pikir pemformatan tidak hanya dilakukan di file aturan tetapi di beberapa tempat juga seperti web ui. apakah ini benar @juliusv ?
Jadi seperti yang ditunjukkan oleh @slrtbtfs sebagian besar pemformatan dan pelestarian akan dilakukan dalam modul Printer.

Sehubungan dengan komentar YAML, ada masalah dengan v3 yang menyebabkan masalah untuk Cortex jadi kami harus menghindari peluncuran lebih lanjut sampai semuanya teratasi.

Yang mengatakan saya pikir pemformatan tidak hanya dilakukan di file aturan tetapi di beberapa tempat juga seperti web ui. Apakah ini benar

Web ui adalah satu-satunya tempat untuk menyelesaikannya.