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 ):
|
1 |
sudo apt-get install mysql-server |
Ora non sto a riprendere la configurazione di MySQL in quanto in rete c’è abbastanza documentazione in merito.
Installiamo il programma:
|
1 |
sudo apt-get install pmacct |
Stoppiamo il demone per configurarlo:
|
1 |
sudo /etc/init.d/pmacct stop |
Creiamo il database con la tabella versione 7 che al momento in cui scrivo è l’ultima, se no basta cambiare il numero:
|
1 |
mysql -h host -u root -p < /usr/share/doc/pmacct/sql/pmacct-create-db_v7.mysql |
Impostiamo i permessi standard ( utente pmacct@localhost e password arealsmartpwd ):
|
1 |
mysql -h host -u root -p < /usr/share/doc/pmacct/sql/pmacct-grant-db.mysql |
Cambiamo eventualmente la password:
|
1 |
mysql -h host -u root -p |
|
1 2 3 |
USE pmacct; UPDATE mysql.user SET Password=PASSWORD('nuova-password') WHERE User='pmacct'; FLUSH PRIVILEGES; |
Ora configuriamo il programma:
|
1 |
sudo nano /etc/pmacct/pmacct.conf |
Questo è un esempio di configurazione:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
! pmacctd configuration ! ! ! daemonize: true pidfile: /var/run/pmacctd.pid syslog: daemon ! ! interested in in and outbound traffic aggregate: src_host,dst_host,src_port,dst_port ! on this network pcap_filter: net 192.168.1.0/24 ! on this interface interface: eth0 ! ! storage methods plugins: mysql sql_host: localhost sql_user: pmacct sql_passwd: nuova-password sql_db: pmacct sql_table_version: 7 ! ! refresh the db every 5 minutes sql_refresh_time: 300 ! reduce the size of the insert/update clause sql_optimize_clauses: true ! accumulate values in each row for up to 5 minutes sql_history: 5m ! create new rows on the minute, hour, day boundaries !sql_history_roundoff: mhd sql_history_roundoff: m ! in case of emergency, log to this file sql_recovery_logfile: /var/lib/pmacct/recovery_log ! try to use only INSERT sql_dont_try_update: true |
Ora non ci basta che avviare di nuovo il demone e controllare sul nostro database i record che vengono inseriti.
|
1 |
sudo /etc/init.d/pmacct start |
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:
|
1 |
pmmplay -d -f /var/lib/pmacct/recovery_log -U <utentemysql> -P <passwordmysql> |
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