Elasticsearch In Production - лучшие практики развертывания

Elasticsearch - высоко оптимизированная поисковая система для современной аналитики данных.

Elasticsearch - удивительный поисковый и аналитический движок в реальном времени. Он построен на Apache Lucene. Он распространяется, RESTful, его легко начать использовать и он очень доступен. Примеры использования Elasticsearch включают в себя поиск, мониторинг транзакций и обнаружение ошибок, обнаружение контента, аналитику журналов, нечеткий поиск, агрегацию данных о событиях, визуализацию данных. Elasticsearch и остальная часть Elastic Stack оказались чрезвычайно универсальными, и, как вы можете видеть выше, варианты использования, есть несколько способов интегрировать Elasticsearch в то, что ваш продукт доставляет сегодня, и добавить дополнительную информацию о нем.

Мы активно используем его для поиска и аналитики в Botmetric, индексируем около миллиарда документов в день и используем очень сложные агрегации для визуализации данных в реальном времени.

Тем не менее, самозагрузка приложения против его запуска в производстве и обслуживании совершенно разные. Эта статья охватывает многие из этих факторов из опыта реальной жизни и является основными общими элементами, которые следует учитывать при запуске Elasticsearch в производстве.

Объем памяти:

Elasticsearch и Lucene написаны на Java, что означает, что вы должны следить за статистикой пространства кучи и JVM. Чем больше кучи доступно для Elasticsearch, тем больше памяти он может использовать для фильтрации и другого кэширования для повышения производительности запросов. Но учтите, что слишком большая куча может привести к длительным паузам сборки мусора. Не устанавливайте Xmx выше предела, который JVM использует для указателей сжатых объектов (сжатых упс); Точное ограничение варьируется, но составляет около 32 ГБ.

Распространенной проблемой является настройка слишком большой кучи. У вас есть машина на 64 ГБ - и, черт возьми, вы хотите выделить Elasticsearch все 64 ГБ памяти. Чем больше, тем лучше! Куча определенно важна для Elasticsearch. Он используется многими структурами данных в памяти для обеспечения быстрой работы. Но с учетом вышесказанного, есть еще один крупный пользователь памяти, который находится вне кучи: кеш файлов ОС.

Lucene предназначен для использования базовой ОС для кэширования структур данных в памяти. Сегменты Lucene хранятся в отдельных файлах. Поскольку сегменты являются неизменяемыми, эти файлы никогда не изменяются. Это делает их очень дружественными к кешу, и базовая ОС с удовольствием сохранит горячие сегменты, размещенные в памяти, для более быстрого доступа Эти сегменты включают в себя как инвертированный индекс (для полнотекстового поиска), так и значения документа (для агрегации). Производительность Lucene зависит от этого взаимодействия с ОС. Но если вы предоставите всю доступную память для кучи Elasticsearch, кеша файлов ОС не останется. Это может серьезно повлиять на производительность. Стандартная рекомендация - выделить 50% доступной памяти для кучи Elasticsearch, оставив остальные 50% свободными. Это не останется неиспользованным; Lucene с радостью использует все, что осталось для файлового кэша. Elasticsearch heap можно настроить следующими способами,

экспорт ES_HEAP_SIZE = 10 г

или

ES_JAVA_OPTS = "- Xms10g -Xmx10g" ./bin/elasticsearch

ПРОЦЕССОР:

Elasticsearch поддерживает агрегации и отфильтрованные запросы. Для выполнения сложных отфильтрованных запросов, интенсивной индексации, фильтрации и запросов к индексам требуется значительная загрузка ЦП, поэтому выбор правильного запроса крайне важен. Нужно понимать спецификации процессора и то, как они ведут себя с Java, когда запросы выполняются на JVM.

Каждый пул запускает несколько потоков, которые можно настроить, и имеет очередь. Изменять это не рекомендуется, если у вас нет особых требований, поскольку Elasticsearch выполняет распределение ядер динамически.

Типы пула потоков:

Elasticsearch имеет 3 типа потоков потоков.

  1. Кэшированный: Кэшированный пул потоков - это неограниченный пул потоков, который будет порождать поток при наличии ожидающих запросов. Этот пул потоков используется для предотвращения блокировки или отклонения запросов, отправленных в этот пул. Неиспользуемые потоки в этом пуле потоков будут прерваны после истечения срока действия поддержки (по умолчанию пять минут). Пул кэшированных потоков зарезервирован для общего пула потоков.
  2. Исправлено: Фиксированный пул потоков содержит фиксированный размер потоков для обработки запросов с очередью (необязательно ограниченной) для ожидающих запросов, у которых нет потоков для их обслуживания. Параметр size управляет количеством потоков и по умолчанию равен числу ядер, умноженному на 5.
  3. Масштабирование. Масштабируемый пул потоков содержит динамическое число потоков. Это число пропорционально рабочей нагрузке и варьируется от 1 до значения параметра размера.

