Grafana: [Funktionsanfrage] Mehrere Warnungen pro Diagramm

Konkreter Anwendungsfall: Ich habe meine App instrumentiert, um ein Histogramm in Prometheus für jede wichtige Funktion aufzuzeichnen (z. B. wo ein externer HTTP-Aufruf oder ein Festplatten-I/O stattfindet) und möchte warnen, wenn eine dieser langsam wird.

Wegen der 1:1-Beziehung zwischen Graph und Alert muss ich dafür derzeit Dummy-Graphen definieren. Es wäre viel logischer, die Warnungen an der gleichen Stelle wie das Diagramm selbst zu definieren.

Und Sie können das nicht in einer Abfrage definieren?

Nein; eine Kette von OR -Bedingungen ist grob, und der einzelne Name der Warnung kann den genauen Grund für die Warnung nicht eindeutig identifizieren. Ich möchte definitiv keine Benachrichtigungen nach dem Muster von Some part of service X is failing senden - Ingenieure auf Abruf wären nicht meine Freunde ...

dann ist es sinnvoller, separate Bedienfelder für die Warnungen zu haben, wenn Sie getrennte Namen und Nachrichten für Warnungsregeln usw. wünschen.

Ja, genau das mache ich im Moment. Besteht die Wahrscheinlichkeit, dass in naher Zukunft mehrere Warnungen pro Diagramm implementiert werden, sodass ich von dieser Problemumgehung wegkommen kann?

es ist sehr unwahrscheinlich

Vielleicht, wenn es eine große Nachfrage danach gibt :)

haha OK - Ich werde sehen, ob ich einen wütenden Mob aufstacheln kann ;) Im Ernst, danke für die Ehrlichkeit.

Ok, wir haben einen Mob von zwei :-) Ich zeichne den Kraftstoffstand in mehreren Tanks grafisch auf und wollte für jeden Tank einen Alarm für niedrigen Kraftstoffstand einrichten.

und jeder Tank hat unterschiedliche Schwellenwerte oder Benachrichtigungen?

Exakt. Einer ist ein 285-Gallonen-Heizöltank. Ich wollte einen Alarm "Heizöl niedrig" einrichten, wenn dieser Tank unter 70 Gallonen fällt. Der andere ist ein 500-Gallonen-Propantank, dafür wollte ich einen "Propan-Niedrig" -Alarm, wenn er unter 100 Gallonen fällt. Ich habe Singlestats für jeden eingerichtet, aber Warnungen sind in einem Singlestat nicht verfügbar.

Ich habe ein Diagramm mit einem Median und einer 90. Perzentil-Metrik. Ich möchte jeweils eine Benachrichtigung erhalten. Dazu muss ich jeweils ein Diagramm erstellen. Wenn ich dann Warnungen und kritische Warnungen für jeden haben möchte, muss ich für jeden einen zweiten Graphen erstellen.

Ich habe 30 oder 40 Dienste zu überwachen, jeder mit 2 bis 5 Schlüsselmetriken. Ich habe Diagramme, in denen ich dieselbe Metrik für mehrere Kunden grafisch darstelle, und obwohl ich (noch) keine Benachrichtigungen pro Kunde durchführen muss, erhöht dies die Anzahl der Metriken, für die ich Benachrichtigungen haben möchte. Der Arbeitsaufwand zum Erstellen von Dutzenden von Diagrammen nimmt sehr schnell zu. In meiner aktuellen Produktionsumgebung (und in meinen früheren Produktionsumgebungen) wäre es sehr nützlich, Warnungen und kritische Warnungen zu haben und mehrere Metriken in einem einzigen Diagramm anzuzeigen und darauf zu warnen.

Diese Funktion würde ich auch gerne sehen. Ein gutes Beispiel ist eine Warnung, wenn eine Metrik einen Schwellenwert überschreitet, und eine andere Warnung, wenn Daten nicht aktualisiert werden. Das heißt, wenn ein Wert zu hoch wird oder wenn Werte nicht gemeldet werden. Dies könnte verwendet werden, um zu zeigen, dass das, was auch immer die Daten meldet, auf ein Problem gestoßen ist, das die Kommunikation mit grafana (oder einem beliebigen Backend) verhindert.

Hallo Torkelo!

Ich habe mehrere "Gefällt mir" für das Feature bekommen! Werden wir in die nächste Veröffentlichung einsteigen =) ?

@rmsys vielleicht wird es irgendwann Zeit brauchen, es aus der Perspektive der UX und der Codekomplexität (und der UX-Komplexität) zu lösen, es steht noch auf keiner Roadmap, aber vielleicht nächstes Jahr, wenn die Alerting-Engine weiter ausgereift ist und ein UX-Design dafür erarbeitet wird aus

Ein weiterer guter Anwendungsfall für mehrere Warnungen sind unterschiedliche Schweregradschwellenwerte mit unterschiedlichen Aktionen. Wenn ein Server langsamer wird, kann eine E-Mail ausreichen, aber wenn die Verlangsamung extrem wird, kann es sich lohnen, den Administrator anzurufen.

Ich habe ein Diagramm, das eine Metrik mit dem Wert valid und invalid zurückgibt. Dies wäre für mich nützlich, da ich ein einzelnes Diagramm mit zwei Abfragen verwenden könnte, um Warnungen zu erstellen, die ausgelöst werden, wenn valid zu niedrig und invalid zu hoch sind.

Außerdem ist es nicht immer vorzuziehen, separate Zustände einer Warnung zu verfolgen (da der Endbenutzer die Details hinter den einzelnen Zuständen kennen müsste), anstatt nur zu wissen, ob eine Warnung ausgelöst wird.

Ich bin mir nicht sicher, ob ich verstehe, was Sie damit meinen. Können Sie das näher erläutern?

Können Sie beschreiben, wie mehrere Warnungen pro Diagramm funktionieren und aussehen würden? Was würden die Anmerkungen sagen und das grüne/rote Herz neben dem Titel des Panels zeigen (wenn sagen wir, 2/5 Alarmregeln würden feuern)?

Möchten Sie etwas zwischen den Warnregeln teilen oder wären sie vollständig isoliert (außer dass sie im selben Diagrammbereich leben und möglicherweise auf dieselben Abfragen verweisen).

Wie würden Sie Schwellenwerte visualisieren, wenn Sie mehrere Warnungsregeln haben? Würden sie als separate Regeln auf der Seite „Warnungsregeln“ und im Fenster „Warnungsliste“ angezeigt? Dann benötigen Sie eine Möglichkeit, zu einer bestimmten Instanz einer Regel zu navigieren und nicht nur zur Registerkarte „Warnung“.

Grafana ist ein visuelles Tool, und wir haben uns dafür entschieden, eine Warnregel mit einem Diagramm zu verknüpfen, damit der Zustand der Warnregel leicht visualisiert werden kann (über die Metriken, Schwellenwerte und den Verlauf des Warnzustands). Ich befürchte, dass die Tatsache, dass jedes Diagramm mehrere Warnregeln darstellen kann, dies sehr erschweren wird, und ich bin mir nicht sicher, ob dies erforderlich ist.

@rssalerno , das Warnungsregeln im Singlestat-Panel unterstützt, scheint nichts mit diesem Problem zu tun zu haben.

@alex-phillips Ihr Szenario klingt so, als könnte es gelöst werden, indem einzelne Alarmregeln flexibler gestaltet werden.

Hat jemand ein paar konkrete Beispiele, wo das gut wäre? Nur kein Szenario zu sehen, in dem es in einem verwirrenden Diagramm mit 2-5 Schwellenwerten enden würde, von denen Sie nicht wissen, dass sie sich auf die Metrik- und Warnungsverlaufsanmerkungen beziehen, von denen Sie auch nicht wissen, aus welcher Warnungsregel sie stammen (ohne zu schweben).

Können Sie beschreiben, wie mehrere Warnungen pro Diagramm funktionieren und aussehen würden? Was würden die Anmerkungen sagen und das grüne/rote Herz neben dem Titel des Panels zeigen (wenn sagen wir, 2/5 Alarmregeln würden feuern)?

Ich denke, mehrere Alarmregeln würden einzeln kommentiert. Herzen können farbcodiert sein. Zur Unterscheidung in Alerts/Panels müssten Regeln benannt werden.

Möchten Sie etwas zwischen den Warnregeln teilen oder wären sie vollständig isoliert (außer dass sie im selben Diagrammbereich leben und möglicherweise auf dieselben Abfragen verweisen).

