Grafana: テンプレート変数を使用したクエリのアラートサポート

+1

1. すべてを使用する場合との違いは何ですか？

+1
ライフタイムの短いサーバーにアラートを追加できると便利です（AWS自動スケーリング）。グラファナにサーバーを自動登録するのはテンプレート作成が簡単ですが、アラートを設定できないのは悲しいことです。

@bergquistたとえば、ホストが12を超える場合、すべてを使用するのは実用的ではありません。

たとえば、失敗しているのがごくわずかである場合（たとえば、5つ）、失敗したアラートごとに電子メールを受信すると非常に便利です。 この方法は、一般にメトリックごとに1つのアラートを期待する他のツールとの統合もはるかに簡単です。

インスタンスが少ない場合やサービスレベルでアラートを送信している場合（キュー内のジョブの数など）は、現在のアプローチ（すべてを使用）は非常に優れています。

@calindが言ったこと、私は複数の$ host変数を持っていて、influxDBでは正常に機能していますが、アラートでは機能していません

+1も。

テンプレート変数を使用してクエリを実行できるので、アラートメトリックを使用して同じクエリを実行し、結果を反復処理してアラート基準を満たすものを確認することはできませんか？

@NotSoCleverLoginそれは可能でしょう。 しかし、選択したテンプレート変数に基づいてアラートルールの動作を変更しますか？

テンプレートにallオプションを使用することが、私にとって意味のある唯一の方法です。

+1

各環境に同じコンポーネントを使用するX環境のセットアップがあります。 現在、CPU使用率/ディスク使用率などのアラートにprometheusを使用しています。そこでクエリのアラートを指定し、アラートがトリガーされると、アラートがトリガーされた環境を示します。

All変数を使用してこれを行うと、ある程度機能します。 しかし、 @ calindの例を使用すると、スクリーンショットには、問題について通知を受けたい環境だけでなく、すべての環境からのすべてのCPUの傾向が表示されます。 グラフは、他の環境からの情報で不明瞭になります（または不明瞭になる可能性があります）。 一部のシナリオでは、他の環境でCPUを比較することが興味深い場合がありますが、テスト環境で発生していることが本番環境などで発生しているという保証はありません。

また、オペレーションで使用できるダッシュボードの作成も検討しており、「標準」の概要ダッシュボードにアラートの注釈を表示します。 これらの種類のダッシュボードに「env」テンプレート変数を使用していることを考えると、現在の実装方法では実際には不可能です。 アラートがトリガーされる「シャドウ」ダッシュボードを手動で（少なくともある程度は）生成する必要があります（これにより、概要ダッシュボードの注釈が失われます）。

テンプレート変数が役立つと思うもう1つのことは、アラート（このような機能の実装を選択した場合）をさまざまなソース（本番環境の場合は運用、テスト環境の場合はqa /developersなど）にルーティングすることです。

テンプレート化されたクエリのアラートをサポートするための+1。

@bergquist 、一部のダッシュボードには_All_オプションがありません。 たとえば、collectd（https://grafana.net/dashboards/24）によるシステムメトリック。 _All_オプションを設定することは、たとえば10台以上のサーバーでは確かに実用的ではありません。 そのため、トラフテンプレート変数を反復処理する必要があります。

Allの使用を許可することは、良いスタートであり、歓迎されています。

Prometheusでは、すべてを許可するには、クエリを別の方法で作成する必要があります。

some.metric{hostname=~"$Hostname"}

そこに余分なチルダがあり、正規表現の検索（およびすべてのワイルドカード）が可能になっていることに注意してください。

ストレートクエリから正規表現検索クエリに移行することによるパフォーマンスへの影響の可能性についてはベンチマークを行っていませんが、少なくとも今のところ、問題は明らかに解決するでしょう。

+1

+1

それがどのように実装されるべきかわからない、ただそれが必要であることを知っている。

+1
Prometheusをデータソースとして使用して、オンプレミスK8SクラスターとAWSK8SクラスターのKubernetesインフラストラクチャを監視します。
すべてのダッシュボードは、データソース（$ Environment）、$ Instance / Node、$ Namespace、および$Podにテンプレート変数を使用します。
Prometheusクエリ構造の方法により、 すべてのクエリにはテンプレート変数があります。 これにより、アラートルールによる保存ができなくなります。
テンプレート化された変数クエリがアラートに追加されるのを楽しみにしています。

+1

+1
論理的な方法である（そして多くの人が使用する）マルチサーバー環境にテンプレートダッシュボードを使用しているため、現在、grafanaでアラートを使用することはできません。 唯一の方法は、テンプレートを使用しない別のダッシュボードを用意するか、プロメテウス自体でアラートを設定することです。これは簡単ではありません。

おそらく、すべてのフィールドにテンプレート変数がバックアップ/事前レンダリングされたダッシュボードを保存/エクスポートするオプションまたは簡単な方法があった場合...これは、別の解決策が見つかるまでの良い中間点になるでしょう。

テンプレート化されたクエリのアラートをサポートするための+1。 現在、すべてのダッシュボードでテンプレートを使用しているため、この非常に優れた機能を利用することはできません。

+1、テンプレート化されたダッシュボードがたくさんあり、今のところアラートを使用できません。アラートを表示するにはダッシュボードを重複排除する必要があるため、テンプレート機能が失われます。

