ElabNET Technik Forum

Hi,

ich habe mal versucht mir via Grafana und den darin enthaltenen Möglichkeiten bei bestimmten Rahmenbedingungen mittels Alamierungen eine Mail zu senden.

Ich versuchte einen "New Notification Channel" zu definieren. Das scheiterte mit "SMTP not configured, check your grafana.ini config file's [smtp] section."

Kommt man da irgendwie dran? Ist da was geplant?

Gruß
Jens

Wieso via Grafana?

Schritt eins TWs bekommt den Logikeditor (nächste Stufe Beta solls ja soweit sein)
Schritt zwei TWs bekommt das Messagemodul da soll es ja e-mail und sonstige Benachrichtigungsservices geben.

Alternative bis dahin eine Dockerlösung, denke ich ginge schneller.

Hi Göran,

War ja nur ein ProofOfConcept.

Woher weiß ich als nicht Beta-Teilnehmer, was wann kommen wird?
Spräche etwas dagegen, die von Grafana ja offensichtlich zur Parametrierung akzeptierten Umgebungsvariablen über die TW-Adminoberfläche zu Erfassen und dann durchzuschleifen? Damit man über diese Methodik dann nichts wichtiges übersteuert, könnte man dem dann wieder mit einer Black-/Whitelist begegnen.

Beste Grüße
Jens

Hi Jens,

da bin ich zuwenig Programmierer um das beurteilen zu können. Wollte halt nur sagen das Logik mit Schwellwerten aller art ja eh out of the box kommen werden genauso wie ein Benachrichtigungsystem. Bis es dann soweit ist, ja klar da kann man natürlich nach Alternativen suchen. Würde aber auch nicht zu viel Aufwand da rein stecken.

Nachdem letztlich sowieso im TWS ein oder mehrere SMTP-Account definiert werden müssen, um später über den Logikeditor/das Messagemodul E-Mails zu versenden, könnte man daraus einen FR machen:

Stufe 1:
Erfassung eines SMTP-Accounts im TWS, damit der TWS selbst z.B. Passworterinnerungen und Fehlermeldungen versenden kann, dieser im Logikeditor/Messagemodul genutzt werden kann und dieser könnte einfach in die grafana.ini mit genutzt werden.

Stufe 2:
Erfassung mehrerer SMTP-Accounts im TWS mit Optionen, wofür jeder Account genutzt werden kann. Wobei ich nicht weiß, in wie vielen Anwendungsfällen diese Stufe überhaupt notwendig ist. Ich bräuchte sie nicht.

Guten morgen zusammen! Ich wollte meinen Post aber bewusst nicht nur auf SMTP beschränken, sondern hatte das als einfaches Beispiel zur Veranschaulichung des Problems genutzt. Wenn mann sich allein die verschiedenen Typen der von Grafana angebotenen "Notification Channel" ansieht, bekommt man einen kleinen Eindruck von der Mächtigkeit des Tools. Da ist das Thema mit den Plugins noch nicht mal ansatzweise beleuchtet.

Stefan steht da aber mit seinem Team wieder klar in der Zwickmühle. Wie weit will man die Konfigurierbarkeit einer im Standard genutzten Komponente öffnen, ohne sich durch dieses Einfallstor potentielle Probleme im Verhalten des Standards mit dem damit verbundenen Supportaufkommen einzufangen.

Letztlich gibt es glaube ich nur zwei Varianten:
1.) Wenn die intern genutzte Grafana-Instanz für die "Spielkinder" unter uns (Wer ist das hier eigentlich nicht ) auch im erweiterten Umfang nutzbar sein soll, dann muss eine umfangreiche Konfigurationsmöglichkeit für alle Grafana-Elemente her. Ob Basis oder Plugin ist dann eigentlich unerheblich. Störungen des Standards kann man dann ggf. darüber verhindern, dass bei einem Merge einer Gesamtkonfigdatei sichergestellt wird, das keine für den Standard relevanten Bestandteile zerstört werden. Das wird aber ggf. bei Updates und späteren Erweiterungen des Standards wieder zur Herausforderung.

2.) Eigene Grafana-Instanz im Docker mit den dann offenen Möglichkeiten und klarer Abtrennung von der Instanz im Standard. Aktuell wüsste ich dann nur aus der neuen Instanz noch nicht an die Daten zu kommen. Aber das liegt wahrscheinlich noch am Stand der Beta mit oder am meinem fehlenden Detailwissen.