Im Allgemeinen würde ich nicht denken, obwohl ich vermute, dass Gruppen einen gemeinsamen Schwellenwert und Namen haben müssten, wenn sie implementiert würden (per https://github.com/grafana/grafana/issues/6557#issuecomment-324363795).

Wie würden Sie Schwellenwerte visualisieren, wenn Sie mehrere Warnungsregeln haben? Würden sie als separate Regeln auf der Seite „Warnungsregeln“ und im Fenster „Warnungsliste“ angezeigt? Dann benötigen Sie eine Möglichkeit, zu einer bestimmten Instanz einer Regel zu navigieren und nicht nur zur Registerkarte „Warnung“.

Wenn Regeln einen zusätzlichen Farbparameter haben, können Schwellenwerte damit gerendert und als solche unterschieden werden, wahrscheinlich möchten Sie auch einen Tooltip. In der Lage zu sein, Regeln umzuschalten, wäre nützlich, und ein Parameter zum Rendern einer bestimmten Regel kümmert sich um Letzteres, denke ich?

@rssalerno , das Warnungsregeln im Singlestat-Panel unterstützt, scheint nichts mit diesem Problem zu tun zu haben.

Ich glaube, Sie werden feststellen, dass er sich auf die Grafik unten bezog, obwohl er separate Panels für jeden Tank hat, könnte Singlestat Alerting sein Problem für dieses spezielle Dashboard lösen.

Hat jemand ein paar konkrete Beispiele, wo das gut wäre? Nur kein Szenario zu sehen, in dem es in einem verwirrenden Diagramm mit 2-5 Schwellenwerten enden würde, von denen Sie nicht wissen, dass sie sich auf die Metrik- und Warnungsverlaufsanmerkungen beziehen, von denen Sie auch nicht wissen, aus welcher Warnungsregel sie stammen (ohne zu schweben).

In erster Linie möchte ich, dass dies # 6557 und # 6553 unterstützt, und für mehrere Schwellenwerte, ähnlich wie bei @alex-phillips. Ein Anwendungsfall, den wir beispielsweise für #6557 haben, besteht darin, für verschiedene Umgebungen ( production , beta , dev usw.) unterschiedliche Warnungen bereitzustellen, kombiniert mit mehreren Schwellenwerten, die dies tun würden die meisten unserer Probleme lösen. Wenn es einen besseren Weg gibt, dies ohne mehrere Regeln zu tun, ist es mir nicht klar.

@Torkelo

Können Sie beschreiben, wie mehrere Warnungen pro Diagramm funktionieren und aussehen würden? Was würden die Anmerkungen sagen und das grüne/rote Herz neben dem Titel des Panels zeigen (wenn sagen wir, 2/5 Alarmregeln würden feuern)?

Ich mag den von @pdf vorgeschlagenen Ansatz

Darüber hinaus wäre der Ansatz zum Anzeigen von Anmerkungen derselbe wie im aktuellen Fall, in dem Sie eine Warnregel mit > 1 Bedingungen haben (jede mit einem anderen Schwellenwert). Und das grüne/rote Herz neben dem Panel-Titel wird rot angezeigt (wenn mindestens eine Warnung ausgelöst wird), ähnlich dem aktuellen Szenario, in dem mindestens eine Bedingung einer Warnungsregel als wahr bewertet wird). Und wahrscheinlich auch die Zahl (2/5) zusammen mit dem roten Herz im Titel zeigen.

Möchten Sie etwas zwischen den Warnregeln teilen oder wären sie vollständig isoliert (außer dass sie im selben Diagrammbereich leben und möglicherweise auf dieselben Abfragen verweisen).

In den meisten unserer Anwendungsfälle teilen diese Regeln nichts miteinander und die Abfragen sind auch unterschiedlich

Wie würden Sie Schwellenwerte visualisieren, wenn Sie mehrere Warnungsregeln haben? Würden sie als separate Regeln auf der Seite „Warnungsregeln“ und im Fenster „Warnungsliste“ angezeigt? Dann benötigen Sie eine Möglichkeit, zu einer bestimmten Instanz einer Regel zu navigieren und nicht nur zur Registerkarte „Warnung“.

Sie würden als separate Regeln auf der Seite „Warnungen“ angezeigt. Auf der Registerkarte "Warnung" wäre wahrscheinlich eine Liste von Warnungen definiert. Richtig, wir müssten die spezifische Warnregel auf dieser Registerkarte hervorheben/erweitern, wenn von der Benachrichtigung aus auf die URL der Warnregel (sollte die Warn-ID oder den Index erfassen) zugegriffen wird. Scheint leicht lösbar zu sein.

In der Benachrichtigungsliste würde es keine Änderung geben. Es zeigt alle einzeln an. Semantisch ist jede Warnung separat. Nur dass es im selben Panel platziert wurde.

Hat jemand ein paar konkrete Beispiele, wo das gut wäre? Nur kein Szenario zu sehen, in dem es in einem verwirrenden Diagramm mit 2-5 Schwellenwerten enden würde, von denen Sie nicht wissen, dass sie sich auf die Metrik- und Warnungsverlaufsanmerkungen beziehen, von denen Sie auch nicht wissen, aus welcher Warnungsregel sie stammen (ohne zu schweben).

Wenn man bedenkt, dass viele Leute für diese Funktion gestimmt haben, wäre es definitiv eine nützliche Funktion. Wenn wir die Unterstützung für mehrere Warnungen haben, dann denke ich, dass es an der Wahrnehmung jedes Benutzers liegt, ob es verwirrend ist oder nicht. IMHO, diejenigen, die denken, dass es verwirrend ist, würden sich für den aktuellen Ansatz separater Panels für jede Grafik entscheiden, und diejenigen, die denken, dass der Nutzen/die Bequemlichkeit, dasselbe Panel für die Visualisierung und Alarmierung zu verwenden, die wahrgenommene Verwirrung überwiegen, werden den Weg mit mehreren Warnungen gehen . Sicher, es würde die UX etwas verändern

In Splunk haben wir High/Low-Warnungen. Wenn mehrere Benachrichtigungen in Grafana verfügbar sind, verwenden wir einfach dieselbe Suche, es handelt sich lediglich um unterschiedliche Schwellenwerte für dieselbe Suche.

+1 für diese Funktion.

+1 dafür. Unser Anwendungsfall ist wie folgt: Wir möchten ein Diagramm mit beispielsweise der CPU-Auslastung für alle unsere Server definieren. Dann erstellen wir auf demselben Diagramm zwei versteckte Metriken, eine für die CPU-Nutzung auf Produktionsservern und eine für die CPU-Nutzung auf Nicht-Produktionsservern. Jede dieser Metriken hätte ihre eigene Warnung mit unterschiedlichen Benachrichtigungskanälen. Wir möchten nicht mehrere Diagramme oder Panels oder Dashboards erstellen müssen, um dies zu erreichen.

+1 für diese Funktion.

Kam hierher, um einige der anderen Probleme in Bezug auf Kategorien und Schweregrade zu lesen. Ich stimme zu, dass alle Warnungen umsetzbar sein sollten. Aber es gibt einen Unterschied zwischen einer „Repariere das gleich morgen früh“-Warnung und einer „Ruf den $400/Stunde-Berater so schnell wie möglich“-Warnung.

Wie viele bereits erwähnt haben, wird dies am häufigsten durch Warnungs- und kritische Schwellenwerte gelöst.

Technisch könnte dies auf verschiedene Arten implementiert werden, Labels, mehrere Warnungen pro Panel, mehrere Schwellenwerte pro Warnung usw.

Um Verwirrung zu stiften, wenn die Kategorisierung zu komplex ist, kann ein Warnung/Kritisch-Setup einfach Rot/Gelb verwenden. Rot überschreibt Gelb.

Bei komplexeren Setups könnte eine andere Option neben dem Schweben zum Auffinden der störenden Zeitreihen eine blinkende Linie/Fläche/was auch immer sein? Das könnte die Aufmerksamkeit auf die richtige Zeitreihe leicht lenken.

Ich denke, die meisten Benutzer wären jedoch mit einer ziemlich einfachen Warn/Crit-Trennung zufrieden.

Dies ist ein absolutes Muss für eine Alarmierungssoftware, insbesondere für die Serverüberwachung. Speicherplatz, Arbeitsspeicher, CPU-Auslastung, Temperatur, Lastdurchschnitt ... alles gute Beispiele, bei denen man mehrere Warnungen mit unterschiedlichen Nachrichten mit unterschiedlichen Schwellenwerten konfigurieren möchte. Nehmen Sie zum Beispiel Speicherplatz. Benötigen Sie eine Warnung für eine Festplattennutzung von über 70 % und eine weitere für eine Festplattennutzung von über 90 %.

Das ist zwar ein Grenzfall, aber wir verwenden die Benachrichtigungen, um uns zu benachrichtigen, wenn ein Produkt in ein paar Tagen nicht verkauft wurde. Wir haben jedes Produkt als Metrik, was wiederum bedeutet, dass wir nur eine Warnung erhalten, wenn eine der Metriken den Warnschwellenwert erreicht. Idealerweise möchten wir eine Benachrichtigung erhalten, wenn die Benachrichtigung zeigt, dass eine zusätzliche Metrik ebenfalls den Warnschwellenwert erreicht hat.

