Apache отключить логи windows

Как в Apache под Windows настроить автоматическую ротацию и очистку логов

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

С помощью этого плагина мы сможем в Apache в 2.4 под Windows настроить автоматическую чистку логов со временем.

Файл данного плагина не входит в стандартный набор Apache, но команда apachelounge компилирует его для Windows. Перейдите на сайт https://www.apachelounge.com/download/, найдите и скачайте файл mod_log_rotate:

Распакуйте архив и поместите файл mod_log_rotate.so в папку modules, если вы устанавливали по этой инструкции, то это папка C:\Server\bin\Apache24\modules\.

Для включения этого модуля, добавьте в ваш конфигурационный файл httpd.conf (C:\Server\bin\Apache24\conf\httpd.conf) строки:

Чтобы изменения вступали в силу, не забывайте при каждом изменении конфигурационного файла httpd.conf перезапускать веб-сервер!

Интервал ротации логов по умолчанию установлен на 86400 секунд (это один день). С помощью директивы

можно установить другой интервал ротации в секундах. Самый короткий интервал, который может быть установлен, равен 60 секундам.

Обычно интервал ротации журнала основан на UTC. Например, интервал 86400 (один день) приведёт к ротации журналов в UTC 00:00.

С помощью следующей директивы вы можете сделать так, чтобы ротация журналов происходила по местному времени:

У директивы RotateInterval может быть альтернативная опция:

Она указывает смещение времени ротации журналов веб сервера. Например:

приведёт к тому, что логи будут ротироваться в 23:00 UTC.

Теперь в качестве имени для настраиваемого лога можно указать дату в формате strftime(). К примеру вы можете сделать что-то вроде такого:

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

Внимание

После включения mod_log_rotate, этот модуль отвечает за весь вывода журнала веб сервера, даже если впоследствии используется RotateLogs Off.

Это означает, что директива BufferedLogs, которая реализуется mod_log_config, будет игнорироваться.

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

Альтернатива для rotatelogs

Использование модуля mod_log_rotate является альтернативой для поставляемой с Apache программы rotatelogs. Если вы не хотите устанавливать дополнительный модуль, то используйте rotatelogs (документация). Если вам нужна инструкция по rotatelogs, то пишите в комментариях!

Связанные статьи:

Comments

Спасибо. mod_log_rotate затрагивает как и access.log так и error.log?

Тем не менее с использованием внешней программы можно управлять и журналом ошибок (если Apache вылетит, внешняя программа всё равно обработает полученную информацию). В частности это умеет упомянутая в инструкции программа rotatelogs (в Windows это rotatelogs.exe).

Я подготовлю инструкцию по rotatelogs и покажу как можно ротировать логи ошибок.

Спасибо буду крайне признателен за Вашу инструкцию по rotatelogs

Источник

Apache log (логи): как настроить и анализировать журналы веб-сервера

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

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

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

Логи 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«.

Также особенностью указания пути до логов в Windows является то, что нужно использовать слэши, а не обратные слэши, то есть «c:/apache» вместо «c:\apache«. Если пропущена буква диска, то по умолчанию будет использоваться диск, на котором размещён httpd.exe. Рекомендуется явно указывать букву диска при абсолютных путях, чтобы избежать недоразумений.

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

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

С помощью директивы LogLevel можно установить уровень важности сообщений, которые должны попадать в журнал ошибок. Доступные варианты:

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

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

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

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

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

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

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

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

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

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

Формат журнала доступа легко настраивается. Формат указывается с использованием строки формата, которая очень похожа на строку формата printf в стиле C. Некоторые примеры представлены в следующих разделах. Полный список возможного содержимого строки формата смотрите здесь: https://httpd.apache.org/docs/current/mod/mod_log_config.html

Общий формат журнала (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-адрес не обязательно является адресом машины, на которой сидит пользователь. Если между пользователем и сервером существует прокси-сервер, этот адрес будет адресом прокси, а не исходной машины.

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

frank (%u)

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

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

Можно отобразить время в другом формате, указав %t в строке формата журнала, где формат такой же, как в 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)

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

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

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

Этот формат точно такой же, как Common Log Format, с добавлением ещё двух полей. Каждое из дополнительных полей использует директиву начинающуюся с символа процента %<заголовок>i, где заголовок может быть любым заголовком HTTP-запроса. Журнал доступа в этом формате будет выглядеть так:

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

