Перейти к содержанию

Лог-файлы

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

Вы можете получить доступ к содержимому Лог-файлов на Платформе двумя способами:

  1. Включить выгрузку лог-файлов на серверы хранения с доступом по S3 и задать время их хранения. Лог-файлы будут выгружаться на серверы хранения раз в час. Опция настраивается одновременно для всех Сервисных конфигураций в составе Аккаунта.
  2. Получать логи серверов доставки в режиме реального времени по протоколу Syslog. Так как этот протокол работает поверх транспортного протокола UDP, гарантия доставки сообщений и их конфиденциальность не обеспечивается. Опция настраивается для каждой Сервисной конфигурации отдельно.

Для доступа к лог-файлам в составе вашего Аккаунта должны быть включены сервисы Raw Access Logs и Cloud Object Storage. Для получения логов серверов доставки по протоколу Syslog в составе вашего Аккаунта должен быть включен сервис Real-time Logs Streaming.

Как получить доступ к лог-файлам?

Как настроить потоковую передачу логов?

Формат лог-файлов

Доступно управление исходящим форматом лог-файлов, поддерживаются форматы:

  • *.log (вариант, выбираемый по умолчанию) - стандартный вариант логов (common log format);
  • *.json - в формате json-структуры;
  • *.tsv - текстовый формат для представления табличных данных, в котором каждая запись занимает одну строку файла, а поля внутри записи разделены символом горизонтальной табуляции (TAB).

Также для выбора набора данных в лог-файлах есть два варианта:

  • Стандартный - фиксированный минимальный набор данных в логе без информации по сервисам: Edge Logic Rules, Bot Detection и DDoS Protection.
  • Настраиваемый - вариант, при котором самостоятельно можно указать набор данных, который необходимо получать в логах. В этом варианте дополнительно можно выбрать поля с информацией по сервисам: Edge Logic Rules, Bot Detection и DDoS Protection.

При выборе варианта Настраиваемый должно быть выбрано не менее 1 поля данных.

Доступные поля данных:

Поле Описание Стандартный Настраиваемый
remoteAddr IP-адрес источника запроса. + +
host Значение заголовка Host в запросе. + +
datetime Время запроса (GMT). + +
request Первоначальная строка запроса целиком. + +
httpStatus HTTP-код ответа (включая коды 502/504) + +
cacheStatus Статус объекта, например, HIT для объекта, отданного из кэша, или MISS для объекта, запрошенного с сервера оригинации. + +
upstreamAddr Адрес сервера оригинации, в случае если объект отсутствует в кэше. + +
bodyBytesSent Размер тела HTTP-запроса (указывается в байтах). + +
httpReferer Значение заголовка Referer. + +
httpUserAgent Значение заголовка User-Agent. + +
requestTime Время обработки запроса в секундах с точностью до миллисекунд; время, прошедшее с момента чтения первых байт от клиента до момента записи в лог после отправки последних байт клиенту. + +
gzipRatio Степень сжатия (отношение размеров объекта от сервера оригинации к размеру объекта отданного пользователю с Платформы). + +
sslProtocol Версия SSL. + +
sslCipher SSL-шифр в случае, если используется защищенное соединение. + +
connectionRequests Порядковый номер запроса в рамках установленного соединения. + +
connection Порядковый номер соединения. + +
bytesSent Полное количество переданных байт (с учетом HTTP-заголовков). + +
upstreamResponseLength Размер полученного ответа с сервера оригинации. + +
upstreamHeaderTime Время получения заголовков ответа с сервера оригинации. + +
upstreamResponseTime Время получения всего объекта с сервера оригинации. + +
upstreamStatus HTTP-код ответа от сервера оригинации. + +
countryCode Двухбуквенный код страны, которой принадлежит IP-адрес пользователя. + +
requestId Уникальный идентификатор запроса пользователя. + +
serverPort Порт сервера, обработавшего запрос. + +
ipInListType В какой тип списка добавлен IP-адрес запроса (Белый пользовательский/Белый системный/Чёрный/Валидация).

Сервис DDoS Protection.
+
actionForRequest Какое действие применено в отношении запроса (Блокировка / Валидация / Пропущен).

Сервис DDoS Protection.
+
rulesetId Каким набором правил был проверен запрос (id набора). 

Сервис Edge Logic Rules.
+
rulesetTerminatingRuleId Каким терминирующим правилом был проверен запрос (ruleID).

Сервис Edge Logic Rules.
+
rulesetTerminatingAction Какое терминирующее действие применено в отношении запроса (название терминирующего действия).

Сервис Edge Logic Rules.
+
botManagementSourceCategory Какую бот-категорию присвоил запросу сервис Bot Detection. +
challengeAttemptId Идентификатор попытки прохождения проверки.

Сервис Edge Logic Rules.
+

При отсутствии в Аккаунте сервисов Edge Logic Rules, Bot Detection и DDoS Protection информация по запросам в полях этих сервисов будет:

  • в случае с форматами *.log и *.tsv — значение для полей отсутствующих сервисов будет пустым;
  • в случае с форматами *.json — не будет пары ключ-значение для полей отсутствующих сервисов.

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

