Grafana: grafanaのアラートシステムの構築

私はこれを手伝いたいです！ 私の提案は、nagiosスタイルのガイドラインに従うことです。 そうすれば、ツールを他の監視ツールと簡単に使用できます。 例：Nagios、Zenoss、Icingaなど。

この機能の最大の利点は、基本的なアーキテクチャを正しくすることです。

私が探求したいいくつかの質問
1）どのコンポーネントがどのように実行される必要があるか（grafanaのprocで、procから）、
2）物事をどのように調整する必要があります。
3）「インストリーム」アラートを無視する必要があります（プルベースのみに焦点を当てます）

1）にさらに深く入ります
grafana-serverをモノリスにするのが心配です。 grafanaサーバーを互いにより分離されたサービスに分離する方法を見つけたい（そして、inprocまたは個別のプロセスとして実行できる）。 これは、バスの抽象化を伴う一種の計画でした。 もう1つのオプションは、アラートコンポーネントがHTTP apiを介してgrafanaとのみ通信するようにすることです。統合が制限される可能性がありますが、確かではありません。

私はtorkeloに同意します。 すべてが「組み込まれている」他のプロジェクトでの私の経験では、トラブルシューティングが非常に面倒になる可能性があります。 サービスを外部で実行するというアイデアは気に入っていますが、すべてのアラートの管理を処理するためにHTTPAPIを介してサービスと通信するgrafanaの優れた構成ページです。 また、大規模な展開の場合、パフォーマンスが最終的に低下するため、これが要件になる可能性があります（少なくとも構成オプションとしてこれを使用します）。

現在のグラファナグラフのしきい値設定（現在はviz専用であり、処理用ではありません）と統合しますか？ 式がしきい値チェックの場合、しきい値行を自動的に表示できます

そこから始めるのが良いと思います。 セットされている場合はアラートを出し、そうでない場合はアラートを出しません。

1番に戻ります。bosunサービスを個別に実行できても、グラファナを介してすべてを完全に構成できる場合は、私の意見では理想的だと思います。

素晴らしい仕事を続けてください。

bosunで私が見た唯一の欠点は、使用できるデータソースです。 bosunアラートを表現するための言語を活用できるだけでなく、通常のgrafana UIを介して構成された既存のデータソースと統合できれば、それは確かに理想的です。

アラートのしきい値に近づいたときにそれを表すことができ、それらが私の心の中でトリガーされたときに注釈を自動的にプッシュできるので、理想的な単一ペインのUIになります。

ここで行われる作業を楽しみにしています！

1. ダッシュボードで定義されたしきい値を使用してアラートを送信する必要があります
   シンプルにしましょう。 ダッシュボードに警告の色が表示されている場合は、警告しているはずです。
2. これは、grafana-serverプロセス自体の外部にある可能性があります。
   ...残りのAPIを使用してダッシュボードとその設定をスクレイピングし、それらをレンダリングして外部コマンドを使用してアラートを出すもの。
3. アラートレベル; このダッシュボードを監視する必要があるエディターにドロップするボックスだけです。 毎分チェックする必要があります。 データがない場合でも、一定期間はアラートを出す必要がありますか？ （チェックボックス）

最後に、 私たちはGrafanaにもっと依存しているので、私は2と言いたいと思っていることを認めます。

なぜこれをGrafanaに含めるべきだと人々が考えるのか興味がありますか？
Grafanaはその実際のデータを受信も保存もしませんが、それを「視覚化するだけ」です。 代わりに、アラートシステムはメトリックストアのデータに基づいている必要があります。
これが本当にGrafanaに統合されている場合は、これを無効にできることを願っています。ここではすでにIcingaをアラートに使用しているため、Grafanaでのアラートは、まったく使用されていなくてもGUIが煩雑になるだけです。

絶対に正しい@dennisjac; Grafanaは物事をレンダリングするだけです。

しかし、サーバー側に移動したため、クライアントのレンダリングだけではなくなりました。 メトリックをチェックしてアラートを出すことができるワーカープロセスの可能性。 それほど難しくありません。

データはデータベースにあります。 メトリックをチェックするように指示するデータが散在している場合...

一部の人々は、私たちが小川を渡って、Grafanaにそれを（大まかに）視覚化する以上のことをさせるべきではないことに同意または反対するかもしれませんが、私は彼らではありません。

私はそれを統合したい人々のための機能に本当に反対していませんが、すでに監視/アラートシステムが利用可能になっている人々のためにそれがオプションになることを願っています。

新しいTelegrafプロジェクト（influxdbの人たちのメトリックコレクター）も、同じ理由で嫌いな監視/アラート機能を検討しています。 私はここでこれについて詳しく説明しました：
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

torkeloは、Grafana2で有効にする必要のない機能を提供する上で、非常に優れた仕事をしてくれたと思います。

influxdbに関しては、どういうわけかお金を稼ぐ必要があります。 influxdbおよびそのための専門的なサービスまたは製品のサポートから。

後者ははるかに実行可能に聞こえます

これに関する別の角度。 grafanaのメトリックストレージとしてelasticsearchがサポートされる予定です。 Bosunは現在、elasticsearchにログデータをクエリできます。

ログデータからのアラートも許可するようにアラートシステムを設計する場合、それは理にかなっていますか？ 最初のバージョンの機能ではないかもしれませんが、後で実装できるものです。

また、プロセスを分割するという考えにも同意します。 Grafanaにアラートを表示および作成するためのインターフェースを用意し、他の何かにアラートを処理させます。 アラート部分をAPIベースにすると、他のツールもそれとインターフェースできるようになります。

アラートに+1。 DevOpsの使用以外では、エンドユーザー向けに構築されたアプリケーションはユーザー定義のアラートを提供する必要があります。 視覚化ツールに入れてよかった...

+1これはループを閉じます-メトリックを取得する提案。

+1 Grafanaからのアラート+ InfluxDBからの水平スケーリングバックエンドは、メトリックアラート構成の標準になります

+1複数のグラファナノードでアラートを水平方向にスケーリングしたいのですが。

「デバウンス」のような動作をアラートに関連付けることができれば素晴らしいと思います。 たとえば、定義されたしきい値がN分間Xを超えた場合にのみアラートを発生させたいとします。

私はいくつかのアラートツールでこれを見てきましたが、残念ながら現在、そのようなオプションを提供していないように見えるSeyrenを使用しています。 ダッシュボードの開発にGrafanaを使用しており、アラートをGrafanaに取り込むことも楽しみにしています。 良い仕事を続けてください。

2つのユースケースがあります。

• インフラストラクチャチームは、通常どおりプロビジョニングツールを介して共通の監視スタックにアラートを作成します（共通のクラスターチェックまたはnagiosフレンドリーシステムのシステムチェック）
• ソフトウェア開発者は、Grafanaを介してアプリの指標を作成します

アラート、フラップ検出、エスカレーション、連絡先を処理する統合アラートシステムが必要です。 これは、同じ真実の情報源でイベント/操作を記録および相互に関連付けるのに役立ちます。 多くのシステムがアラートの問題を解決しました。 Grafanaがこれを長期的に改善できることを願っています。短期的には、既存のシステムを再発明しないことが、成果物の観点から役立つでしょう。

1つの提案は、Grafanaがモニタリング定義（アラート状態）を抽出するためのAPIを提供できること、サードパーティが構成エクスポートプラグインを提供できることです。 これは、nagios構成をエクスポートするユースケースでは非常に理想的です。

さらに重要なのは、統合された異常検出ソリューションも見たいです！

2015年7月15日には、午後05時40分で、Pierigル・Sauxのの[email protected]は書きました：

+1複数のグラファナノードでアラートを水平方向にスケーリングしたいのですが。

—
このメールに直接返信するか、GitHubで表示してください。

@activarsに同意します。 ダッシュボードソリューションがアラートを処理する必要がある理由はよくわかりません。アラートは、他の多くのツールによって多かれ少なかれ解決された問題であり、ほとんどが非常に成熟しています。 一つのことをして、それをうまくやりなさい。

私見では、_統合_の部分に焦点を当てる方が理にかなっています。

例：グラファナで動的な警告/クリティカルのしきい値を定義し（たとえば、上記の@Dieterbeの例のように）、このグラフの状態（normal、warn、crit）を正確に返すAPI（REST？）を提供します。 nagios、icinga、bosunなどは、すべての「監視」対応グラフ（別のAPI機能）を要求し、個々の状態を反復処理して、必要なアラートを実行できます。

私たちの場合、サービスカタログと定義されたアクションは難しい部分です-どのサービスがビジネスクリティカルであるか、どこにメールを送信するか、フラッピングなどです。また、ほとんどの企業がすでに持っているgrafanaのユーザー/グループ管理について心配する必要はありません中央の場所（AD、LDAP、Crowdなど）およびアラートシステムと統合されています。

また、ダッシュボードソリューションとは異なり、アラートツールの品質要件は、信頼性、復元力、安定性などの点ではるかに高いと見なすことができるため、過小評価してはならない（テスト）作業が発生することも考慮する必要があります。

また、Webサービスの呼び出し、マシンへのping、カスタムスクリプトの実行など、時系列に関連しないチェックについてはどうでしょうか... grafanaでもそれが必要ですか？ ボースンの採用はこれらすべてを提供すると思いますが、私はそれについてあまりよく知りません。

一方、単純なアラートシステムが、適切な代替手段がない多くのユーザーを満足させる方法を想像することはできますが、これは、他のアラートツールの統合パターンの例で解決できる可能性があります。

Grafanaにすべての問題を解決してもらいたいのと同じくらい、falkenbtはこれで頭に釘を打ったと思います。

上記のデータを公開するためのAPI、bosunでの配管、および一般的なアラートプラットフォームとの統合パターンは非常に理にかなっています。

raintank @Dieterbeでの新しい仕事おめでとうございます！ 私はしばらくの間あなたのブログを読んでいます、そしてあなたはモニタリングに関して、特にメトリクスとアラートにおけるその位置に関して、いくつかの本当に健全なアイデアを持っています。 grafanaでアラートを実装する良い方法が見つかると確信しています。

おそらく同意するでしょうが、Bosunの背後にいる人々はほとんど正しい方法で警告を行っています。 Bosunに欠けているのは、実際には視覚化です。 GrafanaUIの背後にあるBosunを見たいです。 Grafanasダッシュボードと同じインターフェースの背後にあるbosunsアラートを組み合わせると、すばらしい完全な監視ソリューションになります。

また、オープンソースの監視コミュニティをさらに細分化するのは残念だと思います。監視に関するあなたのアイデアは、Bosunの背後にいる人々のアイデアと本当に互換性があるようです。 あなたが団結するならば、私は結果が素晴らしいだろうと確信しています。

私が働いている場所では、ログ/イベントにElasticを使用しており、メトリックにInfluxDBを使用し始めたところです。 私たちは監視のためのさまざまなソリューションを模索してきましたが、現在はBosunに傾倒しています。 ダッシュボードにはすでにGrafanaを使用していますが、同じインターフェースを介してすべての監視情報にアクセスしたいので、Grafanaがそのインターフェースになることができれば素晴らしいと思います。

素晴らしい仕事を続けてください、そして頑張ってください！

関連する接線では、grafanaをriemannと統合することで、アラート部分が機能するようになりました。 grafanaの内部を知るための素晴らしい演習でした:)。

設定は単なるclojureコードであるため、これはriemannの方が簡単でした。 この統合はBosunではより困難になると思います。

これが実際のスクリーンショットです。

grafana部分への変更には、「/ alerts」と「/ subscriptions」エンドポイントの追加が含まれ、リーマンがクラッドを実行するために上部にある別の小さなAPIと通信するようになりました。

良い点は、アラート定義の変更が、SIGHUPをriemannに送信しなくてもすぐに反映されるという事実です。 したがって、状態変更の有効化/無効化、期間の調整は、UIで変更するだけで、その変更がriemannに伝播されます。

この統合のベンチマークはまだ行われていませんが、それほど悪くなることはないと思います。 コードをクリーンアップした後、公開されたらブログに投稿します。

私たちがこれを行った理由は、人々が非常に馴染みのあるUIからこれらのアラートと通知を設定するだけで、riemannconfigsを作成する必要がないためです:)。

@sudharshあなたの実装は本当に面白いです

たくさんの良いアイデア、みんなに感謝します。
コメントの一部と@pabloaのhttps://github.com/pabloa/grafana-alertsプロジェクトに触発されて、同じワークフローの一部としてアラートルールを構成および管理するためのUIとUXに何よりも焦点を当てることにしました。ダッシュボードとパネルの編集。 Grafanaはこれらのルールをどこかに保存し、他のスクリプトやツールがアラートルールをフェッチできるように簡単にアクセスできるようにします。
おそらく、ファイル、API呼び出し、ダッシュボード構成のセクション、またはデータベースのエントリを介して。
（私はそれをダッシュ​​ボード定義自体の一部として持つというアイデアが好きです。そうすれば、オープンソースプロジェクトには、デフォルトで必ずしもアクティブである必要はありませんが、アラートルールが含まれるgrafanaダッシュボードjsonファイルを含めることができます。データベースはより堅牢に見える）
いずれにせよ、アラートルールを実際に実行してイベントを処理する、使用する他のシステムの構成を生成できるように、簡単にアクセスできるようにします。 （これ以降、これを「ハンドラー」と呼びます）。
このようなハンドラーは、nagios、sensu、bosun、作成するツール、またはbosunに裏打ちされた素晴らしくシンプルな統合を提供するgrafanaにコンパイルできるハンドラーであるlitmusアラートスケジューラーエグゼキューターである可能性がありますが、私たちは本当に必要なシステムを使用できることを確認してください。

ハンドラーが使用するデータストアのクエリをサポートしている限り。 単純な静的しきい値から始めますが、後で、削減関数、複数の条件間のブール式などを簡単に選択できるようにします。

@sudharshそれは非常に素晴らしいアプローチです。 上記の中間ステップをバイパスして、ソリューションがリモートAPIと直接通信する方法が気に入っています（もちろん、これは、回避しようとしている特定の1つのバックエンドでのみ機能することを意味します）。また、構成を自動的に再読み込みできます。 （そうです、bosunは現在それをサポートしていません、将来的にはサポートするかもしれません。FWIWlitmusハンドラーはこれをうまく処理し、bosunの式評価メカニズムを使用します）。 私は本当にリーマンにあまり入りませんでした。 ほとんどの場合、スタックにこのような異なる言語を追加することを懸念していたため、問題が発生したときに理解したりデバッグしたりできる人は多くありません。 しかし、私はあなたのシステムとリーマンのCLJコードについてもっと知りたいと思っています。 （私の疑いが間違っていれば私はそれが大好きです）

@dennisjacはい、それはオプションです。
@elvarbデータソースとしてESのチケットがあり
@rsetzer ：同意し
@falkenbt ：多くのことが時
@ activars ＆ @ falkenbtこれはあなたの期待に一致しているように見えますか、それとも具体的に何を改善できると思いますか？
@jemilssonありがとうございます！ そして、それはまさに私がそれを見る方法です：bosunは警告するのは得意ですが、視覚化は得意ではありません。 Grafanaは視覚化とUXに優れていますが、アラートはありません。 時間の経過とともに成長するコラボレーションを推進しようとしています

電子メールのような通知でどのようなコンテキストを出荷するかについて誰かが考えていますか？
少なくとも、通知には警告しているデータのvizが含まれている必要がありますが、他の関連するグラフを含めることは不可能である必要があります。 ここでは、通知コンテンツを生成するときにgrafanaのpngレンダリングバックエンドを使用できます。 grafanaのスナップショット機能を活用することも考えています。 アラートがトリガーされたときのように、コンテキストの特定のダッシュボードのスナップショットを撮ります。
そのスナップショット（htmlページ）が電子メールに含まれている可能性があります。または、データ/複雑さが少し多すぎる可能性があります。 また、JavaScript機能はメールクライアントでは使用できません（したがって、電子メールのグラフを拡大することはできません）。 おそらく、電子メールからホストされたダッシュボードのスナップショットにリンクすることができます。

Dockerの一般的なアプローチが好きです-バッテリーは含まれていますが、取り外し可能です。 したがって、交換可能な基本的なアラートの実装は、私見の良いアプローチです。

influxdbはアラート用にサポートされますか？ またはグラファイトのみ？

私が見たいのは、階層的なアラートツリーのアイデアです。 監視されているファセットが多すぎて、スタンドアロンのアラート状態には管理できないカーディナリティがあります。 階層ツリーを使用して、高レベルにロールアップする中レベルのアラートにロールアップするこれらすべての低レベルのアラートを定義できます......

そのため、ロールアップされた各アラートは、その下にあるすべての子の重大度が高いと自動的に想定します。 このようにして、分析の表面積を大幅に減らして、システムの状態を正確に把握[および管理]することができます。

これは私が少し前に書いた古い文書から借りた例です。 はい、「Struts」という言葉を使って笑ってください。 それは古いですよね？ これは、1つのサーバーの非常に単純な階層を示しています。

