Просмотр логов apache windows

Для эффективного управления веб-сервером необходимо получить обратную связь об активности и производительности сервера, а также о всех проблемах, которые могли случиться. 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» относительно корневой папки веб-сервера:

ErrorLog "logs/error.log"

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

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

• debug
• info
• notice
• warn
• error
• crit
• alert
• emerg

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

Картинка с сайта: apache-windows.ru

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

Формат журнала ошибок определяется директивой 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

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)

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

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

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

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

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

• %h — имя удалённого хоста. Будет записан IP адрес, если HostnameLookups установлен на Off, что является значением по умолчанию.
• %l — длинное имя удалённого хоста (от identd, если предоставит). Это вернёт прочерк если не присутствует mod_ident и IdentityCheck не установлен на On.
• %u — удалённый пользователь, если запрос был сделан аутентифицированным пользователем. Может быть фальшивым, если возвращён статус (%s) 401 (unauthorized).
• %t — время получения запроса в формате [18/Sep/2011:19:18:28 -0400]. Последнее показывает сдвиг временной зоны от GMT
• \»%r\» — первая строка запроса, помещённая в буквальные кавычки
• %>s — финальный статус. Если бы было обозначение %s, то означало бы просто статус — для запросов, которые были внутренне перенаправлены это обозначало бы исходный статус.
• %b — размер ответа в байтах, исключая HTTP заголовки. В формате CLF, то есть ‘—‘ вместо 0, когда байты не отправлены.

Директива 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, определённой с помощью id на клиентском компьютере. Эта информация крайне ненадёжна и почти никогда не должна использоваться, кроме как в жёстко контролируемых внутренних сетях. Apache httpd даже не будет пытаться определить эту информацию, если для IdentityCheck не установлено значение On.

frank (%u)

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

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

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

[день/месяц/год:час:минута:секунда зона]

день = 2*цифры

месяц = 3*цифры

год = 4*цифры

час = 2*цифры

минута = 2*цифры

секунда = 2*цифры

зона = (`+’ | `-‘) 4*цифры

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

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

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

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

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/access_log combined

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

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\»)

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

«Mozilla/4.08 [en] (Win98; I ;Nav)» (\»%{User-agent}i\»)

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

Картинка с сайта: apache-windows.ru

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

<IfModule log_config_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common

    <IfModule logio_module>
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>

    CustomLog "logs/access.log" common   
</IfModule> 

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

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

CustomLog "logs/access.log" combined

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

В данной статье вы узнаете, как просматривать лог-файлы журнала доступа Apache.

Просмотр журналов доступа Apache

Использование cPanel для загрузки необработанных файлов регистрации доступа

Если вы вошли на веб-сервер с помощью cPanel, то вы можете загрузить журналы доступа Apache через графический интерфейс.

1. Найдите раздел с надписью «Metrics».

Картинка с сайта: wiki.merionet.ru

1. Нажмите «Raw Access». Если включено архивирование, то необработанные файлы журналов Apache можно загрузить внизу страницы. Они будут выглядеть как стандартные гиперссылки, промаркированные с учетом конструкции веб-сайта, которым вы управляете.

Картинка с сайта: wiki.merionet.ru

При нажатии на гиперссылку вам будет предложено сохранить или открыть файл. Эти лог-файлы сжаты при помощи gzip, поэтому, если ваша систему отлична от Linux, то вам могут понадобиться дополнительные инструменты для распаковки. Сохранить файл вы можете в любую папку.

1. Найдите файл в своей ОС, затем щелкните на него правой кнопкой мыши и выберите extract(извлечь). После этого должен появиться новый файл без расширения .gz.

1. Щелкните правой кнопкой мыши и выберите edit (изменить), чтобы открыть файл в любом текстовом редакторе и просмотреть его содержимое.

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

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

По умолчанию вы можете найти лог-файл по следующим путям:

• /var/log/apache/access.log
• /var/log/apache2/access.log
• /etc/httpd/logs/access.log

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

Шаг 1: Отображение последних 100 записей журнала доступа

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

sudo tail -100 /var/log/apache2/access.log

Команда tail указывает на то, что необходимо прочитать последнюю часть файла, а команда -100 – что нужно отобразить 100 записей.

Последняя часть команды, /var/log/apache2/access.log, указывает, где искать лог-файл. Если ваш лог-файл имеет другое расположение, то обязательно укажите верный путь.

Шаг 2: отображение записей определенного типа из журнала доступа

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

Например, введите в терминал следующую команду:

sudo grep GET /var/log/apache2/access.log

Как и предыдущая команда, она обращается к файлу /var/log/apache2/access.log, чтобы отобразить содержимое журнала доступа. Команда grep указывает на то, что отобразить нужно только записи с запросом GET.

