Как читать логи сервера и находить проблемы сайта

Когда сайт падает в самый неподходящий момент, а клиент уже пишет в мессенджер, логи сервера становятся единственным источником правды. Никакие догадки не заменят строчку с конкретным указанием: ошибка в файле index.php на строке 45, память закончилась, база данных не отвечает. Для тех, кто привык работать с визуальными панелями и CMS, первый взгляд на серверный лог может вызвать растерянность — слишком много технических деталей в одном потоке. На самом деле всё структурировано и логично, нужно лишь знать, куда смотреть и как интерпретировать увиденное.

Разберем практический подход к чтению логов, без погружения в теорию ради теории. Речь пойдёт о том, где искать логи на разных конфигурациях — от дешёвого хостинга с cPanel до собственного VPS, как вычленять конкретные типы ошибок и, главное, что делать после того, как вы их нашли. Материал будет полезен владельцам сайтов на Joomla, WordPress и других платформах, а также всем, кто хочет самостоятельно разбираться в веб-администрировании.

Что такое логи сервера и зачем они нужны

Логи сервера — это хронология всех запросов и событий, которые происходят на вашем веб-сервере. Каждый раз, когда браузер пользователя запрашивает страницу, сервер пишет в журнал строку с IP-адресом посетителя, запрошенным URL, кодом ответа (200, 404, 500), временем обработки запроса и рядом других параметров. Одновременно в отдельный файл попадают ошибки: критические сбои в PHP-скриптах, проблемы с доступом к файлам, таймауты соединений с базой данных.

Вся эта информация генерируется на уровне веб-сервера — Apache или Nginx. CMS вроде Joomla или WordPress могут дополнительно вести собственные журналы, но они лишь дополняют серверные, а не заменяют их. Серверный лог видит проблему до того, как она доберётся до CMS: например, если PHP-скрипт упал с фатальной ошибкой, это зафиксируется в логе ошибок Apache, а WordPress даже не успеет обработать запрос и записать что-либо в свой debug.log.

Почему это важно для веб-мастера

1. Диагностика ошибок. Когда пользователь видит «500 Internal Server Error», лог ошибок показывает полный стек вызовов: какой именно файл вызвал сбой, какая библиотека не загрузилась, на какой строке прервалось выполнение. Без логов вы бы просто перебирали варианты вслепую — переименовывали плагины, сбрасывали настройки, гадали на кофейной гуще.
2. Оптимизация скорости. В логах доступа видно, какие запросы обрабатываются медленнее всего. На практике часто оказывается, что три-четыре страницы с тяжёлыми запросами к базе данных замедляют весь сайт, создавая очередь на сервере. Логи позволяют точно определить эти страницы.
3. Безопасность. Массовые POST-запросы к /wp-login.php с разных IP, сканирование /administrator/index.php на Joomla, попытки доступа к .env-файлам — всё это оставляет следы в логах доступа. Вовремя замеченная атака предотвращает взлом, а не устраняет его последствия.
4. Анализ поведения пользователей. Серверные логи показывают реальную картину посещаемости, которую не искажают блокировщики скриптов. Можно отследить, с каких страниц уходят посетители, на каких URLs возникают 404 ошибки из-за битых ссылок.
5. Контроль работоспособности. Если сайт периодически «падает» по ночам, логи часто указывают на конкретный процесс: cron-задача, которая съедает всю память, или пик обращений поискового бота, создающий чрезмерную нагрузку.

Как логи работают в разных системах

Логи сервера не зависят от используемой CMS. Apache и Nginx записывают их одинаково для сайта на Joomla, WordPress, самописном PHP-фреймворке или Tilda (если она развёрнута на вашем сервере). Разница только в способе доступа:

• Хостинг с панелью управления: cPanel, ISPmanager, Plesk, DirectAdmin — логи доступны через веб-интерфейс, обычно с ограничением на количество отображаемых строк.
• Собственный VPS или выделенный сервер: логи хранятся в текстовых файлах в директориях /var/log/ (Linux) или C:\inetpub\logs\ (Windows), доступны через SSH или FTP.
• Облачные платформы: AWS, Google Cloud, Azure — логи собираются через встроенные сервисы мониторинга и доступны через API или веб-консоли.

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

