Куда php пишет логи windows

Обновлено: 08.07.2024

Термины Редактор: Дмитрий Сокол 20376 22 мин Аудио

Лог-файлы (файлы регистрации, журнальные файлы) на Linux - это текстовые файлы о событиях, произошедших на сайте: информация о параметрах посещений сайта и ошибках, которые возникали на нем.

Вебмастерам нужно получать информацию о том, как работает их сайт и сервер. Это можно узнать из log-файлов.

На виртуальном хостинге владельцы сайтов работают с логами web-сервера, доступ к которым предоставляет провайдер.
На VPS/VDS и выделенных серверах можно работать с самыми разнообразными логами, которые записывают все работающие на сервере службы.

Информация, хранящаяся в лог-файлах, служит основой для диагностики работы различных системных служб, а также для разнообразной аналитики, например, о посещаемости сайта или о попытках взлома системы.

На платформе Windows также имеется служба журналирования событий, но там информация записывается не в текстовые файлы, а в журналы специального формата, доступ к информации которых возможен через службу Event Viewer.

Log-файлы и виртуальный хостинг

Провайдер хостинга обеспечивает доступ к лог-файлам web-сервера через панель управления. Например, у провайдера Beget это выглядит так.

Также доступ к лог-файлам конкретного сайта можно получить через файл-менеджер (или по протоколу FTP).

У провайдера Beget в менеджере файлов их можно найти здесь.

При использовании популярной панели ISPmanager log-файлы доступны пользователю и располагаются в каталоге /log. Для каждого из сайтов присутствуют два лог-файла:

посещений (doman.name.access.log);
ошибок (domain.name.error.log).

Виды лог-файлов

Все программы и сервисы Linux ведут log-файлы.

Самые важные - это логи:

веб-сервера;
почтового сервера (maillog);
FTP-сервера;
сервера базы данных;
подсистемы авторизации (auth.log)
логи самой системы (messages, syslog).

Log-файлы на сервере хранятся в специальном каталоге /var/log, внутри которого создаются отдельные файлы и папки для того или иного сервиса.

Различие в хранении log-файлов по версиям Linux

Дистрибутивы Linux имеют разный набор программного обеспечения и различные правила хранении log-файлов. В настоящее время наибольшее распространение получили два семейства дистрибутивов Linux:

системы, основанные на Debian (например, Ubuntu);
основанные на RedHat (Centos, Fedora).

Конкретная версия операционной системы для VPS/VDS выбирается у провайдера в личном кабинете пользователя перед заказом виртуального сервера.

Общие принципы для всех систем Linux одинаковы: log-файлы хранятся в папке /var/log. Разница проявляется лишь в наименовании отдельных файлов и каталогов для определенных подсистем, что зависит не только от версии Linux, но и от используемой панели управления хостингом.

Системные log-файлы

Опишем наиболее важные системные лог-файлы, хранящиеся в каталоге /var/log.

1. Общий системный журнал, в зависимости от версии Linux, записывается в файлы /var/log/syslog (Debian) или /var/log/messages (Redhat). В него пишется информация, начиная от старта системы:

2. Логи авторизации: /var/log/auth.log (Debian) или /var/log/secure (Redhat). Сюда записывается информация об авторизации пользователей, включая неудачные попытки входа в систему.

4. /var/log/boot.log - log загрузки операционной системы Linux.

5. /var/log/cron - отчет службы запуска по расписанию CRON.

Почти все log-файлы Linux представляют собой текстовые файлы, в которых каждая строчка содержит метку времени и описывает определенное событие. Исключение - это бинарный файл “wtmp”, в котором содержится информация о последних заходах пользователей на сервер.

Пример: содержимое каталога /var/log на Linux-системе. Видны текстовые .log-файлы системы, а также двоичный файл wtmp.

Логи web-сервера

Как правило, сайты на сервере работают под управлением web-сервера Apache или Nginx. Также их можно применять на сервере вместе, что позволит использовать сильные стороны каждой программы.

И Apache, и Nginx создают по два файла: один - для записи посещений, второй - для хранения информации об ошибках.

Также к логам веб-сервера относятся лог-файлы интерпретатора PHP (php-fpm) и файлы ошибок PHP.

Логи web-сервера Apache

Web-сервер Apache создает два лог-файла:

Для удобства эти файлы могут создаваться по отдельности для каждого сайта, размещенного на сервере. Тогда они имеют названия “domain.name_access.log” и “domain.name_error.log”.

Пример лог-файла посещений Apache. Список файлов в каталоге показывается командой linux “ls -l”

