Розробка модуля логування для 1С-Бітрікс за PSR-3

Розробка модуля логування 1С-Бітрікс

Розбір інциденту на продакшні без нормальних логів — заняття болісне. Стандартний \Bitrix\Main\Diag\Debug::writeToFile() пише у плоский файл без структури, без рівнів, без ротації. За тиждень роботи — файл на 2 ГБ, який неможливо ні проаналізувати, ні знайти потрібний запис. Ми пропонуємо модуль логування, який вирішує цю проблему системно. Він записує структуровані записи в БД, використовує рівні severity, теги, контекст, ротацію та пошук через адміністративний інтерфейс. Це скорочує час пошуку помилок з годин до хвилин. Отримайте консультацію щодо впровадження модуля логування у вашому проєкті.

Чому стандартний логер Бітрікса не підходить?

Debug::writeToFile() змішує в одному файлі всі події: налагоджувальні, інформаційні та критичні. Немає ротації — файл зростає до десятків гігабайт. Немає пошуку — доводиться використовувати grep по величезному файлу. Немає рівнів — неможливо відфільтрувати лише помилки. Все це перетворює налагодження на ворожіння. Наш модуль вирішує ці недоліки з коробки: структуровані записи в ORM, рівні PSR-3, розділення за каналами, ротація, пошук.

Як модуль логування прискорює налагодження?

Модуль реалізує PSR-3 — це промисловий стандарт логування. Ви отримуєте єдиний інтерфейс для всіх компонентів системи. Час пошуку конкретної помилки скорочується в 10 разів порівняно з плоским файлом. Алерти в Telegram/Slack при критичних помилках дозволяють реагувати миттєво.

Архітектура

Модуль vendor.logger реалізує інтерфейс PSR-3 (Psr\Log\LoggerInterface), що дозволяє підключати його до будь-яких бібліотек, які підтримують PSR-3: Guzzle, Doctrine, Symfony.

Таблиці ORM:

• b_vendor_log_entry — записи логу: id, level (debug/info/notice/warning/error/critical/alert/emergency), channel, message, context (JSON), extra (JSON), created_at, user_id, request_uri, ip
• b_vendor_log_channel — канали: id, code, name, min_level, handlers (JSON), is_active
• b_vendor_log_archive — архівовані записи (після ротації): аналогічна структура + archived_at

Реалізація PSR-3

class BitrixLogger extends \Psr\Log\AbstractLogger { private string $channel; public function __construct(string $channel = 'app') { $this->channel = $channel; } public function log($level, $message, array $context = []): void { if (!$this->isLevelEnabled($level)) { return; } $extra = [ 'user_id' => $GLOBALS['USER']?->GetID(), 'request_uri' => $_SERVER['REQUEST_URI'] ?? '', 'ip' => $_SERVER['REMOTE_ADDR'] ?? '', ]; LogEntryTable::add([ 'LEVEL' => $level, 'CHANNEL' => $this->channel, 'MESSAGE' => $this->interpolate($message, $context), 'CONTEXT' => $context, 'EXTRA' => $extra, ]); } private function interpolate(string $message, array $context): string { $replace = []; foreach ($context as $key => $val) { $replace['{' . $key . '}'] = is_scalar($val) ? $val : json_encode($val, JSON_UNESCAPED_UNICODE); } return strtr($message, $replace); } } 

Використання в коді

$logger = new \Vendor\Logger\BitrixLogger('payment'); $logger->info('Ініційовано платіж', ['order_id' => 42, 'sum' => 1500.00, 'gateway' => 'sberbank']); $logger->error('Помилка платіжного шлюзу', ['order_id' => 42, 'response' => $gatewayResponse]); // Глобальний логер через фасад \Vendor\Logger\Log::channel('sync')->warning('Синхронізація з 1С: товар не знайдено', ['xml_id' => 'ABC-123']); 

Обробники (Handlers)

Запис у БД — не єдиний обробник. Модуль підтримує кілька хендлерів на один канал:

• DatabaseHandler — запис у b_vendor_log_entry (основний)
• FileHandler — запис у файл з автоматичною ротацією (щоденно, максимум N файлів)
• SlackHandler — відправка critical/emergency у Slack-канал через Webhook
• TelegramHandler — відправка алертів у Telegram-бот при рівні >= error

Конфігурація каналів зберігається в b_vendor_log_channel у полі handlers (JSON). Приклад:

{ "handlers": [ {"type": "database", "min_level": "debug"}, {"type": "telegram", "min_level": "error", "chat_id": "-100123456789"} ] } 

Ротація та архівація

Агент ротації запускається раз на добу:

// Записам старше 30 днів — перенесення в b_vendor_log_archive // Записам старше 90 днів в архіві — видалення // Параметри налаштовуються в адміністративному інтерфейсі модуля \Vendor\Logger\RotationAgent::run(); 

Перенесення виконується батчами по 1000 записів, щоб не блокувати таблицю на довгий час.

Перехоплення помилок PHP

Модуль може реєструвати глобальний обробник помилок PHP:

set_error_handler(function($errno, $errstr, $errfile, $errline) { $level = ErrorLevelMapper::toLogLevel($errno); \Vendor\Logger\Log::channel('php')->log($level, $errstr, [ 'file' => $errfile, 'line' => $errline, 'errno' => $errno, ]); return false; // Стандартний обробник Бітрікса теж спрацьовує }); set_exception_handler(function(\Throwable $e) { \Vendor\Logger\Log::channel('php')->critical($e->getMessage(), [ 'exception' => get_class($e), 'file' => $e->getFile(), 'line' => $e->getLine(), 'trace' => $e->getTraceAsString(), ]); }); 

Адміністративний інтерфейс

Пошук за логами — основний інструмент при налагодженні:

• Фільтрація за рівнем, каналом, датою, IP, користувачем, текстом повідомлення
• Пошук за контекстом (JSON-поле через PostgreSQL @> або LIKE по serialized)
• Детальний перегляд запису: повний контекст, стек викликів, заголовки запиту
• Статистика: топ помилок за період, динаміка за рівнями, розбивка за каналами
• Управління конфігурацією каналів та обробників

Що входить у розробку модуля?

• Проєктування структури таблиць ORM під ваші завдання
• Реалізація PSR-3-сумісного логера
• Налаштування обробників (БД, файл, Slack, Telegram)
• Розробка агента ротації та архівації
• Підключення глобального перехоплення помилок PHP
• Створення адміністративного інтерфейсу з пошуком та статистикою
• Інтеграція з існуючим кодом (заміна викликів AddMessage2Log)
• Документація з експлуатації та інструкція для розробників
• Тестування на тестовому полігоні перед викаткою на продакшн

Ми гарантуємо роботу модуля на стабільній кодовій базі без сюрпризів. Спираючись на 10-річний досвід розробки на Бітрікс, ми створюємо рішення, які працюють передбачувано. Докладніше про PSR-3.

Строки розробки

Разом: від 8 робочих днів. Замовте модуль логування під ключ — і забудьте про ручний парсинг логів. Зв'яжіться з нами для оцінки вашого проєкту.