Логирование — штука, про которую все вспоминают, когда уже горит прод. В PHP вариантов море: от error_log() до Monolog и syslog. Но вопрос не в том, куда писать, а в том, как потом это читать.
Если у тебя нет логов — у тебя нет приложения. А если логи есть, но их никто не читает — это то же самое. В PHP можно логировать как угодно: в файлы, базу, syslog, через сторонние сервисы. Но дальше начинается ад: файлы пухнут до гигабайтов, базы захлебываются, а syslog пишет всё подряд, пока DevOps не придёт и не отрежет тебе руки.
Вариант №1. Колхозный: error_log() и ручка в файл
Классика жанра:
function logMessage($message) {
$logFile = __DIR__ . '/application.log';
$timestamp = date('Y-m-d H:i:s');
$logEntry = "{$timestamp} - {$message}\n";
error_log($logEntry, 3, $logFile);
}
Вроде работает. Но через месяц файл вырастает на пару гигабайтов, и ты с ужасом открываешь его в vim. А там миллион одинаковых строк «User logged in». Поздравляю, у тебя теперь кладбище строк, а не логи.
Вариант №2. Человеческий: Monolog
Monolog — стандарт де-факто. Ставишь:
composer require monolog/monolog
Пример:
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
$logger = new Logger('my_app');
$logger->pushHandler(new StreamHandler(__DIR__.'/application.log', Logger::DEBUG));
$logger->info('Приложение запущено');
Красота: уровни логирования (info, warning, error), разные хендлеры (файл, база, Slack, почта, хоть Telegram). Можно разделять логи на «боевые» и «отладочные», можно писать в несколько мест сразу.
Минус — если не настроить ротацию логов (logrotate или хендлеры Monolog), через пару месяцев у тебя будет тот же жирный файл на 10 ГБ.
Вариант №3. Системный: syslog
Если у тебя нормальный сервер, а не shared-hosting 2008 года, можно писать в syslog:
openlog('my_app', LOG_PID, LOG_USER);
syslog(LOG_INFO, 'Приложение запущено');
closelog();
Плюс: всё централизовано, можно собрать логи с десятка серверов в одно место. Минус: если админы не настроили фильтрацию — твои записи утонут в море сообщений от ядра и демонов.
Вариант №4. Продвинутый: ELK, Graylog, Loki
Реально рабочий вариант для продакшена — писать логи в централизованный сервис. PHP → Monolog → отправка в Elasticsearch или Loki → красивая панелька Kibana/Grafana.
Плюсы: поиск, фильтры, алерты.
Минусы: тебе придётся дружить с DevOps и объяснять, зачем у тебя миллион debug-логов про «User clicked button».
Подводные камни
- Нет ротации — нет жизни. Файлы растут безлимитно.
- Базы для логов — зло. Через месяц у тебя таблица на 50 млн строк, и SELECT тормозит так, что проще молиться.
- Лог ≠ print_r. Если ты пишешь в лог дампы массивов по 10К строк — ты враг сам себе.
- Не логируй пароли. Да, люди так делают. А потом выкладывают логи на pastebin.
Вывод
Логи — это не «куда писать», а «как читать». Если у тебя pet-project — хватит error_log(). Если прод — бери Monolog и сразу думай про ротацию и сбор в нормальный сервис (ELK, Loki). Главное правило: лог должен помогать тебе чинить баги, а не быть ещё одной проблемой.
0 комментариев