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

Уявіть: ви - лікар, але пацієнт не вміє говорити. Він не скаже, що болить голова чи коле в боці. Натомість він залишає щоденник, куди записує кожен симптом - щосекунди, 24/7. Якщо ви цей щоденник відкриєте, ви врятуєте йому життя. Якщо ні - одного ранку він просто перестане дихати. Ваш сервер - саме такий мовчазний пацієнт. А його щоденник - це логи. І 90% власників сайтів жодного разу в них не заглядали.

Я щотижня бачу одну й ту саму історію: підприємець пише в підтримку - "сайт не працює, зробіть щось!". Саппорт відповідає: "Подивіться логи". Підприємець дивиться на екран, бачить тисячі рядків незрозумілого тексту і закриває файл. Проблема повторюється через тиждень. І знову. І знову. Давайте це зупинимо.

Що таке серверні логи і чому вони - ваш найкращий детектив

Серверні логи - це текстові файли, куди система записує буквально все, що відбувається на вашому хостингу. Кожен запит відвідувача. Кожна помилка PHP. Кожна спроба авторизації. Кожен збій бази даних. Це як камера спостереження, що знімає 24 години на добу, 365 днів на рік.

Основних типів логів, які вам потрібні прямо зараз, чотири:

• Access log - хто приходив на сайт, звідки, коли і що запитував
• Error log - усі помилки, від дрібних попереджень до фатальних збоїв
• Mail log - що відбувається з електронною поштою на сервері
• Auth log (secure log) - хто намагався увійти на сервер і чи вдалося це

Error log - це перший файл, який ви відкриваєте при будь-якій проблемі. Не гугл, не форум, не чат з підтримкою. Спочатку - лог помилок. У 70% випадків відповідь буде прямо там, чорним по білому.

Де шукати логи і як до них дістатися

Розташування логів залежить від вашого хостинг-провайдера і панелі управління. Ось коротка карта для найпопулярніших варіантів:

На shared-хостингу з cPanel зазвичай все просто: зайдіть у розділ "Metrics" або "Errors" - там буде посилання на останні 300 записів error log. На VPS доведеться підключатися по SSH і працювати з файлами напряму. Команда tail -f /var/log/nginx/error.log покаже помилки в реальному часі - як серіал, тільки страшніший.

Анатомія рядка лога: що означають ці ієрогліфи

Ось типовий рядок з error log Apache:

[Mon Jun 09 14:32:17.892435 2025] [php:error] [pid 23145] [client 91.220.34.12:54312] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes) in /home/user/public_html/wp-includes/class-wpdb.php on line 2056

Виглядає як шифр? Давайте розберемо по шматках:

1. Дата і час - Mon Jun 09 14:32:17 - коли саме сталась помилка
2. Рівень серйозності - php:error - це серйозна помилка, а не попередження
3. PID - 23145 - ідентифікатор процесу (корисно при дебагу)
4. IP клієнта - 91.220.34.12 - хто спровокував помилку
5. Суть проблеми - PHP Fatal error: Allowed memory size exhausted - пам'яті не вистачило
6. Файл і рядок - class-wpdb.php on line 2056 - точне місце збою

Тепер ви знаєте: сайт впав, бо PHP-скрипт намагався з'їсти більше 128 МБ оперативки. Рішення? Або збільшити memory_limit в php.ini, або знайти плагін-обжору, який жере пам'ять. Бачите - лог не просто повідомив про проблему, він вказав на конкретний файл і рядок коду.

П'ять помилок, які кричать з логів найголосніше

За 15 років роботи з серверами я склав свій "хіт-парад" помилок, які зустрічаються найчастіше. Ось вони:

1. 500 Internal Server Error. Королева помилок. Користувач бачить білий екран або невиразне повідомлення. Error log покаже причину: зламаний .htaccess, синтаксична помилка PHP, вичерпаний ліміт пам'яті чи збій модуля. Без лога ви стріляєте навмання.

2. 403 Forbidden. Сервер відмовляє у доступі. Зазвичай - неправильні права на файли (chmod). Access log покаже, до якого файлу намагались достукатися, а error log - чому не вийшло.

3. PHP Warning: Cannot modify header information. Класика для WordPress. Означає, що якийсь файл виводить пробіл або символ BOM перед тим, як PHP встигає відправити заголовки. Лог вкаже точний файл.

