Grafana: Gebäudealarmsystem für grafana

Ich helfe gerne dabei! Mein Vorschlag wäre, sich an die Richtlinien im Nagios-Stil zu halten. Auf diese Weise können die Tools problemlos mit anderen Monitoring-Tools verwendet werden. zB Nagios, Zenoss, Icinga, etc..

Das Wichtigste an dieser Funktion ist, die grundlegende Architektur richtig zu machen.

Einige Fragen, die ich untersuchen möchte
1) Welche Komponenten werden benötigt, wie werden sie ausgeführt (in proc in grafana, out of proc),
2) Wie sollten die Dinge koordiniert werden.
3) Sollten wir "in stream"-Warnungen ignorieren (nur auf Pull-basiert konzentrieren)

Gehen Sie näher auf 1) ein
Ich mache mir Sorgen, grafana-server zu einem Monolithen zu machen. Ich möchte einen Weg finden, grafana-server in Dienste zu unterteilen, die stärker voneinander isoliert sind (und entweder inproc oder als separate Prozesse ausgeführt werden können). Das war so der Plan mit der Busabstraktion. Eine andere Möglichkeit wäre, die Alerting-Komponente nur über die HTTP-API mit Grafana zu sprechen, könnte die Integration einschränken, nicht sicher.

Ich stimme Torkelo zu. Nach meiner Erfahrung mit anderen Projekten, bei denen alles "eingebaut" ist, kann die Fehlersuche ziemlich umständlich werden. Ich mag die Idee, dass der Dienst extern ausgeführt wird, aber eine nette Konfigurationsseite in Grafana, die über die HTTP-API mit dem Dienst kommuniziert, um alle Warnungen zu verwalten. Auch für groß angelegte Bereitstellungen wäre dies wahrscheinlich eine Voraussetzung, da sich die Leistung schließlich verschlechtern würde (ich hätte dies zumindest als Konfigurationsoption).

Integrieren wir in die aktuellen Schwellenwerteinstellungen des Grafana-Graphen (die derzeit nur für die Visualisierung, nicht für die Verarbeitung bestimmt sind)? Wenn der Ausdruck eine Schwellenwertprüfung ist, könnten wir automatisch eine Schwellenwertlinie anzeigen

Ich denke, das könnte ein guter Anfang sein. Warnen, wenn es eingestellt ist, tun Sie es nicht, wenn es nicht ist.

Zurück zu Nummer 1. Ich denke, wenn der Bootsmann-Dienst separat laufen könnte, aber dennoch die Möglichkeit hätte, alles vollständig über Grafana zu konfigurieren, wäre das meiner Meinung nach ideal.

Mach weiter so mit der tollen Arbeit.

Das einzige Manko, das ich bei bosun gesehen habe, sind die Datenquellen, die es verwenden kann. Wenn Sie die Sprache zum Ausdrucken von Bootsmannwarnungen nutzen könnten, aber auch vorhandene Datenquellen integrieren könnten, die über die reguläre Grafana-Benutzeroberfläche konfiguriert werden, wäre dies sicherlich ideal.

Die Möglichkeit, Warnschwellen darzustellen, wenn Sie sich in deren Nähe befinden, sowie automatische Push-Anmerkungen, wenn sie in meinem Kopf ausgelöst wurden, machen eine ideale Benutzeroberfläche mit einem einzigen Fenster aus.

Ich freue mich auf die Arbeit, die hier geleistet wird!

1. Es sollte die Schwellenwerte verwenden, die im Dashboard definiert sind, um zu alarmieren
   Lassen Sie es uns einfach halten; Wenn das Dashboard die Farbe für die Warnung anzeigt, sollte es eine Warnung sein.
2. Dies ist wahrscheinlich etwas außerhalb des Grafana-Server-Prozesses selbst.
   ... Etwas, das die restliche API verwenden würde, um die Dashboards und ihre Einstellungen abzukratzen und sie zu rendern und mit einem externen Befehl zu alarmieren.
3. Alarmstufe; nur ein Kästchen zum Ablegen im Editor, dass dieses Dashboard überwacht werden soll; und es sollte jede Minute überprüft werden. Wenn keine Daten vorhanden sind, sollte es dennoch für einen bestimmten Zeitraum alarmieren? (Kontrollkästchen)

Zuletzt; Da wir mehr von Grafana abhängig sind, gebe ich zu, dass ich sagen kann, dass 2. etwas sein könnte, wofür ich bereit wäre zu zahlen.

Ich bin neugierig, warum die Leute denken, dass dies überhaupt in Grafana aufgenommen werden sollte?
Grafana empfängt oder speichert diese tatsächlichen Daten weder, sondern visualisiert sie "nur". Jedes Warnsystem sollte stattdessen auf den Daten im Metric Store basieren.
Wenn dies wirklich in Grafana integriert ist, hoffe ich, dass dies deaktiviert werden kann, da wir hier bereits Icinga für die Benachrichtigung verwenden, sodass jede Art von Benachrichtigung in Grafana die GUI nur noch mehr überladen würde, obwohl sie überhaupt nicht verwendet würde.

Absolut richtig @dennisjac; Grafana gibt nur Dinge wieder.

Aber da wir die Dinge serverseitig verschoben haben, ist es nicht mehr nur das Client-Rendering; die Möglichkeiten eines Arbeitsprozesses, der Ihre Metriken überprüfen und alarmieren könnte; ist weniger schwierig.

Daten befinden sich in einer Datenbank; vorausgesetzt, es ist mit den Daten bestreut, die es anweisen, die Metrik zu überprüfen ...

Einige Leute mögen zustimmen oder nicht zustimmen, dass wir die Ströme nicht überqueren und Grafana dazu bringen sollten, mehr zu tun, als es (grob) zu visualisieren, aber ich bin nicht sie.

Ich bin nicht wirklich gegen das Feature für Leute, die es integriert haben möchten, aber ich hoffe, es wird für Leute optional gemacht, die bereits Überwachungs- / Warnsysteme zur Verfügung haben.

Das neue Telegraf-Projekt (Metrikkollektor von den Influxdb-Jungs) befasst sich auch mit Überwachungs-/Alarmierungsfunktionen, die aus dem gleichen Grund nicht gemocht werden. Dies habe ich hier konkretisiert:
https://influxdb.com/blog/2015/06/19/Ankündigung-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

Ich denke, Torkelo hat wirklich gute Arbeit geleistet, indem es uns Funktionen in Grafana2 zur Verfügung gestellt hat, die wir nicht aktivieren müssen.

Was influxdb angeht, werden sie irgendwie Geld verdienen müssen; entweder aus der Unterstützung von influxdb und professionellen Dienstleistungen oder Produkten dafür.

Letzteres klingt viel praktikabler

Ein anderer Blickwinkel dazu. Es scheint eine bevorstehende Unterstützung für Elasticsearch als Metrikspeicher für Grafana zu geben. Bosun kann jetzt Elasticsearch nach Protokolldaten abfragen.

Wäre es bei der Gestaltung des Alerting-Systems sinnvoll, auch Alerts aus Log-Daten zuzulassen? Vielleicht kein Feature für die erste Version, aber etwas, das später implementiert werden kann.

Auch ich stimme der Idee der Aufteilung der Prozesse zu. Lassen Sie Grafana die Schnittstelle zum Anzeigen und Erstellen von Warnungen, und lassen Sie die Warnungen von etwas anderem verwalten. Wenn der Benachrichtigungsteil api-basiert ist, können auch andere Tools damit interagieren.

+1 zu Benachrichtigung. Außerhalb der DevOps-Nutzung müssen Anwendungen, die für Endbenutzer entwickelt wurden, benutzerdefinierte Warnungen bereitstellen. Schön, es im Visualisierungstool zu haben...

+1 Dies schließt die Schleife - der Vorschlag, Metriken zu erhalten.

+1 Warnungen von Grafana + ein horizontal skalierendes Backend von InfluxDB werden sie zum Standard für Metrik-Warnungskonfigurationen machen

+1 Ich würde mich über eine horizontale Skalierung der Benachrichtigungen auf mehreren Grafana-Knoten freuen.

Es wäre toll, wenn man ein "Entprellung"-ähnliches Verhalten mit einer Warnung in Verbindung bringen könnte. Ich möchte beispielsweise nur dann eine Warnung auslösen, wenn der definierte Schwellenwert X für N Minuten überschreitet.

Ich habe dies bei einigen Alarmierungstools gesehen, leider verwenden wir derzeit Seyren, das eine solche Option anscheinend nicht bietet. Wir verwenden Grafana für unsere Dashboard-Entwicklung und freuen uns darauf, das Alerting auch in Grafana zu integrieren. Mach weiter so.

Wir haben zwei Anwendungsfälle:

• Infrastruktur-Team erstellt Warnungen durch Bereitstellungstools wie gewohnt im gemeinsamen Monitoring-Stack (gemeinsame Clusterprüfung oder Systemprüfungen in nagios-freundlichem System)
• Softwareentwickler erstellen App-Metriken über Grafana

Wir würden uns über ein einheitliches Warnsystem freuen, das Warnungen, Klappenerkennung, Eskalation und Kontakte handhabt. Das hilft uns, Ereignisse/Vorgänge in derselben Quelle der Wahrheit aufzuzeichnen und zu korrelieren. Viele Systeme haben das Alarmierungsproblem gelöst. Ich hoffe, dass Grafana dies langfristig besser machen kann, kurzfristig wäre es hilfreich, bestehende Systeme nicht neu zu erfinden.

Ein Vorschlag ist, dass Grafana eine API zum Extrahieren der Überwachungsdefinition (Alarmstatus) bereitstellen kann, und Drittanbieter können Konfigurationsexport-Plugins beisteuern. Dies wäre in unserem Anwendungsfall zum Exportieren der Nagios-Konfiguration sehr ideal.

Noch wichtiger ist, dass ich auch gerne eine integrierte Anomalieerkennungslösung sehen würde!

Am 15. Juli 2015 um 17:40 Uhr schrieb Pierig Le Saux [email protected] :

+1 Ich würde mich über eine horizontale Skalierung der Benachrichtigungen auf mehreren Grafana-Knoten freuen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Ich stimme @activars zu. Ich verstehe nicht wirklich, warum eine Dashboard-Lösung Warnungen handhaben sollte, was bei vielen anderen Tools, die meistens recht ausgereift sind, ein mehr oder weniger gelöstes Problem ist. Mach eine Sache und mach es gut.

IMHO wäre es sinnvoller, sich auf den _Integration_-Teil zu konzentrieren.

Beispiel: Definieren Sie dynamische Warn-/Krit-Schwellen in grafana (zB wie im @Dieterbe- Beispiel oben) und stellen Sie eine API (REST?) bereit, die den Zustand (normal, warn, crit) genau dieses Graphen zurückgibt. Ein Nagios, Icinga, Bootsmann etc. könnte alle "Monitoring" aktivierten Graphen (ein weiteres API-Feature) anfordern, durch die einzelnen Zustände iterieren und die notwendigen Alarme durchführen.

In unserem Fall sind Servicekataloge und definierte Aktionen der schwierige Teil - welcher Service ist wie geschäftskritisch, wohin sollen E-Mails gesendet werden, flattern usw. Auch um die Benutzer- / Gruppenverwaltung in grafana müssen Sie sich nicht kümmern, die die meisten Unternehmen bereits in a zentrale Stelle (AD, LDAP, Crowd etc.) und in das Alerting-System integriert.

Außerdem ist zu bedenken, dass im Gegensatz zu einer Dashboard-Lösung die Qualitätsanforderungen an ein Alerting-Tool in Bezug auf Zuverlässigkeit, Belastbarkeit, Stabilität etc. deutlich höher einzuschätzen sind, was einen nicht zu unterschätzenden (Test-)Aufwand verursacht.

Was ist auch mit nicht-zeitreihenbezogenen Prüfungen, wie Aufrufen eines Webservice, Pingen eines Computers, Ausführen von benutzerdefinierten Skripten ... möchten Sie das auch in grafana? Ich denke, die Bootsmannadoption würde all dies bieten, aber ich bin damit nicht wirklich vertraut.

Auf der anderen Seite kann ich mir vorstellen, wie ein einfaches Warnsystem viele Benutzer glücklich machen würde, die keine gute Alternative haben, aber dies könnte vielleicht mit einigen Beispielintegrationsmustern für andere Warntools gelöst werden.

So sehr ich möchte, dass Grafana alle meine Probleme löst, ich denke, Falkenbt hat damit den Nagel auf den Kopf getroffen.

Eine API zur Bereitstellung der genannten Daten, einige Installationen in bosun und einige Integrationsmuster mit gängigen Benachrichtigungsplattformen sind sehr sinnvoll.

Herzlichen Glückwunsch zu deinem neuen Job bei raintank @Dieterbe! Ich lese Ihren Blog schon seit einiger Zeit und Sie haben einige wirklich fundierte Ideen zur Überwachung, insbesondere in Bezug auf Metriken und ihren Platz bei der Alarmierung. Ich bin zuversichtlich, dass Sie einen guten Weg finden werden, Alerting in grafana zu implementieren.

Wie Sie wahrscheinlich zustimmen würden, machen die Leute hinter Bosun die Alarmierung so ziemlich richtig. Das Fehlen von Bootsmann sind eigentlich die Visualisierungen. Ich würde gerne Bosun hinter der Grafana-Benutzeroberfläche sehen. Die Kombination von Grafanas-Dashboard und Bootsmann-Alarmierung hinter derselben Schnittstelle würde eine großartige und vollständige Überwachungslösung ergeben.

Außerdem denke ich, dass es schade wäre, die Open-Source-Monitoring-Community weiter zu fragmentieren, Ihre Ideen zum Monitoring scheinen wirklich mit den Ideen der Leute hinter Bosun kompatibel zu sein. Wenn Sie sich zusammenschließen würden, wäre das Ergebnis sicher großartig.

Wo ich arbeite, verwenden wir Elastic für Protokolle/Ereignisse und haben gerade damit begonnen, InfluxDB für Metriken zu verwenden. Wir haben verschiedene Lösungen für die Überwachung untersucht und tendieren derzeit zu Bosun. Wir verwenden Grafana bereits für Dashboards, möchten aber auf alle unsere Überwachungsinformationen über dieselbe Schnittstelle zugreifen. Es wäre großartig, wenn Grafana diese Schnittstelle werden könnte.

Mach weiter so und viel Erfolg!

An einer verwandten Tangente haben wir den Alerting-Teil durch die Integration von grafana mit riemann zum Alerting-Working gebracht. War eine schöne Übung, die Interna von grafana kennenzulernen :).

Bei Riemann war das einfacher, da die Konfiguration nur Clojure-Code ist. Ich kann mir vorstellen, dass diese Integration in Bootsun schwieriger wird.

Hier sind ein paar Screenshots davon in Aktion

Zu den Änderungen am Grafana-Teil gehörten das Hinzufügen eines "/alerts"- und eines "/subscriptions"-Endpunkts und die Kommunikation mit einer anderen kleinen API, die für Riemann oben sitzt, um den Crud zu erledigen.

Das Schöne ist, dass die Änderungen in den Alert-Definitionen sofort widergespiegelt werden, ohne dass ein SIGHUP an riemann gesendet werden muss. Das Aktivieren/Deaktivieren von Zeitintervallen für Zustandsänderungen ist also nur eine Frage der Änderung in der Benutzeroberfläche und der Weitergabe dieser Änderung an Riemann.

Ich habe diese Integration noch nicht bewertet, aber ich denke nicht, dass sie so schlimm sein wird. Werde darüber bloggen, nachdem ich den Code aufgeräumt habe und sobald er live geht.

Der ganze Grund, warum wir dies getan haben, war, dass die Leute diese Warnungen und Benachrichtigungen einfach über eine sehr vertraute Benutzeroberfläche einstellen können und uns nicht damit belästigen, Riemann-Konfigurationen zu schreiben :).

@sudharsh deine Implementierung klingt wirklich interessant. Planen Sie, dies in die Wildnis zu entlassen?

viele gute ideen, danke an alle.
Inspiriert von einigen Kommentaren und dem https://github.com/pabloa/grafana-alerts-Projekt von @pabloa haben wir uns entschieden, uns in erster Linie auf die Benutzeroberfläche und UX zum Konfigurieren und Verwalten von Benachrichtigungsregeln als Teil desselben Workflows von . zu konzentrieren Bearbeiten von Dashboards und Panels. Grafana würde diese Regeln irgendwo speichern und einen einfachen Zugriff darauf ermöglichen, damit andere Skripte oder Tools die Benachrichtigungsregeln abrufen können.
Vielleicht über eine Datei, einen API-Aufruf, einen Abschnitt in der Dashboard-Konfiguration oder einen Eintrag in der Datenbank.
(Ich mag die Idee, es als Teil der Dashboard-Definition selbst zu haben, damit Open-Source-Projekte mit Grafana-Dashboard-Json-Dateien für sie geliefert werden können, in denen Benachrichtigungsregeln enthalten sind, die jedoch nicht unbedingt standardmäßig aktiv sind eine Datenbank scheint robuster zu sein)
In jedem Fall möchten wir einen einfachen Zugriff bieten, damit Sie die Konfiguration für jedes andere System generieren können, das Sie verwenden möchten, das die Benachrichtigungsregeln tatsächlich ausführt und die Ereignisse verarbeitet. (ab hier werde ich dies als "Handler" bezeichnen).
Ein solcher Handler könnte Nagios oder Sensu oder Bosun sein, ein Tool, das Sie schreiben, oder der Lackmus-Alert-Scheduler-Executor, der ein Handler ist, den Sie in Grafana kompilieren können, der eine nette und einfache Integration bietet, die von Bosun unterstützt wird, aber wir möchten es wirklich Stellen Sie sicher, dass Sie jedes gewünschte System verwenden können.

Solange Ihr Handler das Abfragen des von Ihnen verwendeten Datenspeichers unterstützt. Wir würden mit einem einfachen statischen Schwellenwert beginnen, aber später auch die Auswahl von Reduktionsfunktionen, booleschen Ausdrücken zwischen mehreren Bedingungen usw.

@sudharsh das ist ein sehr schöner Ansatz. Mir gefällt, wie Ihre Lösung direkt mit einer Remote-API kommunizieren kann, wobei der oben beschriebene Zwischenschritt umgangen wird (natürlich bedeutet dies, dass sie nur für 1 bestimmtes Backend funktioniert, was wir zu vermeiden versuchen), und dass sie die Konfiguration automatisch neu laden kann. (Sie haben Recht, bosun unterstützt es derzeit nicht, vielleicht in der Zukunft. FWIW, der Lackmus-Handler handhabt das Problem und verwendet den Ausdrucksauswertungsmechanismus von bosun). Ich habe mich nie wirklich mit Riemann beschäftigt. Meistens habe ich mir Sorgen gemacht, dem Stack eine so andere Sprache hinzuzufügen, die nicht viele Leute verstehen oder debuggen können, wenn etwas schief geht. Aber ich bin sehr gespannt, mehr über Ihr System und den CLJ-Code von Riemann zu erfahren. (Ich würde es lieben, wenn mein Verdacht falsch ist)

@dennisjac ja, es wäre optional.
@elvarb es gibt ein Ticket für ES als Datenquelle . Tatsächlich besteht das Ziel darin, dass, wenn grafana das Rendern von Daten aus einer bestimmten Datenquelle unterstützt, es auch das Erstellen von Benachrichtigungsregeln dafür unterstützt. Was die Abfrageausführung/Abfrage betrifft, hängt dies natürlich davon ab, für welchen Handler Sie sich entscheiden. (für den Lackmus-Handler beginnen wir mit den beliebtesten wie Graphit und Influxdb)
@rsetzer : stimmt, es ist gut, angeben zu können, wie lange ein Schwellenwert überschritten werden soll, bevor wir auslösen
@falkenbt : Ich glaube, viele Dinge können als Zeitreihenabfrageproblem formuliert werden (zum Beispiel das Pings-Beispiel). Aber Sie haben Recht, einige Dinge sind nicht wirklich zeitreihenbezogen und diese liegen außerhalb des Rahmens für das, was wir hier aufbauen möchten. Und ich denke, das ist in Ordnung: Wir möchten die beste Möglichkeit bieten, Alarme auf Zeitreihen zu konfigurieren und zu verwalten und eine Integration mit anderen Systemen anzustreben, die vielleicht mehr für den Fall "misc scripts" optimiert sind (wie Nagios, Icinga, Sensu, .. .). In Bezug auf Bedenken wie Lieferzuverlässigkeit, Eskalationen usw. könnten Sie einen Dienst wie Pagerduty einbinden.
@activars & @falkenbt scheint dies Ihren Erwartungen zu entsprechen oder was könnte Ihrer Meinung nach speziell verbessert werden?
@jemilsson danke! und genau so sehe ich es: bosun ist großartig im alarmieren, aber nicht gut im visualisieren. Grafana ist großartig in Visualisierung und UX, hat aber keine Warnungen. Ich versuche, eine Zusammenarbeit voranzutreiben, die mit der Zeit wachsen wird, denke ich

Hat jemand eine Idee, welche Art von Kontext in Benachrichtigungen wie E-Mails gesendet werden soll?
Zumindest sollte die Benachrichtigung eine Visualisierung der Daten enthalten, auf die Sie aufmerksam machen, aber es sollte möglich sein, andere verwandte Grafiken einzuschließen. Hier könnten wir beim Generieren des Benachrichtigungsinhalts das PNG-Rendering-Backend von grafana verwenden. Ich denke auch darüber nach, die Snapshot-Funktion von Grafana zu nutzen. Erstellen Sie beispielsweise beim Auslösen einer Warnung eine Momentaufnahme eines bestimmten Dashboards, um den Kontext zu erhalten.
und vielleicht könnte dieser Snapshot (HTML-Seite) in der E-Mail enthalten sein, oder das könnte ein bisschen zu viel Daten/Komplexität sein. Außerdem wären die Javascript-Funktionen in E-Mail-Clients sowieso nicht verfügbar (Sie könnten also nicht in der Lage sein, Diagramme in einer E-Mail zu vergrößern). Vielleicht könnten wir von der E-Mail zu einem gehosteten Dashboard-Snapshot verlinken.

