Apache logs: Log Files — Apache HTTP Server Version 2.4

Для этого существуют уровни логирования. К примеру, наиболее важные сообщения, уведомляющие о критических ошибках и сбоях, существует уровень emerg. А сообщения уровня info просто предоставляют полезные подсказки.

Существуют следующие уровни логирования:

• emerg: критическая ситуация, аварийный сбой, система находится в нерабочем состоянии.
• alert: сложная предаварийная ситуация, необходимо срочно принять меры.
• crit: критические проблемы, которые необходимо решить.
• error: произошла ошибка.
• warn: предупреждение; в системе что-то произошло, но причин для беспокойства нет.
• notice: система в норме, но стоит обратить внимание на её состояние.
• info: важная информация, которую следует принять к сведению.
• Debug: информация для отладки, которая может помочь определить проблему.
• trace[1-8]: Трассировка информации различных уровней детализации.

При настройке логирования задаётся наименее важный уровень, который нужно вносить в лог. Что это значит? Логи фиксируют указанный уровень логирования, а также все уровни с более высоким приоритетом. К примеру, если выбрать уровень error, логи будут фиксировать уровни error, crit, alert и emerg.

Для настройки уровня логирования существует директива LogLevel. Уровень логирования по умолчанию задан в стандартном конфигурационном файле:

sudo nano /etc/apache2/apache2.conf
. . .
LogLevel warn
. . .

Как видите, по умолчанию Apache вносит в лог сообщения уровня warn (и более приоритетных уровней).

Где находятся логи Apache?

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

Общесерверные настройки логирования

Чтобы узнать, где находятся стандартные логи сервера, откройте конфигурационный файл.

sudo nano /etc/apache2/apache2.conf

Найдите в файле строку:

ErrorLog ${APACHE_LOG_DIR}/error.log

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

Чтобы узнать значение переменной APACHE_LOG_DIR, откройте файл envvars:

sudo nano /etc/apache2/envvars
. . .
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
. . .

Согласно этому файлу, переменная APACHE_LOG_DIR настроена на каталог /var/log/apache2. Это означает, что Apache  соединит это значение с директивой в конфигурационном файле apache2.conf и будет вносить данные в лог /var/log/apache2/error.log.

sudo ls /var/log/apache2
access.log  error.log  other_vhosts_access.log

Как видите, тут находится лог ошибок error.log и несколько других логов.

Логирование виртуальных хостов

Файл access.log, упомянутый в конце предыдущего раздела, не настраивается в файле apache2.conf. Вместо этого разработчики поместили соответствующую директиву в файл виртуального хоста.

Откройте и просмотрите стандартный виртуальный хост:

Пролистайте файл и найдите следующие три значения, связанные с логированием:

. . .
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
. . .

Местонахождение ErrorLog совпадает с его определением в стандартном конфигурационном файле. Эта строка не обязательно должна находиться в двух отдельных файлах; при изменении местонахождения этого лога в одном из файлов ошибки не возникнет.

Пользовательские логи

В предыдущем разделе строка, описывающая access.log, использует не такую директиву, как предыдущие строки для настройки логов.

CustomLog ${APACHE_LOG_DIR}/access.log combined

Эта директива имеет такой синтаксис:

CustomLog log_location log_format

В данном случае log_format (формат логов) является комбинированным (combined). Эта спецификация не является внутренней спецификацией Apache; она задаёт пользовательский формат, который определен в конфигурационном файле по умолчанию.

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

sudo nano /etc/apache2/apache2.conf
. . .
LogFormat "%h %l %u %t \"%r\" %>s %O \"{Referer}i\" \"%{User-Agent}i\"" combined


Команда LogFormat определяет пользовательский формат логов, вызываемых директивой CustomLog.

Этот формат называется комбинированным (combined).

Примечание: Подробнее о доступных форматах можно узнать здесь.

Существует еще несколько распространённых форматов, которые можно использовать в определении виртуальных хостов. Можно также создавать свои собственные форматы.

Ротация логов Apache

Ротация логов – это процесс, подразумевающий отключение устаревших или слишком объёмных лог-файлов и их архивирование (на установленный период времени). Apache может вносит в лог довольно большие объёмы данных, следовательно, во избежание заполнения дискового пространства необходимо настроить ротацию логов.

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

