Wie Stack-Trace zu protokollieren AWS Elastic Beanstalk, um Kundenfehler schnell zu beheben

Question

Vielleicht gehe ich über den falschen Weg oder nicht fragen den Google den richtigen Weg. Also entschuldige ich mich wenn das ein Duplikat ist. Ich möchte schnell/effizient in meiner Java-Webanwendung Client-/Benutzerfehler beheben können.

Das heißt, wir können leicht sehen, wo unsere Fehler auf einem lokalen Computer sind, indem Sie eine e.printstacktrace tun. Ich möchte den besten Weg wissen, dies auf einer EC2/Elastic Beanstalk-Instanz zu tun. Wenn ein Kunde einen Fehler erhält, möchte ich, dass er per E-Mail nachfragen kann, was unter "Ticket-Nummer" oder "Fehler an diesem Datum um diese Zeit" geschehen ist. Mein Gedanke war, wenn eine Ausnahme auftritt, den Stacktrace in meiner Datenbank zusammen mit dem Benutzernamen zu protokollieren und den db.uniqueKey an den Benutzer zurückzusenden, damit er mir eine E-Mail über diese eindeutige Schlüssel-/ID-Nummer senden kann.

Ich weiß nicht, ob dies eine gute Idee ist, Teilstrings eines Stacktrace zu einem Db zu protokollieren (alle diese Db-Verbindungen öffnen/schließen, um Stacktraces zu protokollieren).

Wenn ich dieses Thema nachgehe, bekomme ich viel über AWS CloudWatch, aber das sieht mehr wie ein Werkzeug aus, um alles zu protokollieren, was in meiner Umgebung und Server passiert. Das scheint ein Rezept für das Scrollen von Protokolldateien für immer.

Protokolliert ein StackTraceString zu einer DB mit einem Benutzernamen eine gute Idee? Gibt es einen besseren Weg, um rechtzeitig zu meinen Nutzern zurückzukehren, was passiert sein könnte?

Answer 1

Sie können einen API-Aufruf an CloudWatch Logs senden, um eine einzelne Protokollnachricht zu senden, anstatt Ihre gesamten Tomcat-Protokolldateien an CloudWatch zu senden. Sie können auch Protokolle in JSON format senden, so dass Sie Metadaten wie Ihre Benutzer-ID, eindeutigen Schlüssel usw. aufnehmen können. Sehen Sie sich die AWSLogsClient Klasse im SDK an.

Beachten Sie, dass es auch Drittanbieter-Dienste wie Loggly und LogEntries gibt, die wirklich gut in dieser Art von Sache sind, und meiner Meinung nach viel benutzerfreundlicher als CloudWatch Logs ist derzeit. Dieser Dienst stellt auch APIs zum Senden einzelner Protokollnachrichten aus Java bereit, wenn Sie nicht Ihre gesamten Protokolldateien an diese senden möchten.

Ich würde empfehlen, einen Dienst für die Protokollierung wie die, die ich aufgeführt habe, statt einer Datenbank zu verwenden. Diese Dienste werden gut skaliert, ohne dass Sie sich über Dinge wie die Anzahl der offenen DB-Verbindungen sorgen müssen. Diese Dienste verarbeiten auch Warnungen, die auf dem Inhalt von Protokollnachrichten basieren, und bieten eine nette Weboberfläche zum Anzeigen der Protokollnachrichten.

Wenn Sie sich entscheiden, mit einer Datenbank-Ansatz gehen würde ich empfehlen, in DynamoDB für diese anstelle einer relationalen Datenbank wie MySQL oder PostgreSQL. DynamoDB lässt sich leicht skalieren, speichert Dokumente einfach als JSON-Daten und kann Lambda-Funktionen auslösen, die beispielsweise für das Senden von Alarmen verwendet werden können.