Außerdem verwenden wir Templating-Variablen, um ein Diagramm für jedes ausgewählte Produkt mit zwei überlagerten Metriken (Volumen und Bruttomarge) auf der linken und rechten Y-Achse zu wiederholen. Dadurch wird jede Möglichkeit der Verwendung von Warnungen zunichte gemacht, da die Warnungsabfrage die Listenvariable $sku für unsere IN ($sku) nicht aufnimmt.

Um dies zu umgehen, habe ich versucht, eine andere Abfrage B zu verwenden, die einfach die Vorlagenabfrage ausführt, um alle Skus nachzuschlagen, an denen wir interessiert sind, und diese direkt in die Warnabfrage IN (SELECT skus from interested_product_table) einfügt. Dies beginnt jedoch damit, uns Warnungen für jedes Diagramm für alle Metriken in jedem Diagramm zu senden, was bedeutet, dass wir Folgendes erhalten:

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

Zum Beispiel, was ziemlich spammy ist.

Stimmen Sie voll und ganz zu, dass die Funktion ein Muss ist, und stimmen Sie überhaupt nicht zu, dass ALLE Benachrichtigungen umsetzbar sein sollten.

Das einfachste Beispiel ist, dass Sie möglicherweise Warnungen erhalten und so schnell wie möglich Maßnahmen ergreifen müssen, z. B. am nächsten Morgen, während es andere Arten von Warnungen gibt, die Sie sogar mitten in der Nacht aufwecken sollten, um Produktionsserver zu reparieren.

Ich gebe meinen Senf dazu - ich hätte diese Funktion gerne.

Ich brauche nicht einmal unterschiedliche Herzen oder verschiedenfarbige Herzen (rot für jede Warnung auf dem Diagramm ist in Ordnung), es sind die E-Mail-Benachrichtigungen, für die ich unterschiedliche Namen haben möchte.

Bitte fügen Sie diese Funktion hinzu. für einen solchen Anwendungsfall
aus einem einzigen Graphen
wenn Wert > X --> Schlupf
wenn Wert > X+Y --> PD

Wir haben hier eine Richtlinie für umsetzbare Warnungen, bei der die Warnung nach Möglichkeit die zu ergreifende Aktion angeben sollte. Wir müssen verschiedene Maßnahmen ergreifen, wenn die Messwerte zu niedrig oder zu hoch sind.

Zum Beispiel: RDS-CPU zu niedrig? Überprüfen Sie den anderen Stack hier auf Verhalten. Zu hoch? Skalieren Sie die Instanz hoch.

Wie bei anderen möchten wir auch verschiedene Arten von Warnungen bei unterschiedlichen Schwellenwerten haben.

Ähnlich wie bei @jdblack möchte ich eine Hochwasser-Warnstufe und eine Hochwasser-Notfallstufe haben. Ich weiß, dass ich es mit zwei Abfragen machen kann, aber es ist nicht so intuitiv oder raffiniert.

Ich habe darüber nachgedacht, Grafana als Signal für ein Autoscaling-System zu verwenden. Wenn die Metrik zu niedrig ist, senden Sie einen Webhook mit einer Nachricht zum Verkleinern, wenn sie zu hoch ist, senden Sie einen Webhook mit einer Nachricht zum Verkleinern. Ohne mehrfache Warnungen ist dies meines Erachtens nicht möglich. Ich stimme auch anderen im Thread zu, dass der Anwendungsfall für eine "Warnung" dann eine "kritische" Schwelle ist.

Vielleicht sollte die Idee, die Warnungen mit einem Diagramm zu koppeln, noch einmal überdacht werden? Vielleicht sollten Warnungen separat erstellt werden, mit einem schönen Vorschaudiagramm beim Erstellen der Warnung. Diese Entkopplung könnte es einfacher machen, eine Diagrammmetrik zu ändern, aber zumindest wäre es flexibler, mehrere Warnungen zu erstellen.

Ich habe versucht, Grafana + Influx für Sensornetzwerke zu verwenden. Die Dashboards funktionieren ziemlich gut, mit Ausnahme von Warnungen. Ich muss benachrichtigt werden, wenn Sensor123 einen bestimmten Schwellenwert überschreitet. Dafür brauche ich kein Diagramm, nur einen Alarm. Außerdem muss ich möglicherweise Tausende von Sensoren haben. Ich kann einen Alarm einrichten, wenn "irgendein" Sensor den Schwellenwert überschreitet, aber ich muss wissen, welcher (welche) alarmieren. Ich habe Dashboards mit Vorlagenvariablen eingerichtet, um einen bestimmten Sensor anzuzeigen, aber ich kann keine Warnung für eine Vorlagenvariable hinzufügen. Zum Testen richte ich einfach eine Handvoll Warnungen für eine Handvoll Sensoren in einem zusätzlichen Dashboard ein, das niemand ansieht, aber für die Zukunft brauche ich eine andere Lösung für Warnungen.

@torkelo , es nähert sich ein Jahr seit einem offiziellen Kommentar dazu - ich frage mich nur, ob es irgendwelche Updates gibt, die geteilt werden können, nachdem das Warnsystem seit einiger Zeit in freier Wildbahn ist?

@MakoSDV Sie sollten in Betracht ziehen, kapacitor für diesen Anwendungsfall zu verwenden.

+1 für diese Funktion; es wäre auch für zweistufige Alarmierung sehr nützlich (z. B.: etwas > X = gelber Alarm, etwas > Y = roter Alarm)

+1, um die Alarmierung flexibler zu gestalten

Ich überwache Temperaturdiagramme in einem Heizkessel, die niedrige Temperaturschwelle ist trivial und muss an einen unkritischen Benachrichtigungskanal gehen, aber die hohe Temperatur ist dringend und muss über den dringenden Kanal summen. Mehrere Alert-Regeln wären hier sehr sinnvoll.

Schade, dass dieses Thema aufgegeben scheint. Weiß jemand, wie wir Entwickler darauf aufmerksam machen können?

Es scheint, als wäre es in Bezug auf die Benutzeroberfläche vergleichsweise einfach, Warnungen so zu implementieren, wie Überschreibungen implementiert werden, um eine oder mehrere Warnungen ohne große Änderungen an der Benutzeroberfläche zuzulassen.

@Gaibhne schrieb:

Weiß jemand, wie wir Entwickler darauf aufmerksam machen können?

Vielleicht für den Support bezahlen? Es scheint, als seien keine Ressourcen für die schwerwiegenden Mängel im Zusammenhang mit Warnungen verfügbar gewesen, obwohl sie seit Jahren die am höchsten von Github-Benutzern bewerteten Probleme sind.

+1 für diese Anfrage.

Wir haben in unserer App einen Zähler eingerichtet, wenn eine Anfrage an einen externen Dienst, den wir integrieren, mit Timeouts abläuft, für die wir in Grafana ein Diagramm erstellt haben.

Wenn es ein paar Zeitüberschreitungen gibt, würden wir gerne wissen, damit wir den externen Dienst später darauf aufmerksam machen können. Wenn es viele Zeitüberschreitungen gibt, bedeutet dies, dass unsere App wahrscheinlich für die meisten Kunden betroffen war, also müssen wir reagieren und sich sofort darum kümmern.

+1 auch dafür.

Versuchen Sie derzeit, zwei separate Warnungen für ein Diagramm einzurichten:

1. Slack-Meldung für Daten, die eine _Warnung_- Stufe erreichen
2. Pager Pflichtwarnung für Daten, die ein _kritisches_ Niveau erreichen

Nach meinem derzeitigen Verständnis müsste ich zwei separate Diagramme derselben Daten erstellen, um dies zu erreichen. Es wäre für mich sinnvoller, mehrere verschiedene Warnungen zu haben, die auf demselben Diagramm wirken.

@torkelo gibt es ein Update zu den Plänen für 2019?

+1

Wir haben Dashboards, die dieselben Microservices für mehrere Clients/Umgebungen überwachen, indem sie eine Variable verwenden, um zwischen den angezeigten Umgebungen zu wechseln.

Unser derzeitiger Schmerz könnte verringert werden, wenn wir Variablen im Titel/Text der Warnung verwenden könnten, damit wir den Client/die Umgebung identifizieren können, aber längerfristig würden wir wirklich gerne die Möglichkeit haben, separate Warnungen mit unterschiedlichen Schwellenwerten unter Verwendung desselben Diagramms zu erstellen.

Es wäre großartig, selbst wenn es erforderlich wäre, für jede Warnung eine andere Abfrage zu verwenden und die Abfrage nur auf „nicht sichtbar“ im Diagramm einzustellen.

Was Sie @itonlytakeswon beschreiben, scheint sich auch auf https://github.com/grafana/grafana/issues/6557 zu beziehen, also sollten Sie das vielleicht auch verfolgen :)

Wieso ist das noch kein Feature?

@jsterling7 beschreibt unseren gewünschten Anwendungsfall perfekt.

@torkelo Jedes Feature-Release

