У нас есть развертывание ELK (ElasticSearch-Logstash-Kibana), в котором мы отправляем журналы через logstash в Elasticsearch Cluster. Индексы создаются ежедневно. Мы закрываем индексы возрастом более 3 дней, делаем снимок индексов возрастом более 7 дней и отправляем их в Amazon S3 через куратора.
У нас есть около 10 различных ежедневных индексов, где средний размер каждого индекса около 1 ГБ. Фактор репликации 1. Каждый индекс имеет 2 шарда. Logstash отправляет данные в кластер ES со скоростью 2000 log_events в секунду.
Наша топология
Конфигурации оборудования
Вся стандартная конфигурация соблюдалась как одноадресный режим в обнаружении, было выделено 30 ГБ ОЗУ.
Прямо сейчас задание моментального снимка запускается через куратора с клиентского компьютера, а запросы отправляются локально экземпляру ES, запущенному на клиентском компьютере. Logstash отправляет журналы прямо на клиентский узел
Используемая команда куратора: -
curator --timeout 21600 --host es-client --port 9200 snapshot --name $snapshot_name_$project-$date --repository walle_elk_archive indices --older-than 3 --time-unit days --timestring %Y-%m-%d --prefix $prefix
Может ли кто-нибудь помочь мне в следующем: -
Можно ли запустить кураторскую работу на клиентской машине, как это сделали мы?
Да, поскольку «клиентская» машина не делает ничего, кроме запуска запросов REST в вашем кластере ES и ожидания ответа.
Можно ли сделать снимок всех индексов с одной машины?
Опять же, да. По той же причине, что и первый вопрос.
Поскольку журналы отправляются непрерывно, приведет ли это к нестабильности кластера при создании моментальных снимков и отправке их в Amazon S3?
Согласно документам ES на Снимок и восстановление
Snapshotting process is executed in non-blocking fashion. All indexing and searching
operation can continue to be executed against the index that is being snapshotted.
Возможно небольшое замедление скорости индексации, но, исходя из технических характеристик вашей машины, я думаю, что все будет хорошо, но на самом деле нет способа узнать, если вы не попробуете. Фактором, ограничивающим скорость моментального снимка, скорее всего, будут диски для общего репозитория файловой системы и скорость вашего интернет-соединения для репозиториев S3.
С точки зрения использования репозитория S3 и того, как это влияет на процесс, не так много деталей (например, нет) в документы для плагина S3 Repository о том, как он на самом деле работает. Я подозреваю, что каждый узел данных, содержащий первичный осколок, отправит его осколки в репозиторий, S3 или иначе. Это означает, что при выполнении моментальных снимков в репозиторий S3, вероятно, не будет большей нагрузки на кластер ES, чем на общий репозиторий файловой системы.
Очередной раз, ПОПРОБУЙ ЭТО, поскольку каждая среда уникальна, и то, что работает для одного человека, может не работать для другого.
Какие передовые практики обычно используют люди для резервного копирования старых индексов из Elasticearch?
Я считаю, что у ES есть неплохая документация, и есть раздел о Снимок и восстановление. На самом деле там не так много "лучших" практик, поэтому, если вы не встретите какие-либо другие источники в Интернете, я бы сказал, что лучше всего просто начать пробовать что-то, чтобы увидеть, что работает для вас.