Grafana: 【機能リクエスト】グラフごとに複数のアラート

具体的なユースケース：主要な機能（外部HTTP呼び出しまたはディスクI / Oが発生する場所など）ごとにPrometheusにヒストグラムを記録するようにアプリをインストルメント化し、これらのいずれかが遅くなったときにアラートを出したい。

現在、グラフとアラートは1：1の関係にあるため、このためのダミーグラフを定義する必要があります。 アラートをグラフ自体と同じ場所に定義しておく方がはるかに論理的です。

そして、1つのクエリでそれを定義することはできませんか？

番号; OR条件のチェーンは粗雑であり、アラートの単一の名前ではアラートの正確な理由を明確に識別できません。 私は間違いなくSome part of service X is failingに沿ってアラートを送信したくありません-電話中のエンジニアは私の友達ではありません...

個別のアラートルール名やメッセージなどが必要な場合は、アラート用に個別のパネルを用意する方が理にかなっています。

うん、それはまさに私が今していることです。 近い将来、グラフごとに複数のアラートを実装して、この回避策から離れることができる可能性はありますか？

ありそうもない

多分それに対する巨大な需要があるなら:)

はははOK-怒っている暴徒を騒がせることができるかどうかを確認します;）正直に感謝します。

2人の暴徒がいます:-)複数のタンクの燃料レベルをグラフ化していて、各タンクに低燃料アラートを設定したいと思いました。

タンクごとにしきい値や通知が異なりますか？

その通り。 1つは285ガロンの灯油タンクです。 そのタンクが70ガロンを下回ったときに「灯油低下」アラートを設定したかったのです。 もう1つは500ガロンのプロパンタンクです。そのため、100ガロンを下回ったときに「プロパン低」アラートが必要でした。 それぞれにシングルスタットを設定しましたが、アラートはシングルスタットでは利用できません。

中央値と90パーセンタイルメトリックのグラフがあります。 それぞれについてアラートを受け取りたいのですが。 これを行うには、それぞれに1つのグラフを作成する必要があります。 次に、それぞれに警告と重大なアラートが必要な場合は、それぞれに2番目のグラフを作成する必要があります。

監視するサービスが30または40あり、それぞれに2〜5の主要なメトリックがあります。 複数の顧客に対して同じメトリックをグラフ化するグラフがあります。顧客ごとにアラートを実行する必要はありませんが（まだ）、アラートを設定するメトリックの数が増えます。 数十のグラフを作成するための作業量は非常に急速に拡大します。 現在の本番環境（および以前の本番環境）では、警告と重大なアラートを設定し、複数のメトリックを1つのグラフに表示してアラートを表示すると非常に便利です。

この機能も見たいです。 良い例は、メトリックがしきい値を超えた場合の1つのアラートと、データの更新に失敗した場合の別のアラートです。 つまり、値が高くなりすぎた場合、または値がレポートに失敗した場合です。 これは、データを報告しているものが、grafana（またはバックエンド）との通信を妨げる問題に遭遇したことを示すために使用できます。

こんにちはトルケロ！

この機能にはいくつかの「いいね」があります。 次のリースを入力しますか=）？

@rmsysは、ある時点で、UXの観点とコードの複雑さ（およびUXの複雑さ）の観点から解決するのに時間がかかる可能性があります。まだロードマップにはありませんが、アラートエンジンがさらに成熟し、このためのUXデザインが機能するようになると、来年になる可能性があります。アウト

複数のアラートのもう1つの良い使用例は、さまざまなアクションでさまざまな重大度のしきい値を設定することです。 サーバーが速度低下を示し始めた場合は、電子メールで十分かもしれませんが、速度低下が極端になった場合は、管理者にページングする価値があるかもしれません。

validとinvalidの値を持つメトリックを返すグラフがあります。 これは、2つのクエリを含む単一のグラフを使用して、 validが低すぎ、 invalidが高すぎる場合に発生するアラートを作成できるため便利です。

また、アラートの個別の状態を追跡することは、アラートがトリガーされたかどうかを知ることよりも（エンドユーザーが個々の状態の背後にある詳細を知る必要があるため）常に好ましいとは限りません。

これが何を意味するのかわかりません。 詳細を教えていただけますか？

グラフごとに複数のアラートがどのように機能し、どのように見えるかを説明できますか？ 注釈は何を示し、パネルタイトルの横にある緑/赤のハートが表示されますか（2/5のアラートルールが発砲している場合）？

アラートルール間で何かを共有したいですか、それとも完全に分離されていますか（同じグラフパネルに存在し、同じクエリを参照している可能性があります）。

複数のアラートルールがある場合、しきい値をどのように視覚化しますか？ アラートルールページとアラートリストパネルに別々のルールとして表示されますか？ 次に、アラートタブだけでなく、ルールの特定のインスタンスに移動する方法が必要です。

Grafanaは視覚的なツールであり、アラートルールの状態を（メトリック、しきい値、アラート状態の履歴を介して）簡単に視覚化できるように、アラートルールをグラフに関連付けることを選択しました。 各グラフが複数のアラートルールを表すことができるようにすると、これが非常に複雑になるのではないかと心配しています。これが必要かどうかはわかりません。

シングルスタットパネルでアラートルールをサポートしている@rssalernoは、この問題とは無関係のようです。

@ alex-phillipsシナリオは、個々のアラートルールをより柔軟にすることで解決できるように思えます。

誰かがこれが良いと思われる具体的な例をいくつか持っていますか？ わからない2〜5のしきい値を持つ紛らわしいグラフになるシナリオが表示されないだけで、どのメトリックおよびアラート履歴アノテーションに関連し、それらがどのアラートルールから来たのか（ホバリングせずに）もわかりません。

グラフごとに複数のアラートがどのように機能し、どのように見えるかを説明できますか？ 注釈は何を示し、パネルタイトルの横にある緑/赤のハートが表示されますか（2/5のアラートルールが発砲している場合）？

複数のアラートルールに個別に注釈が付けられると思います。 ハートは色分けされている場合があります。 ルールは、アラート/パネルで区別するために名前を付ける必要があります。

アラートルール間で何かを共有したいですか、それとも完全に分離されていますか（同じグラフパネルに存在し、同じクエリを参照している可能性があります）。

一般的にはそうではないと思いますが、グループには共有のしきい値が必要であり、実装されている場合は名前を付ける必要があります（https://github.com/grafana/grafana/issues/6557#issuecomment-324363795による）。

複数のアラートルールがある場合、しきい値をどのように視覚化しますか？ アラートルールページとアラートリストパネルに別々のルールとして表示されますか？ 次に、アラートタブだけでなく、ルールの特定のインスタンスに移動する方法が必要です。