ある時点で、サーバーで75％のCPU使用率が持続するため、これらのアラートが警告状態になります：CPU-＃-> CPU-> Host / OS-> System

実際に自分自身を適用した場合、1つのインジケーターでデータセンター全体を監視できます。 （ええ、そうではありませんが、これは思考の練習として役立ちます）

なぜグラファイトビーコンを使わないのですか？ 非常に軽いグラファイトビーコンとグラファナを組み合わせることができると思います。

@felixbarny私はその用語が好きです。 私たちはおそらくその言葉遣いを採用するでしょう。
@JulienChampseixはい、標準ハンドラーはinfluxdbをサポートします/サポートします
面白い@nickman 。 それは実際には、よりきめ細かいアラートルールと情報を含む/依存することができる非常に高レベルのアラートを作成できるという私たちが念頭に置いている最終目標と一致しています。 bosunはすでにこれを行っており、長期的には、よりユーザーフレンドリーなインターフェースを通じてこの機能を利用できるようにしたいのですが、これよりも単純なものから始めなければなりません。
@amirhosseinrajabiはクールなプロジェクトのように見えます。グラファイトビーコンを、grafanaUIを介して構成されたアラートのハンドラーにすることは非常に理にかなっていると思います。

@Dieterbe現在のステータスを更新することは可能ですか？ 警報システム用
どのシステムが互換性があるかを知るために（graphite / influxdb）？
どのサブスクリプションが利用可能ですか？ どのアラートタイプが利用可能ですか？
更新していただきありがとうございます。

現在、UX / UIのプロトタイピングを行っています。 ですから、これが使えるようになるにはかなりの道のりがあります。

こんにちは@Dieterbe

アラートシステムの進捗状況に関する最新情報はありますか？

Grafanaでアラートを受け取るのは素晴らしいことです！ この機能を楽しみにしています。 今更新はありますか？

@mattttt UXの仕事に関するアップデートを提供できますか？

そのとおり。 明日、いくつかの画面/ユーザーフローをアップロードします。

アラートが必要です：ルール定義用のUI、ルール定義用のAPI、アラート通知用のAPI。 このスレッドを興味深く見ていきます。 マルチテナントシステムがあり、GrafanaUIとバックエンドが大好きです。

はい、私もこの新機能を見ることに非常に興味があり、焦ります！
マット、どうもありがとう！ ;）

2015年8月27日午前6時49分GMT + 02：00 andyl [email protected] ：

警告が必要です：ルール定義用のUI、ルール定義用のAPI、およびAPI
アラート通知用。 このスレッドを興味深く見ていきます。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-135290295 。

内部にはたくさんのアイテムがありますが、私はこのスレッドを無視したくありませんでした。

これは私が取り組んできたパネルのモックアップの1つです。 これは、ステータスをツールチップに組み込み、パネル構成で定義された既存のしきい値を使用してアラートを構成する、時間の経過に伴う履歴の状態を示しています。

この例では、これは複数のシリーズを含む単一のクエリでアラートを出します。 ツールチップが拡張され、ホバー時のステータスが表示されます。

_いくつかの小さな未解決の質問_：アラート通知に関する情報があれば、ツールチップにどのくらい入力する必要がありますか？または、この情報は、より詳細なビューで他の場所にアクセスする必要がありますか？ 現時点では後者だと思いますが、声に出して聞いてみる価値はあります。

構成、警告画面、ユーザーフローはゆっくりと進んでいます。 来ることがたくさん。

@matttttいいね！

チャートの下の緑と赤の線が大好きです！

それは稼働時間の計算と関係があり、どこかでそれを数値として見ることができることを望んでいます。 すべてのクエリと各メトリックの合計。

ツールチップについて、線にカーソルを合わせると表示される統計について話しているのですか？

くそー@matttttそれは

それが終わったらこれを見るのが待ちきれません！

これが順調に進んでいるのを見て興奮しています！

現在、監視およびアラートスタックとしてGrafana + Bosun + OpenTSDBを使用しています。 ボースンのパワーとGrafanaの優れたUXがあれば素晴らしいと思います。

Grafanaの構成UXがBosunの構成UXよりも優れている例を次に示します。

環境

監視スタックは、複数のチームとそのサービス間で共有されます。 プロジェクトの仕様に基づいて、さまざまなサービスのセットがさまざまなクラスター/サイトに展開されます。 各チーム/サービスは、独自のダッシュボード/アラートに責任を持つ必要があります。

比較

GrafanaのHTTPAPIを使用すると、チームはサービスをデプロイするときに独自のダッシュボードを配置できます。 Bosunには現在、構成を保存するためのファイルが1つしかありません。 これにより、異なるチーム間や異なるプロジェクト間で共有することが困難になります。

@mattttt @torkelo @Dieterbeアラートピース（またはベータリリース）のリリースについて何かアイデアはありますか？

エコー^。 彼らのベータ版またはアルファ版のリリースですか？ アラートソリューションを研究していますが、グラファナに何かを組み込みたいと思っています。 多くのテストフィードバックを提供できました。

アラート機能はまだ数か月先です。UIのプロトタイプを作成し、さまざまな実装方法を検討していますが、今後2か月で進捗状況がより迅速に進むため、詳細を確認できます。

@mattttt履歴ヘルスバーの色を構成可能にするつもりですか？ 緑と赤は色覚異常とはあまり合いません;）

警告について：私はこれがどのように機能するかに非常に興味があります。 私たちはしばらくの間データを収集して視覚化してきましたが、アラートは現在私たちが理解しようとしているものです。 Grafanaは、特に視覚化がすでに行われているため、そこに良い場所がある可能性があります。 しかし、私が疑問に思うのは、Grafanaがアラートのメトリックシリーズではなく、「エンティティ」をどの程度認識すべきかということです。 メトリックベースのアラートに加えて、視覚的な状態の変化を自動的に切り替えたり（pingまたはhttpチェックが失敗した）、手動で（メンテナンスを行ったり）、サーバーになることを想像できます。

Grafanaのアラートがどこに行くのか興味がありますが、今何かが必要な人のために、https：//exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/detailsのようなnagiosプラグインがあります。しきい値を超えたときにアラートをトリガーできます。

@baaym

しかし、私が疑問に思うのは、Grafanaがアラートのメトリックシリーズではなく、「エンティティ」をどの程度認識すべきかということです。 メトリックベースのアラートに加えて、視覚的な状態の変化を自動的に切り替えたり（pingまたはhttpチェックが失敗した）、手動で（メンテナンスを行ったり）、サーバーになることを想像できます。

これは良い質問であり、私たちが少し話してきたことでもあります。
短期的（そしておそらく長期的）に使用したい解決策は、grafanaにそのようなより高いレベルの概念を認識させないことです。 つまり、ユーザーとしてメトリックシリーズにアラートを設定する権限があり、それらのアラートルールから、アラート結果が生成され（シリーズ名の属性またはタグを含む可能性があります）、そこから任意のエンティティを構築できます。 これはもう少し考えなければならないことですが、例えば

movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warnの線に沿ってアラートを設定したとします。 これにより、特定のクラスター内のすべてのWebサーバーのしきい値が確認され、 movingAverage(cluster1.web-123.cpu.idle,10) is currently 3!などの違反に対するアラートが生成されます。
「最初のフィールドはクラスター名、2番目のフィールドはホスト名」などと言うことができるので、アラートにさらに適切な情報を含めることができます。
ただし、重要なのは、アラート_outcome_には、問題が発生しているエンティティを特定するために必要な情報が含まれていますが、それはgrafanaの範囲外です。 Grafanaはアラートルールの構成のソースであり、Grafanaダッシュボードは、アノテーションとアラートの状態を視覚化するために何を持っているかをロードするように構成できますが、ホストやクラスター。 これはアラートハンドラーで処理できるものだと思います

@Dieterbe

アラート機能を構築する際のユーザー/組織の懸念には、次の2つのタイプがあります。

• スタートアップのように、一般的に独自のアラートソリューションを構築する時間がありません。 すべてがGrafanaに依存してメトリックを警告します
• 確立されたエンジニアリング組織であり、既存のアラートツールが社内に構築されており、ビジネスルールのアラートは他の詳細なアラート信号に基づいて構築されています（Grafanaはその1つです）。

Grafanaは、既存の確立された運用慣行と連携する必要があります。サイクル外に置くことは、アラートの目標を無視します。つまり、ビジネスクリティカルなエンティティの健全性を明確に把握します。 アラートは、環境の明確な状態を構築できるようにセントレール化することをお勧めします。 grafana API（またはその他のソリューション）を使用するパワーユーザーがアラートルールを他のシステムにエクスポートできるようにすることが重要です。

運用可能と言う場合、各アラートには、アラートの目的と過去の動作を説明するためのドキュメント/リンクフィールドをオプションで含める必要があります。

@activars私はそのすべてに同意すると思います。 私の見解では、私たちは、グラファナを残りの環境にプラグインすることを促進するアプローチを取っています（主に、プラグ可能なハンドラーを使用した関心の分離のおかげです）。 提案されたデザインは何らかの形で改善できると思いますか？

@ deebs031は、「エンドユーザー向けに構築されたアプリケーションはユーザー定義のアラートを提供する必要がある」というあまり取り上げられていない良い点を示していると思います。
私見では、聖杯はセルフサービスのメトリクスベースのモニタリングです。私の場合、Grafanaはメトリクスを見たい人のためのメインのフロントエンドであり、同じUI内で自分自身のアラートを作成できるようにするのが理にかなっています。
私は個人的にメトリックに基づいてSensuアラートを実行しましたが、セルフサービスとして提供することは、Grafanaと統合した場合のシームレスさに比べれば、実際には簡単なことではありません。 キャボットも視覚化機能があるので見てみましたが、セルフサービスを念頭に置いて構築されていないため、そのままでは使用できませんでした。
私は「1つのことをうまくやる」側にいますが、メトリクスに基づくセルフサービスアラートの特定のケースでは、その機能をメトリクス視覚化レイヤーと組み合わせることは非常に理にかなっていると思います。

• ユーザーはすでにUIに精通しています
• ユーザーは認証されているため、自分自身または認証で有効なアクセス許可スキーマのアラートを作成できます。
• ユーザーは、これらのメトリックベースのアラートを作成するときに通常非常に役立つグラフを見ることができます

警告に関する私のグラファナコンプレゼンテーションのスライド：
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
コンテキストがないと理解するのはちょっと難しいです。ビデオは約1週間でオンラインになるはずです。準備ができたら、投稿します。

アラートモデル/ UI /定義などを実装する方法のプロトタイピングを開始しました。 メインワークフローについてはかなり良いアイデアがありますが、まだ理解しようとしている1つの大きなポイントは、サードパーティのアラートハンドラーとの統合がどのように見えるかです。
現在の考え方では、grafanaを使用して、しきい値の設定/アラートルールの設定/通知の定義を行い、アラートルールの履歴と現在の状態を視覚化できるようになります。

選択したアラートソフトウェア（bosun / cabot / sensu / nagios / ...）を使用することを前提としています。
そのため、http APIを介してgrafanaにクエリを実行し、すべてのアラートルールを取得する別のツールがあります。 そのツールは、bosun / cabot / sensu / nagios / ...構成を更新できるため、選択したアラートソフトウェアを使用して、アラートを実行および実行し、通知を送信できます。
ただし、現在および過去の状態を適切に視覚化できるようにする必要があるため、アラートプログラムは、スクリプトまたはWebhookなどを呼び出して、新しい状態をgrafanaに通知できる必要があります。そうでない場合は、grafanaがクエリを実行する必要があります。 （ほとんどのツールが優れたAPIを備えていないように思われることを考えると、これは厄介なようです）
これはすべて少し複雑ですが、アラートルールの定義と状態の視覚化にgrafanaを使用しながら、選択したアラートソフトウェアを引き続き使用できることが重要な人々をサポートするには、この方法である必要があります。

現在選択しているアラートツールを使用できることはあなたにとって重要ですか？

私たちがやりたいもう1つのことは、簡単なアラートエグゼキュータを自分で作成することです。これは、grafana apiにアラートを照会し、それらをスケジュールして実行し、通知を実行します（電子メール、Slack、Pagerduty、カスタムスクリプト、およびおそらく他のいくつか）そして再びgrafanaの状態を更新します。
私たちにとってはかなり簡単に書くことができ、あなたにとっても使いやすく、優れた相互運用性を持つことができます。

組み込みのアラート実行機能（上記を参照）は、grafanaで設定したすべてのアラートルールを処理するのに十分だと思いますか？

また、複数のアラートハンドラーを使用できるようにしますか？ どれの ？

@jaimegago amen;）

私にとっては、すべてがスムーズに機能するために構成する必要のあるものの数を実際に最小限に抑えることができるという点で、2番目の方が優れているように思われます。 私たちの現在のセットアップでは、それを使用します。

他のみんなが同意しない場合はそう言われています;）

クイック編集：素晴らしいスライド。 最終製品がその半分の見栄えで出てきたら、それは驚くべきことです。

+1
この統合による内部通知ハンドラーが完璧であることに同意します。 最も一般的なユースケース。

ベータテストに参加できてうれしいです:)そしてスライドは素晴らしいです！

@Dieterbeの最後の投稿でかなり

Grafanaでのアラートは、実際には2つのものです。セルフサービスのアラート設定（ @jaimegagoに感謝します。自分でそれを上手く言うことはできませんでした）とハンドラー自体です。

Grafanaアラートハンドラーを出荷しますが、選択したアラートソフトウェアと統合するためのフレームワークも提供します。

他のアラートシステムへの一種のブリッジを構築するための+1（多分私たちはいくつかの一般的なアラートプラグインシステムの実装を考えることができます:-)）

「外部アラートハンドラ」の部分にもPrometheus追加できます。 Prometheus alertmanagerの最初のバージョンはいくつかの会社で生産されており、完全な書き直しが現在進行中です。 SoundCloudはGrafanaを使用してアラートを構成する場合がありますが、Prometheusalertmanagerがアラートハンドラーとして使用されている場合に限ります。

@grobie 、良いキャッチ、元のコメントで修正。

@mattttt @Dieterbeそれは素晴らしいです！ あなたは「バッテリーは含まれているが取り外し可能」の道を進んでいるように見えます。これは私見の両方の長所です。 承認データをアラートハンドラーに渡す方法についてすでに考えましたか？ 私はこのような話を考えています：
Grafanaユーザーとして、（GrafanaアラートUIを介して構築された何らかの条件）が発生したときに、_email_および/または_pagerduty_および/または_foo_を介してアラートを受け取りたいと思います。
そのユーザーは、許可された通知システムにのみアラートを送信できる必要があります。これはセルフサービスの要件であり、何らかの方法で対処する必要があります。 Grafana 2以降、SQLバックエンドとLDAP統合を使用したユーザー認証/承認があるため、アラートの初日からその機能を利用するにはそれほど遠くないように思われますか？
Sensu（これは私がプラグインするツールです）を使用すると、ハンドラーを介してアラートターゲット（電子メールアドレスなど）を渡すことは非常に簡単であるはずであり、他のことについては言えません。

こんにちは、みんな、
セルフサービスのアラート構成アプローチが大好きなので、この余裕が進んでいることを嬉しく思います。

個人的には、特定のアラートハンドラーは必要ありません。 アラートがスローされるとすぐにトリガーされる、汎用のHTTPPOSTハンドラーが必要です。 ほとんどの管理者は、HTTPを受け入れて、それを使って必要なことを何でも実行できるものをすばやく構築できると思います（nagios、riemann、younameitに送信します）。 したがって、アラートに関するすべての情報をJSONデータとして送信するHTTPハンドラーに満足しています。

grafanaを介したアラートについて話しますが、フラッピング検出のようなものを追加する予定ですか？ それとも、これは外部監視システムが処理する必要があるものですか？

良い仕事を続けてください！

乾杯

アラートがスローされるとすぐにトリガーされる、汎用のHTTPPOSTハンドラーが必要です。 ほとんどの管理者は、HTTPを受け入れて、それを使って必要なことを何でも実行できるものをすばやく構築できると思います（nagios、riemann、younameitに送信します）

したがって、アラートが発生し（「web123のクリティカルCPUがアイドル状態です！、値1がしきい値15よりも低い」など）、そのデータのhttp投稿を行う場合、nagiosでそれをどのように処理しますか？ nagiosがそれをパッシブサービスチェックとして取り込み、nagiosが通知を送信するということですか？

grafanaを介したアラートについて話しますが、フラッピング検出のようなものを追加する予定ですか？ それとも、これは外部監視システムが処理する必要があるものですか？

これも私たちがもっと考える必要があることです。 これは厄介になる可能性があり、pagerdutyやflapjackのようなものを使用する場合は、それを使用してイベントを集約したり、重複を抑制したりできるため、必要な場合もありますが、それをgrafanaハンドラーに実装することを回避できるかどうかを検討しています。 また、任意のメトリッククエリ式にアラートを設定できるため、実際の式で過去のデータを考慮に入れることができるため、式でより堅牢なシグナルを作成できることにも注意してください。状態はそれほど頻繁には変化しません。