Elasticsearch делит использование процессора на пулы потоков различных типов:

  • универсальный: для стандартных операций, таких как обнаружение и тип пула потоков, кэшируется.
  • index: для операций индексации / удаления. Тип пула потоков фиксированный.
  • поиск: для подсчета / поисковых операций. Тип пула потоков фиксированный.
  • get: для операций get. Тип пула потоков фиксированный.
  • массовая: для массовых операций, таких как массовая индексация. Тип пула потоков фиксированный. Наилучшая конфигурация массовых документов зависит от конфигурации кластера, это можно определить, опробовав несколько значений.
  • перколят: для перколяции. Тип пула потоков фиксированный.
  • refresh: для операций обновления. Тип пула потоков - масштабируемый.

Изменение определенного пула потоков может быть сделано путем установки его специфичных для типа параметров.

Прочитайте больше https://www.elastic.co/guide/en/elasticsearch/reference/2.2/modules-threadpool.html#types

Размер осколка:

Осколок - это единица, в которой Elasticsearch распределяет данные внутри кластера. Скорость, с которой Elasticsearch может перемещать осколки при перебалансировке данных, например, После сбоя будет зависеть размер и количество сегментов, а также производительность сети и диска.

В Elasticsearch каждый запрос выполняется в одном потоке для каждого шарда. Однако несколько сегментов могут обрабатываться параллельно, равно как и несколько запросов и агрегатов к одному фрагменту.

Это означает, что минимальная задержка запроса при отсутствии кэширования будет зависеть от данных, типа запроса, а также от размера сегмента. Запросы большого количества маленьких осколков ускорят обработку каждого осколка, но, поскольку нужно поставить в очередь и обработать намного больше задач, это не обязательно будет быстрее, чем запрос меньшего количества больших осколков. Наличие большого количества маленьких сегментов может также уменьшить пропускную способность запроса, если существует несколько одновременных запросов.

Каждый осколок имеет данные, которые должны храниться в памяти, и использует пространство кучи. Это включает в себя структуры данных, хранящие информацию на уровне сегмента, а также на уровне сегмента, чтобы определить, где данные находятся на диске. Размер этих структур данных не фиксирован и будет варьироваться в зависимости от варианта использования. Однако важной характеристикой накладных расходов, связанных с сегментом, является то, что они не строго пропорциональны размеру сегмента. Это означает, что большие сегменты имеют меньше накладных расходов на объем данных по сравнению с меньшими сегментами. Разница может быть существенной. Выбор правильного количества шардов является сложным, потому что вы никогда не знаете, сколько документов вы получите, прежде чем начать. Наличие большого количества осколков может быть как хорошим, так и ужасным для группы. Управление индексами и осколками может привести к перегрузке главного узла, что может привести к отсутствию ответа, что может привести к странному и неприятному поведению. Выделите ваши главные узлы достаточно ресурсов, чтобы справиться с размером кластера.

Плохо то, что количество шардов является неизменным и определяется при создании индекса. После создания индекса единственный способ изменить количество сегментов - это удалить ваши индексы, создать их заново и переиндексировать.

копирование

Elasticsearch поддерживает репликацию, данные реплицируются между узлами данных, поэтому потеря узла не приведет к потере данных. По умолчанию коэффициент репликации равен 1, но в зависимости от требований вашего продукта он может быть увеличен. Чем больше реплик, тем более устойчивыми к стихийным бедствиям будут ваши данные. Другое преимущество наличия большего количества реплик состоит в том, что каждый узел содержит осколок реплики, что повышает производительность запросов, поскольку реплики также используются для запросов.

Формула репликации, используемая Elasticsearch для согласованности,

(основной + number_of_replicas) / 2 + 1

Оптимизация размещения

Основываясь на требованиях к данным о продукте, мы можем классифицировать данные по горячим и холодным. Индексы, к которым обращаются чаще других, могут быть распределены большему количеству узлов данных, в то время как индексы, к которым обращаются реже, индексы могут иметь меньше выделенных ресурсов. Эта стратегия особенно полезна для хранения данных временных рядов, таких как журналы приложений (например, ELK).

Это может быть достигнуто путем запуска cronjob, который перемещает индексы в разные узлы через равные промежутки времени.

