Monitorare il traffico di rete con pmacct su Ubuntu
Di sistemi per il monitoraggio della rete ce ne sono molti e ne ho anche provati tanti ( ntop e ulogd per citarne un paio di cui ho anche postato le prove tempo fa ) ma nessuno faceva quello che mi serviva attualmente, ovvero un sistema poco invasivo e discretamente semplice che permettesse di tenere uno storico dell’uso del traffico internet con possibilità di processare i dati anche in seguito a seconda delle esigenze.
Sinceramente non ricordo nemmeno come in mezzo a tanti risultati, articoli e forum vari ho poi sentito nominare un programma che si chiama pmacct di un certo Paolo Lucente, molto grezzamente si tratta di uno sniffer di rete che registra il traffico su MySQL o PostgreSQL o SQLite.
La cosa bizzarra è che è un sistema che ha notevoli potenzialità ma di cui non si trova quasi documentazione o traccia in rete, sembra un prodotto di nicchia.
Innanzi tutto procediamo all’installazione di MySQL se ancora manca ( o PostgreSQL o SQLlite se preferite, io conosco un pelo meglio MySQL e uso questo ):
Ora non sto a riprendere la configurazione di MySQL in quanto in rete c’è abbastanza documentazione in merito.
Installiamo il programma:
Stoppiamo il demone per configurarlo:
Creiamo il database con la tabella versione 7 che al momento in cui scrivo è l’ultima, se no basta cambiare il numero:
Impostiamo i permessi standard ( utente pmacct@localhost e password arealsmartpwd ):
Cambiamo eventualmente la password:
Ora configuriamo il programma:
Questo è un esempio di configurazione:
Ora non ci basta che avviare di nuovo il demone e controllare sul nostro database i record che vengono inseriti.
Aggiornamento: ho notato che su reti diciamo discrete la mole di dati generata influisce notevolmente sulle prestazioni richieste dal server MySQL, ogni tanto è cosigliato spostare i dati storici su una copia della tabella o meglio ancora usare le tabelle compresse e lasciare la principale con solo qualche centinaia di migliaia di record.
Aggiornamento 2: se il traffico è elevato e si usa il raggruppamento è possibile che venga richiesto un server MySQL con alte prestazioni di CPU e di I/O su disco in quanto le istruzioni di UPDATE sono molte, in tal caso ridurre il periodo di raggruppamento ( es. da 30m a 5m ) e usare l’istruzione “sql_dont_try_update: true” che usa la memoria per limitare al massimo le istruzioni di UPDATE, appoggiandosi a versioni InnoDB invece che MyISAM delle tabelle.
Aggiornamento 3: Nel caso servisse recuperare i dati dal file di recupero ( recovery_log ) serve utilizzare il comando pmmplay:
Se serve solo testare cosa c’è nel file senza fare modifiche al DB basta aggiungere il parametro -t.
Sul wiki ufficiale però sconsigliano di utilizzare il file di recupero dicendo che sarà dismesso ma di urilizzare eventualmente un DB di backup:
While planning for a recovery method, consider that the logfile method is being discontinued and you are encouraged to use the backup DB option.
Le fonti da cui ho attinto e dove si trovano molte altre informazioni utili:
http://www.generationip.com/docs/0004/docs-pmacct-howto-bandwidth-analyser.html
http://www.mail-archive.com/pmacct-discussion@pmacct.net/info.html