apache
Analizzare il traffico dei VirtualHost di Apache con Munin
Prerequisiti
Questo articolo prevede l’uso di Fedora Core 10 con Apache 2 installato e funzionante. Altre distribuzioni potrebbero richiedere la compilazione dei pacchetti che invece su FC10 sono già disponibili.
Installare CBand
Fortunatamente anche per il modulo cband esiste un pacchetto precompilato per FC10 e quindi l’installazione è molto rapida:
sh# yum install mod_cband
Installato il mod_cband aggiungiamo alla definizione di ogni VirtualHost che vogliamo monitorare la configurazione di cband:
<IfModule mod_cband.c> CBandLimit 600G CBandExceededURL http://www.google.com CBandScoreboard /var/run/httpd/cband_scoreboard-#DOMINIO# CBandPeriod 1W </IfModule>
Da notare che ho impostato un limite di 600GB in 1 settimana, che nel mio caso corrisponde praticamente a non limitare, poichè il traffico è molto minore. E’ però necessario imporre un limite (seppur irraggiungibile) per far si che cband conteggi l’utilizzo di banda.
Fatto questo per ogni VH possiamo testare che la configurazione sia corretta, riavviare apache e vedere la pagina delle statistiche di cband:
sh# httpd -t sh# service httpd restart
Aprendo http://localhost/cband-status vedremo una pagina simile a questa:
La pagina delle statistiche di cband
Impostare Classi in Cband
cband permette di definire fino a 3 classi di utenti in base all’IP. Con un po’ di lavoro possiamo quindi identificare i bot dei motori di ricerca, magari tenendo separato google che ci interessa più degli altri, e le classi di IP locali, per evitare che alcune macchine che effettuano richieste automatizzate possano inficiare le statistiche.
Queste sono le mie configurazioni messe in /etc/httpd/conf.d/mod_cband.conf
<CBandClass googlebot_class> CBandClassDst 66.249.64/20 </CBandClass> <CBandClass local_class> CBandClassDst XXX.XXX.XXX.XXX CBandClassDst 127.0.0.1 </CBandClass> <CBandClass bots_class> # Yanga CBandClassDst 91.205.124.3/22 # Exabot CBandClassDst 193.47.80.0/24 # Slurp CBandClassDst 72.30.0.0/16 CBandClassDst 74.6.0.0/16 CBandClassDst 67.195.114.0/24 CBandClassDst 67.195.37.0/24 CBandClassDst 202.160.178.0/20 # Yandex CBandClassDst 77.88.22.0/21 CBandClassDst 93.158.146.0/23 # Jyxobot CBandClassDst 195.113.214.197 # DotBot CBandClassDst 208.115.111.0/24 # libwww-perl CBandClassDst 195.210.89.0/24 # MSN con referrer di ricerca # CBandClassDst 65.55.104.0/21 # Twiceler CBandClassDst 216.129.119.1/24 CBandClassDst 64.1.215.1/24 CBandClassDst 208.36.144.1/24 CBandClassDst 38.99.13.1/24 CBandClassDst 38.99.44.1/24 # AskJeeves CBandClassDst 66.235.124.0/24 # majestic12 CBandClassDst 85.23.64.207 CBandClassDst 212.50.134.32 CBandClassDst 85.16.151.236 CBandClassDst 85.113.244.201 CBandClassDst 68.192.9.221 CBandClassDst 85.178.109.63 # Wikio Feed CBandClassDst 84.55.184.91 # Turnitin CBandClassDst 65.98.224.7 # MSN # CBandClassDst 65.55.208.0/24 # CBandClassDst 65.55.51.0/24 CBandClassDst 65.55.0.0/16 CBandClassDst 219.142.53.0/24 # Gaisbot CBandClassDst 122.147.76.64/28 CBandClassDst 210.66.69.128/26 CBandClassDst 219.87.182.128/27 CBandClassDst 220.228.152.64/27 </CBandClass>
In questo modo il calcolo del traffico avverrà separatamente per “classe”. Potremo conoscere il traffico degli “utenti normali” per differenza, sottraendo dal traffico totale le classi local_class, bots_class, googlebot_class.
Installare Munin
Munin è uno strumento di monitoring con un meccanismo di estendibilità a plugin estremamente semplice ed intuitivo (rispetto a MRTG) che permette di monitorare uno o più server.
Munin si divide infatti in due pacchetti: munin e munin-node.
Mentre munin-node è necessario in ogni server che intendiamo controllare il pacchetto munin serve solamente nella macchina che aggregherà le statistiche per creare dei grafici tramite il noto strumento rrdtool.
Su Fedora Core 10 installare munin è molto semplice:
sh# yum install munin munin-node
Una delle peculiarità di munin è l’autoconfigurazione: i plugin infatti possono verificare l’ambiente in cui sono installati per stabilire se sono “applicabili” all’ambiente o meno. Per verificare l’autoconfigurazione possiamo lanciare questo comando:
sh# munin-node-configure --shell
L’output di questo comando conterrà l’elenco dei comandi da impartire alla shell per installare i plugin che dichiarano la loro compatibilità.
Creare un plugin munin per mod_cband
A questo punto non ci resta che creare un plugin munin che legga la pagina /cband-status e permetta così a munin di visualizzare il grafico degli accessi diviso per vhost.
Questo è un esempio del plugin munin che richiede la pagina e ne estrae i dati:
#!/bin/sh
URL="http://localhost/cband-status?refresh=15&unit=K";
WGET=`which wget`;
WGET_FLAGS="-Yoff";
# Settigs required for autoconf
#%# family=manual
#%# capabilities=autoconf
if [ "$1" = "autoconf" ]; then
echo no
exit 0
fi
if [ "$1" = "config" ]; then
echo 'graph_title CBandwith Usage '
echo 'graph_args -l 0'
echo 'graph_category apache'
echo 'graph_info This graph shows per virtual host traffic from the cband module.'
echo 'graph_vlabel Kbytes per ${graph_period}'
wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td .*http" |sed -e 's^.*http://\(.*\)".*^\1^' | while read site; do
metricname=$(echo $site | sed -e 's/\.//g')
#echo $metricname $site
echo $metricname'.label '$site
echo $metricname'.info Traffic generated on '$site'.'
echo $metricname'.min 0'
echo $metricname'.type DERIVE'
done;
exit 0
fi
if [ -x $WGET ]; then
SITES=$(wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*http" |sed -e 's^.*http://\(.*\)".*^\1^')
$WGET -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*\(color\|http\)" | while read v; do
echo -n $v | sed -e 's^.*http://\(.*\)".*^\1^' | sed -e 's/\.//g'
echo -n '.value '
read v;
echo $v | sed -e 's^.*\/\(.*\)KB.*^\1^'
done;
exit 0
fi
exit 0
E questo è il risultato:
Traffico generato da Google su ogni VHost
I plugin munin che ho creato sono molto spartani ma utili e controllano il traffico totale, quello di google, quello degli altri bots, e il traffico utente (il totale meno i robot e meno la classe locale).
Conclusioni
Il modulo cband, nonostante non più aggiornato dal 2006, non sembra pesare sulle performance e la stabilità di apache2 e dopo un mesetto di utilizzo ne sono soddisfatto.
Dovrei migliorare il plugin configurando meglio le impostazioni dei grafici (usare il min/max/avg, stili di linea differenti.
Troubleshooting
Se cband non vi funziona bene probabilmente si tratta di un problema di ordine di caricamento dei files nella /etc/httpd/conf.d . Questi files vengono caricati in ordine alfabetico, quindi se le definizioni dei virtualhost le avete qui assicuratevi che vengano il ordine alfabetico dopo al mod_cband.conf
Io, per convenzione, li chiamo vh-dominio.conf
Trasloco di siti, propagazione DNS e Reverse Proxy
Lo spostamento di un sito/servizio web da un IP ad un altro può essere molto problematica. I grattacapi principali sono dovuti al tempo di propagazione del DNS, durante il quale i visitatori potrebbero approdare sia sul vecchio che sul nuovo IP in funzione di quale server DNS utilizzano e lo stato della cache.
Per ridurre al minimo questo problema è buona norma ridurre l’expire della cache di un dominio prima di un’operazione di trasloco di questo tipo, ma questa soluzione riduce solo il problema senza rimuoverlo.
Il problema fondamentale consiste nel fatto che a volte non possiamo permetterci che i due servizi su i 2 IP diversi ricevano richieste contemporaneamente perchè queste richieste potrebbero modificare lo stato di entrambi i server creando una divergenza non più sincronizzabile. Basta pensare ad un blog ed il fatto che alcuni utenti potrebbero commentare sul primo IP mentre altri sul secondo, con la conseguente perdita di dati che si avrebbe a transizione completata.
Una soluzione spesso adottata è quella di far rispondere il nuovo (www.dominio.com) sito ad una nuova URL tipo nuovo.dominio.com, sincronizzare il database, modificare la configurazione del webserver per far si che qualunque richiesta a www.dominio.com venga rediretta (302, temporary redirect) a nuovo.dominio.com e poi aggiornare il DNS. Questa soluzione però, oltre a non essere completamente trasparente per l’utente finale, potrebbe creare problemi nel caso in cui l’applicazione che dobbiamo spostare non sia indipendente dal nome. Potremmo infatti avere già dei cookie impostati per quel detterminato l’hostname o potremmo avere dei punti del codice che controllano quale sia l’hostname attuale.
Per questo motivo la mia soluzione preferita è quella di utilizzare un reverse proxy. In pratica si configura il sito nuovo, si sincronizza il db, poi si configura il vecchio non più per fare un redirect ma piuttosto per andare a chiedere la stessa pagina al sito nuovo e fornirla al navigatore.
Per fare questo con apache2 è sufficiente abilitare il mod_proxy in /etc/httpd/conf/httpd.conf togliendo il # dalle due righe:
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so
ed aggiungere al virtualhost che stiamo spostando le seguenti istruzioni:
ProxyRequests Off ProxyPreserveHost On ProxyPass / http://[IP-NUOVO-SERVER]/
Con questa configurazione facciamo sì che le richieste fatte a quel sito vengano gestite non più dal server locale, ma piuttosto apache2 si preoccuperà di andarle a fare sull'[IP-NUOVO-SERVER]. ProxyPreserverHost ci serve così da poter mantenere l’Host nella richiesta e fare in modo che il server di destinazione riceva la richiesta come se l’avesse ricevuta dall’utente originale.
ProxyPass dice che tutte le pagine vengono “girate” al nuovo IP, ma potremmo anche decidere di fare questa operazione solo con alcune sottodirectory.
Esiste però ancora un problema legato a questa tecnica, e cioè che il nuovo server vedrà tutte le richieste venire dall’IP del vecchio server e non conoscerà più l’IP originale. Questo significa che i log avranno l’IP del “proxy” e che alcuni script potrebbero non funzionare bene.
Per questo viene d’aiuto un altro modulo apache chiamato mod_extract_forwarded che permette di estrarre l’IP presente nell’header X-Forwarded-For (aggiunto dal mod_proxy) e sostituirlo al remote address usato da apache.
Se il vostro nuovo server è una fedora core 10, come la mia, allora potete installare il modulo direttamente:
shell# yum install mod_extract_forwarded.i386
Il file di configurazione del modulo è in /etc/httpd/conf.d/mod_extract_forwarded.conf . E’ sufficiente aprirlo e modificare la riga MEFaccept inserendo l’elenco degli IP dei “proxy” fidati:
MEFaccept [IP-VECCHIO-SERVER]
E’ importante specificare questa opzione solo per gli IP dei proxy fidati perchè l’header X-Forwarded-For è un semplice header HTTP e di conseguenza è falsificabile molto semplicemente. Basti pensare che esiste una estensione Firefox che permette di impostare tale header a piacimento.
Ecco fatto, sia i log che tutte le applicazioni mostreranno l’IP originale e non quello del “proxy”.
Pagine
Articoli recenti
Archivi
- Luglio 2009 (1)
- Giugno 2009 (3)
- Maggio 2009 (2)
- Aprile 2009 (8)
- Marzo 2009 (1)