Best practice per l'utilizzo dei marker in SLF4J / Logback

Stiamo usando SLF4J + Logback nel nostro progetto da un po 'di tempo e ne siamo abbastanza soddisfatti, ma la nostra strategia di logging è abbastanza semplice, usando logger basati su classi semplici e nessuna roba di fantasia come MDC o Marker.

Quello che voglio sapere è se qualcuno nella comunità utilizza effettivamente queste funzionalità e come vengono utilizzate per migliorare la registrazione / il filtro.

Sono particolarmente interessato a dove, perché e come utilizzare i marcatori ^[1] per la registrazione. Mi sembrano una caratteristica piuttosto ordinata per l'aggiunta di un contesto semantico nella registrazione - ad esempio, mentre una classe può gestire molteplici preoccupazioni, si possono usare marcatori di attività / preoccupazione specifici per discriminare le dichiarazioni di registro.

Quali potrebbero essere le migliori pratiche, convenzioni o strategie per la creazione e l'utilizzo di marcatori nella registrazione.

Aggiornamento: Credo, quello che sono in realtà dopo non è tanto il motivo per utilizzare i marcatori, ma piuttosto il modo in parte - c'è alcune pratiche buone di marcatori di denominazione (ad esempio utilizzando solo testo con spazi o precipitare / sottolineatura nomi di stile / punteggiatura delimitato parole chiave ), dovrebbe esserci una sorta di pool di "nomi standard", che nominano elementi basati sulle funzioni aziendali. Le domande che posso probabilmente capire da solo, ma se voglio usare queste funzionalità in modo sistematico e presentarle a un team di sviluppatori, ha senso avere alcune linee guida formalizzabili intorno ...

^[1] - Chiedendo come usare i marker non sto davvero chiedendo come usare l'API (è davvero abbastanza diretto) - Mi riferisco piuttosto al livello più generale di come si configurerebbe il log-in usando i marker in modo coerente

Innanzitutto, come ha detto @darioo:

• MDC viene utilizzato per associare più eventi a poche "entità"
• [Marker] sono usati per eventi "speciali" che vuoi filtrare da quelli normali

Quindi la tua affermazione che vuoi usare MDC per questo. I marcatori servono per evidenziare eventi "speciali" - filtrare, se vuoi - piuttosto che "tagliare". Ad esempio, è possibile eseguire il slice in base a un determinato utente, ma filtrare in base a eventuali eccezioni impreviste. In questo caso, è necessario creare una dimensione MDC utente e un marcatore UnexpectedException .

Ma questo a quanto pare non risponde alla domanda che avevi in ​​mente. Stai "piuttosto facendo riferimento al livello più generale di come si configurerebbe il logging usando gli indicatori in modo coerente". Quindi affrontiamo questo:

MDC è per affettare e tagliare a cubetti , e gli indicatori sono per il filtraggio . Queste attività vengono svolte durante i test e in produzione . Pertanto, è necessario decidere quali dimensioni ci si aspetta possano essere utili per suddividere i dati del registro e in quali casi potrebbe essere utile filtrarli quando si verificano i test / produzione. Ogni dimensione ottiene una dimensione MDC. Ogni caso ottiene un indicatore. E 'così semplice.

Gli sviluppatori non devono prendere alcuna decisione qui. Una singola persona o squadra dovrebbe decidere, in fase di progettazione , quale tipo di taglio, taglio a cubetti e filtro deve essere supportato. Questo dovrebbe essere informato immaginando che tipo di attività di analisi ci si aspetta che possano essere richieste.

Questa stessa persona o squadra dovrebbe decidere sulla convenzione di denominazione. È del tutto arbitrario . Scegli qualcosa che sia esteticamente gradevole, auto-descrittivo (la più importante) e abbastanza specifico da essere improbabile che sia in conflitto con aggiunte successive. Hyphens vs. underscore è estremamente nitido e allarmante oltre al punto, ma nota che potrebbe essere meno confuso per i dipendenti ESL leggere i caratteri di sottolineatura (almeno rispetto a CamelCase); allo stesso tempo, secondo quanto riferito, questo infastidisce alcuni sviluppatori a causa dell'imbarazzo nel raggiungere le chiavi richieste.

Per quanto riguarda la scelta di una politica, ciò significa semplicemente definire in quali casi deve essere utilizzata una determinata dimensione Marker o MDC . Tienilo stretto (centralizzato, deliberato), ma consenti ai feedback degli sviluppatori se ritengono che l'insieme di dimensioni e marcatori non siano sufficienti per l'attività da svolgere. Rivedi / aggiungi dimensioni e / o attributi come appropriato.

Comprendi che questa politica sarà quasi necessariamente specifica per il progetto . Non tutti i progetti richiedono lo stesso tipo di analisi della registrazione. Immagina alcuni scenari da incubo. Quindi immagina come vorresti essere in grado di analizzare i log in quello scenario. Probabilmente non vorrai scrivere uno script complicato per provare a tracciare quale messaggio appartiene a quale contesto e quale stato è in quale momento, giusto? Codifica qualunque informazione sia necessaria come dimensioni e marcatori e risparmia un po 'di seccatura se qualcosa va storto.

Innanzitutto, MDC.

MDC è davvero utile in un ambiente in cui si dispone di una "entità" associata ad alcuni comportamenti. Un tipico esempio: l'utente interagisce con un'applicazione Web. Quindi, supponiamo che tu abbia molti utenti che scherzano con la tua app web. Usando MDC, puoi facilmente rintracciarli senza troppi problemi. Esempio semplificato:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Qui, stai usando MDC in due posti: per nome utente e per ID sessione. In questo modo, puoi facilmente accedere alla sessione di un utente per vedere tutto ciò che ha fatto.

Secondo, marcatori.

I marcatori vengono generalmente utilizzati per circostanze "speciali", come l'invio di un'e-mail a un amministratore per alcuni errori gravi. Non tutti gli errori rientrano sempre nella stessa categoria; alcuni devono essere trattati in modo appropriato.

Oppure, quando un utente esce dal tuo servizio, di solito passa a un registro INFO, ma puoi anche usare un marcatore per tali casi, se vuoi eventi come questo in un file di registro separato, in modo da poterlo monitorare più facilmente per la raccolta statistica degli utenti che abbandonano.

Regola del pollice:

• MDC viene utilizzato per associare più eventi a poche "entità"
• i marcatori vengono utilizzati per eventi "speciali" che si desidera siano filtrati da quelli normali

I marcatori possono essere utilizzati per colorare o contrassegnare una singola istruzione di registro. Quello che fai con questi colori, cioè i pennarelli, dipende interamente da te. Tuttavia, due modelli sembrano essere comuni (il primo più comune del secondo) per l'utilizzo dei marker.

1. Trigger : alcuni appender potrebbero essere istruiti a compiere un'azione in presenza di un determinato marker. Ad esempio, SMTPAppenderpuò essere configurato per inviare un'e-mail ogni volta che un evento di registrazione è contrassegnato con il NOTIFY_ADMINmarcatore indipendentemente dal livello di registro. Vedi l' attivazione basata su marker nella documentazione di logback. È inoltre possibile combinare livelli di registro e marcatori per l'attivazione.

2. Filtro : ad esempio è possibile colorare / contrassegnare tutti i registri relativi alla persistenza (in file di varie e più classi) con il colore "DB". È quindi possibile filtrare per "DB": disabilitare la registrazione ad eccezione delle istruzioni di registro contrassegnate con DB. Vedere il capitolo sui filtri nella documentazione di logback per ulteriori informazioni (cercare MarkerFilter).

Proprio come un addendum, se si utilizza logstash e la registrazione json è abilitata, esiste un altro potenziale utilizzo di Marker: per la registrazione delle variabili da associare a un messaggio di registro specifico. Questo è più coerente e più facile da analizzare rispetto a includerlo nel corpo del messaggio. Molto utile, se si adatta al tuo caso d'uso.

Vedi i dettagli qui:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event