Entweder mehrere Warnungen oder das Zulassen von Tag-Werten im Warnungstitel/-text irgendwo würde dies für unsere Verwendung lösen. Wir haben ein einzelnes Diagramm, das eine getaggte Metrik mit mehreren unabhängigen Quellen zeigt, und möchten wissen, welche unter den Schwellenwert fällt. Ich mache gerade die 10 separaten Diagramme, die ich brauche, um dies zu erreichen, aber es fühlt sich an wie ein fehlendes Feature und schlecht für die langfristige Wartung auf meiner Seite.

Es scheint eine große Nachfrage zu sein, ich bin einer von denen, die diese Art von Funktion benötigen. Ich liebe Grafana fast, aber plötzlich macht mich diese Einschränkung ab.

Mein Anwendungsfall ähnelt anderen, auf die hier verwiesen wird, und dem Problem Nr. 6557. Wir haben mehrere Elasticsearch-Cluster, die in einem einzigen Vorlagen-Dashboard überwacht werden. Ich möchte Alarme für sie einzeln auslösen, und so wie es jetzt ist, kann ich nicht einfach ein Diagramm mit den fest codierten Abfragen erstellen, sondern muss ein Diagramm für jeden Cluster erstellen, damit diese Alarme funktionieren ...

+1, das würde unserer Umwelt sehr helfen! Sogar nur ein gelb/roter „Herz“-Zwei-Alarm-Setup pro Diagramm, bei dem, wenn Rot ausgelöst wird, Gelb überschrieben wird.

+1 Das wäre großartig, und ich frage mich, wie trivial es wäre, jeder Bedingung einfach eine optionale konfigurierbare Warnbenachrichtigung zu erlauben, und wenn nicht für eine bestimmte Bedingung auf eine Standardbenachrichtigung zurückgegriffen werden kann ... der schnellste Weg, dies zu erreichen Ich denke ?

+1 Es wäre auch für uns sehr nützlich. Wir haben viele Dashboards mit Vorlagen für mehrere Variablen. Es wäre großartig, eine Vorlagenersetzung sowohl für den Warnungsnamen als auch für die Warnungsbenachrichtigung vorzunehmen.

+1, meiner Meinung nach sollte dies in jedem Überwachungssystem vorhanden sein ... es gibt viele Situationen, in denen Sie den Schweregrad der Warnung identifizieren und entsprechend reagieren müssen, was mehrere Warnungen mit unterschiedlichen Schwellenwerten im selben Dashboard bedeutet.

+1 auch von mir - überrascht, dass das noch nicht existiert!

+1

Ich denke, diese Funktion geht Hand in Hand mit der Einschränkung der Unterstützung von Vorlagenabfragen.

Ich habe ein paar von Prometheus gespeiste Diagramme mit Abfragen eingerichtet, die Vorlagen auf Instanzen und Typenbezeichnungen haben. Ich umgehe das Vorlagenproblem, indem ich unsichtbare Abfragen für die Vorlagenwerte erstelle.

Ich möchte separate Benachrichtigungen für jeden Vorlagenwert, aber ich bin auf eine einzelne Benachrichtigung mit einer generischen Einheitsaktion+Nachricht beschränkt. Ich kann eine lange ODER-Liste verwenden, um auf alle meine Fragen aufmerksam zu machen, aber das fühlt sich grob an.

Eine Alternative besteht darin, ein separates Dashboard mit unzähligen Panels zu erstellen, die niemand ansieht, nur um als Alarmquelle zu dienen.

Das Hinzufügen von Unterstützung für mehrere Warnungen scheint möglicherweise der erste Schritt zur Unterstützung von Vorlagenabfragewarnungen zu sein.

+1. Dies ist ein Muss!

+1 Dies ist äußerst nützlich

@torkelo "Dann ist es sinnvoller, separate Bedienfelder für die Warnungen zu haben, wenn Sie separate Namen und Nachrichten für Warnungsregeln usw. wünschen."

Das macht keinen Sinn. Es ist keine Lösung, von Benutzern zu verlangen, dasselbe Panel mehrmals anzuzeigen, nur damit sie nützliche, nicht generische Warnmeldungen senden können. Es ist ein Hack für etwas, das ein Feature sein sollte, und fügt Rauschen hinzu, das die Nützlichkeit des Produkts beeinträchtigt.

@torkelo "Dann ist es sinnvoller, separate Bedienfelder für die Warnungen zu haben, wenn Sie separate Namen und Nachrichten für Warnungsregeln usw. wünschen."

Das macht keinen Sinn. Es ist keine Lösung, von Benutzern zu verlangen, dasselbe Panel mehrmals anzuzeigen, nur damit sie nützliche, nicht generische Warnmeldungen senden können. Es ist ein Hack für etwas, das ein Feature sein sollte, und fügt Rauschen hinzu, das die Nützlichkeit des Produkts beeinträchtigt.

Exakt. +1 für mehrere Benachrichtigungen pro Panel

In unserer Situation messen wir Zellspannungen in Batterien (16 Zellen pro Batterie). Wir stellen die Serie 16 zum Vergleich auf einem einzigen Panel dar und haben für jede Batterie ein anderes Panel.

Eine einzelne Warnung für das Panel (Diagramm) ist nicht sehr hilfreich. Wir brauchen wirklich die Möglichkeit, mindestens einen Alarm pro Zelle einzurichten, damit die Alarm-E-Mail anzeigt, welche Zelle(n) in Bezug auf die Spannung außerhalb des Bereichs liegt/liegen.

Da in unserem Fall der akzeptable Spannungsbereich für jede Zelle gleich ist, wäre es großartig, eine obere und eine untere Grenze definieren zu können und einzelne Zellbereiche diesen definierten Grenzen zuzuordnen.

Im Moment müssen wir 16 x ODER-Anweisungen für die Zellserie programmieren und die Grenzen für jede Zelle im Prozess (neu) definieren – mühsam einzurichten und ein Wartungsalptraum zu ändern.

Idealerweise sollten wir auch Warnungen und kritische Ereignisse für jede Zelle im Diagrammfeld programmieren.

Ich denke, es ist höchste Zeit, dass die Alarmstruktur geändert wird, um die Anforderungen zu berücksichtigen, die Benutzer identifiziert haben. Diese Anforderungen werden üblicherweise in SCADA-Systemen implementiert, die auch Warnungen generieren. Es ist wirklich nur eine Logik-Engine, sicher?

Gibt es hierzu Neuigkeiten? Ich bin der Meinung, dass diese Funktion ein Muss für größere Bereitstellungen ist. Vor allem, da wir gerne ein einzelnes Diagramm haben möchten, das beispielsweise die Speichernutzung zeigt, möchten wir eine Warnung für 70 %, 80 % usw. usw., was keine großen Mengen an Diagrammen sein sollte.

Ich bin gerade darüber gestolpert und bin sehr überrascht, dass es noch keine Möglichkeit gibt D:

Ich sehe hier https://github.com/grafana/grafana/pull/20822#issuecomment -561047900 , dass dies in Zukunft nicht implementiert wird und sich anhört, als würden Warnungen vollständig aus Dashboards gezogen.

Wie wirkt sich dies auf das JSON-Modell des Dashboards aus? Kann jemand mit Ihnen sprechen, wenn es weitere Neuigkeiten dazu gibt?

Dies war eine dringend benötigte Funktion. Gibt es schon ein Update zur bevorstehenden Situation?

+1 für mehrere Benachrichtigungen pro Panel

+1 für diese Funktion.

Dies war eine dringend benötigte Funktion. Gibt es schon ein Update zur bevorstehenden Situation?

Benötige diese Funktion.

3 Jahre später.. Kann uns jemand sagen, warum dies nicht implementiert wird (trotz der Anzahl der Anfragen)?
Es liegt an einer technischen Einschränkung, es zu implementieren? Es wird abgelehnt? Es ist zu erledigen?
Wie bereits erwähnt, scheint es sich um eine "Grundfunktion" zu handeln.
Beispiel: Ich habe ein Dashboard und eine Serie mit 200 Servern, wenn ich eine Benachrichtigung hinzufüge:
Einer von 200 Servern ist tot: Cool bekomme ich die Benachrichtigung mit Namen
Ups, ein neuer Server ist tot: keine Warnung (oder das Dashboard muss aktualisiert werden oder 24 Stunden später auf die Erinnerung warten ...)
Ist es nicht möglich, ein Kontrollkästchen hinzuzufügen, um es zu überprüfen, damit wir nach Zeile in der Serie benachrichtigt werden können (statt nach der "vollständigen" Serie)?
Wenn jemand aus dem dev, grafana-Team für ein Feedback antworten kann ...

Würde es Ihnen etwas ausmachen, Prometheus für die Benachrichtigung auszuprobieren und Grafana für das Erstellen von Dashboards zu verlassen?

@beastea Wenn Sie ein anderes Tool einrichten müssen, nur um Grafana zum Laufen zu bringen, macht es keinen Sinn, Grafana zu verwenden. Wir wechseln zu Datadog, weil diese Funktionalität dort existiert und es nur ein Tool ist.