Эту команду можно заменить на любые другие команды Apache. Например, если вы хотите отследить доступ к изображениям в формате .jpg, то вы можете заменить GET на .jpg. Как и в предыдущей команде, следите за тем, чтобы был указан фактический путь к лог-файлу вашего сервера.

Просмотр журнала ошибок Apache

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

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

sudo tail -100 /var/log/apache2/error.log

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

Как читать логи в Apache

Когда вы открываете лог-файл доступа впервые, то внутренний вид вас может потрясти.

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

Традиционный формат отображения лог-файла доступа:

"%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i""

Это код для наиболее общих параметров в каждой строке лог-файла.

Каждый знак % соответствует определенному фрагменту информации в журнале:

• %h – IP-адрес клиента (источника запроса на доступ).
• %l – следующая запись может быть просто дефисом – это означает, что информация не была получена. Это результат проверки identd на стороне клиента.
• %u – идентификатор пользователя клиентской стороны, если для запроса доступа требуется HTTP-аутентификация.
• %t – временная метка входящего запроса.
• %r – использованная строка запроса. Здесь речь идет о методе http (GET, POST, HEAD и т.д.), пути к тому, что было запрошено, и используемом протоколе http.
• %>s – код состояния, возвращенный сервером клиенту.
• %b – размер запрошенного ресурса.
• «%{Referer}i» — указывает на то, как был получен доступ, путем перехода по ссылке на другом веб-сайте или другими способами, с помощью которых клиент был направлен на вашу страницу.
• «%{User-agent}i» — сообщает вам информацию об объекте, совершающем запрос, например, о веб-браузере, операционной системе, источнике веб-сайта (если это робот) и т.д.

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

Дополнительную информацию о форматах журналов декодирования можно найти тут

Как использовать данные в лог-файлах Apache

Анализ журнала Apache дает возможность наблюдать за способами взаимодействия клиентов с вашим сайтом.

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

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

Заключение

В данной статье были представлены методы извлечения данных для просмотра лог-файлов доступа Apache.

Файл access.log – отличный вариант для того, чтобы проанализировать то, как клиенты взаимодействуют с вашим сервером. А файл error.log может помочь вам устранить проблемы с вашим веб-сайтом.

Apache – the technology that powers the web. I’m not sure if that is correct, but I think that we wouldn’t see the world wide web in its current shape without it. Launched in 1995 and since April 1996, it has been the most popular web server around the world.

Because of handling your users’ requests, Apache serves as the front application. It is crucial to understand what your server is doing, what file users are accessing, from where they came, and much, much more.

The visibility that Apache logs give you is invaluable in understanding the traffic coming to your application, the errors that happen, and the performance of the user-facing elements. Today, we will look into what the Apache web server logs are, how to interpret them, and how to analyze them easily.

What Are Apache Logs?

Apache logs are text files that contain all the information on what the Apache server is doing. They provide insight into which resources were accessed, when they were accessed, who accessed them, and metrics related to that. They also include information about the errors that happened, resource mapping process, the final resolution of the connection, and many, many more.

In general, the whole Apache logging process comes in multiple phases. First, you need to store the logs somewhere for historical analytical purposes. Second, you need to analyze the logs and parse them to retrieve useful information and metrics. And finally, you may want to graph the data as the visual representation is easier to analyze and understand for a human person.

What Is the Apache Access Log?

The Apache access logs are text files that include information about all the requests processed by the Apache server. You can expect to find information like the time of the request, the requested resource, the response code, time it took to respond, and the IP address used to request the data.

Apache Access Logs Location

The location of the Apache server access log differs depending on the operating system that you are using.

• On Red Hat, CentOS, or Fedora Linux, the access logs can be found in the /var/log/httpd/access_log by default.
• On Debian and Ubuntu, you can expect to find the Apache logs in the /var/log/apache2/access.log and
• FreeBSD will have the Apache server access logs stored in /var/log/httpd-access.log file.

You can configure its location using the CustomLog directive, for example:

CustomLog "/var/log/httpd-access.log"

Apache Access Log Format Configuration

Before we learn about the different log formats, let’s discuss what the Apache HTTP can do when it comes to formatting. There are two most common access log types that you can use and that the Apache server will translate to meaningful information:

• Common Log Format
• Combined Log Format

The log formatting directives are used in combination with the LogFormat option:

LogFormat "%t %h %m \"%r\"" custom

The above line tells that the “%t %h %m \”%r\”” format should be used and assigned to an alias called custom. After that, we can use the custom alias when defining Apache logging. For example:

CustomLog "logs/my_custom_log" custom

The above section will tell Apache to write logs in the logs/my_custom_log file with the format defined by the custom alias. The above configuration will result in logging:

• time of the request thanks to the %t directive,
• remote hostname thanks to the %h directive,
• HTTP method thanks to the %m directive,
• the first line of the request surrounded by double quotes thanks to the %r directive.

