Interpretando os logs de acesso do squid gerados pelo Calamaris

Jean Carlo Faustino <jean@rnp.br>
Thiago Alves da Silva <thiago@rnp.br>

Serviço de Suporte a Operações (SSO)
Rede Nacional de Ensino e Pesquisa

Apresentação
1. Introdução
2. Calamaris
3. Os relatórios do Calamaris
4. Quantificando o uso do serviço
5. Dimensionando os resultados do serviço
6. Dimensionando os resultados de uma hierarquia
7. Considerações finais
Referências bibliográficas

Apresentação

Esse artigo apresenta um roteiro para interpretação dos relatórios gerados pelo aplicativo Calamaris, a partir dos logs de acesso do serviço de cache implementado pelo squid.

Não se trata, porém, de uma análise exaustiva, mas de uma proposta de interpretação voltada para a análise dos resultados da adoção do serviço.

^

1. Introdução

O tratamento dos logs de um aplicativo é um assunto de incontestável importância. Mas, por outro lado, freqüentemente também se constitui numa tarefa sempre trabalhosa. Veja-se, por exemplo, o caso dos logs de acesso de proxy cache gerados pelo squid.

O squid é um aplicativo freeware que possibilita a implementação de um serviço de cache. Porém, como seria possível quantificar o uso desse serviço em número de requisições, bytes e número de clientes? E mais: como medir os resultados obtidos com o servidor local? A resposta evidentemente está na análise dos logs de acesso. Porém, como fazê-lo?

Para análise dos logs do squid, existem diferentes métodos e ferramentas. Uma lista considerável pode ser encontrada no site do próprio squid - em http://www.squid-cache.org/Scripts/. O problema é que algumas dessas soluções tem alguns requisitos - como aplicativos e bibliotecas do sistema - que aumentam consideravelmente o custo de sua adoção, dependendo do sistema operacional do seu servidor.

Portanto, ponderar os custos e benefícios de cada solução é uma questão crucial para a administração de um servidor de cache. Pois nem sempre a solução mais simples de se implementar é aquela que irá fornecer informações consistentes para a análise dos resultados do serviço; ao mesmo tempo em que uma solução muito sofisticada pode trazer uma dificuldade de implementação tal que inviabilizaria a sua adoção e manutenção.

^

2. Calamaris

O calamaris é uma solução razoavelmente simples de se implementar porque trata-se de um script escrito em perl5 - sendo, este, portanto, o seu único requisito de software.

