Комментарии 17
Если вкратце от себя:
Эластик может переваривать большие объемы данных на запись, индексировать их как удобно и быстро искать по ним в довольно больших выборках. Сам по себе он требует много ресурсов, потому для проектов где нет такого потока данных и с логами ничего не нужно делать он будет избыточен. Но в комбинации с кибаной и её плагинами отлично используется для создания дашбордов, для бизнес метрик, алертинга и дальнейшей обработки статистики.
Сам по себе он требует много ресурсов
Какой у вас размер индекса и какая конфигурация кластера (ноды/память/cpu)?
Спасибо за статью. Расскажите, пожалуйста, поподробней про "S3 в режимах HA". Это AWS S3? Проприетарное хранилище?
Чтобы назначить ilm на существующие индексы, достаточно сделать
curl -X PUT "localhost:9200/mylogs-pre-ilm*/_settings?pretty" -H 'Content-Type: application/json' -d'
{
"index": {
"lifecycle": {
"name": "mylogs_policy_existing"
}
}
}
'
reindex, мне кажется, overkill. Или я неправильно понял идею.
Но с такой проблемой не сталкивались совсем.
Спасибо, интересное описание.
Так же недавно отказался от куратора в пользу ilm.
Вопрос шифрования бэкапов в S3 остался за кадром, т.е. при доступе к бакету индексы становятся условно доступны/восстановимы в любом другом кластере.
Рассматривали какое-то решение, кроме шифрования силами S3?
Небольшая придирка на всякий случай:
Version 2.0.0 of Elasticdump removes the bulk options. These options were buggy, and differ between versions of Elasticsearch. If you need to export multiple indexes, look for the multielasticdump section of the tool.
Развернуть все, что было от запуска production, не представлялось возможным, т.к. в кластере банально не было столько места. К тому же, доступ к логам из бэкапа требовался уже сейчас. Решение — развернуть временный кластер, в который восстанавливается бэкап, откуда уже и достаются нужные нам логи
Допускаете ли Вы возможность, когда во временный кластер тоже не поместится такое количество снапшотов, которое Вам нужно? Вот в этом комментарии было описано решение от человека, который собирает 5Тб в день: иметь параллельно снапшоты и текстовый архив логов. Если надо восстанавливать точечно — восстанавливаешь снапшоты. Если надо искать вширь — ищешь по текстовым логам. Мы попробовали, — это работает. Только у нас уже было много старых снапшотов, поэтому пришлось использовать отдельный конвертер снапшотов в текст. 60Тб снапшотов конвертировали в 3Тб зазипованных JSON, и в них вполне можно искать определенные нужные вещи за пару лет назад. Не так замечательно как в Эластике, но в [наш] временный кластер по любому 2 года снапшотов не влезает.
Как мы Elasticsearch в порядок приводили: разделение данных, очистка, бэкапы