Roman Khavronenko 氏のレポート「ExtendedPromQL」の転写を読むことを提案します。
私について簡単に説明します。 私の名前はロマンです。 私は CloudFlare で働いており、ロンドンに住んでいます。 しかし、私は VictoriaMetrics のメンテナーでもあります。
そして私が著者です
「翻訳の難しさ」と呼ばれる最初の部分から始めます。その中で、どの言語でも、あるいは単なるコミュニケーション言語であっても非常に重要であるという事実について話します。 これは、自分の考えを他の人やシステムに伝える方法であり、リクエストを作成する方法だからです。 インターネット上の人々は、Java と他の言語のどちらが優れているかについて議論しています。 私自身にとって、これはすべて具体的なものであるため、タスクを選択する必要があると判断しました。
最初から始めましょう。 PromQLとは何ですか? PromQL は Prometheus クエリ言語です。 これは、時系列データ、つまり時系列を取得するために Prometheus でクエリを作成する方法です。
時系列データとは何ですか? 文字通り、これらは XNUMX つのパラメータです。
彼らは以下のとおりです。
- 私たちは何を見ているのでしょう。
- 見てみると。
- そしてそれはどのような価値を示すのか。
このグラフ (このグラフは私の携帯電話からのもので、私の歩数の統計を示しています) を見れば、これらの質問にすぐに答えることができます。
ステップを検討中です。 それを見ると意味がわかり、時間がわかります。 つまり、この図を見ると、日曜日に約 15 歩歩いたことが簡単に言えます。 これは時系列データです。
次に、それらをテーブルの形式で別のデータ モデルに「分割」(変換) してみましょう。 ここにも私たちが見ているものがあります。 ここで、メタデータと呼ぶ少しの追加データを追加しました。つまり、処理したのは私ではなく、XNUMX 人の人物、たとえばジェイとサイレント ボブです。 これが私たちが注目しているものです。 何を示すのか、いつその値を示すのか。
次に、このすべてのデータをデータベースに保存してみましょう。 たとえば、ClickHouse 構文を使用しました。 ここでは、「Steps」と呼ばれる XNUMX つのテーブル、つまり、私たちが見ているものを作成しています。 私たちがそれを見つめるときがここにあります。 それが示す内容と、それが誰であるかを保存するメタデータ: ジェイとサイレント ボブ。
そして、それをすべて視覚化するために、Grafana を使用します。第一に、それは美しいからです。
また、このプラグインを使用します。 これには XNUMX つの理由があります。 一つ目は私が書いたからです。 そして、ClickHouse から時系列データを取り出して Grafana で表示することがどれほど難しいかを正確に知っています。
グラフパネルに表示していきます。 これは Grafana で最も人気のあるパネルで、時間に対する値を示すため、必要なパラメータは XNUMX つだけです。
最も単純なクエリを作成してみましょう。Grafana でステップ統計を表示し、作成したテーブルにこのデータを ClickHouse に保存する方法です。 そして、このような単純なクエリを作成します。 ステップから選択します。 値を選択し、これらの値の時間を選択します。つまり、先ほど説明したのと同じ XNUMX つのパラメーターです。
その結果、このグラフが得られました。 なぜ彼がそんなに変なのか誰が知っていますか?
そうです、時間順に並べ替える必要があります。
そして最終的には、より良いスケジュールが得られますが、それでも奇妙なスケジュールになります。 その理由は誰にも分かりません。 そうです、参加者は XNUMX 人で、Grafana では XNUMX つの時系列を与えます。なぜなら、データ モデルを再度扱う場合、各時系列は名前とすべてのラベルの Key-Value の一意の組み合わせになるからです。
したがって、特定の人を選ぶ必要があります。 私たちはジェイを選びます。
そしてまた描きます。 これでグラフは真実のように見えます。 現在は通常通りのスケジュールで、すべてが順調に進んでいます。
そしておそらく、あなたはほぼ同じことを PromQL 経由で Prometheus で行う方法を知っているでしょう。 大体こんな感じです。 少し簡単です。 それをすべて分解してみましょう。 私たちは一歩を踏み出しました。 そしてジェイでフィルターします。 ここでは、値を取得する必要があることや時間を選択することは指定しません。
では、ジェイまたはサイレントボブの移動速度を計算してみましょう。 ClickHouse では、runningDifference を実行する必要があります。つまり、ポイントのペア間の差を計算し、それらを時間で割って正確な速度を取得します。 リクエストは次のようになります。
そして、彼はほぼこれらの値を示します。つまり、Silent Bob または Jay は 1,8 秒あたり約 XNUMX ステップを実行します。
Prometheus では、その方法もわかります。 以前よりもはるかに簡単になりました。
また、Grafana でも簡単に実行できるように、PromQL によく似たラッパーを追加しました。 これは、レート マクロ、または任意の呼び方と呼ばれます。 Grafana では「レート」と書くだけですが、深いところではこのような大きなリクエストに変わります。 そして、それを見る必要さえありません。どこかに存在しますが、このような巨大な SQL クエリの作成には常にコストがかかるため、時間を大幅に節約できます。 簡単に間違いを犯し、その後何が起こっているのかを長期間理解できなくなる可能性があります。
これは XNUMX つのスライドに収まらないクエリであり、XNUMX つの列に分割する必要さえありました。 これは ClickHouse のリクエストでもあり、同じレートを作成しますが、両方の時系列 (Silent Bob と Jay) に対して行われるため、パネル上に XNUMX つの時系列が表示されます。 私の意見では、これはすでに非常に困難です。
そしてプロメテウスによれば、それは合計(レート)になります。 ClickHouse 用に、Prometheus クエリに似た RateColumns という別のマクロを作成しました。
調べてみると、PromQL は非常に優れているようですが、もちろん制限もあります。
彼らは以下のとおりです。
- 限定セレクト。
- エッジJOIN。
- HAVING のサポートはありません。
そして、これを長く使ってきた人なら、PromQL で何かを行うのは非常に難しい場合があることをご存知でしょうが、SQL ではほとんどすべてのことが可能です。なぜなら、今話したこれらのオプションはすべて SQL で実行できるからです。 。 しかし、それを使うと便利でしょうか? このことから、最も強力な言語が常に最も便利であるとは限らないのではないかと思います。
したがって、タスクに使用する言語を選択する必要がある場合があります。 まるでバットマンとスーパーマンの戦いのようだ。 スーパーマンの方が強いのは明らかですが、バットマンは彼を倒すことができました。なぜなら、バットマンはより実践的で、自分が何をしているのかを正確に知っていたからです。
次の部分は PromQL の拡張です。
VictoriaMetricsについてもう一度。 VictoriaMetricsとは何ですか? これは時系列データベースであり、オープンソースであり、そのシングル バージョンとクラスター バージョンを配布しています。 私たちのベンチマークによると、これは現在市販されているもので最速であり、圧縮という点では同様です。つまり、生きている人は、Prometheus の圧縮率が 0,4 ~ 1,2 であるのに対し、ポイントあたり約 1,4 バイトの圧縮を報告しています。
私たちはプロメテウスだけをサポートしているわけではありません。 InfluxDB、Graphite、OpenTSDB をサポートしています。
あなたは私たちに「書き込む」ことができます、つまり、古いデータを転送することができます。
また、Prometheus や Grafana とも完全に連携します。つまり、PromQL エンジンをサポートします。 また、Grafana では、Prometheus エンドポイントを VictoriaMetrics に変更するだけで、すべてのダッシュボードが以前と同じように機能します。
ただし、VictoriaMetrics が提供する追加のチップを使用することもできます。
追加した機能を簡単に説明します。
間隔パラメータを省略 - Grafana でパラメータ間隔をスキップできます。 パネルを拡大/縮小したときにおかしなグラフが表示されたくない場合は、変数を使用することをお勧めします $__interval
。 これは Grafana の内部変更であり、データ範囲自体を選択します。 そして、VictoriaMetrics 自体がこの範囲がどうあるべきかを理解できます。 すべてのリクエストを更新する必要はありません。 ずっと簡単になります。
XNUMX 番目の機能は間隔参照です。 この間隔を式で使用できます。 乗算、除算、転送、参照ができます。
次はロールアップ関数ファミリーです。 ロールアップ関数は、任意の時系列を XNUMX つの異なる時系列に変換します。 これらは最小、最大、平均です。 場合によっては外れ値 (異常値) や不正確さを表示できるため、これは非常に便利だと思います。
また、単に怒りやレートを実行している場合は、時系列が意図したとおりに動作しないいくつかのケースをおそらく見逃す可能性があります。 この関数を使用すると、最大値が平均値から大幅に離れていると仮定して、それを確認するのがはるかに簡単になります。
次はデフォルトの変数です。 デフォルト - これは、現時点で時系列がない場合に Grafana で描画する必要がある値を意味します。 それはいつ起こりますか? いくつかのエラーメトリクスをエクスポートするとします。 そして、起動するとエラーが発生せず、その後 XNUMX 時間、さらには XNUMX 日もエラーが発生しない素晴らしいアプリケーションが完成しました。 また、成功からエラーまでの関係を示すダッシュボードもあります。 また、エラー メトリックがないため、何も表示されません。 デフォルトでは何でも指定できます。
Keep_last_Value - メトリクスの最後の値が欠落している場合にそれを保存します。 次のスクレイピング後の Prometheus が 5 分以内にそれを見つけられなかった場合、ここで最後の値が記憶され、チャートが再び壊れることはありません。
Scrape_interval - Prometheus がメトリクスに関するデータを収集する頻度と頻度を示します。 ここでは、たとえばパスを確認できます。
ラベルの置換は人気のある機能です。 ただし、整数の引数を必要とするため、少し複雑になると思います。 そして、5 つの引数を覚えるだけでなく、その順序も覚えておく必要があります。
したがって、それらをもっとシンプルにしないのはなぜでしょうか。 つまり、明確な構文を持つ小さな関数に分割します。
そして今、最も興味深い。 なぜそれが PromQL を拡張したものだと考えられるのでしょうか? 共通テーブル式をサポートしているためです。 QRコード(
で、それ何? 上記のリクエストはかなり人気のあるリクエストです。 多くの企業のダッシュボードでは、すべてに同じフィルターを使用していると思います。 通常はそうです。 ただし、新しいフィルターを追加する必要がある場合は、各パネルを更新するか、ダッシュボードをダウンロードして JSON で開き、検索置換を行う必要があり、これにも時間がかかります。 この値を変数に保存して再利用してみてはいかがでしょうか? 私の意見では、それははるかにシンプルで明確に見えます。
たとえば、すべてのリクエストで Grafana のフィルターを更新する必要があり、ダッシュボードが巨大になったり、ダッシュボードが複数存在したりする場合があります。 そして、この問題を Grafana でどのように解決したいでしょうか?
私はこの問題を次のように解決します。 commonFilter を作成し、その中でこのフィルターを定義し、それをクエリで再利用します。 ただし、今同じことをしても、Grafana ではクエリ変数内で変数を使用することができないため、機能しません。 そして、それは少し奇妙です。
そこで、これを可能にするオプションを作成しました。 そして、そのような機能に興味がある場合、またはそのような機能が必要な場合は、このアイデアを支持するか、気に入らない場合は嫌いにしてください。
PromQL 拡張の詳細。 ここでは変数だけでなく、関数全体を直接定義します。 そしてそれを ru (リソース使用量) と呼びます。 この関数は、無料リソース、リソース制限、およびフィルターを受け入れます。 構文は単純なようです。 この関数を使用して、空きメモリの割合を計算するのは非常に簡単です。 つまり、メモリの量、制限、およびフィルタリングの方法です。 同じフィルターを再利用してすべてを作成した方が、非常に大きなクエリになるため、見た目ははるかに良くなります。
ここに、そのような大きな大きなリクエストの例を示します。 これは、Grafana の公式 NodeExporter ダッシュボードからのものです。 しかし、ここで何が起こっているのかよくわかりません。 もちろん、よく見てみるとわかりますが、括弧の数によって、ここで何が起こっているのかを理解する意欲がすぐに低下する可能性があります。 そして、なぜそれをもっとシンプルかつ明確にしないのでしょうか?
たとえば、このように、変数内の重要なものや部分を強調表示します。 そして、基本的な計算を行ってください。 これはすでにプログラミングに近いものであり、私が将来 Grafana で実現したいと考えているものです。
これは、この ru 関数がすでに存在し、VictoriaMetrics に直接存在している場合に、それをさらに簡単にする XNUMX 番目の例です。 そして、CTE で宣言したキャッシュされた値を渡すだけです。
適切なプログラミング言語を使用することがいかに重要であるかについてはすでに述べました。 そしておそらく、各企業の Grafana では何か違うことが起こっているでしょう。 そしておそらく、開発者に Grafana へのアクセスを依然として与えており、開発者は独自のことを行っています。 そして、それらはすべて異なる方法でそれを行います。 しかし、私はそれをどういうわけか同じにして、つまり共通の標準に落とし込みたかったのです。
システム エンジニアだけでなく、専門家、開発者、SRE もいるとします。 おそらく、モニタリングとは何か、Grafana とは何かを知っている専門家がいるかもしれません。つまり、彼らは何年もこれに取り組んできており、それを正しく行う方法を正確に知っています。 そして、彼らはすでにそれを100回書いて皆に説明しましたが、何らかの理由で誰も聞いていません。
この知識を直接 Grafana に組み込んで、他のユーザーが機能を再利用できるようになったらどうなるでしょうか? また、空きメモリの割合を計算する必要がある場合は、その関数を適用するだけです。 しかし、エクスポータの作成者が、そのメトリクスが何であるか、そしてそれらを正しく計算する方法を正確に知っているため、エクスポータの作成者がその製品とともに、メトリクスの操作方法を示す関数セットも提供していたらどうなるでしょうか?
これは実際には存在しません。 これが私自身がやったことです。 これは Grafana のライブラリ サポートです。 NodeExporter を作成した人たちが、私が説明したことを行ったとします。 また、一連の機能も提供されました。
つまりこんな感じです。 このライブラリを Grafana に接続し、編集に入ります。このメトリックを JSON で操作する方法は非常に簡単です。 つまり、一連の関数、その説明、およびそれらが展開される内容です。
私の意見では、これは便利だと思います。そうすれば、Grafana で同じように書くことができるからです。 そして、Grafana は、これこれのライブラリにこれこれの関数があることを「教えて」くれるので、それを使ってみましょう。 それはとても素晴らしいことだと思います。
VictoriaMetrics について少し説明します。 私たちは面白いことをたくさんやっています。 圧縮に関する記事、他の時系列データ アプリケーションとの競合に関する記事、PromQL の操作方法に関する説明 (初心者が多いため)、垂直方向のスケーラビリティや Thanos との対決に関する記事もお読みください。
質問:
簡単な人生の話から質問を始めます。 初めて Grafana を使い始めたとき、非常に説得力のある 5 行のクエリを書きました。 最終結果は非常に説得力のあるグラフになります。 このグラフはほぼ実稼働状態になっています。 しかし、よく見てみると、数値は予想の範囲内にありましたが、このグラフは現実とはまったく関係のない全くのナンセンスを示していることが判明しました。 そして私の質問。 ライブラリや関数はありますが、Grafana 用のテストはどのように作成すればよいでしょうか? サーバーの実際のコンテナを注文するか注文しないかというビジネス上の決定に影響を与える複雑なクエリを作成しました。 そしてご存知のとおり、このグラフを描画する関数は真実に似ています。 ありがとう。
ご質問ありがとうございます。 ここには XNUMX つの部分があります。 まず、私の経験から言えば、ほとんどのユーザーはチャートを見ても、何が表示されているのか理解できていないという印象を受けます。 どういうわけか、人々は、たとえそれが関数内のバグであっても、チャート上で発生した異常について言い訳を考えるのが非常に上手です。 そして XNUMX 番目の部分では、各開発者が独自のキャパシティ プランニングを行ってある程度の確率で間違いを犯すよりも、そのような関数を使用する方が問題を解決するのにはるかに適しているように思えます。
確認するには?
確認方法は? おそらくそうではありません。
Grafana でのテストとして。
そしてグラファナはどうですか? Grafana は、このリクエストを DataSource に直接変換します。
パラメーターに少し追加します。
いいえ、Grafana には何も追加されません。 step などの GET パラメータが存在する場合があります。 明示的に指定されていませんが、オーバーライドできます。オーバーライドはできませんが、自動的に追加されます。 ここではテストを書きません。 ここで真実の情報源として Grafana に頼るべきではないと思います。
ご報告ありがとうございます! 圧縮してくれてありがとう! グラフ内の変数のマッピングについて、Grafana では変数内で変数を使用できないことを思い出しました。 私の言っている意味が分かりますか?
はい。
Grafana でアラートを作成したいとき、最初はこれが頭痛の種でした。 そして、各ホストに対して個別にアラートを実行する必要があります。 これはあなたがやったことですが、Grafana のアラートに対して機能しますか?
Grafana が他の方法で変数にアクセスしない場合は、はい、機能します。 ただし、私のアドバイスは、Grafana ではアラートをまったく使用しないで、alertmanager を使用することをお勧めします。
はい、私も使っていますが、Grafana でセットアップする方が簡単に思えました。しかし、ヒントをありがとう!
出所: habr.com