Of course, there are way more directives that can be used and the complete list can be found in the mod_log_config documentation of the Apache server.

Common Log Format

The Apache Common Log Format is one of the two most common log formats used by HTTP servers. You can expect it to see its definition to look similar to the following line:

LogFormat "%h %l %u %t \"%r\" %>s %b" common

Here’s how an access log from that log file looks like:

10.1.2.3 - rehg [10/Nov/2021:19:22:12 -0000] "GET /sematext.png HTTP/1.1" 200 3423

As you can see the following elements are present:

• %h, resolved into 10.1.2.3 – the IP address of the remote host that made the request.
• %l, remote log name provided by identd, in our case a hyphen is provided, which is a value that we can expect to be logged in a case when the information provided by the logging directive is not found or can’t be accessed.
• %u, resolved into rehg, the user identifier determined by the HTTP authentication.
• %t, the date and time of the request with the time zone, in the above case it is [10/Nov/2021:19:22:12 -0000]
• \”%r\”, the first line of the request inside double quotes, in the above case it is: “GET /sematext.png HTTP/1.1”
• %>s, the status code reported to the client. This information is crucial because it determines whether the request was successful or not.
• %b, the size of the object sent to the client, in our case the object was the sematext.png file and its size was 3423 bytes.

Combined Log Format

The Apache Combined Log Format is another format often used with access logs. It’s very similar to the Common Log Format but includes two additional headers – the referrer and the user agent. Its definition looks as follows:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined

And the example log line produced by the above log line looks like this:

10.1.2.3 - grah [12/Nov/2021:14:25:32 -0000] "GET /sematext.png HTTP/1.1" 200 3423 "http://www.sematext.com/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.74 Safari/537.36 Edg/79.0.309.43"

Custom Log Format

There is one more thing that we should discuss when it comes to Apache Server logging configuration – the CustomLog directive. We’ve already seen that configuration directive, but let’s discuss that in greater details.

Multiple Access Logs

It is possible to have multiple Apache access logs at the same time without any additional effort. We may want a limited set of information available in some files for quick scanning and the full log using the Combined Log Format if we need the complete information. For example, we could have three access log files – one that includes time, user agent, and the status code, the second that includes the time, IP address, and referrer used, and the third – the Common Log Format.

To do that we need to include multiple CustomLog sections in our configuration file:

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/agent_log "%t %{User-agent}i %>s"
CustomLog logs/referer_log "%t %h %{Referer}i"
CustomLog logs/access_log common

You can see that this time we didn’t use three separate LogFormat configuration options, but we’ve specified the apache log format in the CustomLog format line. This is also possible and very convenient when the formatting of the log lines is used only in that given file.

Conditional Logs

There are cases when you would like to write logs only when a certain condition is met. This is what Apache Server calls conditional logging. It is done by using the CustomLog directive and environment variables. For example, if you would like to log all requests accessing your PNG files in a separate file you can do that the following way:

SetEnvIf Request_URI \.png$ png-image-log
CustomLog "png-access.log" common env=png-image-log

Logs Rotation and Piped Logs

Depending on the logging configuration and the traffic that your Apache servers are handling, logging can be extensive. All the logs that you keep on the machine take space and if you are not using a log centralization solution like Sematext Logs, you will have to deal with space and management of logs.

Let’s talk about log rotation first. Log rotation is a process of creating a new log file that the Apache HTTP server will start writing to and renaming the old log file, so it is no longer updated. The log rotation happens when you gracefully restart the server. That means that without any kind of client requests processing interruption a new log file is created. In production environments, you would like to restart the Apache servers though.

That’s why the Apache server supports piped logs. Instead of writing the log events to a file, you use the piped logs to send the log events to a different application that will handle the log processing – for example to rotatelogs:

CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access.log 86400" common

The rotatelogs application comes with Apache server and is capable of rotating logs without the need of restarting the server. The above example will result in rotating the /var/log/access.log file every 24 hours.

How to Read Apache Access Logs

Apache server access logs are just simple text files. They can be easily opened by any tool that can read such files. On Linux-based systems, this can be the cat command-line tool or tail if you want to monitor the log lines as they go.

There are two caveats, though. The first is access policies. You may not have access to the machines running Apache HTTP server and even if you do, you may not have read access to the appropriate log directories. The second is distribution. It is not uncommon to have multiple Apache servers distributed across multiple data centers. In such a case, it is way easier to use a dedicated observability tool such as Sematext Logs that will provide not only the option to look into the raw files but also aggregated information into the key metrics derived for them.

Understanding Apache Access Logs

Our Apache access logs files are easy to read and not hard to understand either. Just remember about the patterns that you’ve used in your configuration. We’ve already covered the common patterns that you can encounter in the Apache log files. Keep in mind that understanding the log files is even easier with log analysis tools that do the parsing for you and give you an aggregated view of the data which is easier to understand.

