Java >> Programma Java >  >> Java

Approccio IDE all'analisi dei log pt. 2

Introduzione

Nella prima parte ho spiegato l'approccio teorico all'analisi dei log che ritengo sia il migliore per un ingegnere sostenibile. Questo ingegnere non ha bisogno di analizzare i registri immediatamente non appena arrivano, ma si concentra invece su un'analisi approfondita di problemi complicati. In questa seconda parte mostrerò che molti scenari di ricerca possono essere coperti con un modello sofisticato e mostrare un prototipo funzionante.

Cerca modello oggetto

Il requisito principale per il modello di ricerca è che deve essere sofisticato, nel migliore dei casi molto sofisticato. Meno ricerca manuale, meglio è. Un modello sofisticato dovrebbe fare la maggior parte del lavoro e farlo velocemente. Poiché qui non abbiamo server, è importante anche solo il PC dello sviluppatore che dovrebbe gestire 2-3 GB di velocità di registro.

Principali espressioni regolari

Il modello dovrebbe dichiarare alcune espressioni regolari che verranno cercate (con Matcher.find) nei log. Se ne viene dichiarato più di uno per primo vengono raccolti i risultati per il primo, quindi per il secondo ecc. Nel senso più generale il risultato di una ricerca è un array di String – List.

Criteri di accettazione

Non tutti i risultati vengono accettati dal processo di ricerca. Ad esempio, il tecnico può cercare tutti i tipi di connessione esclusa la "X". Quindi lui o lei può creare un criterio di accettazione e filtrarlo. specificando una regex "qualsiasi tipo tranne X". Un'altra possibilità è la ricerca entro un intervallo di tempo. L'ingegnere può cercare qualsiasi record di registro tra 10 e 12 ore (dovrà inserire le date complete ovviamente).

È anche possibile cercare espressioni distinte. In questo caso l'ingegnere specifica un'altra espressione regolare (più di una nel caso generale). Un esempio spiegherà meglio questo concetto.

regex distinta:

connection type (q|w)

record di log trovati dalla regex principale:

connection type w found
connection type q created
connection type s destroyed
connection type q found

Il risultato di una ricerca distinta:

connection type w found
connection type q created

Parametri

Uno dei problemi con le espressioni regolari è che le espressioni regolari davvero utili sono molto lunghe e ingombranti. Ecco una data di esempio da un registro:

2018-08-06 10:32:12.234

Ed ecco la regex:

\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d.\d\d\d

La soluzione è abbastanza semplice:usa la sostituzione. Li chiamo parametri per la regex. Alcuni parametri possono essere statici come l'ora del record, ma alcuni possono essere definiti dall'utente. Immediatamente prima dell'esecuzione i parametri vengono sostituiti con i valori effettivi.

Viste

Il risultato della ricerca è un record di registro, ovvero qualcosa come

2018-08-06 10:32:12.234 [Thread-1] DEBUG - Connection 1234 moved from state Q to state W \r?\n

Sebbene sia fantastico trovare ciò che è stato definito nel modello, sarebbe ancora meglio dividere le informazioni in parti utili. Ad esempio questa tabella rappresenta in modo chiaro e conciso tutte le informazioni utili di questo record:

->
Connessione 1234 Q W

Per estrarre queste informazioni possiamo usare l'approccio "view". Ciò significa dichiarare le espressioni regolari più piccole che vengono cercate nel record di registro e restituire un'informazione sul record di registro. È come una vista di questo record di registro. Mostrare tutto in una tabella facilita la lettura. Inoltre una tabella può essere ordinata in base a qualsiasi colonna.

Ordina e unisci

Il modo più efficiente per effettuare questo tipo di ricerca con il modello è utilizzare un pool di thread e assegnare ogni thread a un file di registro. Supponendo che ci siano 3-4 thread nel pool, la ricerca funzionerà 3-4 volte più velocemente. Ma la fusione dei risultati diventa una questione importante. Ci possono essere 2 soluzioni qui:

  1. Unione dei risultati . Dobbiamo assicurarci che i risultati vadano nell'ordine corretto. Se abbiamo 3 file di registro, il primo che copre 10-12 ore, il secondo 12-14, il terzo 14-17, i risultati della ricerca da quei file devono andare nello stesso ordine. Questo si chiama unione.
  2. Ordinamento dei risultati . Invece di unirli, possiamo semplicemente ordinarli per data e ora. Meno sofisticato ma semplice.

L'unione sembra una tecnica più avanzata che ci consente di mantenere l'ordine originale dei record.

Flusso di lavoro

Pensieri finali

La domanda che deve assillare tutti coloro che hanno raggiunto questo punto in questo post è:qualcuno ha provato a implementare tutto questo? La risposta è si! Esiste un'applicazione funzionante basata sul framework Eclipse, include una configurazione Spring XML e molte altre cose. I modelli di oggetti di ricerca funzionano come descritto in questo articolo.

Ecco il link Github:

https://github.com/xaltotungreat/regex-analyzer-0

Perché 0? Beh, doveva essere un prototipo e in una certa misura lo è ancora. Ho chiamato questa applicazione REAL

R regolare
E xpressioni
A analizzatore
per L ogs

Si presume che l'utente abbia una certa conoscenza su come esportare un'applicazione Eclipse RCP o avviarla dall'IDE Eclipse. Sfortunatamente non ho avuto abbastanza tempo per scrivere una buona documentazione a riguardo. Per impostazione predefinita può analizzare i registri HBase e ci sono molti esempi nella cartella config.

Etichetta Java