Лог-файлы
В этой статье описывается принцип логирования на Платформе, формат лог-файлов, а также советы по самодиагностики проблем, на базе лог-файлов Платформы.
Лог-файлы содержат информацию о запросах пользователей к Платформе и используются при формировании статистики и аналитических отчетов.
pageСтатистика и аналитикаВы можете получить доступ к содержимому лог-файлов двумя способами:
Получить доступ к лог-файлам на серверах хранения по протоколу FTP. Эта возможность предоставляется в рамках сервиса Raw Access Logs.
Получать логи с Платформы в режиме реального времени по протоколу Syslog. Эта возможность предоставляется в рамках сервиса Real-time Logs Streaming.
Формат лог-файлов
Каждому обработанному Платформой пользовательскому запросу в лог-файле соответствует строка следующего вида:
$remote_addr $host [$time_local] "$request" $status $upstream_cache_status "$upstream_addr" $body_bytes_sent "$http_referer" "$http_user_agent" "$request_time" "$gzip_ratio" "$ssl_protocol/$ssl_cipher" "$connection_requests/$connection" $bytes_sent "$upstream_response_length" "$upstream_header_time" "$upstream_response_time" "$upstream_status" $geoip_country_code $request_id $server_port
где:
remote_addr – IP-адрес источника запроса;
host – значение заголовка Host в запросе;
time_local – время запроса (GMT);
request – первоначальная строка запроса целиком;
status – HTTP-код ответа;
upstream_cache_status – статус объекта, например, HIT для объекта, отданного из кэша, или MISS для объекта запрошенного с сервера оригинации;
upstream_addr – адрес сервера оригинации, в случае если объект отсутствует к кэше;
body_bytes_sent – размер тела HTTP-запроса (указывается в байтах);
http_referer – значение заголовка Referer;
http_user_agent — значение заголовка User-Agent;
request_time — время обработки запроса в секундах с точностью до миллисекунд; время, прошедшее с момента чтения первых байт от клиента до момента записи в лог после отправки последних байт клиенту;
gzip_ratio — степень сжатия (отношение размеров объекта от сервера оригинации к размеру объекта отданного пользователю с Платформы);
ssl_protocol/ssl_cipher — версия SSL/SSL-шифр в случае, если используется защищенное соединение;
connection_requests/connection – порядковый номер запроса в рамках установленного соединения/порядковый номер соединения;
bytes_sent – полное количество переданных байт (с учетом HTTP-заголовков);
upstream_response_length – размер полученного ответа с сервера оригинации;
upstream_header_time — время получения заголовков ответа с сервера оригинации;
upstream_response_time — время получения всего объекта с сервера оригинации;
upstream_status – HTTP-код ответа от сервера оригинации;
geoip_country_code — двухбуквенный код страны, которой принадлежит IP-адрес пользователя;
request_id — уникальный идентификатор запроса пользователя;
server_port — порт сервера, обработавшего запрос.
Рекомендации для самостоятельной диагностики
При анализе лог-файлов обращайте внимание на следующие показатели:
HTTP-код ответа (HTTP status code). Коды ответа из диапазонов 400-499 и 500-599 свидетельствуют о проблемах получения данных конечными пользователями. Например, код ответа 404 возникает когда пользователь запросил несуществующий объект, а код ответа 503 обычно возникает, когда сервер перегружен. В этих случаях необходимо обратить внимание на поле upstream_status. Если это поле не пустое, ошибка была получена с сервера оригинации. Пустое поле 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-заголовков на сервере оригинации.
Отсутствие запросов. Отсутствие запросов от определенного пользователя в лог-файлах свидетельствует о наличии у пользователя проблемы при обращении к данным. Необходимо проверить на стороне пользователя работу протокола DNS и убедиться в отсутствии ошибок при установке защищенного соединения TLS (HTTPS).
При каждом HTTP-запросе к серверу оригинации серверы доставки NGENIX выставляют HTTP-заголовок X-Request-ID, содержащий соответствующий идентификатор запроса пользователя, например f20270f7aa3dacdf8e3dadf0fef54.Чтобы найти в лог-файлах Платформы соответствующий запрос пользователя к серверам доставки, используйте поиск по полю request_id.
Рекомендуем настроить логирование HTTP-заголовков на сервере оригинации. Эта информация позволяет идентифицировать IP-адреса пользователей веб-ресурса и упрощает диагностику проблем.