Где искать логи сервера: основные источники

Поиск логов — первый практический шаг. Местоположение зависит от типа хостинга и конфигурации сервера, но общие принципы едины. Рассмотрим основные варианты от простого к сложному.

1. Панель управления хостингом

Самый доступный способ для большинства веб-мастеров. Практически любой коммерческий хостинг в России предоставляет панель управления с разделом для просмотра логов.

cPanel: зайдите в раздел «Metrics» → «Errors» для просмотра логов ошибок и «Raw Access Logs» для логов посещений. В «Raw Access Logs» можно скачать полный файл за определённый период — это полезно, когда встроенный просмотрщик показывает только последние 300 строк, а ошибка происходила вчера. Также логи часто лежат в директории /home/username/logs/, доступной через «File Manager».

ISPmanager: раздел «Логи» даёт доступ к журналам ошибок Apache/Nginx и логам посещений. Удобная особенность — встроенная фильтрация по IP, URL и коду ответа. Если сайт работает на связке Nginx + Apache, логи будут в двух вкладках, и смотреть нужно обе: ошибка может быть зафиксирована как в логе фронтенда (Nginx), так и в логе бэкенда (Apache).

Plesk: во вкладке «Логи» доступны логи ошибок и доступа. Можно настроить автоматическую отправку логов на email — полезная функция для мониторинга, но на практике при большом количестве ошибок ящик быстро переполняется.

FastPanel, DirectAdmin: ищите разделы «Логи» или «Мониторинг». В FastPanel логи Apache/Nginx находятся в соответствующем пункте меню, интерфейс интуитивный.

Важно: на недорогих тарифах хостинга доступ к полному файлу логов может быть ограничен. Встроенный просмотрщик часто показывает только последние 100–500 записей, и если ошибка возникла сутки назад, вы её не увидите. В таких случаях либо включайте запись логов в отдельный файл через настройки CMS (например, debug.log в WordPress), либо переходите на тариф с полноценным доступом к логам.

2. Текстовые файлы на сервере (Linux)

Если у вас свой VPS или выделенный сервер с доступом по SSH, логи хранятся в стандартных директориях. Это наиболее гибкий способ работы — доступны все записи с момента создания файла, можно использовать консольные утилиты для фильтрации и поиска.

Как открывать и работать с файлами:

• tail -n 100 /var/log/apache2/error.log — последние 100 записей. Быстрый способ посмотреть, что происходило в последние минуты.
• tail -f /var/log/apache2/error.log — режим реального времени. Запустите в одном окне терминала, а в другом воспроизводите ошибку на сайте — увидите запись мгновенно. Незаменимо при отладке.
• grep "500" /var/log/apache2/access.log — фильтрация по коду статуса. Выводит только строки с 500-ми ошибками.
• cat /var/log/apache2/error.log | grep "PHP Fatal" — поиск фатальных ошибок PHP.

На практике часто используется комбинация команд: tail -n 1000 /var/log/apache2/access.log | grep " 500 " | awk '{print $1, $7, $9}' — эта команда покажет IP, URL и статус для последних 500-х ошибок.

3. Облачные сервисы и мониторинг

На облачных платформах работа с логами организована через централизованные сервисы:

• AWS CloudWatch Logs — сбор логов со всех инстансов в одном интерфейсе. Можно настраивать метрики и алерты: например, получать уведомление в Telegram при появлении более 10 ошибок 500 за минуту.
• Google Cloud Logging — поиск по ключевым словам, фильтрация по времени, интеграция с другими сервисами Google Cloud.
• Azure Monitor — аналогичный функционал для экосистемы Microsoft.

Эти инструменты особенно ценны, когда у вас несколько серверов и нужно видеть общую картину, не подключаясь к каждому по SSH.

4. Логи CMS (внутренние)

Когда доступ к серверным логам ограничен, выручают встроенные механизмы CMS:

