Esto es uno de esos posts que estaban en la recamara, desde casi que empezó el blog, pero con la descontinuación de Urchin por parte de Google, se había quedado ahí.
Como ya sabemos Urchin era una herramienta de Analítica Web, que se basaba en tags, guardando los hits que genera en el tag de javascript para luego procesarlos. Pero con el lanzamiento de AngelFish Stats, el tema vuelve a tener sentido.
Estos sistemas utilizan cookies para el seguiemiento de las visitas, y con el fin de poder acceder a ellas, hay que habilitar en los logs de nuestro servidor que se impriman las cookies que envía el navegador, inflando con ello el tamaño de nuestros logs, dependiendo de las cookies que utilice nuestra web, nos vamos tranquiliamente a un 100% más de espacio que ocupan nuestras, por ejemplo en este blog, he realizado un muestreo y el hecho de imprimir las cookies en los logs , supone un incremento del 85% de media por línea, lo cual si tenemos muchas visitas puede ser un problema.
Tanto Urchin , AngelFish Stats, y otras herramientas, utilizan de forma exclusiva a su beacon ( gif transparente de 1×1 pixeles ), para todos los datos que muestran y el resto de hits para el típico reporte de IT , es decir para ver los códigos de estado, y demás que da la página, que en mi experiencia casi nadie les presta atención.
Por lo tanto no es descabellado el pensar en tan sólo logear estos impactos para reducir de forma considerable el tamaño de nuestros archivos de logs.
SetEnvIf Request_URI "^/__utm.gif" onlylog
LogFormat "%h %v %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\"" urchin
CustomLog /var/log/apache2/access.log urchin env=onlylog
Básicamente estamos fijando un variable llamada onlylog que filtra el parámetro Request_URI por la siguiente expresión regular “^/__utm.gif” , es decir los impactos que empiecen por __utm.gif, que en el caso de Urchin o Google Analytics, son los que necesitaremos para el procesado. Si estuviesemos hablando por ejemplo de AngelFish, utilizaríamos “^/agf.gif” .
Y acto seguimos le decimos a apache que siga esa regla a la hora de generar nuestros logs.
2,4G access_log
233M access_log_filtered
33M access_log_filtered.gz
Como podemos ver simplemente guardando los hits al gif de seguimiento, conseguimos reducir el tamaño de los logs que necesitamos guardar a un 9.5% del log original, y si además lo comprimimos con un simple Gzip, este porcentaje se va al 1.35% .
También conseguiremos, reducir el tiempo de procesado de nuestros perfiles, pues la herramienta no tendrá que analizar todas las lineas que se generarian de forma habitual, consiguendo con ello una mejora que en la mayoria de las situaciones superará el 50% de tiempo de procesado.
access_log 3764983 líneas
access_log_filtered 235680 líneas
Como podemos ver, nuestra herramienta pasará a tener que procesar el 6.3% de las hits que tendría que procesar de forma habitual.
Así que si los reportes de IT, no son imprescindibles para nosotros, esta solución nos ahorrará muchísimo espacio en nuestros sistemas, así como una ahorro de tiempo de procesado en nuestros perfiles, y por supuesto no debemos olvidarnos, que también conseguiremos reducir el I/O que genera nuestro apache hacía el disco duro al tener que escribir muchísimas menos líneas, y al tener que escribir sobre archivos más pequeños.
Imprimir