Пример полей данных и строки лога для варианта Стандартный (фиксированный набор полей данных) с выводом в формате *.log:

$remoteAddr $host [$datetime] "$request" $httpStatus $cacheStatus "$upstreamAddr" $bodyBytesSent "$httpReferer" "$httpUserAgent" "$requestTime" "$gzipRatio" "$sslProtocol/$sslCipher" "$connectionRequests/$connection" $bytesSent "$upstreamResponseLength" "$upstreamHeaderTime" "$upstreamResponseTime" "$upstreamStatus" $countryCode $requestId $serverPort

где значения полей sslProtocol/sslCipher и connectionRequests/connection отображаются по-разному в разных форматах лог-файлов:

  • Форматы *.log и *.tsv: значения переменных конкатенируются в одно с разделителем в виде символа "/". Пример для sslProtocol/sslCipher (для connectionRequests/connection поведение аналогично):

    Значения полученные через API Отображение в лог-файле
    "sslProtocol": true

    "sslCipher: true"
    "значение sslProtocol/значение sslCipher"
    "sslProtocol": false

    "sslCipher: false"
    "/"
    "sslProtocol": true

    "sslCipher: false"
    "значение sslProtocol/"
    "sslProtocol": false

    "sslCipher: true"
    "/значение sslCipher"
  • Формат *.json: переменные отображаются отдельно.

Рекомендации для самостоятельной диагностики

При анализе лог-файлов обращайте внимание на следующие показатели:

  • HTTP-код ответа (HTTP status code). Коды ответа из диапазонов 400-499 и 500-599 свидетельствуют о проблемах получения данных конечными пользователями. Например, код ответа 404 возникает, когда пользователь запросил несуществующий объект, а код ответа 503 обычно возникает, когда сервер перегружен. В этих случаях необходимо обратить внимание на поле upstream_status. Если это поле не пустое, ошибка была получена с сервера оригинации.  Код 504 в поле upstream_status и код ответа 504 указывают на то, что при попытке подключения не удалось получить ответ в течение заданного времени (таймаута) на одном из этапов выполнения запроса после его получения сервером доставки. Этот код может быть установлен серверами доставки по истечении времени ожидания или получен от сервера оригинации.
  • Время обработки запроса (request_time). Этот показатель говорит о том, сколько времени было затрачено на обработку запроса с момента его получения. Чем меньше значение request_time, тем быстрее пользователь получил данные. Большое время обработки запросов может быть вызвано следующими факторами:
    • Проблемы на сервере оригинации. Если запрашиваемых данных не оказалось в кэше сервера доставки NGENIX или данные оказались неактуальны, сервер доставки загружает их с сервера оригинации. Высокие значения показателей upstream_response_time и request_time означают медленную загрузку данных с сервера оригинации.
    • Медленный пользователь. Если запрашиваемые данные были найдены в кэше сервера доставки, но показатель request_time высокий, это может свидетельствовать о проблемах подключения пользователя к интернету. Медленная скорость и прерывания доступа особенно актуальны для пользователей мобильных сетей.
  • Статус кэширования объекта (upstream_cache_status). Значения MISS и EXPIRED означают, что запрос не был обслужен из кэша сервера доставки. Причинами большого количества таких запросов могут быть настройки в HTTP-заголовках директив Cache-Control и/или Expires, управляющих кэшированием. В этом случае проверьте настройки HTTP-заголовков на сервере оригинации.
  • Идентификатор попытки прохождения проверки (challengeAttemptId). Этот показатель фиксируется для запросов, у которых поле rulesetTerminatingAction принимает одно из значений challenge (jsChallenge/botChallenge/captchaChallenge). Он позволяет определить, была ли проверка успешно пройдена. Для этого необходимо проанализировать лог-файлы и для каждого значения challengeAttemptId подсчитать количество запросов за 5-минутный интервал:
    • Если количество запросов с одинаковым идентификатором больше одного - проверка пройдена успешно.
    • Если за 5 минут зафиксирован только один запрос с данным идентификатором - проверка не пройдена или не проводилась.

Кэширование

  • Отсутствие запросов. Отсутствие запросов от определенного пользователя в лог-файлах свидетельствует о наличии у пользователя проблемы при обращении к данным. Необходимо проверить на стороне пользователя работу протокола DNS и убедиться в отсутствии ошибок при установке защищенного соединения TLS (HTTPS).

Как диагностировать проблемы у конечного пользователя?

При каждом HTTP-запросе к серверу оригинации серверы доставки NGENIX выставляют HTTP-заголовок X-Request-ID, содержащий соответствующий идентификатор запроса пользователя, например f20270f7aa3dacdf8e3dadf0fef54. Чтобы найти в лог-файлах Платформы соответствующий запрос пользователя к серверам доставки, используйте поиск по полю request_id.

Рекомендуем настроить логирование HTTP-заголовков на сервере оригинации. Эта информация позволяет идентифицировать IP-адреса пользователей веб-ресурса и упрощает диагностику проблем.

Правила обработки HTTP-заголовков