Теперь у нас есть журналы, поступающие с уровня CloudFront , Web / App и Search в централизованное хранилище журналов в Amazon S3. В этом последнем посте из этой серии, давайте теперь посмотрим, каковы варианты на уровне хранилища с точки зрения стоимости и что делать с горами журналов.
Использование хранилища с уменьшенным резервированием
Amazon S3 имеет другой класс хранения — стандартное, хранилище с пониженным резервированием (RRS) и Glacier. По умолчанию, когда мы создаем хранилище любого объекта в Amazon S3, он хранится в классе хранения Standard. В классе хранения «Стандарт» все объекты имеют срок службы 99,99999999% и доступность объектов 99,99% в течение определенного года. С RRS Объекты, которые хранятся в S3, реплицируются в меньшем количестве мест, чтобы обеспечить долговечность 99,99% и доступность объектов 99,99% в течение данного года. RRS поставляется дешевле, чем стандартное хранилище. Если мы храним 1 ТБ файлов журналов в стандартном хранилище, это будет стоить около 95 долларов США в месяц (в стандартном регионе США). В соответствии с RRS тот же 1 ТБ хранилища будет $ 76 / месяц.
Опция RRS не может быть включена на уровне группы, а скорее на уровне отдельных объектов. Мы можем включить RRS для папок журналов, которые мы создали через свойства объекта
 |
| Включить хранилище S3 с уменьшенным резервированием |
Анализ журнала
Теперь мы можем инициировать
задания Elastic Map Reduce, чтобы обрабатывать эти файлы журналов и производить аналитику журналов. Elastic Map Reduce принимает корзину S3 в качестве местоположения источника ввода. Мы можем указать область «log» как источник ввода и предоставить EMR реализацию Map-Reduce для обработки журналов.
Годовой анализ / Многолетний анализ
Некоторые требования требуют, чтобы в конце года проводился анализ включения-выключения. Например, мы можем регулярно анализировать данные журнала ежемесячно или по запросу. А в конце года нам может потребоваться анализ данных за весь год и сравнение его с предыдущими годами. В таких случаях, если мы поддерживаем многолетние файлы журналов в S3, стоимость хранилища может быть очень высокой. И журналы предыдущего года будут доступны только один раз в год. По этим причинам мы можем заархивировать старые данные журнала в
Amazon Glacier . Amazon Glacier предоставляет недорогие услуги архивирования за 0,01 доллара США за ГБ в месяц.
Архивация на Glacier
Мы не будем хранить файлы журналов вечно. Обычно для любого приложения требуется хранить файлы журналов в течение определенного периода времени, после которого они могут быть удалены. Допустим, мы заинтересованы в том, чтобы сохранить только файлы журнала за последние 6 месяцев. И иногда мы можем проводить анализ один или три года. В таких случаях мы можем использовать установленные политики жизненного цикла в S3 для автоматического архивирования в Glacier по истечении определенного периода времени. Мы также можем поручить S3 автоматически удалять Объекты по истечении определенного периода времени.
- Нажмите на свойства корзины и перейдите на вкладку «Жизненный цикл»
- Нажмите «Добавить правило», чтобы создать новое «правило жизненного цикла»
- Укажите, что правило должно применяться ко всей корзине, и создайте правило «Переход» и «Срок действия».
- Создайте правило «Переход», указав «180» дней. Это автоматически переместит файлы из корзины S3 на ледник через 180 дней
- Создайте правило «Срок действия», указав «1095» дней. Это автоматически удалит файлы журнала с S3 или Glacier через 3 года.
 |
| Правила жизненного цикла для архивирования на ледник и удаления файлов журнала |
При этом файлы журнала будут автоматически заархивированы в Glacier через 6 месяцев (с момента создания) и будут удалены через 3 года. Как только файлы журналов архивируются в Glacier, класс хранения этих файлов журналов (объектов) в S3 изменяется на Glacier, указывая на то, что они хранятся в Glacier.
 |
