Monitoramento e Logging de Aplicações PHP: Como Não Perder um Bug

Sua aplicação está em silêncio? Isso é um mau sinal

Você já descobriu um bug em produção através de um usuário furioso? Se sim, sabe como isso é doloroso. Se não, você teve sorte (por enquanto).

PHP é a linguagem que roda em 78% de todos os sites do mundo. Mas tem uma característica: é silenciosa demais. Por padrão, o PHP simplesmente engole o erro, exibe uma página em branco ou, pior ainda, continua processando dados incorretos. Sem um sistema de monitoramento e logging, você está voando cego.

Neste artigo, vamos mostrar como transformar sua aplicação PHP de uma "caixa preta" em um sistema transparente, onde cada erro, cada requisição lenta e cada ação suspeita são registrados. Vamos nessa!

Por que "echo $error" não é logging?

Muitos desenvolvedores iniciantes escrevem:

try {\n    // algum código\n} catch (Exception $e) {\n    echo $e->getMessage();\n}\n

Isso não é logging. É um grito no vazio. A saída no navegador não é salva, não é estruturada e não oferece nenhuma análise. Logging de verdade é quando você pode:

\n
• Ver o erro 5 minutos depois que ele ocorreu
\n
• Saber em qual servidor e ambiente aconteceu
\n
• Filtrar milhares de registros e encontrar exatamente o que precisa
\n
• Receber uma notificação no Telegram/Slack se algo quebrar
\n

Vamos conhecer as ferramentas que fazem isso.

Monolog — o padrão de facto para PHP

Se você programa em PHP e não usa Monolog, provavelmente está reinventando a roda. Esta biblioteca se tornou o padrão para logging em PHP (sim, Laravel e Symfony a usam internamente).

Instalação e exemplo básico

composer require monolog/monolog\n

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\n\n// Cria um canal de logs\n$log = new Logger('minha_app');\n// Escreve no arquivo /var/log/minha_app.log\n$log->pushHandler(new StreamHandler('/var/log/minha_app.log', Logger::WARNING));\n\n// Usando\n$log->warning('Isto é um aviso');\n$log->error('Erro crítico: banco de dados indisponível');\n

Já está melhor. Mas o Monolog pode muito mais. Você pode enviar logs para diferentes lugares ao mesmo tempo:

\n
• Para um arquivo — para depuração local
\n
• Para o Elasticsearch — para buscas avançadas
\n
• Para o Telegram/Slack — para notificações urgentes
\n
• Para o Syslog — para administração do sistema
\n

Exemplo avançado com múltiplos handlers

<?php\nuse Monolog\\Logger;\nuse Monolog\\Handler\\StreamHandler;\nuse Monolog\\Handler\\TelegramBotHandler;\nuse Monolog\\Handler\\ElasticsearchHandler;\nuse Monolog\\Formatter\\LineFormatter;\n\n$log = new Logger('producao');\n\n// Todos os erros são gravados em arquivo\n$fileHandler = new StreamHandler('/var/log/app.log', Logger::DEBUG);\n$log->pushHandler($fileHandler);\n\n// Erros críticos vão direto para o Telegram\n$telegramHandler = new TelegramBotHandler(\n    'SEU_TOKEN_DO_BOT', \n    'SEU_CHAT_ID', \n    Logger::CRITICAL\n);\n$telegramHandler->setFormatter(new LineFormatter(\n    "[%datetime%] %channel%.%level_name%: %message% %context%\\n"\n));\n$log->pushHandler($telegramHandler);\n\n// Logando\n$log->critical('Banco de dados caiu', ['servidor' => gethostname()]);\n

Agora, se o banco cair durante a noite, você saberá por uma notificação no celular. E não pela manhã, através de um cliente.

Sentry — monitoramento de erros com contexto

O Monolog escreve logs muito bem, mas quando a quantidade de erros aumenta, ler arquivos se torna um pesadelo. É aí que entra o Sentry — um sistema de coleta de erros com interface web.

O Sentry coleta automaticamente:

\n
• O stack trace (pilha de chamadas)
\n
• Os dados da requisição (URL, cabeçalhos, corpo)
\n
• Informações do usuário (se fornecidas)
\n
• O estado das variáveis
\n