Горячий узел - это тип данных, узел выполняет всю индексацию внутри кластера. Они также содержат самые последние индексы, так как они, как правило, чаще всего запрашиваются. Поскольку индексирование требует интенсивной работы процессора и ввода-вывода, эти серверы должны быть мощными и поддерживаться подключенным хранилищем SSD. Мы рекомендуем использовать минимум 3 горячих узла для обеспечения высокой доступности. Однако, в зависимости от количества последних данных, которые вы хотите собрать и запросить, вам может потребоваться увеличить это число для достижения ваших целей производительности.

Теплый узел - это тип узла данных, предназначенный для обработки большого количества индексов только для чтения, которые с меньшей вероятностью будут часто запрашиваться. Поскольку эти индексы предназначены только для чтения, теплые узлы, как правило, используют большие подключенные диски (обычно вращающиеся диски) вместо твердотельных накопителей. Как и в случае с горячим узлом, мы рекомендуем минимум 3 теплых узла для обеспечения высокой доступности. И, как и прежде, с оговоркой, что для больших объемов данных могут потребоваться дополнительные узлы для удовлетворения требований к производительности. Также обратите внимание, что конфигурации процессора и памяти часто должны отражать конфигурации ваших горячих узлов. Это можно определить только путем тестирования с запросами, аналогичными тем, которые вы испытывали бы в производственной ситуации.

Подробнее о горячем и теплом узле можно узнать здесь.

Другая стратегия, которую вы можете адаптировать, - это архивирование индексов в s3 и восстановление, когда вам нужны данные из этих индексов. Вы можете прочитать больше об этом здесь.

Топология узла:

Узлы Elasticsearch можно разделить на три категории: главный узел, узел данных, клиентский узел.

  1. Главный узел: Главный узел может быть небольшим, если он также не является узлом данных, так как он не хранит никаких индексов / сегментов. Его обязанность - хранить подробное состояние кластера и помогать данным и другим узлам в поиске метаданных индексов / сегментов. Elasticsearch должен иметь несколько мастер-узлов, чтобы избежать проблем с разделенным мозгом.
  2. Узел данных: узел данных отвечает за хранение / запрос фактических данных индекса.
  3. Клиентский узел: клиентский узел используется в качестве прокси для индексации и поиска. Это настоятельно рекомендуется, если агрегации интенсивно используются. Это специальные узлы ElasticSearch, которые не подходят ни для данных, ни для основных. Клиентские узлы осведомлены о кластерах и поэтому могут выступать в качестве интеллектуальных балансировщиков нагрузки Вы можете отправлять свои запросы на клиентские узлы, которые затем могут взять на себя дорогостоящую задачу сбора ответов на результаты запроса от каждого из узлов данных.

добавьте эти настройки в файлasticsearch.yml для соответствующих узлов.

Главный узел: узел.мастер: правда. Узел.данные: ложь
Узел данных: node.master: false node.data:true
Клиентский узел: node.master: false node.data:false

Советы по устранению неполадок:

