Насколько надежны файлы журнала доступа amazon s3?

Question

Мы переходим на s3, чтобы начать предоставлять статически сгенерированный контент для нашего веб-приложения.Мы искали механизм для построения системы показателей использования нашего сайта и планировали анализ журналов доступа для S3, передавая дополнительную информацию для регистрации по GET-запросам контента.Мы столкнулись со следующей записью в руководстве для разработчиков :

Лучшая доставка журнала сервера Effort

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

Однако, функция регистрации на сервере предлагается с максимальной отдачей.Полнота и своевременность регистрации сервера не гарантируется.Запись в журнале для конкретного запроса может быть доставлена ​​задолго до того, как запрос был фактически обработан, или он может вообще не быть доставлен.Цель журналов сервера - дать владельцу корзины представление о характере трафика против его или ее корзины.Это не означает полный учет всех запросов.

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

Answer 1

Я был удивлен, насколько большими стали мои файлы журналов на S3 менее чем за месяц. Моему приложению не нужно было разбирать логи на Amazon, но мне нравится ваш подход. Из того, что я видел, вы можете ожидать, что файлы журналов будут точными и полными. На основании их предупреждения CYA журналы не должны использоваться для чего-либо критического.

Answer 2

Мы использовали S3 для регистрации относительно больших объемов данных (порядка 100 миллионов строк). Нам нужно было полагаться на журналы доступа S3 для конкретной цели, и мы наблюдаем несколько вопросов, которые могут быть важны для потенциальных пользователей журналов доступа:

• Мы видим (несколько) записей в журнале, которые появляются спустя много дней после их создания
• Мы видим повторяющиеся записи, регистрирующие одну транзакцию S3 (в настоящее время расследуется)
• Также, кажется, бывают случаи, когда запись в журнале фактически не создается (в настоящее время расследуется)

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

Answer 3

Я знаю, что это не ответ на ваш вопрос, но ...

Если ваши статические файлы не требуют какой-либо авторизации (подписанные URL для загрузки и т. Д.), Я не вижу хорошего варианта использованияиспользовать S3 для обслуживания статического контента.

Это не CDN и не предназначен для использования в качестве одного.; -)

По крайней мере, я бы порекомендовал использовать cloudfront, но ИМХО это слишком дорого (и не очень хорошо работает по сравнению с другими).Я бы порекомендовал кого-то вроде edgecast или cachefly , поскольку они предлагают больше за ваши деньги. \

Они также предоставляют вам (более или менее) обширные статические имножество полезных функций, таких как простая очистка и аннулирование вашего кэша.