Logs para gerar views

[GoogleCodeExporter]

Gostaríamos de registar estatísticas de acesso aos recursos. Uma solução 
poderá ser feita no front-end, ou seja, no Drupal. Mas é também interessante 
que esta possa ser feita ao nível dos Webservices (a ver questões com 
redundância). Desta forma poderíamos contabilizar os acessos provenientes de 
outros clientes como GleamViz ou SimpleEMClient

Como forma de penalizar o menos possível a performance do site. Sugere-se o 
recurso aos logs de acesso, guardar a Data da ultima actualização dos logs e 
da última views.
O processo correria periodicamente e incrementalmente e os dados poderiam ficar 
registos no recurso, correndo em paralelo com os serviços não carregando o 
processo de visualização. 

- visualizações de data x a data y

Original issue reported on code.google.com by graca.pa...@gmail.com on 26 Nov 2012 at 11:30

[GoogleCodeExporter]

Problema Views:

Exemplo dados.gov.pt

Este link apresenta os metadados
http://www.dados.gov.pt/PT/CatalogoDados/Dados.aspx?name=Alunos20072008
Este link apresenta os dados feed Atom em XML:
http://dadosgovdataservice.cloudapp.net/v1/gepe/Alunos20072008

Após a consulta destes dois urls, se notarmos as "views" foram incrementadas 
em 2. Isto significa que estão a incrementar cada vez que acedem aos dados.

O nosso caso é diferente.
Pergunta: O que deverá despoletar o incremento? Ver os metadados? Ver os 
dados? Os dois?

Para a contabilização, seguindo a sugestão do prof. Mário e usando os logs:

cat /var/log/httpd/access_log|grep rawfetch
10.121.25.XX - Public [05/Dec/2012:17:29:40 +0000] "GET 
/rawfetch/pid/empid:816/datastream/EM HTTP/1.0" 404 228 "-" "Drupal 
(+http://drupal.org/)"
10.121.95.XXX - NonPublic [06/Dec/2012:16:02:30 +0000] "GET 
/rawfetch/pid/empid:719/datastream/EM HTTP/1.0" 200 4255 "-" "Drupal 
(+http://drupal.org/)"
10.121.95.XXX - NonPublic [06/Dec/2012:16:13:17 +0000] "GET 
/rawfetch/pid/empid:619/datastream/EM HTTP/1.0" 200 6126 "-" "Drupal 
(+http://drupal.org/)"

Levanta-se um problema... a Cache Drupal
Por cada rawfetch, por uma questão de performance, estamos a pedir ao Drupal 
para fazer cache de recursos. Isto resulta em menos pedidos à API, logo, não 
dão entrada nos logs. Para contornar, poderia passar por se ter um pedido 
assíncrono, algo semelhante ao google analytics, em Javascript no Front-end. 
Desta forma penalizava-se o menos possível a infraestrutura e o tempo de 
resposta.
O pedido assíncrono seria para um WS dummy, serviria apenas para ficar 
registado no access.log.
Ainda assim seria necessário salvaguardar pedidos duplicados. Haveria pelo 
menos 1 por cada recurso cujo pedido tenha sido feito no front-end.

Tendo tudo no Access Log, seria necessário correr um comando periodicamente, 
possivelmente, na altura em que o access.log passa para access.log.1, ou seja, 
na passagem para histórico, que registasse estes logs.

Solução BD:
. Numa base de dados interna poderiamos criar uma tabela para registar o log:
views_logs (ip, date_time, user, resource)

e Views - MySQL 5.0.1 (http://dev.mysql.com/doc/refman/5.0/en/create-view.html):
total_views_day (day_date, resource, total)
total_views_month (month_date, resource, total)
total_views (resource, total)

Seria necessário criar um webservice para obter as views do recurso, e que 
force uma re-indexação dos metadados no Solr.

Solução Fedora:
. Num novo datastream, exemplo: statistics, guardar um XML com os dados da 
visualização
data hora, user. Este datastream estaria associado a cada recurso 
respetivamente.
No processo de indexação do recurso, seria necessário indexar também o 
total deste novo datastream. Bem como em cada execução, re-indexar o(s) 
recurso(s).

Original comment by graca.pa...@gmail.com on 6 Dec 2012 at 4:48

[GoogleCodeExporter]

Esta instrução devolve o número total de acessos pelo rawfetch a cada 
recurso:
grep "/rawfetch/pid/" /var/log/httpd/access_log|grep " 200 "|grep "GET "|awk 
-F" " '{print $7}'|awk -F"/" '{print $4}'|sort -n |uniq -c|sort -n

Ou apenas todos os que são EM:
grep "/rawfetch/pid/.*/EM" /var/log/httpd/access_log|grep " 200 "|grep "GET 
"|awk -F" " '{print $7}'|awk -F"/" '{print $4}'|sort -n |uniq -c|sort -n

Original comment by graca.pa...@gmail.com on 11 Dec 2012 at 4:31

[GoogleCodeExporter]

E uma instrução como esta poderá chamar um comando para registar o total dos 
vários acessos:

#!/bin/bash
# Usage

temp_file="/tmp/pids_access.txt"

rm $temp_file
grep "/rawfetch/pid/.*/EM" /var/log/httpd/access_log|grep " 200 "|grep "GET 
"|awk -F" " '{print $7}'|awk -F"/" '{print $4}'|sort -n |uniq -c|sort -n >> 
$temp_file

while read LINE
do
    printf "_wget http://localhost/access/increment/pid/%s/access/%s\n" $LINE
done < $temp_file

Original comment by graca.pa...@gmail.com on 11 Dec 2012 at 5:58

[GoogleCodeExporter]

Com a ajuda do Tiago, agora corrigido (os args estavam trocados):
----------------------------------------------------------------
#!/bin/bash

#temporary file path
temp_file="/tmp/pids_access.txt"

#remove temporary file
rm $temp_file

#create temporary file from access.log file filtered by all rawfetch calls
#with success code - 200
#it will result in a file containing number of accesses and their respective 
empids 
grep "/rawfetch/pid/.*/EM" /var/log/httpd/access_log|grep " 200 "|grep "GET 
"|awk -F" " '{print $7}'|awk -F"/" '{print $4}'|sort -n |uniq -c|sort -n >> 
$temp_file

while read LINE
do
   #get empid
   temp_pid=`echo $LINE | cut -d' ' -f2`
   #get number
   temp_num=`echo $LINE | cut -d' ' -f1`
   printf "_wget http://localhost/access/increment/pid/$temp_pid/access/$temp_num\n"
done < $temp_file

Original comment by graca.pa...@gmail.com on 12 Dec 2012 at 12:33

• Changed state: Started

[GoogleCodeExporter]

Uma funcionalidade foi implementada no front-end, com recurso para recolher as 
views do front-end

Original comment by graca.pa...@gmail.com on 10 Jan 2013 at 2:38

• Changed state: Fixed