Grafana: Warnungsunterstützung für Abfragen, die Vorlagenvariablen verwenden

+1

1. Was wäre der Unterschied im Vergleich dazu, einfach alles zu verwenden?

+1
Es wäre schön, Warnungen auf Servern mit geringer Lebensdauer (AWS-Autoskalierung) hinzufügen zu können. Die automatische Registrierung des Servers auf Grafana ist mit dem Templating einfach, aber es ist traurig, keine Warnungen auf sie setzen zu können

@bergquist es ist unpraktisch, all zu verwenden, wenn Sie beispielsweise mehr als ein Dutzend Hosts haben.

Wenn zum Beispiel nur wenige von ihnen fehlschlagen (sagen wir 5), ist es sehr nützlich, eine E-Mail für jede fehlgeschlagene Warnung zu erhalten. Auf diese Weise ist auch die Integration mit anderen Tools viel einfacher, die im Allgemeinen eine Warnung pro Metrik erwarten.

Der aktuelle Ansatz (alle verwenden) ist jedoch ziemlich gut, wenn es weniger Instanzen gibt oder wenn Sie auf Serviceebene warnen (z. B. Anzahl der Jobs in der Warteschlange).

Was @calind sagte, ich habe mehrere $host-Variablen, die mit der influxDB gut funktionieren, aber nicht mit den Warnungen

+1 auch.

Nur ein Gedanke, da Sie mit einer Vorlagenvariablen abfragen können, könnten Sie nicht einfach die gleiche Abfrage mit den Warnmetriken durchführen und vielleicht die Ergebnisse durchlaufen, um zu sehen, welche die Warnkriterien erfüllen?

@NotSoCleverLogin Es wäre möglich. Aber möchten Sie das Verhalten der Warnregel basierend auf den ausgewählten Vorlagenwerten ändern?

Die Verwendung der Option all für die Vorlage ist die einzige Möglichkeit, die für mich sinnvoll ist.

+1

Ich habe ein Setup von X-Umgebungen mit denselben Komponenten in jeder Umgebung. Wir verwenden derzeit Prometheus, um beispielsweise auf CPU-Auslastung/Festplattennutzung usw. zu warnen. Dort geben wir einen Alarm für eine Abfrage an, und wenn der Alarm ausgelöst wird, wird nur angegeben, aus welcher Umgebung der Alarm ausgelöst wurde.

Wenn wir dies mit der All-Variablen machen würden, würde das einigermaßen funktionieren. Aber mit dem Beispiel von @calind würde der Screenshot den Trend aller CPUs aus allen meinen Umgebungen enthalten und nicht nur die Umgebung, in der ich über das Problem informiert werden möchte. Der Graph wird (oder kann) mit Informationen aus anderen Umgebungen verdeckt werden. In einigen Szenarien könnte es interessant sein, die CPU in anderen Umgebungen zu vergleichen, aber es gibt keine Garantie dafür, dass das, was in einer Testumgebung passiert, auch in unserer Produktionsumgebung passiert usw.

Wir prüfen auch die Erstellung von Dashboards, die von Operationen verwendet werden können und Anmerkungen für Warnungen im „Standard“-Übersichts-Dashboard anzeigen. Da wir für diese Art von Dashboards „env“-Template-Variablen verwenden, ist dies mit der derzeitigen Implementierung nicht wirklich möglich. Ich müsste (zumindest teilweise) manuell ein "Schatten"-Dashboard generieren, in dem die Warnungen ausgelöst werden (wodurch ich die Anmerkungen im Übersichts-Dashboard verliere).

Ich denke, Vorlagenvariablen können Ihnen auch dabei helfen, die Warnungen (falls Sie sich für die Implementierung einer solchen Funktion entscheiden) an verschiedene Quellen weiterzuleiten (einige an den Betrieb in der Produktion, an QA/Entwickler in Testumgebungen usw.).

+1 für die Unterstützung von Warnungen bei Vorlagenabfragen.

@bergquist , einige Dashboards haben keine _Alle_ Option. Zum Beispiel Systemmetriken von collectd (https://grafana.net/dashboards/24). Eine _All_-Option zu haben, wäre sicherlich nicht praktikabel für sagen wir 10 oder mehr Server. Aus diesem Grund müssen Vorlagenvariablen durchlaufen werden.

Die Verwendung von All ist ein guter und willkommener Anfang.

In Prometheus müssen Abfragen anders geschrieben werden, um All zuzulassen:

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

Beachten Sie die zusätzliche Tilde dort, die die Suche nach regulären Ausdrücken ermöglicht (und den Platzhalter in All).

Ich habe die möglichen Auswirkungen auf die Leistung eines Wechsels von einer direkten Abfrage zu einer Regex-Suchabfrage nicht bewertet, aber zumindest für den Moment würde es anscheinend unsere Probleme lösen.

+1

+1

Ich bin mir nicht sicher, wie es implementiert werden soll, weiß nur, dass es benötigt wird.

+1
Wir verwenden Prometheus als Datenquelle, um unsere Kubernetes-Infrastruktur für unsere On-Prem K8S-Cluster und unsere AWS K8S-Cluster zu überwachen.
Alle unsere Dashboards verwenden Template-Variablen für die Datenquelle ($Environment), $Instance/Node, $Namespace und $Pod.
Aufgrund der Art und Weise, wie die Prometheus-Abfragestruktur ist; alle Abfragen haben Template-Variablen; was verhindert, dass die Alarmregeln das Speichern zulassen.
Ich würde gerne sehen, dass Templated Variable Queries zur Benachrichtigung hinzugefügt werden.

+1

+1
Wir verwenden Templating-Dashboards für Umgebungen mit mehreren Servern, was der logische Weg ist (und viele Leute verwenden). Daher können wir derzeit keine Warnungen mit Grafana verwenden. Die einzige Möglichkeit besteht darin, ein separates Dashboard ohne Vorlagen zu haben oder Warnmeldungen mit Prometheus selbst einzurichten, was nicht einfach ist.

Wenn es vielleicht eine Option oder eine einfache Möglichkeit gäbe, ein Dashboard mit den Vorlagenvariablen zu speichern/zu exportieren, die in allen Feldern gesichert/vorgerendert sind, wäre dies vielleicht ein guter halber Weg, bis eine andere Lösung gefunden wird.

+1 für die Unterstützung von Warnungen bei Vorlagenabfragen. Wir verwenden derzeit Vorlagen auf allen unseren Dashboards, daher können wir diese wirklich coole Funktion nicht nutzen.

+1, wir haben viele Dashboards mit Vorlagen, und wir können derzeit keine Benachrichtigungen verwenden, wir müssen Dashboards deduplizieren, um Benachrichtigungen zu erhalten, und wir verlieren so die Vorlagenleistung

+1, Fast alle unsere Dashboards verwenden Vorlagenvariablen (und verschachtelte Vorlagenvariablen).

Wir möchten in der Lage sein, Warnungen für Wiederholungspanels festzulegen, um bei Bedarf individuelle Warnungen pro Template-Variablengruppe zu erhalten. Außerdem bedeutet dies, dass die Alarmierung dynamisch und nicht supermanuell ist, wie es jetzt der Fall ist.

GEFAHR: Variablen sind theoretisch gut zu haben, aber wir müssen bedenken, dass, wenn jemand in Ihr Dashboard geht und den Wert ändert und speichert, die resultierende Benachrichtigung beeinträchtigt wird. Ich weiß nicht, ob das in Ordnung ist oder nicht, wird kompliziert.

+1

Bei der Arbeit mit Grafana fühlt es sich so an, als würde das Erstellen von Vorlagen überall gefördert, und es fühlt sich falsch an, einen zusätzlichen Satz von Diagrammen zu erstellen, die keine Variablen verwenden, nur um die Warnfunktion zu verwenden ...

+1 für die Unterstützung von Warnungen bei Vorlagenabfragen.
Außerdem haben wir festgestellt, dass wir bei Verwendung von chinesischem Regelnamen oder chinesischem Titel ungewöhnliche E-Mails mit ausgelösten Regeln erhalten haben. Zum Beispiel haben wir „个股分时线接口请求时间(getTimeTrend) alert“ erwartet, aber „ä¸ªè‚¡åˆ†æ—¶çº¿æŽ¥å £è¯·æ±‚æ—¶é—´( getTimeTrend) alert", vielleicht ist der Zeichensatz nicht korrekt.

+1 zum Implementieren von Vorlagen-Variablen in Warnungen

+1

+1 wäre eine großartige Ergänzung

+1

+1 zum Implementieren von Vorlagen-Variablen in Warnungen

+1

+1 freue mich darauf

+1

+1

+1

+1

Bitte hör +1 zu schreiben!
Alle, die diese Ausgabe abonniert haben, erhalten eine E-Mail...

Es gibt eine Github-Funktion, um diese +1 -Kommentare loszuwerden:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

@thetechnick In der E-Mail befindet sich ein Link, über den Sie den Thread stumm schalten und keine E-Mails erhalten können. Aber ich verstehe, dass Sie vielleicht einfach benachrichtigt werden möchten, wenn das Feature fertig ist, aber ich möchte auch, dass das Problem behoben wird, damit es hoffentlich früher bearbeitet wird :)

