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

Уявіть: ваш сайт лежить вже 20 хвилин. Клієнти пишуть в підтримку, менеджер дзвонить у паніці, а ви дивитесь на екран і не розумієте, що сталося. Знайома ситуація? А тепер уявіть іншу картину - ви відкриваєте один файл, бачите рядок з помилкою, виправляєте за три хвилини і повертаєтесь до кави. Різниця між цими двома сценаріями - вміння читати серверні логи. Це навичка, яка перетворює безпорадне «щось зламалось» на чітке «ось що зламалось і ось як це лагодити». І сьогодні ми розберемо цю навичку по кісточках.

Що таке логи і чому більшість власників сайтів ніколи їх не відкривали

Серверний лог - це щоденник вашого хостингу. Кожен візит, кожна помилка, кожен запит до бази даних - все записується у текстові файли, які мирно лежать десь у директорії /var/log/ і чекають, поки хтось нарешті зверне на них увагу. За моїм досвідом, близько 70% власників сайтів жодного разу не заглядали в логи свого сервера. Вони або не знають про їх існування, або вважають, що це «для програмістів».

А тим часом логи - це найчесніший джерело інформації. Google Analytics може брехати через блокувальники реклами. Моніторинг uptime може пропустити мікропадіння. Але лог не бреше. Він фіксує все як камера спостереження в супермаркеті - байдуже, безпристрасно, по мілісекундах.

Типи логів: хто що записує і де це шукати

На типовому хостингу з Apache або Nginx вас чекають кілька ключових файлів. Плутати їх - як плутати симптоми застуди з алергією: результат лікування буде відповідний.

На shared-хостингу доступ буває обмеженим. Зазвичай ви бачите тільки error log та access log свого акаунта через cPanel або DirectAdmin. На VPS - повна свобода. Саме тому я завжди рекомендую тримати хоча б мінімальний VPS для серйозних проєктів: це як різниця між орендою кімнати і власною квартирою.

Анатомія рядка логу: розбираємо як детективи

Давайте візьмемо типовий рядок з access log Nginx:

185.220.101.45 - - [15/Jan/2025:03:22:11 +0000] "GET /wp-login.php HTTP/1.1" 200 4523 "-" "Mozilla/5.0"

Що тут бачимо?

1. 185.220.101.45 - IP-адреса відвідувача. Вже цікаво: хто це о третій ночі стукає в адмінку?
2. [15/Jan/2025:03:22:11] - точний час запиту. До секунди.
3. "GET /wp-login.php" - що саме просили. Сторінку входу в WordPress. О третій ночі. Неодноразово. Відчуваєте запах брутфорсу?
4. 200 - код відповіді. Сервер віддав сторінку успішно. Якщо тут 403 - доступ заблоковано, 500 - сервер зламався, 404 - сторінки немає.
5. 4523 - розмір відповіді в байтах.
6. User-Agent - хто представився. Браузер, бот, скрипт.

Один рядок логу - і ви вже знаєте: хтось намагається підібрати пароль до вашого сайту. Без логів ви б дізнались про це тільки коли на головній з'явився б банер з казино.

П'ять команд терміналу, які рятують години

Читати лог очима - справа невдячна, коли файл важить 500 МБ. Ось набір команд, які працюють на будь-якому Linux-сервері без встановлення додаткового софту:

• tail -f /var/log/apache2/error.log - дивитись помилки в реальному часі. Як стрічка новин, тільки корисна.
• grep "500" access.log | wc -l - порахувати, скільки разів сервер відповів 500-ю помилкою. Якщо число росте - біда.
• awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20 - топ-20 IP-адрес за кількістю запитів. Перша адреса робить 50 000 запитів за годину? Ласкаво просимо в бан.
• grep "wp-login" access.log | wc -l - скільки разів хтось намагався увійти в адмінку WordPress.
• zcat access.log.*.gz | grep "404" | awk '{print $7}' | sort | uniq -c | sort -rn | head - знайти найпопулярніші неіснуючі сторінки. Золото для SEO.

«Логи - це не просто текстові файли. Це розмова між вашим сервером та зовнішнім світом. Хто не слухає цю розмову - той працює наосліп.» - Brendan Gregg, автор книги «Systems Performance» та інженер Netflix

Ці команди працюють миттєво навіть на слабких серверах. Ніякий Grafana не замінить вміння швидко «проскочити» по логу руками, коли сайт горить прямо зараз.