したがって、アラートが発生し（「web123のクリティカルCPUがアイドル状態です！、値1がしきい値15よりも低い」など）、そのデータの> http投稿を行う場合、nagiosでそれをどのように処理しますか？ nagiosがそれをパッシブサービスチェックとして取り込み、nagiosが通知を送信するということですか？

すこし。 私は実際に、nagiosを取り除くように警告するgrafanaを楽しみにしています。 HTTPハンドラーを使用して、nagiosのパッシブチェックを構成して、そこに結果を送信できるようにする必要があります。 ただし、アラートを構成できる1つのソースとしてgrafanaが必要です。 私たちの場合、アラートの追加を許可されているのは、nagiosでチェックを構成する実際のシステム管理者です。

httpハンドラーを使用すると、grafanaには、リアルタイムモニタリング用のダッシュボード、API、簡単なアラート構成、アラートを内部通知システムに転送できるhttpハンドラーなど、必要なものがすべて揃っています。

乾杯

この統合戦略の論理はわかりますが、少しやり過ぎだと思わざるを得ません。 私が理解していること（そしてスレッドで読むことができること）に対して、ほとんどのGrafanaユーザーがスタンドアロンのアラートテクノロジーを使い続ける唯一の理由は、Grafanaがそれを提案していないということです。 したがって、最初にGrafana Alerting部分に焦点を合わせ、APIを介してスタックの残りの部分と通信するコンポーネントとして開発し、他の寄稿者が動作を模倣して作成できるようにすることは、より「無駄のない」ことではありません。後で特定のアダプター？

tl; dr：最初に独自の「バッテリー」を構築することに焦点を当てることで、Grafanaはフル機能のアラートシステムを備え、後でサードパーティのアラートツールと統合するためのサービスに進化することができます。

これが対処されていない場合、マイナーな懸念。 従来のアラートシステムは、リソースが非常に動的である（プロビジョニングおよび破棄される）ため、クラウドインフラストラクチャに対して適切に拡張できません。 メトリックに関するアラートは、魅力的な機能またはグループ化機能をサポートする必要があります（例外のオーバーライドを除き、ワークロードが異なる場合があります）。 テンプレート化またはグループ化されたアラートは、新しいグループセットを検出できる必要があります。

更新していただきありがとうございます！ 私のユースケースでは、現時点で必要なのはGrafanaに組み込まれているアラートだけです。 Grafanaのアラートを辛抱強く待っていました。

IRCで約束したように、これのユースケースは次のとおりです。

searches our logsに対してpatterns searches our logsレガシーRailsアプリがあります。
特定のpatternがthresholdsを超えた場合に応答するHTTP API
したがって、ステータスは{OK,WARNING,CRITICAL}です。

Thresholdは次のいずれかになります。

• statusのCRITICAL場合patternすべてに存在します。
• patternがX回以上見つかった場合、そのstatusはWARNINGです
  Y回以上見つかった場合、 statusはCRITICALです。
• patternが1時間未満の場合、 statusはOK 。
  3時間未満statusはWARNINGあり、それ以外の場合はstatusは
  CRITICAL 。

この機能を正しく理解していれば、Grafanaはこの使用法をサポートします
この機能と
Elasticsearchデータソースは完全に実装されていますか？

@Dieterbe @matttttスライドとモックアップは絶対に素晴らしいです！ これは本当にゲームチェンジャーです。
私にとって、内部のGrafanaアラートハンドラーは、私たちのニーズに最も適しています。
理由：

• セルフサービス-非常に重要です。 ユーザーは、Grafana内でエンドツーエンドでアラートを作成したいと大声で明確に述べました。
• 統一されたワークフロー-可動部品を増やすのではなく、最小限に抑えたい。 @Dieterbeが指摘したように、サードパーティのアラートハンドラーには少なくとも4つのステップが必要ですが、内部アラートハンドラーには1つしか必要ありません（各しきい値の通知方法を定義する必要がある場合は2つですか？-プレゼンテーションからは
• 緊密な統合とサードパーティのアラートインフラストラクチャへの依存なし。

いくつかの懸念：

• 頻度チェックのしきい値とは何ですか？
• データを取り戻すには速すぎるポーリング頻度をどのように処理しますか？ ログに記録し、警告し、キューに入れますか、それとも削除しますか？
• スケーリングについては、Grafanaが膨大な数のチェック、高速な頻度、特に内部アラートをサポートするためにGrafanaサーバーを追加/スケーリングする必要があるデータソース間の遅延に対応できない可能性があることを懸念しています。 現在、いくつかのサードパーティのアラートハンドラインスタンスが必要なので、これを知っています。 この場合、特にチェックが同じデータソースからのものである場合、Grafanaサーバーのクラスター間でしきい値チェックをシームレスに割り当てたりキューに入れたりするにはどうすればよいでしょうか。 ユーザーエクスペリエンスから、ユーザーが特定のチェックのためにGrafanaの特定の「割り当てられた」インスタンスに移動することなく、負荷分散されたGrafanaサーバーのクラスターを介してシームレスにしきい値を作成することを望んでいます。
• 通知の場合、通知を簡単に開発および統合できるように、これはある種のプラグインアーキテクチャをサポートしますか？ 一般に、HTTPPOSTを実行できるものが必要です。 これは、PagerDuty、xMatters、VictorOps、Opsgenieなどで最も一般的です。それぞれにわずかに異なる形式、認証などが必要です。このスレッドで前述したように、おそらく汎用HTTPPOSTハンドラーが機能してあなたがそれでやりたいことを何でもすることができるカスタムHTTPサービス。 または、カスタムスクリプト機能も機能するはずです。
• APIを介してしきい値を設定、取得、違反を取得できると思いますか？ これは役に立つと思います

アラートを既存のアラートシステムに統合できることが理想的だと思います。 前述のフラップ検出のように、対処されてきたいくつかの困難で醜い問題があり、最初からすべてを再発明することは無駄に思えます。 これがフィーチャークリープの重みで埋もれているのを見たくありません。

しかし、これがこれらすべてのアラートハンドラーに緊密に統合される必要はないと思います。 十分に文書化された優れたAPIにより、これらのシステムに精通している人々がわずかな労力で統合できるようになります。 したがって、「grafana api-> handler」のスライドは、私にとって魅力的に見えるものです。

スコット

みなさん、こんにちは。私はこのディスカッションに遅れて来ていますが、このトピックに関する専門知識があり、アラートの問題を解決しようとしたツールの1つのリード開発者です。 私たちのツールであるStatsAggは、bosunのようなプログラムに匹敵します。 StatsAggは、柔軟なアラート、アラートの一時停止、通知をカバーすることを目的としており、現時点ではかなり成熟していて安定しています（ただし、APIの準備はできていません）。

とにかく、警告の主題に関するいくつかの考え：

• 個々のメトリックによるアラートは最悪です。 私は何千ものサーバーを管理している会社で働いており、「空きディスク容量％」の一連のメトリックごとに個別のアラートを作成/構成/管理する必要があることは、ロジスティック的に実行不可能です。 エンタープライズ監視ツールは、多くの場合、複数のメトリックシリーズを正規表現（または単にワイルドカード式）と結び付けます。 StatsAggは同じ前提で構築されました。 複数のメトリックシリーズが相互に関連付けられている場合、メトリックのグループには、単一の「アラート」によってアラートしきい値チェックが実行されます。 大規模な場合、この種の機能は必要です。
• アラートツールは個々のメトリックからアラートを出すべきではないという私の以前の主張を受け入れる場合、ツールには、適格なメトリックとメトリック値のリストをすばやく取得するメカニズムが必要です。 多くのツールは、メトリックとメトリック値のリストを取得するためにデータストアのクエリに依存しており、このソリューションは率直に言って大規模ではうまく機能しません。 アラートロジックは、その性質上、頻繁に実行する必要があります（X秒ごと、または新しい適格データポイントがロールインするたびに）。 データストア（graphite、opentsdb、influxdbなど）は、「このパターンに準拠するメトリックの現在のリストを表示する」および「これらのYメトリックの最後のX値を表示する」という一定のクエリを処理するように構築されていません。 適切なAPI /クエリ言語がないか、単に負荷を処理できないかのどちらかです。 明確にするために、データストアに10,000,000の使用可能なメトリックシリーズがある場合に、10,000のメトリックシリーズに対してアラートロジックを実行するスケールについて話します。 これはすべての人のユースケースではありませんが、私の会社のユースケースです。
• ストリーム処理を介して問題に取り組むことが、私の最後の箇条書きで提起された問題に対処する唯一の実行可能な方法であることがわかりました。 そのため、StatsAggはデータストアの前に配置するように構築されました。 アラートロジックは、データストアに触れることなくメトリックに対して実行でき、メトリックはデータストアに渡されるだけです。 このアプローチの主な概念は、1）新しく作成されたアラートがアラート評価に古い/アーカイブされたメトリック値を使用できない/使用しない2）ストリーム処理プログラム（ex-StatsAgg）がクラッシュした場合、データポイントがそれを行わないことです。データストアに3）アラート評価に必要なメトリック値がメモリに保存されます。これはサーバーの安定性の問題になる可能性があります。 4）ストリーム処理プログラムは、着信メトリックを分解および再構築できる必要があります（InfluxDBは昨年は簡単にできませんでした...）。 これらのうぬぼれがあっても、このソリューションは私の会社にとって非常にうまく機能し、非常に大規模に機能しました。 時には、200,000以上のライブメトリックシリーズ、平均30k以上の着信メトリック/秒、数千のメトリックシリーズを評価する数百のアラート、およびほとんど汗をかかないStatsAggを実行しているサーバーがあります。 その間、データストアはまったくクエリされません。

これらが私が言及したかった主なことです。 アラートには他にも多くの重要な側面（通知、一時停止など）がありますが、コア問題のアーキテクチャが解決されれば、これらのソリューションを簡単に追加できます。 私たちのニーズの規模は平均的なユーザーと同じではないことは承知していますが、皆さんがこの視点を理解してくれることを願っています。

Alertaにデータを送信できる通知ハンドラーを使用して起動することをお勧めします： //github.com/guardian/alerta

Alertaには、通知を受信するための非常に適切なRESTAPIがあります。

私は無駄のないグラファナのみの実装を好みます！
誰もが典型的な素晴らしいGrafanaUXでこの機能を体験した後、再評価する価値があると思います。

人々が統合したいと思う多くの複雑なケースやカスタムバックエンドシステムがあります。 このスレッドには多くのオープンソースがありますが、商用製品もたくさんあります。 個々のハンドラーを気にしないでください-それはラット全体になり、常にキャッチモードになります

2種類のハンドラーのみを実装することを強くお勧めします。 1つは間違いなくHTTPPOSTであり、最も用途が広く柔軟なツールになります。 もう1つはカスタムスクリプトであるため、ユーザーは選択した特定のツールとの統合を実装できます。 プラグインモデルは悪くありませんが、制限されている特定のプラグイン言語を使用することを余儀なくされます。 外部スクリプトの方が優れています-スクリプトにすべての詳細を渡す限り、スクリプトは任意の言語で記述できます-シェルスクリプト、Pythonなど。

私は@ 007readerと一緒です

同意します。 一般的な統合方法が提供されている限り、カスタム実装は個別のプロジェクトまたは展開にすることができます。

たとえば、最近のCloudWatchリリースはまともですが、選択したメトリクスを代替ストレージに同期するだけで、別のプロジェクトとして作成したいと思います。 2週間のデータではなく、完全に保持されます。

こんにちは、みなさん、
私のgrafanaconプレゼンテーションビデオはオンラインです！
https://www.youtube.com/watch?v=C_H2ew8e5OMにあります
ご覧のとおり、かなりクリアになると思います。 統合の詳細はまだ解明されておらず、多くの人々が話し合いたいトピックでもありました。 （限られた時間で、みんなが参加できるようにここで会話を続けるようにお願いしましたが）

@simmelはい、その通りです。 ESクエリを使用して、それにルールを設定します。
@activarsの再グループ化と検出、その多くはデータソースに依存すると思いますが、以前は見られなかったメトリック/シリーズの「自動検出」が非常に得意なグラファイトやESのようなものを使用する場合は、最も一般的な要件に対処する必要があります/グラファイトまたはクエリ（ESの場合）の指定された式（ワイルドカードを使用）に一致するドキュメント。 他の情報源についてはよくわかりません。 ルールに例外を適用する必要があるというあなたのコメントは難しいものです。おそらくいつかそれに対処する必要がありますが、状況がより明確になり、より落ち着くまで待つことができると思います。 多分私達はそれをどうにかして必要としないようにすることができます。
@mgravlinの頻度がルールの設定になり、遅すぎるデータソースを処理しますが、まだ
@sknolin私が正しく理解していれば、あなたの見解では、nagios / bosunのような別のシステムを使用している場合でも、grafanaはアラートのスケジューリング、実行、通知フックのトリガーなどを行います。 次に、外部システム（nagios / bosun / ...）の役割は正確には何でしょうか。 これも@Crapworksが話していたものと似ているよう
@ jds86930StatsAggは非常に興味深いようです。 ここでも、grafanaとの統合が理にかなっていると思います。 ストリーム処理は、繰り返しクエリを実行する代わりに使用できる有効なアプローチだと思います。 しかし、後者は始めるのが簡単で、一般的には簡単だと思います。 ただし、両方をサポートする必要があります。 したがって、グラファナでは、データのスペクトルに一致するパターン/クエリを設定でき、新しいシリーズ/データがライブになるとそれをカバーできる可能性があります。 しかし、私たちの見解では、データソースが持つ機能（たとえば、グラファイトはワイルドカード、グロブ式など、elasticsearchの豊富なデータとクエリモデルでこれにかなり優れています）を活用するか、誰かがgrafana + StatsAggを使用する場合はStatsAggを使用してそれを解決してください。 grafana自体がここで特定のことを行う必要があると言っていますか？ データソースの速度が十分でない場合は、データソースの問題を解決すると思います。 メトリックメタデータのキャッシュを備えた、より高速なものを取得します。前のメモリサーバーやストリーム処理などです。 しかし、どちらにしても、Grafanaに関する限り、私が考えることができるほどの変化はありませんか？
@blysikはい、

@ 007reader、@shanielh、目標が何であるか、一般的なHTTPポストまたはスクリプトを介したこの統合だけ明確にすること@activars。 外部システムに「新しいルールがあります。これがクエリ、しきい値、頻度などです。実行してください」と伝えますか？ それとも、grafanaはルールを実行してから、外部システムを新しい状態で更新するものでしょうか？

@blysikはい、

正しい。 Alertaは、通知ハブになりつつあります。 それにアラートを送信するあらゆる種類のもの。 例：カスタムスクリプト、Cabot、Zenoss、vCenter、そしておそらくGrafana。 これにより、opsはすべてのアラートを表示するための単一の場所になります。 そして、それがオンコールエンジニアへの通知を促進する唯一の場所です。

@sknolin https://github.com/sknolin正しく理解していれば、
ビュー、grafanaはアラートのスケジューリング、実行、トリガーを行います
のような別のシステムを使用している場合でも、通知フックなど
nagios / bosun。 次に、外部システムの役割は正確には何でしょうか
（nagios / bosun / ...）。 これも@Crapworksと似ているようです
https://github.com/Crapworksが話していました。

私はよく説明しなかったと思います。 それは私が望んでいることではありません、grafanaはそうではありません
そのすべてをやっています。 @Crapworks （入力するのは楽しい）は受動的に話している
サービスチェック、アクティブポーリングを使用します。

したがって、必要なのは、grafanaアラートのステータスを読み取ることができるAPIだけです。
外部システムが他のすべてを行います。

それがどういうわけか偉大な将軍に発展しなかったのかどうかという意味ではありません
警告ツール私はそれを使用しません。 私が今やろうとしていることだけです。

スコット

@sknolin

したがって、必要なのは、grafanaアラートのステータスを読み取ることができるAPIだけです。

そのステータスはgrafanaでどのように更新されますか？ アラートを実行し、grafanaのステータスを更新するプロセスは何ですか？

ポーリングされるたびに、grafanaはアラートステータスを更新し、ポーリングする複数のシステムを処理するための何らかのキャッシュ間隔を設定します。

これには、アラートのロジックを実行して提示するためにgrafanaが必要であるという点がわかります。 ですから、考えてみれば、どんな種類のアラートも必要ありません。

グラフパネルでメトリックの現在の値を取得できれば、必要なアラートを実行できると思います。 たとえば、いくつかのカウンターメトリックの合計からレートを導き出し、それをグラフ化する場合、監視システムを使用して現在の値をポーリングすると便利です。 多分それは今完全に実行可能であり、私はただ鈍感です。

スコット

@Dieterbe後者：

grafanaは、ルールを実行してから、外部システムを新しい状態で更新するものです。