ルールが追加のカラーパラメータをとる場合、それを使用してしきい値をレンダリングし、そのように区別することができます。おそらくツールチップも必要です。 ルールを切り替えることができると便利です。特定のルールをレンダリングするためのパラメーターは、後者を処理すると思いますか？

シングルスタットパネルでアラートルールをサポートしている@rssalernoは、この問題とは無関係のようです。

彼はその下のグラフを参照していることがわかると思いますが、彼はタンクごとに個別のパネルを持っているため、シングルスタットアラートがその特定のダッシュボードの問題を解決する可能性があります。

誰かがこれが良いと思われる具体的な例をいくつか持っていますか？ わからない2〜5のしきい値を持つ紛らわしいグラフになるシナリオが表示されないだけで、どのメトリックおよびアラート履歴アノテーションに関連し、それらがどのアラートルールから来たのか（ホバリングせずに）もわかりません。

主に、これで＃6557と＃6553をサポートし、@ alex-phillipsと同様に複数のしきい値をサポートしたいと思います。 たとえば、＃6557のユースケースの1つは、さまざまな環境（ production 、 beta 、 devなど）に対して異なるアラートを送信し、複数のしきい値を組み合わせることです。私たちの問題のほとんどを解決します。 複数のルールなしでそれを行うためのより良い方法がある場合、それは私には明らかではありません。

@torkelo

グラフごとに複数のアラートがどのように機能し、どのように見えるかを説明できますか？ 注釈は何を示し、パネルタイトルの横にある緑/赤のハートが表示されますか（2/5のアラートルールが発砲している場合）？

@pdfで提案されたアプローチが好きです

さらに、注釈を表示するアプローチは、現在の場合と同じであり、1を超える条件（それぞれが異なるしきい値を持つ）を持つアラートルールがあります。 また、パネルタイトルの横にある緑/赤のハートは赤で表示されます（少なくとも1つのアラートが発生している場合）。これは、アラートルールの少なくとも1つの条件がtrueと評価される現在のシナリオと同様です。 そして、おそらくタイトルに赤いハートと一緒に数字（2/5）も表示します。

アラートルール間で何かを共有したいですか、それとも完全に分離されていますか（同じグラフパネルに存在し、同じクエリを参照している可能性があります）。

ほとんどのユースケースでは、これらのルールはルール間で何も共有せず、クエリも異なります

複数のアラートルールがある場合、しきい値をどのように視覚化しますか？ アラートルールページとアラートリストパネルに別々のルールとして表示されますか？ 次に、アラートタブだけでなく、ルールの特定のインスタンスに移動する方法が必要です。

それらはアラートページに個別のルールとして表示されます。 [アラート]タブには、おそらくアラートのリストが定義されています。 そうです、通知からalretルールのURL（アラートIDまたはインデックスをキャプチャする必要があります）にアクセスするときに、このタブで特定のアラートルールを強調表示/展開する必要があります。 簡単に解決できるようです。

アラートリストパネルでは、変更はありません。 それらすべてを個別に表示します。 意味的には、各アラートは個別です。 同じパネルに配置されているだけです。

誰かがこれが良いと思われる具体的な例をいくつか持っていますか？ わからない2〜5のしきい値を持つ紛らわしいグラフになるシナリオが表示されないだけで、どのメトリックおよびアラート履歴アノテーションに関連し、それらがどのアラートルールから来たのか（ホバリングせずに）もわかりません。

多くの人がこの機能に賛成していることを考えると、これは間違いなく便利な機能です。 複数のアラートをサポートしている場合、混乱するかどうかは各ユーザーの認識次第だと思います。 IMHO、それが混乱していると思う人は、グラフごとに別々のパネルの現在のアプローチを採用し、視覚化とアラートに同じパネルを使用することの有用性/利便性が、知覚される混乱を上回ると考える人は、複数のアラートの方法を採用します。 確かにそれはUXをいくらか変えるでしょう

Splunkには、高/低アラートがあります。 grafanaで複数のアラートが利用可能な場合は、同じ検索を使用します。これらは、同じ検索に対するしきい値が異なります。

この機能の+1。

このために+1。 ユースケースは次のとおりです。たとえば、すべてのサーバーのCPU使用率を使用して1つのグラフを定義します。 次に、同じグラフで2つの非表示のメトリックを作成します。1つは運用サーバーでのCPU使用率、もう1つは非運用サーバーでのCPU使用率です。 これらの各メトリックには、異なる通知チャネルを持つ独自のアラートがあります。 これを実現するために、複数のチャート、パネル、またはダッシュボードを作成する必要はありません。

この機能の+1。

カテゴリと重大度に関する他の問題のいくつかを読んでここに来ました。 すべてのアラートが実行可能であることに同意します。 ただし、「朝一番に修正する」アラートと「1時間あたり400ドルのコンサルタントをできるだけ早く呼び出す」アラートには違いがあります。

多くの人が言及しているように、これは警告とクリティカルのしきい値によって解決される最も一般的なものです。

技術的には、これはさまざまな方法、ラベル、パネルごとのいくつかのアラート、アラートごとのいくつかのしきい値などで実装できます。

分類が複雑な場合の混乱に関しては、警告/重要な設定では単に赤/黄を使用できます。 赤は黄色を上書きします。

より複雑な設定の場合、問題のある時系列を見つけるためのホバー以外の別のオプションは、点滅する線/領域/何でもかまいませんか？ これにより、正しい時系列に簡単に注意を向けることができます。

ただし、ほとんどのユーザーは、かなり単純なWarn / Critの分離に満足すると思います。

これは、アラートソフトウェア、特にサーバーの監視には絶対に必要です。 ディスク容量、メモリ、CPU使用率、温度、負荷平均....さまざまなしきい値のさまざまなメッセージで構成された複数のアラートが必要なすべての代表的な例。 たとえば、ディスク容量を考えてみましょう。 70％を超えるディスク使用量に対して1つのアラートが必要であり、90％を超えるディスク使用量に対して別のアラートが必要です。

ちょっとしたエッジケースですが、アラートを使用して、製品が数日以内に販売されなかった場合に通知します。 各製品をメトリックとして使用します。つまり、メトリックの1つがアラートしきい値に達したときにアラートを1つだけ取得します。 理想的には、アラートが追加のメトリックがアラートしきい値に入ったことを示している場合にアラートを受信したいと思います。

また、テンプレート変数を使用して、選択した各製品のグラフを繰り返し、左右のy軸に2つのメトリック（ボリュームと粗利益）を重ねています。 これにより、アラートクエリがIN ($sku)の$skuリスト変数を取得しないため、アラートを使用する可能性がなくなります。

これを回避するために、別のクエリBを試してみました。このクエリは、テンプレートクエリを実行して、関心のあるすべてのSKUを検索し、アラートクエリIN (SELECT skus from interested_product_table)に直接入力します。 ただし、これにより、各グラフのすべてのメトリックについて各グラフのアラートが送信され始めます。つまり、次のようになります。

Email Alert 1 - metric1,metric2,metric3
Email Alert 2 - metric1,metric2,metric3
Email Alert 3 - metric1,metric2,metric3
Email Alert 4 - metric1,metric2,metric3

Email Alert 5 - metric4
Email Alert 6 - metric4
Email Alert 7 - metric4
Email Alert 8 - metric4

たとえば、これはかなりスパムです。

この機能が必須であることに完全に同意し、すべての通知が実行可能である必要があることに完全に同意しません。

最も単純な例は、アラートを受け取る可能性があり、翌朝のようにできるだけ早く何らかのアクションを実行する必要がある一方で、本番サーバーを修正するために深夜でも起動する必要がある他のタイプのアラートがある場合です。

私の2セントを投入する-私はこの機能が欲しいです。

別のハートや別の色のハート（グラフ上のアラートの赤は問題ありません）も必要ありません。別の名前が必要なのはメール通知です。

この機能を追加してください。 このようなユースケースの場合、
単一のグラフから
値> X->たるみの場合
値> X + Y-> PDの場合

ここには、実行可能なアラートのポリシーがあります。アラートでは、可能であれば実行するアクションを指定する必要があります。 指標が低すぎる、または高すぎることに基づいて、さまざまなアクションを実行する必要があります。

例：RDS CPUが低すぎますか？ ここで他のスタックの動作を確認してください。 高すぎる？ インスタンスをスケールアップします。

他の人と同様に、さまざまなしきい値でさまざまなタイプのアラートを設定することも必要です。

@jdblackと同様に、高水位警告レベルと高水位緊急レベルが必要です。 私は2つのクエリでそれを実行できることを知っていますが、それは直感的でも洗練されたものでもありません。

自動スケーリングシステムに信号を送る方法としてGrafanaを使用することを考えていました。 メトリックが低すぎる場合は、メッセージ付きのWebhookを送信してスケールダウンし、高すぎる場合は、メッセージ付きのWebhookを送信してスケールアウトします。 複数のアラートがなければ、これは不可能だと思います。 また、「警告」と「クリティカル」のしきい値のユースケースが一般的であるというスレッドの他の人にも同意します。

おそらく、アラートをグラフに結合するという考えを再検討する必要がありますか？ アラートを作成するときに、プレビューグラフを使用して、アラートを個別に作成する必要があるかもしれません。 このデカップリングにより、グラフメトリックを変更する際の作業が増える可能性がありますが、少なくとも、複数のアラートを作成する際の柔軟性が高くなります。

センサーネットワークにGrafana + Influxを使用しようとしています。 ダッシュボードは、アラートを除いて、かなりうまく機能します。 Sensor123が特定のしきい値を超えたときにアラートを受け取る必要があります。 そのためのチャートは必要ありません。アラートだけです。 また、数千のセンサーが必要になる可能性があります。 「いずれかの」センサーがしきい値を超えた場合にアラートを設定できますが、どのセンサーがアラートを送信しているかを知る必要があります。 特定のセンサーを表示するためにテンプレート変数を使用してダッシュボードを設定していますが、テンプレート変数のアラートを追加できません。 テストのために、私は、誰も見ていない追加のダッシュボードに少数のセンサー用の少数のアラートを設定するだけですが、前進するには、アラート用の別のソリューションが必要です。

@torkelo 、これに関する公式コメントから1年が近づいています-アラートシステムがしばらくの間使用されてきたので、共有できる更新があるかどうか疑問に思っていますか？

@MakoSDVは、そのユースケースにkapacitorの使用を検討する必要があります。

この機能の+1。 これは、2レベルのアラートにも非常に役立ちます（例：何か> X =黄色のアラート、何か> Y =赤いアラート）

アラートをより柔軟にするための+1

私は暖房ボイラーの温度グラフを監視しています。低温のしきい値は些細なものであり、重要ではない通知チャネルに移動する必要がありますが、高温は緊急であり、緊急チャネルを介してブーンという音を立てる必要があります。 ここでは、複数のアラートルールが非常に理にかなっています。

この問題が見捨てられたように見えるのは残念です。 開発者の注意を引く方法を知っている人はいますか？

UIに関しては、オーバーライドを実装する方法でアラートを実装するのは比較的簡単で、UIをあまり変更せずに1つ以上のアラートを許可できます。

@Gaibhneは書いた：

開発者の注意を引く方法を知っている人はいますか？

おそらくサポートにお金を払う？ 深刻なアラート関連の欠陥に利用できるリソースはないようですが、Githubのユーザー評価で最も高い問題が何年も続いています。

このリクエストには+1。

統合する外部サービスへのリクエストが、Grafanaでグラフを作成したときにタイムアウトした場合に備えて、アプリにカウンターが設定されています。

後で外部サービスを追跡できるように、タイムアウトが2、3回ある場合は、タイムアウトが多い場合は、ほとんどのお客様がアプリに影響を与えている可能性があるため、対応する必要があります。すぐに対処します。

これも+1。

現在、グラフに2つの個別のアラートを設定しようとしています。

1. データが_警告_レベルに達した場合のSlackメッセージ
2. データが_クリティカル_レベルに達した場合のPagerDutyアラート

現在のところ、これを実現するには、同じデータの2つの別々のグラフを作成する必要があります。 同じグラフに複数の異なるアラートを作用させる方が理にかなっています。

@torkeloこれが2019年に入る計画についての更新はありますか？

+1

表示された環境を切り替える変数を使用して、複数のクライアント/環境の同じマイクロサービスを監視するダッシュボードがあります。

クライアント/環境を識別できるようにアラートのタイトル/テキストで変数を使用できれば、現在の苦痛を軽減できますが、長期的には、同じグラフを使用して異なるしきい値で個別のアラートを作成できるようにする必要があります。

アラートごとに異なるクエリを使用し、クエリをグラフに表示されないように設定する必要がある場合でも、これはすばらしいことです。

@itonlytakeswonについて説明していることは、https：//github.com/grafana/grafana/issues/6557にも関連しているようですので、それも追跡することをお勧めします:)

これはまだ機能ではないのですか？

@ jsterling7は、私たちが望むユースケースを完全に説明しています。

@torkeloすべての機能リリース

複数のアラートを使用するか、アラートのタイトル/本文のどこかにタグ値を許可することで、これを解決できます。 いくつかの独立したソースを持つタグ付きメトリックを示す単一のグラフがあり、どれがしきい値を下回っているかを知りたいです。 現在、これを実現するために必要な10個の個別のグラフを作成していますが、機能が不足しているように感じられ、長期的なメンテナンスには不十分です。

需要が高いようですが、私もこのような機能が必要な方です。 私はほとんどgrafanaが大好きですが、突然この制限により私はオフになります。