• Joomla: файл logs/error.log, если логирование включено в настройках. Важно: по умолчанию эта опция часто выключена, проверьте «Общие настройки → Система → Ведение журнала отладки».
• WordPress: файл wp-content/debug.log появляется, если в wp-config.php добавлены строки: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);. Без этого лог не пишется.
• Tilda: логи недоступны напрямую. Можно использовать встроенный мониторинг в панели Tilda, но он показывает только ошибки на уровне платформы, а не сервера.

Логи CMS удобны для отладки ошибок в шаблонах и плагинах, но не заменяют серверные логи. Например, проблему с правами доступа к файлу вы в дебаг-логе CMS можете вообще не увидеть, а в серверном логе ошибок Apache она будет зафиксирована как «Permission Denied».

5. Инструменты для анализа логов

Для регулярной работы с логами ручной просмотр быстро надоедает. Инструменты автоматизируют анализ и делают его наглядным:

• GoAccess — терминальный или веб-интерфейс для анализа логов Apache/Nginx в реальном времени. Показывает топ запрашиваемых URL, коды ответов, источники трафика. Настраивается за 10 минут даже на недорогом VPS.
• AWStats — генератор статических отчётов. Хорош для периодического анализа посещаемости, но для оперативной диагностики ошибок менее удобен.
• Logwatch — автоматический анализ логов и отправка сводок на email. Полезен для ежедневного мониторинга: утром получаете отчёт с количеством ошибок и подозрительной активностью за ночь.
• Kibana + Elasticsearch — промышленное решение для больших проектов. Позволяет строить сложные запросы, визуализировать данные, настраивать предиктивные алерты. Требует ресурсов и времени на внедрение.

Для большинства небольших проектов на Joomla или WordPress вполне достаточно GoAccess или комбинации tail + grep. Переходить на Kibana стоит, когда логов становится больше пары гигабайт в день и ручной анализ перестаёт быть эффективным.

Как читать логи: структура и основные элементы

Логи сервера — это не хаотичный набор символов, а строго структурированные записи. Умение быстро выхватывать взглядом ключевые поля экономит часы при диагностике.

1. Логи посещений (Access Logs)

Каждая строка лога доступа — это один HTTP-запрос к серверу. Формат может различаться в зависимости от настроек Apache (Combined, Common) или Nginx, но основные поля присутствуют всегда.

Пример строки Apache (Combined формат):

192.168.1.100 - frank [07/Jul/2026:10:15:30 +0300] "GET /index.php?page=about HTTP/1.1" 200 12345 "https://google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Разбор полей:

1. IP-адрес посетителя (192.168.1.100) — с какого адреса пришёл запрос. При анализе атак это первое, на что смотрите.
2. Идентификатор пользователя (- frank) — обычно - для анонимных запросов. Заполняется редко, в основном при использовании HTTP-аутентификации.
3. Дата и время ([07/Jul/2026:10:15:30 +0300]) — временная метка запроса с часовым поясом. Позволяет точно определить, когда произошла ошибка.
4. Запрос ("GET /index.php?page=about HTTP/1.1") — метод (GET, POST, HEAD), URL, версия протокола. Метод важен: POST-запросы к /wp-login.php с разных IP — признак перебора паролей.
5. Статус ответа (200) — ключевое поле для поиска проблем. Запомните: 2xx — успех, 3xx — перенаправление, 4xx — ошибка клиента, 5xx — ошибка сервера.
6. Размер ответа (12345) — объём переданных данных в байтах. Аномально большие или маленькие значения могут указывать на проблемы с выводом контента.
7. Ссылка-источник ("https://google.com/") — откуда пришёл пользователь. Поле берётся из заголовка Referer, который может отсутствовать или быть подменён.
8. User-Agent ("Mozilla/5.0...") — информация о браузере и ОС. По этому полю можно отличить реального пользователя от бота.

Пример строки Nginx:

192.168.1.100 - - [07/Jul/2026:10:15:30 +0300] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 435 "https://site.ru/" "Mozilla/5.0"

В Nginx поля те же, но порядок может слегка отличаться. Конкретный формат задаётся директивой log_format в конфигурационном файле nginx.conf. Если логи выглядят нестандартно, проверьте эту директиву.

2. Логи ошибок (Error Logs)

Логи ошибок фиксируют всё, что идёт не по плану: от фатальных сбоев PHP до предупреждений о нехватке памяти. Строка обычно содержит дату, уровень ошибки, клиента (если есть) и текст ошибки.

