Лог ошибок php debian
Обновлено: 04.07.2024
Поведение этих функций зависит от установок в php.ini .
| Имя | По умолчанию | Место изменения | Список изменений |
|---|---|---|---|
| error_reporting | NULL | PHP_INI_ALL | |
| display_errors | "1" | PHP_INI_ALL | |
| display_startup_errors | "1" | PHP_INI_ALL | До PHP 8.0.0 значение по умолчанию было "0" . |
| log_errors | "0" | PHP_INI_ALL | |
| log_errors_max_len | "1024" | PHP_INI_ALL | |
| ignore_repeated_errors | "0" | PHP_INI_ALL | |
| ignore_repeated_source | "0" | PHP_INI_ALL | |
| report_memleaks | "1" | PHP_INI_ALL | |
| track_errors | "0" | PHP_INI_ALL | Объявлено устаревшим в PHP 7.2.0, удалено в PHP 8.0.0. |
| html_errors | "1" | PHP_INI_ALL | |
| xmlrpc_errors | "0" | PHP_INI_SYSTEM | |
| xmlrpc_error_number | "0" | PHP_INI_ALL | |
| docref_root | "" | PHP_INI_ALL | |
| docref_ext | "" | PHP_INI_ALL | |
| error_prepend_string | NULL | PHP_INI_ALL | |
| error_append_string | NULL | PHP_INI_ALL | |
| error_log | NULL | PHP_INI_ALL | |
| syslog.facility | "LOG_USER" | PHP_INI_SYSTEM | Доступно, начиная с PHP 7.3.0. |
| syslog.filter | "no-ctrl" | PHP_INI_ALL | Доступно, начиная с PHP 7.3.0. |
| syslog.ident | "php" | PHP_INI_SYSTEM | Доступно, начиная с PHP 7.3.0. |
Краткое разъяснение конфигурационных директив.
Задаёт уровень протоколирования ошибки. Параметр может быть либо числом, представляющим битовое поле, либо именованной константой. Соответствующие уровни и константы приведены в разделе Предопределённые константы, а также в php.ini . Для установки настройки во время выполнения используйте функцию error_reporting() . Смотрите также описание директивы display_errors.
Значение по умолчанию равно E_ALL &
E_NOTICE &
E_STRICT &
E_DEPRECATED . При этой настройке не отображаются уровни ошибок E_NOTICE , E_STRICT и E_DEPRECATED . Можно отображать их при разработке.
Эта настройка определяет, требуется ли выводить ошибки на экран вместе с остальным выводом, либо ошибки должны быть скрыты от пользователя.
Значение "stderr" посылает ошибки в поток stderr вместо stdout . Значение доступно в версии PHP 5.2.4. В ранних версиях эта директива имела тип bool .
Замечание:
Эта функциональность предназначена только для разработки и не должен использоваться в готовых производственных системах (например, системах, имеющих доступ в интернет).
Замечание:
Несмотря на то, что display_errors может быть установлена во время выполнения (функцией ini_set() ), это ни на что не повлияет, если в скрипте есть фатальные ошибки. Это обусловлено тем, что ожидаемые действия программы во время выполнения не получат управления (не будут выполняться).
Даже если display_errors включена, ошибки, возникающие во время запуска PHP, не будут отображаться. Настойчиво рекомендуем включать директиву display_startup_errors только для отладки.
Замечание:
Настоятельно рекомендуем при работе на готовых работающих web сайтах протоколировать ошибки там, где они отображаются.
Задание максимальной длины log_errors в байтах. В error_log добавляется информация об источнике. Значение по умолчанию 1024. Установка значения в 0 позволяет снять ограничение на длину log_errors. Это ограничение распространяется на записываемые в журнал ошибки, на отображаемые ошибки, а также на $php_errormsg , но не на явно вызываемые функции, такие как error_log() .
Если используется int , значение измеряется байтами. Вы также можете использовать сокращённую запись, которая описана в этом разделе FAQ. ignore_repeated_errors bool
Не заносить в журнал повторяющиеся ошибки. Ошибка считается повторяющейся, если происходит в том же файле и в той же строке, и если настройка ignore_repeated_source выключена.
Если настройка включена (по умолчанию), будет формироваться отчёт об утечках памяти, зафиксированных менеджером памяти Zend. На POSIX платформах этот отчёт будет направляться в поток stderr. На Windows платформах он будет посылаться в отладчик функцией OutputDebugString(), просмотреть отчёт в этом случае можно с помощью утилит, вроде » DbgView. Эта настройка имеет смысл в сборках, предназначенных для отладки. При этом E_WARNING должна быть включена в список error_reporting.
Если включена, последняя произошедшая ошибка будет первой в переменной $php_errormsg .
Если запрещена, то ошибки будут выдаваться простым текстом, без форматирования.
Если включена, то нормальное оповещение об ошибках отключается и, вместо него, ошибки выводятся в формате XML-RPC.
Используется в качестве значения XML-RPC элемента faultCode.
В большинстве случаев вам потребуется, чтобы значение docref_root оканчивалось слешем "/" . Тем не менее, бывают случаи, когда это не требуется (смотрите выше, второй пример).
Замечание:
Эта функциональность предназначена только для разработки, так как он облегчает поиск описаний функций и ошибок. Не используйте его в готовых производственных системах (например, имеющих доступ в интернет).
Замечание:
Значение docref_ext должно начинаться с точки "." .
- all – строка будет разделена на символы новой строки и все символы будут переданы без изменений
- ascii – строка будет разделена на символы новой строки, а любые непечатаемые 7-битные символы ASCII будут экранированы
- no-ctrl – строка будет разделена на символы новой строки, а любые непечатаемые символы будут экранированы
- raw – все символы передаются в системный журнал без изменений, без разделения на новые строки (идентично PHP до 7.3)
Директива не поддерживается в Windows. syslog.ident stringЗамечание:
Тип фильтра raw доступен начиная с PHP 7.3.8 и PHP 7.4.0.
Логи сайта — это системные журналы, позволяющие получить информацию о посещении сайта ботами и пользователями, а также выявить скрытые проблемы на сервере — ошибки, битые ссылки, медленные запросы от сервера и многое другое.
Важные логи сайта
Расположение логов
Важно обратить внимание, что местоположение логов сайта по умолчанию зависит от используемого типа оболочки и может быть изменено администратором.
Стандартные пути до Error.log
Nginx
Php-Fpm
Apache (CentOS)
Apache (Ubuntu, Debian)
Стандартные пути до Access.log
Nginx
Php-Fpm
Apache (CentOS)
Apache (Ubuntu, Debian)
Чтение записей в логах
Записи в логах имеют структуру: одно событие – одна строка .
Записи в разных логах имеют общие черты, но количество подробностей отличается. Далее будут приведены примеры строк из разных системных журналов.
Примеры записей
Error.log
В приведенном примере:
Access.log
В приведенном примере:
Просмотр логов сервера с помощью команды tail
Выполнить просмотр логов в Linux можно с помощью команды tail . Данный инструмент позволяет смотреть записи в логах, выводя последние строки из файла. По умолчанию tail выводит 10 строк.
Первый вариант использования Tail
Аргумент «-f» позволяет команде делать просмотр событий в режиме реального времени, в ожидании новых записей в лог файлах. Для прерывания процесса следует нажать сочетание клавиш «Ctrl+C».
На место переменной «/var/log/syslog» в примере следует подставить актуальный адрес до нужных системных журналов.
Второй вариант использования Tail
В Linux логи веб-сервера не ведутся до бесконечности, поскольку это усложняет их дальнейший анализ. При преодолении лимита записей, система переименует переполненный строками файл журнала и отправит в «архив». Вместо старого файла создастся новый, но с прежним названием.
Если будет использоваться аргумент «-f», команда продолжит отслеживание старого, переименованного журнала. Данный метод делает невозможным просмотр логов в реальном времени, поскольку файл более не актуален.
При использовании аргумента «-F», команда, после окончания записи старого журнала, перейдёт к чтению нового файла с логами. В таком случае просмотр логов в режиме реального времени продолжится.
Аналог команды Tail
Отличие команды tailf от предыдущей заключается в том, что она не обращается к файлу и файловой системе в период, когда запись логов не происходит. Это экономит ресурсы системы и заряд, если используется нестационарное устройство — ноутбук, смартфон или планшет.
Недостаток данного способа — проблема с чтением больших файлов. Если системный журнал достаточно большой, возникает вероятность отказа в работе программы.
Изменение стандартного количества строк для вывода
Как и отмечалось выше, по умолчанию выводится 10 строк. Если требуется увеличить или уменьшить их количество, в команду добавляется аргумент «-n» и необходимое число строк.
При использовании данной команды будут показаны последние 100 строк журнала.
Просмотр логов с помощью ISPManager
Если на сервере установлен ISPManager, логи можно легко читать, используя приведенный ниже алгоритм.
Программы для анализа логов
Анализировать журналы с большим количеством данных вручную не только сложно, но и чревато ошибками. Для упрощения работы с лог файлами было создано большое количество сервисов и утилит.
Инструменты для анализа логов делятся на два основных типа — статические и работающие в режиме реального времени.
Статические программы
Данный тип выполняет работу только с извлеченными логами, но обеспечивает быструю сортировку данных.
WebLog Expert![WebLog Expert]()
Возможности
- Предоставление информации об активность сайта, количестве посетителей, доступ к файлам, URL страницы, ссылающиеся страницы, информацию о пользователе (браузер и операционная система).
- Создание отчётов в формате HTML (.html), PDF (.pdf), CSV (.csv).
- Поддерживает анализ логов Nginx, Apache, ISS.
- Чтение файлов даже в архивах ZIP (.zip), GZ (.gz).
Web Log Explorer
Возможности
Программы для анализа в режиме реального времени
Эти инструменты встраиваются в программную среду сервера, анализируют данные в реальном времени и записывают непрерывный отчёт.
GoAccess
Возможности
- Автоматическая генерация отчёта в формате HTML (.html), JSON (.json), CSV (.csv).
- При подключении к серверу через SSH, возможен анализ в браузере и в терминале
- Поддержка почти всех форматов (Apache, Nginx, Amazon S3, Elastic Load Balancing, CloudFront и др.).
Logstash
Возможности
- Постоянная генерация отчёта в файл JSON (.json).
- Получение и анализ информации из нескольких источников.
- Возможность пересылать журналы с помощью Filebeat.
- Поддержка анализа системных журналов.
- Поддерживается большое количество форматов: от Apache до Log4j (Java).
Ведения логов медленных запросов сервера
Анализ данного лога позволяет определить на какие типы запросов сервер отвечает долго. В идеале задержка должна составлять не более 1 секунды.
На некоторых типах оболочек (MySQL, PHP-FPM) ведение данного лога по умолчанию отключено. Процесс запуска и ведения зависит от сервера.
MySQL
Если сервер управляется с помощью MySQL, то необходимо создать каталог и сам файл для ведения журнала с помощью команд:
Стоит изменить владельца файла, чтобы избежать дальнейших проблем с записью логов. Делается это командой:
После выполнения предыдущих действий, нужно совершить вход в командную строку MySQL под учётной записью суперпользователя:
Для запуска и настройки ведения логов нужно последовательно ввести в терминале следующие команды:
- slow_query_log — запускает ведение журналов медленных запросов.
- slow_launch_time — указывает максимальную задержку отклика, после которой статистика запроса попадёт в журнал. В данном случае запись в логи происходит при преодолении откликом порога 2 секунды.
- slow_query_log_file — задаёт путь до используемого журнала.
Проверить статус и параметры ведения лога медленных запросов можно командой:
Выход из консоли MySQL выполняется командой:
После выполнения всех предыдущих действий, можно просмотреть логи сервера. Для этого в терминале вводится:
PHP-FPM
Для ведения журнала на данной оболочке, необходимо отредактировать параметры в конфигурационном файле. Для этого в терминале вводится команда:
Далее нужно найти строки:
- request_slowlog_timeout = 10s — параметр, позволяющий указать задержку, с которой запись о длительном запросе попадёт в журнал.
- slowlog = /var/log/php-fpm/www-slow.log — параметр, указывающий путь до актуального файла логирования (.log).
После применения изменений, необходимо перезагрузить сервер PHP-FPM. Для этого в консоль вводится команда:
Просмотр логов запускается командой:
Анализ логов медленных запросов
Логи медленных запросов могут за незначительное время вырасти до огромных размеров. Для сортировки и отображения повторяющихся запросов рекомендуется использовать программу MySQLDumpSlow.
Для запуска просмотра логов с помощью этой утилиты, нужно составить команду по приведенному ниже алгоритму:
Ведение логов в Logrotate
На больших ресурсах журналы могут достигать огромных размеров, поэтому нужно своевременно архивировать или очищать логи. С помощью утилиты Logrotate можно управлять ведением журналов: настроить период ротации (архивирование старого журнала и создание нового), период и количество хранения журналов и многое другое.
Изначально программа отсутствует в системе. Ниже приведены команды для инсталляции Logrotate из официальных репозиториев.
Ubuntu, Debian:
CentOS:
После установки необходимо проверить путь для будущих конфигурационных файлов. Для правильной работы они должны находится в папке «logrotate.d». Проверить данный параметр можно открыв конфигурационный файл командой:
В директории «RPM packages drop log rotation information into this directory» должна присутствовать строка:
Теперь создаётся конфигурационный файл «rsyslog.conf». В нём будет находиться конфигурацию по работе с логами. Для создания файла в терминале вводится команда:
В окне терминала откроется текстовой редактор. Теперь нужно внести конфигурацию, как указано в образце. В качестве примера будет использоваться журнал посещений «Access.log» (Nginx).
Теперь остаётся только запустить Logrotate. Для этого вводится команда:
Для проверки правильности работы программы в терминале можно ввести команду:
В данной статье пойдет речь о мониторинге нагрузки, именно, в контексте веб-сервера. Мы не будем особо заострять внимание на проверке производительности системы, как, например, командами top, htop, free и так далее.
Нагрузка на сервер
Анализ нагрузки стоит начать с общих метрик — потребление процессорного времени, памяти, нагрузки на сеть и дисковую систему.
Нагрузка по процессам
Проверить, нагружен ли сервер, а также понять, какой именно процесс больше всего потребляет ресурсов можно с помощью команд:
* по сути, все 3 вышеперечисленные команды выдают одну и туже информацию в разном виде. Какой-то из них может оказаться удобнее пользоваться. Утилита top встроена в систему, для использования остальных необходимо установить одноименные пакеты.
Оперативная память
Для определения объема свободной и занимаемой памяти можно воспользоваться командой:
* предыдущие команды тоже показывали утилизацию памяти, но кому-то команда free может показаться нагляднее.
Нагрузка на диск
Для определения нагрузки на дисковую систему, используем утилиту iotop. Сначала ее нужно установить.
а) На системы Debian / Ubuntu:
apt-get install iotop
б) На системы Red Hat / CentOS:
yum install iotop
После выполняем следующую команду:
Сетевая активность
Для измерения нагрузки на сеть необходимо установить утилиту nload.
а) В CentOS / Red Hat:
yum install nload
б) В Ubuntu / Debian:
apt-get install nload
После установки, запускаем утилиту командой:
* в данном примере будет запущена статистика для использования сетевого интерфейса eth0.
Что грузит систему
Даже, если мы увидим, что на веб-сервере заканчивается оперативная память или загружен процессор, мы не сможем найти источник проблемы, которым, чаще всего, является некорректно работающий скрипт. Поэтому, определяем, какой файл на сервере вызывает нагрузку.
Использование lsof
lsof — утилита командной строки, которая отображает какие файлы используются процессами. Она позволит определить, к каким скриптам идет обращение со стороны веб-сервера. Для начала, необходимо установить lsof.
а) В CentOS / Red Hat:
yum install lsof
б) В Ubuntu / Debian:
apt-get install lsof
Теперь можно выполнить следующие команды:
* первая команда покажет, к каким файлам обращается apache, вторая — php-fpm (часто можно увидеть в связке с nginx).
Анализ error-логов
Анализ логов ошибок позволит не только обнаружить проблемы в работе сайта, но и найти причину его медленной работы. По умолчанию, логи находятся в каталоге /var/log. Если мы не меняли расположение логов, запускаем следующие команды:
tail -f /var/log/nginx/error.log
* лог ошибок nginx.
tail -f /var/log/php-fpm/error.log
* лог ошибок php-fpm.
* лог ошибок apache в CentOS.
tail -f /var/log/apache2/error_log
* лог ошибок apache в Ubuntu.
В первую очередь, нужно обратить внимание на повторяющиеся ошибки — они могут быть причиной проблем. Лучше всего, добиться полного отсутствия ошибок, внеся исправления в работу сайта. Возможно, это устранит проблемы производительности.
Статистика веб-сервера
Для веб-серверов можно воспользоваться служебной страницей просмотра статуса. Она может показать статистику запросов к веб-серверу.
Apache
По умолчанию, server-status не активен. Создаем конфигурационный файл.
Для CentOS / Red Hat:
Для Ubuntu / Debian:
* где 2 — используемая версия apache.
В открытый конфигурационный файл добавим:
<VirtualHost *:80>
servername 111.111.111.111
<Location /server-status>
Sethandler server-status
</Location>
</VirtualHost>
<Location /server-status>
SetHandler server-status
</Location>
* где 111.111.111.111 — IP-адрес нашего веб-сервера; 80 — порт, на котором слушает apache.
* в данном примере мы прописали два варианта просмотра статистики: первый — обращение в браузере к серверу по IP-адресу + /server-status; второй — обращение к любому сайту + /server-status. Разные способы оправданы для разных настроек самих сайтов и используемых CMS.
Проверим корректность внесенных данных и перезапустим веб-сервер apache:
NGINX + PHP-FPM
Открываем конфигурационный файл nginx:
.
server listen 80;
server_name 111.111.111.111;
location /server-status stub_status on;
>
>
.
* где 111.111.111.111 — IP-адрес нашего веб-сервера.
Проверяем корректность настройки и перезапускаем nginx:
systemctl restart nginx
Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:
Теперь настроим статистику для php-fpm. В конфигурационном файле nginx в нашу директиву server добавим:
* обратите внимание на закомментированную строку и строку под ней. В зависимости от того, как настроен php-fpm (слушает на порту или через сокетный файл) необходимо настроить nginx. В данном примере подразумевается, что php-fpm слушает на 9000 порту.
Открываем конфигурационный файл php-fpm:
Снимаем комментарий со следующей строки:
Проверяем настройку nginx, перезапускаем его и php-fpm:
systemctl restart nginx
systemctl restart php-fpm
Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:
Долгие запросы
С помощью длительных запросов к веб-серверу или СУБД можно сделать выводы о том, что является узким местом в работе сервиса.
MySQL / MariDB
Для начала, воспользуемся инструкцией, чтобы настроить ведение лога медленных запросов (для MySQL или MariaDB).
После, воспользовавшись статистикой, находим неоптимальные запросы. В одних случаях необходимо будет переписать сам запрос, в других — создать индексы базы данных.
PHP-FPM
Открываем конфигурационный файл:
Редактируем следующие параметры:
request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/www-slow.log
* request_slowlog_timeout определяет время, в течение которого должен выполняться запрос, чтобы он считался медленным; slowlog — путь до лога, куда будет сохранена информация о медленных запросах.
Если у вас сайт на PHP, даже самый простой, время от времени в его скриптах могут возникать ошибки. Это может привести к различным неприятным последствиям, от некорректной работы некоторых компонентов сайта (например, формы обратной связи), до недоступности сайта целиком. Как самостоятельно распознать тип ошибки PHP и понять, что с ней делать дальше?
Этот материал поможет вам, во-первых, самостоятельно оценить ситуацию (и, возможно, даже решить ее), а во-вторых, точно ускорит диагностику и решение проблемы при обращении в службу поддержки. Самые ценные советы по устранению наиболее частых ошибок PHP, связанных с лимитами оперативной памяти, вы найдете в конце статьи.
Как обнаружить ошибку PHP на сайте
1. Встроенными средствами браузера
Если на странице сайта присутствует ошибка, в этой вкладке вы увидите код ответа 500 (“Internal Server Error”).
После сохранения файла .htaccess и обновления страницы вы сможете увидеть ошибку.
Если сайтом используется, например, CMS WordPress, то отображение ошибок можно также включить, заменив в файле wp-config.php:
3. С помощью журнала ошибок PHP
Журнал ошибок PHP можно просмотреть, например, с помощью файлового менеджера в Панели управления, открыв файл errors.log:
Также можно открыть файл с ошибками и нажать кнопку “Включить автообновление”. Таким образом, новые записи в журнале можно просматривать в реальном времени.
Расшифровка ошибок PHP
“Вызов неопределенной функции weblizar_get_options() в файле используемой на сайте темы enigma”.
Вероятнее всего, был поврежден один из файлов темы, поэтому можно восстановить только директорию темы ./wp-content/themes/enigma/ , а не всего сайта.
Что делать, в зависимости от типа ошибки PHP
Условно ошибки PHP можно разбить на 4 уровня:
- PARSE ERROR
- FATAL ERROR
- WARNING
- NOTICE
Parse Error
Возникают, если уже на этапе проверки кода интерпретатором PHP найдена ошибка. Чаще всего это синтаксические ошибка (например, пропущенная точка с запятой). Скорее всего, такая ошибка возникла в результате последних внесенных на сайт изменений.
Что делать?
1. Если вы НЕ специалист в PHP, восстановите сайт из последней резервной копии на тот момент, когда сайт работал без ошибок.
Fatal Error и Warning
Что делать?
Восстановите сайт из последней доступной резервной копии на тот момент, когда он работал без ошибок.
Notice
К этому уровню ошибок относятся различные “замечания”, суть которых обычно отображена в тексте ошибки.
Что делать?
Частые ошибки PHP и их решение
Fatal Error: Allowed Memory
Для этого найдите в .htaccess такую директиву:
Fatal Error: Out of memory
То же самое, что и предыдущая ошибка, с той разницей, что достигнут лимит памяти, заданный “снаружи”. Обратите внимание на параметр “Памяти на процесс, Мб, не более“ в условиях пользования нашим сервисом.
Для решения вопроса в данном случае, скорее всего, потребуется либо оптимизация скриптов, чтобы они потребляли меньше памяти, либо разбиение процессов на части. Например, объемную загрузку или выгрузку данных, если она упирается в данный лимит, имеет смысл производить частями.
Также в этом случае мы советуем попробовать отключить акселераторы PHP, если они у вас подключены.
Unable to allocate memory for pool
Сайтам на аккаунте не хватает выделенной на тарифном плане памяти для акселераторов PHP.
Также, например, можно отключить акселератор APC для определенного сайта, добавив в файл .htaccess корневой директории следующую директиву:
php_value apc.cache_by_default off
Обычно имеет смысл оставлять APC для использования на самом посещаемом из ваших сайтов — это позволит использовать именно на нем преимущества акселератора, не заполняя его память данными с других, менее посещаемых сайтов.
В случаях, когда акселератор объективно необходим для корректной и комфортной работы сайтов и его отключение нежелательно, напишите в службу поддержки.
Читайте также: