Conhecendo a estrutura de logs do ZTOOL - Parte 1

Uma das grandes preocupações da equipe de desenvolvimento do ZTOOL é disponibilizá-lo de uma forma que seja possível atender da menor e mais simples, a mais complexa estrutura Zimbra, e isso não é uma tarefa trivial. Manter um serviço de correio com poucos domínios, contas e um pequeno fluxo de e-mails é algo simples. As preocupações basicamente resumem-se a hardware confiável e uma correta configuração do ambiente. Dificilmente em uma estrutura desse porte (até 100 contas por exemplo) serão vistos problemas onde o hardware não será suficiente para o processamento necessário. Por outro lado, existem os ambientes complexos, com volumes e fluxos de dados gigantescos, desafiando os administradores a identificar causas de eventuais gargalos e executarem os ajustes para saná-los, estes ajustes são comumente referenciados como "tunning". O ZTOOL possui diversos parâmetros de tunning que podem ser modificados de uma forma a alterar o seu comportamente de acordo com o ambiente existente. Parâmetros como quantidade de threads, intervalos entre ações e áreas de cache são exemplos de ajustes que influenciarão na performance e carga da estrutura. Para poder fazer uma análise do ambiente de forma a poder tomar as decisões corretas, o administrador precisa ter acesso aos dados de funcionamento do ambiente, nesse artigo mostraremos o esquema de logs providos pelo ZTOOL, logs estes que além de fornecer dados para ajustes de tunning, são uma rica fonte de informação utilizada para resolução de eventuais problemas.

Os logs do ZTOOL são gerados no diretório /var/log/ztool tanto no console ZTOOL quanto nos agentes instalados junto ao ambiente Zimbra. Esta primeira parte do artigo é voltada para o detalhamento dos logs do servidor ZTOOL:

Console ZTOOL

Através da figura 1 podemos ilustrar de uma maneira geral a forma como o daemon manager gerencia os demais e quem é responsável pela geração de cada log.

Figura 1 - Daemon manager com seus sub-daemons e logs gerados

• archiver_webservice.log - Gerado pelo archiver, daemon responsável pela coleta dos e-mails para a auditoria. É possível ver por exemplo o arquivamento de um e-mail (Figura 2).

Figura 2 - Log do daemon archiver mostrando o processo de coleta de uma mensagem.

• certifier_webservice.log - Log do daemon certifier, todas as ações referentes a backup e restore são relatados neste arquivo. Na figura 3 podemos ver um exemplo de procedimento de restore em execução.

Figura 3 - Log do daemon certifier mostrando o processo de restore do diretório de uma conta.

• syncer_webservice.log - Eventos de sincronização entre o ZTOOL e o Zimbra, podemos ver nesse log ações como a criação de um usuário no zimbra após o mesmo ter sido criado na base de dados do ZTOOL (Figura 4). 

Figura 4 - Log do daemon syncer mostrando a atualização de uma conta que foi modificada a partir do console web ZTOOL.

• tracker_webservice.log - Neste log é possível acompanhar todos os eventos internos do Zimbra que são monitorados através do daemon tracker. Através destas informações coletadas o ZTOOL faz a relação entre os dados e seus cabeçalhos, desta forma o ZTOOL consegue por exemplo monitorar ações que são tomadas nos e-mails via Imap por exemplo (figura 5).

Figura 5 - Log do daemon tracker mostrando um e-mail enviado a partir do webmail nativo do Zimbra.

• info_webservice.log - Parâmetros de configuração e classes são disponibilizadas a partir do server para os agentes. Todos os daemons inserem informações neste log a medida que precisam desse tipo de informação. A entrega de uma classe para um agente é apenas uma das várias ações que são registrados neste log (figura 6).

Figura 6 - Log info_webservice.log mostrando o envio de uma classe para um agente

