Criando logs estratégicos com Monolog
O PHP se tornou uma das linguagens mais populares na área de desenvolvimento de aplicações para web e com o tempo diversas bibliotecas de gerenciamento de logs surgiram para melhorar a comunicação do sistema com o desenvolvedor e seus administradores.
Ué, logs para administradores do sistema e não apenas para desenvolvedores?!
A um tempo atrás era comum criarmos logs pensando apenas em quais tipos de informações precisamos registrar para que os desenvolvedores soubessem qual comportamento específico o sistema está realizando. Com o tempo, surgiram bibliotecas como Zend Log e Monolog, capazes de registrar logs em diferentes meios de comunicação mudando um pouco o cenário de logs.
No post de hoje, estarei falando especificamente do Monolog, mas o Zend Log funciona de forma um pouco similar, com a diferença que existem poucos meios de comunicação integrados por padrão na biblioteca.
Entendendo o Monolog
Antes de começarmos a falar de como criar logs estratégicos, é necessário entender o que é o Monolog e alguns conceitos dele. Como o foco desse artigo não é entrar em detalhes da instalação do Monolog(até porque a mesma poderá variar dependendo de qual framework você esteja utilizando em seu projeto), entrarei em detalhes somente dos principais conceitos do mesmo.
Channel
Um channel no Monolog representa um canal de logger, objeto responsável por registrar conteúdo de log. Esse nome não necessariamente é aplicado em todas as frameworks, uma vez que cabe a filosofia da framework adotar se poderá existir múltiplos canais de logger.
Por padrão, a biblioteca não possui um recurso de canais, uma vez para você criar o mesmo sem usar frameworks basta apenas instancias o objeto logger que representaria um canal.
Handler
Um “Handler” é um meio de comunicação nos quais os logs serão registrados. No Monolog existem diversos meios de comunicação além do clássico arquivo de texto, como por exemplo, comunicação com Slack, SMS, E-mail, Telegram, HipChat e muitos outros.
Note que esse é um dos pontos mais importantes em relação a esse artigo.
Processor
Um “Processor” adiciona informações especificas ao seu log, como uso de memória do servidor, qual branch e commit do Git está sendo utilizado, etc.
Formatter
Um “Formatter” formata seu log para um formato especifico, caso queira que suas informações seja registrados por XML, JSON, HTML, etc.
Níveis de log
O Monolog suporta os níveis de registo descritos pela RFC 5424, que resumidamente são os mesmos utilizados no Syslog.
- DEBUG (100): Informações de depuração detalhadas.
- INFO (200): Eventos interessantes. Exemplos: Logs do usuário, logs SQL.
- NOTICE (250): Eventos normais mas significativos.
- WARNING (300): ocorrências excepcionais que não são erros. Exemplos: Uso de APIs depreciadas, uso inadequado de uma API, coisas indesejáveis que não são necessariamente erradas.
- ERROR (400): Erros de tempo de execução que não requerem ação imediata, mas normalmente devem ser registrados e monitorados.
- CRITICAL (500): Condições críticas. Exemplo: componente de aplicativo não disponível, exceção inesperada.
- ALERT (550): A ação deve ser tomada imediatamente. Exemplo: Web site inteiro para baixo, banco de dados não disponível, etc. Isso deve acionar os alertas SMS e acordá-lo.
- EMERGENCY (600): Emergência: o sistema é inutilizável.
No Monolog, cada logger poderá ter múltiplos handlers e cada Handler configurado poderá estar configurado para um nível especifico. Quando um nível é configurado, todos os níveis superiores também são registrados no Handler.
Exemplo: Um Handler de e-mail configurado com o nível ERROR, todos os logs de níveis ERROR, CRITICAL, ALERT e EMERGENCY serão registrados nesse Handler.
Frameworks com suporte
A maioria das frameworks PHP atualmente possuem plugins para Monolog ou já o possuem nativamente embarcado. Abaixo segue a lista de frameworks com suporte ao Monolog.
Arquitetando logs inteligentes
Entendendo como funciona o Monolog, agora é fácil de arquitetar uma estrutura de logs inteligentes.
Suponhamos que seu sistema tem uma equipe de administradores e esses administradores precisam atuar caso o seu sistema “falhe” em determinado aspecto.
Cenário: Durante uma importação de dados de uma planilha Excel a aplicação achou uma informação inesperada e precisou parar seu processo de importação.
Normalmente, em casos como o cenário acima, criamos uma tela no próprio sistema para esse tipo de importação ser monitorada. Mas e se essa importação for muito demorada? Sabemos que o administrador do sistema não ficará atento na mesma tela por muito tempo e em casos como esse, na maioria das vezes é necessário uma atuação rápida, seja para analisar o motivo da falha e solicitar ao cliente uma nova planilha Excel ou simplesmente mandar o sistema tentar importar a mesma planilha novamente. Aumentar a produtividade da equipe que administra seu sistema utilizando apenas logs é muito simples.
Inicialmente, sabemos que para este cenário, temos um serviço de importação dos dados presentes em uma planilha Excel e com isso podemos ter um channel exclusivo para esse serviço.
Sabemos que em casos como esse, existem informações pertinentes apenas a desenvolvedores(podemos utilizar o nível DEBUG ou INFO) e informações pertinentes a administradores do sistema(podemos utilizar o nível ERROR ou ALERT).
Nome que informações pertinentes a desenvolvedores, configuradas no nível DEBUG, receberão informações relacionadas a todos os tipos de logs, uma vez que DEBUG é o nível mais baixo. No caso dos administradores, utilizando ERROR, receberão apenas logs dos níveis mais críticos onde normalmente exigem um monitoramento da situação ou uma tomada de decisão rápida.
Sabemos que o Monolog pode registrar logs em diferentes meios de comunicação, mas é importante ponderar qual meio de comunicação será utilizado para qual tipo de lógica. No cenário acima, podemos utilizar o Handler de RotatingFile para desenvolvedores, onde o log é registrado em arquivo de texto(uma das formas mais rápidas do sistema registrar um log) e o Handler do Telegram para administradores, neste caso, os administradores do sistema receberão logs em seus aplicativos do Telegram.
Note que na estratégia acima estou usando logs por arquivo de texto, onde alguém precisa acessar o servidor e consulta-los para o caso dos desenvolvedores, como também estou enviando apenas logs específicos por Telegram para que os administradores do sistema possam atuar rapidamente em questões especificas.
Exemplo usando o Monolog sem framework
<?phpuse Monolog\Logger;
use Monolog\Handler\RotatingFileHandler;
use Mero\Monolog\Handler\TelegramHandler;$log = new Logger('importacao_excel');
$log->pushHandler(new RotatingFileHandler(__DIR__.'/devel.log', 5, Logger::DEBUG));
$log->pushHandler(new TelegramHandler('TOKEN', 111111, Logger::ERROR));
// Escrevendo log apenas para desenvolvedores
$log->debug('Log no nível DEBUG');
$log->info('Log no nível INFO');
$log->notice('Log no nível NOTICE');
$log->warning('Log no nível WARNING');// Escrevendo log para desenvolvedores e administradores
$log->error('Log no nível ERROR');
$log->critical('Log no nível CRITICAL');
$log->alert('Log no nível ALERT');
$log->emergency('Log no nível EMERGENCY');