@anne-nelson Sie müssen Metrik-Sammler und Metrikspeicher einrichten und für die richtige Einrichtung mit HA herumspielen, damit Grafana funktioniert, oder?
Datadog ist nicht nur das eine Tool, es verbirgt es nur vor Ihnen und leistet gute Arbeit, außerdem können Sie Grafana immer noch mit Datadog verwenden: https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea Ich bin mir nicht sicher, was diese Tools sind, also glaube ich nicht, dass wir sie verwenden. Unsere Metriken werden an Influx gesendet, wir werden sie nur an Datadog statt an Grafana senden. Warum sollte ich Dinge über Grafana an Datadog senden, wenn ich sie einfach direkt senden kann? Ich möchte so wenig Werkzeuge wie möglich verwenden.

@anne-nelson Sie können das Pushen von Metriken in Ihrer App implementieren, aber manchmal ist es sehr nützlich, einige der Systemmetriken auch zu pushen, damit Sie wissen, was mit Ihren Festplatten und anderen Dingen los ist. Das meine ich mit Metrics Collecter, einem lokalen Daemon, der solche Dinge tut, wie telegraf, collectd oder fluentd.
Influx in Ihrem Setup - ist eine Sache, die Metriken speichert und eine umfassende Möglichkeit bietet, Suchen über Grafana als Web-UI-Frontend für die Rohdaten durchzuführen, die Ihnen die Möglichkeit geben, Ihre Daten mithilfe einer internen Influx-Abfragesprache zu manipulieren.
Wenn Sie Datadog anstelle von Influx haben, funktioniert es genauso. Grafana hier -ist eine Benutzeroberfläche für den Zugriff auf die Daten. In einem allgemeinen Setup. Es macht also nichts mit Ihren Daten, es präsentiert sie nur in Diagrammen. Sie senden sie also ohnehin direkt.
Falls Sie, wie Sie beschrieben haben, mit Inlux arbeiten, warum Sie nicht in Betracht ziehen, Kondensatoren oder Flussmittel zur Lösung des von Ihnen beschriebenen Problems zu verwenden, da sie viel Reichweite bieten, kann Grafana Ihnen jemals anbieten, und sie sind immer noch vom selben Anbieter und mögen die gleiche Umgebung. Flux ist sogar Teil des Influx-Sendungspakets.

Es wird wirklich hilfreich sein.

@beastea , also ist es wahrscheinlich besser, die Funktion „Warnungen“ in Grafana zu entfernen und die der Leute auf ein anderes Tool zu migrieren (um eine Gasfabrik mit mehreren Tools zu vermeiden)?
Ich meine, OK, wir können Kapacitor, Prometheus usw. verwenden. Aber die Alarmfunktion existiert bereits in Grafana, also macht es in meinem Fall keinen Sinn.

Übrigens, was verhindert, dass dieses Kontrollkästchen hinzugefügt wird, um zeilenweise Warnungen zu erhalten? Wahrscheinlich kann eine Erklärung zum Verständnis beitragen.

@beastea Es scheint wirklich seltsam, dass Sie versuchen, jemanden davon zu überzeugen, Grafana nicht zu verwenden.

Wie anthosz betonte, ist es vernünftig, zu erwarten, dass mehrere Warnungen zu einem Diagramm hinzugefügt werden können, solange Warnungen eine Funktion in Grafana sind. Wenn Sie der Meinung sind, dass wir Grafana nicht für Benachrichtigungen verwenden sollten, sollte Grafana keine Benachrichtigungen als Funktion haben. Es ist klar, dass viele Leute diese Funktion wollen und dass viele Konkurrenzprodukte sie bereits anbieten. Ich verstehe ehrlich gesagt nicht, warum es so viel Gegenwind gibt.

@anne-nelson Ich versuche nicht, jemanden davon zu überzeugen, nicht das zu tun, was er gerne tun würde. Ich versuche, einen Rat zu geben, einen Blick in die andere Richtung zu werfen, die Ihnen heute schon eine Lösung bieten könnte.
Ich diktiere nicht, was Sie wofür verwenden sollten, ich biete Alternativen an, die Ihnen heute eine Lösung bieten könnten. Ich dränge nicht zurück, ich gebe dir einen Rat. Wenn Sie denken, dass mein Rat nicht hilfreich ist, dann ist das schade, aber das war's. Es tut mir leid, dass Sie das Gefühl haben, dass ich Sie ärgere und dass ich mit meinen Ratschlägen zu aufdringlich bin.
Hab viel Spaß.

@beastea Ich hatte aufgrund deiner Abwehrhaltung angenommen, dass du für Grafana arbeitest. Diese Funktion ist für viele Menschen relevant, und das Vorschlagen alternativer Produkte auf eine Funktionsanfrage hin ist nicht hilfreich und bringt diese Diskussion zum Scheitern. Das ist kein Stapelüberlauf.

Kann jeder einfach abhauen? Sie spammen möglicherweise Hunderte von Leuten zu, das ist nicht produktiv.

Sorry für die zusätzlichen Geräusche alle.

@torkelo würde es dir etwas ausmachen, uns ein schreckliches Update zu dieser Feature-Anfrage zu geben? Dieses Thema ist seit einigen _Jahren_ offen und wie Sie sehen, besteht immer noch Interesse. Zumindest kann es hilfreich sein, den Streit und unnötiges Geschwätz zu diesem Thema einzuschränken, um eine Art „offizielle“ Antwort darauf zu erhalten, ob dies in der aktuellen Roadmap enthalten ist oder nicht. Beifall.

Dieser und #6041, der ähnlich ist, werden vollständig ignoriert. Ich wundere mich warum.

Für uns macht es Sinn, da unser Ops-Team neue Integrationen in unsere Plattform registriert. Wir beginnen automatisch mit dem Senden von Metriken an Graphit. Und nur ein Panel in Grafana beobachtet all dies.

Wenn mehrere Systeme ausfallen, erhalten wir nur die Warnung für das erste. Und auch nicht sehr erklärend.

Wenn einer ausfällt und ein zweiter ebenfalls ausgeht, wird der Alarm nicht erneut ausgelöst.

Der Anwendungsfall, den ich dafür habe, ist die Definition von Multi-Window-Warnungen mit mehreren Brennraten über Prometheus und Grafana. Dies ist eine Standardpraxis für Warnungen dieses Typs zur Überwachung von SLOs, wie im Google SRE-Handbuch unter https://landing.google.com/sre/workbook/chapters/alerting-on-slos/ definiert.

Ein absolutes Muss, bitte weiterverfolgen..

Ich bin auch von Prometheus Alerting zu Grafana Alerting gewechselt und freue mich sehr darauf!

Kann jemand, der zuvor an Grafana gearbeitet hat, die bekannten Herausforderungen auflisten, um dies anzugehen?

Hey @torkelo , vielleicht kannst du uns in dieser Angelegenheit aufklären!

Es ist enttäuschend zu sehen, dass 7.x keine Verbesserung der Benachrichtigungen hatte – der vorherige Vorschlag, dass die Benachrichtigungen vollständig entfernt werden sollten, erfüllt mich nicht mit Hoffnung, aber wenn dies der Fall wäre, wäre es sicher gewesen, sie in 7.x zu entfernen logisch angesichts des Umfangs der Überarbeitung?

Es wäre großartig, eine Art Update darüber zu erhalten, warum dies so schwierig zu implementieren ist, nur damit wir verstehen können, _warum_ dieses Problem so lange offen war.

@torkelo hallo.
Ich habe das gleiche Bedürfnis - mehrere Warnungen für eine einzelne Metrik auf einem einzelnen Graf, aber mit mehreren überwachten Servern.
Ich habe ~ 100 Server mit definierter Metrik für freien Speicherplatz auf der Partition „/“ (zum Beispiel - da ich Dutzende solcher Metriken habe). Und ich muss auf JEDEM Server eine einzige eindeutige Warnmeldung erhalten, wenn der freie Speicherplatz auf „/“ weniger als 20 % beträgt.
Derzeit wird das nicht passieren, wenn zum Beispiel Server2 eine Warnung auslöst und während die Leute an der Lösung des Problems arbeiten, wird Server4 die gleiche Warnung ausgeben - wir werden nicht benachrichtigt. Oder übersehe ich eine Funktion?

Die Art der Multiplikation von Panels pro Server pro Metrik ist nicht der richtige Weg.
Könnte mir bitte jemand einen Rat geben, wie man das möglich macht?
Sollte ich mein Grafana aktualisieren (aktuelle Version ist 6.3.5)? Einige Erweiterungen hinzufügen? Plugins? Noch etwas?

Ich danke und schätze alle, die beraten oder helfen können.