私のユースケースは、ここで参照されている他のユースケースと＃6557の問題に似ています。 1つのテンプレートダッシュボードで複数のelasticsearchクラスターを監視しています。 それらへのアラートを個別にトリガーしたいのですが、現在は、クエリをハードコーディングしてグラフを作成するだけでなく、このアラートを機能させるためにクラスターごとにグラフを作成する必要があります...

+1、これは私たちの環境に大いに役立ちます！ グラフ設定ごとに黄色/赤の「ハート」2アラートでさえ、赤がトリガーされた場合、黄色をオーバーライドします。

+1これは素晴らしいことです。各条件にオプションの構成可能なアラート通知を許可するだけで、特定の条件がない場合はデフォルトの通知メッセージにフォールバックできるようにするのは簡単だと思います...それを実現する最も簡単な方法私が思うに ？

+1それは私たちにとっても本当に役に立ちます。 複数の変数をテンプレート化したダッシュボードがたくさんあります。アラート名とアラート通知の両方でテンプレートの置換を行うと便利です。

+ 1、IMOこれはすべての監視システムに存在する必要があります...アラートの重大度を識別してそれに応じて対応する必要がある多くの状況があります。つまり、同じダッシュボードに異なるしきい値を持つ複数のアラートがあります。

私からも+ 1-これがまだ存在しないことに驚いた！

+1

この機能は、テンプレートクエリのサポートの制限と密接に関連していると思います。

インスタンスにテンプレートがあり、ラベルを入力するクエリを使用して、プロメテウスフィードグラフをいくつか設定しました。 テンプレート値の非表示クエリを作成することで、テンプレートの問題を回避します。

テンプレート値ごとに個別のアラートが必要ですが、一般的なフリーサイズのアクションとメッセージを含む単一のアラートに制限されています。 長いORリストを使用して、すべてのクエリについてアラートを出すことができますが、これは大雑把に感じます。

別の方法は、アラートソースとして機能するためだけに、誰も見ていない大量のパネルを備えた別のダッシュボードを作成することです。

複数のアラートのサポートを追加することは、テンプレートクエリアラートをサポートするための最初のステップになる可能性があるようです。

+1。 これは必需品です！

+1これは非常に便利です

@torkelo 「アラートルールの名前やメッセージなどを個別に表示する場合は、アラート用に個別のパネルを用意する方が理にかなっています。」

これは意味がありません。 有用な非一般的なアラートメッセージを送信できるようにするためだけに、同じパネルを複数回視覚化するようにユーザーに要求することは解決策ではありません。 これは、機能であるべきもののハックであり、製品の有用性を低下させるノイズを追加します。

@torkelo 「アラートルールの名前やメッセージなどを個別に表示する場合は、アラート用に個別のパネルを用意する方が理にかなっています。」

これは意味がありません。 有用な非一般的なアラートメッセージを送信できるようにするためだけに、同じパネルを複数回視覚化するようにユーザーに要求することは解決策ではありません。 これは、機能であるべきもののハックであり、製品の有用性を低下させるノイズを追加します。

その通り。 パネルごとに複数のアラートの場合は+1

私たちの状況では、バッテリーのセル電圧を測定しています（バッテリーあたり16セル）。 比較のために16シリーズを1つのパネルにグラフ化し、バッテリーごとに異なるパネルを用意しています。

パネル（グラフ）に対する単一のアラートはあまり役に立ちません。 アラートの電子メールがどのセルが電圧の点で範囲外にあるかを示すように、セルごとに少なくとも1つのアラートを設定する機能が本当に必要です。

私たちの場合、許容電圧範囲は各セルで同じであるため、上限と下限を定義し、個々のセル範囲をそれらの定義された制限に関連付けることができれば素晴らしいと思います。

現時点では、セル系列に対して16 x ORステートメントをプログラムし、（再）プロセス内の各セルの制限を定義する必要があります。セットアップが面倒で、メンテナンスの悪夢を修正する必要があります。

理想的には、グラフパネルの各セルの警告および重大なイベントもプログラミングする必要があります。

ユーザーが特定した要件を網羅するようにアラート構造が変更された時期が来たと思います。 これらの要件は通常、アラートを生成するSCADAシステムに実装されています。 確かに、それは本当に単なるロジックエンジンですか？

これに関する更新はありますか？ この機能は、大規模な展開には必須の機能だと思います。 特に、たとえばストレージ使用量を示す単一のグラフが必要なため、70％、80％など、大量のグラフではないアラートが必要です。

私はちょうど今これに遭遇しました、そして私はこれをまだ行う方法がないことに非常に驚いていますD：

https://github.com/grafana/grafana/pull/20822#issuecomment -561047900これは将来実装されず、アラートがダッシュボードから完全に削除されるように聞こえます。

これはダッシュボードのjsonモデルにどのように影響しますか？ これについてもっとニュースがあるとき、誰かが話すことができますか？

これは非常に必要な機能でした。 今後の状況に関する最新情報はありますか？

パネルごとに複数のアラートの場合は+1

この機能の+1。

これは非常に必要な機能でした。 今後の状況に関する最新情報はありますか？

この機能が必要です。

3年後..（リクエストの数にもかかわらず）なぜこれが実装されないのか誰かが教えてくれますか？
それを実装するのは技術的な制約によるものですか？ 拒否されましたか？ やることですか？
前に言ったように、「基本的な機能」のようです。
例：アラートを追加した場合、ダッシュボードと200台のサーバーを備えたシリーズがあります。
200台のサーバーの1つが停止しています：かっこいい名前のアラートを受け取ります
おっと、新しいサーバーが停止しています。アラートはありません（または、ダッシュボードを更新するか、24時間後にリマインダーを待つ必要があります。）
これをチェックボックスのように追加して、シリーズの行ごとに（「フル」シリーズではなく）アラートを受け取ることができるようにすることはできませんか？
開発者の誰かが、grafanaチームがフィードバックに答えることができる場合...

アラート用のプロメテウスを試して、ダッシュボードを実行するためにグラファナを残していただけませんか？

@beastea Grafanaを機能させるためだけに別のツールをセットアップする必要がある場合は、Grafanaを使用しても意味がありません。 この機能はそこに存在し、ツールは1つしかないため、Datadogに移行します。

@ anne-nelsonは、メトリクスギャザー、メトリクスストレージをセットアップする必要があります。適切にセットアップするには、Grafanaを機能させるために、その周りのHAを試してみてください。
Datadogは1つのツールであるだけでなく、それを非表示にして適切な作業を実行します。また、datadogでgrafanaを使用することもできます： https ：//grafana.com/grafana/plugins/grafana-datadog-datasource