Ich mag den allgemeinen Ansatz von Docker - Batterien enthalten, aber herausnehmbar. Eine grundlegende Benachrichtigungsimplementierung, die ausgetauscht werden kann, wäre also imho ein guter Ansatz.

influxdb wird für Benachrichtigungen unterstützt? oder nur Graphit?

Eine Sache, die ich gerne sehen würde, ist die Idee von hierarchischen Alert Trees. Es werden einfach zu viele Facetten überwacht und eigenständige Warnzustände haben eine unüberschaubare Kardinalität. Mit einem Hierarchiebaum kann ich all diese Warnungen auf niedriger Ebene definieren, die auf mittlere Ebene aufrollen. Warnungen auf mittlerer Ebene, die auf hohe Ebene aufrollen ...

Daher nimmt jede zusammengerollte Warnung automatisch den hohen Schweregrad aller darunter liegenden Kinder an. Auf diese Weise kann ich mit einer viel geringeren Analysefläche einen genauen Eindruck vom Systemzustand erhalten [und verwalten].

Dies ist ein Beispiel, das ich einem alten Dokument entlehnt habe, das ich vor einiger Zeit geschrieben habe. Ja, bitte schmunzeln Sie über die Verwendung des Wortes "Struts". Es ist ALT ok? Dies stellt eine sehr einfache Hierarchie für einen Server dar.

Irgendwann erfährt der Server eine anhaltende CPU-Auslastung von 75%, sodass diese Warnungen in einen Warnzustand versetzt werden: CPU-# --> CPU --> Host/OS --> System

Wenn man sich wirklich einsetzte, könnte man mit einem Indikator ein ganzes Rechenzentrum im Blick behalten. (ja, nicht wirklich, aber das dient als Denkübung)

Warum kein Graphit-Beacon verwenden ? Ich denke, Sie können Graphit-Beacon, das sehr leicht ist, mit Grafana verbinden.

@felixbarny Ich mag diese Terminologie. wir werden diese Formulierung wahrscheinlich übernehmen.
@JulienChampseix ja, der Standardhandler würde/wird influxdb unterstützen
@nickman das ist interessant. es entspricht tatsächlich dem Endziel, das wir vor Augen haben, nämlich in der Lage zu sein, Warnungen auf sehr hohem Niveau zu erstellen, die detailliertere Warnungsregeln und -informationen enthalten/von diesen abhängen können. bosun tut dies bereits, und langfristig wollen wir diese Funktionalität über eine benutzerfreundlichere Oberfläche zur Verfügung stellen, aber wir müssen einfacher anfangen.
@amirhosseinrajabi sieht nach einem coolen Projekt aus und ich denke, es wäre sehr sinnvoll, Graphit-Beacon zu einem Handler für die über die Grafana-Benutzeroberfläche konfigurierten Warnungen zu machen.

@Dieterbe ist es möglich, den aktuellen Status zu aktualisieren? für Warnsystem
um zu wissen welches system kompatibel ist (graphite/influxdb) ?
welches Abonnement verfügbar? Welcher Benachrichtigungstyp ist verfügbar?
Danke für dein Update.

Wir entwickeln derzeit Prototypen für die UX/UI. Wir sind also ziemlich weit davon entfernt, dass dies brauchbar ist.

Hallo @Dieterbe

Gibt es Updates zum Fortschritt des Warnsystems ??

Es wäre großartig, in Grafana eine Alarmierung zu haben! Freue mich auf diese Funktion. Irgendwelche Updates jetzt?

@mattttt können Sie ein Update für Ihre UX-Arbeit bereitstellen?

Ja absolut. Werde morgen einige Bildschirme/Benutzerflüsse hochladen.

Wir brauchen Warnungen: UI für die Regeldefinition, API für die Regeldefinition und API für Warnungsbenachrichtigungen. Werde diesen Thread mit Interesse verfolgen. Wir haben ein mandantenfähiges System und lieben die Grafana-Benutzeroberfläche und das Backend.

Ja, ich bin auch sehr interessiert und ungeduldig, dieses neue Feature zu sehen!
Vielen Dank Matt! ;)

2015-08-27 6:49 GMT+02:00 andyl [email protected] :

Wir brauchen Benachrichtigungen: UI für die Regeldefinition, API für die Regeldefinition und API
für Warnmeldungen. Werde diesen Thread mit Interesse verfolgen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -135290295.

Es gibt viele Dinge, die sich intern zusammenfügen, aber ich wollte diesen Thread nicht vernachlässigen.

Hier ist eines der Mockups eines Panels, an dem ich gearbeitet habe. Dies veranschaulicht den historischen Zustand im Laufe der Zeit, indem der Status in die QuickInfo integriert wird und vorhandene Schwellenwerte verwendet werden, die in der Panel-Konfiguration definiert sind, um Benachrichtigungen zu konfigurieren.

In diesem Beispiel ist dies eine Warnung bei einer einzelnen Abfrage mit mehreren Serien. Tooltips werden erweitert, um den Status zur Hover-Zeit anzuzeigen.

_Ein paar kleine offene Fragen _: Wie viele Informationen über die Warnmeldung sollten ggf. in den Tooltip aufgenommen werden - oder sollten diese Informationen an anderer Stelle in einer detaillierteren Ansicht abgerufen werden? Letzteres glaube ich derzeit, aber es lohnt sich, laut zu fragen.

Konfiguration, Warnbildschirme und Benutzerflüsse kommen langsam. Viel zu kommen.

@mattttt schön!

Ich liebe die grüne und rote Linie unter dem Diagramm!

Das hängt mit Uptime-Berechnungen zusammen, würde das gerne irgendwo als Zahl sehen können. Summen für alle Abfragen und für jede Metrik.

Was den Tooltip angeht, sprichst du von den Statistiken, die angezeigt werden, wenn du mit der Maus über die Linien fährst?

Verdammt @mattttt das sieht toll aus. Ich würde mir nicht einmal Gedanken machen, etwas in den Tooltip zu schreiben. Die Schwellenwertlinie und die Statusleiste für den Alarmstatus unten sind mehr als ausreichend.

Ich kann es kaum erwarten, das zu sehen, wenn es fertig ist!

Ich freue mich zu sehen, dass dies gut vorankommt!

Wir verwenden derzeit Grafana+Bosun+OpenTSDB als unseren Überwachungs- und Alarmierungsstack. Ich stimme definitiv zu, dass es großartig wäre, die Power von Bosun mit der großartigen UX von Grafana zu haben.

Hier ist ein Beispiel dafür, wo die Konfigurations-UX von Grafana besser ist als die von Bosun:

Kontext

Unser Monitoring-Stack wird von mehreren Teams und ihren Diensten gemeinsam genutzt. Je nach Projektspezifikation wird ein unterschiedlicher Satz von Diensten für verschiedene Cluster/Standorte bereitgestellt. Jedes Team/Dienst sollte die Verantwortung für seine eigenen Dashboards/Warnungen übernehmen.

Vergleich

Mit der HTTP-API von Grafana können Teams bei der Bereitstellung ihres Dienstes ihre eigenen Dashboards STELLEN. Bosun verfügt derzeit nur über eine einzige Datei zum Speichern der Konfiguration; Dies erschwert den Austausch zwischen verschiedenen Teams und über verschiedene Projekte hinweg.

@mattttt @torkelo @Dieterbe eine Idee für eine Veröffentlichung des alarmierenden

Echo^. Ist dies eine Beta- oder Alpha-Version? Ich forsche nach Benachrichtigungslösungen, würde aber gerne etwas in Grafana eingebaut haben. Ich könnte viel Test-Feedback geben.

Die Benachrichtigungsfunktion liegt noch einige Monate in der Zukunft, wir entwickeln noch immer Prototypen der Benutzeroberfläche und denken über verschiedene Möglichkeiten zur Implementierung nach, aber der Fortschritt sollte in den nächsten 2 Monaten schneller voranschreiten, damit wir dann mehr wissen

@mattttt Beabsichtigen Sie, die Farben des historischen Gesundheitsbalkens konfigurierbar zu machen? Grün und Rot passen nicht wirklich zum Farbenblind ;)

Bezüglich der Alarmierung: Mich interessiert, wie sich das entwickelt. Wir sammeln und visualisieren schon seit einiger Zeit Daten, und wir versuchen derzeit, die Alarmierung herauszufinden. Grafana könnte dort einen schönen Platz haben, zumal die Visualisierungen bereits vorhanden sind. Was ich mich jedoch frage: Inwieweit sollte Grafana mehr auf "Entitäten" als auf metrische Reihen für die Benachrichtigung achten? Ich kann mir vorstellen, dass ich eine visuelle Zustandsänderung (Ping- oder HTTP-Prüfung schlägt fehlgeschlagen) automatisch oder manuell (durch Wartung) für einen Server umschalten möchte, der in meinem Fall ein Server wäre, zusätzlich zu metrischen Benachrichtigungen.

Ich bin interessant zu sehen, wohin die Warnungen in Grafana gehen, aber für diejenigen unter Ihnen, die jetzt etwas brauchen, gibt es Nagios-Plugins wie https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details die Warnungen auslösen können, wenn Schwellenwerte überschritten werden.

@baaym

Was ich mich jedoch frage: Inwieweit sollte Grafana mehr auf "Entitäten" als auf metrische Reihen für die Benachrichtigung achten? Ich kann mir vorstellen, dass ich eine visuelle Zustandsänderung (Ping- oder HTTP-Prüfung schlägt fehlgeschlagen) automatisch oder manuell (durch Wartung) für einen Server umschalten möchte, der in meinem Fall ein Server wäre, zusätzlich zu metrischen Benachrichtigungen.

Das ist eine gute Frage und auch etwas, worüber wir ein bisschen gesprochen haben.
die lösung, die wir kurzfristig (und möglicherweise auch langfristig) verfolgen möchten, besteht darin, grafana nicht auf solche übergeordneten konzepte aufmerksam zu machen. dh als Benutzer haben Sie die Möglichkeit, Warnungen für Metrikreihen festzulegen, und aus diesen Warnungsregeln werden Warnungsergebnisse generiert (wahrscheinlich einschließlich Attribute oder Tags aus den Reihennamen), aus denen Sie dann beliebige Entitäten erstellen können. darüber müssen wir noch ein bisschen nachdenken, aber zum Beispiel

Angenommen, Sie haben eine Warnung in der Art von movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn . Dies würde den Schwellenwert auf allen Ihren Webservern im angegebenen Cluster überprüfen und Warnungen für alle Verstöße wie movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! generieren.
möglicherweise könnten wir Ihnen ermöglichen, "das erste Feld ist der Clustername, das zweite der Hostname" usw. zu sagen, damit Warnungen bessere Informationen enthalten können.
Der Punkt ist jedoch, dass das _outcome_ der Warnung die Informationen enthält, die Sie benötigen, um zu identifizieren, welche Entität Probleme hat, aber es liegt außerhalb des Umfangs von Grafana. Grafana wäre eher die Quelle für die Konfiguration von Warnungsregeln, und Grafana-Dashboards könnten so konfiguriert werden, dass sie Anmerkungen laden und den Status der Warnungen visualisieren, aber es hätte keine Vorstellung von übergeordneten Konzepten wie Hosts oder Cluster. Ich denke, dies könnte in den Alerting-Handlern gehandhabt werden

@Dieterbe

Beim Erstellen von Benachrichtigungsfunktionen gibt es zwei Arten von Benutzer-/Organisationsproblemen:

• Startup wie, wo sie im Allgemeinen keine Zeit haben, ihre eigene Alarmierungslösung zu entwickeln. Alles würde sich auf Grafana verlassen, um auf Metriken zu warnen
• Etablierte Engineering-Organisation, sie verfügen über vorhandene Alarmierungstools, die im Haus erstellt wurden, Alarme für Geschäftsregeln basieren auf anderen granularen Alarmierungssignalen (Grafana wäre eines davon).

Grafana sollte mit bestehenden, gut etablierten Betriebspraktiken arbeiten. Wenn es außerhalb des Zyklus liegt, wird das Ziel der Benachrichtigung ignoriert – eine klare Sicht auf die Integrität geschäftskritischer Einheiten zu haben. Es ist besser, die Alarmierung zu zentralisieren, um einen klaren Zustand der Umgebung zu erstellen. Es wäre wichtig, Power-Usern zu erlauben, die die grafana-API (oder eine andere Lösung) verwenden, um Benachrichtigungsregeln in andere Systeme zu exportieren.

Wenn von betriebsbereit gesprochen wird, sollte jede Warnung optional ein Dokumentations-/Linkfeld enthalten, um den Zweck der Warnungen und das historische Verhalten zu erläutern.

@activars Ich glaube, ich stimme dem alles zu. aus meiner Sicht verfolgen wir einen Ansatz, der das Einbinden von Grafana in die restliche Umgebung fördert (hauptsächlich dank der Trennung von Interessen mit steckbaren Handlern). Glauben Sie, dass das vorgeschlagene Design in irgendeiner Weise verbessert werden kann?

Ich denke, @deebs031 macht einen guten Punkt, der nicht viel angesprochen wurde "Anwendungen, die für Endbenutzer entwickelt wurden, müssen benutzerdefinierte Warnungen bereitstellen".
IMHO ist das Graal Self-Service-Metriken-basierte Überwachung . In meinem Fall ist Grafana das Haupt-Frontend für Leute, die sich Metriken ansehen möchten.
Ich persönlich habe Sensu-Warnungen basierend auf Metriken durchgeführt, aber die Bereitstellung als Self-Service ist im Vergleich zu der nahtlosen Integration mit Grafana wirklich kein Kinderspiel. Ich habe mir Cabot auch angeschaut, weil es Visualisierungsfunktionen hatte, aber es wurde nicht mit Blick auf Self-Service entwickelt und konnte es daher nicht so verwenden, wie es ist.
Ich bin auf der Seite "eine Sache gut machen", aber ich denke, im speziellen Fall von Self-Service-Benachrichtigungen, die auf Metriken basieren, ist es sehr sinnvoll, diese Fähigkeit mit der Metrik-Visualisierungsebene zu kombinieren:

• Der Benutzer ist bereits mit der Benutzeroberfläche vertraut
• Der Benutzer wird authentifiziert, sodass er Benachrichtigungen für sich selbst oder das Berechtigungsschema erstellen kann, das die Authentifizierung ermöglicht
• Der Benutzer kann die Diagramme sehen, die normalerweise sehr nützlich sind, wenn diese kennzahlenbasierten Warnungen erstellt werden

Folien meiner Grafanacon-Präsentation zum Thema Alerting:
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
Sie sind ohne Kontext etwas schwer zu verstehen, das Video sollte in etwa einer Woche online sein, ich werde es posten, wenn es fertig ist.

Wir haben jetzt damit begonnen, Prototypen zu entwickeln, um die Alerting-Modelle/UI/Definitionen/etc. Wir haben eine ziemlich gute Vorstellung vom Hauptworkflow, obwohl wir noch versuchen herauszufinden, wie die Integration mit Alarmierungs-Handlern von Drittanbietern aussehen sollte.
Wir denken derzeit, dass Sie grafana verwenden können, um Schwellenwerte/Warnungsregeln festzulegen/Benachrichtigungen zu definieren und den historischen und aktuellen Status der Alarmierungsregeln zu visualisieren.

die Annahme ist, dass Sie Ihre bevorzugte Alarmierungssoftware verwenden möchten (bosun/cabot/sensu/nagios/...)
es gäbe also ein separates Tool, das grafana über seine http-API abfragt, um alle Benachrichtigungsregeln abzurufen. Dieses Tool könnte dann Ihre bosun/cabot/sensu/nagios/...-Konfiguration aktualisieren, sodass Sie Ihre bevorzugte Alarmierungssoftware verwenden können, um die Alarme auszuführen und auszuführen und die Benachrichtigungen zu versenden.
aber wir möchten den aktuellen und historischen Zustand richtig visualisieren können, daher müsste Ihr Alarmierungsprogramm entweder in der Lage sein, ein Skript oder einen Webhook oder etwas aufzurufen, um grafana über den neuen Zustand zu informieren, oder grafana müsste danach abfragen. (was eklig erscheint, da die meisten Tools keine großartigen APIs zu haben scheinen)
das ist alles etwas kompliziert, aber es müsste so sein, um leute zu unterstützen, für die es wichtig ist, dass sie ihre alarmierungssoftware ihrer wahl verwenden können, während sie grafana zur definition der alarmierungsregeln und zur visualisierung des zustands verwenden.

Ist es Ihnen wichtig, dass Sie Ihr aktuelles Benachrichtigungstool Ihrer Wahl verwenden können?

Das andere, was wir tun möchten, ist, selbst einen einfachen Alert-Executor zu schreiben, der die grafana-API nach Alerts abfragt, plant und ausführt, die Benachrichtigungen durchführt (es würde E-Mail, Slack, Pagerduty, ein benutzerdefiniertes Skript unterstützen und wahrscheinlich ein paar andere) und aktualisiert den Zustand in grafana erneut.
es wäre ziemlich einfach für uns zu schreiben, für Sie einfach zu bedienen und wir könnten eine großartige Interoperabilität haben.

Ist der eingebaute Alerting-Executor (siehe oben) Ihrer Meinung nach ausreichend, um alle von Ihnen in grafana eingerichteten Alerting-Regeln zu handhaben?

Möchten Sie auch mehrere Alerting-Handler verwenden können? welcher ?

@jaimegago amen ;)

Für mich scheint Nummer 2 besser zu sein, da Sie die Anzahl der Dinge, die Sie konfigurieren müssen, wirklich minimieren können, damit alles reibungslos funktioniert. In unserem aktuellen Setup würden wir das beibehalten.

Nur so wurde gesagt, wenn alle anderen anderer Meinung sind ;)

Schnellbearbeitung: Tolle Folien. Wenn das Endprodukt halb so gut aussieht, dann ist es erstaunlich.

+1
Ich stimme zu, dass der interne Benachrichtigungshandler mit diesen Integrationen perfekt ist! für den häufigsten Anwendungsfall.

Ich freue mich, Beta-Testing zu sein :) und Folien werden fantastisch sein!

Ich denke, der letzte Beitrag von @Dieterbe klärt die Dinge ziemlich auf, aber ich wollte dieses schnelle Diagramm posten, um dies weiter zu verdeutlichen.

Benachrichtigungen in Grafana sind wirklich zwei Dinge, die Self-Service-Alert-Konfiguration (danke @jaimegago , hätte es selbst nicht besser sagen können) und der Handler selbst.

Wir werden einen Grafana-Warnungshandler liefern, aber auch das Framework für die Integration in Ihre bevorzugte Warnsoftware bereitstellen:

+1 für den Bau einer Art Brücke zu anderen Alarmierungssystemen (vielleicht könnten wir darüber nachdenken, ein allgemeines Alarmierungs-Plugin-System zu implementieren :-) )

Sie können Prometheus auch im Teil "Externe Alert-Handler" hinzufügen. Die erste Version von Prometheus alertmanager ist in mehreren Unternehmen in Produktion und eine komplette Neufassung ist derzeit in Arbeit. SoundCloud verwendet möglicherweise Grafana, um Warnungen zu konfigurieren, aber ganz sicher nur, wenn der Prometheus-Alertmanager als Alert-Handler verwendet wird.

@grobie , guter Fang, im Originalkommentar behoben.

@mattttt @Dieterbe das ist toll ! Sieht so aus, als ob Sie auf dem Weg der "Batterien enthalten, aber herausnehmbar" sind, was IMHO das Beste aus beiden Welten ist. Haben Sie sich schon Gedanken gemacht, wie Sie Berechtigungsdaten an den Alert-Handler übergeben? Ich denke an eine Geschichte wie diese:
Als Grafana-Benutzer möchte ich über _email_ und/oder _pagerduty_ und/oder _foo_ benachrichtigt werden, wenn (eine Bedingung, die über die Grafana-Warnungs-UI erstellt wurde) eintritt.
Dieser Benutzer sollte nur in der Lage sein, Warnungen an das Benachrichtigungssystem zu senden, für das er autorisiert ist, dies ist eine Voraussetzung für den Self-Service und muss irgendwie behoben werden. Seit Grafana 2 haben wir ein SQL-Backend + Benutzerauthentifizierung/-autorisierung mit LDAP-Integration, also scheint es nicht zu weit hergeholt, diese Fähigkeit vom ersten Tag der Benachrichtigung an zu haben?
Mit Sensu (das ist das Tool, das ich einstecken würde) sollte die Übergabe des Alert-Ziels (zB E-Mail-Adresse) über den Handler ziemlich einfach sein, kann ich zu den anderen nicht sagen.

Hallo zusammen,
Ich freue mich zu sehen, dass dieses Angebot vorangetrieben wird, da ich den Ansatz zur Konfiguration von Self-Service-Benachrichtigungen liebe.

Persönlich benötige ich keinen bestimmten Alert-Handler. Ich möchte einen generischen HTTP-POST-Handler sehen, der nur ausgelöst wird, sobald eine Warnung ausgelöst wird. Ich denke, die meisten Admins können schnell etwas bauen, das HTTP akzeptiert, und dann alles tun, was sie tun müssen (es an nagios, riemann, younameit senden). Daher würde ich mich über einen HTTP-Handler freuen, der alle Informationen zu einem Alert als JSON-Daten sendet.

Apropos Warnungen über Grafana: Planen Sie, etwas wie Flattererkennung hinzuzufügen? Oder sollte sich das externe Überwachungssystem darum kümmern?

Macht weiter so Jungs!

Danke schön

Ich möchte einen generischen HTTP-POST-Handler sehen, der nur ausgelöst wird, sobald eine Warnung ausgelöst wird. Ich denke, die meisten Admins können schnell etwas bauen, das in der Lage ist, HTTP zu akzeptieren, und dann alles tun, was sie tun müssen (senden an nagios, riemann, younameit).

