Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.
Что такое логи
Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:
- системная информация о переданных пользователю данных;
- сообщения о сбоях и ошибках;
- протоколирующие данные о посетителях платформы.
Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Подписаться
Классификация логов
Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:
- доступа (access_log) — записывают IP-адрес, время запроса, другую информацию о пользователях;
- ошибок (error_log) — показывают файлы, в которых выявлены ошибки и классифицируют сбои;
- FTP-авторизаций — отображают данные о попытках входа по FTP-соединению;
- загрузки системы — с его помощью выполняется отладка при появлении проблем, в файл записываются основные системные события, включая сбои;
- основной — содержит информацию о действиях с файерволом, DNS-сервером, ядром системы, FTP-сервисом;
- планировщика задач — в нем выполняется протоколирование задач, отображаются ошибки при запуске cron;
- баз данных — хранит подробности о запросах, сбоях, ошибки в логах сервера отображаются наравне с другой важной информацией;
- хостинговой панели — включает статистику использования ресурсов сервера, время и количество входов в панель, обновление лицензии;
- веб-сервера — содержит информацию о возникавших ошибках, обращениях;
- почтового сервера — в нем ведутся записи о входящих и исходящих сообщениях, отклонениях писем.
Записи в системные журналы выполняет установленный софт.
Зачем нужны логи
Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:
- поиск ошибок и сбоев в работе системы;
- выявление вредоносной активности;
- сбор статистики посещения веб-ресурса.
После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.
Читайте также
Где посмотреть логи
Расположение определяется хостинг-провайдером или настройками установленного софта. На виртуальном хостинге доступ к лог-файлам предоставляется из панели управления хостингом. Если администратор не открыл его для владельца сайта, получить информацию не получится. Но большинство провайдеров разрешают свободно пользоваться журналами и проводить анализ логов сервера. Независимо от разновидности сервера лог-файлы хранятся в текстовом документе. По умолчанию он называется access.log, но настройки позволяют переименовать файл. Это актуально для Nginx, Apache, прокси-разновидностей squid, других типов. Для просмотра их надо скачать и открыть в текстовом редакторе. В качестве альтернативы можно использовать Grep и схожие утилиты. Они позволяют открыть и отфильтровать логи прямо на сервере.
Как читать логи. Пример
Существует довольно много форматов записи, combined — один из наиболее распространенных. В нем строчка кода может выглядеть так:
%h %l %u %t «%r» %>s %b «%{Referer}i» «%{User-Agent}i»
Директивы имеют следующее значение:
- %h — IP-адрес, с которого был сделан запрос;
- %l — длинное имя удаленного хоста;
- %u — удаленный пользователь, если запрос был сделан аутентифицированным юзером;
- %t — время запроса к серверу и его часовой пояс;
- %r — тип и содержимое запроса;
- %s — код состояния HTTP;
- %b — количество байт информации, отданных сервером;
- %{Referer} — URL-источник запроса;
- %{User-Agent} — HTTP-заголовок.
Еще один пример чтения логов можно посмотреть в статье «Как читать логи сервера».
Опытные веб-мастера для сбора и чтения лог-файлов используют программы-анализаторы. Они позволяют читать логи сервера без значительных временных затрат. Вот некоторые из наиболее востребованных:
- Analog. Один из самых популярных анализаторов, что во многом объясняется высокой скоростью обработки данных и экономным расходованием системных ресурсов. Хорошо справляется с объемными записями, совместим с любыми ОС.
- Weblog Expert. Программа доступна в трех вариациях: Lite (бесплатная версия), Professional и Standard (платные релизы). Версии отличаются функциональными возможностями, но каждая позволяет анализировать лог-файлы и создает отчеты в PDF и HTML.
- SpyLOG Flexolyzer. Простой аналитический инструмент, позволяющий получать отчеты с высокой степенью детализации. Интегрируется c системой статистики SpyLOG, позволяет решать задачи любой сложности.
Логи сервера с ошибками error.log
Это журнал с информацией об ошибках на сайте. В нем можно посмотреть, какие страницы отсутствуют, откуда пришел пользователь с конкретным запросом, имеются ли «битые» ссылки, другие недочеты, включая те, которые не удалось классифицировать. Используется для выявления багов и погрешностей в коде.
Каждая ошибка в логе сервера error.log отображается с новой строки. Идентифицировав и устранив ее, программист сможет наладить работу сайта. Используя журнал, можно выявить и слабые места веб-платформы. Это простой и удобный инструмент анализа, которым должен уметь пользоваться каждый веб-мастер, системный администратор и программист.
- Важные логи сайта
- Расположение логов
- Чтение записей в логах
- Просмотр с помощью команды tail
- Просмотр с помощью ISPManager
- Программы для анализа логов
- Ведение логов медленных запросов сервера
- Ведение логов с помощью Logrotate
Логи сайта — это системные журналы, позволяющие получить информацию о посещении сайта ботами и пользователями, а также выявить скрытые проблемы на сервере — ошибки, битые ссылки, медленные запросы от сервера и многое другое.
Важные логи сайта
- Access.log — логи посещений пользователей и ботов. Позволяет составить более точную и подробную статистику, нежели сторонние ресурсы, выполняющие внешнее сканирование сайта и отправляющие ряд ненужных запросов серверу. Благодаря данному логу можно получить информацию об используемом браузере и IP-адрес посетителя, данные о местонахождении клиента (страна и город) и многое другое. Стоит обратить внимание, если сайт имеет высокую посещаемость, то анализ логов сервера потребует больше времени. Поэтому для составления статистики стоит использовать специализированные программы (анализаторы).
- Error.log — программные ошибки сервера. Стоит внимательно отнестись к анализу данного лога, ведь боты поисковиков, сканируя, получают все данные о работе сайта. При обнаружении большого количества ошибок, сайт может попасть под санкции поисковых систем. В свою очередь из записей данного журнала можно узнать точную дату и время ошибки, IP-адрес получателя, тип и описание ошибки.
- Slow.log (название зависит от используемой оболочки сервера) — в данный журнал записываются медленные запросы сервера. Так принято обозначать запросы с повышенным порогом задержки, выданные пользователю. Этот журнал позволяет выявить слабые места сервера и исправить проблему. Ниже будет рассмотрен способ включить ведение данного лога на разных типах серверов, а также настройка задержки, с которой записи будут заноситься в файл.
Расположение логов
Важно обратить внимание, что местоположение логов сайта по умолчанию зависит от используемого типа оболочки и может быть изменено администратором.
Стандартные пути до Error.log
Nginx
/var/log/nginx/error.log
Php-Fpm
/var/log/php-fpm/error.log
/var/log/php-fpm/error.log
/var/log/php-fpm/error.log
Apache (CentOS)
/var/log/httpd/error_log
Apache (Ubuntu, Debian)
/var/log/apache2/error_log
/var/log/apache2/error_log
/var/log/apache2/error_log
Стандартные пути до Access.log
Nginx
/var/log/nginx/access.log
/var/log/nginx/access.log
/var/log/nginx/access.log
Php-Fpm
/var/log/php-fpm/access.log
/var/log/php-fpm/access.log
/var/log/php-fpm/access.log
Apache (CentOS)
/var/log/httpd/access_log
/var/log/httpd/access_log
/var/log/httpd/access_log
Apache (Ubuntu, Debian)
/var/log/apache2/access_log
/var/log/apache2/access_log
/var/log/apache2/access_log
Чтение записей в логах
Записи в логах имеют структуру: одно событие – одна строка.
Записи в разных логах имеют общие черты, но количество подробностей отличается. Далее будут приведены примеры строк из разных системных журналов.
Примеры записей
Error.log
[Sat Sep 1 15:33:40.719615 2019] [:error] [pid 10706] [client 66.249.66.61:60699] PHP Notice: Undefined variable: moduleclass_sfx in /var/data/www/site.ru/modules/contacts/default.php on line 14
[Sat Sep 1 15:33:40.719615 2019] [:error] [pid 10706] [client 66.249.66.61:60699] PHP Notice: Undefined variable: moduleclass_sfx in /var/data/www/site.ru/modules/contacts/default.php on line 14
[Sat Sep 1 15:33:40.719615 2019] [:error] [pid 10706] [client 66.249.66.61:60699] PHP Notice: Undefined variable: moduleclass_sfx in /var/data/www/site.ru/modules/contacts/default.php on line 14
В приведенном примере:
- [Sat Sep 1 15:33:40.719615 2019] — дата и время события.
- [:error] [pid 10706] — ошибка и её тип.
- [client 66.249.66.61:60699] — IP-адрес подключившегося клиента.
- PHP Notice: Undefined variable: moduleclass_sfx in — событие PHP Notice. В данной ситуации — обнаружена неизвестная переменная.
- /var/data/www/site.ru/modules/contacts/default.php on line 14 — путь и номер строки в проблемном файле.
Access.log
194.61.0.6 – alex [10/Oct/2019:15:32:22 -0700] «GET /apache_pb.gif HTTP/1.0» 200 5396 «http://www.mysite/myserver.html» «Mozilla/4.08 [en] (Win98; I ;Nav)»
194.61.0.6 – alex [10/Oct/2019:15:32:22 -0700] «GET /apache_pb.gif HTTP/1.0» 200 5396 «http://www.mysite/myserver.html» «Mozilla/4.08 [en] (Win98; I ;Nav)»
194.61.0.6 – alex [10/Oct/2019:15:32:22 -0700] "GET /apache_pb.gif HTTP/1.0" 200 5396 "http://www.mysite/myserver.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"
В приведенном примере:
- 194.61.0.6 — IP-адрес пользователя.
- alex — если пользователь зарегистрирован в системе, то в логах будет указан идентификатор.
- [10/Oct/2019:15:32:22 -0700]— дата и время записи.
- «GET /apache_pb.gif HTTP/1.0» — «GET» означает, что определённый документ со страницы сайта был отправлен пользователю. Существует команда «POST», наоборот отправляет конкретные данные (комментарий или любое другое сообщение) на сервер . Далее указан извлечённый документ «Apache_pb.gif», а также использованный протокол «HTTP/1.0».
- 200 5396 — код и количество байтов документа, которые были возвращены сервером.
- «http://www. www.mysite/myserver.html»— страница, с которой был произведён запрос на извлечение документа «Apache_pb.gif».
- «Mozilla/4.08 [en] (Win98; I ;Nav)» — данные о пользователе, которой произвёл запрос (используемый браузер и операционная система).
Просмотр логов сервера с помощью команды tail
Выполнить просмотр логов в Linux можно с помощью команды tail. Данный инструмент позволяет смотреть записи в логах, выводя последние строки из файла. По умолчанию tail выводит 10 строк.
Первый вариант использования Tail
tail -f /var/log/syslog
Аргумент «-f» позволяет команде делать просмотр событий в режиме реального времени, в ожидании новых записей в лог файлах. Для прерывания процесса следует нажать сочетание клавиш «Ctrl+C».
На место переменной «/var/log/syslog» в примере следует подставить актуальный адрес до нужных системных журналов.
Второй вариант использования Tail
tail -F /var/log/syslog
В Linux логи веб-сервера не ведутся до бесконечности, поскольку это усложняет их дальнейший анализ. При преодолении лимита записей, система переименует переполненный строками файл журнала и отправит в «архив». Вместо старого файла создастся новый, но с прежним названием.
Если будет использоваться аргумент «-f», команда продолжит отслеживание старого, переименованного журнала. Данный метод делает невозможным просмотр логов в реальном времени, поскольку файл более не актуален.
При использовании аргумента «-F», команда, после окончания записи старого журнала, перейдёт к чтению нового файла с логами. В таком случае просмотр логов в режиме реального времени продолжится.
Аналог команды Tail
tailf /var/log/syslog
Отличие команды tailf от предыдущей заключается в том, что она не обращается к файлу и файловой системе в период, когда запись логов не происходит. Это экономит ресурсы системы и заряд, если используется нестационарное устройство — ноутбук, смартфон или планшет.
Недостаток данного способа — проблема с чтением больших файлов. Если системный журнал достаточно большой, возникает вероятность отказа в работе программы.
Изменение стандартного количества строк для вывода
Как и отмечалось выше, по умолчанию выводится 10 строк. Если требуется увеличить или уменьшить их количество, в команду добавляется аргумент «-n» и необходимое число строк.
Пример:
tail -f -n 100 /var/log/syslog
tail -f -n 100 /var/log/syslog
tail -f -n 100 /var/log/syslog
При использовании данной команды будут показаны последние 100 строк журнала.
Просмотр логов с помощью ISPManager
Если на сервере установлен ISPManager, логи можно легко читать, используя приведенный ниже алгоритм.
- На главной странице, в панели инструментов «WWW» нужно нажать на вкладку «Журналы».
- ISPManager выдаст журналы посещений и серверных ошибок в виде:
- ru.access.log;
- ru.error.log.*
* Вместо «newdomen.ru» из примера в выдаче будет название актуального домена.
Открыть файл лога можно, нажав на «Посмотреть» в верхнем меню.
- Для просмотра всех записей журнала, необходимо нажать на «Скачать» и сохранить файл на локальный носитель.
- Более старые версии логов можно найти во вкладке «Архив».
Программы для анализа логов
Анализировать журналы с большим количеством данных вручную не только сложно, но и чревато ошибками. Для упрощения работы с лог файлами было создано большое количество сервисов и утилит.
Инструменты для анализа логов делятся на два основных типа — статические и работающие в режиме реального времени.
Статические программы
Данный тип выполняет работу только с извлеченными логами, но обеспечивает быструю сортировку данных.
WebLog Expert
Возможности
- Предоставление информации об активность сайта, количестве посетителей, доступ к файлам, URL страницы, ссылающиеся страницы, информацию о пользователе (браузер и операционная система).
- Создание отчётов в формате HTML (.html), PDF (.pdf), CSV (.csv).
- Поддерживает анализ логов Nginx, Apache, ISS.
- Чтение файлов даже в архивах ZIP (.zip), GZ (.gz).
Web Log Explorer
Возможности
- Создание многоуровневых отчётов, включающих количество посетителей, маршруты пользователей по сайту, местоположение хостов (страна и город), указанные в поисковике ключевые слова.
- Поддержка более 43 форматов логов.
- Возможность прямой загрузки логов с FTP, HTTP сервера.
- Чтение архивированных журналов.
Программы для анализа в режиме реального времени
Эти инструменты встраиваются в программную среду сервера, анализируют данные в реальном времени и записывают непрерывный отчёт.
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, то необходимо создать каталог и сам файл для ведения журнала с помощью команд:
mkdir /var/log/mysql
touch /var/log/mysql/mysql-slow.log
touch /var/log/mysql/mysql-slow.log
touch /var/log/mysql/mysql-slow.log
Стоит изменить владельца файла, чтобы избежать дальнейших проблем с записью логов. Делается это командой:
chown mysql:mysql /var/log/mysql/mysql-slow.log
chown mysql:mysql /var/log/mysql/mysql-slow.log
chown mysql:mysql /var/log/mysql/mysql-slow.log
После выполнения предыдущих действий, нужно совершить вход в командную строку MySQL под учётной записью суперпользователя:
mysql -uroot -p
Для запуска и настройки ведения логов нужно последовательно ввести в терминале следующие команды:
> SET GLOBAL slow_query_log = ‘ON’;
> SET GLOBAL slow_launch_time = 2;
> SET GLOBAL slow_query_log_file = ‘/var/log/mysql/mysql-slow.log’;
> SET GLOBAL slow_query_log = ‘ON’;
> SET GLOBAL slow_launch_time = 2;
> SET GLOBAL slow_query_log_file = ‘/var/log/mysql/mysql-slow.log’;
> FLUSH LOGS;
> SET GLOBAL slow_query_log = 'ON'; > SET GLOBAL slow_launch_time = 2; > SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log'; > FLUSH LOGS;
В примере:
- slow_query_log — запускает ведение журналов медленных запросов.
- slow_launch_time — указывает максимальную задержку отклика, после которой статистика запроса попадёт в журнал. В данном случае запись в логи происходит при преодолении откликом порога 2 секунды.
- slow_query_log_file — задаёт путь до используемого журнала.
Проверить статус и параметры ведения лога медленных запросов можно командой:
> SHOW VARIABLES LIKE ‘%slow%’;
> SHOW VARIABLES LIKE ‘%slow%’;
> SHOW VARIABLES LIKE '%slow%';
Выход из консоли MySQL выполняется командой:
> exit
После выполнения всех предыдущих действий, можно просмотреть логи сервера. Для этого в терминале вводится:
tail -f /var/log/mysql/mysql-slow.log
tail -f /var/log/mysql/mysql-slow.log
tail -f /var/log/mysql/mysql-slow.log
PHP-FPM
Для ведения журнала на данной оболочке, необходимо отредактировать параметры в конфигурационном файле. Для этого в терминале вводится команда:
vi /etc/php-fpm.d/www.conf
vi /etc/php-fpm.d/www.conf
vi /etc/php-fpm.d/www.conf
Далее нужно найти строки:
- request_slowlog_timeout = 10s — параметр, позволяющий указать задержку, с которой запись о длительном запросе попадёт в журнал.
- slowlog = /var/log/php-fpm/www-slow.log — параметр, указывающий путь до актуального файла логирования (.log).
После применения изменений, необходимо перезагрузить сервер PHP-FPM. Для этого в консоль вводится команда:
systemctl restart php-fpm
systemctl restart php-fpm
systemctl restart php-fpm
Просмотр логов запускается командой:
tail -f /var/log/php-fpm/www-slow.log
tail -f /var/log/php-fpm/www-slow.log
tail -f /var/log/php-fpm/www-slow.log
Анализ логов медленных запросов
Логи медленных запросов могут за незначительное время вырасти до огромных размеров. Для сортировки и отображения повторяющихся запросов рекомендуется использовать программу MySQLDumpSlow.
Для запуска просмотра логов с помощью этой утилиты, нужно составить команду по приведенному ниже алгоритму:
mysqldumpslow местонахождение/файла
mysqldumpslow местонахождение/файла
mysqldumpslow местонахождение/файла
Ведение логов в Logrotate
На больших ресурсах журналы могут достигать огромных размеров, поэтому нужно своевременно архивировать или очищать логи. С помощью утилиты Logrotate можно управлять ведением журналов: настроить период ротации (архивирование старого журнала и создание нового), период и количество хранения журналов и многое другое.
Изначально программа отсутствует в системе. Ниже приведены команды для инсталляции Logrotate из официальных репозиториев.
Ubuntu, Debian:
sudo apt install logrotate
sudo apt install logrotate
sudo apt install logrotate
CentOS:
sudo yum install logrotate
sudo yum install logrotate
sudo yum install logrotate
После установки необходимо проверить путь для будущих конфигурационных файлов. Для правильной работы они должны находится в папке «logrotate.d». Проверить данный параметр можно открыв конфигурационный файл командой:
nano /etc/logrotate.conf
В директории «RPM packages drop log rotation information into this directory» должна присутствовать строка:
include /etc/logrotate.d
Теперь создаётся конфигурационный файл «rsyslog.conf». В нём будет находиться конфигурацию по работе с логами. Для создания файла в терминале вводится команда:
sudo nano /etc/logrotate.d/rsyslog.conf
sudo nano /etc/logrotate.d/rsyslog.conf
sudo nano /etc/logrotate.d/rsyslog.conf
В окне терминала откроется текстовой редактор. Теперь нужно внести конфигурацию, как указано в образце. В качестве примера будет использоваться журнал посещений «Access.log» (Nginx).
/var/log/nginx/access.log {
/var/log/nginx/access.log {
daily
rotate 3
size 500M
compress
delaycompress
}
/var/log/nginx/access.log { daily rotate 3 size 500M compress delaycompress }
Теперь остаётся только запустить Logrotate. Для этого вводится команда:
sudo logrotate -d /etc/logrotate.d/rsyslog.conf
sudo logrotate -d /etc/logrotate.d/rsyslog.conf
sudo logrotate -d /etc/logrotate.d/rsyslog.conf
Для проверки правильности работы программы в терминале можно ввести команду:
ls /var/cron.daily/
В статье мы расскажем о том, что такое логи и как они помогут предотвратить аномальную нагрузку на сервер.
- Что такое логи
- Как читать логи
- Логи доступа (access_log)
- Логи ошибок (error_log)
- FTP-логи
- Логи операций в панели управления
- Как анализировать логи при высокой нагрузке на сервер
Что такое логи
Логи — это файлы текстового формата, в которых хранятся следующие данные:
- информация о пользователях,
- информация о действиях на сервере,
- информация о дате и времени операций,
- системная информация о работе сервера.
На хостинге SpaceWeb хранятся логи за прошедший месяц (30 дней): они создаются автоматически в хронологическом порядке. Один файл лога включает в себя историю операций за один прошедший день.
Как читать логи
Каждый log-файл имеет собственную структуру: она отличается в зависимости от типа логов. Чаще всего используются:
- логи доступа или access_log,
- логи ошибок или error_log,
- FTP-логи,
- логи операций в панели управления.
Анализ логов проводится по-разному: это зависит от операции, которую нужно отследить. Например, если вы хотите поверить визиты на сайт и в панель управления, потребуются логи доступа и логи операций в панели управления. О типах логов и их назначении расскажем ниже.
Логи доступа (access_log)
access.log — это текстовый файл, в который записываются все обращения к веб-серверу. Его можно использовать, чтобы получить информацию о посещении вашего ресурса.
Лог доступа имеет следующий вид:
test.ru 123.123.123.123 — — [01/Jan/2022:00:00:00 +0000] «GET /index.html HTTP/1.1» 200 198 «https://test.ru/» «Mozilla/5.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)» 16143 0
Где:
- test.ru — доменное имя сайта;
- 123.123.123.123 — IP-адрес, с которого обращается клиент;
- 01/Jan/2022:00:00:00 +0000 — дата и время запроса;
- GET — метод запроса;
- 200 — последний код ответа, если произошло внутреннее перенаправление (в примере — успешное обращение);
- 198 — размер ответа в байтах без HTTP-заголовка. Если ответ был размера 0, в лог-файле он отобразится знаком -;
- «https://test.ru/» «Mozilla/5.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)» — информация о клиенте (браузере, с которого посетили сайт);
- 16143 — PID процесса Apache;
- 0 — время работы процесса Apache.
Если на вашем аккаунте отключено ведение логов доступа, его можно включить в панели управления в разделе «Статистика и логи». Если вам нужны логи за прошедшие дни, запросите их в службе технической поддержки.
Логи ошибок (error_log)
error.log — это файл, в котором фиксируются все типы ошибок сервера. Логи ошибок позволяют отследить, в какой момент возникла проблема: это поможет в ее решении.
Лог ошибок (error.log) имеет следующий вид:
test.ru [Fri Jan 01 00:00:00 2022] [error] [client 123.123.123.123] File does not exist: /home/d/test/public_html/favicon.ico
Где:
- test.ru — доменное имя сайта;
- Fri Jan 01 00:00:00 2022 — дата и время возникновения ошибки;
- 123.123.123.123 — IP-адрес, с которого обратился клиент.
Если на вашем аккаунте отключено ведение лога ошибок, его можно включить в панели управления в разделе «Статистика и логи». Если вам нужны логи за прошедшие дни, запросите их в службе технической поддержки.
FTP-логи
Логи FTP помогают отследить подключения по протоколу FTP и действия при удаленном соединении с сервером.
FTP-лог имеет следующий вид:
2022-01-01T00:00:00+03:00 vhXX pure-ftpd: (?@123.123.123.123) [DEBUG] Command [user] [vhXXtest]
2022-01-01T00:01:00+03:00 vhXX pure-ftpd: (?@123.123.123.123) [INFO] vhXXtest is now logged in
2022-01-01T00:02:00+03:00 vhXX pure-ftpd: (vhXXtest@123.123.123.123) [DEBUG] Command [retr] [configuration.php]
2022-01-01T00:03:00+03:00 vhXX pure-ftpd: (vhXXtest@123.123.123.123) [NOTICE] /home/v/vhXXtest/public_html//configuration.php downloaded (5317 bytes, 77503.32KB/sec)
2022-01-01T00:04:00+03:00 vhXX pure-ftpd: (vhXXtest@123.123.123.123) [DEBUG] Command [pasv] []
2022-01-01T00:05:00+03:00 vhXX pure-ftpd: (vhXXtest@123.123.123.123) [DEBUG] Command [stor] [configuration.php]
2022-01-01T00:06:00+03:00 vhXX pure-ftpd: (vhXXtest@123.123.123.123) [NOTICE] /home/v/vhXXtest/public_html//configuration.php uploaded (5165 bytes, 985.55KB/sec)
2022-01-01T00:07:00+03:00 vhXX pure-ftpd: (vhXXtest@123.123.123.123) [INFO] Logout.
Где:
- 2022-01-01T00:00:00+03:00 — дата и время действия на сервере FTP,
- 123.123.123.123 — IP-адрес сервера,
- vhXX — имя сервера,
- vhXXtest — имя FTP-пользователя.
Логи FTP можно получить при обращении в службу технической поддержки.
Логи операций в панели управления
Логи операций позволяют отследить всю активность в панели управления SpaceWeb. Благодаря им вы сможете выявить несанкционированные посещения в системе.
Логи операций в панели управления имеют следующий вид:
46085314 Неуспешная авторизация в клиентской ПУ 123.123.123.123 2022-01-01 00:00:00
46172855 Сделан заказ на домен test.ru; mov; test 2022-01-01 00:01:00
46172895 Удалён домен test.ru test 2022-01-01 00:10:00
46518875 Выход из клиентской ПУ 123.123.123.123 test 2022-01-01 00:11:00
46554201 Создание папки /testforum test 2022-01-02 00:00:00
46554208 Создана база данных test_bd test 2022-01-02 00:10:00
46554210 Установка CMS из панели управления smf test.ru:/testforum/ test 2022-01-02 00:20:00
Где:
- 46085314 — номер операции,
- 123.123.123.123 — IP-адрес сервера,
- test — имя пользователя панели управления,
- 2022-01-01 00:00:00 — дата и время выполнения операции.
Логи операций в панели управления можно включить в разделе «Профиль» на вкладке Логи ПУ.
Как анализировать логи при высокой нагрузке на сервер
Для анализа логов подключитесь к серверу по SSH. Далее введите команду, которая подходит для вашего случая.
- Проверьте, на какой странице было наибольшее число посещений за день:
cat test.ru/access_log | awk ‘{ print $8}’ | sort | uniq -c | sort -n -k 1 | tail -n 50
Вместо test.ru укажите корневую директорию сайта.
- Чтобы проверить запросы за несколько прошедших дней, выполните команду:
cat test.ru/access_log*gz | awk ‘{ print $8}’ | sort | uniq -c | sort -n -k 1 | tail -n 50
Вместо test.ru укажите корневую директорию сайта. После этого сформируется архив с журналом логов.
- Выявить аномальное число запросов с одного IP-адреса за день:
cat test.ru/access_log | awk ‘{ print $2}’ | sort | uniq -c | sort -n -k 1 | tail -n 50
Вместо test.ru укажите корневую директорию сайта.
- Чтобы проверить запросы за несколько прошедших дней, выполните команду:
cat test.ru/access_log*gz | awk ‘{ print $2}’ | sort | uniq -c | sort -n -k 1 | tail -n 50
Вместо test.ru укажите корневую директорию сайта. После этого сформируется архив с журналом логов.
Содержание:
- Важные логи сайта
- Расположение логов
- Чтение записей в логах
- Просмотр с помощью команды tail
- Просмотр с помощью ISPManager
- Программы для анализа логов
- Ведение логов медленных запросов сервера
- Ведение логов с помощью Logrotate
Логи сайта — это системные журналы, позволяющие получить информацию о посещении сайта ботами и пользователями, а также выявить скрытые проблемы на сервере — ошибки, битые ссылки, медленные запросы от сервера и многое другое.
Важные логи сайта
- Access.log — логи посещений пользователей и ботов. Позволяет составить более точную и подробную статистику, нежели сторонние ресурсы, выполняющие внешнее сканирование сайта и отправляющие ряд ненужных запросов серверу. Благодаря данному логу можно получить информацию об используемом браузере и IP-адрес посетителя, данные о местонахождении клиента (страна и город) и многое другое. Стоит обратить внимание, если сайт имеет высокую посещаемость, то анализ логов сервера потребует больше времени. Поэтому для составления статистики стоит использовать специализированные программы (анализаторы).
- Error.log — программные ошибки сервера. Стоит внимательно отнестись к анализу данного лога, ведь боты поисковиков, сканируя, получают все данные о работе сайта. При обнаружении большого количества ошибок, сайт может попасть под санкции поисковых систем. В свою очередь из записей данного журнала можно узнать точную дату и время ошибки, IP-адрес получателя, тип и описание ошибки.
- Slow.log (название зависит от используемой оболочки сервера) — в данный журнал записываются медленные запросы сервера. Так принято обозначать запросы с повышенным порогом задержки, выданные пользователю. Этот журнал позволяет выявить слабые места сервера и исправить проблему. Ниже будет рассмотрен способ включить ведение данного лога на разных типах серверов, а также настройка задержки, с которой записи будут заноситься в файл.
Расположение логов
Важно обратить внимание, что местоположение логов сайта по умолчанию зависит от используемого типа оболочки и может быть изменено администратором.
Стандартные пути до Error.log
Nginx
/var/log/nginx/error.log
Php-Fpm
/var/log/php-fpm/error.log
Apache (CentOS)
/var/log/httpd/error_log
Apache (Ubuntu, Debian)
/var/log/apache2/error_log
Стандартные пути до Access.log
Nginx
/var/log/nginx/access.log
Php-Fpm
/var/log/php-fpm/access.log
Apache (CentOS)
/var/log/httpd/access_log
Apache (Ubuntu, Debian)
/var/log/apache2/access_log
Чтение записей в логах
Записи в логах имеют структуру: одно событие – одна строка.
Записи в разных логах имеют общие черты, но количество подробностей отличается. Далее будут приведены примеры строк из разных системных журналов.
Примеры записей
Error.log
[Sat Sep 1 15:33:40.719615 2019] [:error] [pid 10706] [client 66.249.66.61:60699] PHP Notice: Undefined variable: moduleclass_sfx in /var/data/www/site.ru/modules/contacts/default.php on line 14
В приведенном примере:
- [Sat Sep 1 15:33:40.719615 2019] — дата и время события.
- [:error] [pid 10706] — ошибка и её тип.
- [client 66.249.66.61:60699] — IP-адрес подключившегося клиента.
- PHP Notice: Undefined variable: moduleclass_sfx in — событие PHP Notice. В данной ситуации — обнаружена неизвестная переменная.
- /var/data/www/site.ru/modules/contacts/default.php on line 14 — путь и номер строки в проблемном файле.
Access.log
194.61.0.6 – alex [10/Oct/2019:15:32:22 -0700] "GET /apache_pb.gif HTTP/1.0" 200 5396 "http://www.mysite/myserver.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"
В приведенном примере:
- 194.61.0.6 — IP-адрес пользователя.
- alex — если пользователь зарегистрирован в системе, то в логах будет указан идентификатор.
- [10/Oct/2019:15:32:22 -0700]— дата и время записи.
- «GET /apache_pb.gif HTTP/1.0» — «GET» означает, что определённый документ со страницы сайта был отправлен пользователю. Существует команда «POST», наоборот отправляет конкретные данные (комментарий или любое другое сообщение) на сервер . Далее указан извлечённый документ «Apache_pb.gif», а также использованный протокол «HTTP/1.0».
- 200 5396 — код и количество байтов документа, которые были возвращены сервером.
- «http://www. www.mysite/myserver.html»— страница, с которой был произведён запрос на извлечение документа «Apache_pb.gif».
- «Mozilla/4.08 [en] (Win98; I ;Nav)» — данные о пользователе, которой произвёл запрос (используемый браузер и операционная система).
Просмотр логов сервера с помощью команды tail
Выполнить просмотр логов в Linux можно с помощью команды tail. Данный инструмент позволяет смотреть записи в логах, выводя последние строки из файла. По умолчанию tail выводит 10 строк.
Первый вариант использования Tail
tail -f /var/log/syslog
Аргумент «-f» позволяет команде делать просмотр событий в режиме реального времени, в ожидании новых записей в лог файлах. Для прерывания процесса следует нажать сочетание клавиш «Ctrl+C».
На место переменной «/var/log/syslog» в примере следует подставить актуальный адрес до нужных системных журналов.
Второй вариант использования Tail
tail -F /var/log/syslog
В Linux логи веб-сервера не ведутся до бесконечности, поскольку это усложняет их дальнейший анализ. При преодолении лимита записей, система переименует переполненный строками файл журнала и отправит в «архив». Вместо старого файла создастся новый, но с прежним названием.
Если будет использоваться аргумент «-f», команда продолжит отслеживание старого, переименованного журнала. Данный метод делает невозможным просмотр логов в реальном времени, поскольку файл более не актуален.
При использовании аргумента «-F», команда, после окончания записи старого журнала, перейдёт к чтению нового файла с логами. В таком случае просмотр логов в режиме реального времени продолжится.
Аналог команды Tail
tailf /var/log/syslog
Отличие команды tailf от предыдущей заключается в том, что она не обращается к файлу и файловой системе в период, когда запись логов не происходит. Это экономит ресурсы системы и заряд, если используется нестационарное устройство — ноутбук, смартфон или планшет.
Недостаток данного способа — проблема с чтением больших файлов. Если системный журнал достаточно большой, возникает вероятность отказа в работе программы.
Изменение стандартного количества строк для вывода
Как и отмечалось выше, по умолчанию выводится 10 строк. Если требуется увеличить или уменьшить их количество, в команду добавляется аргумент «-n» и необходимое число строк.
Пример:
tail -f -n 100 /var/log/syslog
При использовании данной команды будут показаны последние 100 строк журнала.
Просмотр логов с помощью ISPManager
Если на сервере установлен ISPManager, логи можно легко читать, используя приведенный ниже алгоритм.
- На главной странице, в панели инструментов «WWW» нужно нажать на вкладку «Журналы».
- ISPManager выдаст журналы посещений и серверных ошибок в виде:
- ru.access.log;
- ru.error.log.*
* Вместо «newdomen.ru» из примера в выдаче будет название актуального домена.
Открыть файл лога можно, нажав на «Посмотреть» в верхнем меню.
- Для просмотра всех записей журнала, необходимо нажать на «Скачать» и сохранить файл на локальный носитель.
- Более старые версии логов можно найти во вкладке «Архив».
Программы для анализа логов
Анализировать журналы с большим количеством данных вручную не только сложно, но и чревато ошибками. Для упрощения работы с лог файлами было создано большое количество сервисов и утилит.
Инструменты для анализа логов делятся на два основных типа — статические и работающие в режиме реального времени.
Статические программы
Данный тип выполняет работу только с извлеченными логами, но обеспечивает быструю сортировку данных.
WebLog Expert
Возможности
- Предоставление информации об активность сайта, количестве посетителей, доступ к файлам, URL страницы, ссылающиеся страницы, информацию о пользователе (браузер и операционная система).
- Создание отчётов в формате HTML (.html), PDF (.pdf), CSV (.csv).
- Поддерживает анализ логов Nginx, Apache, ISS.
- Чтение файлов даже в архивах ZIP (.zip), GZ (.gz).
Web Log Explorer
Возможности
- Создание многоуровневых отчётов, включающих количество посетителей, маршруты пользователей по сайту, местоположение хостов (страна и город), указанные в поисковике ключевые слова.
- Поддержка более 43 форматов логов.
- Возможность прямой загрузки логов с FTP, HTTP сервера.
- Чтение архивированных журналов.
Программы для анализа в режиме реального времени
Эти инструменты встраиваются в программную среду сервера, анализируют данные в реальном времени и записывают непрерывный отчёт.
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, то необходимо создать каталог и сам файл для ведения журнала с помощью команд:
mkdir /var/log/mysql
touch /var/log/mysql/mysql-slow.log
Стоит изменить владельца файла, чтобы избежать дальнейших проблем с записью логов. Делается это командой:
chown mysql:mysql /var/log/mysql/mysql-slow.log
После выполнения предыдущих действий, нужно совершить вход в командную строку MySQL под учётной записью суперпользователя:
mysql -uroot -p
Для запуска и настройки ведения логов нужно последовательно ввести в терминале следующие команды:
> SET GLOBAL slow_query_log = 'ON'; > SET GLOBAL slow_launch_time = 2; > SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log'; > FLUSH LOGS;
В примере:
- slow_query_log — запускает ведение журналов медленных запросов.
- slow_launch_time — указывает максимальную задержку отклика, после которой статистика запроса попадёт в журнал. В данном случае запись в логи происходит при преодолении откликом порога 2 секунды.
- slow_query_log_file — задаёт путь до используемого журнала.
Проверить статус и параметры ведения лога медленных запросов можно командой:
> SHOW VARIABLES LIKE '%slow%';
Выход из консоли MySQL выполняется командой:
> exit
После выполнения всех предыдущих действий, можно просмотреть логи сервера. Для этого в терминале вводится:
tail -f /var/log/mysql/mysql-slow.log
PHP-FPM
Для ведения журнала на данной оболочке, необходимо отредактировать параметры в конфигурационном файле. Для этого в терминале вводится команда:
vi /etc/php-fpm.d/www.conf
Далее нужно найти строки:
- request_slowlog_timeout = 10s — параметр, позволяющий указать задержку, с которой запись о длительном запросе попадёт в журнал.
- slowlog = /var/log/php-fpm/www-slow.log — параметр, указывающий путь до актуального файла логирования (.log).
После применения изменений, необходимо перезагрузить сервер PHP-FPM. Для этого в консоль вводится команда:
systemctl restart php-fpm
Просмотр логов запускается командой:
tail -f /var/log/php-fpm/www-slow.log
Анализ логов медленных запросов
Логи медленных запросов могут за незначительное время вырасти до огромных размеров. Для сортировки и отображения повторяющихся запросов рекомендуется использовать программу MySQLDumpSlow.
Для запуска просмотра логов с помощью этой утилиты, нужно составить команду по приведенному ниже алгоритму:
mysqldumpslow местонахождение/файла
Ведение логов в Logrotate
На больших ресурсах журналы могут достигать огромных размеров, поэтому нужно своевременно архивировать или очищать логи. С помощью утилиты Logrotate можно управлять ведением журналов: настроить период ротации (архивирование старого журнала и создание нового), период и количество хранения журналов и многое другое.
Изначально программа отсутствует в системе. Ниже приведены команды для инсталляции Logrotate из официальных репозиториев.
Ubuntu, Debian:
sudo apt install logrotate
CentOS:
sudo yum install logrotate
После установки необходимо проверить путь для будущих конфигурационных файлов. Для правильной работы они должны находится в папке «logrotate.d». Проверить данный параметр можно открыв конфигурационный файл командой:
nano /etc/logrotate.conf
В директории «RPM packages drop log rotation information into this directory» должна присутствовать строка:
include /etc/logrotate.d
Теперь создаётся конфигурационный файл «rsyslog.conf». В нём будет находиться конфигурацию по работе с логами. Для создания файла в терминале вводится команда:
sudo nano /etc/logrotate.d/rsyslog.conf
В окне терминала откроется текстовой редактор. Теперь нужно внести конфигурацию, как указано в образце. В качестве примера будет использоваться журнал посещений «Access.log» (Nginx).
/var/log/nginx/access.log { daily rotate 3 size 500M compress delaycompress }
Теперь остаётся только запустить Logrotate. Для этого вводится команда:
sudo logrotate -d /etc/logrotate.d/rsyslog.conf
Для проверки правильности работы программы в терминале можно ввести команду:
ls /var/cron.daily/
Логи сервера
Если вы хотите знать всё про логи сервера, читайте нашу статью. Мы расскажем, что такое logs, для чего они нужны и покажем, как посмотреть их.
Что такое логи
Чтобы объяснить, что такое логи сервера, скажем несколько слов о самих серверах.
На серверах хранятся файлы сайтов. Чтобы перейти на сайт, пользователь заходит в браузер и вбивает запрос. Затем браузер обращается к серверу, получает файлы нужного сайта и отображает их пользователю. Попадая на сайт, посетитель совершает различные действия — переходит на страницы, оформляет заказ, совершает оплату и другое. При каждом действии посетитель и сервер взаимодействуют друг с другом на уровне интернет-системы.
Логи — это текстовые файлы, в которых хранится информация о пользователях, их взаимодействии с сервером, а также системная информация о работе сервера. Логи формируются в автоматическом режиме и сохраняются в хронологическом порядке. Поэтому их также называют журналом сервера (Server Logs).
Можно выделить несколько основных типов логов:
- сведения о каждом обращении (IP-адрес и тип браузера посетителя) — access_log,
- протоколы действий каждого посетителя (из какого источника перешел на сайт, сколько на нём находился, какие совершал операции и другое),
- записи о сбоях и ошибках — error_log,
- записи о входящих и исходящих сообщениях — почтовые логи,
- сведения о загрузках и основные события в системе,
- данные о количестве входов по FTP-соединению,
- данные о действиях с файерволом, DNS-сервером, ядром системы,
- статистика использования ресурсов сервера, время и количество входов в панель, обновление лицензии.
Где хранятся логи сервера
В некоторых случаях для хранения логов используют отдельный файловый сервер. Но чаще всего логи хранятся на жёстком диске основного сервера. Они располагаются в корневой директории хостинга в системной папке logs. Точный путь до лога будет зависеть от операционной системы сервера. Например, логи SSH Ubuntu хранятся в /var/log/auth.log, а логи SSH CentOS в /var/log/secure.
Зачем проверять логи
Чаще всего обращаться к содержимому логов и анализировать его приходится системным администраторам. Анализ логов необходим в следующих ситуациях:
- сбои в работе сервера,
- резкое повышение нагрузки,
- подозрение на спам-атаки и другое.
Однако уметь анализировать журнал полезно не только админам, но и владельцам сайтов и другим пользователям с доступом в админку. Для этого нужно понимать, как устроены логи.
Как устроены логи
Каждый тип logs имеет свою структуру. В качестве примера разберём структуру access_log:
123.123.123.123 - - [01/Janr/2021:10:00:00 +0300] "GET /wp-includes/feed.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"
Здесь:
- 123.123.123.123 — IP-адрес, с которого был сделан запрос,
- [01/Janr/2021:10:00:00 +0300] — дата и время запроса,
- GET — метод запроса,
- /wp-includes/feed.php — объект запроса,
- HTTP/1.0 — протокол, по которому прошёл запрос,
- 200 — код ответа,
- Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36 — информация о посетителе.
Также структура логов зависит от операционной системы сервера. Например, логи сервера Windows устроены в виде структурированной таблицы. Поэтому, чтобы научиться «читать» логи, нужна практика.
Если вы разобрались со структурой logs, можно приступать к их просмотру. Существует несколько способов, с помощью которых можно посмотреть журнал сайта. Выбор способа будет зависеть от типа платформы, на которой расположен ваш сайт — VPS-сервер или хостинг.
Как проверить логи сервера VPS
Чтобы посмотреть логи:
- 1.
-
2.
Введите команды cd logs и ls —all, чтобы посмотреть содержимое папки logs:
Логи сервера Linux
-
3.
Откройте нужный файл.
Готово.
Как проверить логи хостинга
Чтобы посмотреть содержимое журнала, нужно открыть папку и скачать нужный файл на локальный ПК. Это можно сделать одним из двух способов:
- в хостинг-панели управления, если вы являетесь клиентом REG.RU,
- через подключение по FTP.
В панели управления хостингом
- 1.
-
2.
Перейдите в Менеджер файлов, а затем в директорию logs:
-
3.
Выделите строку с названием нужного типа файла и нажмите Скачать:
Готово.
Обратите внимание: если вид вашей панели управления отличается от представленного в статье, в разделе «Основная информация» переключите тему с paper_lantern на jupiter.
- 1.
-
2.
В разделе «Файлы» нажмите Менеджер файлов:
-
3.
Кликните на папку logs:
-
4.
Выделите строку с названием нужного типа файла и нажмите Скачать:
Готово.
- 1.
-
2.
Перейдите во вкладку «Файлы», а затем в директорию logs:
-
3.
Выделите строку с названием нужного типа файла и нажмите Скачать:
Готово.
По FTP
Чтобы скачать логи:
- 1.
-
2.
Перейдите в директорию logs:
-
3.
Выделите строку с названием нужного типа файла и нажмите Просмотр/Правка:
Теперь вы знаете, что такое журнал сайта и где можно посмотреть логи сервера.
(PHP 4, PHP 5, PHP 7, PHP
error_log — Отправляет сообщение об ошибке заданному обработчику ошибок
Описание
error_log(
string $message
,
int $message_type
= 0,
?string $destination
= null
,
?string $additional_headers
= null
): bool
Список параметров
-
message
-
Сообщение об ошибке, которое должно быть логировано.
-
message_type
-
Определяет куда отправлять ошибку.
Возможны следующие значения:Типы журналов error_log()
0 Сообщение message
отправляется в системный регистратор PHP, используя
механизм логирования операционной системы, или файл, в зависимости от значения директивы
error_log
в конфигурационном файле. Это значение по умолчанию.1 Сообщение message
отправляется электронной почтой на адрес, установленный в параметре
destination
. Это единственный тип сообщения, где используется четвёртый параметр
additional_headers
.2 Больше не используется. 3 message
применяется к указанному в
destination
файлу. Перенос строки автоматически не добавляется в конец
message
.4 Сообщение message
отправляется напрямую в обработчик
логера SAPI. -
destination
-
Назначение. Устанавливается в зависимости от параметра
message_type
. -
additional_headers
-
Дополнительные заголовки. Используется, когда значение параметра
message_type
—1
.
Данный тип сообщения использует ту же внутреннюю функцию, что и
mail().
Возвращаемые значения
Возвращает true
в случае успешного выполнения или false
в случае возникновения ошибки.
Если message_type
равен нулю, функция всегда возвращает true
,
независимо от того, может ли ошибка логироваться или нет.
Список изменений
Версия | Описание |
---|---|
8.0.0 |
Параметр destination иadditional_headers теперь допускают значение null.
|
Примеры
Пример #1 Примеры использования error_log()
<?php
// Отправляет уведомление посредством серверного лога, если мы не можем
// подключиться к базе данных.
if (!Ora_Logon($username, $password)) {
error_log("База данных Oracle недоступна!", 0);
}// Уведомить администратора по электронной почте, если невозможно выделить ресурсы для FOO
if (!($foo = allocate_new_foo())) {
error_log("Большая проблема, мы выпали из FOO!", 1,
"operator@example.com");
}// другой способ вызвать error_log():
error_log("Вы ошиблись!", 3, "/var/tmp/my-errors.log");
?>
Примечания
Внимание
error_log() не является бинарно-безопасной функцией. message
обрезается по null-символу.
Подсказка
message
не должен содержать null-символ. Учтите, что message
может передаваться в файл, по почте, в syslog и т.д. Используйте подходящую преобразующую или экранирующую функцию, base64_encode(), rawurlencode() или addslashes() перед вызовом error_log().
kevindougans at gmail dot com ¶
12 years ago
Advice to novices: This function works great along with "tail" which is a unix command to watch a log file live. There are versions of Tail for Windows too, like Tail for Win32 or Kiwi Log Viewer.
Using both error_log() and tail to view the php_error.log you can debug code without having to worry so much about printing debug messages to the screen and who they might be seen by.
Further Note: This works even better when you have two monitors setup. One for your browser and IDE and the other for viewing the log files update live as you go.
Sion ¶
4 years ago
DO NOT try to output TOO LARGE texts in the error_log();
if you try to output massive amounts of texts it will either cut of the text at about 8ooo characters (for reasonable massive strings, < 32 K characters) or (for insanely massive strings, about 1.6 million characters) totally crash without even throwing an error or anything (I even put it in a try/catch without getting any result from the catch).
I had this problem when I tried to debug a response from a wp_remote_get(); all of my error_log() worked as they should, except for ONE of them... (-_-)
After about a day of debugging I finally found out why & that's why I type this.
Apparently the response contained a body with over 1.6 million chars (or bytes? (whatever strlen() returns)).
If you have a string of unknown length, use this:
$start_index = 0;
$end_index = 8000;
error_log( substr( $output_text , $start_index , $end_index ) );
frank at booksku dot com ¶
16 years ago
Beware! If multiple scripts share the same log file, but run as different users, whichever script logs an error first owns the file, and calls to error_log() run as a different user will fail *silently*!
Nothing more frustrating than trying to figure out why all your error_log calls aren't actually writing, than to find it was due to a *silent* permission denied error!
i dot buttinoni at intandtel dot com ¶
14 years ago
Be carefull. Unexpected PHP dies when 2GByte of file log reached (on systems having upper file size limit).
A work aorund is rotate logs :)
php at kennel17 dot NOSPAM dot co dot uk ¶
17 years ago
It appears that the system log = stderr if you are running PHP from the command line, and that often stderr = stdout. This means that if you are using a custom error to both display the error and log it to syslog, then a command-line user will see the same error reported twice.
Anonymous ¶
19 years ago
when using error_log to send email, not all elements of an extra_headers string are handled the same way. "From: " and "Reply-To: " header values will replace the default header values. "Subject: " header values won't: they are *added* to the mail header but don't replace the default, leading to mail messages with two Subject fields.
<?php
error_log
("sometext", 1, "zigzag@my.domain",
"Subject: FoonFrom: Rizzlas@my.domainn");?>
---------------%<-----------------------
To: zigzag@my.domain
Envelope-to: zigzag@my.domain
Date: Fri, 28 Mar 2003 13:29:02 -0500
From: Rizzlas@my.domain
Subject: PHP error_log message
Subject: Foo
Delivery-date: Fri, 28 Mar 2003 13:29:03 -0500
sometext
---------------%<---------------------
quoth the docs: "This message type uses the same internal function as mail() does."
mail() will also fail to set a Subject field based on extra_header data - instead it takes a seperate argument to specify a "Subject: " string.
php v.4.2.3, SunOS 5.8
russ at russtanner dot com ¶
3 years ago
You can easily filter messages sent to error_log() using "tail" and "grep" on *nix systems. This makes monitoring debug messages easy to see during development.
Be sure to "tag" your error message with a unique string so you can filter it using "grep":
In your code:
error_log("DevSys1 - FirstName: $FirstName - LastName: $Lastname");
On your command line:
tail -f /var/log/httpd/error_log | grep DevSys1
In this example, we pipe apache log output to grep (STDIN) which filters it for you only showing messages that contain "DevSys1".
The "-f" option means "follow" which streams all new log entries to your terminal or to any piped command that follows, in this case "grep".
Matthew Swift ¶
3 years ago
Relative paths are accepted as the destination of message_type 3, but beware that the root directory is determined by the context of the call to error_log(), which can change, so that one instance of error_log () in your code can lead to the creation of multiple log files in different locations.
In a WordPress context, the root directory will be the site's root in many cases, but it will be /wp-admin/ for AJAX calls, and a plugin's directory in other cases. If you want all your output to go to one file, use an absolute path.
paul dot chubb at abs dot gov dot au ¶
14 years ago
When logging to apache on windows, both error_log and also trigger_error result in an apache status of error on the front of the message. This is bad if all you want to do is log information. However you can simply log to stderr however you will have to do all message assembly:
LogToApache($Message) {
$stderr = fopen('php://stderr', 'w');
fwrite($stderr,$Message);
fclose($stderr);
}
SJL ¶
15 years ago
"It appears that the system log = stderr if you are running PHP from the command line"
Actually, it seems that PHP logs to stderr if it can't write to the log file. Command line PHP falls back to stderr because the log file is (usually) only writable by the webserver.
stepheneliotdewey at GmailDotCom ¶
15 years ago
Note that since typical email is unencrypted, sending data about your errors over email using this function could be considered a security risk. How much of a risk it is depends on how much and what type of information you are sending, but the mere act of sending an email when something happens (even if it cannot be read) could itself imply to a sophisticated hacker observing your site over time that they have managed to cause an error.
Of course, security through obscurity is the weakest kind of security, as most open source supporters will agree. This is just something that you should keep in mind.
And of course, whatever you do, make sure that such emails don't contain sensitive user data.
p dot lhonorey at nospam-laposte dot net ¶
16 years ago
Hi !
Another trick to post "HTML" mail body. Just add "Content-Type: text/html; charset=ISO-8859-1" into extra_header string. Of course you can set charset according to your country or Env or content.
EG: Error_log("<html><h2>stuff</h2></html>",1,"eat@joe.com","subject :lunchnContent-Type: text/html; charset=ISO-8859-1");
Enjoy !
eguvenc at gmail dot com ¶
14 years ago
<?php
//Multiline error log class
// ersin güvenç 2008 eguvenc@gmail.com
//For break use "n" instead 'n'
Class log {
//
const USER_ERROR_DIR = '/home/site/error_log/Site_User_errors.log';
const GENERAL_ERROR_DIR = '/home/site/error_log/Site_General_errors.log';
/*
User Errors...
*/
public function user($msg,$username)
{
$date = date('d.m.Y h:i:s');
$log = $msg." | Date: ".$date." | User: ".$username."n";
error_log($log, 3, self::USER_ERROR_DIR);
}
/*
General Errors...
*/
public function general($msg)
{
$date = date('d.m.Y h:i:s');
$log = $msg." | Date: ".$date."n";
error_log($msg." | Tarih: ".$date, 3, self::GENERAL_ERROR_DIR);
}
}
$log = new log();
$log->user($msg,$username); //use for user errors
//$log->general($msg); //use for general errors
?>
franz at fholzinger dot com ¶
17 years ago
In the case of missing your entries in the error_log file:
When you use error_log in a script that does not produce any output, which means that you cannot see anything during the execution of the script, and when you wonder why there are no error_log entries produced in your error_log file, the reasons can be:
- you did not configure error_log output in php.ini
- the script has a syntax error and did therefore not execute
daniel dot fukuda at gmail dot com ¶
13 years ago
If you have a problem with log file permission *silently*
it's best to leave error_log directive unset so errors will be written in your Apache log file for current VirtualHost.
Anonymous ¶
2 years ago
Depending on the error, you may also want to add an error 500 header, and a message for the user:
$message = 'Description of the error.';
error_log($message);
header($_SERVER['SERVER_PROTOCOL'] . ' 500 Internal Server Error', true, 500);
exit($message);
Robert Chapin ¶
4 years ago
When error_log() unexpectedly uses stdout, you should check if the php.ini value for error_log is empty in your CLI environment. Something as simple as this might restore expected behavior:
<?php ini_set('error_log', 'error_log'); ?>
kazezb at nospam dot carleton dot edu ¶
17 years ago
It appears that error_log() only logs the first line of multi-line log messages. To log a multi-line message, either log each line individually or write the message to another file.
Anonymous ¶
13 years ago
After scouring the internet for getting event logging to
work in syslog on Windows 2003, I found the following
from this post and was able to successfully get Windows
Event Viewer to log PHP errors/notices:
http://forums.iis.net/p/1159662/1912015.aspx#1913338
1. Copy the PHP 5 binaries to "C:php".
2. Right-click My Computer and select Properties to bring
up the Computer Properties dialog. Switch to the Advanced
tab and click Environment Variables. Find the system
environment variable PATH, edit it and add ";C:php"
(without the quotes) to the end.
3. Make sure that the configuration file "php.ini" resides
in the directory "C:php" and contains the correct path
settings.
4. DELETE any old "php.ini" files from "C:WINDOWS"
and other directories.
5. Open REGEDIT, navigate to the key
"HKLMSOFTWAREPHP" and DELETE the string value
"IniFilePath" from there. It is outdated and no longer
necessary!
6. Modify NTFS security permissions of the directory
"C:php" to give Read and Execute permissions to (1) the
IIS Guest Account and (2) the group IIS_WPG.
7. Modify NTFS security permissions of the directories
"C:phpsession" and "C:phpupload" to give additional
Modify permissions to (1) the IIS Guest Account and (2)
the group IIS_WPG.
8. Navigate to the registry key
"HKLMSYSTEMCurrentControlSetServicesEventlog
Application" and edit the value "CustomSD" there. Find
the substring "(D;;0xf0007;;;BG)" which Denies access to
the application event log for Builtin Guest accounts (like
the IIS Web User account) and replace this substring with
"(A;;0x3;;;BG)" which allows read and write access. Please
pay attention to leave the rest of the security string intact.
Damaging this value can have dangerous effects!
9. Create or update the registry key
"HKLMSYSTEMCurrentControlSetServicesEventlogApplication
PHP-5.2.0" (adapt the last to your version part
if necessary) with the following values:
* "EventMessageFile" (REG_EXPAND_SZ) = "C:phpphp5ts.dll"
* "TypesSupported" (REG_DWORD) = 7
Как посмотреть логи
- Что такое логи сервера
- Как проверить логи сервера
- Как посмотреть логи хостинга
В этой статье мы расскажем, что такое логи сервера, где они хранятся и как посмотреть их на разных операционных системах и веб-серверах.
Что такое логи сервера
Логи сервера (англ. Server Logs ― журнал сервера) ― это текстовые файлы, в которые в хронологическом порядке записывается информация. Обычно это системная информация о работе сервера и взаимодействии пользователей с ним.
Логи отличаются тем, к каким приложениям они относятся, и тем, какую информацию они несут. Вот несколько типов логов:
- логи доступа (access.log) — в них фиксируются обращения к сайтам,
- логи ошибок (error.log) — в них веб-сервер фиксирует ошибки при обращении к сайтам,
- логи баз данных — в них фиксируются действия с базами данных,
- почтовые логи — в них содержится информация о недоставленных, отправленных и принятых письмах.
Логи могут храниться как на самом сервере, чьи события логируются, так и на отдельном файловом сервере.
Как проверить логи сервера
Рассмотрим несколько вариантов логов на серверах с операционными системами Ubuntu и CentOS. И в Ubuntu, и в CentOS директория /var/log ― это место, где хранятся логи сервера. Мы расскажем о некоторых лог-файлах из этой папки.
Обратите внимание: чтобы выполнить команды, приведённые ниже, подключитесь к серверу по SSH.
Логи SSH CentOS
Логи авторизаций (в том числе SSH-подключений) на сервере с CentOS находятся в файле /var/log/secure. Чтобы открыть этот файл, воспользуйтесь командой:
sudo nano /var/log/secure
Чтобы получить из файла только неудачные попытки подключений по SSH, введите:
grep -a "Failed password" /var/log/secure
Чтобы вывести логи только SSH-подключений:
grep -a “sshd” /var/log/secure
Если вы хотите посмотреть логи подключений конкретного пользователя:
grep -a “username” /var/log/secure
Вместо username введите имя пользователя.
Логи SSH Ubuntu
Журнал авторизации пользователей в Ubuntu находится в файле /var/log/auth.log.
Открыть всё содержимое файла:
sudo nano /var/log/auth.log
Вывести неудачные попытки подключений:
grep -a "Failed password" /var/log/auth.log
Вывести логи всех SSH-подключений:
grep -a "sshd" /var/log/auth.log
Логи подключений конкретного пользователя:
grep -a "username" /var/log/auth.log
Вместо username введите имя пользователя.
Как посмотреть логи хостинга
Посмотреть логи хостинга можно через панель управления ISPmanager или через подключение по FTP или SSH.
ISPmanager
- Откройте панель управления хостингом ISPmanager.
- В левом меню нажмите Менеджер файлов:
- Откройте директорию logs:
В этой папке вы найдёте лог-файлы ваших сайтов:
В названии каждого файла указано имя сайта и тип логов:
- domain-name.ru.access.log ― это логи доступа к сайту domain-name.ru,
- domain-name.ru.error.log ― это логи ошибок сайта domain-name.ru.
Готово, теперь вы знаете, как посмотреть логи ваших сайтов через панель управления ISPmanager.
FTP
- Подключитесь к хостингу по FTP.
- Откройте директорию /logs:
- Чтобы, не скачивая, открыть лог-файл в текстовом редакторе, кликните правой кнопкой мыши на нужный файл и нажмите на Просмотр/правка:
Готово, теперь вы знаете, как проверить логи сайтов на хостинге через FTP.
SSH
- Подключитесь к услуге хостинга по SSH.
- Перейдите в директорию /logs при помощи команды:
cd logs
- Выведите список файлов на экран:
ls -la
- Откройте нужный файл при помощи текстового редактора Vim:
vim log-file-name
Вместо log-file-name введите имя лог-файла.
- Чтобы закрыть редактор без сохранения изменений в файле, нажмите ESC и введите:
:q!
Готово, теперь вы знаете, как проверить логи сайтов на хостинге через SSH.
Вступление
Логи это специальные текстовые файлы с записями всех обращений к сайту. Каждая запись в логе содержит временную метку, короткий ответ сервера и тип запроса. Различаются два типа логов: логи ошибок и логии доступа.
Чаще всего , логи сайта находятся в каталоге сайта в отдельной папке [logs]. В папке [logs],обычно, лежат два файла error_log и access_log.С помощью этих файлов вы всегда можете выяснить ошибку, произошедшую га сайте. Чтобы узнать ошибку нужно примерно вспомнить, когда ошибка возникла и посмотреть записи об ошибках на этот момент.
Журналы ошибок
Журнал access_log
В логе access_log собираются все записи о вошедших на сайт посетителях, в том числе входы поисковых машин и спам ботов. С помощью записей в этих журналах можно посмотреть, с какого IP адреса и когда был сделан вход на сайт, и некоторую информацию об этом посетителе;
Журнал error_log
В логе error_log собираются все ошибки, произошедшие при работе скриптов сайта. Открыв этот файлы можно определить источник и причину ошибки, для её исправления.
Журнал xferlog_regular
В файле xferlog_regular вы найдете записи обо всех изменениях, которые внесены с через FTP клиент. С помощью этих записей, вы можете узнать, какие изменения были сделаны за последнее время по FTP, и с какого IP адреса эти изменения были внесены.Этот лог есть не на всех хостингах.
Как посмотреть и найти ошибку
Чтобы посмотреть ошибки, откройте, для начала, файл error_log.Открыть файл нужно в текстовом редакторе и внимательно изучить записи, обращая внимание на дату и время, когда сделана запись. Вспомните, что вы делали на сайте, какое расширение устанавливали или удаляли, свяжите это по времени с записями в логе и это поможет выявить причину ошибки.
Логи веб-сервера Apache
Кроме логов перечисленных выше, хостинг может предоставлять вам доступ к ошибкам, происходящим на веб-сервере Apache. Ищите отдельную кнопку в административной панели на сервере хостинга, типа «Журнал логов Apache».
Здесь также должно быть два журнала:
- Лог ошибок Apache;
- Лог использования Apache.
Выводы статьи
- Найти, а тем более исправить самостоятельно ошибку на сайте без доступа к записываемым логам домена НЕЛЬЗЯ!
- Если запись логов для домена не ведется, то нужно обратиться в support хостинга, они скажут, как ее включить, или где ее посмотреть.
- Доступ к своим логам не может быть закрыт и не должен стоить дополнительной платы.
- На большинстве хостингах ведутся как минимум, два лога. Лог Error— ошибки в работе скриптов на сайте и Access –лог всех посещений сайта, включая всех ботов.
- В зависимости от настроек хостинга, логии домена могут храниться в разных местах и по-разному архивироваться. Внимательно просмотрите свою панель на сервере или напишите в свой support.
Приведу фото, как организован доступ к логам в DirectAdmin
©Joomla-abc.ru