Пример строки Apache:

[Sun Jul 07 10:15:31.234567 2026] [error] [client 192.168.1.100] PHP Fatal error: Class 'CustomPlugin' not found in /var/www/site/index.php:45

Разбор полей:

1. Дата и время ([Sun Jul 07 10:15:31.234567 2026]) — когда произошла ошибка, с точностью до микросекунд.
2. Тип ошибки ([error]) — уровень: error (ошибка), warn (предупреждение), notice (уведомление), crit (критическая). Для диагностики важнее всего error и crit.
3. IP-адрес клиента ([client 192.168.1.100]) — кто спровоцировал ошибку. Может отсутствовать, если ошибка возникла при запуске сервера или выполнении cron-задачи.
4. Описание ошибки (PHP Fatal error: Class 'CustomPlugin' not found) — самое ценное поле. Прямо указывает, что произошло: не найден класс, синтаксическая ошибка, закончилась память.
5. Путь к файлу и строка (/var/www/site/index.php:45) — точное место в коде, где произошёл сбой.

Пример строки Nginx:

2026/07/07 10:15:31 [error] 1234#1234: *5678 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.100, server: site.ru, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:8080/"

Nginx подробно описывает, что именно пошло не так: отказ в соединении с upstream (бэкендом), таймаут, ошибка разрешения DNS. Строки с «upstream» в Nginx-логах ошибок — верный признак проблем со связкой Nginx + PHP-FPM или Nginx + Apache.

3. Ключевые HTTP-статусы

Коды состояния HTTP — это первый фильтр при анализе логов доступа. По ним вы сразу сужаете круг поиска.

Запомните грубое разделение: коды 400–499 — проблемы на стороне клиента (пользователь запросил несуществующую страницу, не авторизован), 500–599 — проблемы на сервере (ошибка в коде, упала база данных). Это первое, что нужно определить при анализе.

4. Типы ошибок в логах

В логах ошибок Apache и Nginx встречаются характерные формулировки, по которым можно быстро определить категорию проблемы:

1. PHP Fatal Error — самый частый тип. Критическая ошибка PHP: не найден класс, функция, файл. Скрипт прерывается, пользователи видят 500 ошибку или белый экран.
2. Segmentation Fault — ошибка доступа к памяти на уровне процесса. Часто связана с расширениями PHP, написанными на C (например, imagick, ioncube). Решается обновлением или переустановкой расширения.
3. Permission Denied — нет доступа к файлу или директории. Типичная ситуация после восстановления из бэкапа или ручного изменения прав.
4. Connection Refused — сервер не может подключиться к бэкенду. Либо не запущен сервис (PHP-FPM, MySQL), либо указан неверный порт.
5. Timeout — запрос не уложился в отведённое время. Часто при импорте больших файлов, генерации отчётов или медленных запросах к API.
6. Disk Full — на диске закончилось место. Сервер не может писать логи, создавать временные файлы, кешировать данные.
7. Memory Limit — превышен лимит памяти для PHP-скрипта. Решается увеличением memory_limit в php.ini или оптимизацией кода.

Основные ошибки сайта и как их находить в логах

Разберём конкретные сценарии, с которыми сталкивается каждый веб-мастер. От получения ошибки на сайте до её исправления — с примерами строк из реальных логов.

1. Ошибка 404: Файл не найден

Как это выглядит на сайте: пользователь переходит по ссылке и видит «404 Not Found» или кастомную страницу «Страница не найдена».

В логах доступа: строка с кодом 404 в девятом поле (второе с конца в стандартном Combined-формате).

Пример строки:

83.220.239.19 - - [07/Jul/2026:11:22:33 +0300] "GET /old-page.html HTTP/1.1" 404 245 "https://google.com/search?q=site" "Mozilla/5.0"

Что искать в логах ошибок: может быть запись вида File does not exist: /var/www/site/old-page.html. Это прямое указание на то, что файла физически нет на диске.

Типичные причины:

• Страницу удалили, а ссылки на неё остались в меню, в статьях или поисковых системах.
• В Joomla изменили алиас материала, не настроив редирект со старого URL.
• В WordPress отключили плагин, который отвечал за генерацию определённого типа страниц.
• Ошибка в файле .htaccess — модуль mod_rewrite неправильно преобразует ЧПУ-ссылки.

Алгоритм исправления:

1. Проверить, есть ли файл физически на сервере: ls -la /var/www/site/old-page.html.
2. Если файл удалён, а страница должна существовать — понять, какой компонент CMS её генерирует. В Joomla это может быть материал, в WordPress — запись или страница.
3. Если URL изменился — настроить 301-редирект. В Joomla это делается через компонент «Перенаправления», в WordPress — через плагин типа Redirection или через .htaccess.
4. Если URL ошибочный — исправить ссылку в коде, контенте или меню.

2. Ошибка 500: Internal Server Error

Как это выглядит на сайте: белый экран или стандартная страница «500 Internal Server Error». Самая неприятная ситуация для веб-мастера, потому что она редко бывает очевидной.

В логах доступа: строка с кодом 500.

Пример в логах ошибок:

[Mon Jul 08 14:22:45.123456 2026] [error] [client 95.24.178.43] PHP Fatal error: require_once(): Failed opening required '/var/www/site/plugins/system/customplugin/customplugin.php' (include_path='.:/usr/share/php') in /var/www/site/plugins/system/customplugin/customplugin.php on line 12

Типичные причины:

• Ошибка в PHP-коде — опечатка в названии файла, класса, функции. Часто случается после копирования кода из интернета без адаптации.
• После обновления Joomla или WordPress плагин оказался несовместим с новой версией PHP.
• Файл был удалён или повреждён при загрузке по FTP (бинарный режим вместо текстового).
• Не хватает памяти: в логе будет PHP Fatal error: Allowed memory size of ... bytes exhausted.

Алгоритм исправления:

1. В логе ошибок находим конкретный файл и строку. В примере выше это /var/www/site/plugins/system/customplugin/customplugin.php:12.
2. Проверяем, существует ли файл: ls -la /var/www/site/plugins/system/customplugin/customplugin.php.
3. Если файла нет — восстанавливаем из бэкапа или переустанавливаем плагин.
4. Если файл есть — открываем его на строке 12 и смотрим, что там происходит. В примере — не найден другой файл, на который ссылается require_once.
5. Если ошибка в памяти — увеличиваем memory_limit в php.ini (например, до 256M или 512M).
6. В Joomla: если ошибка появилась после установки расширения, переименуйте папку плагина через FTP — система его отключит, сайт заработает, а вы сможете спокойно разбираться.

3. Ошибка 403: Forbidden

Как это выглядит на сайте: пользователь видит «403 Forbidden» или «Access Denied». Страница существует, но сервер не отдаёт её.

Пример строки лога ошибок:

[Mon Jul 08 15:30:44.567890 2026] [error] [client 109.188.126.55] client denied by server configuration: /var/www/site/administrator/

Типичные причины:

• Неправильные права доступа к файлу или директории. Например, после восстановления из бэкапа права на файлах стали 600, а должны быть 644.
• В .htaccess или nginx.conf настроено ограничение доступа по IP, а ваш IP изменился.
• Защита административной панели Joomla через пароль в .htaccess, и файл .htpasswd недоступен.
• Включён плагин безопасности (например, Akeeba Admin Tools в Joomla), который блокирует доступ по определённым правилам.

Алгоритм исправления:

1. Проверить права: ls -la /var/www/site/administrator/. Типичные права: 755 для директорий, 644 для файлов.
2. Если права неверные — исправить: chmod 755 /var/www/site/administrator/.
3. Проверить .htaccess на наличие директив Deny, Allow, Require. Временно закомментировать подозрительные строки.
4. В Joomla: проверить плагины системы безопасности, временно отключить их через FTP (переименовать папку плагина).

4. Ошибка 502/503: Backend не отвечает

Как это выглядит на сайте: «502 Bad Gateway» или «503 Service Unavailable». Сайт не открывается, хотя сервер работает.

Пример строки лога ошибок Nginx:

2026/07/08 16:45:22 [error] 2345#2345: *12345 connect() failed (111: Connection refused) while connecting to upstream, client: 178.67.92.33, server: site.ru, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:9000/"

Типичные причины:

• PHP-FPM упал или не запущен. На практике часто случается после перезагрузки сервера, когда PHP-FPM не прописан в автозагрузку.
• В конфигурации Nginx указан неверный порт для upstream. Например, PHP-FPM слушает порт 9001, а в конфиге указан 9000.
• База данных MySQL/MariaDB не запущена, и запросы к ней вызывают ошибку подключения.

Алгоритм исправления:

1. Проверить, запущен ли PHP-FPM: systemctl status php7.4-fpm (версия PHP зависит от вашей системы).
2. Если не запущен: systemctl start php7.4-fpm.
3. Проверить конфигурацию Nginx: nginx -t (проверка синтаксиса), затем найти директиву fastcgi_pass — она должна указывать на правильный сокет или порт PHP-FPM.
4. Если проблема с базой данных — проверить: systemctl status mysql (или mariadb).

5. Ошибка 408/504: Timeout

Как это выглядит на сайте: страница долго грузится, а затем обрывается с ошибкой таймаута.

Пример строки лога ошибок:

2026/07/08 17:30:55 [error] 3456#3456: *23456 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 46.39.53.19, server: site.ru, request: "POST /administrator/index.php?option=com_installer HTTP/1.1", upstream: "http://127.0.0.1:8080/..."

Типичные причины:

• Долгий запрос к базе данных без индексов на больших таблицах. Классическая ситуация: интернет-магазин с десятками тысяч товаров и запросом, который перебирает всю таблицу.
• Генерация большого PDF или Excel-файла на лету.
• Внешний API отвечает слишком медленно, а скрипт ждёт его без ограничения времени.
• На сервере запущено слишком много процессов, и до вашего запроса очередь не доходит.

Алгоритм исправления:

1. Увеличить таймаут в конфигурации: для Apache — Timeout 300 в httpd.conf, для Nginx — proxy_read_timeout 300 или fastcgi_read_timeout 300 в конфиге сайта.
2. Оптимизировать запрос: добавить индексы в базу данных, переписать медленный SQL.
3. Проверить нагрузку на сервер через top или htop. Если load average зашкаливает — найти и оптимизировать прожорливые процессы.

6. Ошибки безопасности: сканирование, подбор паролей

Как это выглядит в логах доступа: множество запросов к типовым уязвимым путям или повторяющиеся POST-запросы к формам входа.

Примеры строк:

45.33.32.31 - - [08/Jul/2026:18:10:01 +0300] "GET /wp-admin/ HTTP/1.1" 404 245 "-" "Mozilla/5.0"
185.176.27.132 - - [08/Jul/2026:18:10:12 +0300] "POST /administrator/index.php HTTP/1.1" 200 356 "-" "Mozilla/5.0"
91.240.118.22 - - [08/Jul/2026:18:10:23 +0300] "GET /.env HTTP/1.1" 404 162 "-" "python-requests/2.19.1"

Признаки атаки:

• Множество запросов с одного IP к /wp-login.php, /administrator/, /phpmyadmin, /.env за короткий промежуток времени.
• User-Agent содержит «python-requests», «nikto», «sqlmap» — инструменты автоматического сканирования.
• POST-запросы к форме входа с разными паролями — видно по времени между запросами (доли секунды).

Алгоритм действий:

1. Заблокировать IP через .htaccess (Apache): Deny from 45.33.32.31 или через nginx.conf: deny 45.33.32.31;.
2. В Joomla: установить и настроить Akeeba Admin Tools — он автоматически блокирует IP после нескольких неудачных попыток входа.
3. В WordPress: установить Wordfence или Limit Login Attempts Reloaded.
4. Сменить пароли администраторов на сложные, сгенерированные менеджером паролей.
5. Настроить защиту через robots.txt — закрыть от индексации служебные директории (хотя боты-сканеры его игнорируют, это всё равно полезно).

Практические инструменты для анализа логов

Ручной просмотр логов через cat и less быстро утомляет, особенно когда файл весит сотни мегабайт. Рассмотрим инструменты от простых команд до промышленных систем.

