Protokollierungslösung auf Geschäftsebene

Wir suchen nach einer Protokollierungslösung auf Geschäftsebene, die einige Funktionen sowohl für die Protokollierung in eine Datenbank als auch in reguläre Protokolldateien bietet.

1) Reguläre Protokolldateien sind nur für Entwickler lesbar. Kunden möchten auch auf einige Protokolle zugreifen. Wie Ereignisse eines Kaufs, den sie getätigt haben.

2) Reguläre Protokolldateien sind nicht abfragbar. Wir brauchen keine komplexen Abfragen, Verknüpfungen usw., aber das Auffinden von Protokollen zu einer bestimmten Sache im System zwischen zwei Daten und solchen Dingen ist erwünscht.

3) Datenbanken sind nicht "speicherbar", da ich alte Protokolle nicht einfach auf meinen Computer verschieben kann, ohne das real laufende System zu stören.

4) Datenbanken müssen gewartet werden. Die anwendungseigene DB-Wartung ist eine Arbeitsbelastung, und ich möchte ihr keine Wartung einer zweiten DB hinzufügen. Logfiles sind auch nach einem schweren Systemabsturz etc. noch lesbar und benötigen nicht viel Wartung.

5) Für beide: Geschäftsprotokolle sind wichtig, sie sind keine Website-Zugriffsstatistiken, bei denen es nicht darauf ankommt, etwas zu verlieren.

So ungefähr. Gibt es nicht eine Lösung, die ein bisschen das Beste aus beiden Welten hat?

Welches Betriebssystem wäre relevant, Windows würde ganz andere Lösungen anbieten als irgendetwas auf Linux-Basis.
Entwicklungsmaschinen sind Windows und echte Anwendungen laufen auf CentOS.

Antworten (1)

Nun, lass es uns versuchen, falls niemand anderes mit besseren Kenntnissen hereinkommt. Es ist also nicht wirklich eine Antwort, sondern eher ein Hinweis auf ein paar Optionen, die dir helfen könnten.

Zunächst wäre interessant, welche Menge an 'Protokollen' Sie erwarten. Punkt eins (Kaufereignisse) scheint nicht sehr groß zu sein. Auch zu Punkt 3, Sie können immer etwas SQL in eine Datei ausgeben, was das System nicht sehr stören sollte.

Es scheint, dass das, was Sie wollen, auf der Linie einer NoSQL-Datenbank liegen würde. (Obwohl Sie sagen, dass Sie keinen zusätzlichen DB-Wartungsaufwand wünschen). Einige Arten von Schlüsselwertspeichern (z. B. Redis) wären jedoch sehr einfach zu verwenden, andere wären einfach genug und bieten genau die Art von Suche, die Sie durchführen möchten.

Wie in meinem Kommentar zu Programmers.SE geschrieben, könnte der ELK-Stack ein möglicher Weg sein. Elasticsearch für die Suche (mit Kibana als ausreichend komfortables Frontend) und Logstash als einer der Industriestandards für Protokolle (mit Redis für die Speicherung als Option). Dies ist jedoch für Protokolle mit hohem Volumen wie Apache-Protokolle, sb-Protokolle und ähnliche systembasierte Protokolle gedacht.

Sie können dies leicht als Ausgangspunkt verwenden. Wenn Sie kein sehr hohes Volumen haben, können Sie Elasticsearch trotzdem zusammen mit Kibana verwenden und eine API zur Authentifizierung vorschalten.

Versuchen wir vielleicht auch, alle Punkte der Reihe nach durchzugehen:

1) Die meisten Systeme dieser Art (auch die meisten NoSQL-DBs) bieten nicht viel auf dem Gebiet der Benutzerauthentifizierung. Ihre einzige Option in diesem Fall wäre also, ein Frontend für die Benutzer zu schreiben, das dies handhabt. (Angenommen, Entwickler würden Kibana mit vollem Zugriff verwenden und das Frontend wäre weiterhin in der Lage, Abfragen mit der ziemlich einfachen Syntax von Elasticsearch auszuführen.)

2) Genau das, was ELK bietet (und andere NoSQL-Lösungen).

3) Wenn Sie nicht von sehr hohen Datenmengen sprechen, stimmt das einfach nicht.

4) Nun, entweder möchten Sie eine einfache Abfrage oder eine einfache Speicherung als Dateien. Wenn Sie ein „System“ installieren, müssen Sie es bis zu einem gewissen Grad warten. Ich wüsste nichts, was mit Daten umgeht, Persistenz garantiert und keine Wartung erfordert.

5) Die meisten NoSQL-Lösungen lassen zu, was Sie wollen. Welches genau das Beste ist, hängt davon ab, aber Elasticsearch oder MongoDB würden es ermöglichen, mit 100% Persistenz konfiguriert zu werden. Die zu treffenden Kompromisse (wie im 2-von-3-CAP-Theorem sind nur bei superhohen Datenmengen über viele Cluster relevant).

Vielleicht werfen Sie einen Blick auf die Elasticsearch-Site, dort gibt es ein paar Video-Tutorials, die ELK demonstrieren und die Sie nicht mehr als eine Stunde Ihrer Zeit zum Anschauen kosten würden. Nicht zuletzt wird es Ihnen einige interessante Einblicke in das geben, was dort möglich ist.