What Is the Apache Error Log?

So far, we’ve talked about the Apache access log that gives us information on the accessed resources. But it is not the only thing that we should be interested in. We should also care about everything related to errors. In fact, the error log is the most important log file for the Apache HTTP server.

The Apache error log is where all the errors that happened during the processing of the requests. The most important thing, though, is that the error log will contain information on what went wrong during the Apache server startup and it is very likely that it will also contain hints on how to fix the issue.

Apache Errors Logs Location

Where the Apache error log is stored differs depending on the operating system on which it is running.

• On Red Hat, CentOS, or Fedora Linux, the access logs can be found in the /var/log/httpd/error_log by default.
• On Debian and Ubuntu, you can expect to find the Apache logs in the /var/log/apache2/error.log
• FreeBSD will have the Apache server access logs in /var/log/httpd-error.log file.

You can configure its location using the ErrorLog directive, for example:

ErrorLog "/var/log/httpd-error.log"

Apache Error Log Format Configuration

Similar to the Apache access log, you can adjust the format of the error log. The Apache error log format is configured by using the ErrorLogFormat element, for example:

ErrorLogFormat “[%{u}t] [%-m:%l] [pid %P:tid %T] [client\ %a] %M”

The above configuration would produce an Apache error log entry similar to the following one:

[Wed Nov 10 10:21:23.811033 2021] [core:error] [pid 22308:tid 3212342123] [client 10.1.2.3] File does not exist: /usr/local/apache2/htdocs/favicon.ico

In the above example the following formatting options were used:

• %{u}t – the current time including microseconds,
• %-m – the module that produced the error,
• %l – the level of the log event,
• %P – process identifier,
• %T – thread identifier,
• %M – the actual log message.

The full description of the available formatting options is available in the official Apache Server documentation.

Log Levels

In addition to what we discussed so far there is one other thing worth mentioning – the level of log events. The LogLevel directive allows specifying the level of log messages on a per-module basis. For example, if we would like the main log level for all events to be set to the info level but have the error level only for the rewrite module, we could have a configuration directive as follows:

LogLevel info rewrite:error

The following logging levels are described in Apache server documentation:

• emerg
• alert
• crit
• error
• warn
• notice
• info
• debug
• trace1 – trace8

The emerg one is the log event that says that the system is unstable and the trace levels are used for very low-level information logging that you can probably skip.

How to View Apache Error Logs

Viewing the Apache server error logs is just as simple as opening the text file. The error logs are not different from the access logs, so they are just simple text files. You can use whatever tools you want to look into them. But keep in mind that looking into logs from multiple Apache servers distributed across multiple data centers can be challenging. That’s why we strongly suggest using log aggregation tools, such as Sematext Logs, for that job.

Apache Log File Management and Analysis with Sematext

Картинка с сайта: sematext.com

Sematext Cloud Logs – Apache Overview

Understanding and analyzing your Apache servers logs was never easier than with Sematext Logs. The only thing that you need to do is create an account with Sematext, create the Apache Logs App and install the Sematext Agent. You will be guided through the process of setting up the automatic Logs Discovery for your Logs. Your logs will be parsed and sent to the Sematext Logs giving you access to a variety of pre-built reports tailored for your Apache HTTP server.

Картинка с сайта: sematext.com

Sematext Logs – Apache HTTP Information

Sematext Logs is part of the Sematext Cloud full-stack monitoring solution providing you with all you need when it comes to observability. With Sematext Cloud, you get an overview of your Apache servers, errors report, HTTP report, including top HTTP methods and paths with an average response size visualization and requests table. You can see your users with the top User Agents used to access resources served by your Apache servers and, finally, the sources for the data. All within a single Apache Logs monitoring in Sematext Cloud.

Still not sure which open-source search engine to use? Check out this quick video comparing Apache Solr and Elasticsearch below:

Conclusion

Analyzing your Apache servers logs is invaluable in understanding the traffic coming to your application, the errors that happen, and the performance of the user-facing elements. A log management tool such as Sematext Logs does this job for you.

More than understanding server logs, knowing what resources were accessed, who accessed them, and how long it took to process the request is crucial to understanding your user’s behavior. You also need to be sure that you are aware of every error that happens so that you can react as soon as possible. Combining that with the need for distributed infrastructures to handle a large number of concurrent users and provide high availability, using an observability tool is a necessity.

Having Apache metrics and logs in the same place, being able to slice and dice them, being alerted when issues appear and having insight into every piece of your environment is no longer something good to have but need to have. All of that and more is provided by Sematext Cloud, an observability platform with dedicated Apache server logs and metrics support. Built with simplicity in mind and requiring no credit card, nothing stops you from giving it a try to see how it can improve your log management and log analysis processes.