+1、ほとんどすべてのダッシュボードはテンプレート変数（およびネストされたテンプレート変数）を使用します。

必要に応じて、繰り返しパネルにアラートを設定して、テンプレート変数グループごとに個別のアラートを取得できるようにしたいと考えています。 さらに、これは、アラートが動的であり、現在のようにスーパーマニュアルではないことを意味します。

危険：理論的には変数を使用するのは良いことですが、誰かがダッシュボードにアクセスして値を変更して保存すると、結果のアラートが影響を受けることに注意する必要があります。 それが大丈夫かどうかわからない、複雑になります。

+1

grafanaを使用する場合、どこでもテンプレート作成が推奨されているように感じられ、アラート機能を使用するためだけに変数を使用せずにグラフの追加セットを作成するのは間違っていると感じます...

テンプレート化されたクエリのアラートをサポートするための+1。
また、中国語のruleNameまたは中国語のタイトルを使用すると、ルールがトリガーされた異常な電子メールを受信したことがわかりました。 たとえば、「TT股分時線接口请求時間（getTimeTrend）アラート」を期待していましたが、「个股分时线接å£è¯・求时间（ getTimeTrend）alert」、文字セットが正しくない可能性があります。

アラートにテンプレート化された変数を実装するための+1

+1

+1は素晴らしい追加を得るでしょう

+1

アラートにテンプレート化された変数を実装するための+1

+1

+1楽しみにしています

+1

+1

+1

+1

+1を書くのをやめてください！
この問題を購読しているすべての人にメールが届きます...

これらの+1コメントを取り除くためだけのgithub機能があります：
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

@thetechnick電子メールには、スレッドをミュートして電子メールを受信しないリンクがあります。 ただし、機能が完了したときに通知を受け取ることをお勧めしますが、問題を解決して、より早く作業できるようにしたいと思います:)

全体的なアラートの大きな進歩。
アラートのテンプレート変数についても、私はそれを見逃しています。 +1：D

=
その上、Grafanaがqueryで使用されているメトリックがテンプレート変数を使用しているかどうかを検出する方法にバグがある可能性があります。

テンプレート変数を間接的に使用するシリーズがある場合、Grafanaはそのシリーズをアラートとして追加することを停止しません。 アラートは明らかに正しく機能しません。

#Kを参照してください（#Dを使用し、＃Aを使用し、＃Aはtempl。varを使用します）：

私はまだそれを選択することができました：

どこにでもあるテンプレート。これは、どこにも警告しないことを意味します。
アラートがどのように実装されているかはわかりませんが、単純なグラフの場合、データソースを呼び出す前に、クエリが「変換」され、テンプレート変数が値に置き換えられます。 では、なぜこの場合はどうでしょうか？ いずれにせよ、前に述べたように、テンプレート変数を使用するほとんどすべてのクエリがあるので、アラートは完全に私にとって重要です。 アラートをGrafanaの外に移動する必要がないように実装していただけませんか？ どうもありがとう！

テンプレートを使用したアラートは簡単ではないことを認識しておく必要があると思います。誰かがダッシュボードを使用しているときにアラートを変更したくないので、ALLオプションが最適だと思います。
ただし、テンプレートクエリが新しい結果を返す場合、grafanaは新しいアラートを作成する必要があります...これは、アプリをスケーリングするときに静かに発生することがよくあります。
私たちの多くがタグ/タグ値を使用しているため、InfluxDBを使用している場合、これはより多くの問題につながります。それらの時間フィルターはありません...したがって、grafanaは、任意のホストに存在したすべてのサービスに対してアラートを作成します。 。

+1

アラートでデータソースを指定できるようにするだけで問題ありません。 ロジックを壊すことはなく、少なくとも本番環境とステージング環境を指定して監視することができます。

確かに、ALLはオプションです。 より柔軟なのは、クエリ内のテンプレート変数を認識し、ユーザーがアラート条件の構成で値を設定できるようにすることです。 最良の、しかし複雑なのは、クエリ内の異なるテンプレート変数値に対して異なるアラートを設定できるように、複数のアラート（複数のクエリがあるのと同じ方法）を持つことです。 これにより、管理者は、たとえば、ホストごとに異なるアラート条件を設定できます。

複数のアラートプロファイルがあれば便利ですが、最初のパスでは、アラートパネルのダッシュボードで使用できるものと同じテンプレートセレクターを提供するだけで、多くの問題を解決できます。

また、各変数の結果を1つの通知に集約するには、変数ごとに切り替えが必要だと思います。これは、複数選択が有効になっているテンプレート変数に対してのみ有効になっている可能性があります。 これにより、通知の詳細度を制御するためのシンプルで効果的な方法が提供されます。関連する複数のメトリックについては1回だけ通知し、メトリックが失敗した場合はホストごとに通知することができます。 または、影響を受けるホストの数に関係なく、失敗したメトリックについて1回だけ通知することもできます。

このバグの目標となるマイルストーンはありますか？

複雑なクエリとテンプレート変数クエリのアラートに問題がありました。 簡単な回避策を見つけました。これはきれいではないかもしれませんが、私のユースケースでは機能します。
作成後にクエリを抽出するだけなので、テンプレート変数や#ROW参照はありません。 これはあなたにとって明白かもしれません、ロケット科学はありません、しかし私にとってそれは人生を変えるものでした。