Große Fortschritte bei der Alarmierung insgesamt.
Für die Template-Variablen in Alerting fehlt es mir auch. +1 : D

=
Darüber hinaus kann es einen Fehler geben, wie Grafana erkennt, ob die in query verwendete Metrik die Vorlagenvariablen verwendet.

Wenn Sie eine Serie haben, die die Vorlagenvariablen indirekt verwendet, hindert Grafana Sie nicht daran, diese Serie als Warnung hinzuzufügen. Die Warnung funktioniert offensichtlich nicht richtig.

Siehe #K (es verwendet #D, das #A verwendet und #A verwendet templ. var):

Ich könnte es noch auswählen:

Vorlagen überall, was bedeutet, nirgendwo zu warnen.
Ich bin mir nicht sicher, wie die Benachrichtigung implementiert wurde, aber für ein einfaches Diagramm wird die Abfrage "übersetzt", Vorlagenvariablen werden durch Werte ersetzt, bevor die Datenquelle aufgerufen wird, richtig? Warum also nicht in diesem Fall? Da fast alle Abfragen Template-Variablen verwenden, ist das Alerting für mich, wie bereits gesagt, völlig irrelevant. Könnten Sie es bitte implementieren, damit wir die Alarmierung nicht außerhalb von Grafana verschieben müssen? Vielen Dank!

Ich denke, wir sollten erkennen, dass die Benachrichtigung mit Vorlagen nicht trivial ist, und ich denke, die ALL-Optionen sind der richtige Weg, weil wir nicht möchten, dass sich unsere Benachrichtigungen ändern, wenn jemand das Dashboard verwendet.
Aber grafana müsste immer noch neue Warnungen erstellen, wenn die Vorlagenabfrage neue Ergebnisse zurückgibt ... was ziemlich oft passiert, wenn wir unsere Apps skalieren.
Dies führt zu mehr Problemen, wenn Sie InfluxDB verwenden, da viele von uns Tags/Tag-Werte verwenden, denke ich, und es gibt keinen Zeitfilter für sie ... also würde Grafana Warnungen für alle Dienste erstellen, die jemals auf einem Host existierten. .

+1

Nur die Angabe der Datenquelle in der Benachrichtigung zuzulassen, wäre für mich in Ordnung. Es wird keine Logik brechen, und ich kann zumindest Produktions- und Staging-Umgebungen angeben, auf die ich achten muss.

ALLES ist eine Option, sicher. Flexibler wäre es, die Template-Variablen in der Abfrage zu erkennen und den Benutzer die Werte in der Alert-Condition-Konfiguration einstellen zu lassen. Das Beste, aber kompliziert wäre es, denke ich, mehrere Warnungen zu haben (genauso wie es mehrere Abfragen gibt), so dass eine andere Warnung für verschiedene Vorlagenvariablenwerte in der Abfrage eingerichtet werden könnte. Dies würde es dem Administrator beispielsweise ermöglichen, unterschiedliche Alert-Bedingungen für verschiedene Hosts einzurichten.

Mehrere Benachrichtigungsprofile wären großartig, aber für einen ersten Durchgang würde es viele Probleme lösen, wenn Sie einfach die gleichen Vorlagenauswahlen bereitstellen, die auf dem Dashboard im Benachrichtigungsbereich verfügbar sind.

Ich denke auch, dass es für jede Variable einen Umschalter geben sollte, um die Ergebnisse für diese Variable in einer einzigen Benachrichtigung zusammenzufassen. Dies ist wahrscheinlich nur für Vorlagenvariablen aktiviert, bei denen die Mehrfachauswahl aktiviert ist. Dies bietet eine einfache, aber effektive Methode, um die Ausführlichkeit von Benachrichtigungen zu steuern – Sie möchten möglicherweise nur einmal für mehrere verwandte Metriken benachrichtigen, aber für jeden Host benachrichtigen, bei dem eine Metrik fehlschlägt. Oder Sie möchten möglicherweise nur einmal über eine fehlerhafte Metrik benachrichtigen, unabhängig davon, wie viele Hosts betroffen sind.

Haben wir einen gezielten Meilenstein für diesen Fehler?

Ich hatte einige Probleme mit der Benachrichtigung bei komplizierten Abfragen und Abfragen von Vorlagenvariablen. Ich habe eine einfache Problemumgehung gefunden, die vielleicht nicht schön ist, aber für meinen Anwendungsfall funktioniert.
Es wird nur die Abfrage extrahiert, nachdem Sie sie erstellt haben, sodass keine Vorlagenvariablen und keine #ROW-Verweise vorhanden sind. Das könnte für Sie offensichtlich sein, es gibt keine Raketenwissenschaft, aber für mich war es lebensverändernd.

