Мы переходим к s3, чтобы начать обслуживать некоторые из статически созданного контента для нашего веб-приложения. Мы изучали механизм построения метрической системы об использовании нашего сайта, и мы планировали разбор журналов доступа для S3 путем передачи дополнительной информации для регистрации в запросах контента GET. Мы прошли через следующую запись в руководстве для разработчиков:
Доставка журнала сервера Best Effort
Функция ведения журнала доступа к серверу предназначенный для наилучших усилий. Ты можешь ожидаем, что большинство запросов против ведро, которое правильно настроено для ведение журнала приведет к предоставленному журналу записи, и что большинство записей журнала будут быть доставлен в течение нескольких часов после когда они были записаны.
Однако функция ведения журнала сервера предлагаемые на оптимальной основе. полнота и своевременность работы сервера регистрация не гарантируется. Журнал запись для конкретного запроса может доставляться долго после запроса был фактически обработан, или он мог не доставляются вообще. Цель журналов сервера - дать ведро владелец идеи о характере трафика против его или ее ведра. Это не означало полный учет все запросы.
Нам интересно, что другие люди испытали в отношении доставки журналов доступа? Наша альтернатива заключается в создании HTTP-сервера и попытке самостоятельно измерить показатели с помощью другого вызова, но мы считаем, что анализ файлов журналов может оказаться меньше. Мы хотели бы знать, видели ли люди ситуации, когда доставка не состоялась, чтобы попытаться оценить, насколько точны мы можем надеяться, потому что некоторые из показателей, которые мы собираем, используются в некоторых наших бизнес-процессах.
Я был удивлен, как большие мои файлы журналов на S3 попали в течение месяца. Для моего приложения не нужно анализировать журналы на Amazon, но мне нравится ваш подход. Из того, что я видел, вы можете ожидать, что файлы журнала будут точными и полными. Основываясь на их предупреждении CYA, журналы не должны использоваться для чего-либо критического.
Мы использовали S3 для записи относительно больших объемов данных (порядка 100 М строк). Нам нужно было полагаться на журналы доступа S3 для определенной цели, и мы наблюдаем несколько проблем, которые могут быть важны для потенциальных пользователей журналов доступа:
Моя рекомендация - избегать использования журналов доступа S3, если важна точность и полнота данных.
Я знаю, что это не ответ на ваш вопрос, но...
Если ваши статические файлы не требуют какой-либо авторизации (подписанные URL-адреса для загрузки и т.д.), я не вижу хорошего варианта использования S3 для обслуживания статического контента.
Это не CDN и не предназначено для использования в качестве одного.; -)
По крайней мере, я бы рекомендовал использовать cloudfront, но IMHO это слишком дорого (и не очень хорошо работает по сравнению с другими). Я бы рекомендовал кого-то вроде edgecast или cachefly поскольку они предлагают больше за ваши деньги. \
Они также предоставляют вам (более или менее) обширные staticstics и множество приятных функций, таких как легкая очистка и аннулирование вашего кеша.