Реальні кейси: як логи рятували ситуацію

Розкажу три історії з власної практики. Кожна - урок, який коштував комусь грошей або нервів.

Кейс 1: магазин, який «повільно помирав». Інтернет-магазин на Magento почав гальмувати. Щотижня все гірше. Хостинг-провайдер казав: «У вас все нормально». Я відкрив slow query log MySQL - і ось вона, красуня: один SQL-запит виконувався 47 секунд. Кожного разу, коли хтось відкривав каталог. Причина - відсутній індекс на таблиці з 800 000 товарів. Додали індекс за 10 секунд. Сайт полетів.

Кейс 2: «сайт зламали, але нічого не видно». Error log показав сотні записів типу PHP Warning: file_put_contents(/tmp/.cache_x7f3.php). Хтось через вразливість у плагіні залив бекдор і тихенько розсилав спам. Зовні сайт виглядав ідеально. Без логів цей «постоялець» жив би там місяцями.

Кейс 3: трафік є - конверсії немає. Access log показав, що 60% відвідувачів отримували код 301 і робили подвійний редирект з http на https, а потім з www на без www. Кожен редирект - плюс 200-400 мс. Мобільні користувачі просто закривали вкладку. Два рядки в .htaccess вирішили проблему, яку маркетолог шукав три місяці.

Автоматизація: нехай логи самі кричать про проблеми

Читати логи вручну щодня - нереально. Але можна налаштувати систему так, щоб вона сама сигналізувала про підозріле. Ось мінімальний набір для будь-якого VPS:

1. Fail2ban - аналізує auth.log і access.log в реальному часі. Бачить 10 невдалих спроб SSH за хвилину? Автоматичний бан IP на 24 години. Налаштовується за 15 хвилин.
2. Logwatch - щоденний звіт на пошту. Скільки помилок 500, скільки невдалих логінів, скільки місця на диску. Як ранкова газета для сисадміна.
3. GoAccess - перетворює access log на красивий HTML-дашборд. Трафік по країнах, найпопулярніші URL, коди відповідей - все в одному вікні.
4. Logrotate - не дозволяє логам з'їсти весь диск. Архівує старі файли, видаляє зовсім давні. Без нього я бачив сервери, де error.log важив 12 ГБ і займав весь доступний простір.

Правило номер один: лог, який ніхто не читає - марна витрата дискового простору. Лог, який читає автоматика - це система раннього попередження.

Для більш серйозних проєктів варто дивитись у бік ELK-стеку (Elasticsearch + Logstash + Kibana) або Loki + Grafana. Але це вже для команд, де кілька серверів і потік логів обчислюється гігабайтами на добу.

Помилки, через які логи стають марними

Навіть ті, хто знає про логи, часто роблять їх безкорисними:

• Рівень логування занадто низький. Якщо в php.ini стоїть error_reporting = 0, PHP мовчить навіть коли все горить. Для продакшену оптимально E_ALL & ~E_NOTICE & ~E_DEPRECATED.
• Логи ніколи не ротуються. Файл росте, поки не з'їсть диск. Потім падає MySQL, бо нікуди писати тимчасові таблиці. Класика.
• Часовий пояс не налаштований. Лог показує UTC, а ви шукаєте проблему за київським часом. Зміщення в 2-3 години - і ви дивитесь не на ті записи.
• Access log відключений «для економії». Так, він генерує навантаження. Але без нього ви сліпі при будь-якій DDoS-атаці або аномалії трафіку.

Знаєте, що найбільше дратує? Коли проблема сталася вчора, а логи зберігаються тільки за сьогодні. Налаштуйте ротацію з архівуванням мінімум на 30 днів. Дисковий простір коштує копійки. Втрачений клієнт - ні.

Ось вам просте запитання на завершення: коли ви востаннє відкривали error log свого сайту? Якщо відповідь «ніколи» або «не пам'ятаю» - зробіть це прямо зараз. Серйозно, відкрийте термінал або панель хостингу і подивіться. Можливо, там вже тижнями кричить помилка, про яку ви навіть не здогадуєтесь. А може, все чисто - і ви спокійно допʼєте каву. В будь-якому разі, ви вже знатимете. А знання - це єдине, що відрізняє системного адміністратора від людини, яка просто платить за хостинг.