@beasteaこれらのツールが何であるかわからないので、使用しているとは思いません。 メトリックはInfluxに送信され、GrafanaではなくDatadogに送信されます。 直接送信できるのに、Grafana経由でDatadogに送信するのはなぜですか？ できるだけ少ない数のツールを使用したい。

@ anne-nelsonアプリにメトリクスプッシュを実装できますが、ディスクやその他のstufで何が起こっているかを知ることができるように、システムメトリクスの一部もプッシュしておくと非常に便利な場合があります。 これは、メトリクスギャザー、telegraf、collectd、fluentdなどのようなことを行うローカルデーモンの意味です。
セットアップでの流入-メトリックを保存し、内部の流入クエリ言語を使用してデータを操作する機会を与える生データへのWebUIフロントエンドとしてgrafanaを介して検索を実行する豊富な機能を提供するものです。
Influxの代わりにDatadogを使用する場合、まったく同じように機能します。 ここでのGrafanaは、データにアクセスするためのUIです。 一般的な設定で。 したがって、データには何の影響も与えず、グラフに表示するだけです。 とにかくそれらを直接送信します。
あなたが説明したように、あなたがインラックスで作業している場合、あなたが説明した問題を解決するためにkapacitorまたはfluxを使用することを検討されていないのは、それらが多くのリーチャー機能を提供しているためです。同じ環境。 フラックスは、流入輸送パッケージの一部ですらあります。

本当に助かります。

@beasteaは、おそらくgrafanaの「アラート」機能を削除し、人々を別のツールに移行する方が良いでしょう（複数のツールのgazファクトリーを回避するため）？
つまり、OK、kapacitor、prometheusなどを使用できます。ただし、アラート機能はGrafanaにすでに存在するため、私の場合は意味がありません。

ところで、行ごとにアラートを出すためにこのチェックボックスを追加するのを防ぐにはどうすればよいですか？ おそらく説明は理解するのに役立つでしょう。

@beasteaGrafanaを使用しないように誰かを説得しようとしているのは本当に奇妙に思えます。

アラートがGrafanaの機能である限り、anthoszが指摘しているように、グラフに複数のアラートを追加する機能を期待するのは妥当です。 アラートにGrafanaを使用するべきではないと思われる場合は、Grafanaにアラートを機能として含めるべきではありません。 多くの人がこの機能を望んでいること、そして多くの競合製品がすでにそれを提供していることは明らかです。 なぜこれほど多くの反発があるのか​​、私は正直に理解していません。

@ anne-nelson私は誰かにやりたいことをやらないように説得しようとはしていません。 私は、今日すでに解決策を提供している可能性のある別の方向性を検討するためのアドバイスを提供しようとしています。
私はあなたが何のために何を使うべきかを指示しているのではなく、今日あなたに解決策を与えることができる代替案を提供しています。 私は後戻りしていません、私はあなたにアドバイスを与えています。 私のアドバイスが役に立たないと思うなら、それは残念ですが、これはそれです。 あなたが私があなたを苛立たせていると感じていること、そして私が私のアドバイスに強引すぎることを残念に思います。
楽しい時間をお過ごしください。

@beastea防御力のおかげで、Grafanaで働いていたと思います。 この機能は多くの人に関係があり、機能のリクエストで代替製品を提案することは役に立たず、この議論を狂わせます。 これはstackoverflowではありません。

誰もがそれをノックオフできますか？ あなたは潜在的に何百人もの人々にスパムを送ります、これは生産的ではありません。

追加のノイズでごめんなさい。

@torkeloこの機能リクエストの最新情報を提供していただけませんか？ このトピックは何年にもわたって開かれており、ご覧のとおり、まだ関心があります。 少なくとも、これが現在のロードマップに含まれているかどうかについて、ある種の「公式」の回答を得るために、このトピックに関する喧嘩や不必要なおしゃべりを減らすのに役立つかもしれません。 乾杯。

これと類似している＃6041は完全に無視されます。 なんでだろうか。

私たちの運用チームがプラットフォームに新しい統合を登録するので、私たちにとってそれは理にかなっています。 メトリックの送信を自動的に開始します。 そして、grafanaの1つのパネルだけがこれらすべてを監視しています。

複数のシステムがダウンした場合、最初のシステムのアラートのみを受け取ります。 そして、あまり説明的でもありません。

1つがダウンし、もう1つが消えても、アラートは再度発生しません。

これのユースケースは、プロメテウスとグラファナを介してマルチウィンドウマルチバーンレートアラートを定義するためのものです。 これは、 https： //landing.google.com/sre/workbook/chapters/alerting-on-slos/にあるGoogle SREハンドブックで定義されているように、SLOを監視するためにこのタイプのアラートを設定するための標準的な方法です。

絶対に必要です、これをフォローアップしてください。

また、PrometheusアラートからGrafanaアラートに移行しました。これを絶対に楽しみにしています。

これに対処する際の既知の課題をリストアップする前にGrafanaに取り組んだことがある人はいますか？

ねえ@torkelo 、多分あなたはこの問題について私たちを啓発することができます！

7.xを見てがっかりしても、アラートは改善されませんでした-アラートを完全に削除するという以前の提案では、希望は満たされませんでしたが、もしそうなら、7.xでアラートを削除することは間違いありませんでした刷新の規模を考えると論理的ですか？

この問題が長い間開かれている理由を理解できるように、これを実装するのが非常に難しい理由について、ある種の更新を入手するのは素晴らしいことです。

@torkeloこんにちは。
私にも同じニーズがあります。単一のグラフで単一のメトリックに対して複数のアラートがありますが、複数のサーバーが監視されています。
'/'パーティションに空き領域のメトリックが定義されたサーバーが約100台あります（たとえば、このようなメトリックが数十あるため）。 また、「/」の空き容量が20％未満になる場合は、各サーバーで単一の一意のアラート通知を受信する必要があります。
たとえば、server2がアラートをスローし、問題の解決に取り組んでいる間、server4が同じアラートをスローする場合、現在は発生しません。通知は届きません。 または、いくつかの機能が不足していますか？

サーバーごと、メトリックごとにパネルを増やす方法は、方法ではありません。
誰かが私にアドバイスをしてくれませんか、これを可能にする方法はありますか？
Grafanaをアップグレードする必要がありますか（現在のバージョンは6.3.5です）？ いくつかの拡張機能を追加しますか？ プラグイン？ 他に何か？

アドバイスや支援をしてくれるすべての人に感謝します。

@torkeloこんにちは。
私にも同じニーズがあります。単一のグラフで単一のメトリックに対して複数のアラートがありますが、複数のサーバーが監視されています。
'/'パーティションに空き領域のメトリックが定義されたサーバーが約100台あります（たとえば、このようなメトリックが数十あるため）。 また、「/」の空き容量が20％未満になる場合は、各サーバーで単一の一意のアラート通知を受信する必要があります。
たとえば、server2がアラートをスローし、問題の解決に取り組んでいる間、server4が同じアラートをスローする場合、現在は発生しません。通知は届きません。 または、いくつかの機能が不足していますか？