@Dieterbeデータソースのネイティブクエリ構文を使用してデータソース（Graphite、OpenTSDBなど）をポーリングするのが最も簡単で簡単であり、Grafanaにネイティブにアラートを送信する最も簡単な方法であることに同意します。 多くの人にとって、この種のソリューションは彼らのニーズを満たします。これは、最初のGrafana実装に最適なソリューションだと思います（私の意見では）。 私の主なポイントは、アラートの構成可能性とパフォーマンスには上限があり、「データソースのポーリング」モデルではこれを乗り越えるのは難しいということでした。

Grafanaが長期的なアラートソリューションに進む可能性のある方向性に関して、私はいくつかのオプションを見ることができました。

• データストアのメンテナと協力して、アラートのユースケース向けに、より高速で優れた専用APIを構築します。 これらのプロジェクトの多くは遅いペース（数か月から数年）で移動し、拡張要求の一部またはすべてを受け入れない可能性があるため、このオプションは嫌いです。 彼らはおそらく、データストアの母国語でコーディングしたいと思うでしょう。これは必ずしも高速な言語ではありません（PythonのGraphiteなど）。
• 個別のレインタンクプロジェクトとして、各データストアのストリーム処理/キャッシングレイヤーを構築します。 これは、プロジェクトのソリューションを構築するためにさまざまなデータストアのメンテナを説得しようとするよりも、最終的にはより良い結果をもたらすと思います。 これにより、（既存のデータストアクエリメカニズムを使用して）既に実行している作業を拡張し続けることもできます。 独自のカスタムAPIをストリーム処理/キャッシングレイヤーに組み込んで、Grafanaのデータストアへのクエリ構文を簡素化することもできます。
• あなたが取り組んでいるネイティブソリューションに固執し、それをうまく機能させます。 StatsAgg、bosunなどのサードパーティツールは、より要求の厳しい/特殊な/複雑なユースケースに対応します。 Grafanaをこれらのツールと統合することは、ユーザーにとって間違いなく追加のメリットになりますが、Grafanaに重要な複雑さを追加します。 そうは言っても、とにかくこれを行うことになるかもしれないようです（私は今あなたのプレゼンテーションのスライド35の「AlertingBackends」を見ています）。 私はStatsAggにGrafanaに適したAPIのセットを実装することに個人的にオープンです。 APIがどのようになっているのかを理解し、APIプロトコルのドキュメントを作成する必要があります。 それについて話し合いたい場合は、遠慮なく私にメッセージ/メールを送ってください。

こんにちは、みんな、

@Dieterbe私はあなたのプレゼンテーションを見たばかりで、ものは

また、私が何を言おうとしているのかが明確ではないと思うので、私の主張をもう少し明確にしたいと思います。 Nagios、Icinga、Bosunなどの他の監視システムを認識している必要はありません。実際に必要なのは次の場合のみです。

• プレゼンテーションで披露した素晴らしいユーザーインターフェイス、または完全に完成したときの外観
• 完全に構成可能な汎用HTTPPOSTハンドラー（ここで他の人も提案しているように）（後で例を示します）

私が考えているイベントフロー：

• データをgrafanaで視覚化します
• grafanaでアラートのしきい値を追加します
• しきい値を超えるとすぐに、HTTPPOSTハンドラーがトリガーされます
• その時点から、grafanasの作業が行われます

前述の@mgravlinと@ 007readerのように、ほとんどの通知およびアラートサービスはHTTP POSTを使用し、さまざまな種類のデータを必要とします。 したがって、私が考えることができる最も一般的なことは、ユーザーにPOSTデータとヘッダーを定義させることです。これにより、さまざまなテンプレートを使用して、1つのハンドラーで複数のシステムにフィードできます。 擬似コードの例：

"notificator": {
    "httppost": {
        "data": {
            "host": "$hostname",
            "alert": "$alertname",
            "state": "$state"
        },
        "header": {
            "content-type": "application/json"
        }
    }
}

ここで使用するのに十分な変数をユーザーに与えると、大量のバックエンドをフィードするのに十分強力になります。

繰り返しになりますが、この種のハンドラーを使用すると、コーディングの知識があるシステム管理者であれば、独自のhttp postレシーバーを構築して、たとえばhttppostを理解しないバックエンドにフィードするように変換できます。

これはステートレスであるため、スケールアウトもします。 バックエンド/ APIなどの前にロードバランサーを配置するだけで、準備完了です。

少なくとも、これは私の問題のほとんど/ほぼすべてを解決するでしょう;）

乾杯

この機能を構築していただきありがとうございます。 おおよそのリリース日はありますか？

torkeloはIRCで大まかに3か月と言いました。
私が彼を正しく理解していれば、それは本当に大まかな見積もりであり、そのように扱われるべきです。

grafanaでアラートを実行できることに興奮しています。 これが、grafanaが究極の監視ツールにならないようにしている1つの機能だと思います。

アルファ/ベータの初期リリースがある場合は、本番データをテストして早期フィードバックを提供したいと思います。

++

私2笑

+1

エムワンセグ、16・デ・11月・デ2015として午前21時03、ジンドン[email protected]
escreveu：

アルファ/ベータの早期リリースがある場合は、テストして早期に提供したいと思います
生産データによるフィードバック。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-157202686 。

+1
アルファ/ベータの初期リリースがある場合は、本番データをテストして早期フィードバックを提供したいと思います。

+1私2

2015年11月21日14時44分GMT-02：00 chaosong [email protected] ：

+1
アルファ/ベータの早期リリースがある場合は、テストして早期に提供したいと思います
生産データによるフィードバック。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-158661279 。

+1

すべての+1を見るのは素晴らしいですが、FWIWは実際には必要ありません。 これが最も待ち望まれている新機能であることはすでにわかっています。具体的な進歩が見られると、コードは別のブランチに表示され、誰でも操作できるようになります。 ところで、私たちはまた、より多くの人々をフルタイムでgrafanaで作業するようにしていますので、皆さんにご期待ください:)

はい、お願いします。この問題を「見ている」人は484人います。 「+1」するたびに、484人にメール通知が届きます。 通知を購読するだけで、問題への関心が示されます。

+1>; NS

2015年11月30日月曜日10：33：52-0800に、VadimChekanは次のように書いています。

はい、お願いします。この問題を「見ている」人は484人います。 「+1」するたびに、484人にメール通知が届きます。

ソリー、皆さんがこれに一生懸命取り組んでいることを私は知っています。 最初のリリースのタイムラインはありますか？

アラートの指標としきい値（ウェブインターフェースまたはAPIのいずれかを介して）と、これらの指標をチェックしてJSONでHTTP POSTを実行するか、stdoutでJSONを使用してスクリプトを呼び出すGrafana cronjob / daemonを構成できることを嬉しく思います。 個人がこの情報をPagerduty、Slack、IRC、SMS、電子メールなどに渡す簡単なPythonスクリプトを書くのは_非常に_簡単です。

利便性を高く評価しますが、サードパーティのツールと緊密に統合するのはGrafanaの仕事ではないと思います。むしろ、ミニマリストの実装を後で十分に具体化するよりも早く見たいと思います。

@anlutroに完全に同意し

@anlutroにも同意します。 ただし、単純なAPIを提供するだけでなく、アラート部分でAPIとやり取りするカスタムプラグインを処理できるようにします。 そうすれば、基本パッケージに電子メール、pagerduty、その他いくつかを含めることができ、コミュニティは必要に応じてそれに追加することができます。 Logstashプラグインが現在処理されている方法と同様です。

+1

アラートシステムに関するニュースはありますか？ 見積もりはありますか？

+1

+1
考慮すべき概念として、ヒットとヒステリシスのメカニズムが収集されたアラートで機能することは言及する価値があります。

異常検出、相関検出、根本原因検出などの高度なアラート機能について考えたことはありますか？

+1。 プラグインサブシステムとしてのアラート-これは最も柔軟なソリューションです。 バックエンドでこれをより適切に実行できるプロジェクトが多数ある場合は、grafana内にそれほど多くの機能を追加する必要はありません。

@ Dieterbe @ torkeloこれについて非常に大まかな「推測」さえあれば素晴らしいでしょう。 私の場合、メトリックベースのセルフサービスアラートが非常に必要な機能であり、Grafanaがそのための適切なユーザーフロントエンドであると確信しているため、個人的には保持しています。 問題は、6か月経ちましたが、ETAの更新も、あなたの1人からのコメントもかなり長い間なかったので、「何かをハックする必要がある」という逆効果的な考えを持ち始めています。 ..あと数週間ではなく、あと6か月になるかどうかを知ることができれば、十分な情報に基づいて決定を下すことができます。

ありがとう！

+1
2016年1月18日午後9時54分、「JaimeGago」 [email protected]は次のように書いています。

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo非常にラフなものがあれば素晴らしいと思います
これについて「推測」します。 個人的に私はメトリクス以来保持しています
私の場合、ベースのセルフサービスアラートは非常に必要な機能です。
Grafanaが適切なユーザーフロントエンドであると確信しています。 問題は、それは今です
6か月経ちましたが、ETAの更新はなく、次のいずれかによるコメントもありません。
あなたはかなり長い間あなたを持っているので私は「私はただしなければならないだろう
何かをハックする」逆効果的な考え...それが
あと数週間ではなく、あと6か月になると
より多くの情報に基づいた決定。

ありがとう！

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-172722684 。

+1

+1

@jaimegagoは、この問題の進捗状況または進捗状況の欠如についてここで更新しなかったことを本当に申し訳ありません。 これには時間があると思っていたのですが、優先度の高いものが邪魔になって、いつもプッシュされてしまいました。

9月に、データソースに焦点を当てた2.5リリースの基盤となるElasticsearchデータソースサポートに取り組み始めました。その後、v1がテーブルパネルであったため、Grafanaで最も評価の高い問題でした。特に、Elasticsearchサポートの後、テーブル付きの小さなリリースを感じました。パネルはアラートよりも重要だったので、それが2.6の基盤になりました。

最近、多くのユーザーや企業がGrafanaとの統合を望んでいるため、プラグインのAPIと機能の改善に取り組むようになり、この問題はさらに延期されました。 これをあまり伝えていないことを本当に残念に思います。 私たちは常にSOONを開始するという野心を持っていましたが、SOONは何度も何度もプッシュされるようになりました:(

しかし、希望があります！ Grafanaに焦点を当てたフルタイムのチームを拡大し、12月に@bergquistが参加し、2月に再び強化されます。 ETAを提供することはできませんが、これは依然として優先度の高い問題であり、できるだけ早く開始したいと考えています。 この機能をGrafana3.0のヘッドライン機能にしたいと考えています。

@torkelo更新していただきありがとうございます。 私は幸せだとは言えませんが、少なくとも新しい私たちは自分たちがどこに立っているかを知っています。

残りの1つの質問は、2.xがより多くのポイントリリースを取得するのか、それとも3.xが次のリリースになるのかということです。 ;）

@RichiHは別のポイントリリースについては

@torkelo詳細な更新を提供するために時間を

これはすでにロードマップにあるかもしれませんが、そうでない場合は、通知の時点で「POST」を追加することを検討してください。
したがって、kafakのように、アラートを別のシステムに送信して処理することができます

SNMP通知の場合は+1！

+1これはGrafanaに欠けている最大の機能であり、本番環境で実行可能な（そしてクラス最高の）監視ツールになっていると思います。

+1

非協力者からのこの問題へのコメントをロックするために利用できる管理者（@Dieterbe？）はいますか？ したがって、機能の進歩に関する興味深いコンテンツのみを取得し、役に立たない+1は取得しません...

この機能がわからない場合は、アドホックGitHubドキュメントへのリンクをご覧ください。

ありがとう：ハート：

@Mayeuええと、この問題に+1以上の貢献をした「非協力者」の一人として、そして他の場所では、この問題を協力者に固定することは道ではないと思います。 メールにスマートフィルターを作成するだけです;-)。

また、+ 1は目的を満たし、これ（および他の場所）に対する関心の量と広がりを示していると思います。
おそらく、不足しているのは、同じ役割を果たしますが、すべてのサブスクライバーへのすべての通知がないUIの+1ボタンです。したがって、@ githubの機能リクエストです。

私たちは話題から外れています、そしてこれは私がこれに関して書く最初で最後です。

この問題に関心のある人は、右上で購読する必要があります。 それはあなたに情報を与え続けるでしょう、そしてあなたは皆に電子メールを送ることはありません。

+1の蓄積を防ぐための投票システムについては、 https：//github.com/dear-github/dear-githubを参照して

+1

これについて何かニュースはありますか？

私はそうは思わないので、この問題に関するニュースはまだありません。 しかし、Grafanaの次のリリースの良いところは次のとおりです。

Grafanaは、カスタムアプリ/プラグインを処理できるようになります。 次に、独自のカスタムアラートプラグイン/アプリを作成して、Grafanaにインポートできます。 これらの小さなアプリ/プラグインを作成することは、大きなアラート機能を待っている間、すぐに成功します。

視覚化と同じ場所でアラートを構成するというアイデアが好きです。 https://www.youtube.com/watch?v=C_H2ew8e5OMのすばらしいモックですが、いつリリースされるかについての日付はありますか？

素敵なビデオ、ありがとう！

いくつかのフィードバック。

単純な線形しきい値と高度なカスタムクエリのアイデアに満足しています

最も役立つ通知機能：

• exec-sshやsendmailのようなものを使用できます
• webhooks-ユーザーはwebcgiを立ち上げて、Webフックをピックアップして何かを行うことができます...
• email-通知データのjsonダンプを使用して単純な電子メールを送信します。
• プラグイン...本当に必要ありません

アラートの状態をプルするAPI ...悪い考えのように感じます、
ただし、基本的なjson形式でアラート構成をプルするAPIは便利です。
このjsonダンプは、他のシステムが変換に役立つと思われるものに変換される可能性があります。

これが嫌われているかどうかはわかりません..寄付リンクはどこにも見つかりませんでしたが、月末までにこれをv3に組み込むにはどのような貢献が必要になるでしょう..この機能を実際に使用することはできますが、リソースATMに縛られている

+1

+1

これは、ここワークマーケットで私たちにとって非常に必要な機能です。

アラート機能は起動されていますか？

番号
11時13分PMの木、2016年2月25日にkskaran94 [email protected]書きました：

アラート機能は起動されていますか？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-189143056 。

アラート機能が夏にリリースされると想定しても安全ですか？

_サスペンスが激化する_
2016年2月26日午前10時23分、「IanHa」 [email protected]は次のように書いています。

アラート機能がでリリースされると想定しても安全ですか？
夏？

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-189320869 。

これについて何かニュースはありますか？

+1

+1はすでにそれを持っているといいでしょう、人々はすでに一年またはそれ以上待っています。

：+1：私はそれが好きです。 ビデオとプレゼンテーションをありがとう、@ Dieterbe。 テスト/アーリーアダプターに利用できますか？

@torkeloあなたが発表した

この機能をGrafana3.0のヘッドライン機能にしたいと考えています

しかし、3.0の未リリースのブランチ変更ログ（1）を見ると、アラートについては言及されていません。泣き始める必要がありますか、それとも3.0のヘッドライン機能をアラートする予定ですか？

（1） https://github.com/grafana/grafana/blob/master/CHANGELOG.md

grafana 3を不必要に延期するのではなく、grafana 3をリリースしてからアラートの作業を開始できるように、grafana3のプラグインシステムを作成することにしました。

@Dieterbe私が幸せだとは言えませんが、それは理にかなっています。 明らかなフォローアップは、警告のためにETAっぽいものがあるかどうかです。 そしてそれが3.1の確認されコミットされた機能であるかどうか。

また、回避策として、 http： //alerta.io/はGrafanaに実行してほしいことの一部を実行します。 この機能を待っている人は、試してみることをお勧めします。

プラグインの仕様はありますか？ で何かを構築するのに良いかもしれません
バージョン3のリリースに合わせてアラートを処理するコミュニティ？

ベス
2016年3月16日午前8時44分、「RichardHartmann」 [email protected]
書きました：

@Dieterbe https://github.com/Dieterbe私が幸せだとは言えませんが、それは
理にかなっています。 明らかなフォローアップは、ETAっぽいものがあるかどうかです
警告; そしてそれが3.1の確認されコミットされた機能であるかどうか。

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

@Dieterbeクライアント側で通知を作成する機能があると便利だと思います。 たとえば、ダッシュボードを備えたパブリックモニターの音声メッセージなので、ダッシュボードを見て問題があることを知る必要はありません。 Zabbixサウンドアラートのように。 この目的のために、特定のダッシュボードをスキャンする簡単なJavaScriptコードをWeb SpeechAPIを使用して通知し

アラートのバックエンドとしてkapacitorを使用するのはどうですか？彼らのスクリプトの言語はシンプルで本当に強力ですか？ または、複数のアラートバックエンドのサポートと、それに対する抽象化についてはどうでしょうか。

3.0がリリースされたので、グラファナでアラートが発生することを期待しています。 アラートは、grafanaを究極のツールにします。

こんにちは@Dieterbe 、

このバージョンhttps://github.com/raintank/grafana （アラートパッケージがあるとおっしゃっていました）からわかるように、リポジトリは非推奨になり、すべての新しい開発がhttps：// githubで行われていると表示され異なるworldPingなど）のために計画および変更されているのか疑問に思います。