«http://www.example.com/start.html» (\»%i\»)

Referer — это часть заголовок HTTP-запроса, которая называется также Referer. В этой строке содержится информация о странице, с которой клиент был прислан на данный сайт. (Это должна быть страница, которая ссылается или включает /apache_pb.gif).

«Mozilla/4.08 [en] (Win98; I ;Nav)» (\»%i\»)

Заголовок HTTP-запроса User-Agent. Это идентифицирующая информация, которую клиентский браузер сообщает о себе.

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

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

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

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

Источник

Логи в Apache

Каждому из нас хочется побыть «большим братом» и последить за своими посетителями. Это можно делать по-разному: поставить счетчик, например, HotLog, поставить особый скрипт, ну а некоторые делают это с помощью логов Apache. Да-да, вы не ослышались, Apache тоже ведет логи.

На практике необходимо понять значение всего двух директив: LogFormat и CustomLog. Есть еще директива ErrorLog, но лично я использую лог ошибок только для просмотра последних строчек, когда Apache не пускается. Все-таки скажу несколько слов о ErrorLog.

Сами разработчики считают лог ошибок сервера, создающийся директивой ErrorLog, и хранящий все сообщения об ошибках и всю диагностику, наиболее важным логом. Не верьте им. Еррор-лог создается так:

Практически никак не настраивается, однако есть важная директива LogLevel. Она дает указания серверу писать или не писать в лог ошибки различной степени тяжести. Например, директива

Заставит сервер жаловаться только на самые критические проблемы, когда сервер не запускается. Далее параметры по убывающей: alert, crit, error, warn, notice, info и, конечно же, мой любимый

При котором вам будет рассказано даже о том, что сервер все-таки открывает в данный момент файл конфигурации 🙂

Таким образом, если вам нужны логи ошибок, то в httpd.conf следует указать директиву ErrorLog с параметром «имя лога» (путь считается относительно ServerRoot) и LogLevel с параметром «степень точности». Далее все на вашей совести 🙂

Теперь о том, что считаю важным я: Combined Logs. Эти логи повествуют о том, кто, когда и зачем отправлял запросы к серверу. Правда, интересно? Здесь еще две директивы: LogFormat и CustomLog. Покопайтесь в каком-нибудь httpd.conf и вы обязательно увидите там что-нибудь типа

Эти параметры можно комбинировать в любом порядке и в любом количестве. Захотите определять только IP посетителей — пишете так:

Вот и определен новый формат лога. В общем, комбинируйте как хотите. Но логи эта директива не создает. Чтобы сервер начал писать лог, надо потребовать этого директивой CustomLog, которая принимает два параметра: имя файла лога и его тип. Таким образом, чтобы записывать IP клиентов, надо добавить еще и такую строчку:

И только после этого лог начнет нормально вестись. Кстати, популярным считается стандарт «combined log», описывающийся так:

Как видите, довольно информативно. А теперь на минуту представьте себе, что ваш сервер обрабатывает около миллиона запросов в день. И вам охота вести несколько логов. Ну это обычное явление: сколько скажете раз CustomLog, столько логов и создастся, а ну как вам захочется всех поисковиков, ищущих robots.txt писать в отдельный лог? Ладно. Рассказываю.

Есть еще такая полезная директива SetEnvIf (или SetEnvIfNoCase — то же самое, но без учета больших/маленьких букв), она позволяет в зависимости от условия определять переменные среды. Например:

После этого переменная env будет равняться «crawler». Но это еще не все! В зависимости от значения этой переменной вы можете делать запись в разные логи! Вот так:

Вот так, нашему апачу палец в рот не клади 🙂 Не буду рассказывать почему robots.txt так странно написано, называется это регулярные выражения, а почитать про них можно либо в учебнике, либо в странице мануала перла по имени perlre. Вот так: man perlre. Под юниксом, конечно 🙂

Уфф… Все, вроде? Нет, есть еще пипы. Пипы (pipes) позволяют предварительно (прежде чем чего-то в логи записать), что-нибудь эдакое с ними сотворить, например сжать. Стандартный значок пипы в юниксе — вертикальная палка, так что если вам приспичит логи сразу сжимать, делайте так:

Все под юниксом 🙂 Просто потому, что если у вас апач на винде, то логи вести незачем — врядли она у вас сервером работает %)

