Логи хостингу: мова, якою ваш сервер кричить про проблеми, а ви не слухаєте

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

Що таке лог-файли і чому вони важливіші за будь-який плагін моніторингу

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

Головне, що потрібно зрозуміти новачку: логи - це не інструмент для «просунутих адмінів». Це ваша перша лінія діагностики, доступна навіть на найдешевшому shared-хостингу. Плагіни моніторингу показують симптоми. Логи показують причину.

На більшості хостингів логи лежать у передбачуваних місцях:

• access.log (або access_log) - записує кожен HTTP-запит до вашого сайту
• error.log (або error_log) - фіксує помилки PHP, проблеми з правами доступу, збої модулів
• mail.log - логує відправку електронної пошти з сервера
• MySQL slow query log - записує запити до бази даних, які виконувались занадто довго

У cPanel шукайте розділ «Metrics» або «Logs». У панелях типу DirectAdmin чи Hestia - аналогічні секції. Якщо у вас VPS без панелі, стандартний шлях для Apache - /var/log/apache2/ або /var/log/httpd/, для Nginx - /var/log/nginx/.

Анатомія одного рядка: як прочитати те, що виглядає як тарабарщина

Відкриваєте access.log вперше - і бачите щось на кшталт:

192.168.1.1 - - [15/Jun/2025:14:32:01 +0300] "GET /catalog/page-3 HTTP/1.1" 200 34521 "https://google.com" "Mozilla/5.0..."

Виглядає як шифр? Насправді це простіше за квитанцію з супермаркету. Розберімо по шматках:

Бачите? Жодної магії. Кожен рядок - це відповідь на п'ять запитань: хто, коли, що запитав, що отримав, звідки прийшов. Навіть якщо ви не програміст, ви вже можете знайти 404-і помилки, підозрілі IP або сторінки, яких не повинно існувати.

Error.log - файл, який рятує вам нерви о третій ночі

Якщо access.log - це щоденник відвідувань, то error.log - це журнал скарг. Тут сервер фіксує все, що пішло не за планом. І саме сюди потрібно дивитись першим ділом, коли сайт поводиться дивно.

«Більшість інцидентів на продакшн-серверах можна було запобігти, якби адміністратор переглянув error.log за останні 24 години. Помилки рідко з'являються раптово - вони наростають поступово, залишаючи чіткий слід у логах» - Tom Limoncelli, автор «The Practice of System and Network Administration»

Типовий рядок error.log виглядає так:

[Sun Jun 15 14:35:02.123456 2025] [php:error] [pid 12345] [client 192.168.1.1] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted in /home/user/public_html/wp-includes/class-wpdb.php on line 2056

Що ми бачимо? PHP вичерпав ліміт пам'яті (128 МБ) під час роботи з базою даних WordPress. Це не «якась помилка». Це конкретний діагноз з точним файлом і рядком коду. З таким описом навіть на форумі вам дадуть відповідь за п'ять хвилин замість п'яти днів.

Найчастіші помилки, які ви знайдете в error.log:

1. PHP Fatal error: Allowed memory size exhausted - скрипт з'їв більше пам'яті, ніж дозволено. Рішення: збільшити memory_limit або оптимізувати код.
2. Permission denied - неправильні права на файли. Зазвичай потрібно 644 для файлів і 755 для директорій.
3. File does not exist - хтось або щось запитує файл, якого немає. Часто - наслідок невдалого оновлення теми чи плагіна.
4. Connection timed out - сервер не зміг зв'язатись із зовнішнім сервісом (API, поштовий сервер). Перевіряйте мережу та DNS.
5. Too many open files - вичерпано системний ліміт відкритих файлів. Серйозний сигнал, що навантаження перевищує можливості вашого тарифу.

Практичні команди: від «я боюся терміналу» до «я знайшов проблему за 30 секунд»

Ви не зобов'язані читати логи рядок за рядком. Це як шукати голку в стозі сіна - вручну. Натомість використовуйте кілька базових команд, які працюють через SSH.

Побачити останні 50 рядків error.log:
tail -n 50 /var/log/apache2/error.log

Відстежувати нові помилки в реальному часі (лог оновлюється на екрані, як чат):
tail -f /var/log/apache2/error.log

Знайти всі рядки з 404-ю помилкою:
grep " 404 " /var/log/apache2/access.log

Порахувати, скільки разів конкретний IP стукався на сервер:
grep -c "185.220.101.42" /var/log/apache2/access.log

Топ-10 IP-адрес за кількістю запитів (ідеально для виявлення ботів):
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -10

Не маєте SSH-доступу? Не проблема. У cPanel є вбудований «Raw Access Logs» і «Errors» у розділі метрик. Завантажте файл, відкрийте у будь-якому текстовому редакторі (Notepad++, Sublime Text), використовуйте Ctrl+F для пошуку. Примітивно? Так. Ефективно? Абсолютно.

Повільні запити до бази даних: вбивця, якого ніхто не шукає

Є один лог, про який забувають навіть досвідчені веб-майстри - MySQL slow query log. За замовчуванням він часто вимкнений. І це трагедія, бо саме повільні запити до бази даних - причина номер один «необхідного гальмування» сайтів на CMS.

Увімкнути його можна через my.cnf (якщо маєте доступ до конфігурації MySQL):

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

Параметр long_query_time = 2 означає: записувати кожен запит, який виконувався довше 2 секунд. На shared-хостингу попросіть підтримку активувати цей лог для вашого акаунта - більшість провайдерів погоджуються.

Чому це критично: один неоптимізований SQL-запит, який виконується 5 секунд, при 100 одночасних відвідувачах перетворюється на 500 секунд навантаження на процесор. Ваш сайт не «повільний». Він задихається під вагою однієї поганої SQL-конструкції.

Ротація логів: чому ваш диск заповнений, хоча ви нічого не завантажували

Ось сценарій, який я спостерігав десятки разів. Новачок запускає сайт, все працює місяць-два, потім раптом отримує помилку «Disk quota exceeded». Перевіряє - файли сайту важать 500 МБ з доступних 5 ГБ. Де решта? У логах.

Access.log популярного сайту з 10 000 відвідувачів на день генерує приблизно 50-100 МБ на місяць. Error.log при активних помилках PHP - ще більше. За рік без ротації це легко перетворюється на кілька гігабайтів.

На якісних хостингах logrotate налаштований автоматично - старі логи стискаються і видаляються через визначений період. Але на дешевих тарифах або самостійно налаштованих VPS це ваша відповідальність. Перевірте конфігурацію:

cat /etc/logrotate.d/apache2

Якщо файл порожній або відсутній - настав час діяти, поки диск не переповнився посеред ночі.

Від читання логів до передбачення проблем

Справжня цінність логів розкривається не коли ви шукаєте причину вже існуючої поломки. Вона розкривається, коли ви починаєте читати логи до того, як щось зламається. Щотижневий перегляд error.log за 10 хвилин виявляє закономірності, які жоден плагін вам не покаже.

Зростає кількість 503-іх помилок щовівторка о 10 ранку? Можливо, саме тоді запускається ваш email-розсилка і cron-завдання одночасно. IP-адреса з Південно-Східної Азії робить 5000 запитів за годину? Це бот, і його час банити. PHP warning повторюється 200 разів на день, хоча «нічого не зламано»? Через тиждень цей warning стане fatal error.

Логи - це єдине місце, де сервер говорить правду. Не маркетингові обіцянки хостинг-провайдера. Не суб'єктивне «щось повільно». Факти. Дати. Числа. І якщо ви досі жодного разу не заглянули у свій error.log - яку ще діагностику ви ігноруєте?