サーバーごと、メトリックごとにパネルを増やす方法は、方法ではありません。
誰かが私にアドバイスをしてくれませんか、これを可能にする方法はありますか？
Grafanaをアップグレードする必要がありますか（現在のバージョンは6.3.5です）？ いくつかの拡張機能を追加しますか？ プラグイン？ 他に何か？

アドバイスや支援をしてくれるすべての人に感謝します。

この問題は2017年から公開されています（@torkeloの答えは🤡 「アラート用に個別のパネルを用意する方が理にかなっています」🤡（600台のサーバーがある場合はサーバー/アラートごとにパネルを作成するのが非常に便利です）🤡）。

唯一の方法は、Grafanaから別のソリューションに移行するか、維持するための複数のツールを備えたgazファクトリを作成することだと思われます。

@ anthosz-どうもありがとう。 問題は、環境が私たちのものではなく顧客のものであるという事実です。したがって、顧客の「これにお金を払わない」を克服するために、彼が私のリードのためにこれを主張することは、私にとって非常に不安な作業の一種です。 。
ただし、少なくとも、「このようなトリガー/アラームを整理する可能性はありません-このように」という事実がいくつかあります。

再度、感謝します。

_join（voice、choir）_
回路に電流センサーがあり、公称1.5アンペアのエアポンプと公称10アンペアの排水ポンプを監視しています。 エアポンプは24時間年中無休で稼働し、排水ポンプはタンクレベルに基づいてオンデマンドで稼働します。 すべてが正常である場合、電流（I）は、排水ポンプがオフの場合は1.5A、排水ポンプがオンの場合は11.5Aです。

最初の一般的な障害は、エアポンプが焼損することです。これは、エアポンプが停止したときに、電流が流れていないか、排水ポンプが稼働していることを検出する（Imax <0.5Aまたは9A〜11AのIavg）によって警告されます。 これは、システム障害を回避するために48時間以内に対処する必要があります。 データは1分あたり1ポイントで、90分後にアラートが発生します。

同じグラフで2番目に必要なアラートは（Imax> 14Aまたは2Aから9Aの間のIavg）で、これは、ポンプが必要なときに排水ポンプが詰まっているか、エアインラインであることを示します。 これははるかに緊急のアラートであり、3時間以内に対処する必要がある場合があるため、5分後にアラートを送信するのが理想的です。

両方のアラートは、LoRaを介してデータを送信する同じリモート電流センサーからのものです。 複数のアラートを使用すると、同じセンサーのダッシュボードクエリを複製する必要がなくなります。

@torkeloの複数のグラフは、多くのユーザーにとってスケーラブルではありません。 これは追加するのがとても簡単なことのように思えます、そして私はあなたたちがそれを考慮していない理由に興味がありますか？

多分それに対する巨大な需要があるなら:)

ねえ@torkelo 、あなたは巨大な需要として何を考えますか？ あなたのコメントの96のコメントと250の「いいね」は巨大ですか？ これは8番目にコメントの多いオープン機能リクエストであり、それより多くのコメントがあるクローズド機能リクエストは1つだけです。 これは、より多くの：+ 1：リアクションを含む3番目のオープン機能リクエストでもあります。 ロードマップを入力するには何が必要ですか？

@torkelo非常に単純なケースシナリオがあります。

値がしきい値を下回った場合のアラートと、値が（異なる）しきい値を超えた場合のアラートとは異なるアラートが必要です。

これは別のシナリオです。 正常なサーバー数を監視する場合、1台のサーバーを失ったとき（10分以上かかっていない限り問題にならない正当な再起動）と5台のサーバーを失ったときのアラートが異なります。

これがさらに別のシナリオです。 キューの増加率がしきい値を超えた場合は別のアラートを設定し、キューサイズ自体がしきい値を超えた場合は別のアラートを設定したいと思います。

視覚化に関しては、コミュニティは最初からどんな解決策にも満足していると思います。 たとえば、最初のアラートのみを視覚化します（したがって、UIを変更する必要はありません）。 ホバーするとどのアラートがトリガーされたかを示す垂直線ですべてのアラートを視覚化します。 特定のシリーズなどにカーソルを合わせた場合にのみ、しきい値/アラートを表示します。

ちょうど私の2セント。

こんにちは！

ここでチャイムを鳴らしたかったので、私たち（Spotify）もこれが必要です。

現在、Grafanaからアラートを取得する独自のアラートエンジンを実行し、時系列ごとにアラートを送信しています。 現在、時系列ごとのアラートアノテーションをgrafanaにプッシュバックしています。

したがって、UIに関しては、アラートの最初の時系列により、パネル/アラートが「アラート」状態になり、後続の各アラートが積み重なっていきます（状態履歴には、アラートに対する複数の更新と、同様に複数の変更が表示されます）。 「ok」に戻る）

これは私たちが常にアラートを行ってきた方法であるため、これが「必要」です。したがって、時系列ごとのアラートから離れることは、最大10,000のアラートにとって大きな社会的変化になります。 Grafanaネイティブアラートを使用および採用し、それをサポートするようにデータソースを更新したいと考えています。

ここでチャイムを鳴らしたかったので、私たち（Spotify）もこれが必要です。

Grafanaエンタープライズも使用しましたか？ たぶん開発者を助け/やる気にさせることができます=）

また、この機能、同じグラフから複数のアラートをトリガーする機能もぜひご覧ください。 「下」および「上」の状態でトリガーする機能を提供し、より重要なしきい値違反の前に、事実上琥珀色の警告となる可能性があります。

現在、Grafanaからアラートを取得する独自のアラートエンジンを実行し、時系列ごとにアラートを送信しています。 現在、時系列ごとのアラートアノテーションをgrafanaにプッシュバックしています。

@sjoebooはここでは少し話題から外れていますが、公開されているものはありますか？

@vbichovはまだですが、時間枠は流動的ですが、アラートエンジンをオープンソース化したいと考えています。 （ほとんど理想的ではない）内部フォークにあるパッチを共有して、注釈を介したアラートの時系列ごとの追跡を可能にできると確信しています。

注、アラートエンジンは現在、TSDB（https://github.com/spotify/heroic）に固有のものです。

この機能の+1。 これは警告/クリティカルのようなものです。 人生が悪化する前に警告を受けたいのです。 次に、緊急のアラートを取得して、すぐにアクションを実行する必要があります。

ユーザーからの3年間のリクエストの後、これが実装されていないことに驚いています。

複数のパネル（アラートごとに1つ）を作成する必要があると、ダッシュボードが詰まり、新しいアラートの追加が必要以上に複雑になります。

パネルごとに複数のアラートを定義できないのに、なぜアラートタブに1が表示されるのかといつも思っています。 [クエリ]タブでは、この数は定義されたクエリの数も示します。 だから私はいつもこれが可能だと思っていましたが、これがまだ利用できないことに非常に驚いています。

これがまだ実装されていないのは興味深いことです。 アラートタブの「カウント」は、複数ある可能性があると信じ込ませるため、誤解を招く可能性があることに同意します。 また、アラートルールごとにパネルを設定するのは少しばかげています。これは、アラート用のパネルにすぎない「役に立たない」ダッシュボードがあることを意味します。 それは確かに厄介なお尻のダッシュボードですが、これを実装する唯一の方法です。 主に、名前や通知エンドポイントの組み合わせについてさまざまなルールを設定できるようにするためです。 控えめに言っても複雑です。

これは行われましたか？
Grafanaバージョン= 4.x

現在、Grafanaバージョンは7.xになり、この機能は表示されませんでした

これは行われましたか？
Grafanaバージョン= 4.x

現在、Grafanaバージョンは7.xになり、この機能は表示されませんでした

とてもナイーブ😁

この機能の+1。
単一のメトリックについて

1. コンポーネントが期待どおりに動作しておらず、セカンドラインサポートによる綿密な監視が必要であることを示す警告アラート
2. コンポーネントに障害が発生していることを示すエラーアラートが発生し、3次ラインエンジニアリングへのコールアウトがトリガーされます。
   メトリックの複製は不器用であり、ダッシュボードの監視が混乱します。

非常に多くの単純な機能がこのグループによって絶えず拒否されています。他の多くの機能要求を確認してください。これは基本的なことのようです。

別の例を挙げましょう。

Synologyを実行していて、警告したいと思います。 RAIDステータスの通常の値は1ですが、劣化値は11、クラッシュ値は12です。劣化とは、データに引き続きアクセスできることを意味します。 クラッシュは、データが失われる可能性が高いことを意味します。

RAIDが低下した場合は警告を送信し、RAIDがクラッシュした場合はクリティカルアラームを送信したいと思います。
複数のボリュームとストレージプールがあり、それぞれに複数のグラフを要求することはスケーラブルではありません。

これは、ディスクスペースの使用量のような単純なものにも適用できます。
ディスク使用量が80％に達した場合は警告を送信し、ディスク使用量が90％に達した場合はクリティカルアラームを送信したいと思います。 ディスクごとに複数のグラフを作成することは、合理的な質問ではありません。

そして、これはUIでは難しいというコメントがわかりません。 ダッシュボードのリストである同様のものがすでにあります。 [アラート]タブをクリックすると、下部に[新しいアラートの作成]ボタンが付いた名前によるアラートルールのリストが表示されます。 各アラートルールには、その右側に「編集」、「無効化」、または「削除」オプションが必要です。 アラートをクリックするか、編集ボタンをクリックすると、表示されている既存の編集ページに移動しますが、その特定のアラートルールが表示されます。

ディスクごとに複数のグラフを作成することは、合理的な質問ではありません。

APIを使用して、ダッシュボードとそのアラートの作成/更新を自動化できます。 必要に応じて、クエリを定期的に実行してターゲットのサービス検出を取得し、アラートまたはそれらを自動的に作成することで、プロメテウス（またはお持ちのソース）をクエリするプログラムを作成できます。

この問題が持っている巨大なフィードバックで、この機能がまだ実装されていないことは信じられないほどです。

マゼラン望遠鏡の視覚化およびアラートエンジンとしてGrafanaを使用しています。 すべてが1つのプロットに含まれることに値する特性を共有するサブシステムが複数ある場合、問題が発生して1つが正常に動作しなくなったときに、ユーザーは不可解な警告を受け取り、失敗しているものを掘り下げる必要があります。

ダミープロットの作成は回避策であり、解決策ではありません。 これは基本的なようです！

+1必要な機能

+1

OPとまったく同じ状況。 すでに実装されているはずの基本機能。

人々は何も価値を追加せずにこのスレッドの問題をスパムするのをやめることができますか？

問題の上部にある反応を使用して、関心を示します。

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-descは、スパムを送信する人よりも「人気のある」問題をメンテナが主張するのに非常に役立ちます。誰もが問題の説明を見るだけですでに明らかな情報を受信トレイとgithub通知に電子メールで送信します。

それが非常に基本的なものである場合、他の人が無料で仕事をすることを期待しているすべての不平を言う人の誰かがこれを自分で実装し、プルリクエストを行うか、メンテナが上流でそれを望まない場合は自分のフォークを維持する必要があります。

@thomasf 「人々は価値のあるものを何も追加せずにこのスレッドの問題をスパムするのをやめることができますか？」 -あなたと同じように？

メンテナがまだスレッドにいる場合、新しいコメントは少なくともそれを思い出させます。 この時点では、なんとなく役に立たないように思われます。この長い後、メンテナがそれを実装する方法はありません。人々は、メンテナが実際に気にするDatadogのようなより良いツールに実際に移行する必要がありますが、何百ものコメントがあります（特に実際のシナリオがある場合） ）は、単に親指を立てるだけでなく、より多くの影響を及ぼします。

メンテナがまだスレッドにいる場合、新しいコメントは少なくともそれを思い出させます。 この時点では、なんとなく役に立たないように思われます。この長い後、メンテナがそれを実装する方法はありません。人々は、メンテナが実際に気にするDatadogのようなより良いツールに実際に移行する必要がありますが、何百ものコメントがあります（特に実際のシナリオがある場合） ）は、単に親指を立てるだけでなく、より多くの影響を及ぼします。

または、スパムが原因で、メンテナがこの問題に関する通知の購読を解除している可能性があります。更新なしで+ 1 /メッセージが多いのはそれだけではありません。 GrafanaとDataDogを比較しないでください（私たちは両方のユーザーであり、DataDogに戻る方法はありません）

これを入手する最良の方法は、貢献することです（またはおそらくGrafana Entrepriseにお金を払うことです）

あなたは非常に間違っています。 無料かどうかあなたは置くことはできません
forum / slack / github / Feedbackチャネルを作成し、それを無視します。 あなたがそれを考えるなら
オープンソースライセンスにソフトウェアを置くことは、「苦情なし」と「人々」を意味します
あなたの機能を無料で開発します」あなたは再び非常に間違っています。
私の場合、これらの機能を使用すると、grafanaを10個まで販売できることを説明しました
私の顧客。 無視された私、それは顧客に腹を立てていることを意味します。 すごい
おそらく彼らは「十分な」お金を稼ぎ、それ以上は欲しくないのだろう、私は幸せだ
彼らのために....

