Логи (лог-файли) – це файли, що містять системну інформацію роботи сервера або комп’ютера, до яких заносяться певні дії користувача або програми. Іноді також використовується російськомовний аналог поняття – журнал. Їхнє призначення — протоколювання операцій, що виконуються на машині, для подальшого аналізу адміністратором. Регулярний перегляд журналів дозволить визначити помилки в роботі системи в цілому, конкретного сервісу або сайту (особливо приховані помилки, які не виводяться під час перегляду в браузері), діагностувати зловмисну активність, зібрати статистику відвідувань сайту. Загалом лог – це безцінна інформація, якою може скористатися будь-який користувач комп’ютера, щоб дізнатися, що і в який момент часу відбувалося на сайті, в системі або в самій машині.
Для цього потрібно продивитись журнал помилок. Журнали помилок корисні у багатьох відношеннях. У разі серверів та офісних мереж журнали помилок відстежують проблеми, з якими стикаються користувачі, та допомагають в аналізі основних причин цих проблем. Мережевий або системний адміністратор може швидше та легше усувати помилки за допомогою інформації, доступної з журналів помилок. Для веб-майстрів аналіз журналу помилок надає інформацію про проблеми, з якими стикаються користувачі, і може активно вирішувати проблеми, не повідомляючи про них нікому. Журнали помилок також можуть дати уявлення про спроби злому, оскільки більшість спроб злому на системах і серверах призводять до помилок або мають високу ймовірність потрапляння до журналів помилок, оскільки хакери намагаються скомпрометувати систему. Тому знаючи цю інформацію та використовуючи її на практиці, Ви зможете відстежити всі проблеми та вчасно їх усунути.
Журнал помилок сервера, ім’я та місцезнаходження якого задається директивою ErrorLog, є найважливішим файлом журналу. Це місце, куди Apache httpd надсилатиме діагностичну інформацію та записуватиме будь-які помилки, з якими він стикається при обробці запитів. Це перше місце, де потрібно подивитися, коли виникає проблема із запуском сервера або роботою сервера, оскільки він часто містить подробиці, що пішло не так і як це виправити. Журнал помилок зазвичай записується у файл (зазвичай error_log у системах Unix та error.log у Windows та OS/2). У системах Unix також можливо, щоб сервер надсилав помилки до системного журналу або передавав їх програмі. Формат журналу помилок визначається директивою ErrorLogFormat, за допомогою якої можна налаштувати, які значення записуються в журнал. Якщо ви його не вказали, використовується значення за замовчуванням. Типове повідомлення журналу таке:
Перший елемент у записі журналу – це дата та час повідомлення. Наступним є модуль, який створює повідомлення (у разі authz_core) і рівень серйозності цього повідомлення. За цим слідує ідентифікатор процесу і, якщо необхідно, ідентифікатор потоку процесу, в якому виникла умова. Далі ми маємо адресу клієнта, який зробив запит (його IP адреса і номер порту, з якого відкрито з’єднання). І, нарешті, докладне повідомлення про помилку, яке сервер відхилив підключення.
Якщо помістити токен %L до журналу помилок та журналу доступу, буде створено ідентифікатор запису журналу, з яким можна зіставити запис у журналі помилок із записом у журналі доступу. Якщо завантажено mod_unique_id, його унікальний ідентифікатор запиту також використовуватиметься як ідентифікатор запису журналу. Під час тестування часто корисно постійно відстежувати журнал помилок на наявність проблем.
У системах Unix ви можете це зробити, використовуючи команду виду:
Наприклад:
Синтаксис:
Значення за замовчюванням:
Контекст: server config, віртуальні хости. Директива ErrorLog встановлює ім’я файлу, в якому сервер вестиме журнал будь-яких помилок, з якими він стикається.
Використання syslog замість імені файлу дозволяє реєструватися через syslogd(8), якщо система підтримує його і завантажений mod_syslog. За замовчуванням використовується засіб syslog local7, але ви можете перевизначити це, використовуючи синтаксис syslog:засіб, де засіб може бути одним з імен, зазвичай, задокументованих в syslog(1). Засіб фактично є глобальним, і якщо він змінюється на окремих віртуальних хостах, цей останній засіб впливає на весь сервер. Ті ж правила застосовуються до тега syslog, який за умовчанням використовує двійкове ім’я Apache, в більшості випадків httpd. Ви також можете перевизначити це за допомогою синтаксису syslog::tag.
Додаткові модулі можуть надавати власні постачальники ErrorLog. Синтаксис нагадує приклад системного журналу вище.
Примітка: при введенні шляху до файлу на платформах, відмінних від Unix, необхідно стежити за тим, щоб використовувалися лише прямі косі риси, навіть якщо платформа може дозволяти використання зворотних косих рис. Загалом, рекомендується завжди використовувати пряму косу межу у файлах конфігурації.
Синтаксис:
Контекст: server config, віртуальні хости. ErrorLogFormat дозволяє вказати, яка додаткова інформація записується до журналу помилок на додаток до фактичного повідомлення журналу.
Вказування з’єднання або запиту як перший параметр дозволяє вказати додаткові формати, в результаті чого реєструється додаткова інформація, коли перше повідомлення реєструється для певного з’єднання або запиту відповідно. Ця додаткова інформація реєструється лише один раз за з’єднання/запит. Якщо з’єднання або запит обробляються без повідомлення журналу, додаткова інформація також не реєструється.
Можливо, деякі елементи рядка формату не роблять висновок. Наприклад, заголовок Referer присутня лише в тому випадку, якщо повідомлення журналу пов’язане із запитом, а повідомлення журналу з’являється в той момент, коли заголовок Referer вже було зчитано з клієнта. Якщо вихідні дані не створюються, стандартна поведінка полягає у видаленні всього, починаючи з попереднього пробілу до наступного пробілу. Це означає, що рядок журналу неявно поділено на поля в переходах між небілими пробілами та білими пробілами. Якщо елемент рядка формату не робить виводу, все поле опускається. Наприклад, якщо віддалена адреса %a у форматі журналу [%t] [%l] [%a] %M недоступна, навколишні дужки також не реєструються. Символи пробілу можна екранувати за допомогою зворотної косої межі, щоб вони не могли обмежити поле. Комбінація ‘%’ (відсоток і пробіл) – це роздільник поля нульової ширини, який не робить жодного висновку. Вказану поведінку можна змінити, додавши модифікатори до елемента рядка формату. Модифікатор – (мінус) призводить до запису мінуса, якщо відповідний елемент не робить жодного висновку. У форматах один-на-з’єднання/запит також можна використовувати модифікатор + (плюс). Якщо елемент з модифікатором плюс не робить жодного висновку, весь рядок опускається. Число модифікатора може використовуватися для призначення рівня серйозності журналу елементу формату. Елемент буде зареєстрований лише в тому випадку, якщо серйозність повідомлення журналу не вища за вказаний рівень серйозності журналу.
Число може змінюватись від 1 (alert) до 4 (warn) і 7 (debug) до 15 (trace8). Наприклад, ось що станеться, якщо ви додасте модифікатори в токен %{Referer}i, який реєструє заголовок запиту Referer (Скріншот 1). Деякі елементи формату строки приймають додаткові параметри у фігурних скобках (Скріншот 2 та Скріншот 3).
Формат ідентифікатора журналу %L створює унікальний ідентифікатор для з’єднання або запиту. Це можна використовувати для складання того, які строки журналу належать тому ж з’єднанню або запиту, який запит відбувається з яким з’єднанням. Строка формату %L також доступна в mod_log_config, щоб дозволити співвідносити записи доступу до журналу зі строками помилок журналу. Якщо завантажено mod_unique_id, його унікальний ідентифікатор буде відповідати якості ідентифікатора журналу для запитів.
Це може привести до повідомлень про помилки, таких як:
Зверніть увагу, що, як обговорювалося вище, деякі поля повністю випущені, оскільки вони не визначені:
Синтаксис:
Значення за замовчуванням:
Контекст: server config, віртуальні хости, директорії Сумісність: Налаштування на рівні модулів та на рівні директорій доступні в Apache HTTP Server 2.3.6 та пізніших. LogLevel регулює подробиці повідомлень, які записуються в журналах помилок (див. директиву ErrorLog). Доступні такі рівні в порядку зменшення значущості (Скріншот 4 та Скріншот 5).
Якщо вказано певний рівень, повідомлення з усіх інших рівнів вищої значущості також повідомлятимуться. Наприклад, якщо вказано LogLevel info, то також будуть публікуватися повідомлення з рівнями notice та warn. Зверніть увагу, що повідомлення про помилки 404 (файл не знайдено), які генерує сам веб-сервер (core) (Скріншот 6), мають статус info:
Це означає, що за замовчуванням (LogLevel встановлено на warn) запити, що завершилися статусом 404, не будуть потрапляти в журнали помилок!
Щоб це виправити, потрібно встановити рівень на info:
Зверніть увагу, що якщо не знайдено файл, який обробляється іншим модулем, цей модуль може встановити свій власний рівень. Наприклад, модуль php7, якщо не знайдено PHP скрипт, встановить для такого повідомлення рівень серйозності error і такий запис потрапить до журналу помилок навіть при налаштуваннях за замовчуванням:
Наприклад:
Примітка: під час запису у звичайний файл повідомлення з повідомленням з рівнем notice не можуть бути пригнічені і, отже, завжди реєструються. Однак це не стосується випадків, коли реєстрація ведеться з використанням syslog. Вказівка без імені модуля призведе до скидання рівня для всіх модулів до цього рівня. Вказівка рівня з ім’ям модуля встановить рівень лише цього модуля. Можна використовувати ім’я вихідного файлу модуля, ідентифікатор модуля або ідентифікатор модуля з кінцевим _module, опущеним як специфікація модуля.
Це означає, що такі три специфікації еквівалентні:
Також можна змінити рівень для кожного каталогу:
Конфігурація на рівні каталогу для кожного каталогу впливає лише на повідомлення, які реєструються після аналізу запиту та пов’язані з ним. Повідомлення журналу, пов’язані з сервером або з’єднанням, не торкаються. Однак на останні може вплинути директива LogLevelOverride.
Синтаксис:
Контекст: server config, віртуальні хости. Сумісність: Доступна в Apache HTTP Server 2.5.0 та пізніших. LogLevelOverride налаштовує LogLevel для запитів, що надходять із певних клієнтських IP-адрес. Це дозволяє увімкнути докладне ведення журналу лише для певних тестових клієнтів. IP-адреса перевіряється в дуже ранньому стані при обробці з’єднання. Отже, LogLevelOverride дозволяє змінити рівень журналу для таких речей, як рукостискання SSL, які відбуваються до оцінки директиви LogLevel у контейнері <If>. LogLevelOverride приймає або одну IP-адресу, або специфікацію IP-адрес CIDR/довжина_підмережі. Для запитів, які відповідають директиві LogLevelOverride, специфікації LogLevel для кожного каталогу ігноруються.
Приклади:
LogLevelOverride впливає лише на повідомлення журналу, пов’язані із запитом або з’єднанням. Повідомлення журналу, пов’язані з сервером, не торкаються.
Директива LogLevel дозволяє вказувати пороговий рівень важливості потрапляння запису до журналу для шкірного модуля. Таким чином, якщо ви вирішуєте проблему тільки з одним конкретним модулем, ви можете збільшити обсяг його інформації в журналі, не одержуючи на додаток інформацію про інші модулі, які вас не цікавлять. Це особливо корисно для таких модулів, як mod_proxy або mod_rewrite, де ви хочете дізнатися подробиці про те, що вони намагаються зробити, і що в них відбувається.
Зробіть це, вказавши ім’я модуля у вашій директиві LogLevel:
Це встановлює для основного LogLevel значення info, але mod_rewrite зробить значення trace5. Це замінює директиви ведення журналів для кожного модуля, такі як RewriteLog, які були присутні в попередніх версіях сервера. Зверніть увагу, що інформація, яку генерують модулі, завжди потрапляє в балку помилок, навіть якщо не є по суті помилкою! Також зверніть увагу, що деякі модулі не показуватимуть жодної інформації, якщо не встановити рівень трасування в діапазоні від trace1 до trace8.