Wenn also eine Warnung ausgelöst wird (z. B. "web123 hat kritischen CPU-Leerlauf!, Wert 1 niedriger als Schwellenwert 15") und wir einen http-Post dieser Daten erstellen, wie würden Sie das in Nagios handhaben? Sie meinen, Nagios würde es als passiven Service-Check aufnehmen und dann würde Nagios die Benachrichtigungen senden?

Apropos Warnungen über Grafana: Planen Sie, etwas wie Flattererkennung hinzuzufügen? Oder sollte sich das externe Überwachungssystem darum kümmern?

auch darüber müssen wir mehr nachdenken. Dies kann chaotisch werden, und wenn Leute so etwas wie Pagerduty oder Flapjack verwenden, können sie damit Ereignisse aggregieren / Duplikate unterdrücken. Beachten Sie auch, dass Sie, da Sie Warnungen für beliebige Abfrageausdrücke für Metriken festlegen können, viel Macht haben, frühere Daten im tatsächlichen Ausdruck zu berücksichtigen, und so ein robusteres Signal im Ausdruck erstellen können, das ändert den Zustand nicht so oft.

Wenn also eine Warnung ausgelöst wird (sagen wir "web123 hat kritischen CPU-Leerlauf!, Wert 1 niedriger als Schwellenwert 15") und wir einen >http-Post dieser Daten erstellen, wie würden Sie das in Nagios handhaben? Sie meinen, Nagios würde es als passiven Service-Check aufnehmen und dann würde Nagios die Benachrichtigungen senden?

So'ne Art. Ich freue mich schon auf die Grafana-Alarmierung, um Nagios loszuwerden. Bei Verwendung des HTTP-Handlers müssen Sie passive Prüfungen für Nagios konfigurieren, um die Ergebnisse dort übermitteln zu können. Aber ich möchte grafana als die einzige Quelle haben, wo Sie Benachrichtigungen konfigurieren können. In unserem Fall sind die Personen, die Warnungen hinzufügen dürfen, der eigentliche Systemadministrator, der auch die Überprüfungen in Nagios konfigurieren würde.

Mit dem http-Handler hätte grafana alles, was wir dafür brauchen: ein Dashboard für die Echtzeitüberwachung, eine API, eine einfache Alarmierungskonfiguration und einen http-Handler, über den wir Alarme an unser internes Benachrichtigungssystem weiterleiten können.

Danke schön

Obwohl ich die Logik dieser Integrationsstrategie sehe, kann ich nicht anders, als sie für ein wenig übertrieben zu halten. Soweit ich weiß (und was ich im Thread lesen konnte), verwenden die meisten Grafana-Benutzer weiterhin eine eigenständige Benachrichtigungstechnologie, weil Grafana keine vorschlägt. Es wäre also nicht "schlanker", sich zuerst auf den Grafana Alerting-Teil zu konzentrieren und ihn als eine Komponente zu entwickeln, die über die API mit dem Rest des Stapels kommuniziert, damit andere Mitwirkende das Verhalten nachahmen und erstellen können spezielle Adapter später?

tl;dr: Indem Grafana sich zuerst darauf konzentriert, seine eigenen "Batterien" zu bauen, hätte es ein voll funktionsfähiges Warnsystem, das sich später zu einem Dienst zur Integration mit Warntools von Drittanbietern entwickeln kann.

Kleine Sorge, wenn dies nicht behoben wurde. Das traditionelle Warnsystem lässt sich für Cloud-Infrastrukturen nicht gut skalieren, da Ressourcen sehr dynamisch sind (bereitgestellt und zerstört). Benachrichtigungen zu Metriken sollten die Versuchs- oder Gruppierungsfunktion unterstützen (mit Ausnahmen überschreiben, manchmal sind die Arbeitslasten unterschiedlich). Eine vorlagenbasierte oder gruppierte Warnung sollte in der Lage sein, neue Gruppensätze zu erkennen.

Danke für das Update! In meinem Anwendungsfall ist die integrierte Benachrichtigung in Grafana alles, was ich zu diesem Zeitpunkt benötige. Ich habe geduldig und ungeduldig auf die Warnung von Grafana gewartet.

Wie ich im IRC versprochen habe, hier ist unser Anwendungsfall dafür:

Wir haben eine alte Rails-App, die searches our logs für patterns und eine
HTTP-API, um zu antworten, wenn ein bestimmtes pattern überschritten wurde, ist thresholds und
hat somit den Status {OK,WARNING,CRITICAL} .

Threshold kann entweder sein:

• a status von CRITICAL wenn pattern existiert.
• dass status WARNING wenn pattern mehr als X-mal gefunden wird
  und status ist CRITICAL wenn es mehr als Y-mal gefunden wird.
• wenn pattern weniger als 1 Stunde alt ist, dann ist status OK ,
  weniger als 3 Stunden status ist WARNING und ansonsten ist status
CRITICAL .

Wenn ich diese Funktion richtig verstehe, wird Grafana diese Verwendung unterstützen
Muster (über Logstash und Elasticsearch natürlich), wenn diese Funktion und
die Elasticsearch-Datenquelle vollständig implementiert ist?

@Dieterbe @mattttt deine Dias und Mock-ups sehen absolut fantastisch aus! Dies ist wirklich ein Game Changer.
Für mich würde der interne Grafana Alert Handler unseren Bedürfnissen am besten entsprechen.
Gründe dafür:

• Selbstbedienung – Ganz wichtig . Unsere Benutzer sagten laut und deutlich, dass sie in Grafana selbst durchgängig Benachrichtigungen erstellen möchten.
• Einheitlicher Workflow - Ich möchte bewegliche Teile minimieren und nicht vergrößern. Wie @Dieterbe betonte, würde ein Alarmhandler nur 1 erfordern würde (vielleicht 2, wenn Sie eine Benachrichtigungsmethode für jeden Schwellenwert definieren müssen? - unsicher aus der Präsentation).
• Enge Integration und keine Abhängigkeit von der Alarmierungsinfrastruktur von Drittanbietern.

Ein paar Bedenken:

• Was sind die Schwellenwerte für die Häufigkeitsprüfung?
• Wie geht es mit der Abfragefrequenz um, die zu schnell ist, um die Daten zurückzubekommen? Protokollieren, benachrichtigt und in die Warteschlange gestellt oder fallen gelassen?
• Bei der Skalierung, befürchtet, dass Grafana möglicherweise nicht in der Lage ist, mit der bloßen Anzahl von Überprüfungen, der schnellen Häufigkeit und insbesondere mit der Latenz zwischen Datenquellen Schritt zu halten, die wir wahrscheinlich Grafana-Server hinzufügen/skalieren müssen, um interne Benachrichtigungen zu unterstützen. Ich weiß das, weil wir jetzt mehrere Alert-Handler-Instanzen von Drittanbietern benötigen. Wie könnten wir in diesem Fall Schwellenwertprüfungen zwischen einem Cluster von Grafana-Servern nahtlos zuweisen oder in eine Warteschlange stellen, insbesondere wenn die Prüfungen aus derselben Datenquelle stammen? Von einer Benutzererfahrung aus möchte ich, dass Benutzer nahtlos Schwellenwerte über einen Lastausgleichs-Cluster von Grafana-Servern erstellen, ohne dass Benutzer für eine bestimmte Überprüfung zu einer bestimmten "zugewiesenen" Instanz von Grafana gehen.
• Würde dies für Benachrichtigungen eine Art Plugin-Architektur unterstützen, damit Benachrichtigungen einfach entwickelt und integriert werden können? Im Allgemeinen brauchen wir etwas, das HTTP-POSTs durchführen kann. Dies ist am häufigsten bei PagerDuty, xMatters, VictorOps, Opsgenie usw. der Fall. Jeder erfordert ein etwas anderes Format, eine andere Authentifizierung usw. Wie bereits in diesem Thread erwähnt, würde vielleicht ein generischer HTTP-POST-Handler funktionieren, der an a senden würde benutzerdefinierter HTTP-Dienst, der damit machen kann, was Sie wollen. Alternativ sollte auch eine benutzerdefinierte Skriptfunktion funktionieren.
• Ich gehe davon aus, dass Schwellenwerte über eine API festgelegt, abgerufen und Verstöße erhalten werden könnten? Ich denke das wäre hilfreich

Ich finde es ideal, die Alarmierung in bestehende Alarmsysteme integrieren zu können. Es gibt einige schwierige und hässliche Probleme wie die bereits erwähnte Klappenerkennung, die behoben wurden, und es scheint verschwenderisch, alles von Anfang an neu zu erfinden. Ich würde es hassen, dies unter dem Gewicht des Feature-Kriechs begraben zu sehen.

Aber ich glaube nicht, dass dies wirklich eine enge Integration in all diese Alert-Handler sein muss. Eine gute, gut dokumentierte API sollte es Personen ermöglichen, die mit diesen Systemen vertraut sind, sich mit geringem Aufwand zu integrieren. Also die Folie mit 'grafana api -> handler' sieht für mich attraktiv aus.

Scott

Hallo zusammen -- Ich komme zu spät zu dieser Diskussion, aber ich habe einige Kenntnisse zu diesem Thema und bin der leitende Entwickler eines der Tools, das versucht hat, das Alarmierungsproblem zu lösen. Unser Tool StatsAgg ist vergleichbar mit Programmen wie bosun. StatsAgg zielt darauf ab, flexible Warnungen, Warnungsaussetzungen und Benachrichtigungen abzudecken und ist zu diesem Zeitpunkt ziemlich ausgereift/stabil (obwohl die API noch nicht bereit ist).

Trotzdem einige Gedanken zum Thema Alarmierung:

• Warnungen nach individuellen Metriken sind scheiße. Ich arbeite in einem Unternehmen, das Tausende von Servern verwaltet, und es ist logistisch nicht machbar, separate Warnungen für jede Metrikreihe von „freiem Speicherplatz in %“ erstellen/konfigurieren/verwalten zu müssen. Überwachungstools von Unternehmen verknüpfen oft mehrere Metrikreihen mit regulären Ausdrücken (oder einfach nur mit Platzhaltern versehenen Ausdrücken). StatsAgg wurde auf der gleichen Prämisse aufgebaut; mehrere Metrikserien werden miteinander verbunden, und dann werden die Alert-Schwellenwertüberprüfungen für die Gruppe von Metriken durch eine einzige "Warnung" ausgeführt. Im Maßstab ist diese Art von Fähigkeit eine Notwendigkeit.
• Wenn man meine vorherige Behauptung akzeptiert, dass ein Benachrichtigungstool nicht bei einzelnen Metriken warnen sollte, folgt daraus, dass das Tool einen Mechanismus haben muss, um schnell eine Liste der qualifizierenden Metriken und der Metrikwerte zu erhalten. Viele Tools verlassen sich auf die abfragenden Datenspeicher, um die Liste der Metriken und Metrikwerte zu erhalten, und diese Lösung funktioniert ehrlich gesagt nicht sehr gut im Maßstab. Die Benachrichtigungslogik muss von Natur aus oft ausgeführt werden (alle X Sekunden oder wenn jeder neue qualifizierende Datenpunkt einläuft). Die Datenspeicher (Graphit, opentsdb, influxdb usw.) wurden einfach nicht für die ständige Abfrage von "Geben Sie mir die aktuelle Liste der Metriken, die diesem Muster entsprechen" und "Zeigen Sie mir die letzten X-Werte für diese Y-Metriken" erstellt. Sie verfügen entweder nicht über die entsprechende API/Abfragesprache oder können die Last einfach nicht verarbeiten. Um es klar zu sagen, ich spreche von Skalen für die Ausführung von Warnlogik für 10.000 Metrikserien, wenn 10.000.000 verfügbare Metrikserien im Datenspeicher vorhanden sind. Dies ist nicht jedermanns Anwendungsfall, aber es ist der meiner Firma.
• Ich habe festgestellt, dass die Lösung des Problems über die Stream-Verarbeitung der einzige gangbare Weg ist, um die in meinem letzten Aufzählungspunkt angesprochenen Probleme anzugehen. Aus diesem Grund wurde StatsAgg so konzipiert, dass es vor dem Datenspeicher sitzt. Die Benachrichtigungslogik kann gegen die Metriken ausgeführt werden, ohne den Datenspeicher zu berühren, und die Metriken werden einfach an den Datenspeicher weitergeleitet. Die Hauptüberlegungen dieses Ansatzes sind, dass 1) neu erstellte Alerts keine alten/archivierten Metrikwerte für die Alert-Auswertung verwenden können oder 2) wenn das Stream-Processing-Programm (ex-StatsAgg) abstürzt, dann Datenpunkte es nicht schaffen in den Datenspeicher 3) Metrikwerte, die für die Warnungsauswertung benötigt werden, werden im Arbeitsspeicher gespeichert, was ein Problem der Serverstabilität sein könnte. 4) Das Stream-Processing-Programm muss in der Lage sein, die eingehenden Metriken zu dekonstruieren und zu rekonstruieren (was InfluxDB im letzten Jahr nicht leicht gemacht hat...). Trotz dieser Einbildungen hat diese Lösung für mein Unternehmen sehr gut funktioniert, und zwar in sehr großem Umfang. Zeitweise hatten wir mehr als 200.000 Live-Metrikenreihen, Durchschnittswerte von über 30.000 eingehenden Metriken/Sek., Hunderte von Warnungen, die Tausende von Metrikenreihen auswerten, und einen Server, auf dem StatsAgg läuft, der kaum ins Schwitzen kommt. Dabei wird der Datenspeicher überhaupt nicht abgefragt.

Das sind die wichtigsten Dinge, die ich erwähnen wollte. Es gibt auch viele andere wichtige Aspekte bei der Alarmierung (Benachrichtigungen, Aussetzungen usw.), aber diese Lösungen lassen sich leicht anbringen, sobald die Architektur des Kernproblems gelöst ist. Mir ist klar, dass unsere Bedürfnisse nicht mit denen eines durchschnittlichen Benutzers übereinstimmen, aber hoffentlich können Sie alle diese Perspektive zu schätzen wissen.

Ich möchte vorschlagen, mit einem Benachrichtigungs-Handler zu starten, der Daten an Alerta senden kann: https://github.com/guardian/alerta

Alerta verfügt über eine sehr vernünftige REST-API zum Empfangen von Benachrichtigungen.

Ich bevorzuge eine schlanke, reine Grafana-Implementierung!
Ich denke, es lohnt sich, es neu zu bewerten, nachdem jeder Erfahrung mit dieser Funktion in der typischen fantastischen Grafana UX gemacht hat.

Es wird viele komplexe Fälle und/oder benutzerdefinierte Backend-Systeme geben, in die die Leute integrieren möchten. Sie können viele in diesem Thread sehen, hauptsächlich Open Source, aber es gibt auch so viele kommerzielle Produkte! Kümmere dich nicht um einzelne Handler - es wird ein Ratten-Ganzes sein und du wirst immer im Fangmodus sein

Ich würde dringend raten, nur zwei Arten von Handlern zu implementieren. Eines ist definitiv HTTP POST, es wird das vielseitigste und flexibelste Werkzeug sein. Die andere ist benutzerdefiniertes Skripting, sodass die Benutzer die Integration mit ihrem spezifischen Tool ihrer Wahl implementieren können. Das Plugin-Modell ist nicht schlecht, aber es zwingt zur Verwendung einer bestimmten Plugin-Sprache, die einschränkend ist. Externe Skripte sind besser - solange Sie alle Details an ein Skript übergeben, kann das Skript in jeder Sprache geschrieben werden - Shell-Skript, Python usw.

Ich bin bei @007reader

Ich stimme zu. Sofern gängige Integrationsmethoden bereitgestellt werden, kann die benutzerdefinierte Implementierung ein separates Projekt oder eine Bereitstellung sein.

Zum Beispiel ist die aktuelle CloudWatch-Version anständig, aber ich würde sie gerne als separates Projekt erstellen, indem ich nur ausgewählte Metriken zu alternativem Speicher synchronisiere. Es gibt uns eine vollständige Aufbewahrung anstelle von nur 2 Wochen Daten.

Hallo allerseits,
mein grafanacon-Präsentationsvideo ist online!
es ist unter https://www.youtube.com/watch?v=C_H2ew8e5OM
Ich denke, es wird eine Menge aufklären, aber wie Sie sehen können. die Besonderheiten von Integrationen müssen noch geklärt werden und waren auch ein Thema, das viele Leute diskutieren wollten. (obwohl die Zeit begrenzt war und ich die Leute gebeten habe, das Gespräch hier fortzusetzen, damit jeder teilnehmen kann)

@simmel ja genau. Sie würden eine ES-Abfrage verwenden und eine Regel dafür festlegen.
@activars regruppieren und entdecken, ich denke, vieles davon hängt von Ihrer Datenquelle ab, aber die meisten allgemeinen Anforderungen sollten berücksichtigt werden, wenn Sie etwas wie Graphit oder ES verwenden, von dem ich weiß, dass es sehr gut darin ist, zuvor nicht gesehene Metriken / Serien "automatisch zu entdecken". /Dokumente, die dem angegebenen Ausdruck (mit Platzhaltern) für Graphit oder Abfrage (für ES) entsprechen. bei den anderen Quellen bin ich mir nicht sicher. Ihr Kommentar zur Notwendigkeit, Ausnahmen von Regeln anzuwenden, ist komplizierter, wir werden wahrscheinlich irgendwann darauf eingehen müssen, aber ich denke, das kann warten, bis die Dinge klarer und geregelter sind. vielleicht können wir das irgendwie vermeiden.
@mgravlin- Frequenz wird eine Einstellung in der Regel sein, die mit zu langsamen Datenquellen umgeht, noch nicht sicher. aber tu es nicht ;-). auch handlerabhängig. Scale-out-Bereitstellung sollte möglich sein, auch mit enthaltenem Handler, also werden wir uns das ziemlich sicher ansehen. aber vielleicht keine Priorität für die erste Veröffentlichung. Ja, Benachrichtigungs-Plugins sind der Schlüssel und wir werden sicherstellen, dass Sie das verwenden können, was Sie wollen / brauchen. re api: ja :)
@sknolin Wenn ich das richtig verstehe, würde Grafana Ihrer Meinung nach die Alarmplanung, -ausführung, das Auslösen von Benachrichtigungs-Hooks usw. durchführen, selbst wenn ein anderes System wie Nagios / Bosun verwendet wird. Was genau wäre dann die Rolle des externen Systems (nagios/bosun/...) . dies scheint auch dem ähnlich zu sein, worüber @Crapworks gesprochen hat.
@jds86930 StatsAgg sieht ziemlich interessant aus. Ich denke auch hier wäre eine Integration mit grafana sinnvoll. Ich denke, dass die Stream-Verarbeitung ein gültiger Ansatz ist, der als Alternative zu wiederholten Abfragen verwendet werden kann. aber letzteres ist einfach einfacher zu beginnen und einfach einfacher im Allgemeinen, denke ich. Aber beides sollte unterstützt werden. Also ja, in Grafana können Sie Muster/Abfragen einrichten, die einem Datenspektrum entsprechen, und möglicherweise neue Serien/Daten abdecken, sobald sie live gehen. aus unserer Sicht würden Sie jedoch einfach die Funktionalität Ihrer Datenquelle nutzen (zum Beispiel ist Graphit mit seinen Platzhaltern, Glob-Ausdrücken usw Verwenden Sie einfach StatsAgg, um das zu lösen. Wollen Sie damit sagen, dass Grafana selbst hier etwas Bestimmtes tun sollte? Ich denke, wenn Ihre Datenquelle nicht schnell genug ist, lösen Sie das Datenquellenproblem. Holen Sie sich etwas schnelleres, das Caching für metrische Metadaten hat, vielleicht einen Speicherserver vor oder Stream-Verarbeitung. Aber so oder so, was Grafana betrifft, würde sich nicht viel ändern, was mir einfällt?
@blysik ja sieht interessant aus. so viele Benachrichtigungstools da draußen, die wir integrieren sollten :) Um es klar zu sagen, gefällt dir die Idee, Benachrichtigungsregeln zu verwalten und sie in grafana so zu visualisieren, wie es bisher präsentiert wurde, aber du möchtest Alerta verwenden, um sich um die Benachrichtigungen zu kümmern? ? wäre alerta der primäre Ort, an dem Sie sich den Status Ihrer Warnungen ansehen (das scheint eine vernünftige Sache zu sein), aber ich möchte sicherstellen, dass ich vollständig verstehe, wie Sie die Integration sehen.

@007reader , @shanielh , @activars nur um klar zu sein, diese Integration über einen generischen HTTP-Post oder ein Skript, was das Ziel wäre. dem externen System mitteilen "es gibt eine neue Regel, hier ist die Abfrage, die Schwellenwerte, Häufigkeit usw. jetzt bitte ausführen" ? oder wäre grafana das Ding, das die Regeln ausführt und dann die externen Systeme mit dem neuen Zustand aktualisiert?

@blysik ja sieht interessant aus. so viele Benachrichtigungstools da draußen, die wir integrieren sollten :) Um es klar zu sagen, gefällt dir die Idee, Benachrichtigungsregeln zu verwalten und sie in grafana so zu visualisieren, wie es bisher präsentiert wurde, aber du möchtest Alerta verwenden, um sich um die Benachrichtigungen zu kümmern? ? wäre alerta der primäre Ort, an dem Sie sich den Status Ihrer Warnungen ansehen (das scheint eine vernünftige Sache zu sein), aber ich möchte sicherstellen, dass ich vollständig verstehe, wie Sie die Integration sehen.

Richtig. Alerta entwickelt sich zu unserem Benachrichtigungs-Hub. Alle möglichen Dinge, die Warnungen senden. Zum Beispiel: Benutzerdefinierte Skripte, Cabot, Zenoss, vCenter und möglicherweise Grafana. Das gibt Ops einen einzigen Ort, an dem alle Warnungen angezeigt werden. Und dann ist dies der einzige Ort, an dem Benachrichtigungen an den Bereitschaftstechniker gesendet werden.

