Inserindo logs com Laravel 5.6 e Loggly

Esse texto é uma tradução livre do artigo Logging with Laravel 5.6 and Loggly de Matthew.

Quando criamos um site é importante saber o que está funcionando, e principalmente, o que não está. É nesse ponto que usar logs é importante. Sim, logar é uma arte algumas vezes esquecida. Mas, como disse Guillaume da Logmatic com toda a razão, “Logs do PHP em particular NÃO SÃO APENAS DE ERROS”. Ele enfatiza esse ponto no texto, e por uma boa razão. Os logs são úteis também para sabermos o que está funcionando. Eu tive esse post do Guillaume como inspiração, e decide fazer esse falando de como logar no Laravel 5.6 com outra ferramenta de logs(desculpa Logmatic, não é você), chamada Loggly.

Objetivos

• Usar o Laravel 5.6 e não mexer em nenhuma parte do core code;
• Usar a função nativa de log do Laravel;
• Capturar erros e informações e colocá-lo em um arquivo de log local;
• Também enviar todos os logs para uma ferramenta de monitoramento gratuita para uma melhor análise;
• Garantir que os arquivos de log locais sejam limpos rotineiramente;
• Garantir que o aplicativo possa me fazer uma xícara de chá.

Eu não acho que esse último objetivo será alcançado, mas espero que dê tudo certo com o resto.

Por que Loggly?

Primeiro e acima de tudo, é grátis, pelo menos para a quantidade que farei uso para este aplicativo. Existem outras ferramentas, e talvez até algumas outras melhores. O Sentry parece muito bom, embora seu uso seja mais voltado para a captura de erros do que de log. Loggly tem uma interface simples para ver os erros e logs que estão vindo da sua aplicação, e já existe um drive do Loggly feito através do pacote do Monolog, que é exatamente o pacote usado pelo Laravel.

Por que Laravel 5.6?

Por que é animal! Mais especificamente, estou escrevendo isso após ter lido outro tutorial de como fazê-lo(incluindo a documentação do Loggly, presente em seu próprio site) apenas no Laravel 5.5 e versões anteriores. Eu usei seu código e minha aplicação lançou um erro. E não, o Loggly não registrou esse erro. Então, se você está usando o Laravel 5.6 e está recebendo um erro com a função configureMonologUsing(), você precisa conferir o guia de atualização do Laravel 5.6, e seguir suas instruções.

Composer

Vamos garantir que você esteja usando a versão mais nova do Monolog.

composer require monolog/monolog

Fácil, fácil.

Integrando com o Loggly

Agora vamos abrir o arquivo config/services.php e adicionar a parte abaixo no array:

Estamos substituindo qualquer espaço por underscore, então o Loggly aceitará a propriedade. Você também perceberá existe um conjunto de parâmetros nesse arquivo, então adicione o seguinte item ao seu .env:

LOGGLY_KEY=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx

Claro que você precisará de uma chave de acesso. Se você ainda não a tem, crie uma conta na Loggly, faça login e vá para Source Setup > Customer Tokens e obtenha seu token.

O item tag no array acima define como o Loggly identificará sua aplicação. Você pode adicionar diversas origens para uma mesma conta, se você desejar, e a tag é o que identifica de onde veio esse log. Incluímos uma referência ao ambiente para diferenciar meus testes locais da produção.

Agora precisaremos informar ao Laravel como inserir os logs no Loggly, e é nessa parte que o processo é diferente do Laravel 5.5. Ao invés de chamar $app->configureMonologUsing(), precisamos configurar uma classe customizado de log. Para ser honesto, parece mais trabalhoso. Eu prefiro o design pattern utilizado aqui. Criaremos o seguinte arquivo com o código abaixo /app/Loggin/LogglyLogger.php:

O código apresentado diz ao Laravel que logs com níveis acima de INFO(o que é praticamente tudo), serão tratados pelo Loggly. Perceba que estamos setando uma tag usando o que foi definido em config/services.php. Agora, tudo que precisamos é fazer é dizer ao Laravel para usá-lo. Vamos abrir /config/logging.php e adicionar o código abaixo ao array:

A channel stacké útil pois significa que podemos mandar nossos logs para mais de 1 canal, o que é exatamente que estamos fazendo nesse caso. Nós desejamos salvar o log local, mas também enviá-lo ao Loggly. Eu sei 'channels=> ['custom' => 'daily']. Você verá que também vinculei essa classe personalizada que criamos.

Com tudo isso configurado, será o que você precisará. Abra seu aplicativo e gere um erro, e ele deverá aparecer no Loggly. Você também deverá encontrar esse erro em storage/logs.

Mais logs

Como eu disse (ou mencionei?) no começo, logs não são apenas para erros. Lembre-se que você pode (e deve) incluir logs de informações úteis de qualquer parte do seu código. Por exemplo, você pode querer logar a quantidade de vezes que o processo de autenticação respondeu 200, ou talvez outra interação. Pense desse modo — se alguém vier a você, descrevendo um problema e você precisar encontrá-lo(track), que informações você precisará? Crie um log disso.

Log::info('User login successful', ['user_id' => $user->id])

GDPR

Uma consideração importante é que logs talvez contenham Informações de Identificação Pessoal(Personally Identifiable Information). De acordo com os regulamentos do GDPR que entraram em vigor em maio de 2018, vale a pena verificar se tratamos esses registros com cuidado.

Um princípio do GDPR é “não armazene I.I.P(P.I.I), a menos que você precise”. Portanto não logue absolutamente nada disso. Deixe anônima essas informações, se possível.

Como você pode ver no meu código acima, eu inseri o ID do usuário, mas não detalhes de login. NUNCA armazene senhas. Uma dica de ouro é: quão embaraçoso/custoso seria se armazenassem seus registros?

Outra dica é, nunca mantenha I.I.P(P.I.I) por tempo desnecessário. Como você define o tempo necessário, aí você tem que debater com seu time, mas isso provavelmente depende do seu aplicativo e do contexto do log. Eu configurei meu aplicativo para armazenar meus dogs diariamente em arquivos separados, ao invés de deixá-los em um único arquivo. A biblioteca Monolog vem com seu próprio meio de reter logs, então podemos simplesmente adicionar a linha abaixo ao arquivo /config/app.php, e com isso os arquivos dos logs serão mantidos por 5 dias:

'log_max_files' => 5

A própria Loggly também está nos assegura que o GDPR é importante para eles também. Atualmente, eles têm uma declaração sobre sua política de privacidade sobre seu compromisso com o GDPR. Não nos dá muitos detalhes, mas tenha certeza que seus dados estão seguros, e em mãos confiáveis, e se você precisar fazer perguntas específicas a eles sobre como e onde suas dados são armazenados, eles terão prazer em lhe ajudar.

Resumo

Laravel e Loggly são incríveis. Integrá-los é relativamente simples. Você pode (e deve) logar os eventos de seus usuários, assim como os erros.

Você pode deixar as pessoas do GDPR felizes apenas registrando o que você precisa, e excluir quando não for mais útil.