こんにちは@minhdanh 、目標は常に、あなたが参照しているレポであるレインタンク固有のフォークのハックとしてだけでなく、グラフナに「適切に」アラートを追加することでした（そしてそれはとにかく非常に狭いドメインのみをカバーしました、ただし、そのリポジトリにあったスケジューラー/エグゼキューターで作業を開始したら、そのコードの一部を再利用することは理にかなっているかもしれません）。 そのため、次のgrafana 3リリースに向けて、grafanaをプラグイン可能にするために懸命に取り組んできました。 （そしてその結果として、私たち自身のニーズをスタンドアロンアプリに移すことができました。これはあなたが参照しているworldping-apiです）。
最初のステップとして、プラグインがそれらを使用して実行できるように、グラフナダッシュボードとパネルの内部からルールを管理し、何らかのAPIを介してルールを公開するUIを構築する必要があることが非常に明確になりました。 これは、アラートを実行するための最も簡単な方法です。 「バッテリーに含まれるスケジューラー/エグゼキューター」は後で表示され、参照したコードの一部を再利用する場合があります。

とにかく、最初にgrafanaで管理UIを実行し、APIを介してルールを公開し、そこから取得します。

@dieterbeに感謝します。

いつものように、たとえそれが「そうではない」だけであっても、大まかなタイムラインの問題があります
Xの前」。

私は、この質問がいかに煩わしいものであるかを理解しています。
第二部。 私はあなたが他を待っていることがどれほどイライラするかを理解してくれることを願っています
柵の側面ができます。

リチャード

モバイルで送信。 簡潔に申し訳ありません。

こんにちは、みんな、

レインタンクがここでそれを言っても大丈夫だといいのですが、ごく最近、レインタンクがアラートに取り組むために、ほぼ1か月分の専用コーディング時間を注文しました。 それで、なぜこれが最終的なアラート機能をもたらさないのか、まだグラファナでアラートの基盤を築くために何かがすぐに来るのを見るはずです。 他の企業が私たちのアプローチに従うか、個人がこの問題にいくらかの現金を投資するなら、それは思考と優先順位をさらにスピードアップするはずです。

@flyersa 、貢献してくれてありがとう！ どうすれば現金も下ろすことができますか？

ジョン

皆さんこんにちは、

多くの人がこの機能に不安を感じていることを私は知っており、チームがこの機能に取り組み始めたことを報告できることを嬉しく思います。 Grafana3.0ベータ発表ブログで遅延の理由を説明しました

アラートは2段階でリリースされます。 最初のフェーズでは、ユーザーがGrafanaUI内でアラートとしきい値を定義できるようになります。 Grafanaは、HTTP APIを介してこれらのアラート定義をサードパーティのスケジューラーとアラートバックエンドに公開します。 第2フェーズでは、完全に統合されたソリューションのために、これらの定義を消費して実行するためのバックエンドサービスを提供します。

最初のフェーズが数週間以内にリリースされることを願っています。

収益性とスピードのバランスをとろうと努めており、@ flyersaなどのお客様の商業的サポートに心から感謝しています。 他の人がこの機能とGrafanaの開発を一般的にサポートしたい場合は、サポートプランの購入を検討してください。 100％オープンソースの優れたソフトウェアの開発に役立ちます。

この機能を展開する際には、サポートされているすべてのお客様と緊密に連携し、お客様のニーズを十分に満たすようにします。

-ラジダット| ceo / cofounder | レインタンク

こんにちは@ nopzor1200 、

更新していただきありがとうございます。 アラートが利用可能になる時期の見積もりはありますか？

明らかに、特定の日付にコミットすることは不可能ですが、時間枠（週、月など）は非常に高く評価されます。

10倍！

こんにちはみんな、これに本当に興奮しています。 これが私がこれを使用することをどのように想定しているかです。誰かがそれが標準/サポートされているパターンであることをスポットチェックできるなら、私はそれをいただければ幸いです。

• 監視したい各ホストは「チェック」を発行します。 「小切手」は次のもので構成されます。
  
  
  
  • ホスト名
  
  
  • タイムスタンプ
  
  
  • 状態。0= OK、1 =警告、または2 =クリティカルのいずれかです。
  
  
• これらのチェックは、さまざまな任意のソース（シェルスクリプト+ cron、statsd / collectd、Nagiosチェックなど）から取得でき、Elasticsearchに蓄積されます。 同じチェックでもホストごとに構成が異なる場合がありますが、これはGrafanaには不透明です。
• GrafanaをElasticsearchに接続し、ホストからのチェックの状態値が1より大きい場合にアラートを出すように構成します。
• 新しいホストがクラスターに参加する場合、Grafanaでの構成は必要ありません。 Grafanaは、データポイントがどこから来たかに関係なく、状態1または2のデータポイントを表示するだけです。
• ホストが突然死んで小切手の送信を停止した場合、これを検出する必要があります。 これを処理するために、ホストは起動時にマスターチェックを「オン」ステータスとして登録し、値は正常に停止した場合にのみ「オフ」になります。 このようにして、過去X秒間にチェックを発行していない「オン」ホストを探すことができます。
• 一般に、Graphanaの時系列データに対してしきい値ベースのアラートは使用しません。 つまり、Grafana自体の中で「CPU使用率> 80％かどうかのチェック」は行いませんが、Grafanaは「CPU使用率の状態」チェック（0/1/2）を受け取り、1または2の状態でアラートを受け取ります。

ねえ@johnnyshields 、

それはかなり良さそうに見えますが、「0 = OK、1 = WARNまたは2 = CRITICAL」の代わりに、標準レベルの定義を使用しないのはなぜですか？ syslogで使用されるものは、これらのことの事実上の標準です。

• 値->重大度
• 0->緊急事態
• 1->アラート
• 2->クリティカル
• 3->エラー
• 4->警告
• 5->通知
• 6->情報
• 7->デバッグ

また、アラートのしきい値と見なすレベルをgrafanaに指示する（グローバル？）構成があります。

これを踏まえて、私はあなたの投稿に次の変更を追加します：

• ホストからのチェックの状態値がCONFIGURABLE_ALERT_LEVEL以上の場合にアラートを出します。
• Grafanaは、データポイントがどこから来たかに関係なく、状態> = CONFIGURABLE_ALERT_LEVELのデータポイントを表示するだけです。
• Grafanaは、「CPU使用状況」チェックレベルを受け取り、それに応じて構成されている場合はアラートを受け取ります。

@brunoreyありがとう、理にかなっています！

ログレベルと状態は2つの異なるものです。 6情報のログメッセージを表示することもできますが、6情報の状態になるにはどうすればよいでしょうか。

OK、WARN、およびCRITICALの状態は問題ありませんが、OKとCRITICALのみを気にする人には問題が多すぎる可能性があります。 状態を追加すると、その意味が普遍的に理解されていない限り混乱が生じます。3で制限することをお勧めします。

「CPU状態> =警告」と「CPU> 80％」のアラートのみについては、時系列DBに3レベルの状態を保持して、時間の経過とともに状態がどのように変化したかを確認したいという方もいらっしゃると思います。 それらの人々は、州の時系列データに基づいて警告します。 他の人は、生のCPU値が80％を超えていることを警告したいと思うでしょう。 重要なのは、時系列データを警告することだけが必要なことです。

時系列データを直接使用するよりも整数のログ状態の比率を選択する理由は、各ノードでアラートと見なされるものを制御できるようにしたいためです。

たとえば、ワーカーサーバーのCPUは通常100％近くですが、問題はありません。すべてのコアでフルスロットルで起動する必要があります。 ただし、WebサーバーのCPUは20％を超えてはなりません。 したがって、汎用CPUを80％以上にすると、Webには高すぎ、ワーカーには低すぎます。 （これは1つのケースにすぎません）。

@johnnyshields時系列データにしきい値ベースのアラートを使用しない理由がわかりません

上で説明したように、私にはさまざまな役割を持つサーバーがたくさんあり、しきい値はサーバーごとに異なります。 最終的には、しきい値がGrafana内で定義されているのか、サーバー自体で定義されているのかが問題になります。私の場合、サーバーの方が簡単だと思います。

さらに、一部のチェックは「はいまたはいいえ」です。たとえば、プロセスXが実行されている、ポートYへのpingが応答するなどです。

了解した。 これらの状態を判断するのは簡単な場合もあれば（> 80％）、複雑な場合もあります。 それらが複雑な場合、一部のコードがレベルを決定し、そのレベルをTSデータベースに送信します。 これは、データが情報に変換される一般的な方法です。 私のポイントは、警戒心と違いはないということです。

アラートに複雑なルールが必要な場合は、アラートエンジンにルールを組み込み、TSパイプラインにルールを組み込んで新しいTSデータを作成し、それを警告しないでください。

アラートシステムを簡素化します。 TSパイプラインの複雑さを隠します。

パイプラインで新しいTSデータを作成することと、ルールベースのアラートシステムを比較することの利点は、アラートを設定および取得する人々にとって、アラートを視覚的かつシンプルに保つことです。 電子メールまたはSMSを介して送信できる視覚化機能があり、アラートが表示されたものだけを表示します。たとえ、状態が20分前にWARNからCRITICALに変わったのを確認できる単純な状態チャートであってもです。

ホスト/ロールごとにアラートに値すると見なされるものを制御したい場合は、警告と見なされるものとCRITと見なされるものにロジックを追加するのも同様に、重大度に8層の粒度を追加することになると思います。アラート。

他のほとんどすべての最新のアラートシステムはOK / WARN / CRITに収束しているようです。おそらく、Nagiosチェックとの互換性が必要なこともありますが、単純に保ちたいという考えの方が重要だと思います。 Grafanaが同じことを行うと、他のアラート/モニタリングサービスとの統合が容易になります。 たとえば、私の場合、GrafanaアラートをSensuに送信すると、SensuがメールやSlackメッセージなどを送信することになります。 SensuにはOK / WARN / CRITしかないため、これ以上の粒度は無駄になります。

同意するログアラートレベルは過剰に設計されているようです。 OK、警告、Critはほとんどの場合その仕事をするでしょう。

アラートのしきい値については、標準偏差ベースのアラートを実行できるようにしたいと思います。 それらは実際のimoで最も役立ちます。

2016年5月12日には、8:49で、RWhar [email protected]書きました：

@johnnyshields時系列データにしきい値ベースのアラートを使用しない理由がわかりません

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

個人的には、入力としてグラファイトに入力されている既存のTSデータを使用してアラートを送信することを楽しみにしていました。特に、指定された時間範囲内の（StatsDを介した）アプリケーションメトリックからの統計を集計します。

また、アラートがしきい値でトリガーされ、しきい値を超える指定された間隔（たとえば、「rpl_delay」アラートしきい値200 int 50を設定）によって、200、250、300などでアラートが発生するオプションがあると便利です。追加のしきい値レベルを手動で指定する必要があります。

@johnnyshields 1 = WARNと2 = CRITICALの違いは
また、一時的な急上昇の警告が表示されないように、5分間連続して80％を超えていることを検出できる、よりスマートな警告があると便利です。 さらに高度なのは、しきい値の移動などです。たとえば、Webサイトのトラフィックを監視し、トラフィック量がXになり、月に1％とゆっくりと増加しますが、突然、トラフィックが10％急増します。時間。 また、トラフィックの突然の減少の反対を監視できるようにする必要があります。 Skylineが機能していないため、 https：//github.com/etsy/skylineに似てい

皆さん、ここでの私の投稿は、使用するアラート状態の正確な数に関するものではありませんでした。より一般的には、「Grafanaはアラートのユースケースとして列挙された状態をサポートしますか？」

最適な数に不一致があるため（Nagiosは3を使用し、syslogは7を使用し、2のような人もいます）、Grafanaは任意の数の状態をサポートする必要があります。

前に言ったことを言い換えると、トリガーされたアラート1またはトリガーされなかった0ごとに2つの状態しかないはずです。しきい値に近づいているかどうかを知りたい場合は、低い値に追加のしきい値を作成します。

WARNとCRITICALの理由は、実行するアクションが異なるためです。 あるグループの人々と行動は通常WARNで通知され、別のグループ/異なる行動はCRITICALで通知されます。

これは非常に価値のある差別化であり、0-1システムを廃止したくありません。

@lorenwest異なるしきい値に対して異なるチェックが必要な場合は、その個別のグループに対して追加のしきい値を作成します。
したがって、各しきい値は0または1のいずれかです。
たとえば、この方法でアラートを設定する必要があるもう1つの理由は、しきい値が70％を超える場合は電子メールが必要で、80％を超える場合はページが必要な場合です。 別々のグループが必要なのと同じように。 警告vs.クリティカルにはあいまいさが多すぎます。

理にかなっている

それで：

• メトリックには、任意の数の状態（10進数/時系列値を含む）を含めることができます
• メトリックには、同じメトリックに複数のアラートアクションを添付できます
• 各アラートはブール値のtrueまたはfalseであり、トリガーされるかトリガーされないかのいずれかです。

例を挙げると：

• 値が0 = OK、1 = WARN、2 = CRITICALの特定のメトリックがあります
• 3つのアラートを構成します。
  
  
  
  • 値= 1の場合、ダッシュボードに黄色のフラグを表示します
  
  
  • 値= 2の場合、ダッシュボードに赤い旗を表示します
  
  
  • 値が1より大きい場合は、メールを送ってください
  
  

皆さんこんにちは、

このトピックについて質問するのに適切な場所かどうかはわかりませんが、今後のGrafanaアラートモジュールについては、なんらかの方法で試してみます。
私たちの組織では、すべてのセキュリティアラートセンサーがLogstash / Elasticsearchにイベントをフィードし、

"Match where there are X events in Y time" (frequency type)
"Match when the rate of events increases or decreases" (spike type)
"Match when a certain field matches a blacklist/whitelist" (blacklist and whitelist type)
"Match on any event matching a given filter" (any type)
"Match when a field has two different values within some time" (change type)

さらに、アラート基準が検出されると、Elastalertから送信元/宛先IPフィールド、イベント、タイムスタンプフィールドなどの情報を含むスクリプトに引数を渡す引数を使用して外部Pythonスクリプトを実行し、NACシステムがそこから処理します。

Grafanaの今後のアラートモジュールをデータソースとしてElasticsearchで見て、GrafanアラートモジュールがElastalertと同じように連携し、最終的に上記の情報に置き換えることができるかどうか疑問に思います。
お知らせ下さい

ありがとう

grafanaチームがこれに取り組んでいることは知っています。このスレッドは長いですが、Kapacitorは、フロントエンドアラート構成アプリケーションの開発を大幅に容易にする機能をマージしたばかりであることを指摘したいと思います：influxdata / kapacitor＃577

Grafana側の目標は、アラートバックエンドをプラグイン可能にすることです（Grafanaが複数のTSDBストアをサポートする方法と同じです）が、Grafanaのアラート機能がリリースされたときにKapacitorがファーストクラスのサポートを取得することを期待して言及したいと思います。 InfluxDB + Grafanaと同様に、これはぴったりのように見えます。

@ thom-nicヒントをありがとうKapacitorはまさに私が探しているものです...

リーマンも素晴らしく、非常に強力です。 telegraf-> riemann（アラート）-> influxdb <-grafana

alerting_definitionsブランチで進歩を遂げています。

これで、UIおよびHTTPAPIを介して定義できる簡単なアラートルールモデルができました。 HTTP APIを介して、ルール、ルールの変更、ルールの状態をフェッチできます。 単純なアラートルールのスケジューリングとクエリの実行およびルールの実行も統合され始めています。

今私にとって大きな疑問符の1つは、現在のアラートモデルが単純すぎて行き止まりになっていないかどうかです。 つまり、将来的にアラートルールモデルを拡張するには、大幅な変更が必要になるということです。

現在のルールモデル：

description
query: #A  (referencing a query in the metrics tab)
aggregation: avg
timerange:  3600   (seconds from now to look back when fetching data)
frequency: 60  (how often to execute alert rule query and evaluation rule)
critLevel: 80
warnLevel: 50

このストレージモデルは、UIと実際のデータベーステーブルの両方で表されます。 私の恐れは、この単純なルールモデルが時系列データを十分に活用していないことです。 動的しきい値を指定することはできません（しきい値自体がクエリの結果である場合）。 もちろんこれ
後で追加することもできますが、非常に異なるルールモデルと実行エンジンが必要になります。

したがって、私の考えは、この単純なモデルを廃棄し、後で異なる時間範囲の複数のクエリをサポートできる、より複雑で動的な新しいモデルを考案することです。

単純なクエリ：

"alert": {
   "name": "CPU usage last 5min above 90%",
   "frequency": "1m",      
   "expr": "query(#A, 5m, now, avg)",
   "operator": ">",
   "critLevel": 90,
  },

//渡された値に基づいて動的しきい値を使用するアラートになります

"alert": {
   "name": "CPU usage last 5m is 20% higher compared to last 24hours avg",
   "frequency": "1m",
   "expr": "query(#A, 5m, now, avg) => percentDiff() => query(#A, 1d, now, avg)",
   "operator": ">",
   "critLevel": 20,
  },

