Architettura dei dati per le metriche del registro eventi?

Il mio servizio ha un gran numero di eventi utente in corso e vorremmo fare cose come "contare l'occorrenza del tipo di evento T dalla data D ".

Stiamo cercando di prendere due decisioni di base:

1. Cosa conservare? Memorizzare ogni evento anziché solo gli aggregati

   • (Stile registro eventi) registra ogni evento e contali in seguito, contro
   • (Stile serie storica) memorizza un singolo "conteggio dell'evento E per la data D " aggregato per ogni giorno

2. Dove conservare i dati

   • In un database relazionale (in particolare MySQL)
   • In un database non relazionale (NoSQL)
   • In file di registro flat (raccolti centralmente sulla rete tramite syslog-ng)

Che cos'è la pratica standard / dove posso leggere di più sul confronto tra i diversi tipi di sistemi?

Dettagli aggiuntivi:

• Il flusso totale di eventi è ampio, potenzialmente centinaia di migliaia di voci al giorno
• Ma la nostra attuale necessità è solo quella di contare determinati tipi di eventi al suo interno
• Non abbiamo necessariamente bisogno dell'accesso in tempo reale ai dati grezzi o ai risultati di aggregazione

IMHO, "registra tutti gli eventi in file, esegui la ricerca per indicizzazione in un secondo momento per filtrare e aggregare il flusso" è un modo UNIX piuttosto standard, ma i miei compatrioti di Rails-y sembrano pensare che nulla sia reale a meno che non sia in MySQL.

Dipende sempre, ti darò il mio consiglio per offrirti una nuova prospettiva

Cosa conservare? Memorizzare ogni evento anziché solo gli aggregati

(Stile registro eventi) registra ogni evento e contali in seguito, contro

Se hai intenzione di non perdere alcun dettaglio, anche se ora non sono rilevanti, ai miei occhi è l'approccio migliore, perché a volte, man mano che i risultati arrivano, trovi alcuni altri eventi che per X o Y non erano rilevanti o non hanno fornito alcuna informazione aggiuntiva, ma dopo alcune analisi, lo fa semplicemente, e devi anche tenere traccia di quella, quindi perché è registrata ma non spiegata ci vorrebbe del tempo prima che tu possa aggiungerla all'immagine .

(Stile serie storica) memorizza un singolo "conteggio dell'evento E per la data D" aggregato per ogni giorno

Se vuoi implementarlo e utilizzarlo domani, può funzionare, ma se hai nuovi requisiti o trovi una correlazione con un altro evento che hai omesso per qualsiasi motivo, allora devi aggiungere questo nuovo evento e quindi attendere molto tempo per avere buoni livelli di aggregazione

Dove conservare i dati

In un database relazionale (in particolare MySQL)

La prima opzione può essere pesante per un DB se vai per la registrazione di tutti gli eventi, quindi MySQL temo che possa diventare troppo piccolo, e se vuoi scegliere soluzioni RDBMS potresti pensare in grande, come PostgreSQL o proprietario come Oracle o DB2 .

Ma per l'aggregazione sarebbe una buona scelta, a seconda del carico generato è possibile aggregare nel codice e inserire tali aggregazioni nel DB.

In un database non relazionale (NoSQL)

Se cerchi questa soluzione, devi vedere quale approccio vuoi seguire con una bella lettura su Wikipedia può aiutarti, non posso aiutarti molto su questo argomento perché semplicemente non ho abbastanza esperienza, uso principalmente rdbms.

In file di registro flat (raccolti centralmente sulla rete tramite syslog-ng)

Personalmente ti scoraggio a scegliere quell'opzione, se il file cresce troppo, sarebbe più difficile analizzarlo, ma ancora non conosco lo scopo principale, è seguire un sistema o semplicemente controllare un registro file ...

Spero che sia d'aiuto!

Penso che la tua idea di analizzare i log, contare e archiviare i risultati in un DB sia valida. Non sono sicuro che vorresti comunque tutti quei log grezzi nel DB (penso che sia quello che hai detto che i tuoi compatrioti stanno suggerendo). Hai già i registri nei file, giusto? Potresti semplicemente archiviarli. Suppongo che quel bit dipenda davvero dai tuoi casi d'uso.

Concordo anche con @ Thorbjørn Ravn Andersen sullo spostamento della "risposta di commento" alla domanda.

Dipende dall'uso previsto. Se hai un grafico standard o un rapporto che mostra i valori aggregati, ti consigliamo di filtrare semplicemente gli eventi man mano che arrivano e aggregarli nel bucket appropriato. Se è necessario eseguire il drill-down in eventi specifici o se si ritiene di voler tornare indietro e analizzare nuovamente / riclassificare gli eventi in un secondo momento, è necessario memorizzare i singoli eventi.

Se hai tempo e spazio, ciò che mi piace fare di solito è aggregare i dati, ma archiviare i dettagli in un file (compresso). I dettagli non devono essere facilmente accessibili, dal momento che non ne ho quasi mai bisogno, ma sono disponibili per la rielaborazione in blocco se i criteri di classificazione cambiano.

Qualsiasi decisione sull'architettura dovrebbe essere guidata dalle esigenze aziendali. Nel tuo caso, dovresti avere un'idea più chiara di quali informazioni desideri ottenere dal tuo sistema di registro e per decidere come archiviare, quanto spesso richiederai queste informazioni e quanto tempo puoi aspettare per ottenere il risultato . Questo è ciò che guida la progettazione di raccoglitori di log, correlatori di eventi e applicazioni simili.

Piuttosto che darti la mia opinione, ti suggerisco di guardare alcune applicazioni simili a quelle che cerchi di sviluppare. Alcuni di essi potrebbero essere molto più potenti di ciò che si pretende di sviluppare, ma non farà male se si considerano le politiche di architettura e archiviazione seguite. Dal lato professionale, hai applicazioni SIEM come RSA e Arcsight e nel lato Open Source hai iniziative come Kiwi o OSSIM (che ha anche una versione basata su dispositivi professionali).

Un'altra cosa da considerare è che quando inizi a utilizzare i risultati ottenuti dallo strumento, inizierai a ricevere molto probabilmente molte richieste dalla tua direzione per ulteriori informazioni e una più dettagliata. Quindi ... usalo attentamente e pianifica con la tua vista all'orizzonte. Potrebbe darti più lavoro, ma sicuramente potresti ottenere molto supporto e visibilità (la pressione arriva nel pacchetto) ....