Мы планируем долгосрочную миграцию в сторону облака. План состоит в том, чтобы начать с малого и постепенно перемещать менее важные части инфраструктуры в облако. Пока все хорошо.
Часть этой миграции включает файлы журналов с веб-серверов и т. Д. Имейте в виду, что серверы по-прежнему находятся в центрах обработки данных за пределами облака. Должно быть легко иметь задание cron собирать файлы журналов в конце каждого дня, сжимать их и загружать в Amazon S3 с возможным резервным копированием в Glacier. Это легко.
Проблема возникает, когда S3 является только место, где вы храните журналы и хотите искать в журналах различные события. Если вы не знаете временной интервал, вам, возможно, придется загрузить все журналы из S3 для всестороннего поиска, и это окажется дорого - перенос ваших данных в облако дешево, получить оттуда - дорого.
Или я мог бы настроить шаблон экземпляра EC2. Когда кто-то хочет выполнить поиск в журнале, запустите экземпляр, загрузите в него журналы с S3 и удалите grep. Загрузка файлов из S3 в EC2 стоит недорого. Но загрузка может занять некоторое время; Кроме того, если вы не знаете, что ищете, вам нужно загрузить много журналов, что означает использование большого количества места в EBS.
Другой способ - загрузить логи в DynamoDB или что-то в этом роде. Цена может быть проблемой. Другая проблема заключается в том, что журналы представляют собой полностью неструктурированные журналы Apache, Squid и т.п., и поэтому запросы могут занять очень много времени.
Мы говорим о 500 ГБ сжатых журналов в год, срок хранения до 5 лет.
Для меня хранение журналов в облаке кажется не очень хорошей идеей. Можно просто использовать Glacier в качестве «резервной копии на магнитной ленте», но пока храните журналы локально, на паре жестких дисков.
В какую сторону вы наклоняетесь?
Logstash + ElasticSearch + Kibana. Это та комбинация, которая вам нужна.
Похоже, вы смотрите в сторону AWS, поэтому создайте для этого скромный кластер EC2 - возможно, один блок logstash «маршрутизатор / брокер» и два узла кластера Elasticsearch.
Поддерживайте разумный объем данных «в сети» в индексах ES, а затем архивируйте старые индексы в S3. ElasticSearch поддерживает это прямо из коробки и может (относительно легко) экспортировать и импортировать данные из S3.
Что касается получения журналов до EC2, я бы просто использовал туннель IPsec от ваших серверов с собственным хостом к кластеру EC2 и отправлял журналы, используя любой протокол, который вы хотите. Logstash имеет широкую поддержку множества форматов ввода.
Как насчет запуска splunk-сервера в облаке, постоянно поддерживать его на небольшом экземпляре, можно использовать тома EBS или даже попробовать тома S3, если ввод-вывод не становится узким местом.
Мы запустили службу управления облачным журналом (slicklog.com), которая может решить ваши проблемы. Когда ваши журналы прибывают на платформу,
По прошествии периода времени (минимум 1 месяц), настраиваемого через пользовательский интерфейс, журналы архивируются (0,001 USD / ГБ без сжатия), когда журналы архивируются.
Учитывая ваши требования, это можно было бы считать решением, если бы вы могли смириться с тем фактом, что файлы архивных журналов недоступны для поиска.
Надеюсь это поможет.