1. Простые команды (для новичков)

Эти команды доступны на любом Linux-сервере и покрывают 90% задач по анализу логов.

• tail -n 100 /var/log/apache2/error.log — последние 100 строк лога ошибок. Первое, что я запускаю, когда сайт падает.
• tail -f /var/log/apache2/access.log — просмотр в реальном времени. Откройте в одном окне терминала, в другом — перезагрузите проблемную страницу, и вы увидите запись мгновенно.
• grep " 500 " /var/log/nginx/access.log — фильтрация по коду 500. Пробелы вокруг 500 важны, чтобы не захватить строки с числами 5000, 5001 и т.д.
• grep -c " 404 " /var/log/apache2/access.log — подсчёт количества 404 ошибок. Полезно для быстрой оценки масштаба проблемы.
• less /var/log/apache2/error.log — просмотр с возможностью скроллинга и поиска (нажмите / и введите искомое слово).
• awk '{print $1, $7, $9}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20 — топ-20 URL по количеству запросов с IP-адресом и кодом ответа.

2. Веб-интерфейсы

GoAccess — простой анализатор логов с веб-интерфейсом. Устанавливается из репозиториев: apt install goaccess. Запуск в реальном времени: goaccess /var/log/apache2/access.log -o /var/www/html/report.html --real-time-html. После этого отчёт будет доступен по адресу http://ваш-сайт/report.html. Показывает топ URL, коды ответов, источники трафика, распределение по времени суток.

AWStats — более старый, но надёжный инструмент. Устанавливается через apt install awstats. Генерирует статические HTML-отчёты, которые удобно смотреть раз в день. Не подходит для оперативной диагностики, но даёт отличную картину посещаемости за периоды.

3. Мощные системы для профессионалов

Kibana + Elasticsearch — связка для централизованного сбора и визуализации логов. Подходит, когда у вас несколько серверов и объём логов исчисляется гигабайтами в день. Настройка требует времени: нужно поднять Elasticsearch для хранения, Logstash или Filebeat для сбора и Kibana для визуализации. Но результат того стоит: можно строить дашборды, настраивать алерты, искать по любым полям за секунды.

CloudWatch Logs (AWS) — для проектов, размещённых в Amazon Web Services. Логи автоматически собираются с EC2-инстансов, можно настраивать метрики и алерты. Удобно, что всё работает из коробки, не нужно поднимать отдельные сервисы.

Google Cloud Logging — аналогично для Google Cloud. Интегрируется с другими сервисами Google и поддерживает мощный язык запросов.

Чек-лист: как быстро найти проблему в логах

Когда сайт упал, а клиент или начальник требует немедленного решения, нет времени методично перечитывать документацию. Действуйте по этому алгоритму — он проверен на десятках реальных инцидентов.

1. Определите тип ошибки. Посмотрите на страницу в браузере или спросите пользователя — 404, 500, 403 или другой код. Это сразу сужает круг поиска.
2. Найдите логи. Откройте панель хостинга или подключитесь по SSH. Если работаете с VPS — перейдите в /var/log/apache2/ или /var/log/nginx/.
3. Отфильтруйте по коду ошибки. Для ошибок 404, 500, 502, 503 — grep " НОМЕР " /путь/к/access.log | tail -20. Вы увидите последние запросы с этим кодом.
4. Посмотрите логи ошибок за тот же период. tail -50 /var/log/apache2/error.log. В 80% случаев здесь будет прямое указание на файл и строку.
5. Определите причину. Сопоставьте записи из access.log и error.log. Например, access.log показывает 500 на странице /checkout, а error.log — фатальную ошибку в файле плагина оплаты.
6. Исправьте проблему. Если ошибка в коде — исправляйте код. Если в базе данных — проверяйте запущен ли MySQL. Если в правах доступа — меняйте chmod.
7. Проверьте. Перезагрузите проблемную страницу. Если ошибка ушла — хорошо. Если нет — повторите с шага 3, вероятно, есть несколько проблем одновременно.
8. Задокументируйте. Запишите, что было сделано и почему. Через полгода, когда ситуация повторится, вы скажете себе спасибо.