@sknolin https://github.com/sknolin wenn ich das richtig verstehe, in deinem
view, grafana würde die Benachrichtigungsplanung, -ausführung und -auslösung durchführen
Benachrichtigungs-Hooks usw., auch wenn ein anderes System verwendet wird wie
Nagios/Bosun. Was genau wäre dann die Rolle des externen Systems?
(Nagios/Bosun/...) . das scheint auch dem von @Crapworks ähnlich zu sein
https://github.com/Crapworks sprach.

Ich glaube, ich habe nicht gut erklärt. Das würde ich nicht wollen, Grafana nicht
das ganze Zeug machen. @Crapworks (das macht Spaß zu tippen) spricht passiv
Servicechecks, ich würde nur aktives Polling verwenden.

Alles, was ich mir wünschen würde, ist eine API, in der ich den Status von Grafana-Warnungen lesen kann.
Alles andere erledigen externe Systeme.

Das heißt nicht, wenn es sich nicht irgendwie zu einem tollen General entwickelt hat
Benachrichtigungstool würde ich nicht verwenden. Genau das, was ich jetzt tun würde.

Scott

@sknolin

Alles, was ich mir wünschen würde, ist eine API, in der ich den Status von Grafana-Warnungen lesen kann.

Wie würde dieser Status in grafana aktualisiert? Welcher Prozess würde Warnungen ausführen und den Status in Grafana aktualisieren?

Jedes Mal, wenn es abgefragt wird, aktualisiert grafana den Alarmstatus, mit einer Art Zwischenspeicherungsintervall, um mit mehreren Systemen fertig zu werden, die es abfragen.

Ich sehe den Punkt, dass dies immer noch erfordert, dass grafana Logik für die Warnungen macht und sie präsentiert. Wenn ich darüber nachdenke, brauche ich keine Warnungen jeglicher Art.

Ich denke, ich könnte alle erforderlichen Benachrichtigungen ausführen, wenn ich den aktuellen Wert für eine Metrik in einem Diagrammfeld abrufen könnte. Wenn wir beispielsweise eine Rate aus der Summe mehrerer Zählermetriken ableiten und grafisch darstellen, wäre es schön, den aktuellen Wert mit dem Überwachungssystem abzufragen. Vielleicht ist das jetzt völlig machbar und ich bin nur stumpf.

Scott

@Dieterbe Letzteres:

grafana ist das Ding, das die Regeln ausführt und dann die externen Systeme mit dem neuen Zustand aktualisiert

@Dieterbe Ich stimme zu, dass das Abfragen der Datenquelle (Graphite, OpenTSDB usw.) mit der nativen Abfragesyntax der Datenquelle am einfachsten / einfachsten ist und wahrscheinlich der schnellste Weg ist, um eine Form der nativen Benachrichtigung in Grafana zu erhalten. Für viele Leute wird diese Art von Lösung ihre Bedürfnisse erfüllen, und ich denke, dies ist die beste Lösung für die anfängliche Grafana-Implementierung (meiner Meinung nach). Mein Hauptpunkt war, dass es eine Obergrenze für die Konfigurierbarkeit und Leistung von Warnungen gibt, die mit dem Modell "Datenquellenabfrage" nur schwer zu überwinden sein wird.

In Bezug auf die Richtungen, die Grafana für langfristige Alarmierungslösungen einschlagen könnte, konnte ich einige Optionen sehen:

• Arbeiten Sie mit den Datenspeicher-Betreuern zusammen, um schnellere/bessere zweckgebundene APIs für den Benachrichtigungsanwendungsfall zu erstellen. Ich mag diese Option nicht, weil viele dieser Projekte langsamer voranschreiten (Monate bis Jahre) und sie möglicherweise einige / alle Verbesserungsanfragen nicht akzeptieren. Sie möchten wahrscheinlich auch in der Muttersprache ihrer Datenspeicher codieren, die nicht immer schnelle Sprachen sind (z. B. Graphite in Python).
• Erstellen Sie Stream-Processing-/Caching-Layer für jeden Datenspeicher als separate Raintank-Projekte. Ich denke, dies hätte letztendlich ein besseres Ergebnis, als zu versuchen, die verschiedenen Datastore-Maintainer dazu zu bringen, Lösungen für ihre Projekte zu entwickeln. Auf diese Weise können Sie auch Ihre bereits geleistete Arbeit weiter ausbauen (unter Verwendung der vorhandenen Datenspeicherabfragemechanismen). Sie könnten sogar Ihre eigenen benutzerdefinierten APIs in die Stream-Processing-/Caching-Schichten einbauen, die die Abfragesyntax von Grafana für den Datenspeicher vereinfachen könnten.
• Bleiben Sie bei der nativen Lösung, auf die Sie hinarbeiten, und sorgen Sie dafür, dass sie gut funktioniert. Tools von Drittanbietern wie StatsAgg, bosun usw. werden für anspruchsvollere/spezialisierte/komplexe Anwendungsfälle verfügbar sein. Die Integration von Grafana in diese Tools wäre definitiv ein zusätzlicher Vorteil für den Benutzer, würde Grafana jedoch um eine nicht triviale Komplexität erweitern. Das heißt, es sieht so aus, als würden Sie dies trotzdem tun (ich schaue mir gerade 'Alerting Backends' auf Folie 35 Ihrer Präsentation an). Ich persönlich bin offen für die Implementierung eines Grafana-freundlichen Satzes von APIs in StatsAgg; Wir müssten nur herausfinden, wie die APIs sind und eine API-Protokolldokumentation erstellen. Fühlen Sie sich frei, mir eine Nachricht/E-Mail zu senden, wenn Sie darüber sprechen möchten.

Hallo zusammen,

@Dieterbe Ich habe gerade deine Präsentation gesehen und das Zeug sieht fantastisch aus. Ich weiß es wirklich zu schätzen, dass Sie versuchen, ein Warnsystem auf die "richtige" Weise aufzubauen, indem Sie viel Community-Input verwenden! Vielen Dank!

Ich möchte meinen Standpunkt auch etwas klarer machen, da ich glaube, dass es nicht offensichtlich war, was ich sagen wollte. Ich _DARF_ NICHT_, dass grafana jedes andere Überwachungssystem wie Nagios, Icinga, Bosun usw. kennt. Ich brauche eigentlich nur das:

• Die tolle Benutzeroberfläche, die Sie in Ihrer Präsentation gezeigt haben oder wie auch immer sie aussieht, wenn sie fertig ist
• Ein generischer HTTP-POST-Handler (wie einige andere hier auch vorgeschlagen haben), der vollständig konfigurierbar ist (ich werde Ihnen später ein Beispiel geben)

Der Event-Flow, an den ich denke:

• Sie visualisieren Ihre Daten in grafana
• Sie fügen Schwellenwerte für die Benachrichtigung in grafana . hinzu
• Sobald ein Schwellenwert überschritten wird, wird der HTTP-POST-Handler getriggert
• Ab diesem Zeitpunkt ist die Arbeit mit Grafanas getan

Wie @mgravlin und @007reader erwähnt, verwenden die meisten Benachrichtigungs- und Warndienste HTTP POST, was verschiedene Arten von Daten erfordert. Die allgemeinste Sache, die mir einfällt, ist, den Benutzer seine POST-Daten und -Header definieren zu lassen, damit Sie mehrere Systeme mit einem Handler unter Verwendung verschiedener Vorlagen füttern können. Beispiel für Pseudocode:

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

Dem Benutzer genügend Variablen zur Verfügung zu stellen, die er hier verwenden kann, ist mächtig genug, um eine Menge Backends zu versorgen.

Und noch einmal, mit dieser Art von Handler kann jeder Systemadministrator mit Programmierkenntnissen seinen eigenen HTTP-Post-Empfänger erstellen und so umwandeln, wie er beispielsweise Backends füttern möchte, die HTTP-Post nicht verstehen.

Da dies zustandslos ist, wird es auch skaliert. Platzieren Sie einfach einen Load Balancer vor dem Backend/der API/was auch immer und Sie können loslegen.

Zumindest würde dies die meisten / fast alle meine Probleme lösen ;)

Danke schön

Vielen Dank, dass Sie diese Funktion erstellt haben. Gibt es dafür ein ungefähres Erscheinungsdatum?

torkelo sagte ungefähr 3 Monate im IRC.
Wenn ich ihn richtig verstanden habe, ist das eine wirklich grobe Schätzung und sollte auch so behandelt werden.

Ich bin begeistert von der Möglichkeit, mit Grafana Alarm zu machen. Ich denke, dass dies die einzige Funktion ist, die grafana davon abhält, das ultimative Monitoring-Tool zu sein.

Wenn Sie eine frühe Alpha-/Beta-Version haben, würde ich gerne testen und frühes Feedback mit Produktionsdaten geben.

++

Ich 2 lol

+1

Em seg, 16. Nov. 2015 bis 21:03, Jing Dong [email protected]
escreveu:

Wenn Sie eine frühe Alpha/Beta-Version haben, würde ich gerne testen und früh geben
Rückmeldung mit Produktionsdaten.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686.

+1
Wenn Sie eine frühe Alpha-/Beta-Version haben, würde ich gerne testen und frühes Feedback mit Produktionsdaten geben.

+1 ich 2

2015-11-21 14:44 GMT-02:00 chaosong [email protected] :

+1
Wenn Sie eine frühe Alpha/Beta-Version haben, würde ich gerne früher testen und geben
Rückmeldung mit Produktionsdaten.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -158661279.

+1

toll, all die +1 zu sehen, aber FWIW werden sie nicht wirklich benötigt. Wir wissen bereits, dass dies die am sehnlichsten erwartete neue Funktion ist, und sobald wir greifbare Fortschritte haben, wird der Code in einem separaten Zweig erscheinen, mit dem jeder spielen kann. Übrigens, wir bringen auch mehr Leute dazu, Vollzeit an Grafana zu arbeiten, also bleibt alle dran :)

Ja, bitte, es gibt 484 Leute, die diese Ausgabe "beobachten". Jedes Mal, wenn Sie "+1" geben, erhalten 484 Personen eine E-Mail-Benachrichtigung. Abonnieren Sie einfach die Benachrichtigung und sie zeigt Ihr Interesse an der Ausgabe an.

+1 >; P

Am Mo, 2015-11-30 um 10:33:52 -0800 schrieb Vadim Chekan:

Ja, bitte, es gibt 484 Leute, die diese Ausgabe "beobachten". Jedes Mal, wenn Sie "+1" geben, erhalten 484 Personen eine E-Mail-Benachrichtigung.

Entschuldigung, ich weiß, dass ihr sehr hart daran arbeitet. Gibt es einen Zeitplan für die erste Veröffentlichung?

Ich wäre mehr als zufrieden damit, Warnmetriken und Schwellenwerte konfigurieren zu können (entweder über die Weboberfläche oder die API) und einen Grafana-Cronjob/-Daemon, der diese Metriken überprüft und einen HTTP-POST mit JSON durchführt oder ein Skript mit JSON in stdout aufruft. Es wäre _extrem_ einfach für Einzelpersonen, ein einfaches Python-Skript zu schreiben, das diese Informationen an Pagerduty, Slack, IRC, SMS, E-Mail oder was auch immer weitergibt.

Obwohl ich den Komfort sehr schätzen würde, denke ich nicht, dass es Grafanas Aufgabe ist, sich eng in Tools von Drittanbietern zu integrieren, und würde lieber eine minimalistische Implementierung früher als eine gut ausgearbeitete später sehen.

Ich stimme @anlutro voll und ganz zu . Bitte geben Sie etwas Einfaches an, um loszulegen. Das Interessanteste für mich ist, den Leuten zu ermöglichen, selbst einfache Benachrichtigungen zu setzen (Self-Service). Grafana sollte nicht versuchen, bestehende Benachrichtigungs-/Eskalationslösungen zu ersetzen.

Ich stimme auch @anlutro zu. Aber anstatt nur eine einfache API bereitzustellen, sollte der Warnteil in der Lage sein, benutzerdefinierte Plugins zu verarbeiten, die mit der API interagieren. Auf diese Weise könnte das Basispaket E-Mail, Pagerduty und ein paar andere enthalten, dann könnte die Community es nach Bedarf hinzufügen. Ähnlich wie jetzt mit Logstash-Plugins umgegangen wird.

+1

Gibt es Neuigkeiten zum Warnsystem? Irgendwelche Schätzungen?

+1

+1
Erwähnenswert sind die Treffer- und Hysterese-Mechanismen bei Sammelalerts als zu berücksichtigendes Konzept.

Haben Sie an erweiterte Warnfunktionen wie Anomalieerkennung, Korrelationserkennung, Ursachenerkennung usw. gedacht?

+1. Alerting als Plugin-Subsystem - dies wäre die flexibelste Lösung. Sie müssen nicht so viele Funktionen in grafana hinzufügen, wenn es viele Projekte gibt, die dies im Backend besser können.

@Dieterbe @torkelo Es wäre toll, auch nur eine sehr grobe "Schätzung" dazu zu haben. Persönlich habe ich daran festgehalten, da metrikbasierte Self-Service-Benachrichtigungen in meinem Fall eine dringend benötigte Funktion sind und ich bin überzeugt, dass Grafana das richtige Benutzer-Frontend dafür ist. Das Problem ist, dass es jetzt 6 Monate her ist und es seit einiger Zeit kein ETA-Update oder auch nur einen Kommentar von einem von euch gibt, also fange ich an, kontraproduktive "Ich muss nur etwas hacken"-Gedanken zu haben. ..Wenn ich nur wüsste, ob es noch 6 Monate oder noch ein paar Wochen dauern wird, könnte ich eine viel besser informierte Entscheidung treffen.

Vielen Dank!

+1
Am 18. Januar 2016 um 21:54 Uhr schrieb "Jaime Gago" [email protected] :

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo Es wäre toll, auch ein sehr grobes zu haben
"vermuten" dazu. Persönlich halte ich seit Metriken durch
basierte Self-Service-Benachrichtigungen sind in meinem Fall eine dringend benötigte Funktion, und ich bin
überzeugt, dass Grafana das richtige User-Frontend dafür ist. Das Problem ist, es ist jetzt
seit 6 Monaten und es gab kein ETA-Update oder sogar einen Kommentar von einem von
Sie für eine ganze Weile, also fange ich an zu haben "Ich muss einfach"
etwas hacken" kontraproduktive Gedanken...Wenn ich nur wüsste, ob es so ist
es werden noch 6 Monate im Vergleich zu ein paar Wochen mehr, in denen ich viel verdienen könnte
besser informierte Entscheidung.

Vielen Dank!

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -172722684.

+1

+1

@jaimegago tut ich hier nicht über unseren Fortschritt oder mangelnden Fortschritt in diesem Thema

Bereits im September begann ich mit der Arbeit an der Elasticsearch-Datenquellenunterstützung, die die Grundlage für eine datenquellenorientierte 2.5-Version wurde, danach war das am besten bewertete Problem in Grafana seit v1 ein Tabellen-Panel, und besonders nach der Elasticsearch-Unterstützung fühlte ich eine kleine Version mit einer Tabelle war wichtiger als die Alarmierung, so dass dies die Grundlage für 2.6 wurde.

In letzter Zeit haben viele Benutzer und Unternehmen den Wunsch, mehr mit Grafana zu integrieren, was uns veranlasst hat, an der Verbesserung der Plugin-API und der Funktionen zu arbeiten, was zu einer weiteren Verschiebung dieses Problems führte. Es tut mir wirklich leid, dass wir das so schlecht kommuniziert haben. Wir hatten immer den Ehrgeiz, SOON zu starten, aber SOON wurde immer wieder gepusht :(

Aber es gibt Hoffnung! Wir haben das hauptberuflich auf Grafana fokussierte Team erweitert, im Dezember ist @bergquist dazugekommen und im Februar werden wir wieder Verstärkung bekommen. Ich kann keine ETA anbieten, aber dies ist immer noch ein Thema mit hoher Priorität und wir möchten so schnell wie möglich beginnen. Wir möchten, dass diese Funktion die Schlagzeilenfunktion für Grafana 3.0 ist.

@torkelo Danke für das Update; Ich kann nicht sagen, dass ich glücklich bin, aber zumindest wissen wir neu, wo wir stehen.

Eine verbleibende Frage ist, ob 2.x weitere Punktversionen erhalten wird oder ob 3.x die nächste Version sein wird. ;)

@RichiH bezüglich eines weiteren Point-Release, nicht sicher, aber es ist wahrscheinlich, dass im Februar ein weiterer Point-Release vor 3.0 veröffentlicht wird.

@torkelo Vielen Dank, dass Sie sich die Zeit genommen haben, ein detailliertes Update bereitzustellen.

vielleicht ist dies bereits auf der Roadmap, wenn nicht, erwägen Sie bitte, den "POST" ab der Benachrichtigung hinzuzufügen.
So können wir die Warnung an ein anderes System senden, um sie zu verarbeiten, wie zum Beispiel kafak

+1 für SNMP-Benachrichtigungen!

+1 Ich denke, dies ist das größte fehlende Feature von Grafana, um es zu einem praktikablen (und branchenführenden) Überwachungstool für die Produktion zu machen.

+1

Gibt es einen Administrator (@Dieterbe?), der Kommentare zu diesem Problem von Nicht-Mitarbeitern sperren kann? Wir werden also nur interessante Inhalte zum Funktionsfortschritt bekommen und nicht diese nutzlosen +1...

Falls Sie diese Funktion nicht kennen, hier ist der Link zum Ad-hoc-GitHub-Dokument .

Danke Schatz:

@Mayeu äh, als einer der "Nicht-Kollaborateure", die mit mehr als einem +1 zu diesem Problem beigetragen haben, und an anderen Stellen glaube ich nicht, dass es der richtige Weg ist, dieses Problem an Mitarbeiter zu sperren. Erstellen Sie einfach einen intelligenten Filter für Ihre E-Mail ;-).

Ich denke auch, dass die +1 einen Zweck erfüllen, indem sie die Höhe und die Streuung der Zinsen dafür (und anderswo) anzeigen.
Was vielleicht fehlt, ist eine +1-Schaltfläche in der Benutzeroberfläche, die dieselbe Rolle ausfüllen würde, jedoch ohne alle Benachrichtigungen an alle Abonnenten.. also eine Funktionsanfrage für @github.

Wir driften vom Thema ab und dies ist das erste und letzte Mal, dass ich darüber schreibe.

Jeder, der sich für diese Ausgabe interessiert, sollte sich oben rechts abonnieren; es hält Sie auf dem Laufenden und Sie werden nicht an alle E-Mails senden.

Zu einem Abstimmungssystem, um die Ansammlung von +1 zu verhindern, siehe https://github.com/dear-github/dear-github - 27 Tage alt und keine Reaktion von GitHub.

+1

Irgendetwas Neues darüber ?

Ich glaube, es gibt noch keine Neuigkeiten zu diesem Thema. Aber das Gute an Grafanas nächster Veröffentlichung ist:

Grafana wird in der Lage sein, benutzerdefinierte Apps/Plugins zu übergeben. Dann können wir unsere eigenen benutzerdefinierten Plugins/Apps für Benachrichtigungen schreiben und in Grafana importieren. Das Schreiben dieser kleinen Apps/Plugins wird ein schneller Gewinn sein, während Sie auf eine große Benachrichtigungsfunktion warten.

Ich mag die Idee, Warnungen an derselben Stelle zu konfigurieren wie die Visualisierung. Erstaunliche Mocks auf https://www.youtube.com/watch?v=C_H2ew8e5OM, aber gibt es irgendwelche Daten, wann es veröffentlicht wird?

schönes video, danke!

einige Rückmeldungen.

Ich bin mit der Idee einfacher linearer Schwellenwerte und erweiterter benutzerdefinierter Abfragen zufrieden

Notifier am hilfreichsten:

• exec - könnte etwas wie ssh oder sendmail verwenden
• Webhooks - Der Benutzer könnte ein Webcgi aufstellen, um Webhooks aufzunehmen, um Dinge zu tun ...
• email - feuern Sie eine einfache E-Mail mit einem Json-Dump der Benachrichtigungsdaten ab.
• Plugins... nicht wirklich nötig

api zum Abrufen des Alarmzustands ... fühlt sich wie eine schlechte Idee an,
Eine API zum Abrufen der Alert-Konfiguration in einem einfachen Json-Format könnte jedoch nett sein.
Dieser Json-Dump könnte in etwas umgewandelt werden, das für andere Systeme hilfreich sein könnte.

Ich bin mir nicht sicher, ob dies verpönt ist oder nicht. Ich konnte nirgendwo einen Spendenlink finden, aber welche Art von Beitrag wäre notwendig, um dies bis Ende des Monats in v3 zu bringen sind Geldautomaten gefesselt

+1

+1

Dies ist eine dringend benötigte Funktion für uns hier bei Work Market.

Werden die vorgestellten Benachrichtigungen gestartet?

Nein
Am Do, 25. Februar 2016 um 23:13 Uhr schrieb kskaran94 [email protected] :

Werden die vorgestellten Benachrichtigungen gestartet?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -189143056.

Wäre es sicher davon auszugehen, dass die Benachrichtigungsfunktion im Sommer veröffentlicht wird?

_Spannung nimmt zu_
Am 26. Februar 2016 um 10:23 Uhr schrieb "Ian Ha" [email protected] :

Wäre es sicher davon auszugehen, dass die Benachrichtigungsfunktion im
Sommer?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -189320869.

Irgendetwas Neues darüber?

+1

+1 wäre schön, es schon zu haben, die Leute warten schon das ganze Jahr oder noch länger.

:+1: Ich mag es. Danke für das Video und die Präsentation, @Dieterbe. Ist es zum Testen/Early Adopters verfügbar?

@torkelo Du hast angekündigt

Wir möchten, dass diese Funktion die Schlagzeilenfunktion für Grafana 3.0 ist

Aber wenn ich mir das 3.0 unveröffentlichte Änderungsprotokoll (1) anschaue, wird die Warnung nicht erwähnt, sollte ich anfangen zu weinen oder ist es immer noch geplant, Warnungen für die 3.0-Schlagzeilenfunktion zu haben?