私がしていることは、クエリを準備することです。

次に、Chrome開発ツールを使用して抽出します（ターゲットパラメータ値をコピーします）。

別の行に配置します（最初に編集モードを切り替えるように切り替えます）。

アラートを設定します。

出来上がり！

@siteshbeheraこれはバグではありません。 その機能のリクエスト。

しかし、違います。 現在、これに関するマイルストーンはありません。

この機能のコミットには、人工知能のgrafanaプラグインを含める必要があります。

アラートでテンプレートを待機しています+1

私はまた、オープニングポストで可能な実装としてcalindが提供したものに非常に賛成です。 テンプレート化されたダッシュボードを使用する（私を含む）数にうまく収まるようです-ダッシュボードが1つありますが、特定のものを手動で確認するためにいくつかの変数を切り替え/制限します。 「サーバー」変数の例が最も適切なものかもしれないと思います。 そこで、テンプレート変数（_all_-valueなし）は、ダッシュボードの「_tab_」と同じようになります。これらを切り替えて、さまざまなデータセットを表示できます。 その場合、アラートを設定するときに、可能な「_tab_」ごとにアラートが個別に存在すると簡単に推測できます。

Alerts+1でテンプレートをサポートするのを待っています

アラートがこのテンプレートを部分的に可能にしていたLibratoの以前のユーザーとして、私は同様に部分的な解決策でチャイムを鳴らしたいと思います。 Libratoでは、各メトリックには「ソース」変数が付属しており、グラフ上のアラートは自動的にソースごとになります。

同等の解決策は、ここで提起されたニーズを満たすと思います。 アラートを作成するときは、単一​​のテンプレート値を「ソース」として選択できる必要があります。このソースはアラートに記載されており、他のすべての値は「すべて」に設定されています。 このソリューションは、少なくとも、複数のテンプレート変数の使用を許可した場合に発生する組み合わせの問題を回避します。

私自身、興味のあるデータに非表示の最大または最小グラフを設定し、アラートを実行します。それほど強力ではありませんが、この問題が解決されるまではまだ機能するソリューションです。

こんにちは、私は間違いなくこの機能を探しています。これまでのほとんどの場合、すべてのダッシュボードがテンプレート化されたクエリを使用して複数の環境をサポートしているためです（少なくとも）。

grafanaのロードマップが追跡されている場所はありますか？ または、githubでmantainerを突くことなく、機能（このような）が将来（近くまたはそれほど近くではない）実装されるかどうかを確認する方法はありますか？ :)

これを本当に熱心に待っている素晴らしい

+1

+1

これを行う方法はまだわかりません。

選択したテンプレート変数をアラートに再利用するのは危険だと思います。なぜなら、人々は1つのオプションだけを表示することを選択してから、 Allまたはそれより広いものに戻すのを忘れることができるからです。 私はそのような行動で安全を感じることはありません。 アラートルールは、非常に理解しやすく、推論しやすいものにする必要があります。 明示的なルール>魔法のルール。

この問題の1つの解決策は、テンプレート変数ごとに2つの値を設定することです。 1つはダッシュボードでの視覚化用で、もう1つはアラート用です。 これにより、アラートのオプションを常に広げながら、グラフでいくつかのオプションを選択することが可能になります。 これらの値を接続することは可能ですが、デフォルトの動作ではありません。

その解決策は、どれもかなり大きくて複雑な機能です。

解決策について2つの提案があります。

1. 短期的な提案は、アラートオプションを追加して、レンダリングされたガーフ（電子メールで送信されるもの）にアラートを送信しているメトリックのみが表示されるようにすることです。 これにより、アラートグラフに数十のメトリックが含まれている場合の混乱が解決されます。

2. 長期的な解決策は、テンプレート変数を反復処理することです。これにより、テンプレート値の組み合わせごとに個別のアラートが得られます。

11月に言ったように。 プロメテウスユーザーの場合、クエリが適切に記述されていれば、変数値として「All」を使用するだけで十分です（some.metric {hostname =〜 "$ Hostname"}）。

おそらく実装も非常に簡単なはずです。

@bergquistオプション2は正しい方向に向かっていると思います（https://github.com/grafana/grafana/issues/6557#issuecomment-272588490で提案したものの部分的な実装）、それほど複雑ではないようですが、テンプレート変数の選択を処理するコードはダッシュボードにすでに存在し、変数の構成を複製する必要はなく、選択するだけです。 この機能の最初のパスで、ダッシュボードの選択をアラートに接続する必要はないと思います。

テンプレート変数を使用せずにアラート専用の新しいメトリッククエリを作成し、Grafanaバージョンv4.1.1で（グラフから除外するために）無効にすることで解決しました。

アラートにテンプレート化された変数を実装するための+1

アラートにテンプレート化された変数を実装するための+1

これはGrafanaの_すべての_バージョンに影響しますか？ それとも、これは以前に利用可能だった機能でしたか？ これは私にとって一種の取引ブレーカーであり、以前のバージョンをインストールしてもかまいません。

@alejandroandreuアラートはバージョン4で追加され、テンプレートを使用したことはありません。

アラートにテンプレート化された変数を実装するための+1

