Кластеры Elasticsearch управляются мастер узлами, а точнее, избранным мастер узлом. Главный узел отслеживает все данные кластера, включая состояние всех остальных узлов, с помощью набора данных, который называется "состояние кластера". Состояние кластера включает в себя информацию о метаданных: узлах, индексах, шардах, распределении шардов, маппинге и настройках индексов и т.д. Вся эта информация должна быть совместно использована всеми узлами для обеспечения согласованности операций в кластере.
Кластеру Elasticsearch необходимо поддерживать состояние кластера в памяти на каждом узле, что может потребовать большого количества ресурсов. Если состояние кластера становится слишком большим, это может (в лучшем случае) привести к снижению производительности, а в худшем - к нестабильной работе кластера.
Основными причинами чрезмерно большого состояния кластера являются:
- Большое количество индексов и шардов на кластере
- Большое количество полей в индексах
- Большое количество шаблонов, некоторые из которых могут не использоваться
- Большое количество конвейеров ввода
- Большое количество хранимых скриптов
- Большие таблицы маршрутизации
В этом руководстве мы рассмотрим первые две причины большого состояния кластера: слишком большое количество шардов в кластере и чрезмерное количество полей.
Все перечисленные выше ситуации могут привести к нестабильности и снижению производительности кластера, что зачастую приводит и к увеличению затрат. Если вы хотите снизить стоимость развертывания Elasticsearch, то следующие решения могут решить возникшие проблемы, а также уменьшить необходимые ресурсы и затраты.
Слишком много шардов в кластере
Обычно это вызвано созданием большого количества мелких индексов, что также называется избыточным шардингом. Основная причина обычно связана с приложениями. Например:
- У вас много небольших ежедневных индексов
- Много мелких клиентских индексов
- Отсутствие "домашней уборки" для очистки ненужных данных.
Существуют различные способы устранения вышеописанных проблем:
Удалить или закрыть индексы
Самым быстрым способом уменьшить количество шардов и повысить производительность кластера будет выполнение команды:
| 1 2 | DELETE myindex-2014* POST myindex-2014*/_close |
Закрытие индекса освободит ресурсы памяти, используемые индексами, при сохранении индекса на диске, и легко и быстро реверсируется (POST myindex/_open).
Переиндексация маленьких индексов в большие индексы
Максимальный рекомендуемый размер шарда Elasticsearch составляет 30-50 ГБ, поэтому было бы идеально переиндексировать маленькие индексы в большие индексы, максимально приближенные к этому размеру. На практике разумным будет любой размер между 10 и 50 ГБ.
Например:
- Переиндексировать дневные индексы в месячные индексы
- Переиндексировать несколько "клиентских" индексов в один индекс для всех клиентов.
Иногда при таком типе переиндексации требуется работа с псевдонимами, чтобы обеспечить согласованность данных и исключить влияние на запросы к индексу. Подобная автоматизация может быть выполнена с помощью AutoOps - подробнее здесь.
Также можно уменьшить количество реплик до 1 или 0.
Использование ILM для оптимизации размера шардов индексов
Если у вас есть индексы, основанные на времени (например, журналы), то управление жизненным циклом индекса (Index Lifecycle Management, ILM) является очень эффективным инструментом. С помощью ILM можно:
Поддерживать оптимальный размер шардов путем автоматического создания нового индекса каждый раз, когда шард достигает оптимального размера.
Автоматически удалять индексы по достижении ими определенного возраста в соответствии с политикой хранения данных.
Если вы не используете ILM, рекомендуется отключить его. Функции мониторинга Kibana, ILM и SLM создают небольшие ежедневные индексы, которые иногда бывают пустыми. Поэтому, если в них нет необходимости, лучше отключить их, чтобы избежать создания пустых индексов.
Слишком много пустых индексов
Пустые индексы также способствуют увеличению количества шардов на кластере и увеличивают нагрузку по поддержанию состояния кластера.
Пустые индексы часто возникают из-за того, что ILM (Index lifecycle management) сворачивает индексы, поскольку они достигли определенного возраста. Например, если политика ILM определяет, что индекс должен сворачиваться каждые 30 дней, то пустой индекс будет продолжать сворачиваться в указанное время, даже если он не используется, создавая множество ненужных пустых индексов. Для решения этой проблемы необходимо убедиться, что все ненужные индексы, управляемые ILM, удалены.
Иногда приложения могут создавать ненужные индексы, которые необходимо периодически очищать. В этом случае следует рассмотреть возможность использования автоматических скриптов для обнаружения неиспользуемых пустых индексов и их регулярного удаления.
Чрезмерное количество полей в индексах
Маппинги Elasticsearch для всех индексов также хранятся в состоянии кластера. Если у вас большое количество полей (особенно если они реплицируются на большое количество индексов), то это также может увеличить нагрузку на поддержку состояния кластера. Л
Вот несколько способов избежать создания чрезмерного количества полей и решить эту проблему, если она возникла:
Отказ от динамического маппинга
Рассмотрите возможность отключения динамического маппинга в шаблонах индексов. Это можно сделать, добавив в шаблоны следующие параметры:
| 1 | dynamic: false |
Оптимизация правил динамического маппинга / Удаление многополевых маппингов
Если вы решили не отключать динамический маппинг, то рассмотрите возможность изменения правил динамического маппинга по умолчанию, чтобы не создавать несколько полей для текстовых полей. По умолчанию Elasticsearch создает для любого текстового поля как текстовое поле, так и поле для ключевого слова, что приводит к дублированию количества полей в индексе. Вы можете изменить это поведение, изменив правила динамического маппинга, как показано ниже:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | "mappings" : { "dynamic_templates" : [ { "analyzed_text_strings" : { "match_pattern" : "regex", "mapping" : { "type" : "text" }, "match_mapping_type" : "string", "match" : "description|body|title|message" } }, { "keyword_strings" : { "mapping" : { "ignore_above" : 256, "type" : "keyword" }, "match_mapping_type" : "string" } } ], |
Приведенный выше динамический шаблон применит полнотекстовый анализатор только к полям с description|body|title|message в имени поля. Все остальные строки будут индексироваться только как тип "keyword".
Данная модификация рекомендуется для новых индексов, но будьте осторожны с индексами, которые уже используются в производстве. Кроме того, следует иметь в виду, что для учета измененных имен полей потребуется модифицировать поисковые приложения и переиндексировать исторические данные, поскольку "my_field.keyword" придется заменить на "my_field" без суффикса.
Сократите количество полей в шаблонах
Часто шаблоны маппинга содержат большое количество ненужных полей, которые клиентские приложения добавляют "на всякий случай", чтобы избежать конфликта маппингов. Это особенно характерно для приложений семейства "beats", которые часто создают шаблоны, содержащие тысячи полей, чтобы охватить большое разнообразие приложений протоколирования, чтобы они работали "из коробки". Хотя это и удобно, но снижает производительность кластера, поэтому следует подумать о замене таких шаблонов собственными, содержащими сокращенные версии только тех полей, которые действительно необходимы. Это особенно важно, если у вас есть большое количество индексов, связанных с этими шаблонами.