Рассмотрим методы настройки ротации логов Apache.

Ротация логов вручную

Перемещать логи во время работы Apache нельзя. То есть, чтобы переместить в архив устаревшие или заполненные логи и заменить их новыми, нужно перезапустить сервер.

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

Ниже приведён пример из документации Apache. Возможно, понадобится добавить в начало этих команд sudo.

mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
[post-processing of log files]

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

Имейте в виду: ротация логов вручную очень ненадёжна в больших серверных средах.

Утилита logrotate

По умолчанию система Ubuntu настраивает ротацию логов при помощи утилиты logrotate.

Данная программа может выполнять ротацию логов при соблюдении определенных критериев. Просмотреть события, включающие Logrotate для ротации логов, можно в файле /etc/logrotate.d/apache2:

sudo nano /etc/logrotate.d/apache2

В нём находится несколько параметров logrotate. Обратите внимание на первую строку:

/var/log/apache2/*.log {

Это значит, что logrotate будет выполнять ротацию только тех логов, которые находятся в /var/log/apache2. Имейте это в виду, если вы выбрали другой каталог для хранения в конфигурации Apache.

Как видите, логи ротируются еженедельно. Также тут есть раздел кода, перезапускающий Apache после ротации:

postrotate
/etc/init.d/apache2 reload > /dev/null
endscript

Эти строки автоматически перезапускают веб-сервер Apache после завершения ротации.

Примечание: К сожалению, настройки данного файла не охвачены в данном руководстве.

Ротация логов по каналам

Использование каналов вместо файлов – простой способ передать обработку вывода программе логирования.  Это также решает проблему ротации логов, поскольку ротация может выполняться с помощью программы на серверной стороне (а не самим сервером Apache).

Чтобы логи обрабатывались программой логирования, принимающей стандартный вывод, замените следующую строку следующим образом:

CustomLog "| logging_program logging_program_parameters" combined

Apache запустит программу логирования во время загрузки и перезапустит её в случае ошибки или сбоя.

Для ротации логов можно использовать разные программы, но по умолчанию Apache поставляется с rotatelogs. Чтобы настроить эту программу, используйте:

CustomLog "| /path/to/rotatelog /path/of/log/to/rotate number_of_seconds_between_rotations" log_level

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

Заключение

Конечно, это руководство охватывает только основы логирования Apache.

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

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

Настройка журналов ошибок и доступа Apache

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

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

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

В этой статье описывается, как настроить и прочитать журналы доступа и ошибок Apache.

Содержание

Настройка журнала доступа

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

Директива CustomLog определяет расположение файла журнала и формат регистрируемых сообщений.

Базовый синтаксис директивы CustomLog следующий:

CustomLog log_file format [condition];

log_file может относиться либо к ServerRoot либо к полному пути к файлу журнала. Сообщения журнала также можно передать другой программе с помощью символа вертикальной черты | .

Второй аргумент, format определяет формат сообщений журнала. Это может быть явное определение формата или псевдоним, определяемый директивой LogFormat .

LogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combined
CustomLog logs/access.log combined

CustomLog logs/access.log "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i""

Чтобы не повторять один и тот же код несколько раз, предпочтительнее определить директиву LogFormat и использовать ее в качестве псевдонима в директиве CustomLog .

Полный список всех строк формата и модификаторов см. В документации модуля «mod_log_config» .

Третий аргумент [condition] является необязательным и позволяет записывать сообщения журнала только при выполнении определенного условия. Обычно это делается с использованием переменных окружения. Условие может быть отменено с помощью ! условное обозначение.

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

SetEnvIf Request_URI .css$ css-file
CustomLog logs/access.log custom env=!css-file

Чтобы изменить формат ведения журнала, вы можете определить новую директиву LogFormat или переопределить формат по умолчанию. Обычно лучше определить новый формат.

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

Для этого просто закомментируйте или удалите директиву CustomLog из разделов конфигурации основного сервера и виртуального сервера.

Если вы хотите отключить журнал доступа только для одного виртуального хоста, установите для первого аргумента директивы CustomLog значение /dev/null :

CustomLog /dev/null combined

Настройка журнала ошибок

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

Директива ErrorLog определяет расположение имени журнала ошибок. Он имеет следующий вид:

ErrorLog log_file

Если путь к log_file не является абсолютным, он устанавливается относительно ServerRoot . Сообщения об ошибках также могут быть переданы другой программе с помощью символа вертикальной черты | .

Параметр LogLevel устанавливает уровень ведения журнала. Ниже перечислены уровни в порядке их серьезности (от низкого до высокого):

• trace1 — trace8 — сообщения трассировки.
• debug — debug сообщения.
• info — Информационные сообщения.
• notice — Уведомления.
• warn — Предупреждения.
• error — Ошибки при обработке запроса.
• crit — Критические проблемы. Требуется быстрое действие.
• alert — Оповещения. Действия должны быть предприняты немедленно.
• emerg — Чрезвычайная ситуация. Система находится в непригодном для использования состоянии.

Каждый уровень журнала включает в себя более высокие уровни. Например, если вы установите уровень журнала , чтобы warn , Apache также записывает error , crit , alert и emerg сообщения.

Если параметр LogLevel не указан, по умолчанию используется warn . Рекомендуется установить уровень как минимум crit .

Директива ErrorLogFormat определяет формат журнала ошибок. В большинстве дистрибутивов Linux сервер Apache использует формат по умолчанию, которого достаточно в большинстве случаев.

Виртуальные хосты и глобальное ведение журнала

Поведение журнала и расположение файлов можно установить глобально или для каждого виртуального хоста.

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

Директива журнала, установленная в блоке <VirtualHost> заменяет директиву, установленную в контексте сервера.

Виртуальные хосты без директив CustomLog или ErrorLog будут записывать свои сообщения журнала в глобальные журналы сервера.

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

<VirtualHost *:80>
     ServerName example.com
     ServerAlias www.example.com
     ServerAdmin [email protected]
     DocumentRoot /var/www/example.com/public
     LogLevel warn
     ErrorLog /var/www/example.com/logs/error.log
     CustomLog /var/www/example.com/logs/access.log combined
</VirtualHost>

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

Расположение файлов журнала

По умолчанию в дистрибутивах на основе Debian, таких как Ubuntu , журналы доступа и ошибок расположены в каталоге /var/log/apache2 . В CentOS файлы журнала помещаются в каталог /var/log/httpd .

Чтение и понимание файлов журнала Apache

Файлы журнала можно открывать и анализировать с помощью стандартных команд, таких как cat , less , grep , cut , awk и т. Д.

Вот пример записи из файла журнала доступа, в котором используется формат журнала combine Debian:

192.168.33.1 - - [08/Jan/2020:21:39:03 +0000] "GET / HTTP/1.1" 200 6169 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36"

Давайте разберемся, что означает каждое поле записи:

• %h — 192.168.33.1 — Имя хоста или IP-адрес клиента, выполняющего запрос.
• %l — - — Имя удаленного журнала. Если имя пользователя не задано, в этом поле отображается - .
• %u — - — Если запрос аутентифицирован, отображается имя удаленного пользователя.
• %t — [08/Jan/2020:21:39:03 +0000] — Время локального сервера.
• "%r" — "GET / HTTP/1.1" — первая строка запроса. Тип запроса, путь и протокол.
• %>s — 200 — окончательный код ответа сервера. Если символ > не используется и запрос был перенаправлен внутри, он покажет статус исходного запроса.
• %O — 396 — Размер ответа сервера в байтах.
• "%{Referer}i" — "-" — URL перехода.
• "%{User-Agent}i" — Mozilla/5.0 ... — Пользовательский агент клиента (веб-браузера).

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

tail -f access.log 

Выводы

Файлы журналов содержат полезную информацию о проблемах с сервером и о том, как посетители взаимодействуют с вашим сайтом.

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

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Файлы журнала — Apache HTTP Server версии 2.4

Доступные языки:  en  | фр  | я | ко | tr 

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

[Пт, 09 сентября, 10:42:29. 2 2011] [core:error] [pid 35708:tid 4328636416] [клиент 72.15.99.187] Файл не существует: /usr/local/apache2/htdocs/favicon.ico

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

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

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

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

хвост -f журнал_ошибок

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

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

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

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

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

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

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

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

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

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

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

 LogFormat "%h %l %u %t \"%r\" %>s %b" общий
CustomLog logs/access_log common 

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

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

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

127.0.0.1 - откровенный [10/окт/2000:13:55:36 -0700] "ПОЛУЧИТЬ /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 до На .

откровенный ( %u )

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

[10 октября 2000:13:55:36 -0700] ( %т )

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

[день/месяц/год:час:минута:секундная зона]
день = 2*цифра
месяц = ​​3*буква
год = 4*цифра
час = 2*цифра
минута = 2*цифра
секунда = 2* зона цифр
= (`+' | `-') 4*цифра

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

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

Строка запроса от клиента дается в двойном размере кавычки. Строка запроса содержит много полезного информация. Во-первых, метод, используемый клиентом, ПОЛУЧИТЬ . Во-вторых, клиент запросил ресурс /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/журнал_доступа 

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

127.0.0.1 - откровенный [10/окт/2000:13:55:36 -0700] "ПОЛУЧИТЬ /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [ru] (Win98; я ;Nav)"

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

"http://www.example.com/start.html" ( \"%{Referer}i\" )

Заголовок HTTP-запроса Referer (sic). Это дает сайт, с которого, по словам клиента, он был направлен. (Этот должна быть страница, которая ссылается или включает /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 logs/agent_log "%{User-agent}i" 

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

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

Иногда бывает удобно исключить определенные записи из журналов доступа на основе характеристик запрос клиента. Это легко сделать с помощью переменных окружения. Во-первых, переменная среды должна быть установлена, чтобы указать, что запрос соответствует определенным условиям. Обычно это достигается с SetEnvIf . Затем env= пункт 9/robots\.txt$" не логировать # Записываем, что осталось CustomLog logs/access_log common env=!dontlog

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

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

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

 SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t "%r" %>s %b %{CACHE_MISS}e" общий кэш
CustomLog logs/access_log common-cache 

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

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

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

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

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

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

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

mv access_log access_log.old
mv error_log error_log.old
apachectl изящный
сон 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" common 

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

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

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

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

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

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

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

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

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

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

 LogFormat "%v %l %u %t \"%r\" %>s %b" общий хост
CustomLog logs/access_log comonvhost 

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

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

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

Forensic Logging

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

Файл PID

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

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

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

Как просматривать и анализировать файлы журналов доступа и ошибок Apache

Apache — технология, на которой работает Интернет. Я не уверен, что это правильно, но я думаю, что без него мы бы не увидели всемирную паутину в ее нынешнем виде. Запущен в 1995, а с апреля 1996 года он является самым популярным веб-сервером в мире.

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

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

Что такое журналы Apache?

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

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

Что такое журнал доступа Apache?

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

Расположение журналов доступа Apache

Расположение журнала доступа к серверу Apache зависит от используемой операционной системы.

• В Red Hat, CentOS или Fedora Linux журналы доступа можно найти в /var/log/httpd/access_log по умолчанию.
• В Debian и Ubuntu, вы можете найти журналы Apache в /var/log/apache2/access.log и
• FreeBSD будут хранить журналы доступа к серверу Apache в0043 /var/log/httpd-access.log файл.

Вы можете настроить его расположение с помощью директивы CustomLog, например:

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

Конфигурация формата журнала доступа Apache

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

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

Директивы форматирования журнала используются в сочетании с параметром LogFormat :

 LogFormat "%t %h %m \"%r\"" пользовательский 
3 строка выше сообщает, что следует использовать формат «%t %h %m \»%r\»» и назначить псевдоним с именем  custom  . После этого мы можем использовать пользовательский псевдоним   при определении ведения журнала Apache. Например: 
 
 CustomLog "logs/my_custom_log" пользовательский 
 Приведенный выше раздел указывает Apache записывать журналы в файл  logs/my_custom_log  в формате, определяемом пользовательским псевдонимом  . Приведенная выше конфигурация приведет к регистрации:
 время запроса благодаря директиве  %t ,
 имя удаленного хоста благодаря директиве  %h ,
 метод HTTP благодаря директиве  %m ,
 первая строка запроса в двойных кавычках благодаря  %r  директива.
 Конечно, можно использовать намного больше директив, и полный список можно найти в документации mod_log_config сервера Apache.
 Общий формат журнала 
 Общий формат журнала  Apache  — один из двух наиболее распространенных форматов журнала, используемых HTTP-серверами. Вы можете ожидать, что его определение будет выглядеть примерно так:
 LogFormat "%h %l %u %t \"%r\" %>s %b" common 
 Вот как выглядит журнал доступа из этого файл журнала выглядит так:
 10.1.2.3 - rehg [10/ноября/2021:19:22:12 -0000] "GET /sematext.png HTTP/1.1" 200 3423 
 Как видите, присутствуют следующие элементы:
  %h  , преобразованный в  10.1.2.3  — IP-адрес удаленного хоста, отправившего запрос.
  %l  , имя удаленного журнала, предоставленное  identd  , в нашем случае указан дефис, который является значением, которое мы можем ожидать для регистрации в случае, когда информация, предоставленная директивой ведения журнала, не найдена или недоступен.
  %u  , преобразованный в  rehg  , идентификатор пользователя, определяемый HTTP-аутентификацией.
  %t  , дата и время запроса с часовым поясом, в приведенном выше случае это  [10/Nov/2021:19:22:12 -0000] 
 \”%r\” , первая строка запроса в двойных кавычках, в приведенном выше случае это:  «GET /sematext.png HTTP/1.1» 
  %>s  , код состояния, сообщаемый клиенту. Эта информация имеет решающее значение, поскольку она определяет, был ли запрос успешным или нет.
  %b  , размер объекта, отправляемого клиенту, в нашем случае объектом был файл  sematext.png  и его размер был  3423  байт.
 Формат комбинированного журнала 
 Формат комбинированного журнала Apache   — еще один формат, часто используемый с журналами доступа. Он очень похож на  Common Log Format , но включает два дополнительных заголовка — реферер и пользовательский агент. Его определение выглядит следующим образом:
 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" комбинированный 
 И пример строки журнала, созданной приведенной выше строкой журнала, выглядит следующим образом:
 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, например Gecko) Chrome/79.0.3945.74 Safari/537.36 Edg/79.0. 309.43" 
 Пользовательский формат журнала 
 Есть еще одна вещь, которую мы должны обсудить, когда дело доходит до конфигурации ведения журнала Apache Server —  Директива CustomLog . Мы уже видели эту директиву конфигурации, но давайте обсудим ее более подробно.
 Журналы множественного доступа 
 Можно одновременно иметь несколько журналов доступа Apache без каких-либо дополнительных усилий. Нам может понадобиться ограниченный набор информации, доступной в некоторых файлах для быстрого сканирования, и полный журнал с использованием комбинированного формата журнала  , если нам нужна полная информация. Например, у нас может быть три файла журнала доступа — один, который включает время, пользовательский агент и код состояния, второй, который включает время, IP-адрес и используемый реферер, а третий —  Общий формат журнала  .
 Для этого нам нужно включить несколько разделов  CustomLog  в наш файл конфигурации:
 LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/agent_log "%t %{User-agent}i %>s"
Журналы CustomLog/referer_log "%t %h %{Referer}i"
CustomLog logs/access_log common 
 Как видите, на этот раз мы не использовали три отдельных параметра конфигурации  LogFormat , но указали формат журнала apache в  Строка формата CustomLog . Это также возможно и очень удобно, когда форматирование строк лога используется только в данном файле.
 Условные журналы 
 Бывают случаи, когда вы хотите записывать журналы только при выполнении определенного условия. Это то, что Apache Server называет условной регистрацией. Это делается с помощью директивы CustomLog и переменных среды. Например, если вы хотите регистрировать все запросы на доступ к вашим файлам PNG в отдельном файле, вы можете сделать это следующим образом:
 SetEnvIf Request_URI \.png$ png-изображение-журнал
CustomLog "png-access.log" common env=png-image-log 
 Ротация журналов и журналы, передаваемые по каналам 
 В зависимости от конфигурации ведения журнала и трафика, который обрабатывают ваши серверы Apache, ведение журнала может быть обширным. Все журналы, которые вы храните на компьютере, занимают место, и если вы не используете решение для централизации журналов, такое как Sematext Logs, вам придется иметь дело с пространством и управлением журналами.
 Давайте поговорим о  ротации журналов  первый.  Ротация журнала  — это процесс создания нового файла журнала, в который HTTP-сервер Apache начнет запись, и переименования старого файла журнала, чтобы он больше не обновлялся. Ротация журнала происходит, когда вы  корректно перезапускаете сервер  . Это означает, что без какого-либо прерывания обработки клиентских запросов создается новый файл журнала. Однако в производственных средах вы хотели бы перезапустить серверы Apache.
 Вот почему сервер Apache поддерживает  трубы бревна  . Вместо того, чтобы записывать события журнала в файл, вы используете передаваемые журналы для отправки событий журнала в другое приложение, которое будет обрабатывать журнал — например, в  rotatelogs  :
 CustomLog "|/usr/local/apache/ bin/rotatelogs /var/log/access.log 86400" common 
 Приложение  rotatelogs  поставляется с сервером Apache и способно чередовать журналы без необходимости перезапуска сервера. Приведенный выше пример приведет к вращению  /var/log/access.log  каждые 24 часа.
 Как читать журналы доступа Apache 
 Журналы доступа к серверу Apache представляют собой простые текстовые файлы. Их можно легко открыть любым инструментом, который может читать такие файлы. В системах на базе Linux это может быть инструмент командной строки cat или  tail , если вы хотите отслеживать строки журнала по мере их появления.
 Но есть две оговорки. Во-первых, это политики доступа. У вас может не быть доступа к машинам, на которых запущен HTTP-сервер Apache, и даже если вы это сделаете, у вас может не быть доступа для чтения к соответствующим каталогам журналов. Второе — это дистрибуция. Нередко несколько серверов Apache распределены по нескольким центрам обработки данных. В таком случае намного проще использовать специальный инструмент наблюдения, такой как Sematext Logs, который предоставит не только возможность просмотра необработанных файлов, но и агрегированную информацию в ключевых метриках, полученных для них.
 Понимание журналов доступа Apache 
 Наши файлы журналов доступа Apache легко читать и несложно понять. Просто помните о шаблонах, которые вы использовали в своей конфигурации. Мы уже рассмотрели общие шаблоны, с которыми вы можете столкнуться в файлах журнала Apache. Имейте в виду, что понимание файлов журналов становится еще проще с инструментами анализа журналов, которые выполняют синтаксический анализ за вас и дают вам агрегированное представление данных, которое легче понять.
 Что такое журнал ошибок Apache? 
 До сих пор мы говорили о журнале доступа Apache, который дает нам информацию о доступных ресурсах. Но это не единственное, что нас должно интересовать. Мы также должны заботиться обо всем, что связано с ошибками. Фактически, журнал ошибок является наиболее важным файлом журнала для HTTP-сервера Apache.
 Журнал ошибок Apache содержит все ошибки, произошедшие во время обработки запросов. Самое главное, однако, то, что журнал ошибок будет содержать информацию о том, что пошло не так во время запуска сервера Apache, и весьма вероятно, что он также будет содержать подсказки о том, как исправить проблему.
 Расположение журналов ошибок Apache 
 Место хранения журнала ошибок Apache зависит от операционной системы, в которой он работает.
 В  Red Hat, CentOS или Fedora Linux,  журналы доступа можно найти в  /var/log/httpd/error_log  по умолчанию.
 В  Debian и Ubuntu,  вы можете найти журналы Apache в  /var/log/apache2/error.log 
  FreeBSD  будет иметь журналы доступа к серверу Apache в  /var/log/httpd-error.log  файл.
 Вы можете настроить его расположение с помощью директивы ErrorLog, например:
 ErrorLog "/var/log/httpd-error.log" 
 Конфигурация формата журнала ошибок Apache 
 Подобно журналу доступа Apache, вы можете настроить формат журнала ошибок. Формат журнала ошибок Apache настраивается с помощью элемента  ErrorLogFormat , например:
 ErrorLogFormat «[%{u}t] [%-m:%l] [pid %P:tid %T] [client\ % а] %М”
 Приведенная выше конфигурация создаст запись в журнале ошибок Apache, подобную следующей:
 [Среда, 10 ноября 10:21:23. 811033 2021] [core:error] [pid 22308:tid 3212342123] [client 10.1.2.3] File не существует: /usr/local/apache2/htdocs/favicon.ico 
 В приведенном выше примере использовались следующие параметры форматирования:
  %{u}t  – текущее время, включая микросекунды,
  % -m  – модуль, который выдал ошибку,
  %l  – уровень события лога,
  %P  – идентификатор процесса,
  %T  – идентификатор потока,
  %M  – собственно сообщение лога.
 Полное описание доступных параметров форматирования доступно в официальной документации Apache Server.
 Уровни журнала 
 В дополнение к тому, что мы обсуждали до сих пор, стоит упомянуть еще одну вещь — уровень событий журнала. 9Директива 0372 LogLevel  позволяет указать уровень сообщений журнала для каждого модуля. Например, если мы хотим, чтобы основной уровень журнала для всех событий был установлен на уровне  info , но чтобы уровень  error  был только для модуля перезаписи, мы могли бы иметь следующую директиву конфигурации:
 LogLevel info rewrite :error 
 В документации сервера Apache описаны следующие уровни ведения журнала:
 emerg
 alert
 Crit
 Ошибка
 Warn
 Обратите внимание
 Info
 Debug
 Trace1 - Trace8
  Emerge  Один из них - это событие, которое говорит, что система нестабильна, а  Trace . очень низкоуровневое ведение журнала информации, которое вы, вероятно, можете пропустить.
 Как просмотреть журналы ошибок Apache 
 Просмотреть журналы ошибок сервера Apache так же просто, как открыть текстовый файл. Журналы ошибок ничем не отличаются от журналов доступа, поэтому они представляют собой простые текстовые файлы. Вы можете использовать любые инструменты, которые хотите изучить их. Но имейте в виду, что просмотр журналов с нескольких серверов Apache, распределенных по нескольким центрам обработки данных, может быть сложной задачей. Вот почему мы настоятельно рекомендуем использовать для этой работы инструменты агрегации журналов, такие как Sematext Logs.
 Управление файлами журналов Apache и их анализ с помощью Sematext 
  Облачные журналы Sematext — обзор Apache 
 Понимание и анализ журналов серверов Apache никогда не было проще, чем с журналами Sematext. Единственное, что вам нужно сделать, это создать учетную запись в Sematext, создать приложение Apache Logs и установить агент Sematext. Вы получите инструкции по настройке автоматического обнаружения журналов для ваших журналов. Ваши журналы будут проанализированы и отправлены в журналы Sematext, что даст вам доступ к множеству предварительно созданных отчетов, адаптированных для вашего HTTP-сервера Apache.
  Журналы Sematext — информация Apache HTTP 
 Журналы Sematext являются частью комплексного решения для мониторинга Sematext Cloud, предоставляющего вам все необходимое, когда речь идет о наблюдаемости. С Sematext Cloud вы получаете обзор ваших серверов Apache, отчет об ошибках, отчет HTTP, включая основные методы и пути HTTP с визуализацией среднего размера ответа и таблицей запросов. Вы можете увидеть своих пользователей с лучшими пользовательскими агентами, используемыми для доступа к ресурсам, обслуживаемым вашими серверами Apache, и, наконец, источники данных. Все в рамках единого мониторинга Apache Logs в Sematext Cloud.
 Все еще не знаете, какую поисковую систему с открытым исходным кодом использовать? Посмотрите это краткое видео, в котором сравниваются Apache Solr и Elasticsearch ниже:
 
 Заключение 
 Анализ журналов серверов Apache бесценен для понимания трафика, поступающего в ваше приложение, возникающих ошибок и производительности элементов, с которыми сталкивается пользователь. Инструмент управления журналами, такой как Sematext Logs, сделает эту работу за вас.
 Больше, чем понимание журналов сервера, знание того, к каким ресурсам осуществлялся доступ, кто к ним обращался и сколько времени потребовалось для обработки запроса, имеет решающее значение для понимания поведения вашего пользователя. Вы также должны быть уверены, что знаете о каждой возникающей ошибке, чтобы иметь возможность отреагировать как можно скорее. В сочетании с потребностью в распределенных инфраструктурах для обработки большого количества одновременных пользователей и обеспечения высокой доступности использование инструмента наблюдения является необходимостью.
 Иметь метрики и журналы Apache в одном месте, иметь возможность делить их на кусочки, получать оповещения о возникновении проблем и иметь представление о каждой части вашей среды — это уже не хорошо, а необходимо.
No related posts.