Sentry ohne Server: Nur Exceptions serialisieren
Hallo, vor ein paar Wochen wurde mir hier Sentry empfohlen. Wir haben jedoch schon ein zentrales Tool um Fehler von Remote-Hosts anzuzeigen. Darum missfällt mir die Vorstellung einen zweiten Server und eine zweite GUI für Exceptions zu erstellen. Ein Kollege und ich haben folgendes überlegt: Wir nutzen den Sentry-Client für Python der Exceptions serialisiert. Diese Exceptions werden aber nicht an den Sentry-Server übergeben sondern in eine Datei geschrieben. Dann sammelt das schon lange existierende zentrale Tool diese serialisierten Exceptions ein. In der Zentrale wird dann die Exception deserialisiert und "hübsch" angezeigt. Obiges sind theoretische Vorüberlegungen. Bevor ich hier Zeit investiere wollte ich hier fragen, ob es aus eurer Sicht einen Weg gibt, der einfacher/sinnvoller ist. Vielleicht bin ich hier blind und habe hier etwas übersehen. Wir würden von Sentry also nur das serialisieren der Exception nutzen und ggf auch das deserialisieren (zu HTML wandeln). Wir haben rund 100 Systeme die wir überwachen. Was denkt ihr? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Ich denke du hast Sentry noch nicht verstanden. Einen Exception Serialisierer schreibt man in einer halben Stunde, wenn man sich Mühe gibt. Das ist wirklich der geringste Teil des ganzen. Sentry’s Stärke ist die UX. Das aggregieren von exceptions, die Möglichkeit nach Kriterien zu filtern, sie zB für eine bestimmte Release stummzuschalten, so das sie erst wieder auftauchen, wenn eine neue Version ausgerollt wurde, Statistiken, etc. Ist also in meinen Augen keine gute Idee. Von meinem iPad gesendet
Am 16.12.2017 um 09:11 schrieb Thomas Güttler Lists
: Hallo,
vor ein paar Wochen wurde mir hier Sentry empfohlen.
Wir haben jedoch schon ein zentrales Tool um Fehler von Remote-Hosts anzuzeigen.
Darum missfällt mir die Vorstellung einen zweiten Server und eine zweite GUI
für Exceptions zu erstellen.
Ein Kollege und ich haben folgendes überlegt:
Wir nutzen den Sentry-Client für Python der Exceptions serialisiert. Diese Exceptions
werden aber nicht an den Sentry-Server übergeben sondern in eine Datei geschrieben.
Dann sammelt das schon lange existierende zentrale Tool diese serialisierten Exceptions
ein. In der Zentrale wird dann die Exception deserialisiert und "hübsch" angezeigt.
Obiges sind theoretische Vorüberlegungen.
Bevor ich hier Zeit investiere wollte ich hier fragen, ob es aus eurer Sicht einen Weg gibt, der einfacher/sinnvoller ist.
Vielleicht bin ich hier blind und habe hier etwas übersehen.
Wir würden von Sentry also nur das serialisieren der Exception nutzen und ggf auch das deserialisieren (zu HTML wandeln).
Wir haben rund 100 Systeme die wir überwachen.
Was denkt ihr?
Gruß,
Thomas
-- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
_______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 16.12.2017 um 10:12 schrieb Diez B. Roggisch: Ich denke du hast Sentry noch nicht verstanden. Ja, ich denke, du hast da Recht. Einen Exception Serialisierer schreibt man in einer halben Stunde, wenn man sich Muehe gibt. Das ist wirklich der geringste Teil des ganzen. Ich glaube, ich wuerde dafuer deutlich laenger brauchen. Wenn die Variablen jedes Frames des Stacktraces mit uebergeben werden sollen, dann gibt es dort schon eine Menge Sonderfaelle. Dinge, die sich nicht serialisieren lassen wie zB offene File-Descriptoren. Wenn das schon implementiert ist, und tausendfach getestet wurde, dann wuerde ich lieber das nehmen als selber zu entwickeln. Sentry's Staerke ist die UX. Das aggregieren von exceptions, die Moeglichkeit nach Kriterien zu filtern, sie zB fuer eine bestimmte Release stummzuschalten, so das sie erst wieder auftauchen, wenn eine neue Version ausgerollt wurde, Statistiken, etc. Ist also in meinen Augen keine gute Idee. Wir haben nicht hunderte Exceptions am Tag. Es sind nur wenige. Sicherlich kann der zentrale Sentry Server sehr viel, aber ich frage mich, ob es vielleicht fuer meinen Kontext besser ist ein (anstatt zwei) Monitoring Tools zu haben. Gruss, Thomas -- Thomas Guettler [1]http://www.thomas-guettler.de/ I am looking for feedback: [2]https://github.com/guettli/programming-guidelines References Visible links 1. http://www.thomas-guettler.de/ 2. https://github.com/guettli/programming-guidelines
Hallo Thomas, du hast die Leute hier um ihre Einschaetzung geben, und in ungewohnter Eintracht schallte es “Sentry” zurueck. Natuerlich ist es dir ueberlassen, diesen Rat zu ignorieren. Aber du wirst keinen anderen bekommen. Wenn du glaubst, eine selbstgestrickte Loesung (egal ob mit oder ohne den Client von Sentry, mehr Daten zu erfassen macht ja die Auswertung nur *noch* komplizierter), musst du das schon selbst rechtfertigen. Ich denke nicht, das jemand anderes das fuer dich tut. Mach es doch so: wenn du eh den Client ausrollen willst, dann installier doch einfach Sentry, lass die Clients dagegen laufen, und schau dir das an. Das ist ja nun wirklich nicht die Welt an Aufwand. Und wenn das zweite Browsertab mit einem extra Prozess dahinter nach ein paar Tagen oder Wochen wirklich so viel Probleme bereitet, dann ist die Entscheidung gegen Sentry aufgrund einer Evaluation getroffen, und nicht von einem Bauchgefuehl heraus, das dir hier eh niemand nehmen kann. Diez
On 18 Dec 2017, at 09:30, Thomas Güttler
wrote: Am 16.12.2017 um 10:12 schrieb Diez B. Roggisch:
Ich denke du hast Sentry noch nicht verstanden.
Ja, ich denke, du hast da Recht.
Einen Exception Serialisierer schreibt man in einer halben Stunde, wenn man sich Muehe gibt. Das ist wirklich der geringste Teil des ganzen.
Ich glaube, ich wuerde dafuer deutlich laenger brauchen. Wenn die Variablen jedes Frames des Stacktraces mit uebergeben werden sollen, dann gibt es dort schon eine Menge Sonderfaelle. Dinge, die sich nicht serialisieren lassen wie zB offene File-Descriptoren. Wenn das schon implementiert ist, und tausendfach getestet wurde, dann wuerde ich lieber das nehmen als selber zu entwickeln.
Sentry's Staerke ist die UX. Das aggregieren von exceptions, die Moeglichkeit nach Kriterien zu filtern, sie zB fuer eine bestimmte Release stummzuschalten, so das sie erst wieder auftauchen, wenn eine neue Version ausgerollt wurde, Statistiken, etc.
Ist also in meinen Augen keine gute Idee.
Wir haben nicht hunderte Exceptions am Tag. Es sind nur wenige. Sicherlich kann der zentrale Sentry Server sehr viel, aber ich frage mich, ob es vielleicht fuer meinen Kontext besser ist ein (anstatt zwei) Monitoring Tools zu haben.
Gruss, Thomas
-- Thomas Guettler [1]http://www.thomas-guettler.de/ I am looking for feedback: [2]https://github.com/guettli/programming-guidelines
References
Visible links 1. http://www.thomas-guettler.de/ 2. https://github.com/guettli/programming-guidelines _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 18.12.2017 um 13:00 schrieb Diez B. Roggisch: Hallo Thomas, du hast die Leute hier um ihre Einschaetzung geben, und in ungewohnter Eintracht schallte es "Sentry" zurueck. Natuerlich ist es dir ueberlassen, diesen Rat zu ignorieren. Aber du wirst keinen anderen bekommen. Wenn du glaubst, eine selbstgestrickte Loesung (egal ob mit oder ohne den Client von Sentry, mehr Daten zu erfassen macht ja die Auswertung nur *noch* komplizierter), musst du das schon selbst rechtfertigen. Ich denke nicht, das jemand anderes das fuer dich tut. Mach es doch so: wenn du eh den Client ausrollen willst, dann installier doch einfach Sentry, lass die Clients dagegen laufen, und schau dir das an. Das ist ja nun wirklich nicht die Welt an Aufwand. Und wenn das zweite Browsertab mit einem extra Prozess dahinter nach ein paar Tagen oder Wochen wirklich so viel Probleme bereitet, dann ist die Entscheidung gegen Sentry aufgrund einer Evaluation getroffen, und nicht von einem Bauchgefuehl heraus, das dir hier eh niemand nehmen kann. Ja, das klingt sinnvoll. Gruss, Thomas -- Thomas Guettler [1]http://www.thomas-guettler.de/ I am looking for feedback: [2]https://github.com/guettli/programming-guidelines References Visible links 1. http://www.thomas-guettler.de/ 2. https://github.com/guettli/programming-guidelines
participants (3)
-
Diez B. Roggisch
-
Thomas Güttler
-
Thomas Güttler Lists