Источник

Управление логами Apache

TransferLog /data/apache/logs/gen_msg
ErrorLog /data/apache/logs/error_msg

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

ServerName www.company_a.com
DocumentRoot /data/apache/co_a/html
TransferLog /data/apache/co_a/logs/gen_msg
ErrorLog /data/apache/co_a/logs/error_msg

ServerName www.company_b.com
DocumentRoot /data/apache/co_b/html
TransferLog /data/apache/co_b/logs/gen_msg
ErrorLog /data/apache/co_b/logs/error_msg

Ясно, что в таком конфиге не только
документы будут разделяться по разным
каталогам, но и логи. Отметьте, что записи лежат вне DocumentRoot,
что довольно неплохо для обеспечения
безопасности.

Существует несколько уровней при помощи
которых можно настроить глубину записи
активности Web-сервера. Уровни логов такие: emerg,
alert, crit, error, warn, notice, info
и debug. Дописывая определение уровня в
конец директивы, управляющей логгированием,
мы можем определить, что именно писать.
Например, я хочу заставить Apache записывать
неотложные записи и предупреждения только
для одного из доменов. В контейнере нужного
домена делаем так:

Формат, в котором сервер делает записи,
так же можно произвольно менять. Делается
это директивой LogFormat все в том же htttpd.conf.
По дефолту выглядит запись примерно так:

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

LogFormat «Date: %t, Host: %h, User: %u, File Requested: %r» simple
.

.
CustomLog /data/apache/co_a/logs/gen_msg simple
.

Помимо приведенных в примере кодов можно
использовать %a для IP адреса, %b для
количества байт, %f для имени файла, %i для
заголовка запроса, %s для статуса. Полностью
список кодов можно найти
на сайте Apache. Пример работы приведенного
выше лога:

CustomLog search_eng_log «%i»

Включение и исключение

На своем сайте я предпочитаю запросы с
собственной рабочей станции записывать в
отдельный лог, это упрощает отладку
скриптов и самого сервера. Вводим
переменную и по ней определяем куда и что
класть:

SetEnvIf Remote_Addr «12.127.17.72» my_stuff
CustomLog logs/my_access complex env=my_stuff
CustomLog logs/gen_msg simple env=!my_stuff

Всем понятно, что логи приличного сервера
разрастаются довольно быстро. По умолчанию
они очищаются каждую неделю: access_log
копируется в access_log.1, access_log.1 в access_log.2 и так
далее (в обратном порядке разумеется).
Однако если вы устанавливаете собственные
логи, то нужно задать и их ротацию. Сделать
это можно несколькими путями. ИМХО лучше
всего написать простой скрипт для cron, который
затем регулярно выполнять:

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Логи Apache (ч. 2): Формат логов ошибок. Журнал событий модулей

Оглавление: Всё о логах Apache — от настройки до анализа

4. Криминалистические логи

5. Дополнительные настраиваемые журналы отладки. Журналы выполнения CGI скриптов

Логи ошибок Apache

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

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

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

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

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

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

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

Директива ErrorLog

Описание: устанавливает место, куда сервер будет записывать ошибки.

Значение по умолчанию:

Контекст: server config, виртуальные хосты.

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

Если путь-до-файла начинается с символа труба «|» тогда предполагается, что это команда для вызова журнала ошибок.

Смотрите подробности в разделе «Конвейерная обработка».

Использование syslog вместо имени файла позволяет регистрироваться через syslogd(8), если система поддерживает его и если загружен mod_syslog. По умолчанию используется средство syslog local7, но вы можете переопределить это, используя синтаксис syslog:средство, где средство может быть одним из имён, обычно задокументированных в syslog(1). Средство фактически является глобальным, и если оно изменяется на отдельных виртуальных хостах, указанное последнее средство влияет на весь сервер. Те же правила применяются к тегу syslog, который по умолчанию использует двоичное имя Apache, в большинстве случаев httpd. Вы также можете переопределить это, используя синтаксис syslog::tag.

Дополнительные модули могут предоставлять свои собственные поставщики ErrorLog. Синтаксис похож на пример системного журнала выше.

БЕЗОПАСНОСТЬ: см. раздел «Вопросы безопасности», чтобы узнать, почему ваша безопасность может быть скомпрометирована, если каталог, в котором хранятся файлы журналов, доступен для записи кому-либо, кроме пользователя, запускающего сервер.

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