私が実行している環境の一部は本番環境ではないため、アラートが評価する組み合わせを選択/入力できるようにしたいと思います。これを実装するには2つの方法があります。最初の方法はより明確で、2番目の方法は設定が簡単です。

必要なすべての組み合わせを手動で入力します

• この構成は、アラート構成パネルに表示されます。

たとえば、3つのテンプレート変数（ cloud 、 region 、 type ）がある場合、次のようなテーブルに入力します。

| クラウド| 地域| タイプ|
| ------- | ------------ | ------ |
| aws | us-east-1 | 製品|
| aws | us-west-1 | 製品|
| 紺碧| 米国中央部| 製品|

テーブルには、新しい行を挿入するための追加の行と、すべての行の削除ボタンが必要です。

可能な値を入力すると、Grafanaはデカルト積を計算します

• 注：この構成は、テンプレート変数構成パネルに入力できます

| クラウド| 地域| タイプ|
| ------- | ------------ | ------ |
| aws | us-east-1 | 製品|
| 紺碧| us-west-1 | |
| | 米国中央部| |

この入力用に作成される組み合わせは次のとおりです。

• aws us-east-1 prod
• aws us-west-1 prod
• aws Central US prod
• azure us-east-1 prod
• azure us-west-1 prod
• azure Central US prod

ただし、 Grafanaは、最初の変数（ cloud ）を「入力」し、可能なすべての組み合わせが見つかるまで2番目の変数（ region ）から使用可能な値をフィルタリングすることで、この状況を処理できます（注-すべての変数に対して繰り返し実行する必要があります）。 これは、次のようなタグでクエリを使用する場合に可能です。

SHOW TAG VALUES WITH KEY = "REGION" WHERE "CLOUD" =~ /$CLOUD/   

そしてこの場合、生成された組み合わせは問題ありません（これは最初のオプションの表と同じです）：

• aws us-east-1 prod
• aws us-west-1 prod
• azure Central US prod

私の提案がお役に立てば幸いです。

この問題（OpenTSDBデータソース）は少し異なるコンテキストで発生します。テンプレート変数を使用してメトリックのダウンサンプル間隔を選択すると、アラートクエリはエラー400で失敗します。一般的なソリューションの実装の難しさは理解していますが、アラートを有効にするには、既存のさまざまなダッシュボードを再設計する必要があります。

@dbcookは明確な問題のように聞こえますが、おそらく別の問題を提出する必要があります。

テンプレートは本当に素晴らしい機能であり、アラートも同様です。 厄介な回避策ではなく、スムーズに連携させることをお勧めします。

@tomekit回避策をありがとう、実際の実装を待っている間、それは有望に見えます。 ただし、Chrome開発ツールを使用してクエリを抽出する場所が見つからないため、新しいクエリのターゲットパラメータ値をコピーできません。 「要素の検査」を試しましたが、スクリーンショットに表示されている「名前」、「ヘッダー」、「フォームデータ」を見つけるのに苦労しています。

そのための手順を説明していただけませんか。 あなたの助けは大歓迎です！

ありがとう

@mathurjこれは[ネットワーク]->[XHR]タブです。 それは今役に立ちますか？

次に、「レンダリング」リクエストをクリックします。

@tomekitに感謝します。このページは表示されますが、「render」という名前のリクエストは表示されません。 ただし、実行しているクエリに関する別のリクエストがありますが、「ターゲット」パラメータがありません。

「レンダリング」リクエストを実行する方法についてのリードはありますか？

@mathurjダッシュボードのグラフの1つを見て、[更新]（右上隅）をクリックすると、「レンダリング」リクエストが表示されます。

試してみましたが、まだ「レンダリング」リクエストはありません:(そして「ターゲット」パラメータもありません。とにかく@tomekitの助けに感謝します。実際の実装を待つ必要があると思います。 @bergquist @torkelo ？

で作業します
some.metric {hostname = \〜 "$ Hostname"}
クエリ自体は問題ありませんが、
しかし、ここのテンプレートである私のデータソース...

environment = \〜 "$ environment"
うまくいかないようです...これが機能する方法はありますか？ または、テンプレートを削除する必要があります：失望：

+2

この機能は、プロメテウスをデータソースとして使用する場合に特に便利です。

上記と同様の理由で、これも必要です。 これは、テンプレートが定義するコレクション全体のforeachループとして機能することを期待しています。

これが必要です!!! :)👍

個人的には、この機能もサポートしています。 遅延メトリックを生成する一連の負荷テストを使用して、複数のシステムをテストしています。 ダッシュボードを1つにする代わりに、変数を使用してさまざまなシステムのデータを保持するデータソースを切り替え、スクリプトを作成せずに1つのボードを維持するだけで済みます。
したがって、アラートでのテンプレートのサポートをいただければ幸いです。

+1
これも必要です

+1
これも必要です

+1
これも必要です

なぜそんなに多くの人がそれらの+1の返信を「親指を立てる」のか尋ねることができますか？

@skygragon元の投稿を+1するオプションが存在する場合、それは本質的に役に立たないスパムです。 最初の投稿の「いいね」アイコンをクリックするだけです。

テンプレート変数とアラートは、Grafanaの最も優れた機能の2つです。
しかし、それらが相互に排他的であるのを見るのは悲しいです......