(1) https://github.com/grafana/grafana/blob/master/CHANGELOG.md

Wir haben uns entschieden, das Plugin-System für grafana 3 so auszuarbeiten, dass wir grafana 3 veröffentlichen und dann mit der Alarmierung beginnen können, anstatt grafana 3 unnötig zu verschieben.

@Dieterbe Ich kann nicht sagen, dass ich glücklich bin, aber das macht Sinn. Das offensichtliche Follow-up ist, wenn es etwas ETA-artiges gibt, um zu alarmieren; und wenn es sich um ein bestätigtes und festgeschriebenes Feature für 3.1.

Als Workaround macht http://alerta.io/ einen Teil dessen, was Grafana tun soll; Leute, die auf diese Funktion warten, möchten sie vielleicht ausprobieren.

Gibt es eine Spezifikation für das Plugin? Könnte gut sein, etwas in der zu bauen
Community, die Benachrichtigungen mit der Veröffentlichung von Version 3 zu behandeln?

Beth
Am 16.03.2016 8:44 Uhr, "Richard Hartmann" [email protected]
schrieb:

@Dieterbe https://github.com/Dieterbe Kann nicht sagen, dass ich glücklich bin, aber das
macht Sinn. Die offensichtliche Folge ist, ob es etwas ETA-artiges gibt für
Alarmierung; und wenn es sich um ein bestätigtes und festgeschriebenes Feature für 3.1.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe Ich denke, es wäre auch schön, eine Benachrichtigung auf der Clientseite erstellen zu können. Zum Beispiel Sprachnachrichten auf einem öffentlichen Monitor mit Dashboard, sodass Sie nicht auf das Dashboard schauen müssen, um zu wissen, dass es Probleme gibt. Wie Zabbix-Soundwarnungen. Zu diesem Zweck habe ich einfachen JavaScript-Code geschrieben , der ein bestimmtes Dashboard scannt und mich bei Problemen über die Web Speech API benachrichtigt. Momentan funktioniert es bei mir super.

Wie wäre es mit der Verwendung von Kapacitor als Backend für Warnungen, deren Skriptsprache einfach und sehr leistungsstark ist? Oder was ist mit der Unterstützung für mehrere Benachrichtigungs-Back-Ends und der Abstraktion darüber.

Jetzt, da 3.0 herauskommt, freue ich mich sehr, hoffentlich Alerts in Grafana zu haben. Alerting macht grafana zum ultimativen Werkzeug.

Hallo @Dieterbe ,

Wie ich aus dieser Version https://github.com/raintank/grafana (von der Sie sagten, dass sie das Alerting-Paket enthält) ersehen kann, ist das Repo jetzt veraltet und es heißt, dass alle neuen Entwicklungen in https://github stattfinden. com/raintank/worldping-api. Da frage ich mich, ob diese Benachrichtigungsfunktion noch in Entwicklung ist oder für etwas anderes geplant und geändert wurde (wie worldPing, das nicht so aussieht, wie wir es hier

Hallo @minhdanh , das Ziel war immer, Warnungen "richtig" in Grafana hinzuzufügen, nicht nur als Hack in einer Raintank-spezifischen Gabel, auf die Sie sich beziehen (und das deckte ohnehin nur einen sehr engen Bereich ab). obwohl es sinnvoll sein kann, einen Teil dieses Codes wiederzuverwenden, sobald wir mit der Arbeit an einem Scheduler/Executor beginnen, den dieses Repository hatte). Deshalb haben wir hart daran gearbeitet, grafana für das kommende grafana 3-Release so steckbar zu machen. (und als Ergebnis daraus konnten wir unsere eigenen Bedürfnisse in eine eigenständige App verlagern, die die Worldping-Api ist, auf die Sie sich beziehen).
Es ist sehr klar geworden, dass wir als ersten Schritt einfach die Benutzeroberfläche erstellen sollten, um die Regeln aus Ihren Grafana-Dashboards und -Panels heraus zu verwalten und sie über eine Art API verfügbar zu machen, damit Plugins sie verwenden können, um sie auszuführen. Dies ist der schnellste Weg, um die Benachrichtigung in Gang zu setzen. der "Batterien enthalten Scheduler/Executor" würde dann später kommen und möglicherweise einen Teil des Codes wiederverwenden, auf den Sie sich bezogen haben.

Wie auch immer, wir erstellen zuerst die Verwaltungsoberfläche in Grafana und stellen die Regeln über die API zur Verfügung, und wir übernehmen es von dort.

Danke @dieterbe.

Wie immer stellt sich die Frage nach einem groben Zeitplan, auch wenn es nur "nicht
vor X".

Ich verstehe, wie nervig diese Frage sein kann, daher die Formulierung in der
zweiter Teil. Ich hoffe ihr versteht, wie frustrierend das Warten auf den anderen ist
Seite des Zauns sein kann.

Richard

Per Handy gesendet; entschuldige meine Kürze.

Hallo zusammen,

Ich hoffe, es ist in Ordnung, dass Raintank es hier sagt, aber wir haben vor kurzem fast einen Monat lang dedizierte Codierungsstunden bei Raintank bestellt, um an der Alarmierung zu arbeiten. Warum dies also noch nicht zu einer endgültigen Alarmierungsfunktion führen wird, sollten wir bald etwas sehen, um die Grundlage für die Alarmierung in Grafana zu legen. Wenn andere Unternehmen unserem Ansatz folgen würden oder auch Einzelpersonen etwas Geld in diese Angelegenheit investieren, sollte das Denken und Prioritäten noch mehr beschleunigen.

@flyersa ,

Jon

Hallo alle,

Ich weiß, dass viele auf diese Funktion gespannt sind, und ich freue mich, Ihnen mitteilen zu können, dass das Team damit begonnen hat, daran zu arbeiten. Wir haben unsere Gründe für die Verzögerung im Blog zur

Wir werden die Alarmierung in zwei Phasen freigeben. In der ersten Phase können Benutzer ihre Warnungen und Schwellenwerte innerhalb der Grafana-Benutzeroberfläche definieren. Grafana wird diese Warnungsdefinitionen auch über eine HTTP-API für Drittanbieter-Scheduler und Warnungs-Back-Ends verfügbar machen. In der zweiten Phase werden wir den Backend-Service bereitstellen, um diese Definitionen für eine vollständig integrierte Lösung zu nutzen und zu handeln.

Wir hoffen, dass die erste Phase in wenigen Wochen veröffentlicht wird.

Wir versuchen, Profitabilität mit Geschwindigkeit in Einklang zu bringen, und wir schätzen die kommerzielle Unterstützung unserer Kunden wie @flyersa SEHR. Wenn andere die Entwicklung dieser Funktion und Grafana im Allgemeinen unterstützen möchten, erwägen Sie bitte den Kauf eines Supportplans . Es wird uns helfen, großartige Software zu entwickeln, die zu 100 % Open Source ist.

Wir werden bei der Einführung der Funktion eng mit allen unterstützten Kunden zusammenarbeiten und sicherstellen, dass sie deren Anforderungen gut erfüllen.

-raj dutt | CEO/Mitbegründer | Regentank

Hallo @nopzor1200 ,

Danke für dein Update. Haben Sie eine Schätzung, wann Benachrichtigungen verfügbar sein werden?

Natürlich ist es unmöglich, sich auf ein bestimmtes Datum festzulegen, aber ein Zeitrahmen wird sehr geschätzt (Wochen, Monate usw.).

10x!

Hallo Leute, bin echt gespannt darauf. So stelle ich mir vor, dies zu verwenden, wenn jemand stichprobenartig überprüfen kann, ob es sich um ein standardmäßiges / unterstütztes Muster handelt, würde ich es begrüßen.

• Jeder Host, den ich überwachen möchte, gibt "Checks" aus. Ein „Check“ besteht aus:
  
  
  
  • der Hostname
  
  
  • der Zeitstempel
  
  
  • der Status, der entweder 0=OK, 1=WARN oder 2=CRITICAL ist
  
  
• Diese Prüfungen können aus einer Vielzahl von beliebigen Quellen stammen (Shell-Skripte + cron, statsd/collectd, Nagios-Prüfungen usw.) und werden in Elasticsearch gesammelt. Dieselbe Prüfung kann auf verschiedenen Hosts unterschiedliche Konfigurationen aufweisen, dies ist jedoch für Grafana undurchsichtig.
• Ich werde Grafana konfigurieren, sich mit Elasticsearch zu verbinden und zu warnen, wenn eine Prüfung von einem Host den Statuswert >= 1 hat.
• Wenn neue Hosts dem Cluster beitreten, ist in Grafana keine Konfiguration erforderlich; Grafana sieht einfach jeden Datenpunkt im Zustand 1 oder 2, unabhängig davon, woher er stammt.
• Wenn ein Host plötzlich stirbt und keine Schecks mehr sendet, müssen wir dies erkennen. Um dies zu handhaben, registriert ein Host beim Start eine Masterprüfung als "ON"-Status, und der Wert geht nur auf "OFF", wenn er normal gestoppt wird. Auf diese Weise kann ich nach "ON"-Hosts suchen, die in den letzten X Sekunden keine Überprüfungen ausgegeben haben.
• Im Allgemeinen werde ich keine schwellenwertbasierten Warnungen für Zeitreihendaten in Graphana verwenden. Mit anderen Worten, ich werde nicht in Grafana selbst "überprüfen, ob CPU-Auslastung > 80%", sondern Grafana erhält eine "CPU-Auslastungsstatus"-Prüfung (0 / 1 / 2) und eine Warnung im 1- oder 2-Zustand.

Hey @johnnyshields ,

Das sieht ziemlich gut aus, aber warum nicht statt "0=OK, 1=WARN oder 2=CRITICAL" eine Standard-Level-Definition verwenden? Der von syslog verwendete ist so ziemlich ein De-facto-Standard für diese Dinge:

• Wert -> Schweregrad
• 0 -> Notfall
• 1 -> Warnung
• 2 -> Kritisch
• 3 -> Fehler
• 4 -> Warnung
• 5 -> Hinweis
• 6 -> Information
• 7 -> Debuggen

Und verfügen Sie über eine (globale?) Konfiguration, um grafana mitzuteilen, welche Ebene als Alarmschwelle betrachtet werden soll.

Vor diesem Hintergrund würde ich Ihrem Beitrag folgende Änderungen hinzufügen:

• Warnung, wenn eine Prüfung von einem beliebigen Host den Statuswert >= CONFIGURABLE_ALERT_LEVEL hat.
• Grafana sieht einfach jeden Datenpunkt im Zustand >= CONFIGURABLE_ALERT_LEVEL, egal woher er kommt
• Grafana erhält bei entsprechender Konfiguration eine Prüfstufe "CPU Usage State" und eine Warnung.

@brunorey danke, macht Sinn!

Protokollebenen und Status sind zwei verschiedene Dinge. Sie könnten eine 6-Informations-Protokollmeldung haben, aber wie kann etwas in einem 6-Informations-Zustand sein?

Die Zustände OK, WARN und CRITICAL sind in Ordnung und möglicherweise zu gut für diejenigen, denen nur OK und CRITICAL wichtig sind. Das Hinzufügen weiterer Zustände führt zu Verwirrung, es sei denn, ihre Bedeutung wird allgemein verstanden, und ich schlage vor, auf 3 zu begrenzen.

In Bezug auf nur Warnungen bei "CPU-Status >= WARN" im Vergleich zu "CPU > 80%" behaupte ich, dass einige Leute ihre 3-Ebenen-Zustände in einer Zeitreihen-DB behalten möchten, damit sie sehen können, wie sich der Zustand im Laufe der Zeit verändert hat. Diese Personen werden basierend auf ihren staatlichen Zeitreihendaten alarmiert. Andere möchten darauf hinweisen, dass der CPU-Rohwert über 80% liegt. Der Punkt ist, dass das Abmelden von Zeitreihendaten das Einzige ist, was benötigt wird.

Der Grund, warum ich das Verhältnis von ganzzahligen Protokollzuständen anstelle der direkten Verwendung der Zeitreihendaten wähle, besteht darin, dass ich in der Lage sein möchte, steuern zu können, was auf jedem Knoten als Warnung angesehen wird.

Worker-Server haben zum Beispiel routinemäßig eine CPU von fast 100 %, und das ist kein Problem – ich möchte, dass sie auf allen Kernen Vollgas geben. Webserver sollten jedoch keine CPU über 20% haben. Wenn ich also eine generische CPU > 80% machen würde, wäre sie für die Webs zu hoch und für die Arbeiter zu niedrig. (Dies ist nur ein Fall).

@johnnyshields Ich verstehe nicht, warum Sie keine schwellenwertbasierten Warnungen für Zeitreihendaten verwenden würden, IMO ist das der wirklich starke (einzige?) Wert des Hinzufügens von Warnungen zu Grafana / Graphit. Deine Sachen im "Checks"-Stil klingen besser für etwas Einfaches wie Monit - habe ich hier etwas übersehen?

Wie oben erläutert, habe ich viele Server mit unterschiedlichen Rollen und die Schwellenwerte sind je nach Server unterschiedlich. Letztendlich ist es eine Frage, ob Schwellenwerte innerhalb von Grafana oder auf dem Server selbst definiert sind, ich denke, der Server ist in meinem Fall einfacher.

Darüber hinaus sind einige Prüfungen "ja oder nein", z. B. läuft Prozess X, antwortet ein Ping auf Port Y usw.

Verstanden. Manchmal ist die Bestimmung dieser Zustände einfach (> 80%), manchmal ist es komplex. Wenn sie komplex sind, bestimmt ein Code die Level und sendet den Level an eine TS-Datenbank. Das ist eine gängige Praxis, bei der Daten in Informationen umgewandelt werden. Mein Punkt ist, es gibt keinen Unterschied zu einem alarmierenden Sinn.

Wenn Sie komplexe Regeln für Ihre Warnungen benötigen, bauen Sie die Regeln nicht in die Warnungs-Engine ein, bauen Sie die Regeln in die TS-Pipeline ein, um neue TS-Daten zu erstellen, und geben Sie Warnungen ab.

Vereinfachen Sie das Warnsystem. Komplexität in der TS-Pipeline ausblenden.

Der Vorteil der Erstellung neuer TS-Daten in einer Pipeline gegenüber einem regelbasierten Warnsystem besteht darin, dass Warnmeldungen für die Personen, die die Warnmeldungen einstellen und erhalten, visuell und einfach bleiben. Es gibt eine Visualisierung, die per E-Mail oder SMS gesendet werden kann, die genau das zeigt, bei dem eine Warnung angezeigt wird – selbst wenn es sich um ein einfaches Statusdiagramm handelt, in dem der Status vor 20 Minuten von WARN auf CRITICAL geändert wurde.

Ich denke, wenn Sie steuern möchten, was auf Host-/Rollenbasis als alarmierend angesehen wird, sind Sie genauso gut dran, Logik zu dem hinzuzufügen, was als WARN und was als CRIT gilt, wie Sie 8 Ebenen der Granularität zum Schweregrad hinzufügen Alarm.

Fast alle anderen modernen Alarmierungssysteme scheinen auf OK/WARN/CRIT konvergiert zu sein, und obwohl es wahrscheinlich teilweise darum geht, Kompatibilität mit Nagios-Prüfungen zu wünschen, denke ich, dass die Idee, es einfach zu halten, wichtiger ist. Wenn Grafana dasselbe tut, wird die Integration mit anderen Alarmierungs-/Überwachungsdiensten einfacher. Zum Beispiel würde ich in meinem Fall wahrscheinlich Grafana-Warnungen an Sensu füttern, die dann eine E-Mail, eine Slack-Nachricht oder was auch immer versenden würden. Sensu hat nur OK/WARN/CRIT, also würde mehr Granularität verschwendet.

Die Protokollwarnungsstufe zustimmen scheint übertrieben zu sein. OK, warnen, Crit wird wahrscheinlich in den meisten Fällen den Job erledigen.

Bei Schwellenwerten für Warnungen würde ich gerne auf Standardabweichungen basierende Warnungen durchführen können. Sie sind in der Praxis imo am nützlichsten.

Am 12. Mai 2016 um 8:49 Uhr schrieb RWhar [email protected] :

@johnnyshields Ich verstehe nicht, warum Sie keine schwellenwertbasierten Warnungen für Zeitreihendaten verwenden würden, IMO ist das der wirklich starke (einzige?) Wert des Hinzufügens von Warnungen zu Grafana / Graphit. Deine Sachen im "Checks"-Stil klingen besser für etwas Einfaches wie Monit - habe ich hier etwas übersehen?

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an

Persönlich habe ich mich darauf gefreut, Warnungen zu verwenden, bei denen vorhandene TS-Daten als Eingabe in Graphit eingespeist werden, insbesondere die Aggregation von Statistiken aus Anwendungsmetriken von (über StatsD) innerhalb bestimmter Zeitbereiche.

Außerdem wäre es schön, eine Option zu haben, bei der Warnungen beim Schwellenwert ausgelöst werden könnten und festgelegte Intervalle über den Schwellenwert hinaus - z müssen Sie manuell zusätzliche Schwellenwerte angeben.

@johnnyshields Ich verstehe nicht den Unterschied zwischen 1=WARN oder 2=CRITICAL. Die Warnung wird entweder ausgelöst oder nicht ausgelöst. Sie sind entweder über 80 % oder nicht über 80 %. Ich sehe also nur zwei Zustände 0 und 1.
Es wäre auch schön, eine intelligentere Benachrichtigung zu haben, bei der Sie erkennen können, dass Sie 5 Minuten lang über 80% waren, damit Sie nicht bei vorübergehenden Spitzen gewarnt werden. Noch fortgeschrittener sind Dinge wie das Verschieben von Schwellenwerten, bei denen Sie beispielsweise Ihren Website-Traffic überwachen, und Sie erhalten X Traffic und dieser steigt langsam, sagen wir, 1 % pro Monat, aber plötzlich erhalten Sie einen Anstieg des Traffics um 10 % in a Stunde. Sie möchten auch in der Lage sein, das Gegenteil, einen plötzlichen Verkehrsabfall, zu überwachen. Etwas Ähnliches wie https://github.com/etsy/skyline, da Skyline nicht mehr existiert.

Leute, in meinem Beitrag hier ging es nicht um die genaue Anzahl der zu verwendenden Warnmeldungszustände - ich fragte allgemeiner: "Wird Grafana aufgezählte Zustände als Anwendungsfall für Warnmeldungen unterstützen?"

Da es Meinungsverschiedenheiten über die optimale Zahl gibt (Nagios verwendet 3, Syslog verwendet 7, manche Leute mögen 2 usw.), sollte Grafana eine beliebige Anzahl von Zuständen unterstützen.

Ich möchte nur wiederholen, was ich zuvor gesagt habe, dass es meiner Meinung nach nur zwei Zustände für jede ausgelöste Warnung 1 oder nicht ausgelöste 0 geben sollte. Wenn Sie wissen möchten, ob Sie sich einem Schwellenwert nähern, legen Sie einen zusätzlichen Schwellenwert für den niedrigeren Wert fest.

Der Grund für WARN vs. CRITICAL ist, dass die Aktionen, die Sie ergreifen, unterschiedlich sind. Eine Gruppe von Personen und Aktionen werden in der Regel bei WARN und eine andere Gruppe/andere Aktionen bei CRITICAL benachrichtigt.

Das ist eine ziemlich wertvolle Unterscheidung, die ich mit einem 0-1-System nicht weglassen möchte.

@lorenwest Wenn Sie eine andere Prüfung für einen anderen Schwellenwert wünschen,
jeder Schwellenwert ist also entweder 0 oder 1.
Ein weiterer Grund, warum Sie die Benachrichtigungen auf diese Weise einrichten möchten, ist, wenn Sie eine E-Mail wünschen, wenn der Schwellenwert über 70 % liegt, aber eine Seite, wenn Sie über 80 % sind. So wie Sie separate Gruppen wünschen. WARN vs. CRITICAL hat zu viel Mehrdeutigkeit.

@doanerock das macht Sinn. Das Zulassen einer beliebigen Anzahl von Warnungen zu einer beliebigen TS-Metrik oder einem Ereignis ermöglicht die größte Flexibilität. Dies vereinfacht die Definition von Warnungen, da nicht mehrere Aktionen für mehrere Ebenen vorhanden sind.

so:

• Metriken können eine beliebige Anzahl von Zuständen haben (einschließlich Dezimal-/Zeitreihenwerte)
• Metriken können mehrere Warnaktionen an dieselbe Metrik anhängen
• jede Warnung ist ein boolescher Wert true oder false -- sie wird entweder ausgelöst oder nicht ausgelöst.

um ein beispiel zu geben:

• Ich habe eine bestimmte Metrik mit den Werten 0 = OK, 1 = WARN, 2 = CRITICAL
• Ich konfiguriere 3 Warnungen:
  
  
  
  • wenn Wert = 1, zeige eine gelbe Flagge in meinem Dashboard
  
  
  • wenn Wert = 2, zeige eine rote Flagge in meinem Dashboard
  
  
  • wenn Wert >= 1, schick mir eine E-Mail
  
  

Hallo alle,

Ich weiß nicht, ob es der richtige Ort ist, um nach diesem Thema zu fragen, aber ich werde es in Bezug auf das kommende Grafana-Benachrichtigungsmodul versuchen.
In unserer Organisation haben wir alle unsere Sicherheitswarnungssensoren, die Logstash/Elasticsearch nach Ereignissen füttern, und wir verwenden Yelp/elastalert , um Warnungen mit bestimmten Mustern mit folgenden Kriterien auszuführen:

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

Wenn Warnkriterien erkannt werden, führen wir außerdem ein externes Python-Skript mit Argumenten aus, das Argumente von Elastalert an das Skript mit Informationen wie Quell-/Ziel-IP-Feld, Ereignis- und Zeitstempelfeld weitergibt, und unser NAC-System kümmert sich von dort aus.

Wenn ich mir nun das Grafana Upcoming Alerting-Modul und Elasticsearch als Datenquelle ansehe, frage ich mich, ob das Grafan Alerting-Modul genauso wie Elastalert kooperieren und schließlich durch die oben genannten Informationen ersetzen kann?
Bitte beraten

Vielen Dank

Ich weiß, dass das Grafana-Team hart daran arbeitet, und dieser Thread ist lang, aber ich möchte darauf hinweisen, dass Kapacitor gerade eine Funktion zusammengeführt hat, die die Entwicklung von Frontend-Alert-Konfigurationsanwendungen erheblich erleichtern wird: influxdata/kapacitor#577

Soweit ich weiß, besteht das Ziel auf der Grafana-Seite darin, das Benachrichtigungs-Backend steckbar zu machen (genauso wie Grafana mehrere TSDB-Speicher unterstützt), aber ich wollte erwähnen, dass Kapacitor erstklassige Unterstützung erhält, wenn die Benachrichtigungsfunktion von Grafana veröffentlicht wird. Es sieht gut aus, genauso wie InfluxDB + Grafana.

@thom-nic danke für den Tipp Kapacitor ist genau das was ich suche...

Riemann ist auch großartig und sehr mächtig. telegraf -> riemann (alarmierend) -> influxdb <- grafana

Wir machen Fortschritte im Alerting_definitions-Zweig.

Wir haben jetzt ein einfaches Alert-Regelmodell, das Sie in der Benutzeroberfläche und über die HTTP-API definieren können. Sie können Regeln, Regeländerungen und Regelzustände über die HTTP-API abrufen. Auch die einfache Planung von Warnungsregeln und die Ausführung von Abfragen und die Ausführung von Regeln beginnen, zusammenzukommen.

Ein großes Fragezeichen für mich ist jetzt, ob das aktuelle Alert-Modell zu einfach und eine Sackgasse ist. Damit meine ich, dass die Erweiterung des Alert-Regelmodells in der Zukunft umfangreiche Änderungen erfordern wird.

Aktuelles Regelmodell:

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

Dieses Speichermodell wird sowohl im UI als auch in der eigentlichen Datenbanktabelle dargestellt. Meine Befürchtung ist, dass dieses einfache Regelmodell Zeitreihendaten nicht gut genug nutzt. Sie können keine dynamischen Schwellenwerte angeben (wobei die Schwellenwerte selbst Ergebnisse einer Abfrage sind). Natürlich das
könnte später hinzugefügt werden, würde aber ein ganz anderes Regelmodell und eine andere Ausführungs-Engine erfordern.

Meine Idee ist es also, dieses einfache Modell zu verwerfen und ein neues, komplexeres und dynamischeres Modell zu entwickeln, das später mehrere Abfragen für verschiedene Zeiträume unterstützen kann.

Einfache Abfrage:

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

// jetzt zu einem Alert, der basierend auf seinen übergebenen Werten einen dynamischen Schwellenwert verwendet

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

Nun könnten Sie dies in Frage stellen, indem Sie sagen, dass wir Graphite hier neu erfinden, und solche Ausdrücke sollten von der TSDB behandelt werden. Aber keine TSDB unterstützt Berechnungen mit Abfragen für verschiedene Zeitbereiche (timeShift verschiebt nur die gleiche Zeitspanne). Einige Probleme mit dynamischen Schwellenwerten sind die Visualisierung. Es kann auch dazu führen, dass sich die Alarmierungsregel stärker von dem unterscheidet, was tatsächlich im Panel visualisiert wird.

Ich bin mir ziemlich unsicher, wie die GAL (Grafana Alerting Language) aussehen soll. Sollen es sich nur um Ausdrucksketten handeln, bei denen jeder Teil entweder eine Abfrage sein kann, die eine oder mehrere Reihen zurückgibt (jede Reihe auf einen Punkt aggregiert), und dann eine optionale Subtraktions- oder Prozentfunktion, die mit einer anderen Abfrage verglichen werden kann. Der gesamte Ausdruck führt zu einem Wert, der dann mit Operator- und Crit/Warn-Stufen verwendet werden kann, um den Alert-Status zu erhalten.

Oder sollte der Ausdruck den Operator und die Ebenen enthalten?

Andere Optionen würden eine vollständige Programmiersprache sein und Folgendes tun:

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

return percentDiff(last5minAvg, last24Avg)
"

@torkelo :

1. Bauen Sie dies als eigenständige Komponente? Letztendlich bauen Sie einen Signalprozessor ähnlich dem Kapacitor für Influxdb **, der selbst ein Signal
2. wird grafana in ähnlicher Weise die Möglichkeit haben, die obige Signal-Engine nicht zu verwenden, sondern stattdessen ein 0/1/2-Signal von einer Drittanbieterquelle wie einem Nagios-Plugin zu erhalten, von dem viele bereits in freier Wildbahn existieren?

** = Zugegeben Kapicator verwendet Zeitreihen-Stream-Verarbeitung, während Ihre Engine eine Polling-basierte Engine ist, aber dennoch ein Signal ausgibt.

Vielen Dank für die Bitte um Input.

Meine Meinung ist, Grafana-Warnungen einfach zu halten, und der beste Maßstab für Einfachheit ist die Visualisierung. Wenn Sie die Warnung nicht als Linie in einem vorhandenen TS-Diagramm visualisieren können, ist sie zu komplex.

Überlassen Sie die Komplexität dem TS-Graphen. Wenn die Warnung größere Anforderungen hat, erstellen Sie einen weiteren Satz von TS-Daten basierend auf diesen Anforderungen und platzieren Sie die Warnung in einem Diagramm dieser Daten.

Wenn Sie nur ein Leitprinzip haben, benötigen Sie eine einfache Visualisierung des Alerts.

Das andere Problem ist "wie viele Warnungen sollte ich konfigurieren"? Dieses Thema wurde in diesem Thread diskutiert, und ich bin der Meinung, dass Sie an Flexibilität verlieren, sobald Sie mehrere Warnungen in eine Warnung packen (Warnung, Fehler, hohe Warnung, niedrige Fehler usw.). Warnungen und Fehler sind unterschiedliche Dinge – sie haben unterschiedliche Ebenen, unterschiedliche Leute kümmern sich um sie und sie haben unterschiedliche Benachrichtigungsmethoden.

Halten Sie Benachrichtigungen einfach und lassen Sie mehrere Benachrichtigungen in einem Diagramm anzeigen.

Ich denke, dass #3677 (Generic Transforms on Time Series Query Results) hier sehr nützlich wäre. Mit diesen TSDB-unabhängigen Funktionen können Sie einen komplexen "Warnungsgraph" erstellen, in dem Sie einfache Festwertschwellen für warnen, krit. usw. verwenden können.

Das einfache Alert-Regelmodell wäre dann alles, was benötigt wird. Die Komplexität wird dann in der Erstellung und Kombination der Graphen „versteckt“.

Ich bin dafür, es einfach zu halten. Ich bin kein Entwickler, ich bin eher Light-Touch-Dev-Ops und möchte meine Grafana/Graphite-Plattform meinem Admin-Team zur Verwaltung übergeben. In diesem Fall wird ein Alert Builder, der dem vorhandenen ähnlich ist, viel einfacher sein. Nicht allzu viel Aufhebens, wenn es eine Menge neuer Anweisungen einführt, solange Regeln noch auf die gleiche Weise konstruiert werden können, wie dies bei Abfragen für Graphen derzeit der Fall ist, wird es leicht sein, sich damit zurechtzufinden.

tl;dr eine ganz neue Sprache kann übertrieben und zu komplex sein. Erstellen von Regeln mit Maus=gut.

Ohne eine ganz neue Sprache zu entwickeln, ging ich davon aus, dass dies größtenteils ein Frontend für bestehende Benachrichtigungsplattformen wie Kapacitor, Reimann & Bosun sein würde, ähnlich wie Grafana ein Frontend zum Verfassen von InfluxDB-Abfragen bereitstellt. zB wird das schwere Heben von einem Warnsystem eines Drittanbieters erledigt und Grafana stellt die Benutzeroberfläche bereit. Vielleicht ist das nicht der Fall?

IIRC, Grafana will den "Batterien im Lieferumfang enthalten, aber herausnehmbar" gehen. Dh es sollte eigenständig mit einer mitgelieferten Alerting-Engine funktionieren, aber auch an bestehende Plattformen anschließbar sein.

Ich würde sagen, dass es mit ein paar integrierten Methoden kommen muss - E-Mail (Liefern von SMTP-Host) und WebAPI/Webhook. Der Rest kann dann mit Plugins kommen, wie etwa der Integration in PagerDuty.

@felixbarny könntest du beschreiben, was du meinst, an vorhandene Plattformen anschließbar? Natürlich lassen sich die Warnmeldungen in viele vorhandene Warntools integrieren. Aber für andere Systeme könnte es schwierig sein, die Planung und Ausführung von Alarmregeln zu handhaben. Es wäre möglich, einfach die Regeln aus der Grafana HTTP API zu lesen. Aber es würde viel Code erfordern, um die Regelplanung und -ausführung zu handhaben. Wir werden aber natürlich die Möglichkeit bieten, die Regeln nur in Grafana zu definieren und ein anderes System die Regeln ständig auszulesen und auszuführen

@GriffReborn du
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

Diese Produkte eignen sich _bereits_ gut für komplexe, dynamische Alarme. Was sie nicht haben, ist ein schönes visuelles Frontend zum Konfigurieren und Verwalten von Warnungen, zum visuellen Identifizieren aktiver Warnungen usw. Was ich mir gewünscht hätte, ist eine Frontend-Benutzeroberfläche, die Konfigurationen im Wesentlichen auf Ihre (Grafana-unterstützten) Warnungen überträgt Wahlsystem, das dann tatsächlich die ganze Arbeit erledigt.

@thom-nic Ich stimme zu. Das Hauptaugenmerk sollte auf dem Aufbau eines Alerting-Dashboards liegen, das vorhandene Alert-Info-Feeds verwenden kann ("feed-agnostisch"). Die Erstellung einer von Grafana gesponserten leichten Signalverarbeitungs-Engine (idealerweise als Standalone) sollte zweitrangig sein.

@johnnyshields neue Panels zu

Ich denke auch, dass das einfache Modell ausreichen sollte und auch dazu führen wird, dass das lang ersehnte Feature so schnell wie möglich verfügbar ist. Grafana ist für Metriken gedacht, grundlegende Benachrichtigungen sollten ausreichen.

@torkelo Um ehrlich zu sein, bin ich mit Alarmierungsplattformen wie bosun nicht sehr vertraut und weiß nicht, wie eine ordnungsgemäße Integration konkret aussehen könnte. Ich bezog mich auf Dinge, die @Dieterbe sagte, zum Beispiel in seiner Grafanacon-Präsentation: http://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny Nun , das planen wir auch. Um APIs für andere Benachrichtigungs-Back-Ends zu verwenden, um die in Grafana definierten Regeln zu lesen. Wir werden jedoch nicht die Bridge bereitstellen, die die Warnungsregeln von Grafana liest und sie in eine andere Regelausführungs-Engine übersetzt.

Eine Idee, die wir jetzt haben, ist, einfache Regeln wie diese zu definieren

Sie können aber auch dynamische Schwellenwerte verwenden und mit einer anderen Abfrage oder derselben Abfrage, jedoch mit unterschiedlichem Zeitbereich und Aggregation vergleichen.

Eine weitere komplexe "Prognose"-Abfrage. Wenn eine Abfrage verwendet wird, um eine Trendlinie zu erhalten, prognostizieren Sie diese rechtzeitig und alarmieren Sie diese.

Scheint das Beste aus beiden Welten zu sein. Liebe diese Idee! Sind die „Evaluate Against“-Funktionen Teil von Grafana oder sind sie TSDB-spezifisch?

@felixbarny Sie sind Teil des Grafana-Warnungsregelmodells und werden von der Grafana-Warnungsregelauswertungs-Engine verarbeitet.

Können Sie mehrere Regeln an ein einzelnes Diagramm anhängen? Ich mag die Einfachheit von Warn-/kritischen Ebenen in einer Regel, und einige Diagramme haben sowohl hohe als auch niedrige Schwellenwerte, die entweder mehrere Ebenen in einer Warnung oder mehrere Warnungen in einer Grafik erfordern würden.

Und obwohl ich die komplexe Regelfunktionalität mag, kann dies alles erreicht werden, indem man einen anderen Graphen erstellt und diesen Graphen mit einer einfachen Regel alarmiert. Der Vorteil, die Komplexität aus dem Warnsystem herauszuhalten, besteht darin, dass die Historie der Umstände, die das Auslösen der Regel verursachen, in der TSDB gespeichert wird.

Auf diese Weise können Sie eine Warnung als einfache horizontale Linie in einem Diagramm visualisieren und sehen, wie diese Regel im Laufe der Zeit ausgelöst wurde (oder wurde).

Es hält die Alarmierung für den Durchschnittsmenschen einfach, für jeden komplex genug und für diejenigen zugänglich, die Dinge visuell verstehen.

@lorenwest ja, wir werden die Dinge einfach halten und nur eine Warnungsregel pro Panel zulassen. Aber eine Regel kann eine Abfrage verwenden, die viele Serien zurückgibt, wodurch die Regel im Grunde in mehrere aufgeteilt wird (so können Sie eine einzelne Regel haben, die jeden Server überprüft, wenn die Abfrage eine Serie pro Server zurückgibt).

Und obwohl ich die komplexe Regelfunktionalität mag, kann dies alles erreicht werden, indem man einen anderen Graphen erstellt und diesen Graphen mit einer einfachen Regel alarmiert.

Nicht sicher, was Sie hier meinen. Ein anderes Diagramm löst das Szenario, in dem Sie bei einer Abfrage im Vergleich zu sich selbst über einen anderen Zeitraum oder vollständig im Vergleich zu einer anderen Abfrage warnen möchten, überhaupt nicht (vielleicht ist die andere Abfrage eine andere Datenquelle, die dynamische Schwellenwerte aus einer Datenbank abruft). Dieses Szenario kann nicht in der TSDB oder durch einfaches Aufteilen der Regel in zwei Regeln in zwei separaten Fenstern gelöst werden.

Aber unser Hauptziel ist es, den einfachen Fall zu lösen und ihn einfach und intuitiv zu machen, aber wir möchten zumindest später auch einige komplexere Alarmierungsregeln unterstützen, die wirklich die Tatsache ausnutzen, dass Sie mit TSDB-Daten und auch der Tatsache zu tun haben dass verschiedene Abfragen auf verschiedene Datenquellen abzielen können

Ich denke, der Punkt von @lorenwest ist, dass

Bei einem komplexeren Alarmierungsmodell gibt es keinen sichtbaren Indikator mehr dafür, wo die Schwellenwerte zu einer Warnung führen würden.

Wenn Sie sich an das einfache Modell halten, können Sie viele der komplexen Überwachungsanforderungen erfüllen, vorausgesetzt, die Datenquelle bietet die Möglichkeit. Für die "prozentuale Änderung im Vergleich zu" könnten Sie eine Graphitabfrage (anderes Diagramm) erstellen, die den aktuellen Tag mit dem vorherigen vergleicht, und dann einfache Schwellenwerte dafür festlegen. Es ist sicherlich viel komplizierter, Warnungen zu erstellen, aber es funktioniert.

Gut, dass wir auf der gleichen Seite sind @torkelo. Das passt zur Beschreibung im Originalbeitrag.

Ich habe keine Lust, eine ganz neue Benachrichtigungsplattform zu schaffen, die an Grafana anknüpft. Was ich mir von der Grafana-Alarmierung erhoffe, ist etwas, das NewRelic ersetzt, aber mit der unglaublichen Kraft, die Grafana mit sich bringt. In der Lage zu sein, eine Warnung auszulösen (egal ob E-Mail, API oder was auch immer), wenn einer meiner Graphen einen Schwellenwert erreicht ... das ist GOLD. Lebensveränderndes Zeug.

Sogar einfache Schwellenwertwarnungen wären eine schöne einfache Lösung.

Wenn Sie diese eine Regel befolgen, sind Sie goldrichtig:

Lassen Sie niemals eine Warnung zu, die nicht durch Überlagern eines Panels angezeigt werden kann.

Wenn Sie es nicht visualisieren können, ist es zu komplex. Erstellen Sie ein Diagramm, das diese Komplexität verkörpert, und alarmieren Sie dieses Diagramm. Dies zwingt uns, Visualisierungen zu erstellen, die diese Komplexität verkörpern (eine gute Sache), während es für den Alert-Builder (und den Verbraucher) leicht zu erkennen ist, worauf er sich einlässt.

@woodsaj Ich stimme zu, dass wir die Verbindung zwischen dem, was Sie alarmieren, und dem, was Sie sehen, fördern möchten. Wir haben noch nie darüber gesprochen, dies aufzugeben. Ein Brainstorming ist, wie weit die statischen Schwellenwerte für einzelne Abfragen gehen, sind sie gut genug für v2 von Grafana Alerting oder v3? Und um eine Diskussion darüber anzuregen, welche Einschränkungen bei der Art von Warnungsregeln mit einzelnen Abfragen und statischen Schwellenwerten möglich sind.

Derzeit sind TSDBs sehr unflexibel, was für verschachtelte Abfragen Sie tun können (vergleichen Sie beispielsweise eine Reihe mit sich selbst). Graphite ist der einzige, der verschachtelte Abfragen unterstützt. Aber selbst Graphite kann nicht zwei Abfragen vergleichen, die auf unterschiedliche Zeitfenster abzielen (Timeshift verschiebt nur dasselbe Fenster, aber nicht unterschiedlich große Zeitfenster). Aber je mehr ich darüber nachdenke, desto mehr stimme ich zu, dass das meiste davon in der TSDB-Abfrage gelöst werden kann, vorausgesetzt, sie ist leistungsfähig genug.

Der Hauptgrund für diese Diskussion ist ein Brainstorming, wie die Regel modelliert werden soll, aus welchen Komponenten eine Regel besteht und welche Abstraktionen sie enthält (Abfrage, Zeitfenster, Aggregation, Ebenen usw.). Wie können wir möglicherweise dynamische Schwellenwerte in v2 oder mehr funktionsreichen Warnungsabfragen unterstützen, die Trends in der Zukunft prognostizieren. Wie müsste sich die Engine zur Modell- und Regelauswertung ändern?

In Bezug auf "Sollte Warnungen zu Panels zugeordnet werden" - Ich denke, dies kann eine nützliche Option sein, wäre jedoch eine schlechte Designeinschränkung, selbst für v1.

Ich denke, einer der kniffligeren Aspekte bei der Alarmierung ist der Umfang, und sobald Sie beginnen, über Visualisierung zu sprechen, wird das Problem offensichtlich.

Ich stelle mir den Umfang als die Fläche/Tiefe eines Systems vor, die eine Warnung als Umfang abdeckt. So können Ihre Benachrichtigungen beispielsweise bereichsbezogen sein:

• Dienste (Anwendungsmetriken)
• Ganze Cluster, die einen Dienst bilden
• Einzelne Knoten in einem Cluster
• Hosts / Prozesse in einem Cluster
• Teilsystem von Prozessen / Anwendungen (Middleware-Metriken)
• Subsysteme von Hosts (dh Festplatte, CPU) (Systemmetriken)

Ich glaube nicht, dass es eine "richtige" Einzelantwort gibt, auf welcher Ebene man warnen sollte. Manchmal hängt es von den Teams, der Bedeutung des Dienstes, der allgemeinen Infrastruktur (dh Cloud vs. Hardware, Cluster vs. Monolith) usw. ab. Bei mehrschichtigen Anwendungsbereichen scheint eine Benachrichtigungshierarchie also gut zu sein. Aber ich glaube nicht, dass die Definition dieser Hierarchien im Allgemeinen aufrechterhalten werden kann. Es ist eine Menge Arbeit, Änderungen, und es gibt oft Beziehungen, die in realen Systemen keine schönen Bäume ergeben. Googles SRE-Buchaggression:

"""
Google SRE hat mit komplexen Abhängigkeitshierarchien nur begrenzten Erfolg gehabt. Wir verwenden selten Regeln wie: "Wenn ich weiß, dass die Datenbank langsam ist, warnen Sie bei einer langsamen Datenbank; andernfalls warnen Sie, wenn die Website im Allgemeinen langsam ist." Abhängigkeitsabhängige Regeln beziehen sich normalerweise auf sehr stabile Teile unseres Systems, wie zum Beispiel unser System zum Ableiten von Benutzerdatenverkehr aus einem Rechenzentrum. "Wenn ein Rechenzentrum leer ist, benachrichtige mich nicht über die Latenzzeit" ist beispielsweise eine gängige Regel für Rechenzentrumswarnungen. Nur wenige Teams bei Google pflegen komplexe Abhängigkeitshierarchien, da unsere Infrastruktur eine stetige Rate kontinuierlicher Refactorings aufweist.
"""

Ebenfalls mit dem Umfang verbunden ist die Art der Benachrichtigung (z. B. eine E-Mail senden oder sie protokollieren / auf dem Dashboard anzeigen, damit sich jemand damit befassen kann, wenn sie ihre Morgenrunden machen).

Für Grafana könnten meine Warnungen also zu folgenden Punkten führen:

• Ein Panel
• Eine Gruppe von Platten
• Ein Dashboard
• Eine Gruppe von Dashboards (von denen ich mir vorstelle, dass sie Drilldowns haben)

Manchmal möchte ich, dass diese Warnungen eine Benachrichtigung senden, manchmal möchte ich, dass sie nur ein visueller Indikator irgendwo in Grafana in einem der Bereiche sind (dh Schwellenwert überschritten oder Zustandsänderungen als Anmerkungsmarkierungen). Es wird für verschiedene Unternehmen und sogar für verschiedene Gruppen/Dienste innerhalb eines Unternehmens unterschiedlich sein.

@kylebrandt die ganze idee bei der warnung in Grafana besteht darin, sie an Panels und Visualisierungen zu binden. Wo Sie Diagramme und Panels haben können, die Metriken mit unterschiedlichem Umfang (wie Dienste, Cluster, einzelne Hosts) visualisieren und damit auf jeder Ebene und jedem Umfang warnen können.

Nicht zu sehen, wie die Verknüpfung einer Warnung mit einem Panel und etwas, das visualisiert werden kann, dazu führt, dass Warnungen auf verschiedenen Ebenen nicht mehr definiert werden. Und natürlich legen Sie pro Alert fest, welche Benachrichtigungen verwendet werden sollen.

@torkelo Die Entscheidung, zu alarmieren, läuft immer auf einen (wahren/falschen) Bool hinaus. Es könnte verschiedene Ebenen (warn, krit, etc...) oder sogar Fuzzy-Logik geben, aber am Ende ist es eine boolesche Entscheidung. Es ist nicht immer hilfreich, diesen Bool allein in einem einzigen Panel grafisch darzustellen.

$metric > $threshold ist also die grundlegendste Warnung, und sie gibt natürlich true zurück, wenn die Metrik den Schwellenwert überschreitet. Das passt gut in ein Panel (visualisieren Sie die Metrik und visualisieren Sie den Schwellenwert innerhalb eines Panels). Aber um Warngeräusche zu eliminieren, neigen der Umfang und die Bedingungen in den meisten Fällen dazu, darüber hinaus zu wachsen (als wir mit der Arbeit an Bosun begannen, dachte ich, dass diese Fälle die Minderheit wären, nicht so sehr, wenn Sie möchten den Lärm kontrollieren). Du könntest also etwas sagen wie:

Benachrichtigen Sie, wenn:

• CPU ist für X Minuten über 80 %
• Job A läuft nicht (wir wissen, dass dies die CPU erhöht, und es ist uns egal) und Job A wird seit mehr als einer Stunde nicht ausgeführt
• Dieter hat in den letzten 24 Stunden mehr als 3 Tassen Starbucks getrunken (denn wenn er mehr hat, macht er dumme Dinge, die die CPU erhöhen und wir wollen nicht darauf aufmerksam machen)

Es ist also nicht so sinnvoll, nur zu visualisieren, dass die Warnung (Wahr / Falsch) ist, wenn mehrere Bedingungen vorliegen. Wir müssen jede Bedingung visualisieren (und dann vielleicht noch mehr für unterstützende Informationen).

Aus all diesen Bedingungen eine neue Metrik zu machen, hilft im Moment bei der Visualisierung nicht wirklich, weil es nur Wahr/Falsch wäre und was Sie wirklich sehen müssen, sind alle zugrunde liegenden Informationen. Was wir also haben, anstatt Metrik + Schwellenwert zu visualisieren, ist die Visualisierung von Metrik(en) + Schwellenwert(en), die auf verschiedenen Skalen liegen können.

In diesem Fall _kann_ ja der Alert einem einzelnen Panel zuordnen, aber je nach Visualisierung und Alert gibt es viele Fälle, in denen das nicht wirklich das ist, was man möchte. Ich möchte ein Panel für jedes der booleschen Elemente, aus denen die Warnung besteht, um zu sehen, welche davon ausgelöst wurden - aber um Warnungsmüdigkeit zu vermeiden, möchte ich nur eine Benachrichtigung für die Kombination aller Bedingungen.

Es scheint, dass eine Art Alarm-Joiner mit einfacher boolescher Logik dies einfach machen könnte.

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

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

@torkelo Ich ziehe den Alerting_definitions-Zweig von Github und
Außerdem habe ich "alerting: enabled=false" in den "Servereinstellungen" der "Serveradministration" gefunden. Beeinflusst das die Benachrichtigungsfunktion? Gibt es ein Build- oder Laufzeit-Flag, das ich verwenden sollte?
bitte beraten.

Ich hatte einen Versuch mit dem neuesten Code (ebada26b85d8410142c2942ef7ba78b17e88313c), aktivierte Benachrichtigungen und bekam eine Benutzeroberfläche.

Aber ich habe Tonnen von Fehlern

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

Ich habe es mit InfluxDB-Datenquellen im Proyy- und Direktmodus versucht.

Ist es etwas zu erwarten?

Ja, es ist noch nicht bereit zum Testen.

Ok, gut zu wissen.

Ich werde von Zeit zu Zeit Updates verfolgen.
Ist es vielleicht besser zu warten , bis dieser Zweig im Master zusammengeführt wird , also ganz einsatzbereit ?

Ja, wir hoffen, es etwa Mitte Juli zum Master zusammenführen zu können

Hast du dazu ein Fortschrittsupdate?
Schlagen Sie noch Mitte Juli?
Diese Funktion so schnell wie möglich in Produktion zu haben, wäre wirklich eine große Hilfe!

Sogar eine Light-Version mit nur Benachrichtigungen wie E-Mail wäre so toll!
Ein Update zu Ihrem Fortschritt wäre großartig (ich muss mich entscheiden, ob ich ein benutzerdefiniertes Warnsystem implementiere oder mich auf Grafana verlasse, und ich bevorzuge definitiv die zweite Option!).
Danke Jungs

Der Winter ist gekommen, also wird die Warnung sein :)

Am Dienstag, den 12. Juli 2016 um 01:41 Uhr schrieb c-val [email protected] :

Sogar eine Light-Version mit nur Benachrichtigungen wie E-Mail wäre so toll!
Ein Update zu eurem Fortschritt wäre toll (ich muss mich entscheiden zwischen
ein benutzerdefiniertes Warnsystem implementieren oder sich auf Grafana verlassen, und ich auf jeden Fall
2. Option bevorzugen!).
Danke Jungs

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

Deepak

Ich würde dies als "Geschäftsanforderung" betrachten und empfehlen, dies auf der Ebene der "Unternehmensarchitektur" zu bewerten. Durch die Anwendung von _einigen_ der Praktiken und Muster, die für die Enterprise Software Architecture verwendet werden, können Sie Ihre Ideen durch agile Modellierung kommunizieren, was wiederum eine höhere Qualität des Verständnisses sowohl für die Stakeholder als auch für das Entwicklungsteam fördert.

Bevor wir anfangen können, über Technologie und Architektur zu sprechen, müssen wir uns zumindest auf Folgendes einigen:

1. Wir verstehen unsere Funktionen im Sinne von "Business Process Management (BPM)"; und
2. Wir verwenden die "Business Process Modeling Language (BPML)", damit wir mit der Modellierung der Anforderungen und Implementierungen an derselben Stelle mit UML beginnen können.
3. Wir definieren unsere Architektur mit einer Disziplin auf Unternehmensebene.

Jetzt der lustige Teil! Da ich umfangreiche Erfahrung mit der Überwachung auf globaler Ebene habe, empfehle ich, Folgendes zu berücksichtigen:

• Lassen Sie Grafana in Ruhe, es ist die Präsentationsschicht ! Wenn Sie einen Workflow zum Modellieren und Definieren von Regeln zum Generieren von Warnungen hinzufügen möchten, ist das in Ordnung, aber belassen Sie es dabei. Schließlich wurden die Panels und Plugins deshalb richtig implementiert?
• Lassen Sie die Daten dort, wo sie sein sollen. Die Metriken, die nach Hause gerufen werden, sollten als Bürger erster Klasse behandelt werden und ihre Werte dauerhaft zu speichern hat oberste Priorität. Ob es sich um einen Cache, eine documentdb, eine tsdb oder einen SQL-Server handelt, spielt keine Rolle. Fehlertoleranz wird vorausgesetzt. Natürlich wird die richtige "Technologieauswahl" für die Architektur getroffen).
• Um uns auf Verfügbarkeit + Skalierbarkeit einzustellen, müssen wir die richtigen Frameworks verwenden, die speziell dafür entwickelt wurden: die serviceorientierte Architektur ("SOA") erfüllen. Auf einer sehr hohen Ebene können wir das Nachrichtenwarteschlangenprotokoll verwenden, um Ereignisse und Nachrichten über das "AMQP"-Protokoll zu senden und zu empfangen. Vergiss REST & HTTP... vorerst. Mit einem Message Queue-Server wie RabbitMQ oder ZeroMQ haben wir eine verteilte, fehlertolerante, hochverfügbare Kommunikationspipeline, die sowohl Verleger/Sender von Daten als auch Arbeiter/Empfänger zur Verarbeitung nutzen können. Dies ist der "Enterprise Service Bus". (Schauen Sie sich dieses Foliendeck an , das ZeroMQ erklärt).
• Verwenden Sie eine Abfragesprache, die speziell für unterschiedliche, nicht verknüpfte, zusammengesetzte Datenmodelle erstellt wurde. Durch Verwendung einer „Graph Database“ und der „ SparQL “

SPARQL ermöglicht es Benutzern, Abfragen gegen Daten zu schreiben, die man grob "Schlüsselwert"-Daten nennen kann, oder genauer gesagt auf Daten, die der RDF-Spezifikation des W3C folgen. Die gesamte Datenbank ist somit eine Menge von "Subjekt-Prädikat-Objekt"-Tripeln. Dies ist analog zu der Verwendung des Begriffs "Dokument-Schlüssel-Wert" in einigen NoSQL-Datenbanken, wie beispielsweise MongoDB.
[..]
SPARQL bietet somit einen vollständigen Satz analytischer Abfrageoperationen wie JOIN, SORT, AGGREGATE für Daten, deren Schema intrinsisch Teil der Daten ist, anstatt eine separate Schemadefinition zu erfordern. Schemainformationen (die Ontologie) werden jedoch oft extern bereitgestellt, um eine eindeutige Verknüpfung verschiedener Datensätze zu ermöglichen. Darüber hinaus bietet SPARQL eine spezifische Graph-Traversal-Syntax für Daten, die man sich als Graph und Abb. vorstellen kann.
..
https://en.wikipedia.org/wiki/SPARQL

Denken Sie daran, was Grafana uns gegeben hat, was Nagios nie getan hat, läuft auf einen einzigen Fehler hinaus: mangelnde Skalierbarkeit. Grafana ist "schnell", wie Sie sagen, aber Sie berücksichtigen nicht die Tatsache, dass Sie nur Zeitreihendaten speichern und verarbeiten - nicht auch die Metadatenschicht(en) ! Wir brauchen die Semantik von SparQL und die Leistungsfähigkeit von Elasticache + Graphing-Datenbank-Engine(s).

Es mag komplex klingen .. was es leicht viel komplexer werden kann als diese beiden Seiten, aber ich habe Sie vor Jahren roher Gewalt, Versuch und Irrtum bewahrt und den Lärm aussortiert (dh: es gibt 30 Entwurfsmuster für Unternehmensarchitektur, 12 für uml usw., wir müssen nur über 3 sprechen, um das auszuschalten - für den Moment)

Dies sollte die Gänge zum Laufen bringen.. Ich brauche etwas Schlaf (die ganze Nacht durchgezogen) und ich werde an Teil 2 arbeiten. Fühlen Sie sich frei, mich @appsoa auf Skype oder yomateo auf IRC anzupingen.

Einige Leckereien in der Zwischenzeit:

• Eine Beispiel-Referenzarchitektur, die ich mit SOA erstellt habe .
• Microsoft Azure Service Fabric: Erstellen und betreiben Sie permanent verfügbare, skalierbare, verteilte Anwendungen.

@talbaror Im Idealfall würden Sie die Protokollnachrichten des NAC mit einem Agenten wie bei einer PIX-Firewall erfassen und sie einfach über rsyslogd oder ein beliebiges Protokoll, das der Ereignisverarbeitungsserver verwendet, versenden/wiedergeben lassen.

Wenn Sie keinen Ereignisverarbeitungsdienst eingerichtet haben, können Sie die Regelverarbeitung von Snort-Network Intrusion Detector verwenden . Ping mich an, wenn du Hilfe brauchst .. Ich habe 4 Jahre bei einer Security-as-a-Service-Firma verbracht ;)

Können Sie Anomalie-Erkennung wie Banshee integrieren ?
Mit visuellen Markierungen und Warnungen.

@torkelo bitte geben Sie uns eine Mark-to-Market auf der Zeitleiste für den Versand an?

@johnnyshields Daran arbeite ich jetzt jeden Tag. Es ist eine knifflige Sache und ich möchte wirklich die Grundlagen richtig machen, damit sich das Warnsystem weiterentwickeln und in Zukunft noch reichhaltiger werden kann. Das aktuelle Modell, mit dem ich arbeite, sieht wirklich gut aus und wird nächste Woche ein Update zum neuen bedingungsbasierten Alert-Regelmodell veröffentlichen.

Ich hoffe, es innerhalb von 2 Wochen mit dem Master zusammenzuführen und verfügbar zu machen (hinter der Funktionsumschaltung), wenn die Dinge reibungslos verlaufen. Wir haben noch kein festes Datum für die nächste Version von Grafana, entweder eine 3.2-Version im September oder eine größere 4.0-Version Ende Oktober.

@torkelo Ich hoffe, wir erhalten die
Verwenden von Grafana für Kubernetes.

Für andere Leute, die bereits statsd/graphite/grafana installiert haben und nur darauf warten, dass das Grafana Alerting System bereit ist, die ersten Warnungen durchzuführen, habe ich in der Zwischenzeit eine großartige Alternative gefunden, Seyren: https://github.com /scobal/seyren

Es lässt sich leicht in PagerDuty integrieren und Sie können einfach die Diagrammziele kopieren, die Sie bereits in Ihren grafana-Dashboards haben, um Warnungen zu erstellen und die Warn- und Fehlerschwellenwerte anzugeben.

Anscheinend hat das Team große Fortschritte bei der Benachrichtigungsfunktion gemacht. Ich glaube an die Philosophie "nur eine Sache tun, aber gut machen". Ich bin mir nicht ganz sicher, ob es die beste Idee ist, die gesamte Alarmierungslogik in Grafana zu integrieren. Wie auch immer, ich habe gerade einen kleinen js-Knoten-Daemon "flapjack-grafana-receiver" geschrieben, um Grafana-Ereignisse an Flapjack zu senden. Ich werde es wahrscheinlich als Open Source verwenden. Hat jemand Interesse?

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

Fortschrittsbericht!

Mindestens eine Person arbeitet seit April Vollzeit an der Alarmierung, die Fortschritte waren aufgrund vieler Umschreibungen nicht so schnell, wie wir es uns gewünscht hätten. Auch wenn wir für die erste Version grundlegende Benachrichtigungsfunktionen anstreben, halten wir es für wichtig, das grundlegende Benachrichtigungsregelmodell richtig zu machen, damit wir die Benachrichtigungsregeldefinition und die Benachrichtigungsregelauswertungs-Engine in zukünftigen Versionen ohne größere Überarbeitung erweitern können.

Das Ziel, mit einer sehr einfachen Alarmierung zu beginnen, hat uns in einige Sackgassen gebracht, die sich nicht richtig anfühlten und einige große Umschreibungen erforderten. Aber wir sind jetzt wieder auf dem richtigen Weg und machen gute Fortschritte bei einem bedingungsbasierten Regelmodell, mit dem wir viel zufriedener sind.

Regeldefinition

Das neue Warnungsregelmodell besteht aus einer oder mehreren Bedingungen. Bedingungen können unterschiedlicher Art sein. Im Moment gibt es nur einen Abfragetyp. Aber wir können später Bedingungen wie Time of day oder Day of week oder interessanter Other alert hinzufügen (damit Sie den Status einer anderen Warnungsregel als Bedingung einschließen können).

Die Abfragebedingung besteht aus einer Abfrage und einem Zeitbereich, einem Reduzierer, der alle Datenpunkte, die für jede von der Abfrage zurückgegebene Serie zurückgegeben werden, auf einen einzigen Wert reduziert, der im Schwellenwertvergleich verwendet wird. Der Reduzierer könnte in Zukunft auch eine "Prognose" sein, die eine lineare Regression der Daten durchführt und einen zukünftigen Wert prognostiziert.

Der Bewertungsteil der Abfragebedingung kann entweder größer als, kleiner als, zwischen usw. sein. Sie können Griffe im Diagramm ziehen, um Schwellenwerte festzulegen.

Das bedingungsbasierte Modell bietet viele spannende Möglichkeiten, um Alert-Regeln in Zukunft ohne eine komplette Überholung der Engine leistungsfähiger zu machen, auch die Abfragebedingung verfügt über diese steckbaren Komponenten, die eine Erweiterung ermöglichen (Reducer mit Parametern und Evaluator mit Parametern).

Benachrichtigungen

In dieser vergangenen Woche haben wir an Benachrichtigungen gearbeitet und die Dinge beginnen sich zu vereinen!

Wir haben E-Mail-, Webhook- und Slack-Benachrichtigungstypen. Die Slack-Benachrichtigung sieht ziemlich gut aus :)

Helfen wollen?

Sie können bereits testen und Feedback geben, der Code lebt im Alerting-Zweig, und Sie müssen ihn auch in der Konfigurationsdatei mit aktivieren.

[alerting]
enabled = true

Zusammenführen zum Master

Wir stehen kurz davor, dies zu meistern und die Arbeit dort fortzusetzen. Ich hatte gehofft, dies vor meinen Sommerferien zu tun (gerade 1 Woche weg), aber es gibt immer noch einige kleinere Änderungen am SQL-Schema, die ich vor dem Zusammenführen mit Master vornehmen möchte. Merge to master WIRD am 19. August stattfinden, versprochen :) Danach wird die Benachrichtigung in der neuesten 4.0 Nightly Build sein, so dass es für Sie einfach sein wird, Fehler und Feedback zu testen und zu melden.

Was übrigbleibt?

Es gibt eine Reihe von Funktionen, die fehlen, die wir für eine Beta-Version wünschen.

• Mehr Reduzierstücke und Möglichkeit zum Wechseln des Reduzierstücks (jetzt nur durchschnittlich)
• E-Mail-Benachrichtigung sieht scheiße aus
• Sperrschema für Webhook
• Design für Warnungslistenseite
• Benachrichtigungsverlauf anzeigen
• Benachrichtigungsverlauf als Anmerkungen im Diagramm anzeigen
• Alarmplaner und Motorstabilität
• Verbesserungen des Alert-Schedulers, um die Last zu verteilen (damit Alerts nicht gleichzeitig ausgeführt werden)
• Clustering des Benachrichtigungsplaners

Es tut mir wirklich leid, dass diese Funktion so lange dauert.

@torkelo bitte haben Sie die Möglichkeit, Maschinen für einen bestimmten Zeitraum in der Beta in den Wartungsmodus zu versetzen.

@torkelo Danke für das Update. Soweit ich sehen kann, ist dies darauf ausgerichtet, Alarmierung innerhalb von Grafana zu haben. Folgen Sie immer noch dem modularen Kurs in https://github.com/grafana/grafana/issues/2209#issuecomment -149351263 ?

Auch vielen Dank an die versteckten Elfen, die daran arbeiten. Ich vermute @Dieterbe , aber ich weiß es nicht.

@RichiH wir sind uns nicht sicher, wie das funktionieren wird, wir haben versucht herauszufinden, wie man ein System wie in diesem Kommentar macht, aber nicht sicher, wie es funktionieren wird. Wir konzentrieren uns jetzt auf ein starkes Out-of-the-Box-Alarmierungserlebnis, das mit der Zeit besser werden kann. Benutzer mit vorhandenem Alerting-Handler könnten möglicherweise den Alerting Executor in Grafana deaktivieren und Grafana veranlassen, den Alert, der ausgewertet werden muss, an ein anderes System zu senden. Es würde jedoch viel Arbeit an Drittsystemen erfordern, um diese Integration zu implementieren.

@torkelo Meine Gedanken waren in die gleiche Richtung, weshalb ich mich entschieden habe zu fragen.

Persönlich interessiere ich mich für die Alarmierung von Prometheus, würde mich aber über eine schöne visuelle Integration mit Grafana freuen. Es ist mir egal, wo ich Regeln definiere, solange sie von Prometheus gespeichert und ausgeführt werden.

@bergquist Da Sie auf der promcon sein werden, kann es sinnvoll sein, sich hinzusetzen und über mögliche Ansätze zu sprechen. Wenn Sie möchten, werde ich die Prometheus-Entwickler fragen, welche Zeit am besten passt. Es kann sein, dass es am Abend vor und/oder nach dem Aufräumen etwas Ruhe gibt, um sich hinzusetzen. Ich kann Sie wissen lassen, wenn Sie möchten.

Hallo @torkelo - das sieht toll aus.

Ich habe gerade Ihren Zweig gezogen und wenn ich einen Alarm für ElasticSearch teste, erhalte ich die Fehlermeldung

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

...bedeutet dies, dass ElasticSearch noch nicht unterstützt wird :cry:

ps in der Prozessausgabe bekomme ich dies:

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

@Workshop2 wir unterstützen bisher nur Graphit für Benachrichtigungen, aber wir werden Elasticsearch irgendwann unterstützen :) Ich werde dafür eine bessere Fehlermeldung hinzufügen.

Wie verhält sich das Warnsystem, wenn die Abfrage keine Daten zurückgibt? Wird es standardmäßig eine Warnung auslösen?
Auch ein einfacher count Reducer wäre cool, der einfach die Anzahl der Datenpunkte zurückgibt, die von einer Abfrage zurückgegeben werden.

@bergquist Ich dachte, dass die

@RichiH Eine Möglichkeit besteht darin, eine Grafana-App wie bosun zu erstellen. https://grafana.net/plugins/bosun-app Das ermöglicht jedoch keine einfache Wiederverwendung von Abfragen / Dashboards. Lassen Sie uns mehr darüber bei promcon sprechen. Freue mich auf ein treffen mit dir! :)

Kein influxdb-Support anfangs auch?

Ich wusste nicht, dass es spezifisch an Graphit gebunden ist :( Wir verwenden auch Zufluss und
elastische Suche ;)

Am Montag, 8. August 2016 um 14:18 Uhr schrieb elvarb [email protected] :

Kein influxdb-Support anfangs auch?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
.

Enrico Kern