Ich bereite eine Abfrage vor:

extrahieren Sie es dann mit den Chrome-Entwicklungstools (kopieren Sie den Zielparameterwert):

Setzen Sie es in eine andere Zeile (wechseln Sie zuerst in den Bearbeitungsmodus um):

Richten Sie die Benachrichtigung ein:

Voila!

@siteshbehera Dies ist kein Fehler. Es ist ein Feature-Request.

Aber nein. Wir haben derzeit keinen Meilenstein dafür.

Grafana-Plug-in für künstliche Intelligenz sollte für diese Funktion im Commit enthalten sein.

Warten auf Vorlagen in Alerts zu +1

Ich bin auch sehr dafür, was calind im Eröffnungspost als mögliche Umsetzung angegeben hat. Es scheint genau dazu zu passen, wie viele (ich eingeschlossen) Vorlagen-Dashboards verwenden - wo Sie ein Dashboard haben, aber einige Variablen wechseln/begrenzen, um bestimmte Dinge manuell zu betrachten. Ich denke, das Beispiel der "server"-Variablen dürfte am passendsten sein. Dort würde die Template-Variable (ohne _all_-value) zu etwas ähnlichem wie ein „_tab_“ in meinem Dashboard – ich kann zwischen ihnen wechseln, um verschiedene Datensätze anzuzeigen. Es ist dann leicht anzunehmen, dass beim Einrichten einer Benachrichtigung die Benachrichtigung für jedes mögliche "_tab_" separat vorhanden wäre.

Warten auf die Unterstützung von Vorlagen in Alerts +1

Als früherer Benutzer von Librato, bei dem die Alarmierung teilweise in der Lage war, diese Vorlage zu erstellen, möchte ich mich mit einer ebenso teilweisen Lösung einbringen. In Librato wird jede Metrik mit einer „Quelle“-Variablen geliefert, und Warnungen in einem Diagramm würden automatisch pro Quelle angezeigt.

Ich denke, eine gleichwertige Lösung würde die hier angesprochenen Bedürfnisse befriedigen. Beim Erstellen einer Warnung sollten Sie in der Lage sein, einen einzelnen Vorlagenwert als „Quelle“ auszuwählen, und diese Quelle wird in der Warnung erwähnt, während alle anderen auf „alle“ gesetzt werden. Diese Lösung vermeidet zumindest das Kombinatorik-Problem, das Sie bekommen, wenn Sie die Verwendung mehrerer Template-Variablen zulassen.

Ich selbst setze einfach ein unsichtbares Max- oder Min-Diagramm über die Daten, die mich interessieren, und mache die Warnung darauf, nicht so leistungsfähig, aber immer noch eine funktionierende Lösung, bis dieses Problem gelöst ist.

Hallo, ich suche definitiv nach dieser Funktion, da alle meine Dashboards in den meisten Fällen zuvor Vorlagenabfragen verwenden, um (mindestens) mehrere Umgebungen zu unterstützen.

Gibt es einen Ort, an dem die Roadmap von Grafana verfolgt wird? Oder können wir auf irgendeine Weise sehen, ob Funktionen (wie diese) in einer Zukunft (nahe oder nicht so nahe) implementiert werden, ohne Mantainer auf Github anzustupsen? :)

Erstaunlich, wirklich gespannt auf diesen warten

+1

+1

Wir sind uns immer noch nicht sicher, wie wir das machen sollen.

Ich denke, die Wiederverwendung der ausgewählten Vorlagenvariable für die Benachrichtigung wäre gefährlich, da Benutzer nur eine Option anzeigen und dann vergessen können, wieder zu All oder etwas Breiterem zu wechseln. Ich würde mich bei einem solchen Verhalten nicht sicher fühlen. Warnregeln sollten extrem einfach zu verstehen und zu begründen sein. Explizite Regeln > magische Regeln.

Eine Lösung für dieses Problem wäre, zwei Werte für jede Vorlagenvariable zu haben. Eine für die Visualisierung im Dashboard und eine für die Benachrichtigung. Dies würde es ermöglichen, immer die breitere Option bei der Alarmierung zu haben und dennoch nur wenige Optionen in den Diagrammen auszuwählen. Das Verbinden dieser Werte sollte möglich sein, aber nicht das Standardverhalten.

Diese Lösung wäre ziemlich groß und komplex.

Ich habe zwei Lösungsvorschläge.

1. Ein kurzfristiger Vorschlag besteht darin, eine Warnoption hinzuzufügen, sodass im gerenderten Garph (dem per E-Mail gesendeten) nur Warnmetriken angezeigt werden. Dies würde das Durcheinander beseitigen, wenn das Warndiagramm Dutzende von Metriken enthält.

2. Eine langfristige Lösung wäre es, durch Vorlagenvariablen zu iterieren, sodass Sie eine eindeutige Warnung für jede Vorlagenwertkombination haben.

Wie ich bereits im November erwähnt habe. Für Prometheus-Benutzer ist es ausreichend, „All“ als Variablenwert zu verwenden, wenn die Abfragen richtig geschrieben sind ( some.metric{hostname=~"$Hostname"} ).

Sollte wohl auch sehr einfach umzusetzen sein.