Типовые ошибки и как их избежать

За годы работы с логами я регулярно наступал на одни и те же грабли. Лучше учиться на чужих ошибках.

1. Просмотр логов без фильтрации

Ситуация: открываете access.log размером 2 ГБ и пытаетесь скроллить в поисках ошибок. Это бессмысленно: вы потратите часы и пропустите нужные строки.

Как правильно: всегда используйте grep для фильтрации по коду ошибки или временному периоду. Например, grep "08/Jul/2026:18:" access.log | grep " 500 " — все 500-е ошибки за конкретный час.

2. Неправильное понимание контекста ошибки

Ситуация: видите «File not found», удаляете ссылку на несуществующий файл из кода, а ошибка остаётся. На самом деле файла нет на диске, потому что плагин не доустановился.

Как правильно: всегда проверяйте контекст. Если в логе указан путь к файлу — проверьте, существует ли он физически: ls -la /путь/к/файлу. Часто проблема не в том, что файл не найден, а в том, что путь указан неверно.

3. Игнорирование прав доступа

Ситуация: после восстановления сайта из бэкапа половина страниц выдаёт 403. Вы проверяете код, конфигурацию, перезагружаете сервер — ничего не помогает. А проблема в том, что права на файлах сбились при копировании.

Как правильно: всегда проверяйте права, особенно после операций с файловой системой. Команда ls -la /var/www/site/ покажет владельца и маску доступа. Типичные значения: владелец www-data (или nginx), права 755 на директории, 644 на файлы.

4. Неправильная настройка времени ожидания

Ситуация: страница импорта товаров падает с ошибкой 504, хотя на старом сервере работала. Разница в том, что на новом сервере таймаут Nginx установлен в 30 секунд, а импорт занимает минуту.

Как правильно: для долгих операций увеличивайте таймауты: в Apache — директива Timeout, в Nginx — fastcgi_read_timeout и proxy_read_timeout. Но не злоупотребляйте: если таймаут 600 секунд, а запросов много, они быстро забьют все доступные слоты.

5. Игнорирование безопасности

Ситуация: сайт работает медленно, вы смотрите нагрузку — она под 100%. Открываете логи доступа, а там сотни запросов в минуту от ботов, которые перебирают пароли к /wp-login.php.

Как правильно: регулярно просматривайте access.log на предмет подозрительной активности. Настройте автоматическую блокировку IP после нескольких неудачных попыток входа (через fail2ban или плагины безопасности CMS).

FAQ: частые вопросы о логах сервера

Где найти логи на хостинге с панелью ISPmanager?
В разделе «Логи» → «Логи ошибок Apache/Nginx» и «Логи посещений». Если сайт работает на связке Nginx + Apache — смотрите оба лога.

Как посмотреть только ошибки 500?
grep " 500 " /var/log/apache2/access.log — пробелы вокруг 500 обязательны, иначе grep найдёт все строки с «500» в любом контексте.

Что делать, если лог слишком большой?
Используйте tail для просмотра последних записей: tail -n 500 access.log | grep "ошибка". Либо фильтруйте по времени через awk: awk '$4 >= "[08/Jul/2026:18:"' access.log.

Как найти, какой файл вызвал ошибку 500?
Смотрите error.log — там будет строка вида: PHP Fatal error: ... in /var/www/site/components/com_example/example.php:87. Файл и строка указаны после «in».

Почему я не вижу ошибок в логах, хотя сайт не работает?
Возможно, ошибка происходит на уровне, который не пишется в стандартные логи: например, проблема с DNS, фаервол блокирует запросы, или сайт работает через CDN и ошибка на стороне CDN, а не сервера. Проверьте все звенья цепочки.

Как быстро проанализировать, какие страницы чаще всего выдают 404?
grep " 404 " access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20 — топ-20 URL с 404 ошибкой. Полезно для поиска битых ссылок.

Можно ли автоматически получать уведомления о критических ошибках?
Да. Настройте алерты в CloudWatch (AWS) или Google Cloud Logging, либо используйте fail2ban с действием отправки email, либо напишите простой скрипт, который парсит error.log и отправляет уведомление в Telegram при появлении строк с «PHP Fatal».