Директива ErrorLogFormat

Описание: Определение формата для записей журнала ошибок.

Контекст: server config, виртуальные хосты.

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

Указание соединения или запроса в качестве первого параметра позволяет указать дополнительные форматы, в результате чего регистрируется дополнительная информация, когда первое сообщение регистрируется для определённого соединения или запроса, соответственно. Эта дополнительная информация регистрируется только один раз за соединение/запрос. Если соединение или запрос обрабатываются без какого-либо сообщения журнала, дополнительная информация также не регистрируется.

Может случиться, что некоторые элементы строки формата не производят вывод. Например, заголовок Referer присутствует только в том случае, если сообщение журнала связано с запросом, а сообщение журнала появляется в тот момент, когда заголовок Referer уже был считан с клиента. Если выходные данные не создаются, поведение по умолчанию заключается в удалении всего, начиная с предыдущего пробела до следующего пробела. Это означает, что строка журнала неявно разделена на поля в переходах между не белыми пробелами и белыми пробелами. Если элемент строки формата не производит вывод, все поле опускается. Например, если удалённый адрес %a в формате журнала [%t] [%l] [%a] %M недоступен, окружающие скобки также не регистрируются. Символы пробела можно экранировать с помощью обратной косой черты, чтобы они не могли ограничить поле. Комбинация ‘% ‘ (процент и пробел) — это разделитель поля нулевой ширины, который не производит никакого вывода.

Вышеуказанное поведение можно изменить, добавив модификаторы к элементу строки формата. Модификатор — (минус) приводит к записи минуса, если соответствующий элемент не производит никакого вывода. В форматах один-раз-на-соединение/запрос также можно использовать модификатор + (плюс). Если элемент с модификатором плюс не производит никакого вывода, вся строка опускается.

Число в качестве модификатора может использоваться для назначения уровня серьёзности журнала элементу формата. Элемент будет зарегистрирован только в том случае, если серьёзность сообщения журнала не выше указанного уровня серьёзности журнала. Число может варьироваться от 1 (alert) до 4 (warn) и 7 (debug) до 15 (trace8).

Например, вот что произойдёт, если вы добавите модификаторы в токен %i, который регистрирует заголовок запроса Referer.

Модифицированный токен	Значение
%-i	Регистрирует — если Referer не установлен.
%+i	Опускает всю строку, если Referer не установлен.
%4i	Регистрирует Реферер только в том случае, если серьёзность сообщения журнала выше 4.

Некоторые элементы строки формата принимают дополнительные параметры в фигурных скобках.

Строка формата	Описание
%%	Буквальный знак процента.
%a	Клиентский IP адрес запроса (смотрите также модуль mod_remoteip).
%a	Лежащий в основе IP-адрес соединения (см. модуль mod_remoteip).
%A	Локальный IP-адрес.
%<ИМЯ>e	Содержимое переменной окружения запрос с ИМЕНЕМ.
%E	Код состояния и строка ошибки APR/OS
%F	Имя исходного файла и номер строки журнала вызовов
%<ИМЯ>i	ИМЯ заголовка запроса
%k	Количество запросов подтверждения активности (keep-alive) для этого соединения
%l	Лог-уровень сообщения
%L	Лог ID запроса
%L	Лог ID соединения
%L	Идентификатор журнала соединения, если используется в области соединения, в противном случае пусто
%m	Имя модуля, регистрирующего сообщение
%M	Фактическое сообщение журнала
%<ИМЯ>n	Идентификатор процесса текущего процесса
%P	Идентификатор дочернего процесса, который обслуживал запрос.
%T	Идентификатор текущего процесса
%T	Уникальный системный идентификатор текущего потока (тот же идентификатор, который отображается, например, top; в настоящее время только в Linux)
%t	Текущее время
%t	Текущее время, включая микросекунды
%t	Текущее время в компактном формате ISO 8601, включая микросекунды
%v	Каноническое ServerName сервера, обслуживающего запрос.
%V	Имя сервера в соответствии с настройкой UseCanonicalName.
\ (обратный слэш и пробел)	Пробельный разделитель без создания нового поля (разделитель внутри одного поля, пробел внутри поля)
% (процент и пробел)	Разделитель полей (без вывода)

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

