Как стать автором
Обновить

Как мы Elasticsearch в порядок приводили: разделение данных, очистка, бэкапы

Время на прочтение8 мин
Количество просмотров31K
Всего голосов 35: ↑34 и ↓1+45
Комментарии17

Комментарии 17

Материал интересный, но может кто нибудь пожалуйста объяснить зачем хранить логи в базах типо эластика?
Парсинг на лету, индексация, быстрые отчеты. У нас еще оттуда заббикс дергает данные постфактум и смотрит на предмет косяков.
Kibana — удобный инструмент для их последующего анализа, построения графиков по определённым поискам и т.п. Опять же можно экспортировать отдельные выборки в метрики для прометеуса / графаны.

Логи из эластика теперь можно и в самой графане смотреть. И сразу же графики по запросам строить.
Если поподробней, то у нас уже была некоторая обзорная статья с тем что мы используем для сбора логов и почему habr.com/ru/company/flant/blog/480946
Если вкратце от себя:
Эластик может переваривать большие объемы данных на запись, индексировать их как удобно и быстро искать по ним в довольно больших выборках. Сам по себе он требует много ресурсов, потому для проектов где нет такого потока данных и с логами ничего не нужно делать он будет избыточен. Но в комбинации с кибаной и её плагинами отлично используется для создания дашбордов, для бизнес метрик, алертинга и дальнейшей обработки статистики.
Сам по себе он требует много ресурсов

Какой у вас размер индекса и какая конфигурация кластера (ноды/память/cpu)?
Не могу сказать в общем по компании, т.к. Эластиков много, но конкретно в этом случае размеры индексов есть на скриншотах в статье.
За основу статьи брался 3 нодовый Эластик, каждая нода 16CPU 32RAM

Спасибо за статью. Расскажите, пожалуйста, поподробней про "S3 в режимах HA". Это AWS S3? Проприетарное хранилище?

В зависимости от платформы где развёрнут проект. Пользуемся и S3 в облаках (в том числе и AWS), и Сeph S3 или Minio для bare-metal.

Чтобы назначить 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?

В данном случае мы обходимся разными access/secret key для кластеров и бакетов и политикой доступа. Само 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 года снапшотов не влезает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий