Apache: Файлы журналов

RU EN

Пункт 13. Файлы журналов

Чтобы эффективно управлять веб-сервером, необходимо получать отзывы об активности и производительности сервера, а также о любых проблемах, которые могут возникнуть. HTTP-сервер Apache предоставляет очень широкие и гибкие возможности ведения журналов. В этом документе описывается, как настроить возможности ведения журнала и как понять, что содержится в журналах.

Обзор

HTTP-сервер Apache предоставляет множество различных механизмов для регистрации всего, что происходит на вашем сервере, от первоначального запроса через процесс сопоставления URL-адресов до окончательного разрешения соединения, включая любые ошибки, которые могли возникнуть в процессе. В дополнение к этому сторонние модули могут предоставлять возможности ведения журнала или вводить записи в существующие файлы журнала, а такие приложения, как программы CGI, сценарии PHP или другие обработчики, могут отправлять сообщения в журнал ошибок сервера.

В этом документе мы обсуждаем модули ведения журнала, которые являются стандартной частью http-сервера.

Предупреждение безопасности

Любой, кто может писать в каталог, где Apache httpd записывает файл журнала, почти наверняка может получить доступ к uid, под которым запускается сервер, который обычно является root. НЕ давайте людям доступ на запись к каталогу, в котором хранятся журналы, не зная о последствиях ; подробности см. в документе с советами по безопасности.

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

Журнал ошибок

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

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

Формат журнала ошибок определяется директивой ErrorLogFormat , с помощью которой вы можете указать, какие значения регистрируются. Формат по умолчанию определен, если вы его не укажете. Типичное сообщение журнала выглядит следующим образом:

[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico

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

В журнале ошибок может появиться очень большое количество различных сообщений. Большинство из них похоже на пример выше. Журнал ошибок также будет содержать результаты отладки сценариев CGI. Любая информация, записанная stderr сценарием CGI, будет скопирована непосредственно в журнал ошибок.

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

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

tail -f error_log

Ведение журнала по модулям

Директива LogLevel позволяет указать уровень серьезности журнала для каждого модуля. Таким образом, если вы устраняете проблему только с одним конкретным модулем, вы можете увеличить объем его журнала, не получая также сведений о других модулях, которые вас не интересуют. Это особенно полезно для таких модулей, как или mod_proxy где mod_rewrite вы хотите узнать подробности о том, что он пытается сделать.

Сделайте это, указав имя модуля в своей LogLevel директиве:

 Перезапись информации LogLevel: trace5

Это устанавливает для main LogLevel значение info, но превращает его в trace5 for mod_rewrite .

Это заменяет директивы ведения журнала для каждого модуля, такие как RewriteLog , которые присутствовали в более ранних версиях сервера.

Журнал доступа

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

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

Различные версии Apache httpd использовали другие модули и директивы для управления ведением журнала доступа, включая mod_log_referer, mod_log_agent и директиву TransferLog . Директива CustomLog теперь включает в себя функциональность всех старых директив.

Формат журнала доступа легко настраивается. Формат задается с помощью строки формата, которая очень похожа на строку формата printf(1) в стиле C. Некоторые примеры представлены в следующих разделах. Полный список возможного содержимого строки формата см. в разделе mod_log_config Строки формата.

Общий формат журнала

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

 LogFormat "%h %l %u %t \"%r\" %>s %b" общий
Журналы CustomLog/access_log общие

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

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

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

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

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

127.0.0.1 ( %h )

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

- ( %l )

«Дефис» в выводе указывает на то, что запрошенная часть информации недоступна. В этом случае недоступной информацией является идентификатор RFC 1413 клиента, определенный на identd клиентском компьютере. Эта информация крайне ненадежна и почти никогда не должна использоваться, кроме как в жестко контролируемых внутренних сетях. Apache httpd даже не будет пытаться определить эту информацию, если не IdentityCheck установлено значение On .

frank ( %u )

Это идентификатор пользователя лица, запрашивающего документ, как определено HTTP-аутентификацией. Такое же значение обычно предоставляется сценариям CGI в REMOTE_USER переменной среды. Если код состояния для запроса (см. ниже) равен 401, то этому значению нельзя доверять, поскольку пользователь еще не аутентифицирован. Если документ не защищен паролем, эта часть будет " - ", как и предыдущая.

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

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

[day/month/year:hour:minute:second zone] day = 2*digit month = 3*letter year = 4*digit hour = 2*digit minute = 2*digit second = 2*digit zone = (`+' | `-') 4*digit

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

"GET /apache_pb.gif HTTP/1.0" ( \"%r\" )

Строка запроса от клиента заключена в двойные кавычки. Строка запроса содержит много полезной информации. Во-первых, метод, используемый клиентом GET . Во-вторых, клиент запросил ресурс /apache_pb.gif , и в-третьих, клиент использовал протокол HTTP/1.0 . Также возможно независимо регистрировать одну или несколько частей строки запроса. Например, строка формата " %m %U%q %H " будет регистрировать метод, путь, строку запроса и протокол, что приведет к точно такому же выводу, что и " %r ".

200 ( %>s )

Это код состояния, который сервер отправляет обратно клиенту. Эта информация очень ценна, потому что она показывает, привел ли запрос к успешному ответу (коды, начинающиеся с 2), к перенаправлению (коды, начинающиеся с 3), к ошибке, вызванной клиентом (коды, начинающиеся с 4), или к ошибке в сервер (коды начинаются с 5). Полный список возможных кодов состояния можно найти в спецификации HTTP (RFC2616, раздел 10).

2326 ( %b )

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

Комбинированный формат журнала

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

 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" в сочетании
Комбинированный журнал CustomLog/access_log

Этот формат точно такой же, как и общий формат журнала, с добавлением еще двух полей. В каждом из дополнительных полей используется процентная директива , где заголовком может быть любой заголовок HTTP-запроса. Журнал доступа в этом формате будет выглядеть так: %{header}i

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

Дополнительные поля:

"http://www.example.com/start.html" ( \"%{Referer}i\" ): Заголовок HTTP-запроса Referer (так в оригинале). Это дает сайт, с которого клиент сообщает, что его перенаправили. (Это должна быть страница, которая ссылается на или включает /apache_pb.gif ).
"Mozilla/4.08 [en] (Win98; I ;Nav)" ( \"%{User-agent}i\" ): Заголовок HTTP-запроса User-Agent. Это идентифицирующая информация, которую браузер клиента сообщает о себе.

Журналы множественного доступа

Журналы множественного доступа можно создать, просто указав несколько CustomLog директив в файле конфигурации. Например, следующие директивы создадут три журнала доступа. Первый содержит основную информацию CLF, а второй и третий содержат информацию о реферере и браузере. Последние две CustomLog строки показывают, как имитировать эффекты директив ReferLog и AgentLog .

 LogFormat "%h %l %u %t \"%r\" %>s %b" общий
Журналы CustomLog/access_log общие
Журналы CustomLog/referer_log "%{Referer}i -> %U"
Журналы CustomLog/agent_log "%{User-agent}i"

Этот пример также показывает, что нет необходимости определять псевдоним с помощью директивы LogFormat . Вместо этого формат журнала можно указать прямо в директиве CustomLog .

Условные журналы

Бывают случаи, когда удобно исключить определенные записи из журналов доступа на основе характеристик клиентского запроса. Это легко сделать с помощью переменных окружения. Во-первых, необходимо установить переменную среды, чтобы указать, что запрос соответствует определенным условиям. Обычно это достигается с помощью SetEnvIf . Затем env= предложение директивы CustomLog используется для включения или исключения запросов, в которых установлена переменная среды. Некоторые примеры:

 # Пометить запросы от loop-back интерфейса
SetEnvIf Remote_Addr "127\.0\.0\.1" не регистрируйте
# Отметить запросы для файла robots.txt
SetEnvIf Request_URI "^/robots\.txt$" не регистрируйте
# Записываем, что осталось
Журналы CustomLog/access_log общий env=!dontlog

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

 SetEnvIf Accept-Language "en" английский
Журналы CustomLog/english_log общий env=english
Журналы CustomLog/non_english_log общий env=!english

В сценарии кэширования хотелось бы знать об эффективности кэша. Очень простой способ выяснить это:

 SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t "%r" %>s %b %{CACHE_MISS}e" общий кэш
Журналы CustomLog/access_log общий кэш

mod_cache будет запущен раньше mod_env и, в случае успеха, доставит контент без него. В этом случае попадание в кэш будет занесено в журнал - , а промах - в журнал 1 .

В дополнение к env= синтаксису LogFormat поддерживает значения регистрации в зависимости от кода ответа HTTP:

 LogFormat "%400,501{User-agent}i" журнал браузера
LogFormat "%!200,304,302{Referer}i" журнал перехода

В первом примере User-agent будет регистрироваться, если код состояния HTTP равен 400 или 501. В других случаях вместо этого будет регистрироваться буквенный «-». Аналогично, во втором примере Referer будет регистрироваться, если код состояния HTTP не равен 200, 204 или 302. (Обратите внимание на «!» перед кодами состояния.

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

Ротация журнала

Даже на умеренно загруженном сервере объем информации, хранящейся в файлах журналов, очень велик. Файл журнала доступа обычно увеличивается на 1 МБ или более на каждые 10 000 запросов. Следовательно, необходимо будет периодически менять файлы журналов, перемещая или удаляя существующие журналы. Это невозможно сделать во время работы сервера, потому что Apache httpd будет продолжать запись в старый файл журнала до тех пор, пока он будет держать этот файл открытым. Вместо этого сервер необходимо перезапустить после перемещения или удаления файлов журнала, чтобы он открыл новые файлы журнала.

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

mv access_log access_log.old mv error_log error_log.old apache2ctl graceful sleep 600 gzip access_log.old error_log.old

Еще один способ выполнить ротацию журналов — использовать конвейерные журналы, как описано в следующем разделе.

Перенаправленные журналы

Apache httpd может записывать файлы журналов ошибок и доступа через канал к другому процессу, а не напрямую к файлу. Эта возможность значительно повышает гибкость ведения журнала без добавления кода на главный сервер. Чтобы записывать журналы в канал, просто замените имя файла символом канала " | ", за которым следует имя исполняемого файла, который должен принимать записи журнала на свой стандартный ввод. Сервер запустит процесс piped-log при запуске сервера и перезапустит его, если произойдет сбой во время работы сервера. (Последняя особенность — то, почему мы можем называть эту технику «надежной конвейерной регистрацией».)

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

Одним из важных способов использования журналов, передаваемых по конвейеру, является возможность чередования журналов без перезапуска сервера. HTTP-сервер Apache включает в себя простую программу, вызываемую rotatelogs для этой цели. Например, чтобы чередовать журналы каждые 24 часа, вы можете использовать:

 CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" общий

Обратите внимание, что кавычки заключают в себя всю команду, которая будет вызываться для канала. Хотя эти примеры относятся к журналу доступа, тот же метод можно использовать и для журнала ошибок.

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

По умолчанию процесс передаваемого журнала запускается без вызова оболочки. Используйте " |$ " вместо " | " для создания с помощью оболочки (обычно с /bin/sh -c ):

 # Вызвать «rotatelogs» с помощью оболочки
CustomLog "| $/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" общий

Это было поведением по умолчанию для Apache 2.2. В зависимости от специфики оболочки это может привести к дополнительному процессу оболочки на время существования программы канала регистрации и проблемам с обработкой сигналов во время перезапуска. Из соображений совместимости с Apache 2.2 обозначение " || " также поддерживается и эквивалентно использованию " | ".

Примечание для Windows

Обратите внимание, что в Windows вы можете столкнуться с проблемами при запуске многих конвейерных процессов ведения журнала, особенно когда HTTPD работает как служба. Это вызвано нехваткой места в куче рабочего стола. Пространство кучи рабочего стола, предоставляемое каждой службе, указывается третьим аргументом параметра SharedSection в значении реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SubSystems\Windows. Изменяйте это значение с осторожностью ; применяются обычные предостережения для изменения реестра Windows, но вы также можете исчерпать пул кучи рабочего стола, если число настроено слишком высоко.

Виртуальные хосты

При запуске сервера со многими виртуальными хостами существует несколько вариантов работы с файлами журналов. Во-первых, можно использовать логи точно так же, как и на одноузловом сервере. Просто поместив директивы ведения журнала вне <VirtualHost> разделов в контексте основного сервера, можно регистрировать все запросы в одном и том же журнале доступа и журнале ошибок. Этот метод не позволяет легко собирать статистику по отдельным виртуальным хостам.

Если директивы CustomLog или ErrorLog размещены внутри <VirtualHost> раздела, все запросы или ошибки для этого виртуального хоста будут записываться только в указанный файл. Любой виртуальный хост, у которого нет директив ведения журнала, по-прежнему будет отправлять свои запросы в журналы основного сервера. Этот метод очень удобен для небольшого количества виртуальных хостов, но если количество хостов очень велико, им может быть сложно управлять. Кроме того, это часто может создавать проблемы из-за недостаточного количества файловых дескрипторов.

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

 LogFormat "%v %l %u %t \"%r\" %>s %b"
Журналы CustomLog/access_log

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

Другие файлы журналов

Связанные модули	Связанные директивы
`mod_logio` `mod_log_config` `mod_log_forensic` `mod_cgi`	`LogFormat` `BufferedLogs` `ForensicLog` `PidFile` `ScriptLog` `ScriptLogBuffer` `ScriptLogLength`

Регистрация фактических отправленных и полученных байтов

mod_logio добавляет два дополнительных LogFormat поля (%I и %O), которые регистрируют фактическое количество байтов, полученных и отправленных по сети.

Криминалистическая регистрация

mod_log_forensic обеспечивает криминалистическую регистрацию клиентских запросов. Ведение журнала выполняется до и после обработки запроса, поэтому журнал судебной экспертизы содержит две строки журнала для каждого запроса. Криминалистический регистратор очень строгий, без каких-либо настроек. Это может быть бесценным инструментом отладки и безопасности.

PID-файл

При запуске Apache httpd сохраняет идентификатор родительского процесса httpd в файле logs/httpd.pid . Это имя файла можно изменить с помощью PidFile директивы. Идентификатор процесса предназначен для использования администратором при перезапуске и остановке демона путем отправки сигналов родительскому процессу; в Windows вместо этого используйте параметр командной строки -k. Дополнительные сведения см. на странице Остановка и перезапуск.

Журнал сценариев

Чтобы помочь в отладке, ScriptLog директива позволяет записывать ввод и вывод из сценариев CGI. Это следует использовать только при тестировании, а не для живых серверов. Более подробная информация доступна в документации mod_cgi.