Ricerca di modelli nei registri

0

Sto cercando di mettere insieme un modo per capire se gli incidenti si sono verificati in base al contenuto del registro. In genere, su log (o tabella DB) conterrebbe un elenco di transazioni composto come segue: {Timestamp} {TransactionID} {Message}

Come esempio di problema che ho incontrato, l'ho usato per rilevare se si sono verificati "incidenti" eseguendo alcune query molto semplici come:

SELECT Timestamp, count(*)
FROM table
GROUP BY Timestamp
HAVING COUNT(*) > 5
ORDER BY Timestamp

Funziona OK ma ha avvertimenti molto forti:

  • Nei momenti di alta attività restituirà i record per niente (e alzando la barra si nasconderanno le righe che dovrebbero essere restituite)
  • Diciamo che ho 4 eventi al timestamp t e 2 eventi al timestamp (t + 1), la mia query non restituirà nulla anche se dovrebbero essere considerati. Sfortunatamente, aggregando i timestamp per intervalli di tempo, mi porterò al punto precedente sull'elevato tempo di attività.

Qualcuno potrebbe avere alcune informazioni su come affrontare il problema più ampio del rilevamento degli incidenti nei registri?

    
posta E. Jaep 06.12.2013 - 22:32
fonte

2 risposte

2

Would someone have some insights on how to tackle the broader problem of incident detection within logs?

Esistono due approcci classici a questo problema.

Nel primo approccio, hai un elenco preciso degli incidenti che vuoi segnalare. Per ognuno di questi incidenti, scegli un tipo di "definizione matematica" e un test formale per l'incidente. Molto probabilmente, il tuo dizionario degli incidenti potrebbe evolvere nel tempo. È interessante notare che puoi inserire i rapporti sugli incidenti nel flusso degli eventi che stai analizzando, il che ti dà la possibilità di definire i modelli di incidenti a un livello più alto.

Nel secondo approccio, hai un ampio database di "attività normale" e le tue abilità statistiche sono in buona forma. È quindi definire osservabili numerici (come il tempo che intercorre tra due operazioni, o la tariffa giornaliera di una certa transazione, o qualsiasi altra cosa sembra avere un senso per il vostro problema) e quindi applicare rilevamento valori anomali univariata metodi.

Il primo approccio ti dà l'opportunità di rilevare incidenti noti, il secondo ti dà la possibilità di "vedere che succede qualcosa di strano" bu ti richiederà di guardare cosa sta realmente accadendo.

Molto probabilmente potresti voler utilizzare una combinazione di entrambi gli approcci, ma devi assolutamente analizzare l'importanza e la probabilità di ciascun tipo di incidente prima di escogitare una strategia efficiente.

    
risposta data 06.01.2014 - 16:28
fonte
0

Attualmente la tua query sta tentando di rilevare gli incidenti in base all'euristico "molti eventi di registro avvenuti in una breve finestra di tempo". Per alcune classi di "incidenti", questa potrebbe essere una buona euristica, ma sembra che non sia per te. Non so cosa intendi per "incidente" in questo contesto, ma presumo che tu stia cercando di individuare problemi su un server o qualcosa del genere, ma il

Un approccio migliore consiste nel mettere più informazioni nel registro. Quali informazioni dovrebbero essere specifiche per il tuo dominio problematico. Ad esempio, un modo per aggiungere ulteriori informazioni è aggiungere una colonna {tipo di evento} ai tuoi dati. Quindi potresti avere tipi di eventi come "acquisto riuscito" o "ERRORE" o "transazione cancellata dall'utente" o "ricerca non trovata risultati", o qualsiasi lista di tipi definisce il tipo di eventi che stai cercando di notare. Quindi le tue query possono essere strutturate per includerle e la tua euristica può essere migliorata o forse diventare un algoritmo deterministico.

In generale, decidere cosa registrare e come registrarlo è una funzione di quali domande si desidera chiedere ai registri. Riguarda ciò che ti serve da loro. Quindi, se inizi da quella prospettiva e quindi progetta la registrazione, sarà molto più semplice rispondere a tali domande quando necessario.

    
risposta data 07.12.2013 - 15:16
fonte

Leggi altre domande sui tag