Для чтения информации из log-файла можно использовать команду “cat имя-лог-файла” или “tail имя-log-файла”.

В зависимости от конкретной панели управления файлами, внутри этого каталога могут находиться папки domains или domlogs, в которых будут записываться лог-файлы отдельно для каждого сайта.

Логи web-сервера Nginx

Nginx также создает два лог-файла для посещений и ошибок. Они располагаются в каталоге /var/log/nginx . В случае совместной работы с Apache лог-файлы Nginx иногда объединяются в один файл с логами Apache, но это несколько неудобно, с точки зрения обнаружения ошибок.

Если Nginx настроен для обслуживания нескольких сайтов, то его лог-файлы записываются отдельно для каждого сайта.

В случае использования Nginx совместно с панелью управления Vesta, log-файлы для отдельных сайтов хранятся в папке /var/log/nginx/domains , а в папке конкретного пользователя в каталоге logs создаются псевдонимы для этих файлов.

Пример: вывод командой “ls *.log” списка log-файлов web-сервера nginx в папке /var/log/nginx/domains (на снимке экрана видно, что там хранятся файлы сразу нескольких сайтов)

Логи интерпретатора PHP

В PHP есть возможность записи ошибок для определенной страницы сайта в отдельный лог-файл (это делается через файл .htaccess). В таком случае файлы ошибок PHP располагаются в одном каталоге с конкретной страницей сайта и имеют вид “php_error.log” или просто “error.log”.

Ротация log-файлов

Для посещаемого сайта размеры лог-файлов могут достигать сотен мегабайт. Рано или поздно они начинают занимать много дискового пространства, поэтому на серверах Linux используется механизм ротации log-файлов.

Как это работает?
1. Данные о посетителях (или ошибках) сайта записываются в файл с обычным названием, например, access.log.
2. Раз в сутки (обычно в ночное время) этот файл автоматически переименовывается в “access.log.1” и сжимается архиватором Gzip.
3. Имя файла становится вида “access.log1.gz”.
4. Вместо этого файла web-сервер начинает записывать информацию в новый файл access.log.
5. Еще через сутки архивный файл “access.log.1.gz” переименовывается в “access.log.2.gz”, и вместо него создается новый архив “access.log.1.gz” из текущего log-файла web-сервера и так далее.

Всего на сервере хранятся сжатые log-файлы за последний месяц.

Пример: на снимке экрана виден список log-файлов web-сервера. Среди них присутствуют как текущие файлы access.log и error.log за сегодняшний день, так и файлы за предыдущие дни access.log.1, error.log.1 и так далее.

То же происходит и с log-файлами других сервисов: почта, FTP, системные логи - все они проходят через ротацию.

Таким образом, ротация файлов помогает сохранять место на диске. Зная общий принцип, по которому именуются сжатые лог-файлы, системный администратор может найти нужную информацию за конкретный период времени.

Log-файлы почтовой системы

На сервере Linux могут быть установлены разнообразные программы для работы почтовой подсистемы. В последнее время большинство панелей управления хостингом (VestaCP, cPanel, ISPmanager) используют связку из почтовой программы Exim для отправки и приема писем (протокол SMTP) и другой почтовой программы Dovecot - для доступа пользователей к почтовым ящикам (протоколы IMAP/POP3).

Пример: log-файлы сервера Exim в папке /var/log/exim. На снимке экрана - вывод списка файлов командой ls -l

Log-файлы FTP-сервера

Вариантов программного обеспечения для FTP Linux много, но принцип хранения log-файлов примерно одинаковый. В папке /var/log создаются log-файлы FTP-сервера, например, vsftpd.log или proftpd.log. Также практически всеми FTP-серверами создается файл xferlog, в котором записывается информация о файлах, скачанных с сервера или закачанных на сервер по протоколу FTP.

Пример: log-файлы FTP-сервера vsftpd. На снимке экрана - вывод команды списка файлов, созданных FTP-сервером (vsftpd.log и xferlog)

Log-файлы сервера базы данных

Популярный сервер базы данных MySQL также ведет log-файл “mysqld.log”. Он располагается в папке /var/log/mysql или /var/log/mariadb, в зависимости от используемой версии MySQL.

Также сервер MySQL может создавать в этой папке файл отладки медленных запросов к базе данных. Обычно он называется “mysql_slow.log”.

Пример: содержимое файла медленных запросов MySQL. Вывод содержимого log-файла командой “tail mysql_slow.log”

Использование log-файлов для отладки работы web-сайтов

Если, например, конкретный web-сайт показывает в браузере ошибку 500, то можно зайти в этот файл и посмотреть, что именно происходит на сервере.