Beste Grüße
Jens

Hallo Jens @blaubaerli ,

das mit der Email-Notifikation ist in der Pipeline.
Ob als Teil der Logik oder als eigenständiges Subsystem, wird noch diskutiert.

Falls du aber mit den Grafana-Alerts spielen möchtest, könntest du das z.B. über "Telegram" auf dein i-/android-phone machen.

Hab es gerade mit dieser Anleitung erfolgreich getestet:
https://community.grafana.com/t/telegra ... ration/242

Viel Spaß beim Alarmieren
Stefan K.

blaubaerli hat geschrieben: ↑Fr Dez 28, 2018 8:52 amStefan steht da aber mit seinem Team wieder klar in der Zwickmühle. Wie weit will man die Konfigurierbarkeit einer im Standard genutzten Komponente öffnen, ohne sich durch dieses Einfallstor potentielle Probleme im Verhalten des Standards mit dem damit verbundenen Supportaufkommen einzufangen.

Richtig, daher gehören die ganzen Open-Source-Tools, die wir "kostenlos" beilegen auch nicht zu den Teilen der Software, für die wir dann auch Support schulden. Das geht auch bei der Mächtigkeit von Grafana / Docker / Portainer / CometVisu usw. nicht, weil völlig unkalkulierbar.

blaubaerli hat geschrieben: ↑Fr Dez 28, 2018 8:52 am2.) Eigene Grafana-Instanz im Docker mit den dann offenen Möglichkeiten und klarer Abtrennung von der Instanz im Standard.

Das ist auch meine Empfehlung. Wer sich nun ganz armtief in Garafana einarbeiten und jede Möglichkeit und Update und Plugin dort nutzen möchte, baut sich eine eigene Version in Docker.

blaubaerli hat geschrieben: ↑Fr Dez 28, 2018 8:52 amAktuell wüsste ich dann nur aus der neuen Instanz noch nicht an die Daten zu kommen. Aber das liegt wahrscheinlich noch am Stand der Beta mit oder am meinem fehlenden Detailwissen.

Jep. Der Weg dafür ist bereits in BETA 15 drin und wurde hier in einem der CometVisu Threads bereits gezeigt.

S. Kolbinger hat geschrieben:Ob als Teil der Logik oder als eigenständiges Subsystem, wird noch diskutiert.

Ein Gedanke der mir gerade beim Lesen dazu kam:
Völlig unabhängig wie das später realisiert wird. Die Fehlerberichterstattung, sollte out ouf the Box so einfach wie möglich funktionieren. Was meine ich damit? Man gibt dem Timberwolf die notwendigen Daten, also E-Mail Adresse und Kontodaten für den E-Mail Server und fertig. Am besten sind dies Daten die man gleich bei der ersten Einrichtung eingeben kann. Dann bekommt daraufhin ohne erstmal weiteres einstellen zu müssen Emails, wenn es Fehler in 1-Wire, DMX oder sonst wo gibt.

Im Prinzip würde ich das sogar beides realisieren:
- Teil des Logikeditor = Emails für genaue Fehlerüberwachung bestimmter Objekte, bzw. Statusemails etc.
- Teil des Subsystemes = Allgemeine Fehler Emails ("Ein 1-Wire Gerät ist gestört") die einen dazu bewegen sollen die Oberfläche aufzurufen, um weitere Maßnahmen zu ergreifen.

Auch wenn das etwas doppelt gemoppelt erscheinen mag, ich denke es kann durchaus Sinn machen, denn je komplexer/umfangreicher das Einrichten wird, desto später wird das genutzt.

Ich hoffe es wird einigermaßen klar, was ich meine.

Also ich möchte nicht Out of the Box nen Spam-Generator haben.

Jedwedes Problemchen irgendwo im System brauch ich keine e-mail auf meinem Acc.

Ich hätte schon gern eher das man da selbst aktiv eine Benachrichtigung einrichtet. Wer mal einen Blick in die "pre-beta-Version" des Logikeditor geworfen hat sah ja bereits eine Ausgabeoption bei den Logiken mit dem Begriff Error. Ich denke wenn man diesen Ausgang mit einem Mail-Object verlinkt dann hat man auch das was Du suchst. Aber es ist nicht per default aktiviert und mit einer Message verlinkt.

Oder ich habe dich falsch verstanden.