+1

@bergquistあなたのチームはこれについてもう一度話し合い、うまくいけばこれにマイルストーンを置くことができますか？ これは、ほぼ2年間で最も要求された機能であり、かなりの数のユーザーがこの機能を利用して満足していると思います。

良い解決策はまだ提案されていません。異なる目的に役立つ2つの機能が混在しているため、これは悪い考えであると確信しています。 テンプレート変数は、動的なダッシュボードと探索に使用されます。 アラートルールは、正規表現/ワイルドカードクエリを使用して動的にすることができます。 これら2つを混合することは、少なくとも理解可能で予測可能な方法では、ひどい考えのように思えます。

いくつかの限られた方法でそれをサポートすることにはいくつかの正当な理由がありますが、それが追加する極端な複雑さと開発コストの価値があるかどうかはわかりません。 しかし、私たちはアイデア、提案、PRを受け入れています。

問題は、監視しているサーバーがかなりあり、それらがAmazonを通じて動的に作成されているため、ある時点で稼働しているサーバーの数がわからないことです。

（たとえば）各サーバーのCPUを示すテンプレート化されたグラフがあるので、そこでもアラートを出したいです。

しかし、ワイルドカードを使用して同じことを達成できるとおっしゃっていますか？

@ yesman85もちろん、時系列ストアによって異なります。 ただし、ほとんどの場合、命名パターンに従う複数のメトリックをターゲットにするために、何らかの形式のglob/regexクエリ構文をサポートしています。

@torkeloこの立場が公に表明されたのはこれが初めてだと思います。 ここには誤解があるかもしれません-ダッシュボード出力用に選択されたテンプレート値がアラートに影響を与えることをユーザーが望んでいないと思いますが、代わりにアラートを構成するときに同じテンプレート選択を使用できるようにします。

このスレッドからの関連する実装の提案：
https://github.com/grafana/grafana/issues/6557#issuecomment -272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641（オプション2）

また、関連する問題：
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

これらの制限により、怒りのアラートにGrafanaを使用できなくなりました。これを行う唯一の方法は、アラート用に個別の非表示クエリを追加するか、アラートと表示用に個別のダッシュボードを作成することです。 。 どちらのオプションもメンテナンスの悪夢であり、Grafanaがユーザーによる構成と解釈を簡単に監視できるという大きな可能性を制限します。

Libratosのソースベースのアラートに触発された上記の私の提案は、上記の問題のほとんどすべてをカバーしているように見える、限定された、理解可能で予測可能な解決策を提供すると思います。

grafanaでは、アラートに1つだけのテンプレート変数を使用できるようになり、その変数の各値が独自のアラートを生成します。 アラートを作成する正規表現をフィルタリングするために、正規表現を追加することもできます。

@pdf https://github.com/grafana/grafana/issues/6041が大きな制限であり、間違いなく修正したいのですが、この問題とは無関係であることに同意します。 まだ修正していないのは悪いことです。私は同意します。ここ数か月、アラート側の人員が少し不足していますが、すぐに変更されます。

同じではない@danhallinは、クエリでワイルドカードまたはグロブ式を使用するか、限られたタグのセットでのみフィルターを使用する多くのシリーズを対象とするGrafanaのクエリに変換されるようです。 Libratoアラートルールはダッシュボードとは別に定義されていますが、そうではないので、ダッシュボード全体のデータフィルタリング機能にどのように変換できますか？

現在、ある種の作業を行う方法は、アラート用に個別の非表示のクエリを追加することです。これは、メンテナンスの悪夢です。

そのようなテンプレート化されたグラフにアラートルールを混在させることは悪夢であることを理解してください。 ただし、アラートでテンプレート変数をサポートすることは、さらに大きな悪夢になる可能性があると考えてください。 おそらくばかげた質問ですが、アラートに焦点を当てたダッシュボードとグラフを作成することはできませんか？ 探索とトラブルシューティングのために、ダッシュボードに多くのテンプレート変数を残しますか？ おそらく似ている場合が多いので、作業が重複しているように感じます:(いくつかのテンプレート変数を使用したダッシュボードのコンテキストでのアラートルールの問題は、どのように機能して理解できるか、さらにはどのようにできるかです。まったく実装されていません。

1つのクエリが2つのテンプレート変数$Aと$Bを使用し、それぞれに50の値があるとします。 これにより、アラートルールが2500回評価されますか？ つまり、変数が「単一値」である場合、つまり、$Aと$Bが単一の値を持つ場合にのみクエリが機能するように構築されている場合は、それを実行する必要があります。 ショーストッパーではないかもしれませんが、複数値の変数のみがサポートされていることを説明する必要があります。 この機能の実装、使用、理解を非常に困難にする、さらに多くの制限と問題のある詳細がおそらくあります。

しかし、私はそれに100％反対しているわけではありません。限られた方法でそれを行う方法があるかもしれないと思います（1つだけをサポートするなど）
複数値変数）。 複数のデータソースがあり、アラートルールでデータソース変数をターゲットにして、多くのデータセンター/環境（個別のTSDBを持つ）でアラートルールを再利用できるというユースケースもあります。このユースケースは解決する必要があります。データソーステンプレート変数をワイルドカードを使用したメトリッククエリとして使用しても、それを解決することはできません。

しかし、アラートに焦点を当てたダッシュボードとグラフを作成することはできませんか？ 探索とトラブルシューティングのために、ダッシュボードに多くのテンプレート変数を残しますか？ おそらく似ている場合が多いので、重複した作品のように感じます:(

私は実際にコメントを編集してこのオプションを参照しました（そして他のアラート関連の問題点の問題をいくつか追加しました）。 ただし、ご存知のとおり、これは、ダッシュボード/パネルの作成（および、これらすべてのクエリを更新する必要がある場合はメンテナンス）に、アラートを送信するテンプレートバリエーションの数を掛け、アラートの注釈をそれらが存在する可能性のある場所から分離することを意味します。で最も役立ちます-アラート注釈付きのテンプレート化されたダッシュボードは、相関関係を作成するのに非常に役立ちますが、複数のブラウザタブを調べて並べてみる必要がある場合は、それほど役に立ちません。

1つのクエリが2つのテンプレート変数$Aと$Bを使用し、それぞれに50の値があるとします。 これにより、アラートルールが2500回評価されますか？ つまり、変数が「単一値」である場合、つまり、$Aと$Bが単一の値を持つ場合にのみクエリが機能するように構築されている場合は、それを実行する必要があります。 ショーストッパーではないかもしれませんが、複数値の変数のみがサポートされていることを説明する必要があります。 この機能の実装、使用、理解を非常に困難にする、さらに多くの制限と問題のある詳細がおそらくあります。

ここには2つの別々の問題があると思います。 ＃6041に密接に関連する1つの_is_（私は信じています）は、シリーズ/テンプレート値（以前のコメントで述べた集約トグル）ごとにアラート条件を個別に評価したいという要望があるかもしれません。 今のところそれを脇に置いておくと、この問題の大部分を解決する理想的な方法は、パネルごとに複数のアラート構成を許可し、ダッシュボード出力の場合とまったく同じ方法で変数の補間を行うことです。またはアラートクエリを構成するときの複数値テンプレート値。 クエリはアラート設定ごとに1回実行され、選択した値が入力されます。 結果は、現在とまったく同じように解釈されます。 何かをひどく誤解していない限り、これが複雑さの大幅な増加とは見なされないため、非常にユーザーフレンドリーである必要があります。

テンプレート値を選択してアラートスコープを単純に制限する機能は、複数のアラート構成がなくても便利ですが（この機能をこの順序で開発するのに役立つ場合）、複数の構成で指数関数的に価値があります。

複数のデータソースがあり、アラートルールでデータソース変数をターゲットにして、多くのデータセンター/環境（個別のTSDBを持つ）でアラートルールを再利用できるというユースケースもあります。このユースケースは解決する必要があります。データソーステンプレート変数をワイルドカードを使用したメトリッククエリとして使用しても、それを解決することはできません。

パネルごとの複数のアラート構成/クエリは、複数のTSDBを処理する方法を提供し、1つのオプションは、アラートクエリのグループ化を許可して、グループ内のすべてのクエリの結果に基づいて状態遷移が発生するようにすることです（現在の動作と同様）シリーズ用）。 それほど複雑ではないようです。

これは間違いなく人気のあるニーズです。アラートを達成するには、移動する必要がありました。
Grafanaから離れて、GraphiteのRenderを使用してカスタムソリューションを作成します
API生データ..動的/テンプレートでアラートをサポートするとは思わない
データは、少なくともGraphiteを使用した複雑なものです。

もう1つの考えは、です。 Grafanaにアラートセクションがある理由はダッシュボードの一部です
これが複雑であると考えられる場合は構成します。 あなたはそれを離れて分離することができます
ユーザーが動的クエリを入力/構成できるアラートビュー、
間隔、あそこの評価条件..これは私たちを意味するかもしれません
重複したダッシュボードを持ってはいけません..意味がありますか？

BR、
ヴィシュワ..

2017年8月23日午前8時1分、「PeterFern」 [email protected]は次のように書いています。

しかし、アラートに焦点を当てたダッシュボードとグラフを作成することはできませんか？
ダッシュボードに探索用の多くのテンプレート変数を残し、
トラブルシューティング？ おそらく多くの場合があることを私は知っています
似ているので、重複した作業のように感じます:(

私は実際にコメントを編集してこのオプションを参照しました（そしていくつか追加しました
その他のアラート関連の問題点の問題）。 あなたが特定したように、しかし
これは、ダッシュボード/パネルの作成（およびすべての場合はメンテナンス）を増やすことを意味します
これらのクエリは、必要なテンプレートバリエーションの数だけ更新する必要があります）
アラートを送信し、アラートの注釈を場所から分離します
それらはで最も役立つかもしれません-アラート注釈付きのテンプレート化されたダッシュボード
相関関係を作成するのに非常に役立ちますが、必要な場合はそれほど役立ちません
複数のブラウザタブを調べて、並べてみてください。

1つのクエリが2つのテンプレート変数、$Aと$Bを使用するとします。それぞれに50があります。
値。 これにより、アラートルールが2500回評価されますか？ つまり
変数が「単一値」の場合、つまりクエリは機能するように構築されている場合
$Aと$Bの値が1つである場合は、それを行う必要があります。 ショーではありません
ストッパー多分、多値変数だけを説明する必要があります
サポートされています。 おそらくもっと多くの制限と問題のある詳細があります
そのため、この機能の実装、使用、理解が非常に困難になります

ここには2つの別々の問題があると思います。 1つは（私は信じています）密接に
＃6041に関連https://github.com/grafana/grafana/issues/6041 、
アラート状態を個別に評価したいという要望があるかもしれません
シリーズ/テンプレート値（前に述べた集約トグル
コメント）。 今のところそれを脇に置いておけば、私は解決するための理想的な方法を信じています
この問題の大部分は、パネルごとに複数のアラート構成を許可することです。
ダッシュボードの場合とまったく同じ方法で変数の補間を行うだけです
出力-ユーザーが単一値または複数値のテンプレート値を選択できるようにする
アラートクエリの構成。 クエリはアラートごとに1回実行されます
config、選択した値が入力されています。 結果は次のようになります
現在とまったく同じように解釈されます。 私がひどくいない限り
何かを誤解しているので、これが大幅な増加とは思わない
複雑で、非常にユーザーフレンドリーである必要があります。

テンプレート値を選択してアラート範囲を単純に制限する機能は、
複数のアラート設定がなくても便利です（開発に役立つ場合）
この機能はこの順序で）ですが、指数関数的に価値があります
複数の構成で。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
。

同じではない@danhallinは、クエリでワイルドカードまたはグロブ式を使用するか、限られたタグのセットでのみフィルターを使用する多くのシリーズを対象とするGrafanaのクエリに変換されるようです。 Libratoアラートルールはダッシュボードとは別に定義されていますが、そうではないので、ダッシュボード全体のデータフィルタリング機能にどのように変換できますか？

私が話しているのは基本的に次のコピーであることがわかりました： https ：//github.com/grafana/grafana/issues/6041

私はこれよりもその機能のリクエストをサポートしています。

サーバーを定期的に起動し、すべてのホスト（mem、hd、cpuなど）に共通するものを測定するテンプレート化されたダッシュボードを用意しています。 可能な組み合わせごとにグラフを含む「アラート」ダッシュボードを作成するのは面倒です。必要なアラートの多くは、すべてのホストに一般化できます。 AFAIKTこの問題は、このユースケースを可能にする方法を求めており、＃6041では解決されません。 私が何かを逃していない限り。

すべての組み合わせに対してグラフとアラートを作成することは、私たちが提案していることではありません。アラートクエリでワイルドカードまたは正規表現を使用して、すべてのホストなどをカバーするようにします。次に、アラート用に調整でき、競合しないアラートとグラフが1つあります。トラブルシューティングと動的フィルタリングの要件。

このユースケースでは、イベントのリアルタイム処理を提供する（潜在的に）一時的なインスタンスがいくつかあります。特定のアプリケーションで生成されたメトリックが0に低下した場合は、アラートを受け取る必要があります。ただし、インスタンスが削除または停止された場合でも、名前付きメトリックが保持されます。それらに関連付けられており、ワイルドカード検索で表示され、誤ってアラートが生成されます。

「SimpleJSONDatasource」から生成されたテンプレート化された複数値変数（Allに設定）を使用してこれを回避しました。この変数には、実行する必要のあるインスタンスの信頼できる情報源が含まれています。すべてが完全に機能します。 残念ながら、アラートを有効にしようとするとすぐに、この機能リクエストが表示されました:)

私たちの特定のユースケースがどれほどユニークかはわかりませんが、テンプレートを使用せずにこれについて警告する他の方法はわかりません-今のところ、Grafanaの外でこれらの問題について警告し続ける必要があります（これは残念です-私たちは非常にヘビーなGrafanaユーザーです！）

+1

したがって、これらの問題が発生しない1つのケースは、テンプレート変数が定数型である場合です。 たとえば、定数変数に依存してそのダッシュボード上のデータを特定のリソースに制限する複数のダッシュボードがあります（複数値変数を使用しなかった理由は、各ダッシュボードが異なるセットアップを正当化するのに十分異なるが、十分に近いためです「テンプレート」ダッシュボードを正当化するため）。 少なくともこの場合（定数変数）、現在のアラート動作については何も変更する必要はありません。

このトピックに関するニュースはありますか？

やあ、

この機能を利用する希望はありますか？ 他のシステムがこの機能をどのように備えているのか疑問に思います。エージェントをインストールすると自動的にポータルに表示され、アラートを設定できるため、一種のテンプレートを使用している必要があります。 （これはNew Relicでの私の経験です）。

@vishwanathhアラート用に個別のセクションを作成するアプローチが気に入りました（グラフパネルに表示するのが複雑な場合）。アラート用にクエリを入力できます。 このように、ユーザーにはプレースホルダーパネル（アラートに使用）が表示されません。

余分なノイズで申し訳ありませんが、これはGrafanaにある本当に素晴らしい機能です。

+1、非常に重要な機能！

さらに、プロメテウスのメトリッククエリ式を変更してテンプレート変数を削除させた場合、これはまったく実行可能ではありません。 したがって、この機能は、prometheus+grafanaが本番環境に移行するために最も重要だと思います。

とにかく、チームが優先順位を検討してください、ありがとう！

5.0が間もなくリリースされるので、次のリリースシリーズでアラートが発生することに焦点を当てたいと思います。 Githubの反応を見ると、アラート関連の欠陥は、ユーザーから遠く離れて最も関心を持っているように見えます。

UI / UXの複雑さの懸念から、これらの問題に取り組むことにいくらかの抵抗があったことは知っていますが、これらの懸念が必ずしも正当化されるとは確信していません。 実際のコードを使用したプルリクエスト以外に、計画/設計に役立つ、またはこれらの問題を前進させるためにユーザーができることはありますか？

@torkeloこれは、タグを使用してすべてのホストのアラートを設定するのに役立ちました。現在、各アラートグラフには、タグの組み合わせによって形成された複数のシリーズが含まれています。 すべてが正常に機能しているように見えました。 しかし、ドキュメントやその他の問題を調べてみると、グラフ内のシリーズのいずれかがすでにアラート状態になっている場合、他のシリーズのアラートも制限を超えてもトリガーされないことがわかりました。

それもまた制限です。

ありがとう。

この機能に関するニュースはありますか？

新しい寄稿者がこの機能を追加するための努力は何ですか？

+1

テンプレート変数がアラート通知に使用されることを許可してください。
+1

+1

解決されることを願っています。

+1

ここで死んだ馬を倒したくはありませんが、同じ問題が発生しているので、既存の提案がすべての状況で機能しない理由についていくつかのコンテキストを提供したいと思います。 回避策についてもいくつかアイデアがありますが、回避策を十分に行うために_いくつかの機能_が必要なのはなぜですか。

以下のすべてのシナリオでは、単一のテンプレート変数を使用しています： $env

「アラートダッシュボードを作成しないのはなぜですか？」

本番環境だけでなく、いくつかの異なる環境について警告したいと思います。 したがって、少なくとも3つの異なる場所に同じメトリックを設定する必要があります（アラートするメトリックだけでなく、すべてのメトリックを含むトラブルシューティングダッシュボード、prodアラートダッシュボード、統合アラートダッシュボード）。 これはすぐに手に負えなくなる可能性があり、ユーザーエラーが発生しやすくなります。

同様に重要なこととして、これはアラートからの自動アノテーションから得られる利益の多くを無効にします。 探索ダッシュボードからアラートダッシュボードに行ったり来たりして、イベントの開始時と終了時のアノテーションを確認する必要がある場合、それはかなり面倒です。

試みられた解決策

これを回避するために行ったのは、ダッシュボードに_特にアラート用に_重複したメトリックを追加したことです。 したがって、アラートを送信するメトリックがある場合は、パネルに移動して、それらのアラートの明示的なメトリックを追加します（そしてそれらを非表示にします）。

警告が必要な特定のパネルのシリーズリストは、次の行に沿って表示されます。

テンプレート化されていないシリーズは非表示としてマークされています。 次に、[アラート]タブで、変数シリーズではなく、_these_シリーズのしきい値を設定します。

このソリューションの問題

ただし、これはうまく機能しません。 例えば：

ご覧のとおり、[アラート]パネルでは、どの環境がアラートを発しているのかを指定できません。そのため、アラートにドリルダウンして、現在どの環境が中断されているかを把握する必要があります。 ただし、これを簡単に修正するには、状態遷移を表示する[アラート履歴]パネルのように説明を詳細にすることができます。

これは少なくともある程度は役立ちますが、このパネルでも、どのアラートがHealthyに戻ったかはわかりません（上のスクリーンショットの説明は、誰かがどのように疑問に思っている場合にシリーズに設定したエイリアスから派生したものです少なくともそれだけ表示するために）。

この特定のチケットが解決されるまで役立つこと

• アラートの入力された説明の代わりにシリーズエイリアスを表示するオプションを許可します（このようにして、エイリアスは少なくともアラートの$変数を指定できます）
• 状態遷移を正常に戻し、シリーズエイリアスも表示できるようにします（上の履歴のスクリーンショット）
• 特定のパネルのアクティブなアラートの凡例値を許可する（私が想定するシリーズエイリアスを使用）

修正方法がわからないもの

複数の環境/変数に対してアラートが構成されているグラフの注釈：

これでは、パネルに入らなければ、どのアラートが発生しているかを実際に判断することはできません。 凡例の提案はこれを明確にするのに役立ちますが、正しい$envが選択されていない場合、注釈にはあまり効果がありません（上の写真では、 intが警告していますが、 prodはダッシュボードで選択された変数であるため、 prodを使用して、グラフの上にintアラートからの注釈を表示しています。

+1

一を足す ：）

この問題の+1を停止してください。 不要なスパムメールを生成します。 githubの問題のコメントにリアクションを追加する機能はしばらく前から存在しており、429人を超える人々が、サブスクライブしているすべての人にスパムを送信する代わりに、最初のコメントを高く評価する方法を考え出しました。

この機能が本当に必要です。テンプレートを使用したいと思いますが、この場合、明確なアラートシステムを用意することが最も重要です。 したがって、これを回避するために、ダッシュボードでテンプレートを作成することは避けています...混乱しています。

私は同意し、この機能は私たちに大いに役立ちます!!!!

+1してください

これが必要です

+1してください。 本当に必要です。

@bergquist @torkelo +1スパムを阻止するために、この問題をロックしていただけますか？