Пример: просмотр лог-файла ошибок web-сервера из панели провайдера Beget через файл-менеджер

При работе с лог-файлами web-сервера на виртуальном сервере необходимо знать, в каком каталоге находятся log-файлы для того или иного сайта. Это зависит от установленного на сервере программного обеспечения, в частности, - от конкретной панели управления.

Пример: содержимое рабочего каталога панели VestaCP. Виден каталог logs, в котором хранятся log-файлы

проблему с файлом .htaccess;
ошибку подключения к серверу базы данных;
ошибку языка PHP.

Использование log-файлов для аналитики

Любому владельцу сайта нужно знать аудиторию своих посетителей. Эта информация содержится в лог-файлах посещений web-сервера (access.log). Для удобной обработки информации провайдеры хостинга, а также панели управления предлагают такие системы: Webalizer и AWStats.

Пример: аналитика посещений web-сайта с использованием системы AWStats

Также на основе лог-файлов можно получить представление о распределении нагрузки на сайт по времени суток, следить за ошибками ненайденных страниц, вести мониторинг безопасности.

Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.

Что такое логи

Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:

Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.

Классификация логов

Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:

Записи в системные журналы выполняет установленный софт.

Зачем нужны логи

Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:

поиск ошибок и сбоев в работе системы;
выявление вредоносной активности;
сбор статистики посещения веб-ресурса.

После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.

Логи Apache в Windows

В Windows имеются особенности настройки имени файла журнала — точнее говоря, пути до файла журнала. Если имена файлов указываются с начальной буквы диска, например "C:/", то сервер будет использовать явно указанный путь. Если имена файлов НЕ начинаются с буквы диска, то к указанному значению добавляется значение ServerRoot — то есть «logs/access.log» с ServerRoot установленной на "c:/Server/bin/Apache24", будет интерпретироваться как "c:/Server/bin/Apache24/logs/access.log", в то время как "c:/logs/access.log" будет интерпретироваться как "c:/logs/access.log".

Apache error: ошибки сервера и сайтов

Путь до файла журнала с ошибками указывается с помощью ErrorLog, например, для сохранения ошибок в папке "logs/error.log" относительно корневой папки веб-сервера:

Журнал ошибок обычно записывается в файл (обычно это error_log в системах Unix и error.log в Windows и OS/2). В системах Unix также возможно, чтобы сервер отправлял ошибки в системный журнал или передавал их программе.

Если поместить токен %L в журнал ошибок и журнал доступа, будет создан идентификатор записи журнала, с которым вы можете сопоставить запись в журнале ошибок с записью в журнале доступа. Если загружен mod_unique_id, его уникальный идентификатор запроса также будет использоваться в качестве идентификатора записи журнала.

Во время тестирования часто бывает полезно постоянно отслеживать журнал ошибок на наличие проблем. В системах Unix вы можете сделать это, используя:

Apache access: логи доступа к серверу

Журнал доступа к серверу записывает все запросы, обработанные сервером. Расположение и содержимое журнала доступа контролируются директивой CustomLog. Директива LogFormat может быть использована для упрощения выбора содержимого журналов. В этом разделе описывается, как настроить сервер для записи информации в журнал доступа.

Общий формат журнала (Common Log)

Типичная конфигурация для журнала доступа может выглядеть следующим образом.

В первой строке задано имя (псевдоним) common, которому присвоено в качестве значения строка "%h %l %u %t \"%r\" %>s %b".