@bergquist Ich denke, Option 2 geht in die richtige Richtung (eine teilweise Implementierung dessen, was ich in https://github.com/grafana/grafana/issues/6557#issuecomment-272588490 vorgeschlagen habe), es scheint nicht zu komplex zu sein, da der Code zur Behandlung der Vorlagen-Variablenauswahl bereits für das Dashboard vorhanden ist und die Var-Konfiguration nicht dupliziert werden muss, sondern nur die Auswahl. Ich glaube nicht, dass ich mir die Mühe machen würde, die Dashboard-Auswahl im ersten Durchgang bei dieser Funktion mit der Benachrichtigung zu verbinden.

Ich habe es gelöst, indem ich eine neue Metrikabfrage nur für die Warnung ohne die Vorlagenvariablen erstellt und sie in Grafana Version v4.1.1 deaktiviert habe (um sie aus dem Diagramm auszuschließen).

+1 zum Implementieren von Vorlagen-Variablen in Warnungen

+1 zum Implementieren von Vorlagen-Variablen in Warnungen

Betrifft dies _alle_ Versionen von Grafana? Oder war das eine Funktion, die vorher verfügbar war? Dies ist eine Art Deal Breaker für mich und es würde mir nichts ausmachen, eine frühere Version zu installieren.

@alejandroandreu Alerting wurde in Version 4 hinzugefügt, es hat nie mit Templating funktioniert.

+1 zum Implementieren von Vorlagen-Variablen in Warnungen

Ich möchte die Kombinationen auswählen/eingeben können, die die Warnungen auswerten sollen, da einige der von mir ausgeführten Umgebungen keine Produktionsumgebungen sind. Es gibt zwei Möglichkeiten, dies zu implementieren. Die erste ist expliziter, die zweite ist einfacher zu konfigurieren.

Geben Sie alle gewünschten Kombinationen manuell ein

• Diese Konfiguration sollte im Alert-Konfigurationsfenster angezeigt werden

Wenn ich zum Beispiel 3 Vorlagenvariablen habe: cloud , region und type , würde ich eine Tabelle füllen, die so aussieht:

| Wolke | Region | Typ |
|-------|------------|------|
| aws | us-ost-1 | Produkt |
| aws | us-west-1 | Produkt |
| azurblau | Zentrale USA | Produkt |

Die Tabelle sollte eine zusätzliche Zeile zum Einfügen neuer Zeilen und eine Löschschaltfläche für jede Zeile haben.

Geben Sie mögliche Werte ein und Grafana berechnet das kartesische Produkt

• Hinweis: Diese Konfiguration kann im Konfigurationsfenster für Vorlagenvariablen eingegeben werden

| Wolke | Region | Typ |
|-------|------------|------|
| aws | us-ost-1 | Produkt |
| azurblau | us-west-1 | |
| | Zentrale USA | |

Die Kombinationen, die für diese Eingabe erstellt werden, sind:

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

Aber Grafana kann mit dieser Situation umgehen, indem es die erste Variable ( cloud ) "eingibt" und dann die verfügbaren Werte aus der zweiten Variablen ( region ) filtert, bis es alle möglichen Kombinationen findet (Hinweis - es sollte iterativ für alle Variablen durchgeführt werden). Dies ist möglich, wenn Personen Abfragen in den Tags wie diese verwenden:

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

Und in diesem Fall sind die erzeugten Kombinationen in Ordnung (was der Tabelle in der ersten Option entspricht):

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

Ich hoffe, meine Vorschläge werden hilfreich sein.

Wir haben dieses Problem (OpenTSDB-Datenquelle) in einem etwas anderen Kontext – wenn Sie eine Vorlagenvariable verwenden, um ein Downsample-Intervall in der Metrik auszuwählen, schlägt die Warnungsabfrage mit Fehler 400 fehl. Ich verstehe die Schwierigkeiten bei der Implementierung einer allgemeinen Lösung, aber wir sind es verschiedene vorhandene Dashboards umgestalten müssen, um Warnmeldungen zu ermöglichen.

@dbcook klingt nach einem eindeutigen Problem, für das Sie wahrscheinlich ein separates Problem einreichen sollten.

Die Vorlagenerstellung ist wirklich eine großartige Funktion, ebenso wie die Benachrichtigung. Es ist besser, wenn sie reibungslos zusammenarbeiten, anstatt umständliche Problemumgehungen.

@tomekit Danke für die Problemumgehung, es sieht vielversprechend aus, während wir auf die tatsächliche Implementierung warten. Ich kann jedoch nicht finden, wo ich die Abfrage mit den Chrome-Entwicklungstools extrahieren kann, und kann daher den Zielparameterwert für die neue Abfrage nicht kopieren. Ich habe "Inspect Element" ausprobiert, aber ich habe Schwierigkeiten, "Name" oder "Headers" oder "Form Data" zu finden, die Sie auf dem Screenshot gezeigt haben.

Könnten Sie bitte die Schritte dazu veranschaulichen? Ihre Hilfe wird sehr geschätzt!

Danke

@mathurj Es ist die Registerkarte Netzwerk -> XHR. Hilft es jetzt?

Klicken Sie dann auf die Anfrage "Rendern".

Danke @tomekit Ich kann diese Seite jetzt sehen, aber ich kann keine Anfrage mit dem Namen "Render" sehen. Es gibt jedoch eine weitere Anfrage zu der Abfrage, die ich ausführe, die jedoch keinen "Ziel"-Parameter enthält.

Irgendwelche Hinweise, wie man mit der "Render"-Anfrage umgeht?

@mathurj Ich bekomme die "Render" -Anforderung, sobald ich auf eine der Grafiken in meinem Dashboard schaue und auf "Aktualisieren" klicke (obere rechte Ecke).

Habe es versucht, immer noch keine "Render" -Anfrage für mich :( Und auch kein "Ziel" -Parameter. Trotzdem danke für deine Hilfe @tomekit . Ich schätze, ich muss auf die tatsächliche Implementierung warten, was dem Aussehen nach eine Weile dauern könnte es. @bergquist @torkelo ?

ok arbeiten mit
some.metric{hostname=\~"$Hostname"}
in der Abfrage selbst ist in Ordnung,
aber es ist meine Datenquelle, die hier die Vorlage ist ...

Umgebung=\~"$Umgebung"
scheint nicht zu funktionieren ... irgendwie funktioniert das, habe ich etwas falsch gemacht? oder sollte ich die Vorlage loswerden :enttäuscht:

+2

Diese Funktion ist besonders nützlich, wenn Prometheus als Datenquelle verwendet wird!

Ich brauche das auch, aus ähnlichen Gründen wie oben erwähnt. Ich erwarte, dass dies als for each-Schleife über die gesamte Sammlung funktioniert, die die Vorlage definiert.

Wir brauchen das!!! :) 👍

Ich persönlich unterstütze diese Funktion auch. Wir testen mehr als ein System mit einer Reihe von Lasttests, die Verzögerungsmetriken generieren. Anstatt ein Dashboard zu haben, verwenden wir eine Variable, um zwischen den Datenquellen zu wechseln, die die Daten für die verschiedenen Systeme enthalten, um nur ein Board pflegen und nicht skripten zu müssen.
Daher wäre eine Unterstützung für Vorlagen in Warnungen sehr wünschenswert.

+1
das brauchen wir auch

+1
das brauchen wir auch

+1
das brauchen wir auch

Darf ich fragen, warum so viele Leute diese +1-Antworten "Daumen runter" geben??

@skygragon Es ist im Wesentlichen nutzloser Spam, wenn die Option vorhanden ist, dem ursprünglichen Beitrag +1 zu geben. Klicken Sie einfach auf das Daumen-hoch-Symbol im ersten Beitrag.

Vorlagenvariablen und Benachrichtigungen sind zwei der besten Funktionen von Grafana.
Traurig zu sehen, dass sie sich gegenseitig ausschließen.......

+1

@bergquist könnte Ihr Team dies noch einmal besprechen und hoffentlich einen Meilenstein setzen? Es ist die am häufigsten nachgefragte Funktion seit fast 2 Jahren und ich wette, dass einige Benutzer mit dieser Funktion zufrieden wären.

Es wurde noch keine gute Lösung vorgeschlagen, und wir sind uns immer noch ziemlich sicher, dass dies eine schlechte Idee ist, da zwei Funktionen vermischt werden, die unterschiedlichen Zwecken dienen. Template-Variablen werden für dynamische Dashboards und Exploration verwendet. Alert-Regeln können bereits mit Regex-/Wildcard-Abfragen dynamisch gemacht werden. Diese beiden zu mischen scheint eine schreckliche Idee zu sein, zumindest auf eine verständliche und vorhersehbare Weise.

Es gibt jedoch einige gute Gründe, es auf eine begrenzte Weise zu unterstützen, aber nicht sicher, ob es die extreme Komplexität wert ist, die es hinzufügen würde, und die Entwicklungskosten. Aber wir sind offen für Ideen, Vorschläge & PRs.

Das Problem ist, dass ich ziemlich viele Server habe, die ich überwache, UND sie werden dynamisch über Amazon erstellt, sodass ich zu einem bestimmten Zeitpunkt nicht weiß, wie viele Server aktiv sind.

Ich habe ein Diagramm mit Vorlagen, das die CPU für jeden Server anzeigt (zum Beispiel), also möchte ich auch dort warnen.

Aber Sie sagen, ich könnte dasselbe erreichen, indem ich Platzhalter verwende?

@ yesman85 hängt natürlich von Ihrem Zeitreihenspeicher ab. Die meisten unterstützen jedoch eine Form von Glob/Regex-Abfragesyntax, um auf mehrere Metriken abzuzielen, die einem Benennungsmuster folgen.

@torkelo Ich glaube, dies ist das erste Mal, dass diese Position öffentlich geäußert wird. Ich denke, hier liegt vielleicht ein Missverständnis vor – ich glaube nicht, dass Benutzer möchten, dass sich die für die Dashboard-Ausgabe ausgewählten Vorlagenwerte auf die Benachrichtigung auswirken, sondern dass beim Konfigurieren von Benachrichtigungen dieselben Vorlagenauswahlen verfügbar sind.

Relevante Umsetzungsvorschläge aus diesem Thread:
https://github.com/grafana/grafana/issues/6557#issuecomment -272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641 (Option 2)

Auch verwandte Probleme:
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

Diese Einschränkungen haben uns daran gehindert, Grafana für die Alarmierung bei Ärger zu verwenden, da die einzige Möglichkeit, diese Art von Arbeit derzeit zu tun, darin besteht, entweder eine Reihe separater versteckter Abfragen für die Alarmierung hinzuzufügen oder separate Dashboards für die Alarmierung und die Anzeige zu erstellen . Beide Optionen sind ein Albtraum für die Wartung und schränken das große Potenzial von Grafana für eine einfache Konfiguration und Interpretation der Überwachung durch die Benutzer eher ein.

Ich denke, mein obiger Vorschlag, inspiriert von Libratos quellenbasiertem Alerting, bietet eine begrenzte, verständliche und vorhersehbare Lösung, die fast alle der oben genannten Probleme abzudecken scheint.

In Grafana würde dies bedeuten, dass nur eine Vorlagenvariable für die Benachrichtigung verwendet werden könnte, und jeder Wert in dieser Variablen würde seine eigene Benachrichtigung generieren. Sie könnten möglicherweise auch eine Regex hinzufügen, um herauszufiltern, für welche Sie Warnungen erstellen möchten.

@pdf Ich stimme zu, dass https://github.com/grafana/grafana/issues/6041 eine große Einschränkung ist, die wir definitiv beheben wollen, die aber nichts mit diesem Problem zu tun hat. Es ist schlimm, dass wir es noch nicht behoben haben. Ich stimme zu, wir waren in den letzten Monaten auf der Alarmierungsseite etwas unterbesetzt, aber das wird sich bald ändern!

@danhallin das ist nicht dasselbe, scheint es würde sich in eine Abfrage in Grafana übersetzen, die auf viele Serien abzielt, indem Sie Platzhalter oder Glob-Ausdrücke in Ihrer Abfrage verwenden oder nur nach einer begrenzten Anzahl von Tags filtern? Librato-Warnregeln werden separat von Dashboards definiert, nicht wahr? Wie können sie also in eine Dashboard-weite Datenfilterfunktion übersetzt werden?

Eine Möglichkeit, dies zu tun, besteht derzeit darin, eine Reihe separater versteckter Abfragen für die Benachrichtigung hinzuzufügen, was ein Albtraum für die Wartung ist

Verstehen Sie, dass das Mischen von Alarmregeln in Ihre Diagrammvorlagen ein Alptraum ist. Denken Sie jedoch, dass die Unterstützung von Vorlagenvariablen bei der Benachrichtigung ein noch größerer Albtraum sein könnte. Wahrscheinlich eine dumme Frage, aber können Sie nicht Dashboards und Grafiken erstellen, die sich auf Alarmierung konzentrieren? und die Dashboards mit vielen Vorlagenvariablen zur Untersuchung und Fehlerbehebung belassen? Ich weiß, dass es wahrscheinlich viele Fälle gibt, in denen sie ähnlich wären, also fühlt es sich wie doppelte Arbeit an :( Das Problem mit Alarmregeln im Kontext eines Dashboards mit ein paar Vorlagenvariablen ist, wie es funktionieren und verständlich sein sollte und wie es sogar sein kann überhaupt umgesetzt werden.

Angenommen, eine Abfrage verwendet 2 Vorlagenvariablen, $A und $B, die jeweils 50 Werte haben. Würde dies dazu führen, dass die Warnregel 2500 Mal ausgewertet wird? Ich meine, wenn die Variablen "Einzelwert" sind, dh die Abfragen so gebaut sind, dass sie nur funktionieren, wenn $A und $B einen einzigen Wert haben, dann müssten wir das tun. Vielleicht kein Showstopper, wir müssten erklären, dass nur mehrwertige Variablen unterstützt werden. Es gibt wahrscheinlich noch viele weitere Einschränkungen und problematische Details, die es sehr schwierig machen, diese Funktion zu implementieren, zu verwenden und zu verstehen

Aber ich bin nicht 100% dagegen, denke, es könnte eine Möglichkeit geben, es auf eine begrenzte Weise zu tun (wie nur eine zu unterstützen
mehrwertige Variable). Es gibt auch den Anwendungsfall, mehrere Datenquellen zu haben und eine Datenquellenvariable in Ihrer Warnregel anvisieren zu können, um diese Warnregeln in vielen Rechenzentren / Umgebungen (mit separaten TSDBs) wiederzuverwenden, die dieser Anwendungsfall lösen müsste Die Verwendung einer Datenquellenvorlagenvariablen als Metrikabfrage mit Platzhaltern kann sie nicht lösen.

aber können Sie nicht Dashboards und Diagramme erstellen, die sich auf die Benachrichtigung konzentrieren? und die Dashboards mit vielen Vorlagenvariablen zur Untersuchung und Fehlerbehebung belassen? Ich weiß, dass es wahrscheinlich viele Fälle gibt, in denen sie ähnlich wären, also fühlt es sich wie doppelte Arbeit an :(

Ich habe meinen Kommentar tatsächlich bearbeitet, um auf diese Option zu verweisen (und ein paar der anderen Problempunkte im Zusammenhang mit Warnungen hinzugefügt). Wie Sie jedoch festgestellt haben, bedeutet dies, dass die Erstellung von Dashboards/Bereichen (und die Wartung, wenn all diese Abfragen aktualisiert werden müssen) mit der Anzahl der Vorlagenvariationen multipliziert wird, auf die Sie hinweisen möchten, und außerdem die Warnungsanmerkungen von ihrem Standort getrennt werden am nützlichsten in - Ein vorlagenbasiertes Dashboard mit Warnhinweisen kann sehr nützlich sein, um Korrelationen herzustellen, aber nicht so sehr, wenn Sie versuchen müssen, mehrere Browser-Registerkarten zu durchsuchen und zu versuchen, die Dinge in Einklang zu bringen.

Angenommen, eine Abfrage verwendet 2 Vorlagenvariablen, $A und $B, die jeweils 50 Werte haben. Würde dies dazu führen, dass die Warnregel 2500 Mal ausgewertet wird? Ich meine, wenn die Variablen "Einzelwert" sind, dh die Abfragen so gebaut sind, dass sie nur funktionieren, wenn $A und $B einen einzigen Wert haben, dann müssten wir das tun. Vielleicht kein Showstopper, wir müssten erklären, dass nur mehrwertige Variablen unterstützt werden. Es gibt wahrscheinlich noch viele weitere Einschränkungen und problematische Details, die es sehr schwierig machen, diese Funktion zu implementieren, zu verwenden und zu verstehen

Hier gibt es meiner Meinung nach zwei getrennte Probleme. Eine _ist_ (glaube ich) eng verwandt mit #6041, da möglicherweise der Wunsch besteht, Alarmbedingungen einzeln pro Serie/Vorlagenwert auszuwerten (der aggregierte Umschalter, den ich in einem früheren Kommentar erwähnt habe). Wenn wir das jetzt beiseite legen, glaube ich, dass der ideale Weg, um den Großteil dieses Problems zu lösen, darin besteht, mehrere Alarmkonfigurationen pro Panel zuzulassen und einfach eine variable Interpolation auf genau die gleiche Weise wie bei der Dashboard-Ausgabe durchzuführen: Benutzern die Auswahl einzelner oder Vorlagenwerte mit mehreren Werten beim Konfigurieren von Warnungsabfragen; Die Abfragen werden einmal pro Alarmkonfiguration ausgeführt, wobei die ausgewählten Werte ausgefüllt werden. und die Ergebnisse werden genau so interpretiert, wie sie es derzeit sind. Wenn ich nicht etwas grob missverstehe, sehe ich dies nicht als signifikante Zunahme der Komplexität und sollte recht benutzerfreundlich sein.

Die Möglichkeit, Vorlagenwerte auszuwählen, um einfach den Warnbereich einzuschränken, wäre auch ohne mehrere Warnkonfigurationen nützlich (wenn es hilft, diese Funktionalität in dieser Reihenfolge zu entwickeln), wäre aber mit mehreren Konfigurationen exponentiell wertvoller.

Es gibt auch den Anwendungsfall, mehrere Datenquellen zu haben und eine Datenquellenvariable in Ihrer Warnregel anvisieren zu können, um diese Warnregeln in vielen Rechenzentren / Umgebungen (mit separaten TSDBs) wiederzuverwenden, die dieser Anwendungsfall lösen müsste Die Verwendung einer Datenquellenvorlagenvariablen als Metrikabfrage mit Platzhaltern kann sie nicht lösen.

Mehrere Alarmkonfigurationen/-abfragen pro Panel würden eine Methode zum Umgang mit mehreren TSDBs bereitstellen, und eine Option könnte darin bestehen, das Gruppieren von Alarmabfragen zuzulassen, sodass Zustandsübergänge basierend auf dem Ergebnis aller Abfragen in der Gruppe erfolgen (ähnlich wie die Dinge derzeit funktionieren). für Serien). Scheint nicht allzu kompliziert zu sein.

Dies ist definitiv ein beliebtes Bedürfnis. Um nun Alerting zu erreichen, mussten wir umziehen
weg von Grafana und erstellen Sie unsere benutzerdefinierte Lösung mit Graphites Render
APIs-Rohdaten .. Ich glaube nicht, dass Warnungen in dynamisch / mit Vorlagen unterstützt werden
Daten sind zumindest mit Graphite komplex.

Ein weiterer Gedanke ist,. Warum Grafana einen Abschnitt „Warnungen“ hat, ist Teil des Dashboards
config, wenn dies als komplex angesehen wird. Sie können es wegschieben, um es zu trennen
Benachrichtigungsansicht, in der Benutzer ihre dynamische Abfrage einfach eingeben / konfigurieren können,
Intervall, Bewertungszustand da drüben.. Vielleicht könnte das wir bedeuten
Sie haben keine doppelten Dashboards. Macht Sinn?

BR,
Vishwa..

Am 23. August 2017 um 8:01 Uhr schrieb „Peter Fern“ [email protected] :

aber können Sie nicht Dashboards und Diagramme erstellen, die sich auf die Benachrichtigung konzentrieren?
und verlassen Sie die Dashboards mit vielen Vorlagenvariablen zur Erkundung und
Fehlerbehebung? Ich weiß, es gibt wahrscheinlich viele Fälle, wo sie sein würden
ähnlich, fühlt sich also wie Doppelarbeit an :(

Ich habe meinen Kommentar tatsächlich bearbeitet, um auf diese Option zu verweisen (und ein paar hinzugefügt
der anderen alarmbezogenen Schmerzpunkte). Wie Sie jedoch festgestellt haben,
Dies bedeutet eine Vervielfachung der Erstellung von Dashboards/Panels (und ggf. der Wartung).
diese Abfragen müssen aktualisiert werden) um die Anzahl der gewünschten Vorlagenvariationen
zu warnen, und trennt auch die Warnungsanmerkungen vom Standort
Sie können am nützlichsten sein in - einem vorlagenbasierten Dashboard mit Warnungsanmerkungen
kann sehr nützlich sein, um Korrelationen herzustellen, aber nicht so sehr, wenn Sie müssen
Versuchen Sie, mehrere Browser-Tabs zu durchsuchen und versuchen Sie, die Dinge in eine Reihe zu bringen.

Angenommen, eine Abfrage verwendet 2 Vorlagenvariablen, $A und $B, sie haben jeweils 50
Werte. Würde dies dazu führen, dass die Warnregel 2500 Mal ausgewertet wird? ich meine
wenn die Variablen "Einzelwert" sind, dh die Abfragen nur funktionieren
Wenn $A und $B einen einzigen Wert haben, müssten wir das tun. Keine Show
Stopper vielleicht, wir müssten erklären, dass nur Multi-Value-Variablen sind
unterstützt. Es gibt wahrscheinlich noch viele weitere Einschränkungen und problematische Details
das macht diese Funktion sehr schwer zu implementieren, zu verwenden und zu verstehen

Hier gibt es meiner Meinung nach zwei getrennte Probleme. Man ist (glaube ich) eng
bezogen auf #6041 https://github.com/grafana/grafana/issues/6041 , in
dass möglicherweise der Wunsch besteht, die Alarmbedingungen individuell pro auszuwerten
Serien-/Vorlagenwerte (der aggregierte Umschalter, den ich in einer früheren
Kommentar). Wenn wir das jetzt beiseite legen, glaube ich, dass dies der ideale Lösungsweg ist
Der Großteil dieses Problems besteht darin, mehrere Alarmkonfigurationen pro Panel zuzulassen, und
Führen Sie einfach die variable Interpolation auf genau die gleiche Weise wie für das Dashboard durch
Ausgabe - ermöglicht es Benutzern, Vorlagenwerte mit einem oder mehreren Werten auszuwählen, wenn
Warnabfragen konfigurieren; Die Abfragen werden einmal pro Alarm ausgeführt
config, wobei die ausgewählten Werte ausgefüllt sind; und die Ergebnisse werden
genau so interpretiert werden, wie sie derzeit sind. Es sei denn, ich bin grob
Da ich etwas falsch verstehe, sehe ich das nicht als signifikanten Anstieg an
Komplexität und sollte sehr benutzerfreundlich sein.

Die Möglichkeit, Vorlagenwerte auszuwählen, um den Umfang der Warnungen einfach einzuschränken, würde dies tun
immer noch nützlich sein, ohne mehrere Warnkonfigurationen (wenn es hilft, sich zu entwickeln
diese Funktionalität in dieser Reihenfolge), wäre aber exponentiell wertvoller
mit mehreren Konfigurationen.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
.

@danhallin das ist nicht dasselbe, scheint es würde sich in eine Abfrage in Grafana übersetzen, die auf viele Serien abzielt, indem Sie Platzhalter oder Glob-Ausdrücke in Ihrer Abfrage verwenden oder nur nach einer begrenzten Anzahl von Tags filtern? Librato-Warnregeln werden separat von Dashboards definiert, nicht wahr? Wie können sie also in eine Dashboard-weite Datenfilterfunktion übersetzt werden?

Ich sehe jetzt, dass das, was ich bespreche, im Grunde eine Kopie von ist: https://github.com/grafana/grafana/issues/6041

Ich unterstütze diese Feature-Anfrage gegenüber dieser.

Wir starten regelmäßig Server und wir haben Dashboards mit Vorlagen, die gemeinsame Dinge auf allen Hosts messen (Mem, HD, CPU usw.). Das Erstellen eines „Warnungs“-Dashboards mit Diagrammen für jede mögliche Kombination ist zu mühsam, viele der gewünschten Warnungen können über alle Hosts hinweg verallgemeinert werden. AFAIKT, dieses Problem fragt nach einer Möglichkeit, diesen Anwendungsfall zu ermöglichen, und würde in #6041 nicht gelöst. Es sei denn, ich vermisse etwas.

Wir schlagen nicht vor, ein Diagramm und eine Warnung für jede Kombination zu erstellen, sondern dass Ihre Warnungsabfrage Wildcards oder Regex verwendet, sodass sie alle Hosts usw. abdeckt. Dann haben Sie eine Warnung und ein Diagramm, die für Warnungen optimiert werden können und nicht mit ihnen konkurrieren Anforderungen für Fehlerbehebung und dynamische Filterung.

Für unseren Anwendungsfall haben wir eine Reihe von (potenziell) kurzlebigen Instanzen, die eine Echtzeitverarbeitung von Ereignissen bereitstellen – wir müssten benachrichtigt werden, wenn bestimmte von der Anwendung generierte Metriken auf 0 fallen. Wenn Instanzen jedoch entfernt oder angehalten werden, haben sie immer noch eine benannte Metrik die mit ihnen verknüpft sind und in einer direkten Wildcard-Suche auftauchen, was zu fälschlicherweise generierten Warnungen führt.

Ich habe dies umgangen, indem ich eine vorlagenbasierte, mehrwertige Variable (auf Alle gesetzt) ​​verwendet habe, die aus einer "einfachen JSON-Datenquelle" generiert wurde, die eine Wahrheitsquelle dafür enthält, welche Instanzen ausgeführt werden sollten - alles funktioniert perfekt. Leider, sobald ich versuchte, die Benachrichtigung zu aktivieren, wurde ich zu dieser Funktionsanfrage geführt :)

Ich bin mir nicht sicher, wie einzigartig unser spezieller Anwendungsfall ist, aber ich bin mir nicht sicher, ob es eine andere Möglichkeit gibt, ohne die Verwendung von Vorlagen darauf aufmerksam zu machen - im Moment müssen wir außerhalb von Grafana weiterhin auf diese Probleme aufmerksam machen (was eine Schande ist - wir sind sehr starke Grafana-Benutzer!)

+1

Ein Fall, in dem wir keines dieser Probleme haben, ist, wenn die Vorlagenvariable ein konstanter Typ ist. Zum Beispiel haben wir mehrere Dashboards, die sich auf eine konstante Variable verlassen, um die Daten auf diesem Dashboard auf eine bestimmte Ressource zu beschränken (der Grund, warum wir keine mehrwertige Variable verwendet haben, ist, dass jedes Dashboard unterschiedlich genug ist, um unterschiedliche Setups zu rechtfertigen, aber nahe genug ist um ein "Vorlagen"-Dashboard zu rechtfertigen). Zumindest in diesem Fall (konstante Variablen) muss sich nichts am aktuellen Alarmierungsverhalten ändern.

Gibt es Neuigkeiten zu diesem Thema?

Hallo,

Gibt es irgendwelche Hoffnungen, diese Funktion zu bekommen? Ich frage mich nur, wie andere Systeme diese Funktionen haben, da sie auch eine Art Vorlagen verwenden müssen, da der Agent, wenn wir ihn installieren, automatisch im Portal angezeigt wird und die Benachrichtigung auch dafür eingestellt werden kann. (Das ist meine Erfahrung mit New Relic).

@vishwanathh Mir gefiel der Ansatz, einen separaten Abschnitt für Warnungen zu haben (wenn es kompliziert ist, ihn im Diagrammfeld zu haben), in dem wir unsere Abfragen nur für Warnungen eingeben können. Auf diese Weise sehen unsere Benutzer das Platzhalterfeld (das für die Benachrichtigung verwendet wird) nicht.

Entschuldigen Sie das zusätzliche Rauschen, aber dies wäre eine wirklich großartige Funktion in Grafana.

+1, sehr sehr wichtiges Feature!

Wenn ich außerdem den Prometheus-Metrik-Abfrageausdruck ändern lasse, um die Vorlagenvariable zu entfernen, ist dies überhaupt nicht machbar. Ich denke also, dass diese Funktion am wichtigsten ist, damit Prometheus + Grafana in der Produktion landet!

Wie auch immer, bitte Team kann die Priorität berücksichtigen, danke!

Da 5.0 in Kürze auf den Markt kommt, würde ich gerne sehen, dass während der nächsten Release-Serie ein deutlicher Fokus auf die Warnungen gelegt wird. Wenn man sich die Reaktionen von Github ansieht, scheinen Benachrichtigungsmängel bei den Benutzern mit Abstand das größte Interesse zu haben.

Ich weiß, dass es aufgrund von UI/UX-Komplexitätsbedenken einige Zurückhaltung gab, diese Dinge anzugehen, aber ich bin nicht davon überzeugt, dass diese Bedenken unbedingt gerechtfertigt sind. Gibt es irgendetwas, das wir als Benutzer tun können, um die Planung/das Design zu unterstützen oder diese Probleme voranzutreiben, abgesehen von Pull-Requests mit tatsächlichem Code?

@torkelo Dies hat mir geholfen, Warnmeldungen für alle meine Hosts mithilfe von Tags einzurichten, und jetzt enthält jedes Warndiagramm mehrere Serien, die durch die Kombination von Tags gebildet werden. Alles schien gut zu funktionieren. Aber beim Durchsehen der Dokumente und anderer Probleme wurde mir klar, dass, wenn eine der Serien innerhalb des Diagramms bereits den Alarmzustand angenommen hat, Warnungen für andere Serien nicht ausgelöst werden, wenn sie auch das Limit überschreiten.

Das sind wieder Einschränkungen.

Danke.

Irgendwelche Neuigkeiten zu dieser Funktion?

Wie hoch ist der Aufwand für einen neuen Beitragenden, um diese Funktion hinzuzufügen?

+1

Bitte erlauben Sie die Verwendung von Vorlagenvariablen für Warnmeldungen.
+1

+1

Wir hoffen auf eine Lösung.

+1

Ich möchte hier kein totes Pferd schlagen, aber wir haben das gleiche Problem, und ich möchte einen Kontext dafür liefern, warum die bestehenden Vorschläge nicht unter allen Umständen funktionieren. Ich habe auch ein paar Ideen für Problemumgehungen, aber warum brauchen wir _einige Funktionen_, damit die Problemumgehungen ausreichend sind.

Für alle folgenden Szenarien verwenden wir eine einzelne Vorlagenvariable: $env

„Warum nicht einfach Warn-Dashboards erstellen?“

Wir möchten auf ein paar verschiedene Umgebungen aufmerksam machen, nicht nur auf die Produktion. Also müssten wir jetzt dieselbe Metrik an _mindestens_ 3 verschiedenen Stellen haben (das Fehlerbehebungs-Dashboard mit allen Metriken, nicht nur die Metrik, für die wir warnen; das Produktwarn-Dashboard; das Integrationswarn-Dashboard). Dies kann ziemlich schnell außer Kontrolle geraten und ist anfällig für Benutzerfehler.

Ebenso wichtig ist, dass dadurch ein Großteil des Gewinns aus automatisierten Anmerkungen von Warnungen zunichte gemacht wird. Wenn ich von meinem Erkundungs-Dashboard zu meinem Alarm-Dashboard hin und her wechseln muss, um die Anmerkungen für den Beginn und das Ende eines Ereignisses anzuzeigen, wird das ziemlich mühsam.

Versuchte Lösung

Um dies zu umgehen, haben wir doppelte Metriken _speziell für Benachrichtigungen_ zu unseren Dashboards hinzugefügt. Wenn es also eine Metrik gibt, für die wir warnen möchten, gehen wir zum Panel und fügen explizite Metriken für diese Warnungen hinzu (und blenden sie aus).

Unsere Serienliste für ein bestimmtes Panel, das gewarnt werden muss, sieht folgendermaßen aus:

Mit der als ausgeblendet markierten Serie ohne Vorlage. Dann legen wir auf der Registerkarte "Warnungen" Schwellenwerte für _diese_ Serien fest, nicht für die Variablenserien.

Probleme mit dieser Lösung

Das funktioniert aber nicht großartig. Zum Beispiel:

Wie Sie sehen können, erlaubt uns das Alerts -Bedienfeld nicht anzugeben, _welche Umgebung_ warnt – also müssen wir in die Alerts eintauchen, um herauszufinden, welche Umgebung im Moment gebohrt wird. Eine einfache Lösung für dieses Problem könnte jedoch darin bestehen, dass die Beschreibung so ausführlich ist wie das Bedienfeld „Alarmverlauf“, das Zustandsübergänge anzeigt:

Dies ist zumindest etwas hilfreich, aber selbst in diesem Panel gibt es keinen Hinweis darauf, welche Warnung zu Healthy zurückgekehrt ist (die Beschreibung aus dem obigen Screenshot wurde von dem Alias ​​abgeleitet, den wir für die Serie festgelegt haben, falls sich jemand fragt, wie um wenigstens so viel zum Vorschein zu bringen).

Dinge, die helfen würden, bis dieses spezielle Ticket gelöst ist

• Erlauben Sie die Option zum Anzeigen des Serien-Alias ​​anstelle einer getippten Beschreibung für die Warnung (auf diese Weise kann der Alias ​​zumindest die $-Variable angeben, für die er alarmiert)
• Erlauben Sie den Zustandswechsel zurück zu gesund, um auch den Serien-Alias ​​anzuzeigen (im Verlaufs-Screenshot oben).
• Erlauben Sie einen Legendenwert für aktive Warnungen (unter Verwendung des Serienalias, den ich annehme) für ein bestimmtes Panel

Dinge, bei denen ich nicht sicher bin, wie ich sie beheben soll

Anmerkungen zu Diagrammen, bei denen Warnungen für mehrere Umgebungen/Variablen konfiguriert sind:

Damit können wir nicht wirklich sagen, welche Warnung ausgelöst wird, ohne in das Panel zu gehen. Der Legendenvorschlag könnte helfen, dies zu verdeutlichen, bringt aber nicht viel für die Anmerkung, wenn nicht das richtige $env ausgewählt ist (im obigen Bild int , aber prod ist die im Dashboard ausgewählte Variable, daher zeigen wir Anmerkungen aus der int -Warnung über dem Diagramm mit prod an.

+1

Plus eins :)

Bitte hören Sie auf, diesem Problem +1 zu geben. Es generiert unnötige Spam-E-Mails. Die Möglichkeit, eine Reaktion auf einen Kommentar zu einem Github-Problem hinzuzufügen, gibt es schon seit einiger Zeit, und über 429 Leute haben herausgefunden, wie sie den ersten Kommentar mögen können, anstatt alle Abonnenten zu spammen.

Bitte, wir brauchen diese Funktion wirklich, wir würden gerne Vorlagen verwenden, aber in unserem Fall ist es am wichtigsten, ein klares Warnsystem zu haben. Um dies zu umgehen, vermeiden wir die Erstellung von Vorlagen in unserem Dashboard ... es ist ein Durcheinander.

Ich stimme zu und diese Funktion wird uns sehr helfen !!!!

+1 bitte

wir brauchen das

+1 bitte. Es ist wirklich nötig.

@bergquist @torkelo können wir dieses Problem bitte sperren, um den +1-Spam zu stoppen?