ここでGraphiteを再発明していると言って、これに疑問を抱くかもしれません。このような表現はTSDBによって処理される必要があります。 ただし、TSDBは、異なる時間範囲のクエリを使用した計算をサポートしていません（timeShiftは同じ期間のみをシフトします）。 動的しきい値に関するいくつかの問題は、それを視覚化する方法です。 また、アラートルールを、パネルで実際に視覚化されているものからさらに切り離すことができます。

GAL（Grafana Alerting Language）がどのように表示されるかはよくわかりません。 各部分が1つ以上のシリーズを返すクエリ（各シリーズは1つのポイントに集約される）であり、オプションの減算関数またはパーセント関数で別のクエリと比較できる場合は、式チェーンだけである必要があります。 式全体が値になり、演算子およびクリティカル/警告レベルで使用してアラート状態を取得できます。

または、式に演算子とレベルを含める必要がありますか？

他のオプションは完全なプログラミング言語になり、次のことを行います。

expr: "
let last5mAvg = query(#A, 5m, now, avg)
let last24hAvg = query(#A, 1d, now, avg)

return percentDiff(last5minAvg, last24Avg)
"

@torkelo ：

1. これをスタンドアロンコンポーネントとして設計していますか？ 最終的には、 Kapacitor for Influxdb **に似たシグナルプロセッサを構築し、それ自体がシグナルを発信します（0 = "ok"、1 = "warn"、2 = "crit"）。 この信号をGrafana以外の場所に送信することは可能ですか？たとえば、A）Nagiosに送信するか、B）パイプでDBに戻しますか？
2. 同様に、grafanaには、上記のシグナルエンジンを使用せずに、Nagiosプラグインなどのサードパーティソースから0/1/2シグナルを受信するオプションがありますか？その多くはすでに野生に存在していますか？

** =許可されたKapicatorは時系列ストリーム処理を使用しますが、あなたはポーリングベースのエンジンですが、それでもシグナルを発します。

ご意見をお寄せいただきありがとうございます。

私の意見では、grafanaアラートをシンプルに保つことです。シンプルにするための最良の基準は、視覚化です。 アラートを既存のTSグラフの線として視覚化できない場合は、複雑すぎます。

複雑さはTSグラフに任せてください。 アラートのニーズが大きい場合は、それらのニーズに基づいて別のTSデータのセットを作成し、そのデータのグラフにアラートを配置します。

指針となる原則が1つしかない場合は、アラートを簡単に視覚化する必要があります。

もう1つの問題は、「構成する必要があるアラートの数」です。 このトピックはこのスレッドで説明されており、複数のアラートを1つのアラート（警告、エラー、高警告、低エラーなど）に入れ始めるとすぐに、柔軟性が失われ始めると思います。 警告とエラーは異なるものです-それらは異なるレベルを持ち、異なる人々がそれらを気にし、そしてそれらは異なる通知方法を持っています。

アラートをシンプルに保ち、人々が複数のアラートをグラフに配置できるようにします。

ここでは、＃3677（時系列クエリ結果の一般的な変換）が非常に役立つと思います。 これらのTSDBに依存しない関数を使用すると、警告やクリティカルなどに単純な固定値のしきい値を使用できる複雑な「アラートグラフ」を作成できます。

その場合に必要なのは、単純なアラートルールモデルだけです。 グラフの作成と組み合わせでは、複雑さが「隠され」ます。

私はそれをシンプルに保つためにすべてです。 私は開発者ではなく、より軽いtouch-dev-opsであり、Grafana / Graphiteプラットフォームを管理者チームに引き渡して管理できるようにしたいと考えています。 この場合、既存のものと同様のアラートビルダーがはるかに簡単になります。 グラフのクエリと同じ方法でルールを作成できる限り、新しい命令が大量に導入されても大騒ぎすることはありません。簡単に理解できます。

tl; drまったく新しい言語はやり過ぎで、複雑すぎるかもしれません。 mouse = goodを使用してルールを作成します。

まったく新しい言語を構築することを除けば、GrafanaがInfluxDBクエリを作成するためのフロントエンドを提供するのと同様に、これは主にKapacitor、Reimann、Bosunなどの既存のアラートプラットフォームのフロントエンドになると思いました。 たとえば、手間のかかる作業はサードパーティのアラートシステムによって行われ、GrafanaがUIを提供します。 多分そうではありませんか？

IIRC、Grafanaは、「バッテリーは含まれていますが、取り外し可能」な方法を採用したいと考えています。 つまり、付属のアラートエンジンを使用してスタンドアロンで動作する必要がありますが、既存のプラットフォームにプラグインできる必要もあります。

電子メール（SMTPホストを提供）とWebAPI / Webhookの2つの組み込みメソッドが付属している必要があると思います。 その後、残りはPagerDutyへの統合などのプラグインが付属します。

@felixbarnyは、既存のプラットフォームにプラグインできるという意味を説明できますか？ もちろん、アラート通知は多くの既存のアラートツールと統合されます。 ただし、アラートルールのスケジューリングと実行を処理する他のシステムでは注意が必要な場合があります。GrafanaHTTPAPIからルールを読み取るだけで可能です。 ただし、ルールのスケジューリングと実行を処理するには、多くのコードが必要になります。 ただし、もちろん、Grafanaでのみルールを定義し、別のシステムが常にルールを読み取って実行するオプションを提供します。

@GriffRebornあなたは別のレベルで考えています。 SMTP、PagerDutyなどの出力を_すでに_サポートしていると述べた既存のアラートバックエンド：
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

これらの製品は、複雑で動的なアラートを適切に実行します。 彼らが持っていないのは、アラートを構成および管理したり、アクティブなアラートを視覚的に識別したりするための優れたビジュアルフロントエンドです。私が欲しかったのは、基本的に構成をプッシュするフロントエンドUIです（Grafanaがサポートする）アラートなどです。選択したシステムで、実際にすべての作業を実行します。

@ thom-nic同意します。 主な焦点は、既存のアラート情報フィード（「フィードにとらわれない」）を使用できるアラートダッシュボードの構築です。 Grafanaが後援する軽量信号処理エンジン（理想的にはスタンドアロンとして）を作成することは、二次的な関心事であるはずです。

@johnnyshieldsは、既存のアラートバックエンドからの情報を表示する新しいパネルを作成するのは簡単です。 私たちがやろうとしているのは、Grafanaユーザーがグラフ/シングルスタットパネルで定義するメトリッククエリにアラートルールを簡単に定義できるようにすることです。 次に、これらのルールをスケジュールして実行および評価し、アラート状態を更新し、通知をトリガーするアラートエンジンをgrafanaバックエンドに配置します。

また、シンプルなモデルで十分であり、待望の機能をできるだけ早く導入できると思います。 グラファナはすべてメトリック用であり、基本的なアラートで十分です。

@torkelo正直なところ、私はbosunのようなアラートプラットフォームにあまり精通しておらず、適切な統合が具体的にどのように見えるかわかりません。 私は@Dieterbeが言ったことを参照していました。たとえば、彼のGrafanaconプレゼンテーションで： http ：//de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarnyまあそれは私たちもやろうとしていることです。 Grafanaで定義されたルールを読み取るために使用する他のアラートバックエンド用のAPIを用意する。 ただし、Grafanaからアラートルールを読み取り、それらを別のルール実行エンジンに変換するブリッジは提供しません。

したがって、私たちが今持っているアイデアの1つは、このような単純なルールを定義することです。

ただし、動的なしきい値を設定して、別のクエリまたは同じクエリと比較することもできますが、時間範囲と集計は異なります。

別の複雑な「予測」クエリ。 クエリを使用してトレンドラインを取得する場合は、それを時間的に予測し、アラートを出します。

両方の長所のようです。 そのアイデアが大好き！ 「EvaluateAgainst」機能はGrafanaの一部ですか、それともTSDB固有ですか？

@felixbarnyは、Grafanaアラートルールモデルの一部であり、Grafanaアラートルール評価エンジンによって処理されます。

1つのグラフに複数のルールを添付できますか？ 1つのルールの警告/クリティカルレベルの単純さが好きです。一部のグラフには、1つのアラートに複数のレベルが必要な、または1つのグラフに複数のアラートが必要な高しきい値と低しきい値の両方があります。

複雑なルール機能は気に入っていますが、これはすべて、別のグラフを作成し、そのグラフに単純なルールでアラートを出すことで実現できます。 アラートシステムから複雑さを排除することの利点は、ルールを起動させる状況の履歴がTSDBに保持されることです。

これにより、アラートをグラフ上の単純な水平線として視覚化し、そのルールが時間の経過とともにどのように発生するか（または発生したか）を確認できます。

それは、平均的な人にとっては単純で、誰にとっても十分に複雑で、視覚的に物事を理解している人にとってはアクセス可能な警告を維持します。

@lorenwestはい、私たちは物事をシンプルに保ち、パネルごとに1つのアラートルールのみを許可します。 ただし、ルールは多くのシリーズを返すクエリを使用できます。これにより、基本的にルールが複数に分割されます（したがって、クエリがサーバーごとにシリーズを返す場合、各サーバーをチェックする単一のルールを持つことができます）。

複雑なルール機能は気に入っていますが、これはすべて、別のグラフを作成し、そのグラフに単純なルールでアラートを出すことで実現できます。

ここで何を意味するのかわかりません。 別のグラフは、別のクエリと比較して、別の時間範囲でそれ自体と比較して、別のクエリと完全に比較して、クエリでアラートを送信するシナリオをまったく解決しません（おそらく、他のクエリは、データベースから動的しきい値をフェッチする別のデータソースです）。 このシナリオは、TSDBで解決することも、ルールを2つの別々のパネルで2つのルールに分割するだけでは解決できません。

しかし、主な目標は、単純なケースを解決し、それを簡単で直感的にすることですが、少なくとも後で、TSDBデータを処理しているという事実と事実を実際に利用するいくつかのより複雑なアラートルールをサポートしたいと考えていますさまざまなクエリがさまざまなデータソースをターゲットにできること

@lorenwestが指摘したのは、アラートルールが単純なしきい値であるため、ルールはグラフに視覚化されているデータに適用されるということだと思います。 したがって、しきい値をオーバーレイすると、現在のしきい値に基づいて、過去にアラートがトリガーされた場所を明確に確認できます。

より複雑なアラートモデルでは、しきい値がアラートをもたらす場所を示す目に見えるインジケーターがなくなりました。

単純なモデルに固執することで、データソースが機能を提供することで、複雑な監視要件の多くを達成できます。 「比較した変化率」については、当日と前日を比較するグラファイトクエリ（異なるグラフ）を作成し、それに簡単なしきい値を設定できます。 アラートを作成するのは確かにはるかに複雑なプロセスですが、機能します。

同じページ@torkeloにいることをうれしく思います。 これは、元の投稿の説明と一致します。

Grafanaに接続するためのまったく新しいアラートプラットフォームを作成するのは好きではありません。 Grafanaのアラートに期待しているのは、NewRelicに代わるものですが、Grafanaがもたらす素晴らしいパワーを備えています。 グラフの1つがしきい値に達したときにアラート（電子メール、APIなど）をトリガーできること...それはGOLDです。 人生を変えるもの。

単純なしきい値アラートでさえ、優れた単純なソリューションになります。

この1つのルールに従うと、金色になります。

パネルにオーバーレイしても視覚化できないアラートは絶対に許可しないでください。

視覚化できない場合は、複雑すぎます。 この複雑さを具体化するチャートを作成し、そのチャートに注意を向けます。 これにより、アラートビルダー（およびコンシューマー）が自分たちが何に取り組んでいるのかを簡単に確認できるようにしながら、その複雑さ（良いこと）を具体化する視覚化を構築する必要があります。

@woodsaj私は、あなたが警告するものとあなたが見るものとの間のリンクを奨励したいということに同意します。それは私たちがこれまで放棄することについて議論したことではありません。 ブレーンストーミングを試みているのは、単一クエリの静的しきい値がどこまで進んでいるかということです。GrafanaAlertingのv2またはv3には十分ですか？ そして、単一のクエリと静的なしきい値で可能なアラートルールの種類の制限についての議論を引き起こします。

現在、TSDBは、どのような種類のネストされたクエリを実行できるかについて非常に柔軟性がありません（たとえば、シリーズをそれ自体と比較してください）。 ネストされたクエリをサポートしているのはGraphiteだけです。 ただし、Graphiteでさえ、異なるタイムウィンドウを対象とする2つのクエリを比較することはできません（タイムシフトは同じウィンドウをシフトするだけで、サイズの異なるタイムウィンドウはシフトしません）。 しかし、これについて考えれば考えるほど、TSDBクエリで十分に強力であれば、このほとんどを解決できることに同意します。

この議論を提起する主な理由は、ルールをモデル化する方法、ルールを構成するコンポーネント、ルールに含まれる抽象化（クエリ、時間枠、集計、レベルなど）についてブレインストーミングすることです。 将来の傾向を予測するv2以上の機能豊富なアラートクエリで動的しきい値をサポートするにはどうすればよいでしょうか。 モデルとルール評価エンジンをどのように変更する必要がありますか？

「アラートをパネルにマップする必要がある」に関して-これは便利なオプションかもしれませんが、v1の場合でも設計上の制約としては不適切だと思います。

アラートのよりトリッキーな側面の1つはスコープであると思います。視覚化について話し始めると、問題が明らかになります。

スコープは、アラートがカバーするシステムの表面積/深さとして考えます。 したがって、たとえば、アラートのスコープは次のようになります。

• サービス（アプリケーションメトリック）
• サービスを構成するクラスター全体
• クラスター内の個々のノード
• クラスター内のホスト/プロセス
• プロセス/アプリケーションのサブシステム（ミドルウェアメトリック）
• ホストのサブシステム（つまり、ディスク、CPU）（システムメトリック）

どのレイヤーに警告すべきかについて、「正しい」単一の答えがあるとは思いません。 チーム、サービスの重要性、一般的なインフラストラクチャ（つまり、クラウドとハードウェア、クラスターとモノリス）などに依存する場合があります。したがって、階層化されたスコープを考えると、アラート階層は良いように思えます。 しかし、これらの階層を定義することは一般的に維持可能ではないと思います。 それは多くの作業と変更であり、現実世界のシステムではきれいな木を作らない関係がしばしばあります。 GoogleのSREブックの攻撃性：

"" "
Google SREは、複雑な依存関係階層で限られた成功しか経験していません。 「データベースが遅いことがわかっている場合は、データベースが遅いことを警告します。それ以外の場合は、Webサイトが一般的に遅いことを警告します」などのルールを使用することはめったにありません。 依存関係に依存するルールは通常、データセンターからユーザートラフィックを排出す​​るシステムなど、システムの非常に安定した部分に関係します。 たとえば、「データセンターが空になった場合、その遅延について警告しないでください」は、データセンターの一般的な警告ルールの1つです。 Googleのインフラストラクチャでは継続的なリファクタリングが一定の割合で行われているため、複雑な依存関係階層を維持しているチームはほとんどありません。
"" "

また、スコープに関連するのは、アラートのタイプです（つまり、電子メールを送信するか、ログに記録するか、ダッシュボードに表示して、朝のラウンドを行っているときに対処できるようにします）。

したがって、Grafanaの場合、アラートは次のようにマップされる可能性があります。

• パネル
• パネルのグループ
• ダッシュボード
• ダッシュボードのグループ（ドリルダウンがあると思います）

これらのアラートに通知を送信させたい場合もあれば、スコープの1つでGrafanaのどこかにある視覚的なインジケーター（つまり、しきい値を超えた、または注釈マーカーとしての状態の変化）にしたい場合もあります。 それは、会社ごとに、さらには会社内のグループ/サービスごとに異なるでしょう。

@kylebrandt Grafanaでのアラートの全体的なアイデアは、パネルと視覚化に結び付けることです。 さまざまなスコープ（サービス、クラスター、個々のホストなど）のメトリックを視覚化するグラフとパネルを作成でき、それを使用することで、任意のレベルまたはスコープでアラートを送信できます。

アラートをパネルや視覚化できるものにリンクする方法がわからないと、さまざまなレベルでのアラートの定義が停止します。 そしてもちろん、アラートごとにどの通知を使用するかを指定します。

@torkeloアラートの決定は、常に（true / false）ブール値に

したがって、 $metric > $thresholdは最も基本的なアラートであり、もちろん、メトリックがしきい値を超えた場合にtrueを返します。 これはパネルにうまく適合します（メトリックを視覚化し、パネル内のしきい値を視覚化します）。 しかし、警告ノイズを排除するために、範囲と条件はほとんどの場合それを超える傾向があります（私たちがBosunに取り組み始めたとき、私はこれらのケースが少数であると思いました、あなたがしたいのであればそれほど多くはありませんノイズを制御します）。 だからあなたは次のようなことを言うかもしれません：

次の場合に警告します。

• X分間CPUが80％を超えている
• ジョブAが実行されておらず（CPUを上げることがわかっていて、気にしない）、ジョブAが1時間以上実行されていない
• ディーターは過去24時間に3杯以上のスターバックスを持っていました（彼がもっと持っているとき、彼はCPUを上げる愚かなことをし、私たちはそれらについて警告したくないからです）

したがって、複数の条件がある場合にアラートだけを視覚化することは（True / False）、それほど有用ではありません。 それぞれの条件を視覚化する必要があります（そして、情報をサポートするためにさらにいくつかの条件を視覚化する必要があります）。

これらすべての条件を新しいメトリックにすることは、現時点では視覚化に役立ちません。これは、True / Falseであり、実際に確認する必要があるのは、基礎となるすべての情報であるためです。 したがって、メトリック+しきい値を視覚化する代わりに、さまざまなスケールである可能性のあるメトリック+しきい値を視覚化することができます。

したがって、この場合、アラートは単一のパネルにマップできますが、視覚化とアラートによっては、それが実際には望まない場合が多くあります。 アラートを構成するブール項目ごとにパネルを作成して、どれがトリップしたかを確認したいと思いますが、アラートの疲労を避けるために、すべての条件の組み合わせに対して1つの通知のみが必要です。

単純なブール論理を持つある種のアラートジョイナーがこれを簡単にするかもしれないようです。

alert1:
  select: CPU is above 80% for X minutes
  output: null
alert2:
  select: Job A is not running
  output: null
alert3:
  select: Job A has being running for more than an hour
  output: send alert
alert4:
  select: Dieter has had more than 3 cups of starbucks in the last 24 hours
  output: null

(alert joiner does simple true/false logic and perhaps can graph it.)
alert5:
  database: alerts
  select: alert1 & alert2 &!alert4
  output: send alert

@torkelo Githubから
さらに、「サーバー管理」の「サーバー設定」内に「alerting：enabled = false」が見つかりました。 それはアラート機能に影響しますか？ 使用する必要のあるビルドフラグまたはランタイムフラグはありますか？
アドバイスを下さい。

最新のコード（ebada26b85d8410142c2942ef7ba78b17e88313c）を試して、アラートを有効にしてUIを取得しました。

しかし、たくさんのエラーが発生しました

EROR[06-17|14:38:23] Failed to extract alerts from dashboard  logger=alerting.extractor error="missing query.query"
EROR[06-17|14:38:23] Failed to save alerts                    logger=context userId=1 orgId=1 uname=admin error="Failed to extract alerts from dashboard"

ProyyモードとDirectモードでInfluxDBデータソースを試してみました。

それは期待されるものですか？

はい、まだテストの準備ができていません。

知っておいてよかった。

私は時々更新を追跡します。
このブランチがマスターにマージされるのを待って、すぐに使用できるようにする方がよいでしょうか？

はい、7月中旬にマスターするためにマージしたいと思っています

これに関する進捗状況の更新はありますか？
あなたはまだ7月中旬にヒットするつもりですか？
この機能をできるだけ早く本番環境に導入することは、非常に大きな助けになります。

電子メールのみのアラートのような軽いバージョンでさえ、とても素晴らしいでしょう！
進捗状況の更新は素晴らしいでしょう（カスタムアラートシステムを実装するか、Grafanaに依存するかを選択する必要があり、間違いなく2番目のオプションを好みます！）。
君たちありがとう

冬が来たので、警告します:)

1:41の火、2016年7月12日には、C-ヴァル[email protected]書きました：

電子メールのみのアラートのような軽いバージョンでさえ、とても素晴らしいでしょう！
あなたの進捗状況に関する最新情報は素晴らしいでしょう（私はどちらかを選択する必要があります
カスタムアラートシステムを実装するか、Grafanaに依存することで、私は間違いなく
2番目のオプションを好む！）。
君たちありがとう

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
。

ディーパック

これを「ビジネス要件」と見なし、「エンタープライズアーキテクチャ」レベルで評価することをお勧めします。 エンタープライズソフトウェアアーキテクチャに使用されるプラクティスとパターンの_いくつか_を適用することにより、アジャイルモデリングを通じてアイデアを伝達できるようになり、利害関係者と開発チームの両方の理解の質が向上します。

テクノロジーとアーキテクチャの秘密のソースについて話し始める前に、少なくとも次のことに同意する必要があります。

1. 私たちは、「ビジネスプロセス管理（BPM）」の観点から機能を考えています。 と
2. 「ビジネスプロセスモデリング言語（BPML）」を使用しているため、UMLを使用して同じ場所で要件と実装のモデリングを開始できます。
3. 私たちは、エンタープライズレベルの規律でアーキテクチャを定義します。

今、楽しい部分です！ 世界規模でのモニタリングの豊富な経験があるので、次のことを考慮することをお勧めします。

• grafanaはそのままにして、プレゼンテーション層です。 アラートを生成するためのルールをモデル化および定義するためのワークフローを追加する場合は、問題ありませんが、そのままにしておきます。 結局のところ、それがパネルとプラグインが正しく実装された理由ですか？
• 運命づけられた場所にデータを残します。 自宅に電話された指標は一級市民として扱われるべきであり、それらの値を永続的に保存することが最優先事項です。 キャッシュ、documentdb、tsdb、またはsqlサーバーのいずれにあるかは関係ありません。 フォールトトレランスが暗示されます。もちろん、アーキテクチャに対して適切な「テクノロジの選択」が行われます）。
• 可用性とスケーラビリティのセットアップを行うには、このために特別に設計された適切なフレームワークを使用する必要があります。サービス指向アーキテクチャ（ "SOA"）を満たします。 非常に高いレベルでは、メッセージキュープロトコルを使用して、「AMQP」プロトコルを介してイベントとメッセージを送受信できます。 今のところ、RESTとHTTPを忘れてください... RabbitMQやZeroMQなどのメッセージキューサーバーを使用すると、データの発行者/送信者とデータを処理するワーカー/受信者の両方が使用できる、分散型のフォールトトレラントで高可用性の通信パイプラインがあります。 これが「エンタープライズサービスバス」です。 （ZeroMQについて説明しているこのスライドデッキを確認してください）。
• 異種のリンクされていない複合データモデル用に特別に作成されたクエリ言語を使用します。 「グラフデータベース」と「 SparQL 」クエリインターフェイスを使用すると、次のようになります。

SPARQLを使用すると、ユーザーは、大まかに「キー値」データと呼ぶことができるデータ、より具体的には、W3CのRDF仕様に従ったデータに対してクエリを作成できます。 したがって、データベース全体は「主語-述語-目的語」トリプルのセットです。 これは、MongoDBなど、一部のNoSQLデータベースでの「document-key-value」という用語の使用法に類似しています。
[..]
したがって、SPARQLは、個別のスキーマ定義を必要とせずに、スキーマが本質的にデータの一部であるデータに対して、JOIN、SORT、AGGREGATEなどの分析クエリ操作のフルセットを提供します。 ただし、スキーマ情報（オントロジー）は、さまざまなデータセットを明確に結合できるようにするために、外部から提供されることがよくあります。 さらに、SPARQLは、グラフおよび図と考えることができるデータの特定のグラフ走査構文を提供します。
..
https://en.wikipedia.org/wiki/SPARQL

Nagiosが一度も行ったことのないことをGrafanaが私たちに与えたことは、単一障害点、つまりスケーラビリティの欠如に要約されることを忘れないでください。 Grafanaはあなたが言うように「高速」ですが、メタデータレイヤーではなく、時系列データのみを保存および処理しているという事実を考慮していません。 SparQLのセマンティクスとElasticache +グラフデータベースエンジンの能力が必要です。

複雑に聞こえるかもしれませんが、これらの2ページよりも簡単に複雑になる可能性がありますが、何年にもわたるブルートフォース、試行錯誤からあなたを救い、ノイズを取り除きました（つまり、エンタープライズアーキテクチャには30のデザインパターンがあり、 umlなど、これをノックアウトできるようにするには、3について話す必要があります-今のところ）

これでギアが回転するはずです。少し眠る必要があり（一晩中引っ張られます）、パート2に。skypeの@appsoaまたはIRCのyomateoに

その間にいくつかの御馳走：

• SOAを使用して作成したリファレンスアーキテクチャの例。
• Microsoft Azure Service Fabric：常時接続のスケーラブルな分散アプリケーションを構築して運用します。

@talbaror理想的には、PIXファイアウォールのようなエージェントを使用してNACのログメッセージをキャプチャし、rsyslogdまたはイベント処理サーバーが使用するプロトコルを介して送信/再生するだけです。

イベント処理サービスを設定していない場合は、 Snort-Network IntrusionDetectorのルール処理を使用できます。 助けが必要な場合は私にpingしてください..私はサービスとしてのセキュリティ会社で4年間過ごしました;）

バンシーのような異常検出を統合できますか？
視覚的なマーカーと警告付き。

@torkeloは、これを出荷するためのタイムラインで時価教えてください。

@johnnyshields私は今これに毎日取り組んでいます。 それはトリッキーなことであり、アラートシステムが進化し、将来さらに豊かになることができるように、基本を正しく理解したいと考えています。 私が使用している現在のモデルは非常に見栄えが良く、来週、新しい条件ベースのアラートルールモデルに関する更新を投稿する予定です。

それをマスターにマージし、問題がスムーズに進んだら2週間以内に（フィーチャートグルの背後で）利用できるようにしたいと考えています。 Grafanaの次のバージョン（9月の3.2リリース、または10月末のより大きな4.0リリース）の日付はまだ決まっていません。

@torkeloできるだけ早くアラートが
kubernetesにgrafanaを使用する。

すでにstatsd / graphite / grafanaを配置していて、Grafana Alerting Systemが最初のアラートを実行する準備ができるのを待っている他の人々のために、私はその間に使用するための優れた代替手段を見つけました、Seyren： https ：

PagerDutyと簡単に統合でき、グラファナダッシュボードにすでにあるグラフターゲットをコピーして、警告とエラーのしきい値を指定してアラートを出すことができます。

チームはアラート機能で大きな進歩を遂げているようです。 私は「ただ一つのことをするが、それをうまくやる」という哲学を信じています。 アラートロジック全体をGrafana内に配置することが最善のアイデアかどうかはよくわかりません。 とにかく、私は小さなノードのjsデーモン「flapjack-grafana-receiver」を作成して、grafanaイベントをflapjackに投稿しました。おそらくオープンソースにします。興味のある人はいますか？

https://github.com/Charles546/flapjack-grafana-receiver

進捗状況の更新！

4月以降、少なくとも1人がフルタイムでアラートに取り組んでいますが、多くの書き直しがあったため、進捗は思ったほど速くありませんでした。 初期バージョンの基本的なアラート機能を目指していますが、将来のリリースで大規模なオーバーホールなしにアラートルール定義とアラートルール評価エンジンを拡張できるように、基本的なアラートルールモデルを正しく取得することが重要であると考えています。

非常に単純なアラートから始めるという目標は、私たちを正しく感じられなかったいくつかの行き止まりを取り除き、いくつかの大きな書き直しを必要としました。 しかし、私たちは今、軌道に乗っており、私たちがはるかに満足している条件ベースのルールモデルで順調に進歩してい

ルールの定義

新しいアラートルールモデルは、1つ以上の条件で構成されています。 条件にはさまざまなタイプがあります。 現在、クエリタイプのみがあります。 ただし、後でTime of day 、 Day of week 、さらに興味深いことにOther alertなどの条件を追加できます（したがって、別のアラートルールの状態を条件として含めることができます）。

クエリ条件は、クエリと時間範囲で構成されます。レデューサーは、クエリが返した各シリーズに対して返されたすべてのデータポイントを取得し、しきい値の比較に使用される単一の値に減らします。 レデューサーは、将来、データに対して線形回帰を実行し、将来の値を予測する「予測」になる可能性もあります。

クエリ条件の評価部分は、より大きい、小さい、間などのいずれかになります。グラフ内のハンドルをドラッグして、しきい値を設定できます。

条件ベースのモデルは、エンジン全体をオーバーホールすることなく、将来アラートルールをより強力にするための多くのエキサイティングな可能性を提供します。また、クエリ条件には、拡張を可能にするこれらのプラグ可能なコンポーネントがあります（パラメーター付きのリデューサーとパラメーター付きのエバリュエーター）。

通知

今週は通知に取り組んでおり、物事がまとまり始めています！

メール、Webhook、Slackの通知タイプがあります。 Slack通知はかなり見栄えがします:)