Leitender Systemingenieur

glispa GmbH
Sonnenburger Straße 73
10437 Berlin, Deutschland

Tel: +49 30 5557130-17
Fax: +49 30 5557130-50
skype: flyersaenrico. [email protected]

---

Sitz Berlin, AG Charlottenburg HRB 114678B

Nur zu Beginn werden wir Prometheus wahrscheinlich vor der Veröffentlichung hinzufügen. Vielleicht auch InfluxDB oder Elasticsearch, da die Alarmplanung und -ausführung im Backend stattfindet, wurde der Anfrage- und Antwortcode von Grund auf neu geschrieben (in Go), der Frontend-Datenquellen-Plugin-Code (in js geschrieben) kann nicht wiederverwendet werden.

Wir verwenden Influx, ich denke, wir können auf die Grafana-Integration verzichten und Kapacitor mit einem einfachen Web-Frontend zum Erstellen und Verwalten von Warnungen verwenden.

+1 Warnung + InfluxDB.

Am Montag, 8. August 2016 um 06:01 Uhr, Thom Nichols [email protected]
schrieb:

Wir verwenden Influx, ich denke, wir können auf die Grafana-Integration verzichten und verwenden
Kapacitor mit einem einfachen Web-Frontend zum Erstellen und Verwalten von Warnungen.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
.

Deepak

Es ist bedauerlich, dass die Arbeit, die wir in die Erstellung von Datenquellen-Plugins stecken, nur auf dem Client nützlich ist.

In Anbetracht der unmittelbaren und langfristigen Arbeit zur Unterstützung von Benachrichtigungen für verschiedene Datenquellen, dem Aufbau einer Go-Plugin-Architektur usw. wäre es nicht fast der gleiche Arbeitsaufwand (wenn nicht weniger), den Benachrichtigungsserver in NodeJS zu erstellen, sodass er vorhandene verwenden könnte Datenquellen-Plugins?

Abgesehen von den Meinungen zu go vs. nodejs könnte dies die Codeduplizierung für Benachrichtigungen bei verschiedenen Datenquellen erheblich reduzieren.

Und wenn Sie Node wirklich nicht mögen, wette ich, dass es in go einen Callout-Mechanismus zum Laden und Ausführen von JS gibt.

+1-Benachrichtigung für ElasticSearch

Hallo, wir haben auf das Alarmierungssystem gewartet für... OpenTSDB! Können wir
hoffen, es bald für OpenTSDB zu bekommen? (Vielleicht wann?)

Vielen Dank an das Team!

2016-08-08 17:28 GMT+02:00 Slava Vishnyakov [email protected] :

+1-Benachrichtigung für ElasticSearch

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
.

+1-Benachrichtigung für ElasticSearch
Hätte es die Möglichkeit, bei Alarm ein Skript auszuführen?

Habt ihr schon den Alerting Branch in einem Docker Image?

1. Funktionieren Warnungsabfragen nur für Abfrage "A"? Ist das hartcodiert?
2. Wann können wir mit einer voll funktionsfähigen Alerting-Version rechnen? (19. noch das Ziel)
3. Wann können wir davon ausgehen, dass Elasticsearch mit Benachrichtigungen funktioniert?

Bearbeiten:

1. Kann ich mehr als eine Alarmregel pro Diagramm hinzufügen?
2. Kann ich der HTTP-Nachricht Informationen über den Alarm hinzufügen? (dashboard/graph/observed_query/alarm_config/alarm_query/threshold/warn_or_crit/value/observed_timeframe/time_of_occurence)

@DEvil0000

1) Sie können zu jeder Abfrage wechseln, die Sie auf der Registerkarte "Metriken" haben.
2) Voll funktionsfähig, hängt davon ab, was Sie meinen. Wir planen, es diese Woche zusammenzuführen, um es zu meistern. Dann können die Leute mit dem Testen des nächtlichen Builds beginnen und Feedback geben. Alpha Release innerhalb von 2-3 Wochen, Beta & Stable Release hängt vom Feedback ab und wie schnell es stabil werden kann
3) Elasticsearch ist knifflig, erfordert viel Code zum Abfragen und Analysieren von Antworten in Zeitreihen, wird also wahrscheinlich kommen, nachdem die Unterstützung für Prometheus und InfluxDB hinzugefügt wurde

@torkelo
Ich bin neu bei Elasticsearch, Grafana und Go Lang. Und ich glaube, Sie haben bereits nach Kunden gesucht, aber haben Sie diese gesehen?
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
Diese Bibliotheken könnten den Aufwand reduzieren.

Auch vielen Dank an die versteckten Elfen, die daran arbeiten. Ich vermute @Dieterbe , aber ich weiß es nicht.

Alerting ist jetzt hauptsächlich @torkelo und @bergquist (und @mattttt ). Ich habe den Fokus auf unser kommendes Graphit-Backend verlagert, https://github.com/raintank/metrictank

Ich freue mich sehr, dass diese Funktion Fortschritte macht. Würde gerne Unterstützung für OpenTSDB haben, da andere Alarmierungslösungen (Bosun) für den regelmäßigen Einsatz hier nicht benutzerfreundlich genug wären.

Ich hoffe, den Alarm in der nächsten offiziellen Version zu sehen und zolle den Programmierern Tribut, die hart am Code gearbeitet haben.

Ich hoffe, den Alarm in der nächsten offiziellen Version zu sehen und zolle den Programmierern Tribut, die hart am Code gearbeitet haben.

@superbool tut

Merge to master WIRD bis zum 19. August passieren, versprochen :)

@torkelo hehe, wenn ich das nächste Mal wette. Gibt es ein neues Datum?

Können wir erwarten, dass die Benachrichtigungen für OpenTSDB geplant sind?
(bescheidene) Gründung zur Förderung von dev.

2016-08-22 10:05 GMT+02:00 A. Binzxxxxxx [email protected] :

Ich hoffe, den Alarm in der nächsten offiziellen Version zu sehen und zolle den Programmierern Tribut, die hart am Code gearbeitet haben.

@superbool https://github.com/superbool sorry kann das nicht lesen und
Google-Übersetzung war nicht sehr hilfreich

Merge to master WIRD bis zum 19. August passieren, versprochen :)

@torkelo https://github.com/torkelo hehe, wenn ich das nächste Mal wette
neues Datum?

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment -241340597,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
.

@DEvil0000 Ich hoffe, dass die
Entschuldigung, mein Englisch ist nicht sehr gut, ich hoffe du verstehst meine Worte

@DEvil0000 Der Plan war, letzten Freitag zusammenzuführen, aber aufgrund einiger ungeplanter Ereignisse ( https://twitter.com/torkelo/status/766514688997732352 ) mussten wir es etwas verschieben :) Wir haben noch einige Kleinigkeiten zu erledigen.

@torkelo Herzlichen Glückwunsch!
@bergquist @torkelo Ich muss vor Oktober mit

Der Alerting-Zweig wurde jetzt mit dem Master zusammengeführt. :raised_hands:

Wir freuen uns über alle Rückmeldungen, die wir zu dieser Ausgabe erhalten haben. Danke an euch alle !
Für zukünftige Diskussionen und Feedback posten Sie bitte im entsprechenden Benachrichtigungsproblem oder erstellen Sie ein neues. Dies hilft uns, unsere zukünftige Arbeit zu organisieren und zu priorisieren. Ich schließe dieses Ticket zugunsten der neuen. Aber zögern Sie nicht, die Diskussion in dieser Ausgabe fortzusetzen.

Was kommt als nächstes?

• Alpha-Release (Dokumente und Blogpost)
• Sammeln Sie Feedback aus der Community.
• Arbeiten Sie weiter an den verbleibenden Problemen für die Benachrichtigung
• Geben Sie Grafana 4.0 mit Benachrichtigungen frei.

Versuch es?

• In der Konfiguration muss die
• Benachrichtigungen finden Sie jetzt im Seitenmenü.
• Sie können eine Warnung hinzufügen, indem Sie zu einem Diagrammbereich gehen und die Registerkarte Warnung auswählen.
• Verwenden Sie die Schaltfläche _Alarm testen_, um Ihre Warnung zu überprüfen.
• Um die Warnung zu speichern, müssen Sie nur das Dashboard speichern.
• Richten Sie die Benachrichtigung in /alerting/notifications ein, um über das Auslösen von Warnungen benachrichtigt zu werden.
• Fügen Sie den Notifier auf der Registerkarte Warnung zu einer Warnung hinzu.

Aktuelle Einschränkungen

• Bisher unterstützen wir nur Graphit.
• In dieser Version unterstützt nur das Diagrammfenster Benachrichtigungen.

Beispiel-Dashboards

Beispiel-Dashboards finden Sie im Beispielordner.
Die Beispiel-Dashboards basieren auf den Daten unseres gefälschten Graphit-Datenschreibers. Graphit und den Fake-Data-Writer können Sie aus unseren Docker-Compose-Dateien starten.

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

Dies sollte nur als grober Anhaltspunkt betrachtet werden und wir werden in den nächsten Wochen weitere Dokumentationen zum Alerting hinzufügen.

Viel Spaß beim Alarmieren! :cocktail: :tada:

@bergquist Herzlichen Glückwunsch.

Gibt es ein Problem, das wir bezüglich der Zukunft dieser Funktion verfolgen können?

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

Es gibt nur ein "UND" und kein "ODER" in den Warnungsbedingungen, um "ist oben" ODER "ist unten" in einem Panel hinzuzufügen oder gibt es eine andere Möglichkeit, dies zu unterstützen?

Ich denke, es gibt eine Option "ist außerhalb der Reichweite" / "ist in Reichweite". Ich würde aber auch gerne ein "oder" sehen.

Hallo alle! Vielen Dank für Ihren Beitrag zu dieser nützlichen Funktionalität.

Es ist wirklich interessant für mich, aber in vielen Fällen bräuchte ich ein "ODER" in den Alert-Bedingungen, da es keine Möglichkeit gibt, mehr als einen Alert in einem gragh zu erstellen.

Ich denke, dass ich ohne dieses "ODER" keine Warnungen für diese Art von Diagrammen erstellen kann:

Irgendeine Idee? Planen Sie, eine "ODER"-Option hinzuzufügen?

BR

@jmgonzalezp ja, wir hoffen, auch OR unterstützen zu können (noch nicht sicher über das Mischen von AND und OR)

Wir haben noch 2 verbleibende Designentscheidungen für Benachrichtigungen, zu denen wir uns über Feedback freuen würden (Kategorisierung und Schweregrad/Status).

Hier ist das Problem mit unseren aktuellen Gedanken und wir würden uns sehr über Ihr Feedback freuen.
https://github.com/grafana/grafana/issues/6007

Hallo zusammen! Danke für diese großartige Funktion in grafana!

Ich habe eine Frage zu diesem Warnsystem. Derzeit verwenden wir die Auto Scaling-Gruppe in AWS für die Bereitstellung von Grafana. Wäre das ein Problem, wenn ich Grafana auf mehreren Computern ausführe? Das Problem, auf das ich mich beziehe, ist, würde es mehrere gleiche Warnungen von mehreren Grafana-Maschinen geben? Oder hat grafana das schon gemeistert?

@torkelo Ich habe die gleiche Frage wie @akurniawan. Betrachten wir dieses Setup: 1 Load Balancer, 3 Grafana-Instanzen hinter dem Load Balancer, 1 MySQL DB, die sich alle 3 Instanzen teilen. Wie gehen Grafana-Server mit Warnungen bei dieser Art von Einrichtung um? Sollten wir die Benachrichtigungen dann nur für eine Instanz aktivieren oder Grafana verfolgt die Benachrichtigungen, damit nicht mehrere Knoten dieselben Benachrichtigungen überprüfen und senden?

@utkarshcmu @akurniawan Alerting innerhalb von Grafana unterstützt HA noch nicht. Unser Plan ist es, in Zukunft Partitionswarnungen zwischen Servern zu unterstützen.

@bergquist Danke für die Antwort. :)

@bergquist Gibt es eine ETA, wann die InfluxDB-Unterstützung dafür hinzugefügt wird?

@thisisjaid nach diesem https://github.com/grafana/grafana/milestone/40 sollte es am 10. hier sein.

@Dieterbe Irgendeine ETA, um den Support für OpenTSDB zu benachrichtigen?

@sofixa Danke, hätte mir die Roadmap selbst

@Dieterbe Irgendeine ETA, um den Support für OpenTSDB zu benachrichtigen?

Ich arbeite nicht mehr an der Benachrichtigung. vielleicht können @torkelo oder @bergquist antworten.

@torkelo @bergquist

Beliebige ETA für Benachrichtigungen zur Unterstützung von OpenTSDB

@LoaderMick @naveen-tirupattur OpenTSDB-Alarmierung wird Grafana hinzugefügt, sollte Teil der nächsten Version sein. Außerdem funktioniert das Alerting für OpenTSDB in den Nightly-Builds.

Gibt es eine ETA, um auch den Support für influxDB und prometheus zu benachrichtigen?

@nnsaln-Warnungen für beide Datenquellen befinden sich bereits im Master-Branch.

Ich kann anscheinend nicht die Benachrichtigungen mit OpenTSDB mit (Grafana v4.0.0-pre1 (commit: 578507a)) zum Laufen bringen. Ich habe das E-Mail-System getestet (funktioniert), aber die Warnungen werden einfach nicht ausgelöst, selbst wenn ich einen sehr niedrigen Schwellenwert habe. Gibt es irgendwie, die Abfragen manuell auszuführen und die Daten zu sehen, die es zieht?

Grafana v4.0.0-pre1 (commit: 9b28bf2)
error tsdb.HandleRequest() error Influxdb hat Statuscode zurückgegeben ungültiger Statuscode: 400 Bad Request

@torkelo
Kann die 'Webhook Alert Notification' die Alert-Metrik, JSON oder den Formulartyp posten?

Hallo Leute, wird Grafana Benachrichtigungen für Abfragen mit Vorlagenvariablen unterstützen oder gibt es dafür eine Zielversion?

Alle, bitte versuchen Sie es mit der Betaversion von 4.0; Wenn etwas fehlt, öffnen Sie neue Themen.

Richard

Per Handy gesendet; entschuldige meine Kürze.

Ich habe 4.0 Beta ausprobiert, aber ich habe immer noch diesen Fehler
error tsdb.HandleRequest() error Influxdb hat Statuscode zurückgegeben ungültiger Statuscode: 400 Bad Request

Ich kann keine Warnungsbenachrichtigungen speichern - senden an, nachdem ich gespeichert habe, wird die Zeile "Senden an" wieder leer

@nnsaln Sie sollten dort das Benachrichtigungsziel ausfüllen, nicht die E-Mail-Adresse. Öffnen Sie das grafana-Seitenmenü und bewegen Sie den Mauszeiger über die Menüoption Benachrichtigungen, und klicken Sie dann auf die Menüoptionen für Benachrichtigungen. Dort können Sie ein Benachrichtigungsziel einrichten, das Sie aus Ihren Benachrichtigungsregeln verwenden können.

Gibt es einen Plan, Vorlagenvariablen zusammen mit Warnungen zu unterstützen? Das tue ich
verstehen, dass jeder Graph, der von einer (oder gesetzten) Vorlagenvariable erzeugt wird, entspricht
auf einen anderen Graphen und damit das Generieren einer Warnung gegen einen statischen Wert ist
nicht richtig.

Am Mo, 5. Dezember 2016 um 2:06 AM, Tomas Barton [email protected]
schrieb:

@nnsaln https://github.com/nnsaln Du sollst die Benachrichtigung ausfüllen
Ziel dort, nicht E-Mail-Adresse. Öffne das Grafana-Seitenmenü und fahre mit der Maus darüber
die Menüoption Benachrichtigungen und dann die Menüoptionen Benachrichtigungen. Dort
Sie können ein Benachrichtigungsziel einrichten, das Sie aus Ihren Warnungsregeln verwenden können.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
.

--
Deepak

Nein, dazu gibt es derzeit keinen Support. Vielleicht in ferner Zukunft, aber

99% der Dashboards verwenden Vorlagenvariablen. Sie wurden mit Vorlage entworfen
Variablen, um das Problem der "Dashboard-Explosion" zu vermeiden.

Am Mo, 5. Dezember 2016 um 20:20 Uhr, Torkel Ödegaard [email protected]
schrieb:

Nein, dazu gibt es derzeit keinen Support. Vielleicht in ferner Zukunft, aber

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
.

--
Deepak

Ja, aber ein generisches Explorations-Dashboard ist nicht dasselbe wie ein Dashboard-Design für Warnungsregeln.

Bisher gab es keinen Vorschlag, wie Vorlagenvariablen auf intuitive / verständliche Weise unterstützt werden können. Was sollte eine Warnungsabfrage mit einer Variablen tun? Mit dem aktuell gespeicherten Variablenwert interpolieren, mit allen? Sollte es jeden Wert als separate Regel behandeln und den Zustand für jeden beibehalten usw. Die Unterstützung von Vorlagenvariablen eröffnet eine Menge Würmer für Komplexität und potenziell verwirrendes Verhalten. könnte eines Tages hinzugefügt werden, wenn jemand einen einfachen und verständlichen Weg findet.

In der Zwischenzeit hindert Sie nichts daran, separate Alert-Dashboards zu erstellen.
Alerting ist neu und eine große Bereicherung für grafana. Es wird sich im Laufe der Zeit entwickeln,
Aber in der kurzen Zeit, in der es implementiert wurde, hat es grafana einen enormen Mehrwert gegeben,
und danke allen Mitwirkenden dafür!

Am 06.12.2016 11:14 nachm. schrieb "Torkel Ödegaard" <
[email protected]>:

Ja, aber ein generisches Explorations-Dashboard ist nicht dasselbe wie ein Dashboard
Design für Alert-Regeln.

Bisher gab es keinen Vorschlag zur Unterstützung von Vorlagenvariablen
intuitiv / verständlich. Was sollte eine Warnungsabfrage mit einer Variablen sein?
tun? Mit dem aktuell gespeicherten Variablenwert interpolieren, mit allen? Sollte es
Behandeln Sie jeden Wert als separate Regel und behalten Sie den Status für alle usw. bei. Unterstützend
Template-Variablen öffnen eine Dose voller Würmer für Komplexität und potenziell
verwirrendes Verhalten. könnte eines Tages hinzugefügt werden, wenn jemand eine Idee hat
einfache und verständliche Weise.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
.

+1 Torkel.

Es macht die Alarmierung ziemlich kompliziert.

Am Di., 6. Dezember 2016 um 14:14 Uhr, Torkel Ödegaard [email protected]
schrieb:

Ja, aber ein generisches Explorations-Dashboard ist nicht dasselbe wie ein Dashboard
Design für Alert-Regeln.

Bisher gab es keinen Vorschlag zur Unterstützung von Vorlagenvariablen
intuitiv / verständlich. Was sollte eine Warnungsabfrage mit einer Variablen sein?
tun? Mit dem aktuell gespeicherten Variablenwert interpolieren, mit allen? Sollte es
Behandeln Sie jeden Wert als separate Regel und behalten Sie den Status für alle usw. bei. Unterstützend
Template-Variablen öffnen eine Dose voller Würmer für Komplexität und potenziell
verwirrendes Verhalten. könnte eines Tages hinzugefügt werden, wenn jemand eine Idee hat
einfache und verständliche Weise.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
.

--
Deepak

@bergquist zu diesem Kommentar

Alerting innerhalb von grafana unterstützt HA noch nicht. Unser Plan ist es, in Zukunft Partitionswarnungen zwischen Servern zu unterstützen

Gibt es ein Ticket, um den Fortschritt zu verfolgen? Irgendeine Filiale, die beitragen kann?

Und vielen Dank für die schöne Arbeit!

Kern,

<3 Grafana.

Ich habe nur versucht, Gedanken zu Benachrichtigungen mit Vorlage zu teilen
Armaturenbretter.

Am Freitag, 9. Dezember 2016 um 2:53 Uhr, Dmitry Zhukov [email protected]
schrieb:

@bergquist https://github.com/bergquist zu diesem Kommentar

Alerting innerhalb von grafana unterstützt HA noch nicht. Unser Plan ist es hinzuzufügen
Unterstützung für die zukünftige Partitionierung von Warnungen zwischen Servern

Gibt es ein Ticket, um den Fortschritt zu verfolgen? Irgendeine Filiale, die beitragen kann?

Und vielen Dank für die schöne Arbeit!

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
.

--
Deepak

@torkelo @Dieterbe Es ist großartig, endlich Alerts in Grafana integriert zu haben! Was ist die empfohlene Methode (falls vorhanden) zum programmgesteuerten Erstellen von Warnungen?

@jaimegago Um Warnungen programmgesteuert zu erstellen, verwenden Sie die Dashboard-API. Warnungen werden zusammen mit einem Panel und einem Dashboard gespeichert.

@torkelo Wie

Bearbeiten: Als ich mir selbst hier geantwortet habe, habe ich den Endpunkt api/alert-notifications gefunden. Ich denke es muss nur dokumentiert werden

Natürlich gibt es dafür eine http-API, gehen Sie einfach auf die Seite mit den Benachrichtigungen, fügen Sie eine Benachrichtigung hinzu und überprüfen Sie den HTTP-API-Aufruf, den Grafana macht

@torkelo , Gibt es eine API, die verwendet werden kann, um programmgesteuert eine Warnung zu erstellen (keine Warnungsbenachrichtigung zu erstellen)

@CCWeiZ Alerts ist ein Teil des Dashboards json. Sie können also nur ein Dashboard erstellen, das Warnungen enthält, nicht nur Warnungen.

Weitere Informationen zur Dashboard-API finden Sie unter http://docs.grafana.org/http_api/dashboard/

ist dies verfügbar: Ich möchte eine Warnung einrichten, wenn ein Wert im Vergleich zu vor 3 Tagen nicht ansteigt. (sagt die Anfragen, wenn jetzt Wert - vor 3 Tagen Anfragen < 100, dann sagen wir es gibt nicht viele Anfragen.). Wie macht man das?