У нас есть кластер ElasticSearch с 4 узлами данных: каждый узел имеет 4 ядра, 16 ГБ ОЗУ и 160 ГБ хранилища (в кластере есть отдельные выделенные главные узлы). Кластер отвечает за хранение и представление (с помощью Kibana) ряда различных журналов для различных клиентов и сервисов, которые мы поддерживаем в dev / test / prod.
Мы пытаемся разработать лучший подход к индексации данных. Наша цель - сохранить разделение данных на самом низком допустимом уровне, чтобы мы могли легко управлять (т. Е. Архивировать, удалять и т. Д.) Каждой клиентской средой с разной продолжительностью хранения в зависимости от значения данных.
Мы уже знаем, что хотим индексировать по дате, но как мы можем быть более детальными, прежде чем простой подсчет индекса станет громоздким? Например, разумно ли logstash- {client} - {environment} - {date}? Будет ли у нас слишком много индексов?
Масштабирование ES для LogStash - сложная проблема, особенно для случаев с очень разными интервалами хранения. Для масштабирования ES есть две большие ручки, которые можно повернуть:
Количество полей масштабирует требования Java HEAP ко всему. Я слышал ужасные истории о людях, разрешающих вводить данные в формате JSON, которые приводят к таким событиям:
http.192-168-82-19.request = "GET /"
http.192-168-82-19.verb = "GET"
http.192-168-82-19.path = "/"
http.192-168-82-19.response_time = 12022
И так далее. Как вы могли догадаться, это дает поразительно большое количество полей в каталоге. Им потребовалось много времени, чтобы выкопать эту яму, поэтому обратите внимание на вводимые данные и постарайтесь не войти в нее. Для мультиклиентской архитектуры, такой как ваша, рекомендуется осуществлять контроль изменений в полях, разрешенных в ваших индексах; вы будете счастливее от этого.
Количество шардов снова масштабирует Java HEAP, а также время восстановления при отказе узла. 8 ТБ в 30 шардах восстанавливаются иначе, чем 8 ТБ в 300. Как правило, чем меньше, тем лучше, но это зависит от вашей оперативной памяти.
Один из показателей, который я использую для определения правильности размера кластера ElasticSearch, - это то, насколько проблематично его обслуживать. Если я в облако и мой метод исправления состоит в том, чтобы создать новый базовый образ и развернуть новую виртуальную машину, я буду очень обеспокоен тем, сколько времени потребуется, чтобы заполнить этот новый экземпляр данными. В этом случае я с большей вероятностью добавлю узлы данных, чтобы полностью сократить время восстановления по причинам технического обслуживания. Если я нахожусь на реальных серверах, и мой метод исправления заключается в перезагрузке компьютера и продолжении работы, восстановление в полном объеме происходит гораздо реже, поэтому меня меньше беспокоит несколько ТБ данных на моих узлах данных. Только вы можете решить, где здесь ваша болевая точка.
В новых версиях ElasticSearch (в частности, в серии 5.x) есть функция переиндексации, которая может быть чрезвычайно полезна для таких случаев, как ваш, особенно в сочетании с Curator. Как только ваши индексы устареют до определенного момента, когда они сохраняются только в целях соблюдения требований, вы можете переиндексировать дневные индексы за неделю в один недельный. Это превращает 70 сегментов (2 реплики * 5 разделов * 7 дней) в 10 сегментов за счет замедления поиска на этой неделе.
Такие вещи могут быть очень сложными для ваших серверов, поэтому это может быть неправильный выбор. Но это метод, который позволит вам запустить «архивный» кластер серверов ES с их собственными периодами хранения и запросов.