Il giorno mer 14 ott 2020 alle ore15：35ThomasFrössman<
[email protected]> ha scritto：

何も追加せずに、このスレッドの問題のスパムを阻止できますか？
価値？。

問題の上部にある反応を使用して、関心を示します。

それがとても基本的なものであるなら、多分ただ期待しているすべての不平を言う人の誰か
彼らのために無料で仕事をする他の人々はこれを自分で実装する必要があります
プルリクエストを行うか、次の場合は独自のフォークを維持します
メンテナは上流でそれを望んでいません。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
。

私が_any_ソフトウェアに費やしても構わないと思っている金額は、私が投資のために提供されると予想できるカスタマーサービスのレベルに正比例します。 それが「有料サポート」を提供するオープンソース製品であろうと、商用製品であろうと、それは実際には重要ではありません。

この問題を抱えていることは、プロジェクトのメンテナからのぞき見がない限り、残念ながら、お金を使うことによって何かが変わるかどうかについての合理的な疑いの感覚を推測することなく、長い間開いたままです。 ソフトウェアを販売しようとしている場合は、これを検討するのが賢明でしょう。

プルリクエストを行うか、独自のフォークを維持します

開発者からどこから始めればいいのかというヒントさえあれば、そうしなければならないと思うかどうかに関係なく、単に価値が非常に大きいという理由だけで、これを検討すると言っているのは私だけではないと確信しています。提供。 残念ながら、そうではないようで、メンテナがあまり気にしていないように見える機能のために製品をリバースエンジニアリングしようとすることにほとんど興味がありません。

最後に、スレッドが閉じられている/ロックされていない限り、私は人が彼らの心を話さない理由がわかりません。 それがあなたに合わない場合、あなたは退会することが許されます。 私は実際、これの相対的な不条理について嘆いている人々を読むのを楽しんでいます。 😁

8で計画されているアラートNG（NextGen）アラートは、単一のアラート定義からの複数のアラートインスタンスをサポートします。 したがって、prometheusのようなシステムでhost=*のようなものは、ホストごとにアラートを作成します。

https://github.com/grafana/grafana/issues/6983#issuecomment-712915673に追加された単一の統計のコンテキストでのこれに関するいくつかの一般的な情報

私たちはまだ設計とプロトタイピングを行っていますが、物事に関するいくつかの最初の考えに対応するために：

グラフごとに複数のアラート

アラート定義は独自のエンティティになるため、パネルに関連付けられることはありません。 アラート定義から、複数のアラートインスタンスになる可能性があります。 次に、パネルはインスタンスまたは定義をサブスクライブできます。 ただし、ダッシュボードパネルからアラートを作成するための優れたUXパスが必要になると思います。これは、優れたフローだからです。

また、アラートの個別の状態を追跡することは、アラートがトリガーされたかどうかを知ることよりも（エンドユーザーが個々の状態の背後にある詳細を知る必要があるため）常に好ましいとは限りません。

1つの定義からの多くのアラートが許可されると、それらをどのようにグループ化するかが問題になります（多くのアラートを取得できるため）。 私は現在、これがAlertingNGでどのように機能するかについて2つのパスを見ています。

1. アラートインスタンスのグループ化を処理できるpagerdutyやalertmanagerなどのIRMでアラートNGを使用します。
2. より大きなスコープディメンションでグループ化するようにクエリを変更します。 したがって、たとえば、 host=*,cluster=* cluster=*をクエリする場合（またはデータソースのようなSQLの場合はgroup by）。 または、サーバー側の式（アラートngに付属）に機能を追加して、データソースがこれを行わない場合にgroup / byピボット操作を可能にする予定です。 これは、IRMを使用せず、Eメール/ Slackなどのサービスに直接送信する場合に当てはまります。

警告/クリティカル

これはもっと複雑です。 WIP設計では、機能として削除しました（少なくともアラート定義については、アラート定義を複製し、変更し、重大度でラベル付け/タグ付けする方法があります）

多くの場合、これは非常に便利であるため、これは困難です。

• 私にとって、警告/クリティカルには明確な用途があります：壊れた/壊れた、または劣化した/壊れたアプローチ。
• それらがないと、多くのセットアップで、さまざまな重大度レベルに対してかなりの量のアラートが繰り返されることになります。

では、なぜそれらを持たないことに決めたのでしょうか？ それはかなりの非自明な複雑さを追加します：

• 別のメトリックからのしきい値（または値ではなくクエリ時間の異なる範囲であるしきい値）をサポートする場合、実行する条件は2つあります。
• アラートインスタンスの状態については、少なくとも次のことをサポートしたいと思います。
  
  
  
  • 不明：インスタンスが消えました
  
  
  • エラー：インスタンスに関する問題があることがわかったはずのクエリが壊れています
  
  
  • 警告：条件は真です
  
  
  • 普通。 条件は真ではありません
  
  
• また、FORのような式を継続したいと考えています。 さらに状態を追加する場合、通知の欠落やノイズの結果としてフラッピングが発生しないように設計することは複雑です。 一般に、ステートマシンは時間の経過とともにバグが発生しやすく、正しく理解するのが困難です（そのようなものが好きな場合は、TLA /アクションの時相論理を検索して詳細を確認してください）。 したがって、重大度レベルを追加すると、状態空間が予想以上に増加します。 つまり、意図しない行動や、メンタルモデルを作成するのが難しい行動をとる可能性が高くなります。
• 他のシステムまたはIRMとの統合を検討している場合、重大度に関する特定の概念があると、統合が複雑になる可能性があります。

（少なくともアラート定義については、アラート定義を複製し、変更し、重大度でラベル付け/タグ付けする方法があるかもしれません

これは、クリティカル/警告の差別化のための完全に許容できる回避策です。 個別のしきい値を維持できることを嬉しく思います。 警告/クリティカルのしきい値を組み合わせておくと便利ですが、大したことではありません。

次に、それらをどのようにグループ化するかが問題になります（多くのアラートが発生する可能性があるため）

自分のチケットボリュームとアラーム生成を管理するのはユーザー次第です。 アラームを設定する場合は、それぞれを個別の電子メールまたは通知にする必要があります。 このように考えると、たとえば、トリガーされたアラームに基づいてチケットを生成する自動システムを作成する場合、複数のアラームを1つの電子メールにグループ化すると、これが困難になるか、単に不快になります。 さらに、複数のアラームが1つの電子メールに表示されるということは、各アラームが独自の電子メールスレッドを持つことができないことを意味します。ユーザーが手動で分離し、新しいスレッドを開始する必要があります。 代わりに、スレッドをその特定のアラームに含めることができるように、各アラームトリガーには独自の通知が必要です。

うまくいけば、グループ化について心配する必要がないので、これにより警告の設計が単純化されます。 それはユーザーが処理する必要があります。