助けたい？

すでにテストしてフィードバックを提供できます。コードはアラートブランチにあります。また、を使用して構成ファイルで有効にする必要があります。

[alerting]
enabled = true

マスターにマージ

私たちはこれをマスターにマージし、そこで作業を継続することに非常に近いです。 私は夏休みの前にこれを行うことを望んでいました（ちょうど1週間が過ぎました）が、マスターにマージする前にやりたいマイナーなSQLスキーマの変更がまだいくつかあります。 マスターへのマージは8月19日までに行われます。約束します:)その後、アラートは最新の4.0ナイトリービルドで行われるため、バグやフィードバックを簡単にテストして報告できます。

残り物？

ベータリリースに必要な機能が不足しています。

• より多くのレデューサーとレデューサーを変更する機能（現在は平均のみ）
• メール通知はがらくたのように見えます
• Webhookのスキーマをロックダウンする
• アラートリストページのデザイン
• アラート履歴を表示する
• アラート履歴をグラフ上の注釈として表示
• アラートスケジューラとエンジンの安定性
• 負荷を分散するためのアラートスケジューラの改善（アラートが同時に実行されないようにするため）
• アラートスケジューラクラスタリング

この機能に時間がかかって申し訳ありません。

@torkeloは、ベータ版で設定された期間、マシンをメンテナンスモードにする機能を持っている必要があります。

@torkelo更新していただきありがとうございます。 私が見ることができることから、これはGrafana内でアラートを出すことを目的としています。 https://github.com/grafana/grafana/issues/2209#issuecomment -149351263に記載されているモジュラーコースをまだフォローしてい

また、これに取り組んでいる隠されたエルフが誰であるかに感謝します。 @Dieterbeだと思いますが、わかりません。

@RichiHそれがどのように機能するかはわかりません。そのコメントのようにシステムを実行する方法を

@torkelo私の考えは同じ線に沿っていたので、私は尋ねることにしました。

個人的には、Prometheusのアラートが気になりますが、Grafanaとの視覚的な統合があれば幸いです。 ルールがPrometheusによって保存および実行される限り、ルールをどこで定義するかはあまり気にしません。

@bergquist promconにいるので、座って可能なアプローチについて話すのは理にかなっているかもしれません。 必要に応じて、Prometheusの開発者に最適な時間について説明します。 クリーンアップの前および/または後の夕方に座る静かな時間がある場合とない場合があります。 よろしければお知らせします。

こんにちは@ torkelo-これは見栄えがします。

ブランチをプルしましたが、ElasticSearchのアラームをテストすると、エラーが発生します

firing false
timeMs 0.225ms
error tsdb.HandleRequest() error Could not find executor for data source type elasticsearch

...これは、ElasticSearchがまだサポートされていないことを意味します：cry：

プロセス出力のps私はこれを取得します：

EROR[08-04|09:15:00] Alert Rule Result Error                  logger=alerting.engine ruleId=1 error="tsdb.HandleRequest() error Could not find executor for data source type elasticsearch" retry=nil LOG15_ERROR="Normalized odd number of arguments by adding nil"

@ Workshop2これまでのところ、アラート用のグラファイトのみをサポートしていますが、最終的にはElasticsearchをサポートする予定です:)これについてはより適切なエラーメッセージを追加します。

クエリがデータを返さない場合、アラートシステムはどのように動作しますか？ デフォルトでアラートをトリガーしますか？
また、クエリによって返されたデータポイントの数を返すだけの単純なcountレデューサーはかっこいいでしょう。

@bergquist使用されているデータソースに関して、アラートは透過的であると思いました。 グラファイトデータソース以外でアラート機能のプレビュー/テストを開始できるようになるまでどのくらいかかりますか？ （「どれくらい...」という質問は誰も好きではないことに気づきました、ごめんなさい）

@RichiH 1つのオプションは、bosunのようにgrafanaアプリを作成することです。 https://grafana.net/plugins/bosun-appしかし、それは簡単な方法でクエリ/ダッシュボードの再利用を可能にしません。 promconでそれについてもっと話しましょう。 あなたに会うのを楽しみにしています！ :)

最初はinfluxdbのサポートもありませんか？