Строка формата состоит из директив, начинающихся с символа процента, каждая из которых указывает серверу регистрировать определённый фрагмент информации. Литеральные (буквальные) символы также могут быть помещены в строку формата и будут скопированы непосредственно в вывод журнала. Символ кавычки (") должен быть экранирован путём размещения обратной косой черты перед ним, чтобы он не интерпретировался как конец строки формата. Строка формата также может содержать специальные управляющие символы "\n"для новой строки и "\t" для обозначения таба (табуляции).

В данной строке значение директив следующее:

Директива CustomLog устанавливает новый файл журнала, используя определённый псевдоним. Имя файла для журнала доступа относительно ServerRoot, если оно не начинается с косой черты (буквы диска).

Приведённая выше конфигурация будет сохранять записи журнала в формате, известном как Common Log Format (CLF). Этот стандартный формат может создаваться многими различными веб-серверами и считываться многими программами анализа журналов. Записи файла журнала, созданные в CLF, будут выглядеть примерно так:

Каждая часть этой записи журнала описана ниже.

127.0.0.1 (%h)

Это IP-адрес клиента (удалённого хоста), который сделал запрос к серверу. Если для HostnameLookups установлено значение On, сервер попытается определить имя хоста и зарегистрировать его вместо IP-адреса. Однако такая конфигурация не рекомендуется, поскольку она может значительно замедлить работу сервера. Вместо этого лучше всего использовать постпроцессор журнала, такой как logresolve, для определения имён хостов. Указанный здесь IP-адрес не обязательно является адресом машины, на которой сидит пользователь. Если между пользователем и сервером существует прокси-сервер, этот адрес будет адресом прокси, а не исходной машины.

- (%l)

frank (%u)

[10/Oct/2000:13:55:36 -0700] (%t)

Время получения запроса. Формат такой:

Можно отобразить время в другом формате, указав %t в строке формата журнала, где формат такой же, как в strftime(3) из стандартной библиотеки C, или один из поддерживаемых специальных токенов. Подробности смотрите в строках формате строки mod_log_config.

200 (%>s)

2326 (%b)

Последняя часть указывает размер объекта, возвращаемого клиенту, не включая заголовки ответа. Если контент не был возвращён клиенту, это значение будет "-". Чтобы записать «0» без содержимого, вместо %b используйте %B.

Логи комбинированного формата (Combined Log)

Другая часто используемая строка формата называется Combined Log Format. Может использоваться следующим образом.

Дополнительными полями являются:

Настройки логов в Apache по умолчанию

По умолчанию в главном конфигурационном файле Apache прописаны следующие настройки логов:

Как можно увидеть, установлены три псевдонима: combined, common и combinedio. При этом по умолчанию используется common. При желании вы без труда сможете переключиться на combined или настроить формат строки лога под свой вкус.

Например, если вы предпочитаете, чтобы в файле лога доступа также присутствовала информация о пользовательском агенте и реферере, то есть Combined Logfile Format, то вы можете использовать следующую директиву:

Давайте поговорим о безопасности при обработке данных, связанной с выводом отладочной информации в браузер посетителя. Очень часто, при обработке клиентских данных весь вывод отладочной информации, как и ошибок, программисты отправляют в браузер посетителя, совершенно не задумываясь при этом о дальнейшем профилировании проекта и его усовершенствовании, а также о том, что своими же руками они предоставляют конфиденциальные технические данные работы проекта любому желающему, да и попросту раздражают этим рядового пользователя.

Это при том, что PHP уже давно обладает богатым набором функций и средств для логирования, журналирования и сбора ошибок и непредвиденных ситуаций. Кроме этого часть ошибок так и остается «за кадром», которые можно выявить и устранить уже в процессе работы, тем самым повышая стабильность сайта и избегая потери новых посетителей, которые, столкнувшись с определенными трудностями и ошибками, попросту уйдут на другой ресурс.

Обычно (утрировано и упращенно) это выглядит, например, так:

Пример «взят» не из воздуха, вот так, приблизительно, но в более сложной форме выглядит разбитие на постраничную навигацию в разделах известного новостного движка DLE. А также вот так (echo mysql_error(); die()) выводится, зачастую, в браузер посетителя возникновение mysql ошибки в Joomla 1.5 и более новых версий (чуть сложнее, но смысл остается тот же).

Здесь была осознанно допущена одна оплошность. Дело в том, что данный вариант будет работать отлично! И в повседневной работе программист не увидит выполнение echo mysql_error().

Но почему не следует выводить в браузер отладочную информацию и ошибки исполнения PHP?

Итак, первое, из за того, что мы обходимся без проверки, что же приходит со стороны клиента, например, отрицательные значения $id и $limit, которые допускаются для типа данных integer, или несуществующие значения приведут к выводу отладочной информации mysql_error(). Итак, ясным по белому, мы дадим информацию злоумышленнику о существующих таблицах и пищу для размышления, как же проще осуществить mysql injection в другом месте, где используются эти же таблицы при составлении запросов. Или же в некоторых случаях покажем посетителям техническую информацию, которую видеть они не должны. С одной стороны здесь нам помогут более строгие проверки входных данных. Перепишем этот пример с использованием выше сказанного:

Мы предотвратили, как минимум, возникновение нескольких исключительных ситуаций. Мы знаем, что нам нужны только лишь целые положительные значения $id,$limit – поэтому используем явное приведени типов для этих переменных, оператор приведения к целому (int) и функцию получения целого числа abs(). Также мы знаем, что количество выбранных новостей не должно быть равно нулю, поэтому определяем минимальный «порог» в 10 новостей $limit = $limit ? $limit : 10;, формируя запрос, мы проверяем данные, и если они есть и отличны от 0, то добавляем их в mysql запрос по частям.

Все бы хорошо, но и здесь могут быть подводные камни. И все равно существует некоторая вероятность того, что при манипуляции с входными данными злоумышленник увидит вывод той самой информации echo mysql_error();. Зачастую это может получиться даже чисто случайно.

Другой распространенный пример. Многие программисты добавляют вывод технической информации еще на этапе подключения к базе данных. Что, в случае отсутствия соединения с базой данных (сверх нагрузки/временной недоступности сервера баз данных) также выводит отладочную информацию посетителям. При этом там, зачастую, могут в простом тексте встречаться даже логин/название базы/хост подключения к базе данных. А сам программист может никогда и не увидеть подобной информации, и даже не узнать о временном полягании проекта (например из за превышения числа подсоединений к базе данных в случае с увеличением аудитории, как итог: при частом повторении проблемы потеря новых посетителей, раскрытие важных технических данных).

А ведь сбор такой информации бывает полезным для профилирования приложения и дальнейшего его усовершенствования (обеспечения стабильности работы). Для выявления «подводных» камней в стабильной работе сайта.

Итак, давайте обратимся к документации по php. К разделу о создании собственных исключений и перенаправлении отладочной информации и ошибок, логировании и журналировании.

Какие функции и данные для логирования в PHP могут быть полезны?

– для генерации исключения. , error_reporting – для подавления вывода ошибок – для установки собственной функции «перехвата» ошибок – для отлова критических ошибок (которая работает, как нужно, начиная с php 5.2) – функция получения последней ошибки, произошедшей в скрипте, очень полезна в случае прерывания скрипта из за возникновения критической ошибки – суперглобальный массив – источник информации – где и когда и какая ошибка произошла – функция для получения значения переменных среды окружения сервера, в том случае, если какие-то данные в суперглобальном массиве $_SERVER отсутствуют

Примечание автора: желательно подключить подобный код как можно раньше, еще на этапе инициализации созданного php приложения:

Зачастую, подобной информации хватит с головой и для логирования и исправления ошибок, которые были не замечены на этапе разработки, так и для отлова злоумышленников. Но есть один тип ошибок, который не будет перехвачен. Это критические ошибки PHP E_ERROR, которые приводят к прерыванию php скрипта . Начиная с версии PHP 5.2 для перехвата критических ошибок можно определить собственную функцию при мопощи register_shutdown_function. Мы создаем собственную функцию для этих целей critical_error, в которой при помощи функции error_get_last получаем информацию о текущей ошибке. Так как данная функция будет всегда выполняться после завершения php скрипта, мы логируем информацию только об ошибках с типом E_ERROR.

Можно было бы использовать функцию error_log с указанием пути к источнику логирования, но было отдано предпочтение простым файловым функциям, при помощи которых можно установить функцией flockприоритетное эксклюзивное запирание во избежание попыток одновременной записи в логфайл несколькими скриптами (и возникновения «битых» файлов).

Давайте на примере все того же скрипта с mysql рассмотрим принцип логирования mysql ошибок (впрочем, по такому же принципу можно построить логирование любых внештатных ситуаций):

Вот и все, в файле ошибок при возникновении ошибки mysql будет добавлена новая строка с подробной информацией. Таким способом вы сможете логировать практически любую полезную для вас информацию, скрыв ее от Ваших посетителей. А сбор и анализ подобной информации поможет в дальнейшем в повышении стабильности и совершенствовании Вашего проекта.

Примечание автора: также для генерации и перехвата ошибок Вы можете использовать конструкции try<>catch(Exeption $e)

Примечание автора: правилом хорошего тона при перехвате и обработке ошибок (особенно критических, которые ведут к невозможности предоставить посетителю необходимую информацию, за которой он, собственно, и пришел к Вам на сайт) является создание для каждого вида подобных ошибок статической страницы с объяснением на человекопонятном языке без технических данных сути проблемы (также на такой странице можно оставить контакты админитрации) и перенаправление посетителя на нужную страницу в ходе возникновения ошибки.

Например, в приведенном примере с категориями можно создать страницу с подобным текстом:

Уважаемый посетитель!

Просим Вас уведомить нас о сложившийся ситуации любым удобным для Вас способом

(контактные данные)

Во первых: ваши же посетители будут четко, понятно и информативно ставить Вас в известность о произошедшей ситуации, во вторых: тем самым Вы сбережете их нервы, и даже в случае возникновения непредвиденной ситуации посетители могут продолжить изучать Ваш ресурс.

Информация к размышлению, что можно сделать лучше в этом скрипте?

Читайте также: