На странице Журнал ошибок PHP (Настройки > Производительность > Ошибки PHP (N)) можно просмотреть журнал регистрации ошибок PHP, где N — общее количество ошибок.
Примечание: Данная страница отображается, только если в настройках модуля Монитор производительности указана опция Вести журнал предупреждений PHP.
Фильтр
Форма фильтра используется для фильтрации записей журнала в соответствии с указанными условиями. Нижеследующая таблица описывает параметры, по которым могут выбираться записи.
| Поле | Описание |
|---|---|
| Найти | Позволяет найти записи об ошибках по их основным параметрам. Это поле присутствует, даже если фильтр свернут. |
| Хит | Позволяет найти записи по идентификатору хита. |
| Класс ошибки | Позволяет осуществлять поиск в журнале по классу (типу) ошибок. |
| Файл | Позволяет осуществлять поиск в журнале по файлу, в котором произошла ошибка. |
| Текст | Позволяет осуществлять поиск в журнале по тексту ошибки. |
Чтобы отфильтровать ошибки по заданным критериям поиска, нажмите кнопку Найти. Для отображения всех ошибок нажмите кнопку Отменить.
Контекстная панель
| Кнопка | Описание |
|---|---|
| Группировка | Позволяет задать способ группировки записей об ошибках в журнале:
|
| Настроить | Переход к диалогу настройки внешнего вида отчетной формы. |
| Excel | Экспорт данных из отображаемой таблицы в MS Excel. |
Ошибки PHP
| Поле | Описание |
|---|---|
| ID | Идентификатор записи об ошибке в журнале. |
| Хит | Идентификатор хита. |
| Класс ошибки | Класс (тип) ошибки. |
| Файл | Путь к файлу в системе, в котором произошла ошибка. |
| Строка | Номер строки в файле. |
| Текст | Текст ошибки. |
© «Битрикс», 2001-2023, «1С-Битрикс», 2023
Наверх
Какие именно ошибки вы хотите отслеживать?
Дебаг в файл:
Существует возможность записывать в отдельный отладочный файл все запросы к базе данных и время их выполнения, для этого необходимо инициализировать переменную $DBDebugToFile, значением «true» в файле /bitrix/php_interface/dbconn.php.
В новом ядре за это отвечают функции: BitrixMainDiagDebug::dumpToFile и BitrixMainDiagDebug::writeToFile.
Ручное добавление через addMessage2Log:
// В файле /bitrix/php_interface/dbconn.php определить константу LOG_FILENAME, в которой задать путь к лог-файлу
define("LOG_FILENAME", $_SERVER["DOCUMENT_ROOT"]."/log.txt");
В дальнейшем любые массивы, тексты можно отправлять в этот файл посредством
AddMessage2Log("Произвольный текст сообщения или массив", "my_module_id(необязательно)");
Нужно включить показ ошибок bitrix/www/bitrix/.settings.php
‘debug’ => true,
тоже самое с базой данных .
bitrix/www/bitrix/php_interface/dbconn.php
Также можно заменить ‘log’ => null на
'log' =>
array (
'settings' =>
array (
'file' => '/var/log/php/exceptions.log',
'log_size' => 1000000,
),
),
Думаю, объяснять, что такое логи — нет необходимости. Имея под рукой логи проще разобраться с возникшими проблемами и выяснить, когда и почему они начались. В данной статье расскажу основные моменты в использовании логов.
Для начала обсудим важный, но не для всех явный момент — логи полезны только в том случае, если с ними удобно работать.
Поэтому логи не должны занять все свободное пространство на диске, т.е. в логи нужно помещать только нужную информацию, а не все подряд. Устаревшие логи должны удаляться. Для удаления устаревших логов лучше всего настроить задание на cron.
Логи должны быть удобными для изучения — логи с ошибками и логи с диагностическими данными должны помещаться в разные файлы. Желательно разделять логи на временные интервалы — например, ежедневные логи (наиболее распространенный вариант, но если уверены, что логов будет мало — можно выделять, например, по месяцам, или неделям).
Все логи нужно держать в одной папке, чтобы было удобней их изучать (/logs/, /_logs/, /local/logs/ и т.п. ). В целях защиты следует закрыть доступ к папке с логами по http — настраивается в .htacces,
deny from all
и/или добавить к названию файла уникальный для проекта постфикс.
Папку для логов надо предварительно создать и убедиться, что битрикс (веб-сервер) имеет права на запись в нее.
В системе 1С-Битрикс существует 2 вида логов
AddMessage2Log(…)
Это функция из старого ядра.
Многие модули пишут через нее отладочную информацию.
Пример настройки места хранения логов, выводимых данной функцией, выглядит так (не забывайте, что папка logs/bx должна быть создана):
define("LOG_FILENAME", $_SERVER["DOCUMENT_ROOT"] . "/logs/bx/" . date("Y-m-d") . ".log");
Прописать данную настройку можно, например, в dbconn.php.
Секция exception_handling в файле .settings.php
Это уже функционал нового ядра.
Ядро через данный функционал пишет информацию обо всех ошибках и исключениях. Что именно пишется — зависит от настроек.
Пример настройки логов с разделением по дате:
'exception_handling' => array (
'value' => array (
'debug' => false, // disables error output to screen
// ошибки для вывода в лог
'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_WARNING,
'exception_errors_types' => E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_COMPILE_WARNING,
'ignore_silence' => true,
'assertion_throws_exception' => true,
'assertion_error_type' => 256,
'log' => array (
'settings' => array (
'file' => "logs/bx_error/" . date("Y-m-d") . ".log",
'log_size' => 1000000, // ~ 1Mb per file
),
),
),
'readonly' => true,
),
Функции отладки в ядре D7
На замену функции AddMessage2Log в ядре D7 пришли новые функции:
use BitrixMainDiagDebug; Debug::dumpToFile($_SERVER); // для случаев, когда нужен var_dump Debug::writeToFile($_SERVER); // когда нужен print_r
Также в ядре D7 появились методы, для измерения времени. В старом ядре аналогов не было.
use BitrixMainDiagDebug;
Debug::startTimeLabel("foo");
foo();
Debug::endTimeLabel("foo");
Debug::startTimeLabel("bar");
bar();
Debug::endTimeLabel("bar");
print_r(Debug::getTimeLabels());
Таким образом, корректная расстановка функций логирования и временных меток позволит обнаружить уязвимости в коде и
уменьшить время отдачи сайта от сервера пользователю.
Просмотров: 7139
Дата последнего изменения: 21.04.2022
Сложность урока:
3 уровень — средняя сложность. Необходимо внимание и немного подумать.
4
5
Недоступно в лицензиях:
Ограничений нет
Введение
В ядро добавлены логгеры, реализующие интерфейс PSR-3:
- базовый абстрактный класс BitrixMainDiagLogger, реализующий интерфейс PSR-3;
- файловый логгер BitrixMainDiagFileLogger;
- syslog логгер BitrixMainDiagSysLogger.
Логгеры пользуются форматтером логов BitrixMainDiagLogFormatter, который делает замены плейсхолдеров в соответствии с PSR-3.
Примечание: Библиотека доступна с версии main 21.900.0.
Logger Interface
Интерфейс PsrLogLoggerInterface довольно прост, это — набор функций логирования, поддерживающих уровни логирования. Уровни задаются константами PsrLogLogLevel::*.
interface LoggerInterface
{
public function emergency($message, array $context = array());
public function alert($message, array $context = array());
public function critical($message, array $context = array());
public function error($message, array $context = array());
public function warning($message, array $context = array());
public function notice($message, array $context = array());
public function info($message, array $context = array());
public function debug($message, array $context = array());
public function log($level, $message, array $context = array());
}
В сообщении могут быть {плейсхолдеры}, которые заменяются данными из ассоциативного массива $context.
Также полезным может быть интерфейс PsrLogLoggerAwareInterface, если вы хотите сообщить, что ваш объект готов принять логгер PSR-3:
interface LoggerAwareInterface
{
public function setLogger(LoggerInterface $logger);
}
Логгеры в продукте
Логгеры в продукте расширены по сравнению с PSR-3. Можно:
- установить минимальный уровень логирования, ниже которого логгер ничего не выведет,
- установить форматтер.
Файловый логгер BitrixMainDiagFileLogger умеет записывать сообщения в файл, указанный в конструкторе. Если размер лога превышает указанный максимальный, производится однократная ротация файла. Ноль означает не делать ротацию. По умолчанию размер 1 Мб.
$logger = new DiagFileLogger($logFile, $maxLogSize); $logger->setLevel(PsrLogLogLevel::ERROR); // выведет в лог $logger->error($message, $context); // НЕ выведет в лог $logger->debug($message, $context);
Syslog логгер BitrixMainDiagSysLogger является надстройкой над функцией php syslog. Конструктор принимает параметры, использующиеся функцией openlog.
$logger = new DiagSysLogger('Bitrix WAF', LOG_ODELAY, $facility);
$logger->warning($message);
На файловый логгер переведена функция AddMessage2Log и класс BitrixMainDiagFileExceptionHandlerLog, а также логирование в модуле Проактивная защита (security).
Форматирование сообщения
В логгер можно установить форматтер сообщения. По умолчанию используется форматтер BitrixMainDiagLogFormatter, реализующий интерфейс BitrixMainDiagLogFormatterInterface:
interface LogFormatterInterface
{
public function format($message, array $context = []): string;
}
Конструктор форматтера принимает параметры $showArguments = false, $argMaxChars = 30 (показывать значение аргументов в трейсе, максимальная длина аргумента).
$logger = new MainDiagFileLogger(LOG_FILENAME, 0); $formatter = new MainDiagLogFormatter($showArgs); $logger->setFormatter($formatter);
Основная задача форматтера — подставлять значения в плейсхолдеры сообщения из массива контекста. Форматтер умеет обрабатывать определенные плейсхолдеры:
{date}— текущее время * ;{host}— HTTP host * ;{exception}— объект исключения (Throwable);{trace}— массив бектрейса;{delimiter}— разделитель сообщений * .
* — не обязательно передавать в массиве контекста, подставляется автоматически.
$logger->debug(
"{date} - {host}n{trace}{delimiter}n",
[
'trace' => DiagHelper::getBackTrace(6, DEBUG_BACKTRACE_IGNORE_ARGS, 3)
]
);
Значения из массива контекста форматтер старается привести к удобному виду в зависимости от типа значения. Принимаются строки, массивы, объекты.
Использование
В простом виде объект может принять логгер снаружи, поддерживая интерфейс PsrLogLoggerAwareInterface. Можно использовать соответствующий трейт:
use BitrixMainDiag;
use PsrLog;
class MyClass implements LogLoggerAwareInterface
{
use LogLoggerAwareTrait;
public function doSomething()
{
if ($this->logger)
{
$this->logger->error('Error!');
}
}
}
$object = new MyClass();
$logger = new DiagFileLogger("/var/log/php/error.log");
$object->setLogger($logger);
$object->doSomething();
Однако, не удобно менять код на работающем проекте, чтобы передать логгер в нужный объект. Для этого в классе логгера предусмотрена своя фабрика. На вход фабрике передается строка-идентификатор логгера:
use BitrixMainDiag;
use PsrLog;
class MyClass implements LogLoggerAwareInterface
{
use LogLoggerAwareTrait;
public function doSomething()
{
if ($logger = $this->getLogger())
{
$logger->error('Error!');
}
}
protected function getLogger()
{
if ($this->logger === null)
{
$logger = DiagLogger::create('myClassLogger', [$this]);
$this->setLogger($logger);
}
return $this->logger;
}
}
Настройка
В корневой секции файла .settings.php логгеры указываются в ключе loggers. Синтаксис описания совпадает с настройками ServiceLocator. Отличие состоит в том, что сервис-локатор является реестром, а здесь настраивается фабрика.
В замыкание-конструктор constructor можно передать дополнительные параметры через второй параметр фабрики DiagLogger::create('logger.id', [$this]). Параметры позволяют гибко включать логирование в зависимости от переданных параметров, в том числе вызывать методы самого объекта.
Дополнительно можно указать минимальный уровень журналирования (level) и собственный форматтер (formatter). Форматтер ищется в сервис локаторе по его идентификатору.
// /bitrix/.settings.php
return [
//...
'services' => [
'value' => [
//...
'formatter.Arguments' => [
'className' => 'BitrixMainDiagLogFormatter',
'constructorParams' => [true],
],
],
'readonly' => true,
]
'loggers' => [
'value' => [
//...
'main.HttpClient' => [
// 'className' => 'BitrixMainDiagFileLogger',
// 'constructorParams' => ['/home/bitrix/www/log.txt'],
// 'constructorParams' => function () { return ['/home/bitrix/www/log.txt']; },
'constructor' => function (BitrixMainWebHttpClient $http, $method, $url) {
$http->setDebugLevel(BitrixMainWebHttpDebug::ALL);
return new BitrixMainDiagFileLogger('/home/bitrix/www/log.txt');
},
'level' => PsrLogLogLevel::DEBUG,
'formatter' => 'formatter.Arguments',
],
],
'readonly' => true,
],
//...
];
При указании замыкания-конструктора constructor желательно использовать файл .settings_extra.php, чтобы не потерять код при сохранении настроек из API.
Существует PsrLogNullLogger, его можно установить, если не хочется писать if($logger) перед каждым вызовом логгера. Однако, следует учитывать, стоит ли делать дополнительную работу по формированию сообщения и контекста.
Классы
Список классов, поддерживающих фабрику логгеров:
| Класс | Id логгера | Передаваемые параметры |
|---|---|---|
| BitrixMainWebHttpClient | main.HttpClient | [$this, $this->queryMethod, $this->effectiveUrl] |
Думаю, объяснять, что такое логи — нет необходимости. Имея под рукой логи проще разобраться с возникшими проблемами и выяснить, когда и почему они начались. В данной статье расскажу основные моменты в использовании логов.
Для начала обсудим важный, но не для всех явный момент — логи полезны только в том случае, если с ними удобно работать.
Поэтому логи не должны занять все свободное пространство на диске, т.е. в логи нужно помещать только нужную информацию, а не все подряд. Устаревшие логи должны удаляться. Для удаления устаревших логов лучше всего настроить задание на cron.
Логи должны быть удобными для изучения — логи с ошибками и логи с диагностическими данными должны помещаться в разные файлы. Желательно разделять логи на временные интервалы — например, ежедневные логи (наиболее распространенный вариант, но если уверены, что логов будет мало — можно выделять, например, по месяцам, или неделям).
Все логи нужно держать в одной папке, чтобы было удобней их изучать (/logs/, /_logs/, /local/logs/ и т.п. ). В целях защиты следует закрыть доступ к папке с логами по http — настраивается в .htacces,
deny from all
и/или добавить к названию файла уникальный для проекта постфикс.
Папку для логов надо предварительно создать и убедиться, что битрикс (веб-сервер) имеет права на запись в нее.
В системе 1С-Битрикс существует 2 вида логов
AddMessage2Log(…)
Это функция из старого ядра.
Многие модули пишут через нее отладочную информацию.
Пример настройки места хранения логов, выводимых данной функцией, выглядит так (не забывайте, что папка logs/bx должна быть создана):
define("LOG_FILENAME", $_SERVER["DOCUMENT_ROOT"] . "/logs/bx/" . date("Y-m-d") . ".log");
Прописать данную настройку можно, например, в dbconn.php.
Секция exception_handling в файле .settings.php
Это уже функционал нового ядра.
Ядро через данный функционал пишет информацию обо всех ошибках и исключениях. Что именно пишется — зависит от настроек.
Пример настройки логов с разделением по дате:
'exception_handling' => array (
'value' => array (
'debug' => false, // disables error output to screen
// ошибки для вывода в лог
'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_WARNING,
'exception_errors_types' => E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_COMPILE_WARNING,
'ignore_silence' => true,
'assertion_throws_exception' => true,
'assertion_error_type' => 256,
'log' => array (
'settings' => array (
'file' => "logs/bx_error/" . date("Y-m-d") . ".log",
'log_size' => 1000000, // ~ 1Mb per file
),
),
),
'readonly' => true,
),
Функции отладки в ядре D7
На замену функции AddMessage2Log в ядре D7 пришли новые функции:
use BitrixMainDiagDebug; Debug::dumpToFile($_SERVER); // для случаев, когда нужен var_dump Debug::writeToFile($_SERVER); // когда нужен print_r
Также в ядре D7 появились методы, для измерения времени. В старом ядре аналогов не было.
use BitrixMainDiagDebug;
Debug::startTimeLabel("foo");
foo();
Debug::endTimeLabel("foo");
Debug::startTimeLabel("bar");
bar();
Debug::endTimeLabel("bar");
print_r(Debug::getTimeLabels());
Таким образом, корректная расстановка функций логирования и временных меток позволит обнаружить уязвимости в коде и
уменьшить время отдачи сайта от сервера пользователю.
Объяснять, что такое логи — нет необходимости. Когда есть логи, то проще разобраться с возникшими проблемами и выяснить, почему они начались. Основные моменты в использовании логов.
Логи не должны занимать всё свободное пространство на диске, т.е. в логи нужно помещать только нужную информацию, а не всё подряд. Устаревшие логи должны удаляться. Для удаления устаревших логов лучше всего настроить задание на cron.
Логи должны быть удобными для изучения — логи с ошибками и логи с диагностическими данными должны помещаться в разные файлы. Желательно разделять логи на временные интервалы — например, ежедневные логи (наиболее распространенный вариант, или, например, по месяцам, или неделям).
Все логи нужно держать в одной папке, чтобы было удобней их изучать (/logs/, /_logs/, /local/logs/ и т.п. ). В целях защиты следует закрыть доступ к папке с логами по http — настраивается в .htacces,
deny from all
и/или добавить к названию файла уникальный идентификатор.
Папку для логов надо предварительно создать и убедиться, что битрикс (веб-сервер) имеет права на запись в нее.
В системе 1С-Битрикс существует 2 вида логов:
ADDMESSAGE2LOG(…)
Это функция из старого ядра. Многие модули пишут через нее отладочную информацию.
Пример настройки места хранения логов, выводимых данной функцией, выглядит так (папка logs/bx должна быть создана):
define("LOG_FILENAME", $_SERVER["DOCUMENT_ROOT"] . "/logs/bx/" . date("Y-m-d") . ".log");
Прописать данную настройку можно, например, в dbconn.php.
СЕКЦИЯ EXCEPTION_HANDLING В ФАЙЛЕ .SETTINGS.PHP
Это уже функционал нового ядра D7.
Битрикс через данный функционал пишет информацию обо всех ошибках и исключениях. Что именно пишется — зависит от настроек.
Пример настройки логов с разделением по дате:
'exception_handling' => array (
'value' => array (
'debug' => false, // disables error output to screen
// ошибки для вывода в лог
'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_WARNING,
'exception_errors_types' => E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_COMPILE_WARNING,
'ignore_silence' => true,
'assertion_throws_exception' => true,
'assertion_error_type' => 256,
'log' => array (
'settings' => array (
'file' => "logs/bx_error/" . date("Y-m-d") . ".log",
'log_size' => 1000000, // ~ 1Mb per file
),
),
),
'readonly' => true,
),
ФУНКЦИИ ОТЛАДКИ В ЯДРЕ D7
На замену функции AddMessage2Log в ядре D7 пришли новые функции:
use BitrixMainDiagDebug; Debug::dumpToFile($_SERVER); // для случаев, когда нужен var_dump Debug::writeToFile($_SERVER); // когда нужен print_r
Также в ядре D7 появились методы, для измерения времени. В старом ядре аналогов не было.
use BitrixMainDiagDebug;
Debug::startTimeLabel("foo");
foo();
Debug::endTimeLabel("foo");
Debug::startTimeLabel("bar");
bar();
Debug::endTimeLabel("bar");
print_r(Debug::getTimeLabels());
Таким образом, правильная расстановка функций логирования и временных меток позволит выявить уязвимости в коде и уменьшить время выдачи сайта от сервера пользователю.
Проверяем логи, битрикс окружение
bitrix, nginx, apache, php, mysql, sendmail, cron
В процессе жизнедеятельности сайт и сервер оставляют после себя различные записи в лог-файлах. Данные из этих файлов желательно периодически разгребать и анализировать, что бы сайт работал быстро и бесперебойно
Для битрикс окружения на centos пути к логам обычно будут такими (зависит от настроек):
- Битрикс: __bx_log.log или log.txt в корне сайта. Зависит от переменной LOG_FILENAME в файле /bitrix/php_interface/dbconn.php
- Apache: /var/log/httpd/error_log
- Nginx: /var/log/nginx/error.log
- PHP: /var/log/php/exceptions.log
- Почта: /home/bitrix/msmtp_default.log
- bash, cron: /var/spool/mail/root и /var/spool/mail/bitrix
- bitrixvm: /opt/webdir/temp (логи запущенных задач)
Как часто надо проверять? Раз в неделю стоит поглядывать, я думаю. Просто что бы убедиться, что эти файлы пусты и ошибок не было.
И как бонус стоит проверить файл /var/log/btmp командой last -f /var/log/btmp если там очень много попыток авторизации, значит доступ к ssh пытаются «брутфорсить». Стоит изменить порт доступа к ssh (в файле /etc/ssh/sshd_config поменять строку «Port 22» на другое значение, разрешить доступ к новому порту в iptables и перезагрузить sshd) Что бы сбросить лог авторизации нужно выполнить команду cat /dev/null > /var/log/btmp
Есть вопросы или нашли ошибку? Напишите комментарий (можно без регистрации), отвечать стараюсь быстро.
Опубликовано 21 апреля 2017 | Обновлено 24 июля 2020
Возврат к списку