• ztmanager.log - O daemon manager é responsável pela gerência dos demais daemons, determina diversas ações a serem executadas por estes, todo agendamento existente no ZTOOL (expurgo de dados fora da retenção por exemplo) é feito por ele. Na figura 7 podemos verificar o processo de expurgo de mensagens do backup que sairam do período de retenção.

Figura 7 - Daemon manager expurgando dados do backup que sairam do período de retenção.

• manager.out - Não podemos considerar este arquivo como um log no sentido convencional. De fato, este arquivo não cresce de forma incremental, ele é constantemente sobrescrito pelo daemon manager que dá informações em "tempo real" sobre a execução dos demais daemons em execução. A melhor maneira de visualizar seu conteúdo é através do comando  watch -n1 'cat /var/log/ztool/manager.out'   (figura 8).

Figura 8 - Visualiação do arquivo /var/log/ztool/manager.out

As informações estão distribuídas em 3 blocos divididos que são descritos abaixo: 

1 - Informações sobre o manager (figura 9).

Figura 9 - Primeiro bloco da saída do arquivo manager.out

Este bloco refere-se as informações acerca do daemon manager, composto pelas seguintes informações:

1. PID do daemon manager;
2. Versão do PHP em uso;
3. S.O. base para a instância ZTOOL;
4. Data e hora em que o daemon foi carregado;
5. Memória atualmente utilizada pelo daemon;
6. Pico de memória desde a carga;
7. Data e hora do último evento processado.

2 - Informações sobre o processo de comunicação (figura 10). 

Figura 10 - Segundo bloco da saída do arquivo manager.out

Este bloco refere-se as informações acerca do processo responsável pela comunicação (coleta das informações a partir do web-service ou banco de dados). Os dados apresentados são respectivamente:

1. Memória em uso atualmente pelo processo responsável pela comunicação;
2. Data e hora do último evento processado;
3. Descrição do último evento processado.

3 - Informações sobre os demais daemons (figura 11).

Figura 11 - Terceiro bloco da saída do arquivo manager.out

O terceiro e último bloco é composto pelas informações de suas sub-threads organizadas da seguinte forma:

1. Informações do worker conf e do último evento processado por ele;
2. Informações do worker sync e do último evento processado por ele;
3. Informações do worker arch e do último evento processado por ele;
4. Data e hora do último evento processado;
5. Memória em uso por cada worker.

• php-fpm.log e php_errors.log - Arquivo de log do servidor PHP e arquivo com eventuais erros do PHP-FPM;  

Existem ainda, 2 sub-diretórios onde foram alocados os logs específicos da comunicação com dispositivos mobile e com o servidor nginx (responsável por prover a comunicação com os daemons via webservice). A descrição de cada log segue abaixo:

• /var/log/ztool/zmobile - Diretório com os logs de comunicação com dispositivos mobile

• zmobile-error.log - Log dos erros do webservice de sincronização de smartphones;
• zmobile.log - Log do webservice de sincronização de smartphones 

• /var/log/ztool/nginx - Diretório com os logs de comunicação com os demais daemons via web-service

• archiver.access.log  - Histórico de acessos do daemon archiver;
• archiver.error.log - Erros em eonexões do daemon archiver;
• certifier.access.log  - Histórico de acessos do daemon certifier;
• certifier.error.log - Erros em eonexões do daemon certifier;
• syncer.access.log - Histórico de acessos do daemon syncer;
• syncer.error.log - Erros em eonexões do daemon syncer;
• tracker.access.log - Histórico de acessos do daemon tracker;
• tracker.error.log -  Erros em eonexões do daemon tracker;
• zweb.access.log - Histórico de acessos no frontend web; 
• zweb.error.log - Erros em eonexões no frontend web;
• info.access.log - Histórico de acessos de conexões para trocar de informações;
• info.error.log - Erros em eonexões de conexões para trocar de informações; 
• error.log -

Com isso finalizamos a primeira parte deste artigo, na segunda parte iremos detalhar os logs do agente ZTOOL.