@torkelo hallo.
Ich habe das gleiche Bedürfnis - mehrere Warnungen für eine einzelne Metrik auf einem einzelnen Graf, aber mit mehreren überwachten Servern.
Ich habe ~ 100 Server mit definierter Metrik für freien Speicherplatz auf der Partition „/“ (zum Beispiel - da ich Dutzende solcher Metriken habe). Und ich muss auf JEDEM Server eine einzige eindeutige Warnmeldung erhalten, wenn der freie Speicherplatz auf „/“ weniger als 20 % beträgt.
Derzeit wird das nicht passieren, wenn zum Beispiel Server2 eine Warnung auslöst und während die Leute an der Lösung des Problems arbeiten, wird Server4 die gleiche Warnung ausgeben - wir werden nicht benachrichtigt. Oder übersehe ich eine Funktion?

Die Art der Multiplikation von Panels pro Server pro Metrik ist nicht der richtige Weg.
Könnte mir bitte jemand einen Rat geben, wie man das möglich macht?
Sollte ich mein Grafana aktualisieren (aktuelle Version ist 6.3.5)? Einige Erweiterungen hinzufügen? Plugins? Noch etwas?

Ich danke und schätze alle, die beraten oder helfen können.

Diese Ausgabe ist seit 2017 geöffnet (Und die Antwort von @torkelo ist 🤡 "es macht mehr Sinn, separate Panels für die Alerts zu haben" 🤡 (sehr schön, ein Panel pro Server/Alert zu erstellen, wenn wir 600 Server haben) 🤡).

Anscheinend besteht die einzige Möglichkeit darin, von Grafana zu einer anderen Lösung zu migrieren oder eine Gasfabrik mit mehreren zu wartenden Tools zu erstellen.

@anthosz - vielen Dank. Das Problem ist die Tatsache, dass die Umgebung nicht uns, sondern den Kunden gehört, daher wäre es eine sehr schwierige Aufgabe für mich, darauf zu bestehen, um meinen Vorsprung zu wahren, und ihn weiter zu führen, um das „werden nicht dafür bezahlen“ der Kunden zu überwinden. .
Zumindest habe ich jedoch einige Fakten, die besagen, dass keine Möglichkeit besteht, solche Auslöser / Alarme zu organisieren - auf diese Weise.

Danke noch einmal.

_mitmachen(Stimme, Chor)_
Ich habe einen Stromsensor an einem Stromkreis, der eine Luftpumpe mit 1,5 Ampere nominal und eine Abwasserpumpe mit 10 Ampere nominal überwacht. Die Luftpumpe läuft rund um die Uhr, die Abwasserpumpe läuft je nach Tankfüllstand nach Bedarf. Wenn alles in Ordnung ist, beträgt der Strom (I) entweder 1,5 A, wenn die Abwasserpumpe ausgeschaltet ist, oder 11,5 A, wenn die Abwasserpumpe eingeschaltet ist.

Der erste häufige Fehler ist, dass die Luftpumpe durchbrennt, was durch (Imax < 0,5 A oder Iavg zwischen 9 A und 11 A) gemeldet wird, was entweder keinen Strom erkennt oder die Abwasserpumpe läuft, wenn die Luftpumpe gestorben ist. Dies muss innerhalb von 48 Stunden behoben werden, um einen Systemausfall zu vermeiden. Daten sind 1 Punkt pro Minute, Warnungen nach 90 Minuten.

Die zweite gewünschte Warnung auf demselben Diagramm ist (Imax > 14 A oder Iavg zwischen 2 A bis 9 A), was darauf hinweist, dass die Abwasserpumpe verstopft oder Luft in der Leitung ist, obwohl sie pumpen sollte. Dies ist eine viel dringendere Warnung, die möglicherweise innerhalb von 3 Stunden behoben werden muss, daher wäre eine Warnung nach 5 Minuten ideal.

Beide Warnungen stammen von demselben entfernten Stromsensor, der Daten über LoRa sendet. Mehrere Warnungen würden mich davon abhalten, eine Dashboard-Abfrage für denselben Sensor zu duplizieren.

@torkelo Multiple Graphs ist für viele Benutzer einfach nicht skalierbar. Das scheint so einfach hinzuzufügen zu sein, und ich bin neugierig, warum ihr es nicht in Betracht zieht?

Vielleicht, wenn es eine große Nachfrage danach gibt :)

Hey @torkelo , was siehst du als große Nachfrage an? 96 Kommentare und 250 "Gefällt mir" in deinem Kommentar sind riesig? Es ist die 8. am häufigsten kommentierte offene Feature-Anfrage und nur eine geschlossene Feature-Anfrage hat mehr Kommentare als diese. Es ist auch der 3. offene Feature-Request mit mehr :+1:-Reaktionen. Was wird benötigt, um in die Roadmap einzutreten?

@torkelo Ich habe ein sehr einfaches Fallbeispiel.

Ich brauche eine andere Warnung, wenn der Wert unter den Schwellenwert fällt, als die Warnung, wenn der Wert einen (anderen) Schwellenwert überschreitet.

Hier ist ein anderes Szenario. Wenn ich die Anzahl gesunder Server überwache, benötige ich andere Warnungen, wenn ich 1 Server verliere (legitimer Neustart, der kein Problem darstellt, es sei denn, er dauert über 10 Minuten), im Vergleich zum Verlust von 5 Servern.

Hier ist noch ein weiteres Szenario. Ich möchte eine andere Warnung festlegen, wenn die Anstiegsrate in einer Warteschlange einen Schwellenwert überschreitet, und eine andere Warnung, wenn die Warteschlangengröße selbst einen Schwellenwert überschreitet.

In Bezug auf die Visualisierung glaube ich, dass die Community zunächst mit jeder Lösung zufrieden wäre. z. B. nur die erste Warnung visualisieren (also keine UI-Änderungen erforderlich). Visualisieren Sie alle Warnungen mit vertikalen Linien, die Ihnen beim Bewegen mit der Maus mitteilen, welche Warnung ausgelöst wurde. Schwellenwerte/Warnungen nur anzeigen, wenn Sie mit der Maus über eine bestimmte Serie fahren usw.

Nur meine 2 Cent.

Hallo!

Wollte mich hier einmischen, wir (Spotify) brauchen das auch.

Wir betreiben derzeit unsere eigene Benachrichtigungs-Engine, die Benachrichtigungen von Grafana bezieht, und Benachrichtigungen pro Zeitreihe. Wir verschieben derzeit die Warnungsanmerkungen pro Zeitreihe zurück in Grafana.

In Bezug auf die Benutzeroberfläche führt also die erste Zeitreihe zur Warnung dazu, dass das Panel/die Warnung in den Status „Warnung“ wechselt, und jede nachfolgende Warnung häuft sich einfach an (der Statusverlauf zeigt mehrere Aktualisierungen „bis“ Warnungen und ebenso mehrere Änderungen zurück zu "ok")

Wir "brauchen" dies, da wir dies immer so gemacht haben, um Alarme zu machen, also wäre die Abkehr von Alarmen pro Zeitreihe eine große soziale Veränderung für ~10.000 Alarme. Wir würden sehr gerne die native Benachrichtigung von Grafana verwenden und übernehmen und unsere Datenquelle aktualisieren, um sie zu unterstützen.

Wollte mich hier einmischen, wir (Spotify) brauchen das auch.

Hast du auch Grafana Enterprise verwendet? Kann vielleicht Entwicklern helfen/motivieren =)

Wir würden uns auch über diese Funktion freuen , die Möglichkeit , mehrere Warnungen aus demselben Diagramm auszulösen . Die Möglichkeit, sowohl bei einem „unterhalb“- als auch bei einem „oberhalb“-Zustand auszulösen, und die Möglichkeit zu haben, vor einer wichtigeren Schwellenverletzung effektiv eine gelbe Warnung zu erhalten

Wir betreiben derzeit unsere eigene Benachrichtigungs-Engine, die Benachrichtigungen von Grafana bezieht, und Benachrichtigungen pro Zeitreihe. Wir verschieben derzeit die Warnungsanmerkungen pro Zeitreihe zurück in Grafana.

@sjoeboo ein bisschen off-topic hier, aber ist irgendetwas öffentlich verfügbar?

@vbichov noch nicht , wir wollen die Alarmierungs-Engine öffnen, obwohl der Zeitrahmen im Fluss ist. Ich bin sicher, ich könnte einen Patch teilen, den wir auf unserem (kaum idealen) internen Fork haben, um die Verfolgung von Warnungen pro Zeitreihe über Anmerkungen zu ermöglichen.

