Логування HTTP-запитів в Apache: Короткий посібник

Основи ведення журналів Apache

Записи в журналах Apache містять інформацію про відповіді Apache, запити від інших комп’ютерів та внутрішні дії сервера. У цьому посібнику ми розглянемо основи ведення журналів, а саме типи журналів, місця їх зберігання та навіть способи їх інтерпретації. Крім того, ми поділимося інформацією про налаштування модулів та встановлення власних форматів журналів.

Категорії журналів Apache

Журнали Apache поділяються на дві категорії: журнали помилок та журнали доступу.

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

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

Журнали помилок

Як очевидно, журнали помилок містять дані про помилки, що виникли під час обробки сервером конкретного запиту. Як і журнали доступу, вони також містять точний час надходження запиту та IP-адресу. Завдяки журналам помилок ви будете повідомлені про проблеми, що виникли. Наприклад, якщо файл відсутній,

Розташування файлів журналів

Згідно з налаштуваннями за замовчуванням, зберігання як журналів помилок, так і журналів доступу здійснюється окремо на сервері. Залежно від використовуваної ОС, розташування може дещо відрізнятися.

Налаштування журналів Apache

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

Використання директиви LogLevel

LogLevel необхідна для визначення мінімального рівня серйозності подій. Рівень серйозності визначає важливість конкретної події та може змінюватися. Наприклад, рівень серйозності може бути встановлений як Trace8 або Emerg. Рівень Emerg позначає події, що можуть призвести до певної нестабільності, а Trace8 — повідомлення трасування. Наприклад, LogLevel crit ігнорує всі рівні, крім Emerg, Alert та Crit.

Визначення власних форматів журналів

Директива LogFormats відповідає за форматування та структуру подій у журналах. За замовчуванням використовується формат CLF (Common Format), але ви також можете вказати власний форматний рядок.

Директива CustomLog також потрібна для зміни місця розташування файлів журналів. У більшості систем Linux журнали зазвичай записуються в каталоги var/log/httpd або var/log/apache2. Крім того, ви можете змінити рядок після імені файлу, щоб конкретні зміни застосовувалися лише до цього файлу.

Повний перелік полів можна переглянути в документації щодо журналів. Для моніторингу активності сервера та негайного вирішення проблем, що виникають, слід використовувати наступні 5 полів:

1. %T — вказує час, витрачений на обробку запиту. Це дуже корисне поле, оскільки дозволяє виміряти швидкість роботи сайту. Щоб отримати ті самі результати, але в мікросекундах, замість T слід використовувати D.
2. %>s — за допомогою цього параметра можна перевірити статус запиту після певного внутрішнього перенаправлення.
3. %a — показує IP-адресу, з якої було зроблено запит. Це означає, що ви зможете набагато легше ідентифікувати активність трафіку.
4. %{ID}e — ID означає ідентифікатор запиту, тобто кожен запит має свій унікальний ідентифікатор. Це можна використовувати для відстеження запитів між сервером веб-додатку та Apache.
5. %U — шлях URL, але без додаткових параметрів, наприклад, рядка запиту.

Присвоєння псевдонімів журналам

Присвоєння псевдонімів журналам є надзвичайно корисним, особливо у випадку, коли для кількох віртуальних хостів використовуються різні файли журналів. Присвоєне ім’я можна використовувати з директивою CustomLog, щоб журнали записувалися у вказаному форматі. Це означає, що ви можете задавати конкретні формати журналів для різних файлів журналів і при цьому не витрачати час на повторне визначення формату кожного разу.

Ведення журналів у форматі JSON

Зберігання журналів у звичайному текстовому форматі значно полегшує перевірку файлів у разі необхідності. Звісно, такий формат зручний для звичайного читання, але обробляти такі дані за допомогою інструментів управління логами буде складно, оскільки ці рішення мають власний формат. Звісно, більшість інструментів управління використовують стандартний формат Apache, але якщо це не так, варто розглянути JSON.

JSON — це абревіатура від JavaScript Object Notation, і це чудовий формат для зберігання структурованих даних. JSON є досить корисним, оскільки дозволяє зберігати майже будь-яку структуру чи тип даних. Крім того, цей формат чудово підходить для самодокументування інформації. Серед основних типів, що підтримуються цим форматом, можна виділити масиви, числа, рядки, нульове значення та логічні оператори.

Впровадження ротації логів

Проблеми, що можуть виникати з логами доступу або іншими логами, — це надмірне споживання місця або складнощі з управлінням. Завдяки впровадженню ротації логів можна вирішити ці проблеми.

Існує спеціальна програма rotatelogs, яка допомагає здійснювати ротацію логів залежно від їхнього розміру та часу. Стандартна команда logrotate також є хорошим варіантом, з якого можна почати. У більшості систем Linux Apache має файл конфігурації.

Файл конфігурації за замовчуванням у Debian 11 розташований у каталозі /etc/logrotate.d/apache2. Ви можете змінити цей файл, щоб налаштувати ротацію логів Apache. Роз’яснимо значення кожного розділу цього файлу конфігурації:

-        Missingok не виявляє жодних проблем у разі, якщо файл журналу вказано.

-        /var/log/apache2/*.log – означає, що конфігурація стосуватиметься всіх файлів, які закінчуються на .log у вказаному місці. Після { вказуються всі директиви для logrotate, а після цього використовується }.

-        Compress означає, що стиснення застосовується до файлів журналів, що підлягають ротації.

-        Якщо вказано «daily», це означає, що ротація відбувається щодня; також ви можете змінити це значення на «yearly», «weekly» або «monthly».

-        «Rotate 14-» означає, що зберігається 14 файлів журналу, а решта видаляються. У разі використання щоденної ротації у вас буде приблизно 2 тижні збережених журналів.

-        «Delaycompress» означає, що найновіші файли залишаються нестисненими, тоді як найстаріші будуть стиснуті.

-        Notifempty — означає, що всі порожні файли не підлягають ротації.

-        Sharedscripts — скрипти postrotate не працюватимуть, доки всі журнали не будуть обновлені.

-        Create 640 root adm — означає, що після ротації будуть створені файли з правами доступу 640.

Налаштування журналів за замовчуванням для віртуальних хостів

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

Ось приклад, де журнали записуються в окремий файл access.log:

<VirtualHost *:80>
 ​ServerName skills.com (приклад домену)
 ​ServerAdmin webmaster@skills.com
 ​DocumentRoot /var/www/skills.com
 ​LogLevel info ssl:warn
 ​ErrorLog /var/www/skills.com/logs/error.log
 ​CustomLog /var/www/skills.com/logs/access.log example
</VirtualHost>

Debian, Ubuntu та Linux Mint

У системах Debian файл конфігурації шифрування веб-сайтів за замовчуванням за допомогою SSL/TLS знаходиться у /etc/apache2/sites-available/default-ssl.conf, а конфігурація віртуального хосту для незашифрованих веб-сайтів — у /etc/apache2/sites-available/000-default.conf.

Таблиця директив за замовчуванням

Red Hat, Fedora та CentOS

У Red Hat та подібних системах файли конфігурації віртуальних хостів знаходяться в /etc/httpd/conf.d, а головний файл конфігурації — у /etc/httpd/conf/httpd.conf.

Таблиця директив за замовчуванням

OpenSUSE

У системі OpenSUSE конфігурація для веб-сайтів із SSL/TLS знаходиться у файлі /etc/apache2/default-vhost-ssl.conf, а для незашифрованих — у файлі /etc/apache2/default-vhost.conf.

Таблиця директив за замовчуванням

Модулі Apache для ведення журналів

Існує кілька модулів, які можуть суттєво допомогти у зміні поведінки ведення журналів. Спираючись на наші знання, отримані під час налаштування сервера Apache, ми поділимося важливою інформацією про корисні модулі Apache для ведення журналів.

mod_log_config

Це, мабуть, найпростіший модуль, про який ми вже згадували в цій статті.

mod_log_debug

Цей модуль може бути включений не в усі дистрибутиви Apache, але він корисний для реєстрації повідомлень налагодження. Наприклад, цей модуль можна використовувати для реєстрації повідомлень від певних клієнтів, реєстрації подій за певним URL-шляхом тощо.

Наприклад:

<Location /path/to/some/directory>
​LogMessage "Запит на /path/to/directory надійшов від"
​${REMOTE_ADDR}
</Location>

mod_log_forensic

За допомогою цього модуля можна вести журнал до та після обробки запиту. Після увімкнення цього модуля можна використовувати ключові слова для визначення, який файл журналу є криміналістичним. Також можна використовувати %{forensic-id} у різних рядках, щоб додавати криміналістичні дані до звичайних журналів.

Ось приклад:

<VirtualHost *:80>
​ServerName skills.com (це приклад домену)
   ServerAdmin webmaster@skills.com
   DocumentRoot /var/www/skills.com
   LogLevel info ssl:warn
   ErrorLog /var/www/skills.com/logs/error.log
   CustomLog /var/www/skills.com/logs/access.log example
   CustomLog /var/www/skills.com/logs/forensic.log forensic
</VirtualHost>

mod_logio

Цей модуль дає змогу реєструвати кількість байтів, отриманих/надісланих за кожен запит. Цей модуль також враховує зміни розміру, пов’язані з шифруванням TLS/SSL, і зазвичай включається відповідно до характеристик за замовчуванням.  

mod_filter

Цей модуль допомагає відбирати певні запити на основі заданого фільтра. Контекстний фільтр, який надає цей модуль, враховує конфігурацію віртуального хосту, конфігурацію Apache, файли .htaccess та інше.

Цей модуль зазвичай ввімкнено за замовчуванням, але, можливо, вам доведеться його ввімкнути.

mod_unique_id

Цей модуль необхідний для формування унікального ідентифікатора для кожного запиту. Ідентифікатор записується до журналу доступу. Він передається обробнику додатка за допомогою змінної середовища UNIQUE_ID. Таким чином, розробникам стає набагато простіше відстежувати запити.