4. MySQL server has gone away. База даних обірвала з'єднання. Причини: запит занадто великий, таймаут з'єднання занадто короткий або MySQL просто впав. Auth log може показати, чи не був сервер під атакою саме в цей момент.

5. Too many open files. Операційна система вичерпала ліміт дескрипторів файлів. Це як готель, де всі кімнати зайняті - новий гість просто не може заселитися. Рішення - збільшити ulimit або оптимізувати з'єднання.

Якщо ви навчитесь розпізнавати ці п'ять патернів, ви закриєте 80% усіх проблем свого хостингу. Правило Парето працює і тут.

Практичні команди: мінімальний набір для виживання

Вам не потрібно ставати сисадміном. Достатньо вивчити кілька команд, які працюють на будь-якому Linux-сервері:

• tail -n 100 /var/log/nginx/error.log - показати останні 100 рядків помилок
• grep "Fatal" /var/log/apache2/error.log - знайти всі фатальні помилки
• grep "login" /var/log/auth.log | tail -n 50 - останні 50 спроб входу
• awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20 - топ-20 IP-адрес за кількістю запитів (ідеально для виявлення ботів і DDoS)

Остання команда - мій улюблений інструмент. Якщо одна IP-адреса зробила 15 000 запитів за годину, а решта - по 50-100, ви знайшли або бота, або атаку. Заблокуйте цю IP через файрвол і спостерігайте, як навантаження падає вдвічі за хвилину.

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

Читати логи вручну щодня - це як переглядати записи камер спостереження 24 години поспіль. Нереально і непотрібно. Замість цього налаштуйте автоматичні тригери:

Fail2ban - безкоштовний інструмент, який читає auth log і автоматично блокує IP-адреси після N невдалих спроб входу. Встановлення займає 10 хвилин, а ефект - колосальний. За моїми спостереженнями, на типовому VPS щодня відбувається від 200 до 5000 спроб брутфорсу SSH. Fail2ban перетворює цю лавину на тихий струмок.

Logwatch або GoAccess - збирають статистику з логів і надсилають вам щоденний звіт на пошту. П'ять хвилин на читання ранкового листа - і ви в курсі здоров'я сервера.

Logrotate - обов'язковий компонент. Без нього логи зростатимуть нескінченно і одного дня з'їдять увесь диск. Я бачив сервери, де access.log важив 47 ГБ. Диск заповнився на 100%, сайт ліг, а власник не розумів, куди зникло місце. Logrotate стискає старі логи і видаляє їх за розкладом - наприклад, зберігати останні 7 днів, решту - в архів або на смітник.

Ось мінімальна стратегія, яка працює:

1. Налаштуйте logrotate для щоденної ротації і зберігання логів за 14 днів
2. Встановіть Fail2ban для захисту SSH і панелі адміністратора
3. Підключіть GoAccess або Logwatch для щоденних звітів
4. Раз на тиждень переглядайте error log вручну - 10 хвилин, не більше

Коли логи рятують не тільки сервер, а й гроші

Один мій клієнт - інтернет-магазин з оборотом близько $12 000 на місяць - скаржився, що конверсія впала на 30% за два тижні. Маркетологи шукали проблему в рекламі. Дизайнери перемальовували кнопки. А причина тихо сиділа в error log: плагін кешування після оновлення почав видавати 503-ю помилку для 15% відвідувачів. Рівно для тих, хто заходив зі смартфонів з певними куками. Google Analytics цього не бачив, бо скрипт аналітики не встигав завантажитися. А лог бачив. Кожен такий запит був задокументований з точністю до мілісекунди.

Виправлення зайняло 4 хвилини - відкотити плагін до попередньої версії. Втрата за два тижні сліпоти - приблизно $3 600.

Логи - це не технічна деталь для гіків. Це фінансовий інструмент для бізнесу.

Тож ось моє запитання до вас: коли ви востаннє відкривали error log свого сервера? Якщо відповідь - "ніколи" або "не пам'ятаю" - зробіть це сьогодні. Прямо зараз. Вам не потрібно розуміти кожен рядок. Просто знайдіть слово "Fatal" або "Error" і загугліть перше повідомлення, яке побачите. Це буде найкорисніші 10 хвилин, які ви витратите на свій сайт цього місяця.