Architettura dei dati per le metriche del registro degli eventi?

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

What to store? Storing every event vs. only storing aggregates

(Event log style) log every event and count them later, vs.

Se hai intenzione di non perdere nessun dettaglio, anche se ora non sono rilevanti, ai miei occhi questo è l'approccio migliore, perché a volte, quando i risultati arrivano, trovi altri eventi che per X o Y loro non erano rilevanti, o non hanno portato alcuna informazione in più, ma dopo qualche analisi, semplicemente lo fa, e devi anche tenerne traccia, quindi perché è stato registrato ma non conteggiato, ci vorrà del tempo prima che tu possa aggiungerlo alla foto.

(Time-series style) store a single aggregated "count of event E for date D" for every day

Se vuoi implementarlo e usarlo domani, può funzionare, ma se hai nuovi requisiti o trovi una correlazione con un altro evento che hai omesso per qualsiasi motivo, devi aggiungere questo nuovo evento e quindi aspetta un po 'di tempo per avere dei bei livelli di aggregazione

Where to store the data

In a relational database (particularly MySQL)

La prima opzione può essere pesante per un DB se si va a registrare tutti gli eventi, quindi MySQL temo che possa diventare troppo piccolo, e se si vuole andare per le soluzioni RDBMS si potrebbe pensare più 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 a non-relational (NoSQL) database

Se cerchi questa soluzione, devi vedere quale approccio vuoi seguire con simpatia leggere su wikipedia può aiutare tu, io non posso aiutarti molto su quell'argomento perché semplicemente non ho abbastanza esperienza, per lo più uso rdbms.

In flat log files (collected centrally over the network via syslog-ng)

Personalmente ti scoraggio a scegliere questa opzione, se il file cresce troppo, sarebbe più difficile da analizzare, ma ancora non conosco lo scopo principale, è seguire un sistema, o semplicemente controlla un file di registro ...

Spero che ti aiuti!

Penso che la tua idea di analizzare i log, contare e memorizzare i risultati in un DB sia valida. Non sono sicuro che vorrai tutti quei log grezzi nel DB comunque (penso che sia quello che hai detto che i tuoi compatrioti stanno suggerendo). Hai già i log in file, corretto? Potresti semplicemente archiviarli. Suppongo che il bit dipenda davvero dal / dai tuo caso / i.

Concorda anche con @ Thorbjørn Ravn Andersen sul trasferimento della "risposta commentata" alla domanda.

Dipende dall'uso previsto. Se si dispone di un grafico standard o di un report che mostra valori aggregati, è necessario filtrare semplicemente gli eventi mentre arrivano e aggregarli nel bucket appropriato. Se hai bisogno di approfondire gli eventi specifici, o se pensi di voler tornare indietro e rianalizzare / ri-categorizzare gli eventi in un secondo momento, dovresti memorizzare i singoli eventi.

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

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

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

Un'altra cosa da considerare è che quando inizi a utilizzare i risultati ottenuti dallo strumento, inizierai a ricevere molto probabilmente molte richieste dalla tua gestione per ulteriori informazioni e una più dettagliata. Quindi ... usalo con attenzione 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) ....