Лог-файлы¶
Лог-файлы содержат информацию о запросах пользователей к Платформе и используются при формировании статистики и аналитических отчетов.
Вы можете получить доступ к содержимому Лог-файлов на Платформе двумя способами:
- Включить выгрузку лог-файлов на серверы хранения с доступом по S3 и задать время их хранения. Лог-файлы будут выгружаться на серверы хранения раз в час. Опция настраивается одновременно для всех Сервисных конфигураций в составе Аккаунта.
- Получать логи серверов доставки в режиме реального времени по протоколу 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-адреса пользователей веб-ресурса и упрощает диагностику проблем.