Производительность Elasticsearch сильно зависит от машины, на которой он установлен. ЦП, использование памяти и дисковый ввод-вывод являются основными показателями операционной системы для каждого узла Elasticsearch. Рекомендуется просматривать показатели виртуальной машины Java (JVM) при скачках загрузки ЦП. В следующем примере причиной всплеска была более высокая активность сбора мусора.

  1. Давление кучи. Высокое давление памяти влияет на производительность кластера двумя способами: поскольку давление памяти возрастает до 75% и выше, остается меньше доступной памяти, и теперь вашему кластеру также необходимо потратить некоторые ресурсы ЦП для восстановления памяти посредством сбора мусора. Эти циклы ЦП недоступны для обработки пользовательских запросов, когда включена сборка мусора. В результате время отклика для пользовательских запросов увеличивается, поскольку система становится все более и более ограниченной в ресурсах. Если давление памяти продолжает расти и достигает почти 100%, используется гораздо более агрессивная форма сборки мусора, что, в свою очередь, существенно повлияет на время отклика кластера. Показатель времени отклика индекса показывает, что высокое давление памяти приводит к значительному снижению производительности.
  2. Рост памяти без кучи JVM, поглощение памяти, предназначенной для кэширования страниц, и, возможно, повторное получение OOM на уровне ядра.
  3. Избегайте проблем с расщепленным мозгом. Расщепленный мозг - это сценарий, где кластер распадается. Например, у вас есть 6 узлов кластера. 2 узла отключаются от кластера, но они все еще могут видеть друг друга. Эти 2 узла затем создают еще один кластер. Они даже выберут нового хозяина между собой. Теперь у нас есть два кластера с одинаковым именем, один с 4 узлами, а другой с 2 ​​узлами. У каждого тоже есть мастер-узел. Это то, что называется проблемой разделения мозга с кластерами ES. Чтобы избежать этого, установите параметр ES discovery.zen.minimum_master_nodes равным половине числа узлов + 1.
  4. Поскольку Elasticsearch интенсивно использует запоминающие устройства, мониторинг дискового ввода-вывода обеспечивает выполнение этой базовой потребности. Есть много причин для уменьшения дискового ввода-вывода, это считается ключевым показателем для прогнозирования многих видов проблем. Это хороший показатель для проверки эффективности индексации и производительности запросов. Анализ операций чтения и записи напрямую указывает на то, что системе больше всего нужно в конкретном случае использования. Настройки операционной системы для дискового ввода-вывода являются основой для всех других оптимизаций, настройка дискового ввода-вывода может избежать потенциальных проблем. Если дискового ввода-вывода все еще недостаточно, такие контрмеры, как оптимизация количества сегментов и их размера, регулирование слияния, замена медленных дисков, переход на SSD или добавление дополнительных узлов, должны оцениваться в соответствии с обстоятельствами, вызывающими ввод-вывод. узкие места.
  5. Для приложений, которые полагаются на поиск, взаимодействие с пользователем тесно связано с задержкой поисковых запросов. Есть много вещей, которые могут повлиять на производительность запроса, например, построенные запросы, неправильно настроенный кластер Elasticsearch, проблемы с памятью JVM и сборкой мусора, дисковый ввод-вывод и так далее. Задержка запроса - это показатель, который напрямую влияет на пользователей, поэтому убедитесь, что вы поместили в него несколько предупреждений.
  6. Большинство фильтров в Elasticsearch кэшируются по умолчанию. Это означает, что во время первого выполнения фильтрованного запроса Elasticsearch найдет документы, соответствующие фильтру, и построит структуру, называемую «набор битов», используя эту информацию. Данные, хранящиеся в наборе битов, содержат идентификатор документа и соответствует ли данный документ фильтру. Последующее выполнение запросов, имеющих один и тот же фильтр, будет повторно использовать информацию, хранящуюся в наборе битов, тем самым ускоряя выполнение запроса, сохраняя операции ввода-вывода и циклы ЦП. Рекомендуется использовать фильтр в запросе. Для более подробной информации обратитесь сюда.
  7. Время обновления и время объединения тесно связаны с производительностью индексации, а также влияют на общую производительность кластера. Время обновления увеличивается с увеличением количества файловых операций для индекса Lucene (осколок).
  8. Включение медленной регистрации запросов поможет определить, какие запросы являются медленными и что можно сделать, чтобы улучшить их, что особенно полезно для подстановочных запросов.
  9. Увеличьте размер ulimit, чтобы разрешить максимальное количество файлов.
  10. Производительность ElasticSearch может снизиться, когда ОС решит выгрузить неиспользуемую память приложения. Отключите подкачку, установив параметры уровня ОС или установив следующее в конфигурации ElasticSearch bootstrap.mlockall: true
  11. Отключить удаление всех индексов по шаблону запроса. Чтобы гарантировать, что кто-то не выполнит операцию DELETE для всех индексов (* или _all), установите для action.destructive_requires_name значение true.

Перед тем, как закончить, вот список URL, которые полезны для просмотра метрик.

  • / _cluster / health? pretty: Для индикатора состояния кластера.
  • / _status? pretty: Для получения всей информации обо всех индексах.
  • / _nodes? pretty: Для всей информации об узлах.
  • / _cat / master? pretty: для главного узла.
  • / _stats? pretty: для распределения осколков, статистика индексов.
  • / _nodes / stats? pretty: Для статистики отдельных узлов это включает в себя статистику jvm, http, io для узла.

Агрегирование метрик Elasticsearch поддерживается большинством инструментов системного мониторинга, таких как Datadog, TICK. Рекомендуется использовать такие инструменты, а создание воронки настоятельно рекомендуется для постоянного мониторинга Elasticsearch.

Вывод:

Elasticsearch - это распределенный механизм полнотекстового поиска и анализа, который позволяет нескольким арендаторам осуществлять поиск по всем своим наборам данных, независимо от их размера, с беспрецедентной скоростью. В дополнение к своим полнотекстовым возможностям поиска ElasticSearch используется в качестве аналитической системы и распределенной базы данных. ElasticSearch имеет большие значения по умолчанию, чтобы начать. Но, пройдя начальную стадию эксперимента, вы должны потратить некоторое время на настройку параметров под свои нужды. Рекомендуется вернуться к конфигурации позже, вместе с официальной документацией, чтобы убедиться, что ваш кластер настроен в соответствии с вашими потребностями.