現在のルール ファイル移行ツールは、使用できない出力ファイルを生成します。
小さな問題:
"^(?:ext.|xfs)$"
代わりに"ext.|xfs"
"^(?:ext.|xfs)$"
そのまま出力されますより大きな問題:
promtool fmt
フォーマットを使用する必要があります。最初のものは、Go マップとおそらく YAML ライブラリの動作方法を考えると、修正が難しいようです。
セカンド以降は修正可能です。
3 番目は、おそらく YAML ライブラリのみを使用した場合でもありません。
全体的な決定について、私たちはどのように感じていますか? これまでのところ、移行にいくらかの痛みがあり、YAML にも問題がないわけではないようですが、一般的には作業が簡単なので、この決定を歓迎する人がいると聞いています。
インデントの問題は予期しないものでしたが、全体的に問題を引き起こしたようには見えないので、YAML はまだ道半ばだと思います。
参考までに、私は (いくつかの) ルールを手動で移行し、YAML、go テンプレート、Prometheus のルール言語を組み合わせて、(1) 移行が簡単で、(2) 理解しやすく保守しやすいものにする方法についていくつかの結論に達しました。 3 つの異なるフォーマット/言語と、大きく異なる改行、引用符、および空白の要件の組み合わせは、巨大で不必要な PITA ですが、それは重要ではありません。
このアプローチは、自動化されたツールを作成する場合 (私自身のニーズには大きすぎる) や、手動での移行を支援する場合に役立ちます。 かなり複雑なサンプルの移行ルールから始めますので、努力する価値があるかどうかを理解できます。
- alert: TasksMissing
expr: |
(
# Compare with a matching job-specific threshold, keeping all labels on the left
job_env:up:ratio
<= on(job) group_left()
job:up:ratio_critical_threshold
) or (
# Or select all jobs without a matching job-specific threshold
(
job_env:up:ratio
unless on(job)
job:up:ratio_critical_threshold
)
# And compare with the default threshold, keeping all labels on the left
<= on() group_left()
job:up:ratio_critical_threshold{job=""}
)
for: 1m
labels:
severity: critical
annotations:
summary: Tasks missing for {{ $labels.job }} in {{ $labels.env }}
description:
'{{ with printf `job_env:up:count{job="%s",env="%s"} - job_env:up:sum{job="%s",env="%s"}` $labels.job $labels.env $labels.job $labels.env | query }}
{{- . | first | value -}}
{{ end }}
of
{{ with printf `job_env:up:count{job="%s",env="%s"}` $labels.job $labels.env | query }}
{{- . | first | value -}}
{{ end }}
{{ $labels.job }} instances are missing in {{ $labels.env }}:
{{ range printf `up{job="%s",env="%s"}==0` $labels.job $labels.env | query }}
{{- .Labels.instance }}
{{ end }}'
debug: '{{ externalURL }}{{ printf `up{job="%s",env="%s"}==0` $labels.job $labels.env | graphLink }}'
YAML はインデント、改行、コメントを防ぐために非常に懸命に努力していますが、インデント、改行、コメントを保持できることに注意してください。 基本的に、異なる場所でリテラル ブロック表記と一重引用符付きフロー表記を使用し、特定の引用文字を特定の用途に制限します。
基本的な考え方は
expr: |
ビット) を使用し、ブロック全体をexpr
後ろにインデントします。 これにより、あらゆるフォーマット/インデントを使用し、Prometheus によって解析および削除されるコメントを追加できます (これが、私が YAML への移行のセールス ポイントを実際に購入しない理由です。 )。debug: '
またはdescription:\n '
) を使用し、一重引用符は YAML の使用に制限し、Prometheus 文字列には二重引用符 ( job="foo"
) およびGo テンプレート文字列のバッククォート (たとえば、 printf
ビット)。 これにより、すべての空白 (改行を含む) が単一の空白に変換され、Go テンプレートのトリミング ( {{
と}}
代わりに{{
{{-
と-}}
を使用する) と組み合わせると、 }}
必要に応じて、好きなようにフォーマット (ループなど) できます。全体的にとてもシンプルで自然です。\
しかし、誰かが喜んで (そして大量の時間を持っていれば)、少なくともその一部を自動化することは可能です。
ルール移行ツールは廃止され、現在のリリースから削除されたため、これは廃止されました。
ただし、ルールのきれいな書式設定は依然として重要です。 #5370 を参照してください。 それでも、混乱を避けるためにこれを閉じます。
最も参考になるコメント
参考までに、私は (いくつかの) ルールを手動で移行し、YAML、go テンプレート、Prometheus のルール言語を組み合わせて、(1) 移行が簡単で、(2) 理解しやすく保守しやすいものにする方法についていくつかの結論に達しました。 3 つの異なるフォーマット/言語と、大きく異なる改行、引用符、および空白の要件の組み合わせは、巨大で不必要な PITA ですが、それは重要ではありません。
このアプローチは、自動化されたツールを作成する場合 (私自身のニーズには大きすぎる) や、手動での移行を支援する場合に役立ちます。 かなり複雑なサンプルの移行ルールから始めますので、努力する価値があるかどうかを理解できます。
YAML はインデント、改行、コメントを防ぐために非常に懸命に努力していますが、インデント、改行、コメントを保持できることに注意してください。 基本的に、異なる場所でリテラル ブロック表記と一重引用符付きフロー表記を使用し、特定の引用文字を特定の用途に制限します。
基本的な考え方は
expr: |
ビット) を使用し、ブロック全体をexpr
後ろにインデントします。 これにより、あらゆるフォーマット/インデントを使用し、Prometheus によって解析および削除されるコメントを追加できます (これが、私が YAML への移行のセールス ポイントを実際に購入しない理由です。 )。debug: '
またはdescription:\n '
) を使用し、一重引用符は YAML の使用に制限し、Prometheus 文字列には二重引用符 (job="foo"
) およびGo テンプレート文字列のバッククォート (たとえば、printf
ビット)。 これにより、すべての空白 (改行を含む) が単一の空白に変換され、Go テンプレートのトリミング ({{
と}}
代わりに{{
{{-
と-}}
を使用する) と組み合わせると、}}
必要に応じて、好きなようにフォーマット (ループなど) できます。全体的にとてもシンプルで自然です。\
しかし、誰かが喜んで (そして大量の時間を持っていれば)、少なくともその一部を自動化することは可能です。