Это может привести к сообщениям об ошибках, таких как:

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

Директива LogLevel

Описание: Контролирует вербальность ErrorLog.

Значение по умолчанию:

Контекст: server config, виртуальные хосты, директории

Совместимость: Настройка на уровне модулей и на уровне директорий доступны в Apache HTTP Server 2.3.6 и более поздних.

LogLevel регулирует подробность сообщений, записываемых в журналах ошибок (см. директиву ErrorLog). Доступны следующие уровни в порядке убывания значимости:

Уровень	Описание	Пример
emerg	Чрезвычайные ситуации — система не работоспособна.	«Child cannot open lock file. Exiting»
alert	Действие должно быть принято немедленно.	«getpwuid: couldn’t determine user name from uid»
crit	Критические условия.	«socket: Failed to get a socket, exiting child»
error	Ошибки.	«Premature end of script headers»
warn	Предупреждения.	«child process 1234 did not exit, sending another SIGHUP»
notice	Нормальное, но значимое состояние.	«httpd: caught SIGBUS, attempting to dump core in …»
info	Информационные сообщения.	«Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)…»
debug	Сообщения уровня отладки.	«Opening config file …»
trace1	Трассировочные сообщения.	«proxy: FTP: control connection complete»
trace2	Трассировочные сообщения.	«proxy: CONNECT: sending the CONNECT request to the remote proxy»
trace3	Трассировочные сообщения.	«openssl: Handshake: start»
trace4	Трассировочные сообщения.	«read from buffered SSL brigade, mode 0, 17 bytes»
trace5	Трассировочные сообщения.	«map lookup FAILED: map=rewritemap key=keyname»
trace6	Трассировочные сообщения.	«cache lookup FAILED, forcing new map lookup»
trace7	Трассировочные сообщения, сброс больших объёмов данных.	«| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |»
trace8	Трассировочные сообщения, сброс больших объёмов данных.	«| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |»

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

то также будут публиковаться сообщения с уровнями notice и warn.

Обратите внимание, что сообщения об ошибках 404 (файл не найден), которые генерирует сам веб-сервер (core), имеют статус info:

Это означает, что при настройках по умолчанию (LogLevel установлена на warn) запросы, завершившиеся статусом 404 не будут попадать в журналы ошибок! Чтобы это исправить, нужно установить уровень на info:

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

Рекомендуется использовать уровень как минимум crit (или более низкой значимости).

Примечание: при записе в обычный файл сообщения с уведомлением с уровнем notice не могут быть подавлены и, следовательно, всегда регистрируются. Однако это не относится к случаям, когда регистрация ведётся с использованием syslog.

Указание уровня без имени модуля приведёт к сбросу уровня для всех модулей до этого уровня. Указание уровня с именем модуля установит уровень только для этого модуля. Можно использовать имя исходного файла модуля, идентификатор модуля или идентификатор модуля с конечным _module, опущенным в качестве спецификации модуля. Это означает, что следующие три спецификации эквивалентны:

Также возможно изменить уровень для каждого каталога:

Конфигурация на уровне каталога для каждого каталога влияет только на сообщения, которые регистрируются после анализа запроса и связаны с ним. Сообщения журнала, связанные с сервером или соединением, не затрагиваются. Однако на последние может повлиять директива LogLevelOverride.

Директива LogLevelOverride

Описание: Переопределить вербальность ErrorLog для определённых клиентов.

Значение по умолчанию: не установлено.

Контекст: server config, виртуальные хосты.

Совместимость: Доступна в Apache HTTP Server 2.5.0 и более поздних.

LogLevelOverride принимает либо один IP-адрес, либо спецификацию IP-адресов CIDR/длина_подсети. Синтаксис спецификации loglevel см. в разделе Директива LogLevel.

Для запросов, соответствующих директиве LogLevelOverride, спецификации LogLevel для каждого каталога игнорируются.

LogLevelOverride влияет только на сообщения журнала, связанные с запросом или соединением. Сообщения журнала, связанные с сервером, не затрагиваются.

Журнал событий модулей

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

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

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

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

Обратите внимание, что информация, которую генерируют модули, всегда попадает в лог ошибок, даже если не является по сути ошибкой! Также обратите внимание, что некоторые модули не будут показывать никакой информации, если не установить уровень трассировки в диапазоне от trace1 до trace8.

Источник