Depois de instalado, basta lhe passar como argumento o arquivo access.log do squid, para se gerar um relatório considerável de informações (ver lista completa em http://cord.de/tools/squid/calamaris/). Esse relatório pode ser gerado tanto em formato texto (ASCII) ou HTML.

A seguir, um exemplo da execução do calamaris para se gerar um relatório em formato texto.

calamaris -a /var/squid/logs/access.log.0 > default.txt

E para se gerar o mesmo relatório em formato HTML, a única coisa que se altera é a inclusão da letra "w" na lista de argumentos:

calamaris -wa /var/squid/logs/access.log.0 > default.html

O calamaris trabalha em princípio com o arquivo access.log, o que significa que os dados de origem têm que estar no formato desse arquivo. Entretanto, os exemplos acima estão fazendo referência ao arquivo access.log.0 - o que, nesse caso, representa um arquivo que foi rotacionado pelo squid através do seguinte comando:

squid -k rotate

O uso desse rotacionamento de log do squid, em combinação com o calamaris, é bastante útil para a finalidade de se analisar comparativamente períodos equivalentes de diferentes servidores - o que normalmente é o caso de uma hierarquia de servidores. Assim, o rotacionamento - por exemplo - semanal dos logs do squid, de diferentes servidores de cache, viabilizará a comparação do uso do serviço num mesmo intervalo de tempo.

Deve-se, contudo, ressaltar que o squid trabalha com um número limitado de arquivos rotacionados, eliminando os mais antigos. Assim, dentro de uma política de preservação dos logs de acesso, deve-se tomar precauções para se preservar os arquivos mais antigos.

^

3. Os relatórios do calamaris

Conforme se mencionou nesse artigo, os relatórios do calamaris são gerados de maneira bastante simples. Quanto às informações fornecidas, elas são bastante completas - e separadas, por temas, em tabelas de dados. Não há nenhum gráfico mas é possível gerá-los a partir dos dados fornecidos por essas tabelas.

Facilitar a conversão desses dados, presentes nessas tabelas do relatório do calamaris, em gráficos é um dos propósitos desse artigo. Obviamente, trata-se de um recorte específico que busca:

• Quantificar o uso do serviço em número de requests, bytes e número de usuários;
• Dimensionar os resultados da adoção de um serviço de cache local;
• Dimensionar os resultados da adoção de uma hierarquia de servidores de cache.

A seguir, cada um desses objetivos será tratado em detalhes.

^

4. Quantificando o uso do serviço

A quantificação do uso do serviço pode ser expressa segundo os seguintes critérios:

• Número de requests, isto é, de solicitações feitas pelos clientes;
• Número de bytes, trafegados entre servidor e clientes como decorrência das solicitações desse último;
• Número de clientes, isto é, de hosts que acessaram o serviço.

A primeira informação (número de requests) pode ser coletada na tabela "incoming requests by method" , no encontro da coluna "Request" com a linha "Sum".

A segunda informação (número de bytes) pode ser coletada também na tabela "incoming requests by method", no encontro da coluna "Byte" com a linha "Sum".

A terceira e última informação (número de hosts clientes) pode ser na tabela "Summary", na linha "unique hosts/users".

Em paralelo à obtenção desses dados, deve-se gerar uma tabela semelhante a que se segue onde as linhas indicam os servidores de cache e as colunas indicam os períodos a serem comparados.

Com base nessa tabela, o Microsoft Excel - por exemplo - pode facilmente gerar um gráfico como o abaixo:

Assim, gerando-se uma tabela para cada tipo de informação acima apontada, se obterá respectivamente três gráficos que auxiliarão a visualizar o dimensionamento da adoção do serviço em termos de número de requests, bytes e clientes.

Contudo, alguns cuidados devem ser tomados durante o processo de obtenção dos dados referentes ao número de bytes, nas tabelas do calamaris, porque eles podem ser informados em bytes, kbytes ou mbytes sendo, portanto, necessário realizar as devidas conversões para torná-los equivalentes.

^

5. Dimensionando os resultados do serviço

O dimensionamento dos resultados do serviço de cache é viabilizado comparando-se o número de MISS com o número de HIT. Pois, enquanto o MISS informa a quantidade de informação que o servidor de cache teve que ir buscar num servidor externo, o HIT informa qual a quantidade de informações que já estava disponível no servidor local.

Assim, contrapondo-se o valor dessas duas variáveis é possível construir um dimensionamento dos resultados do serviço. Essa comparação pode ser feita com base no critério do número de requests ou do número de bytes.

Com base no critério de requests, os dados podem ser coletados na tabela "incoming TCP-requests by status", no encontro da coluna "Request" com as linhas "HIT" e "MISS".

Com base no critério de bytes, os dados podem ser coletados na mesma tabela, no encontro da coluna "Bytes" com as linhas "HIT" e "MISS".

Em paralelo à obtenção desses dados, deve-se gerar uma tabela semelhante a que se segue onde as linhas indicam os servidores de cache e as colunas indicam os valores do HIT e do MISS.

Com base nessa tabela, o Microsoft Excel - por exemplo - pode facilmente gerar um gráfico como o abaixo:

Seguindo esse mesmo modelo, pode-se gerar tanto uma tabela para o número de requests quanto para o número de bytes produzindo, consequentemente, seus respectivos gráficos. Eventualmente essas tabelas e gráficos podem também ser expandidos para se comparar os mesmos valores em diferentes períodos.

Contudo, alguns cuidados devem ser tomados durante o processo de obtenção dos dados referentes ao número de bytes, nas tabelas do calamaris, porque eles podem ser informados em bytes, kbytes ou mbytes sendo, portanto, necessário realizar as devidas conversões para torná-los equivalentes.

^

6. Dimensionando os resultados de uma hierarquia

O dimensionamento dos resultados da hierarquia é viabilizado comparando-se três variáveis: DIRECT, SIBLING e PARENT. O valor dessas variáveis é constituído com base somente naquelas informações que o servidor de cache local foi buscar num servidor externo. Assim, dessas informações que foram pegas fora do servidor:

• o PARENT informa a quantidade obtida de um servidor pai;
• o SIBLING informa a quantidade obtida de um servidor irmão;
• o DIRECT informa a quantidade obtida fora da hierarquia, ou seja, diretamente com o servidor web de origem.

Assim, contrapondo-se o valor dessas três variáveis é possível construir um dimensionamento dos resultados da hierarquia. Essa comparação pode ser feita com base no critério do número de requests ou do número de bytes.

Com base no critério de requests, os dados podem ser coletados na tabela "outgoing requests by status", no encontro da coluna "Request" com as linhas "DIRECT", "HIT on SIBLING or PARENT CACHE" e "FETCH from Parent Cache" - as quais correspondem respectivamente às variáveis DIRECT, SIBLING e PARENT.

Com base no critério de bytes, os dados podem ser coletados na mesma tabela, no encontro da coluna "bytes" com as mesmas linhas do critério anterior.

Em paralelo à obtenção desses dados, deve-se gerar uma tabela semelhante a que se segue, onde as linhas indicam os servidores de cache e as colunas indicam os valores do DIRECT, SIBLING e PARENT.

Com base nessa tabela, o Microsoft Excel - por exemplo - pode facilmente gerar um gráfico como o abaixo:

Seguindo esse mesmo modelo, pode-se gerar tanto uma tabela para o número de requests quanto para o número de bytes produzindo, conseqüentemente, seus respectivos gráficos.

Contudo, alguns cuidados devem ser tomados durante o processo de obtenção dos dados referentes ao número de bytes, nas tabelas do calamaris, porque eles podem ser informados em bytes, kbytes ou mbytes sendo, portanto, necessário realizar as devidas conversões para torná-los equivalentes.

^

7. Considerações finais

Conforme mencionado na apresentação desse artigo, o objetivo aqui não é o de realizar uma comparação exaustiva de todas as possibilidades de análise dos relatórios gerados pelo calamaris. O objetivo aqui foi o de interpretar os dados com a finalidade de:

• Quantificar o uso do serviço;
• Dimensionar os resultados da adoção desse serviço;
• Dimensionar os resultados da adoção de uma hierarquia de cache.

Para dar conta de outras possibilidades, existem outros aplicativos de análise de logs disponíveis a partir da homepage do próprio squid: http://www.squid-cache.org/Scripts. Um dos exemplos, ali presentes, é o software Webalizer. O seu procedimento de instalação é bem mais difícil do que o calamaris mas ele fornece, por exemplo, uma apresentação gráfica do uso - por hora - do serviço.

Mas embora o calamaris não forneça um resultado gráfico tão bom quanto o Webalizer, ele fornece os dados sem os quais não seria possível construir a interpretação exposta nesse artigo. O único problema era que não havia um roteiro para se interpretar os dados que ele gerava, exigindo, portanto, que se recorresse a uma série de documentações de diferentes fontes a fim de se construir um procedimento de interpretação - processo que a elaboração desse artigo, a partir de então, pretende facilitar.

^

Referências bibliográficas

[1] CALAMARIS. Calamaris. Disponível em: <http://calamaris.cord.de/>. Acesso em out. 2002.

[2] JESUS, D. C. S.; PEIXINHO, I. de C.; CARDOSO, R. de L.. Implantando WCCP na Hierarquia de Proxies da RNP. RNP NewsGeneration, vol.5, n.2, 16 mar. 2001. Disponível em:<http://www.rnp.br/newsgen/0103/wccp.shtml>. Acesso em out. 2002.

[3] LUOTONEN, A. Web proxy servers. Prentice-Hall, 1998.

[4] FIELDING, R.; GETTYS, J.; MOGUL, J.; FRYSTYK, H.; MASINTER, L.; LEACH, P.; BERNERS-LEE, T. Hypertext Transfer Protocol -- HTTP/1.1. RFC 2616, jun. 1999. Disponível em: <http://www.ietf.org/rfc/rfc2616.txt?number=2616>. Acesso em out. 2002.

[5] GOLAND, Y.; WHITEHEAD, E.; FAIZI, A.; CARTER, S.; JENSEN, D. HTTP Extensions for Distributed Authoring - WEBDAV. RFC 2518, feb. 1999. Disponível em: <http://www.ietf.org/rfc/rfc2518.txt?number=2518>. Acesso em out. 2002.

[6] WESSELS, D.; CLAFFY, K. Application of Internet Cache Protocol (ICP), version 2. RFC 2187, sep. 1997. Disponível em: <http://www.ietf.org/rfc/rfc2187.txt?number=2187>. Acesso em out. 2002.

[7] WESSELS, D.; CLAFFY, K. Internet Cache Protocol (ICP), version 2. RFC 2186, sep. 1997. Disponível em:<http://www.ietf.org/rfc/rfc2186.txt?number=2186>. Acesso em out. 2002.

[8] SQUID CACHE LOGFILE ANALYSIS SCRIPTS. [Squid Cache Logfile Analysis Scripts]. Disponível em: <http://www.squid-cache.org/Scripts/>. Acesso em out. 2002.

[9] SQUID FREQUENTLY ASKED QUESTIONS: SQUID LOG FILES. 6. Squid Log Files. Disponível em:
<http://www.squid-cache.org/Doc/FAQ/FAQ-6.html>. Acesso em out. 2002.

[10] WATANABE, C. S. Introdução ao Cache de Web . RNP News Generation, vol.4, n.2, 17 mar. 2000. Disponível em: <http://www.rnp.br/newsgen/0003/cache.shtml>. Acesso em out. 2002.

[11] HOME OF THE WEBALIZER. Webalizer: what is your webserver doing today? Disponível em: <http://www.mrunix.net/webalizer/>. Acesso em out. 2002.