Хостинг и инфраструктура

Как читать логи сервера: 404, боты и медленные запросы

Что показывает каждая часть строки лога сервера, как находить ошибки 404 и медленные запросы, и как отличить реальных посетителей от ботов.

Команда rabbitclipПубликация: 4 мин чтения

Коротко

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

Если сайт компании по управлению зданиями получает лишь несколько сотен посетителей в месяц, а сервер фиксирует десятки тысяч запросов в день, эта разница почти всегда объясняется трафиком ботов. Без анализа логов понять источник такого разрыва практически невозможно.

Как читать строку лога?

Лог сервера это запись, которую сервер ведет для каждого полученного запроса; формат «combined», используемый по умолчанию в Nginx и Apache, перечисляет IP-адрес источника, дату, запрошенный адрес, HTTP-метод, код состояния, количество отправленных байт, страницу-источник перехода и идентификатор браузера именно в таком порядке.

В типичной строке сначала стоит IP-адрес посетителя, затем дата и время в квадратных скобках, потом запрошенный адрес в кавычках, начинающийся с GET или POST, сразу за ним трехзначный код состояния, 200 для успеха, 404 для не найдено, 500 для ошибки сервера, объем переданных данных и в конце идентификатор браузера в кавычках. Освоив этот порядок один раз, можно читать любой файл лога в дальнейшем.

Что на самом деле показывают ошибки 404?

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

Регулярный просмотр ошибок 404 в логах показывает, какая именно битая ссылка реально затрагивает настоящих посетителей; 404, который повторяется часто и исходит от настоящего браузера, стоит исправить в первую очередь, а единичную попытку бота обычно можно проигнорировать.

Как отличить реальных посетителей от трафика ботов?

Первое, на что стоит посмотреть, это поле user-agent; известные поисковые боты открыто представляются. Но вредоносный бот часто использует user-agent, похожий на настоящий браузер, поэтому одного этого поля недостаточно.

  • Больше одного запроса в секунду с одного и того же IP-адреса, что не соответствует поведению человека
  • Повторяющиеся запросы, сосредоточенные только на определенных страницах, форма входа, поле поиска
  • Запросы, которые сразу идут на глубокие страницы, ни разу не обратившись перед этим к robots.txt
  • Правдоподобный user-agent в сочетании с отсутствующими заголовками, которые обычно отправляет настоящий браузер, язык, куки

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

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

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

Сколько хранить логи и кто должен их просматривать?

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

Регулярный просмотр логов может занимать у одного человека десять минут в неделю; цель не в том, чтобы читать каждую строку, а в том, чтобы отслеживать распределение кодов состояния и самые повторяющиеся ошибки.

Быстрая сводка одной командой

Быструю сводку по файлу лога можно получить и без технической команды. Простая команда, которая считает и сортирует строки лога по коду состояния, за секунды показывает, сколько раз повторяется каждая ошибка; самые частые 404 или 500 оказываются в начале списка.

Та же логика, но с сортировкой по общему числу запросов с одного IP-адреса, сразу выдает необычно активный источник ботов. Оба фильтра дают результат гораздо быстрее, чем построчное чтение всего файла.

Частые ошибки

Логи обычно остаются файлом, который открывают только тогда, когда что-то уже сломалось; без регулярного взгляда раннее предупреждение упускается.

  • Смотреть в логи только после того, как сайт уже упал, упуская более ранние сигналы тревоги
  • Никогда не просматривать ошибки 404, из-за чего битые ссылки остаются незамеченными месяцами
  • Читать аналитику так, будто каждый визит это человек, ни разу не учитывая долю трафика ботов
  • Никогда не добавлять в логи поле времени ответа, из-за чего причина замедления остается неизвестной

Логи сервера показывают сайт честнее любой панели аналитики; каждый запрос, реальный или ботовский, там зафиксирован. Еженедельная десятиминутная привычка ловит многие проблемы до того, как они превратятся в жалобу клиента. На вводной встрече с rabbitclip можно вместе разобрать логи вашего собственного сервера.

Частые вопросы

Нужен ли специальный инструмент, чтобы читать файлы логов?

Для небольшого сайта достаточно фильтровать обычный текстовый файл через командную строку. С ростом трафика инструмент анализа логов упрощает работу.

Всегда ли ошибка 404 это проблема?

Нет. Бот, пробующий случайный адрес, который никогда не существовал, это нормально; настоящая проблема это битая ссылка, с которой часто сталкиваются реальные посетители.

Можно ли полностью заблокировать трафик ботов?

Не полностью, но известные вредоносные паттерны поведения можно в значительной степени заблокировать на уровне сервера или CDN.

Всегда ли причина медленного запроса в сервере?

Нет. Медленность может идти от запроса к базе данных, сторонней интеграции или тяжелого изображения; лог показывает только где происходит замедление, причину нужно исследовать отдельно.

Можно ли получить быструю сводку вместо построчного чтения?

Да. Простая команда, которая считает и сортирует по коду состояния или IP-адресу, показывает самую частую ошибку или необычный источник ботов без чтения каждой строки.

Поделиться

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

Похожие статьи

Если не знаете, с чего начать, — вы там, где нужно.

Проект в вашей голове может быть уже чётким или пока в виде идеи. Подходит и то, и другое. Коротким разговором обсудим вместе, где вы сейчас и куда можете прийти.

Запланируем встречу
Обсудить проект