グラファイトとの具体的な結合を知りませんでした:(流入と
elasticsearch;）

14:18時月、2016年8月8日には、elvarb [email protected]は書きました：

最初はinfluxdbのサポートもありませんか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
。

エンリコ・ケルン

リードシステムエンジニア

glispa GmbH
SonnenburgerStraße73
10437ベルリン、ドイツ

tel：+49 30 5557130-17
ファックス：+49 30 5557130-50
skype：flyersaenrico。 [email protected]

---

Sitz Berlin、AG Charlottenburg HRB 114678B

最初は、リリース前にPrometheusを追加する可能性があります。 おそらくInfluxDBまたはElasticsearchも、アラートのスケジューリングと実行がバックエンドで行われ、応答コードが最初から（Goで）記述されているため、フロントエンドのデータソースプラグインコード（jsで記述）を再利用することはできません。

私たちはinfluxを使用しています。私たちは、grafanaの統合をやめ、アラートの作成と管理にシンプルなWebフロントエンドを備えたKapacitorを使用する可能性があると思います。

+1アラート+ InfluxDB。

2016年8月8日月曜日午前6:01、トムニコルズ[email protected]
書きました：

私たちは流入を使用しています、私たちはグラファナの統合と使用を放棄するかもしれないと思います
アラートを作成および管理するためのシンプルなWebフロントエンドを備えたKapacitor。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
。

ディーパック

残念ながら、データソースプラグインの構築に費やした作業は、クライアントでのみ役立ちます。

さまざまなデータソースのアラートをサポートする即時および長期の作業、goプラグインアーキテクチャの構築などを考慮すると、NodeJSでアラートサーバーを構築するのは（少なくはないにしても）ほぼ同じ量の作業ではないので、既存のデータソースプラグイン？

goとnodejsについての意見はさておき、これにより、さまざまなデータソースでアラートを出すためのコードの重複を大幅に減らすことができます。

そして、あなたが本当にノードが気に入らないのなら、JSをロードして実行するためのコールアウトメカニズムがあるに違いありません。

ElasticSearchの+1アラート

こんにちは、私たちはアラートシステムを待っていました... OpenTSDB！ していい
OpenTSDBですぐに入手したいですか？ （たぶんいつ？）

チームに感謝します！

2016年8月8日17：28 GMT + 02：00スラヴァVishnyakov [email protected] ：

ElasticSearchの+1アラート

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
。

ElasticSearchの+1アラート
警告時にスクリプトを実行する可能性はありますか？

Dockerイメージにアラートブランチはもうありますか？

1. アラートクエリはクエリ「A」に対してのみ機能しますか？ これはハードコーディングされていますか？
2. 完全に機能するアラートバージョンはいつ期待できますか？ （19番目はまだターゲット）
3. Elasticsearchがアラートで機能することをいつ期待できますか？

編集：

1. グラフごとに複数のアラームルールを追加できますか？
2. アラームに関する情報をHTTPメッセージに追加できますか？ （ダッシュボード/グラフ/ observed_query / alarm_config / alarm_query / threshold / warn_or_crit / value / observed_timeframe / time_of_occurence）

@ DEvil0000

1）[メトリック]タブにある任意のクエリに変更できます。
2）完全に機能します。意味によって異なります。 今週はそれを統合してマスターする予定です。 その後、人々はナイトリービルドのテストを開始してフィードバックを提供できます。 2〜3週間以内のアルファ版リリース、ベータ版と安定版のリリースは、フィードバックと、どれだけ早く安定するかによって異なります。
3）Elasticsearchはトリッキーで、応答を時系列にクエリして解析するために多くのコードを必要とするため、PrometheusとInfluxDBのサポートが追加された後に来る可能性があります

@torkelo
私はelasticsearch、grafanaに不慣れで、langに行きます。 そして、あなたはすでにクライアントを検索していると思いますが、それらを見たことがありますか？
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
それらのライブラリは労力を減らすかもしれません。

また、これに取り組んでいる隠されたエルフが誰であるかに感謝します。 @Dieterbeだと思いますが、わかりません。

アラートは現在、主に@torkeloと@bergquist （および@mattttt ）です。 今後のグラファイトバックエンドhttps://github.com/raintank/metrictankにフォーカスを切り替えました

この機能が進歩しているのを見てとてもうれしいです。 他のアラートソリューション（Bosun）は、ここで定期的に使用するにはユーザーフレンドリーではないため、OpenTSDBのサポートが必要です。

次の公式バージョンでアラームが表示され、コーディングに熱心に取り組んできたプログラマーに敬意を表したいと思います。

次の公式バージョンでアラームが表示され、コーディングに熱心に取り組んできたプログラマーに敬意を表したいと思います。

@superbool申し訳ありませんがこれを読むことができず、グーグル翻訳はあまり役に立ちませんでした

マスターへのマージは8月19日までに行われます、私は約束します:)

@torkelo hehe次回賭けます。新しい日付はありますか？

OpenTSDBのアラートがスケジュールされることを期待できますか？
（控えめな）開発者を奨励するための設立。

2016年8月22日10時05分GMT + 02：00 A. Binzxxxxxx [email protected] ：

次の公式バージョンでアラームが表示され、コーディングに熱心に取り組んできたプログラマーに敬意を表したいと思います。

@superbool https://github.com/superbool申し訳ありませんが、これを読むことができず、
グーグル翻訳はあまり役に立ちませんでした

マスターへのマージは8月19日までに行われます、私は約束します:)

@torkelo https://github.com/torkelo hehe次回賭けます。ありますか？
新しい日付？

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment -241340597、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
。

@ DEvil0000アラート機能が次の安定したGrafanaバージョンで公開されることを期待しており、ツールを開発するすべての人に敬意を表したいと思います。
申し訳ありませんが、私の英語はあまり上手ではありません、あなたが私の言葉を理解できることを願っています

@ DEvil0000先週の金曜日にマージする予定でしたが、計画外のイベント（https://twitter.com/torkelo/status/766514688997732352）のため、少し延期する必要がありました:)まだやるべきことがいくつかあります。

@torkeloおめでとうございます！
@bergquist @torkelo 10月までにエラスティックでアラートを

これで、アラートブランチがマスターにマージされました。 ：raised_hands：

この号から寄せられたすべてのフィードバックに感謝します。 みなさん、ありがとう！
今後の議論とフィードバックのために、対応するアラートの問題に投稿するか、新しい

では、次は何ですか？

• アルファリリース（ドキュメントとブログ投稿）
• コミュニティからフィードバックを収集します。
• 警告のために残りのます
• 警告付きでGrafana4.0をリリースします。

やってみて？

• あなたにはアラートを有効にする必要があります設定。
• サイドメニューにアラートが表示されるようになりました。
• グラフパネルに移動して[アラート]タブを選択すると、アラートを追加できます。
• _Test alert_ボタンを使用して、アラートを確認します。
• アラートを保存するには、ダッシュボードを保存する必要があります。
• アラートの発生について通知されるように/ alerting / notificationsに通知を設定します。
• アラートタブのアラートに通知機能を追加します。

現在の制限

• これまでのところ、グラファイトのみをサポートしています。
• このリリースでは、グラフパネルのみがアラートをサポートしています。

ダッシュボードの例

サンプルダッシュボードは、examplesフォルダーにあります。
ダッシュボードの例は、偽のグラファイトデータライターからのデータに基づいています。 docker-composeファイルからgraphiteとfake-data-writerを起動できます。

cd docker/
./create_docker_compose.sh graphite
docker-compose up

これは大まかなガイドと見なす必要があり、今後数週間でアラートに関するドキュメントを追加する予定です。

ハッピーアラート！ ：カクテル：：多田：

@bergquistおめでとうございます。

この機能の将来について私たちがフォローできる問題はありますか？

@ Workshop2 https://github.com/grafana/grafana/issues/5858

1つのパネルに「上にある」または「下にある」を追加するためのアラート条件には「AND」のみがあり、「OR」はありません。これをサポートする他の方法はありますか？

「範囲外」/「範囲内」のオプションがあると思います。 しかし、私は「または」も見たいです。

皆さんこんにちは！ この便利な機能にご協力いただき、ありがとうございます。

それは私にとって本当に興味深いことですが、多くの場合、1つのグラフに複数のアラートを作成する可能性がないため、アラート条件に「OR」が必要になります。

その「OR」がないと、この種のグラフのアラートを作成できないと思います。

何か案が？ 「OR」オプションを追加する予定ですか？

BR

@jmgonzalezpはい、ORもサポートしたいと考えています（ANDとORの混合についてはまだ

フィードバックが必要であることを警告するための設計上の決定が2つ残っています（分類、および重大度/状態）。

これが私たちの現在の考えの問題であり、あなたのフィードバックを本当に感謝します。
https://github.com/grafana/grafana/issues/6007

こんにちは、みんな！ grafanaのこのような素晴らしい機能に感謝します！

このアラートシステムについて質問があります。 現在、AWSで自動スケーリンググループを使用してgrafanaをデプロイしていますが、複数のマシンでgrafanaを実行すると、問題が発生しますか？ 私が言及している問題は、複数のgrafanaマシンから複数の同じアラートが発生するかどうかです。 または、grafanaはすでにそれを処理していますか？

@ torkelo @ akurniawanと同じ質問があります。 この設定について考えてみましょう。1つのロードバランサー、ロードバランサーの背後にある3つのGrafanaインスタンス、3つのインスタンスすべてが共有する1つのMysqlDB。 このタイプのセットアップでは、Grafanaサーバーはアラートをどのように処理しますか？ その場合、1つのインスタンスでのみアラートを有効にする必要がありますか、それともGrafanaがアラートを追跡して、複数のノードが同じアラートをチェックして送信しないようにする必要がありますか？

@utkarshcmu @akurniawan grafana内のアラートは、まだHAをサポートしていません。 将来的には、サーバー間でアラートを分割するためのサポートを追加する予定です。

@bergquist回答ありがとうございます。 :)

@bergquist InfluxDBサポートがいつ追加されるかについてのETAはありますか？

@thisisjaidはこのhttps://github.com/grafana/grafana/milestone/40で判断すると、10日にここにあるはずです。

@Dieterbe OpenTSDBのサポートを警告するためのETAはありますか？

@sofixaありがとう、

@Dieterbe OpenTSDBのサポートを警告するためのETAはありますか？

私はもう警告に取り組んでいません。 多分@torkeloまたは@bergquistが答えることができます。

@torkelo @bergquist

OpenTSDBのサポートを警告するためのETA

@LoaderMick @ naveen-tirupattur OpenTSDBアラートがGrafanaに追加され、次のリリースの一部になるはずです。 また、OpenTSDBのアラートはナイトリービルドで機能しています。

influxDBとprometheusのサポートを警告するためのETAもありますか？

両方のデータソースに対する@nnsalnアラートは、すでにマスターブランチにあります。

（Grafana v4.0.0-pre1（commit：578507a））を使用してOpenTSDBでアラートを機能させることができないようです。 電子メールシステム（動作中）をテストしましたが、しきい値が非常に低い場合でもアラートが発生しません。 クエリを手動で実行して、プルしているデータを確認する方法はありますか？

Grafana v4.0.0-pre1（コミット：9b28bf2）
エラーtsdb.HandleRequest（）エラーInfluxdbがステータスコードを返しました無効なステータスコード：400不正なリクエスト

@torkelo
「webhookアラート通知」はアラートメトリック、json、またはフォームタイプを投稿できますか？

こんにちは皆さん、Grafanaはテンプレート変数を使用したクエリのアラートをサポートしますか、それともこれのターゲットリリースはありますか？

すべて、4.0ベータ版をお試しください。 何かが足りない場合は、新しい問題を開いてください。

リチャード

モバイルで送信。 簡潔に申し訳ありません。

4.0ベータ版を試しましたが、それでもこのエラーが発生します
エラーtsdb.HandleRequest（）エラーInfluxdbがステータスコードを返しました無効なステータスコード：400不正なリクエスト

アラート通知を保存できません-送信先、保存後、送信先の行が再び空白になります

@nnsalnメールアドレスではなく、通知ターゲットを

アラートとともにテンプレート変数をサポートする計画はありますか？ 私がやります
（またはセットの）テンプレート変数によって生成された各グラフを理解する
別のグラフに変換するため、静的な値に対してアラートを生成します。
正しくありません。

2:06で月、2016年12月5日には、トマス・バートン[email protected]
書きました：

@nnsalnhttps ：//github.com/nnsaln通知を入力することになっています
メールアドレスではなく、そこをターゲットにします。 grafanaサイドメニューを開き、カーソルを合わせます
[アラート]メニューオプションをクリックし、[通知]メニューオプションをクリックします。 三
アラートルールから使用できる通知ターゲットを設定できます。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
。

-
ディーパック

いいえ、現在これを行うためのサポートはありません。 多分遠い将来ですが

ダッシュボードの99％はテンプレート変数を使用しています。 それらはテンプレートで設計されました
「ダッシュボードの爆発」の問題を回避するための変数。

20:20時月、2016年12月5日には、TorkelÖdegaard [email protected]
書きました：

いいえ、現在これを行うためのサポートはありません。 多分遠い将来ですが

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
。

-
ディーパック

はい。ただし、一般的な探索ダッシュボードは、アラートルールのダッシュボードデザインと同じではありません。

これまでのところ、直感的で理解しやすい方法でテンプレート変数をサポートする方法についての提案はありませんでした。 変数を使用してクエリにアラートを送信するにはどうすればよいですか？ 現在保存されている変数値で補間しますか？ すべての値を個別のルールとして扱い、すべての状態を維持する必要があります。テンプレート変数をサポートすると、複雑さと潜在的に混乱する動作のためにワームの缶が開かれます。 誰かがシンプルで理解しやすい方法を思いついたら、いつか追加されるかもしれません。

それまでの間、個別のアラートダッシュボードを作成することを妨げるものは何もありません。
アラートは新しく、grafanaに大幅に追加されました。 それは時間内に進化します、
しかし、実装された短い時間で、それはgrafanaに大きな価値を追加しました。
そして、そのためのすべての貢献者に感謝します！

午前06.12.201611：14nachm。 schrieb "TorkelÖdegaard" <
[email protected]>：

はい。ただし、一般的な探索ダッシュボードはダッシュボードと同じではありません。
アラートルールの設計。

これまでのところ、テンプレート変数をサポートする方法についての提案はありませんでした
直感的で理解しやすい方法で。 変数でクエリに警告するもの
NS？ 現在保存されている変数値で補間しますか？ それが必要
すべての値を個別のルールとして扱い、すべての状態を維持します。
テンプレート変数は、複雑さと潜在的にワームの缶を開きます
紛らわしい行動。 誰かが思いついた場合、いつか追加されるかもしれません
シンプルでわかりやすい方法。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
。

+1トーケル。

アラートはかなり複雑になります。

2時14分PMの火、2016年12月6日には、TorkelÖdegaard [email protected]
書きました：

はい。ただし、一般的な探索ダッシュボードはダッシュボードと同じではありません。
アラートルールの設計。

これまでのところ、テンプレート変数をサポートする方法についての提案はありませんでした
直感的で理解しやすい方法で。 変数でクエリに警告するもの
NS？ 現在保存されている変数値で補間しますか？ それが必要
すべての値を個別のルールとして扱い、すべての状態を維持します。
テンプレート変数は、複雑さと潜在的にワームの缶を開きます
紛らわしい行動。 誰かが思いついた場合、いつか追加されるかもしれません
シンプルでわかりやすい方法。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
。

-
ディーパック

このコメントに関する@bergquist

grafana内のアラートはまだHAをサポートしていません。 将来的には、サーバー間でアラートを分割するためのサポートを追加する予定です。

進捗状況を追跡するためのチケットはありますか？ 貢献するブランチはありますか？

そして、素晴らしい仕事に感謝します！

カーン、

<3グラファナ。

テンプレートを使ってアラートに関する考えを共有しようとしていました
ダッシュボード。

2016年12月9日金曜日午前2時53分、ドミトリー・ジューコフ[email protected]
書きました：

このコメントに関する@bergquisthttps ：//github.com/bergquist

grafana内のアラートはまだHAをサポートしていません。 私たちの計画は追加することです
将来的にサーバー間でアラートを分割するためのサポート

進捗状況を追跡するためのチケットはありますか？ 貢献するブランチはありますか？

そして、素晴らしい仕事に感謝します！

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
。

-
ディーパック

@torkelo @DieterbeついにGrafanaにアラートが組み込まれたのは素晴らしいことです！ プログラムでアラートを作成するための推奨される方法（ある場合）は何ですか？

@jaimegagoは、ダッシュボードAPIを使用してプログラムでアラートを作成します。アラートは、パネルとダッシュボードとともに保存されます。

@torkelo通知ターゲットはどうですか（たとえば、APIを介して新しい通知メールを作成します）？

編集：ここで自分自身に答えると、api / alert-notificationsエンドポイントが見つかりました。 文書化する必要があると思います

もちろん、そのためのhttp apiがあります。アラート通知ページに移動し、通知を追加して、grafanaが行うhttpapi呼び出しを確認してください。

@torkelo 、プログラムでアラートを作成するために使用できるAPIはありますか（アラート通知を作成するのではありません）

@CCWeiZ Alertsは、ダッシュボードjsonの一部です。 したがって、アラートのみではなく、アラートを含むダッシュボードのみを作成できます。

ダッシュボードAPIの詳細については、 http： //docs.grafana.org/http_api/dashboard/をご覧ください。

これは利用可能ですか：値が3日前と比較して、値が増加していない場合にアラートを設定したいと思います。 （要求を言います。現在の値が-3日前の要求が100未満の場合、要求はあまりないと言います。） これを行う方法？