| S3 Storage Class для архивных файлов |
Восстановление из ледника
Для анализа на конец года нам понадобятся архивные данные в Glacier в Amazon S3, чтобы мы могли запускать задания Elastic Map Reduce для них, чтобы получать аналитическую информацию на конец года / на несколько лет. Мы можем сделать это через Консоль управления AWS:
- Щелкните правой кнопкой мыши конкретный объект (файл журнала), класс хранения которого Glacier (что означает, что он заархивирован) и «Инициировать восстановление»
- Укажите, как долго нам требуется объект в S3 для выполнения анализа и выполнения запроса
Как только этот запрос инициирован, AWS обычно требуется около 3-4 часов для восстановления объекта из Glacier в S3. Процесс «Восстановление объекта» может быть выполнен только на уровне отдельного объекта. Обычно у нас будет большое количество файлов журналов в конце года, и сделать это практически невозможно.
Восстановление из Glacier программно
Восстановление из Glacier — это, по сути, операция S3, а не операция Glacier, как кажется. Нам нужно использовать S3 API, чтобы начать восстановление
AmazonS3 s3Client =newAmazonS3Client(newBasicAWSCredentials("aws-access-key","aws-secret-access-key"));ObjectListing listing = s3Client.listObjects(newListObjectsRequest() .withBucketName("my-global-logs") .withPrefix("web-logs/"));
Первый шаг — перечислить все ключи Объектов, которые мы хотим восстановить. Для этого используйте вызов API S3 ListObjects, чтобы получить список всех объектов. Несколько указателей при использовании этого API
- Укажите имя корзины, которое мы хотим перечислить. Также включите префикс, если мы заинтересованы в восстановлении только определенного каталога в этом сегменте. Например, если мы заинтересованы только в проведении анализа веб-журналов, а не других, мы можем указать, как указано выше
- Поскольку корзина может содержать 1000 объектов, API S3 выполняет разбиение на страницы при отправке ответа. Следовательно, используйте метод isTruncated в ответе «ObjectListing», чтобы проверить, есть ли еще объекты. Если это так, инициируйте дальнейшие вызовы API до конца списка
- Поскольку мы перечисляем весь сегмент, вызов также приведет к ключам для каталога. Что-то вроде следующего. Поэтому проверьте наличие ключа, содержащего файл, а не каталог, и продолжайте добавлять такие ключи в список (например, выполняя простую проверку «contains («. Log «)»)
веб-журналы / 2012 /
веб-журналы / 2012/12 /
веб-журналы / 2012/12/10 /
веб-журналы / 2012/12/10 / я-7a3flcd3 /
веб-журналы / 2012/12/10 / я-7a3flcd3 / tomcat.log
веб-журналы / 2012/12/10 / я-9d9dedf2 /
веб-журналы / 2012/12/10 / я-9d9dedf2 / 01 /
веб-журналы / 2012/12/10 / я-9d9dedf2 / 02 /
веб-журналы / 2012/12/10 / я-9d9dedf2 / 03 /
Как только мы получим полный список ключей объектов для восстановления, следующим шагом будет запуск процесса восстановления для всех объектов.
RestoreObjectRequest requestRestore =newRestoreObjectRequest("my-global-logs","<object-key>",<restoration-period>);
s3Client.restoreObject(requestRestore);
Как только вышеупомянутый запрос инициируется для всех Объектов, Amazon Glacier требуется около 3-5 часов, чтобы восстановить Объекты и сделать его доступным в Amazon S3. Затем мы можем запустить задания Elastic Map Reduce со всеми необходимыми данными.
Вещи, чтобы запомнить / рассмотреть
- Архивирование и восстановление являются операциями S3 и, следовательно, являются частью S3 API.
- Если у вас есть данные, хранящиеся в Glacier, которые не были заархивированы с S3, то для их восстановления вы должны использовать Glacier API для инициирования загрузок. Смотрите шаги, описанные в документации AWS для загрузки архива.
- Восстановленные объекты по умолчанию хранятся в разделе «Сокращение избыточности».
- Если у вас есть миллионы Объектов в S3, которые необходимо перенести в Glacier, помните о стоимости запросов на восстановление. Эрик Хаммонд провел здесь очень подробный анализ
- Ледник предназначен для архивного хранения. Это означает, что вы не часто получаете доступ к данным и можете ждать доступа к данным. Любой запрос на загрузку от Glacier, займет 3-5 часов, прежде чем он станет доступен. Поэтому тщательно выбирайте архивную политику. Если вы планируете часто получать данные журнала, Glacier не будет правильным выбором и окажется очень дорогим (так как он не предназначен для частого поиска)
Решения для управления журналами
Существует множество решений для управления журналами, которые доступны в качестве службы и могут быть подключены к существующим приложениям и облачной среде.
- Splunk — это широко используемое решение для управления и мониторинга журналов. Splunk можно настроить на сервере и легко настроить для начала сбора данных с веб-серверов. Также доступна версия SaaS, где сервис полностью управляется Splunk
- Loggly — еще одно облачное решение для управления журналами , которое доступно в качестве службы.
- Есть также доступные решения с открытым исходным кодом, такие как LogStash, которые могут быть настроены для наших нужд
На этом мы завершаем цикл статей о том, что я хотел охватить как часть анализа журналов с использованием S3 и Glacier. Ведение журнала является важным компонентом любой системы, и в эпоху облачных вычислений хорошее решение для управления журналами окажется полезным. Как только проблемы масштабирования и производительности будут решены с помощью облачных вычислений, ближайшей следующей потребностью любой системы будет иметь эффективный способ взглянуть на систему и проанализировать в масштабе. Решение для управления журналами определенно пригодится.