Hinweis: Die Benachrichtigungs-Engine ist derzeit spezifisch für unsere TSDB (https://github.com/spotify/heroic).

+1 für diese Funktion. das ist so etwas wie eine Warnung/kritisch. Wir wollen eine Warnung bekommen, bevor das Leben schlechter wird. Dann sollten wir kritische Warnungen erhalten, um sofort Maßnahmen zu ergreifen.

Ich bin erstaunt, dass dies nach 3 Jahren Anfragen von Benutzern nicht implementiert wurde.

Das Erstellen mehrerer Panels (eines für jede Warnung) verstopft ein Dashboard und macht das Hinzufügen neuer Warnungen viel komplizierter, als es sein sollte

Ich frage mich immer, warum auf der Registerkarte "Warnungen" eine 1 angezeigt wird, wenn Sie nicht mehr als eine Warnung pro Panel definieren können. Im Abfrage-Reiter zeigt diese Zahl auch die Anzahl der definierten Abfragen an. Also dachte ich immer, dass dies möglich wäre und ich bin ziemlich überrascht, dass dies noch nicht verfügbar ist.

Interessant, dass dies immer noch nicht implementiert ist. Ich stimme zu, dass die "Zählung" auf der Registerkarte "Warnung" irreführend ist, da sie zu der Annahme führt, dass es mehrere geben kann. Außerdem ist es ein bisschen lächerlich, ein Panel pro Alarmregel zu haben, da dies bedeutet, dass ich ein "nutzloses" Dashboard habe, das nichts anderes als Panels für Benachrichtigungen ist. Es ist sicherlich ein unordentliches Dashboard, aber es ist die einzige Möglichkeit, dies zu implementieren. Hauptsächlich, damit ich unterschiedliche Regeln für die Kombination von Namen und/oder Benachrichtigungsendpunkten haben kann. Es ist gelinde gesagt kompliziert.

Ist das gemacht worden?
Grafana-Version = 4.x

Jetzt geht die Grafana-Version auf 7.x und ich habe diese Funktion nicht gesehen

Ist das gemacht worden?
Grafana-Version = 4.x

Jetzt geht die Grafana-Version auf 7.x und ich habe diese Funktion nicht gesehen

So naiv😁

+1 für diese Funktion.
Auf einer einzigen Metrik würde ich gerne

1. Eine Warnmeldung, die darauf hinweist, dass sich eine Komponente nicht wie erwartet verhält und eine genaue Überwachung durch den 2nd-Line-Support erfordert
2. Eine Fehlermeldung, die darauf hinweist, dass eine Komponente ausfällt, und Callouts an die 3rd-Line-Engineering auslöst.
   Das Duplizieren der Metrik ist umständlich und macht unsere Dashboards für die Überwachung unübersichtlich.

So viele einfache Funktionen werden von dieser Gruppe ständig verweigert, überprüfen Sie die vielen anderen Funktionsanfragen ... das scheint etwas Grundlegendes zu sein.

Ich gebe ein weiteres Beispiel.

Ich betreibe eine Synology und möchte darauf aufmerksam machen. Der Raid-Status hat einen normalen Wert von 1. Er hat jedoch auch einen Degraded-Wert von 11 und einen Crashed-Wert von 12. Degraded bedeutet, dass Daten noch zugänglich sind. Abgestürzt bedeutet hohe Wahrscheinlichkeit von Datenverlust.

Ich möchte eine Warnung senden, wenn der Raid degradiert ist, und einen kritischen Alarm, wenn der Raid abgestürzt ist.
Ich habe mehrere Volumes und Speicherpools und das Erfordernis mehrerer Diagramme für jedes ist nicht skalierbar.

Dies kann auch auf etwas so Einfaches wie die Speicherplatznutzung angewendet werden.
Ich möchte eine Warnung senden, wenn die Festplattennutzung 80 % erreicht, und einen kritischen Alarm, wenn die Festplattennutzung 90 % erreicht. Das Erstellen mehrerer Diagramme für JEDE meiner Festplatten ist keine vernünftige Frage.

Und ich verstehe den Kommentar nicht, dass dies in der UI schwierig ist. Sie haben bereits etwas Ähnliches, nämlich eine Liste von Dashboards. Wenn Sie auf die Registerkarte "Warnung" klicken, sollte eine Liste mit Warnungsregeln nach Namen mit der Schaltfläche "Neue Warnung erstellen" unten angezeigt werden. Jede Warnungsregel sollte rechts davon eine Option zum „Bearbeiten“, „Deaktivieren“ oder „Löschen“ haben. Wenn Sie auf die Warnung oder auf die Schaltfläche „Bearbeiten“ klicken, sollten Sie zur vorhandenen Bearbeitungsseite gelangen, die nur für diese bestimmte Warnungsregel angezeigt wird.

Das Erstellen mehrerer Diagramme für JEDE meiner Festplatten ist keine vernünftige Frage.

Sie können die API verwenden, um das Erstellen/Aktualisieren von Dashboards und deren Warnungen zu automatisieren. Wenn Sie möchten, können Sie ein Programm erstellen, das Prometheus (oder eine andere Quelle, die Sie haben) abfragt, indem Sie regelmäßig Abfragen ausführen, um einen Dienst zu erhalten, der nach Zielen erkennt und automatisch Warnungen oder sie erstellt.

Unglaublich, dass diese Funktion noch nicht implementiert wurde, bei dem riesigen Feedback, das dieses Problem hat.

Ich verwende Grafana als unsere Visualisierungs- und Warn-Engine an den Magellan-Teleskopen. Wenn ich mehrere Subsysteme habe, die Eigenschaften teilen, die es verdienen, dass sie alle in einem Plot sind, müssen meine Benutzer, wenn ein Problem auftritt und eines beginnt, sich schlecht zu verhalten, eine kryptische Warnung erhalten und graben, was fehlschlägt.

Das Erstellen von Dummy-Plots ist eine Problemumgehung, keine Lösung. Das scheint einfach!

+1 notwendige Funktion

+1

Genau die gleiche Situation wie beim OP. Grundfunktion, die bereits implementiert sein sollte.

Können die Leute aufhören, dieses Thread-Problem zu spammen, ohne etwas Wertvolles hinzuzufügen?.

Verwenden Sie die Reaktionen am Anfang der Ausgabe, um Interesse zu signalisieren.

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc ist für einen Betreuer unendlich nützlicher, um festzustellen, welche Probleme „beliebt“ sind, als dass Leute spammen Jeder E-Mail-Posteingang und GitHub-Benachrichtigungen mit Informationen, die bereits durch einen Blick auf die Problembeschreibung klar sind.

Wenn es so einfach ist, sollte vielleicht jemand von all den Meckerern, der nur erwartet, dass andere Leute kostenlos für sie arbeiten, dies selbst implementieren und entweder einen Pull-Request stellen oder seinen eigenen Fork pflegen, wenn die Betreuer es nicht im Upstream wollen.

@thomasf "Können die Leute aufhören, dieses Thread-Problem zu spammen, ohne etwas Wertvolles hinzuzufügen?" - Genau wie du?

Wenn die Betreuer noch im Thread sind, erinnern neue Kommentare sie zumindest daran. An diesem Punkt scheint es irgendwie nutzlos zu sein, es gibt keine Möglichkeit, dass die Betreuer es nach so langer Zeit implementieren werden, und die Leute sollten wirklich zu besseren Tools wie Datadog wechseln, wo sich die Betreuer tatsächlich interessieren, aber Hunderte von Kommentaren (insbesondere wenn sie tatsächliche Szenarien haben ) hat viel mehr Einfluss als nur ein Daumen nach oben.

Wenn die Betreuer noch im Thread sind, erinnern neue Kommentare sie zumindest daran. An diesem Punkt scheint es irgendwie nutzlos zu sein, es gibt keine Möglichkeit, dass die Betreuer es nach so langer Zeit implementieren werden, und die Leute sollten wirklich zu besseren Tools wie Datadog wechseln, wo sich die Betreuer tatsächlich interessieren, aber Hunderte von Kommentaren (insbesondere wenn sie tatsächliche Szenarien haben ) hat viel mehr Einfluss als nur ein Daumen nach oben.

Oder vielleicht haben sich die Betreuer wegen des Spams von der Benachrichtigung zu diesem Problem abgemeldet, dass nicht der einzige mit vielen +1/Nachrichten ohne Update ist. Bitte vergleichen Sie nicht Grafana und DataDog (wir waren Benutzer von beiden, keine Möglichkeit, zu DataDog zurückzukehren)

Der beste Weg, um dieses zu bekommen, ist, einen Beitrag zu leisten (oder wahrscheinlich für Grafana Entreprise zu bezahlen).

Du liegst sehr falsch. Kostenlos oder nicht, Sie können nicht a setzen
forum/slack/github/feedback channel und dann ignorieren. Wenn du das denkst
eine Software unter eine Opensource-Lizenz zu stellen bedeutet "keine Beschwerden" und "Leute
wird für deine Features kostenlos entwickeln" liegst du wieder sehr sehr falsch. In
In meinem Fall erklärte ich ihnen, dass ich mit dieser Funktion zehn Grafana verkaufen kann
Kunden von mir. Der ignoriert mich, das heißt der sauer auf einen Kunden. Toll
Vermutlich bewegen sie "genug" Geld und sie wollen nicht mehr, ich freue mich
für Sie....

Heute, 14. Oktober 2020, um 15:35 Uhr Thomas Frössman <
[email protected]> ha geschrieben:

Können die Leute aufhören, dieses Thread-Problem zu spammen, ohne etwas von hinzuzufügen
Wert?.

Verwenden Sie die Reaktionen am Anfang der Ausgabe, um Interesse zu signalisieren.

Wenn es so einfach ist, erwartet vielleicht jemand von all den Nörglern
andere Leute, die für sie kostenlos arbeiten, sollten dies selbst umsetzen
und entweder eine Pull-Anfrage stellen oder ihre eigene Gabel pflegen, wenn die
Betreuer wollen es nicht im Upstream.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

Der Geldbetrag, den ich bereit bin, für _beliebige_ Software auszugeben, ist direkt proportional zum Niveau des Kundendienstes, den ich für meine Investition erwarten kann. Ob es sich dabei um ein Open-Source-Produkt mit "kostenpflichtigem Support" oder ein kommerzielles Produkt handelt, spielt keine Rolle.

Dass dieses Problem so lange offen bleibt, ohne dass die Betreuer des Projekts auch nur einen Blick darauf werfen, führt leider zu einem vernünftigen Gefühl des Zweifels, ob sich durch das Ausgeben von Geld etwas ändern würde. Wenn Sie versuchen, Software zu verkaufen, ist es wahrscheinlich ratsam, dies in Betracht zu ziehen.

eine Pull-Anfrage stellen oder ihren eigenen Fork pflegen

Wenn es auch nur einen Hinweis von den Entwicklern gäbe, wo ich anfangen soll, bin ich sicher, dass ich nicht der Einzige bin, der sagt, dass ich dies in Betracht ziehen würde, unabhängig davon, ob ich denke, dass ich es tun sollte oder nicht, einfach aufgrund des schieren Werts, den es hätte zur Verfügung stellen. Leider scheint das nicht der Fall zu sein, und ich habe wenig Interesse daran, das Produkt für eine Funktion zurückzuentwickeln, die den Betreuern anscheinend nicht wirklich wichtig ist.

Schließlich sehe ich keinen Grund, warum jemand seine Meinung nicht äußern sollte, es sei denn, der Thread ist geschlossen / gesperrt. Sie können sich abmelden, wenn Ihnen das nicht passt. Ich genieße es tatsächlich, Leute zu lesen, die sich über die relative Absurdität dieser Sache beklagen. 😁

Alerting NG (NextGen)-Alerting, das für 8 geplant ist, wird mehrere Alert-Instanzen aus einer einzigen Alert-Definition unterstützen. So etwas wie host=* mit einem System wie Prometheus erstellt Warnungen pro Host.

Einige allgemeine Informationen dazu im Zusammenhang mit einzelnen Statistiken wurden zu https://github.com/grafana/grafana/issues/6983#issuecomment -712915673 hinzugefügt

Wir entwerfen und entwickeln immer noch Prototypen, aber um auf einige anfängliche Gedanken zu den Dingen zu reagieren:

Mehrere Warnungen pro Diagramm

Warnungsdefinitionen sind ihre eigenen Entitäten, sodass sie nicht an ein Panel gebunden sind. Aus Alarmdefinitionen können mehrere Alarminstanzen werden. Dann kann ein Panel Instanzen oder Definitionen abonnieren. Ich kann mir vorstellen, dass wir immer noch einen netten UX-Pfad vom Dashboard-Panel wollen, um eine Warnung zu erstellen, weil das ein netter Flow ist.

Außerdem ist es nicht immer vorzuziehen, separate Zustände einer Warnung zu verfolgen (da der Endbenutzer die Details hinter den einzelnen Zuständen kennen müsste), anstatt nur zu wissen, ob eine Warnung ausgelöst wird.

Sobald viele Warnungen aus einer Definition zulässig sind, wird die Art und Weise, wie sie gruppiert werden sollten, zu einem Problem (da man zu vielen Warnungen gelangen kann). Ich sehe derzeit zwei Wege, wie dies mit Alerting NG funktionieren würde:

1. Verwenden Sie Alerting NG mit einem IRM wie pagerduty oder alertmanager, das die Gruppierung von Alertinstanzen handhaben kann.
2. Ändern Sie Ihre Abfrage so, dass sie nach einer größeren Scoping-Dimension gruppiert wird. Wenn Sie beispielsweise cluster=* anstelle von host=*,cluster=* abfragen (oder gruppieren nach für SQL-ähnliche Datenquellen). Alternativ beabsichtige ich, serverseitigen Ausdrücken (die mit Alerting ng geliefert werden) Funktionen hinzuzufügen, um Gruppierungs-/Nach-Pivot-Operationen zu ermöglichen, wenn die Datenquelle dies nicht tut. Dies wäre der Fall, wenn Sie kein IRM verwenden und direkt an Dienste wie E-Mail/Slack senden.

Warnung/kritisch

Dieser ist komplizierter. Für das WIP-Design habe ich es als Funktion entfernt (zumindest für eine Warnungsdefinition wird es vielleicht eine Möglichkeit geben, die Warnungsdefinition zu duplizieren, zu ändern und sie mit dem Schweregrad zu kennzeichnen / zu kennzeichnen)

Das ist schwierig, weil es in vielen Fällen sehr nützlich ist:

• Für mich haben Warnung/Kritik klare Verwendungen: Annäherung an kaputt/gebrochen oder degradiert/gebrochen.
• Ohne sie werden viele Setups am Ende eine beträchtliche Anzahl von Warnungen für unterschiedliche Schweregrade wiederholen.

Warum also entscheiden, sie nicht zu haben? Es fügt einiges an nicht offensichtlicher Komplexität hinzu:

• Angenommen, Sie möchten Ihre Schwellenwerte unterstützen, die von einer anderen Metrik stammen (oder Ihre Schwellenwerte sollen unterschiedliche Bereiche der Abfragezeit sein, nicht Werte), müssen jetzt zwei Bedingungen ausgeführt werden.
• Für die Zustände von Alarminstanzen möchte ich mindestens Folgendes unterstützen:
  
  
  
  • Unbekannt: Eine Instanz ist verschwunden
  
  
  • Fehler: Die Abfrage, die herausgefunden hätte, dass es ein Problem mit den Instanzen gibt, ist defekt
  
  
  • Warnung: Die Bedingung ist wahr
  
  
  • Normal. Die Bedingung ist nicht wahr
  
  
• Wir möchten auch weiterhin FOR-ähnliche Ausdrücke haben. Wenn Sie weitere Zustände hinzufügen, ist das Entwerfen, dass das Flattern weder zu verpassten Benachrichtigungen noch zu Rauschen führt, kompliziert. Im Allgemeinen sind Zustandsmaschinen im Laufe der Zeit sehr anfällig für Fehler und sind schwer richtig zu machen (suchen Sie nach TLA / Temporal Logic of Actions, um mehr zu erfahren, wenn Sie so etwas mögen). Das Hinzufügen von Schweregraden vergrößert also den Zustandsraum mehr als man vermuten würde. Das bedeutet, dass wir eher unbeabsichtigte Verhaltensweisen haben oder Verhaltensweisen, für die es schwieriger ist, ein mentales Modell zu haben.
• Wenn Sie eine Integration mit anderen Systemen oder IRMs anstreben, könnten spezifische Vorstellungen zum Schweregrad die Integration erschweren.

(Zumindest für eine Warnungsdefinition wird es vielleicht eine Möglichkeit geben, die Warnungsdefinition zu duplizieren, zu ändern und sie mit dem Schweregrad zu kennzeichnen / zu kennzeichnen

Dies ist ein durchaus akzeptabler Workaround für die Unterscheidung kritisch/Warnung. Ich bin mehr als glücklich, separate Schwellenwerte beizubehalten. Einen kombinierten Warnungs-/kritischen Schwellenwert zu haben, wäre schön zu haben, ist aber kein Dealbreaker.

dann wird es zu einem Problem, wie sie gruppiert werden sollten (da man zu vielen Warnungen gelangen kann).

Es ist Sache des Benutzers, sein eigenes Ticketvolumen und seine eigene Alarmgenerierung zu verwalten. Wenn Sie Alarme einstellen, sollte jeder eine separate E-Mail oder Benachrichtigung sein. Stellen Sie sich das so vor: Wenn Sie ein automatisiertes System zum Generieren von Tickets basierend auf ausgelösten Alarmen erstellen, würde das Gruppieren mehrerer Alarme in einer E-Mail dies beispielsweise entweder schwierig oder einfach nur unausstehlich machen. Darüber hinaus bedeuten mehrere Alarme, die in einer E-Mail angezeigt werden, dass jeder Alarm keinen eigenen E-Mail-Thread haben kann, er müsste manuell von den Benutzern getrennt und neue Threads gestartet werden. Stattdessen sollte jede Alarmauslösung ihre eigene Benachrichtigung haben, damit Threads auf diesen spezifischen Alarm beschränkt werden können.

Hoffentlich vereinfacht dies das alarmierende Design, da Sie sich keine Gedanken über die Gruppierung machen sollten. Das ist Sache des Benutzers.