Ich verwende MonologBundle in meinem Symfony 2.8 -Projekt, um Protokollnachrichten zu verwalten. Mit verschiedenen Handlers ist es kein Problem, Protokolle in eine Datei zu schreiben und sie gleichzeitig per E-Mail zu senden.
Ich möchte die Anzahl der Nachrichten, die ich per Mail erhalte, reduzieren. Ich benutze bereits den Handler DeduplicationHandler und FingersCrossed , um nach Fehlerlevel zu filtern und doppelte Nachrichten zu vermeiden. Das funktioniert gut, ist aber nicht genug.
Zum Beispiel möchte ich die Anzahl der Mail über PageNotFound Fehler reduzieren. Natürlich möchte ich benachrichtigt werden, wenn /existingPage nicht gefunden wird, aber ich bin nicht an Nachrichten über /.well-known/... -Dateien interessiert.
Ein weiteres Beispiel sind Meldungen über Fehler in einer CSV-Parser-Komponente eines Drittanbieters. Es gibt einige bekannte und harmlose Fehler, die mich nicht interessieren, aber natürlich sind andere Fehler wichtig.
Diese Fehler / Nachrichten werden durch Code von Drittanbietern generiert, ich kann die Quelle nicht beeinflussen. Ich könnte diese Nachrichten nur vollständig ignorieren, aber das ist nicht das, was ich will.
Ich suche nach einer Lösung, um die Nachrichten nach Inhalt zu filtern. Wie kann das in Monolog gemacht werden?
Ich habe bereits versucht, dies mit einem HandlerWrapper zu lösen und habe dieses Problem in einer anderen Frage diskutiert: Die Idee war, dass die HandlerWrapper fungiert als Filter. Das HandlerWrapper wird von Monolog aufgerufen, es überprüft den Nachrichteninhalt und entscheidet, ob es verarbeitet werden soll oder nicht (z. B. alle Nachrichten einschließlich des Texts "./well-known/" verwerfen). Wenn eine Nachricht weitergegeben wird, sollte die HandlerWrapper sie einfach an ihren geschachtelten / umhüllten Handler übergeben. Andernfalls wird die Nachricht ohne weitere Verarbeitung übersprungen.
Allerdings hat diese Idee nicht funktioniert, und die Antworten auf die andere Frage zeigen, dass ein HandlerWrapper nicht der richtige Ansatz für dieses Problem ist.
Die neue / tatsächliche Frage lautet also: Wie erstelle ich einen Filter für Monolog-Nachrichten, mit dem ich steuern kann, ob eine bestimmte Nachricht verarbeitet werden soll oder nicht?
Ich bin mir nicht sicher, warum die Verwendung eines HandlerWrappers der falsche Weg ist.
Ich hatte das gleiche Problem und habe einen Weg gefunden, wie man einen Handler einpackt, um bestimmte Datensätze zu filtern.
In dieser Antwort beschreibe ich zwei Wege, um das zu lösen, ein komplexeres und ein leichteres.
Als erstes habe ich eine neue Klasse erstellt, die den HandlerWrapper erweitert und eine Logik hinzugefügt hat, wo ich Datensätze filtern kann:
%Vor%Dann habe ich eine Service Definition und einen CompilerPass erstellt, wo ich den GroupHandler
einpacken kann services.yml
Wie Sie sehen können, gehe ich hier alle Definitionen durch und finde diejenigen, die den GroupHandler als Klasse haben. Wenn dies der Fall ist, füge ich dem Container, der den ursprünglichen Handler mit meinem CustomHandler schmückt, eine neue Definition hinzu.
Randnotiz : Zuerst habe ich versucht, alle Handler (außer natürlich den CustomHandler :) zu umbrechen), aber da einige Handler andere Schnittstellen implementieren (wie die ConsoleHandler mit dem EventSubscriberInterface) das hat nicht funktioniert und führte zu Problemen, die ich nicht hatte Ich möchte es auf eine hacky Art lösen.
Vergessen Sie nicht, diesen Compiler-Pass zum Container in Ihrer AppBundle-Klasse hinzuzufügen
%Vor%Nun, da alles vorhanden ist, müssen Sie Ihre Handler gruppieren, damit dies funktioniert:
app/config(_prod|_dev).yml
Wir benutzen den gleichen CustomHandler wie wir es auf komplexe Weise gemacht haben, dann definieren wir unsere Handler in der config:
app/config(_prod|_dev).yml
Dekorieren Sie den Handler in Ihrer services.yml mit Ihrem eigenen CustomHandler
services.yml
Für die Eigenschaft dekoriert müssen Sie das Format monolog.handler.$NAME_SPECIFIED_AS_KEY_IN_CONFIG verwenden, in diesem Fall war es graylog.
... und das ist es
Während beide Wege funktionieren, habe ich den ersten verwendet, da wir mehrere Symfony-Projekte haben, wo ich das brauche und alle Handler dekoriere manuell ist einfach nicht das was ich wollte.
Ich hoffe, das hilft (obwohl ich ziemlich spät für eine Antwort bin))