Важная настройка Elasticsearch

Для начала работы с Elasticsearch требуется очень небольшая настройка, но перед использованием кластера в рабочей среде необходимо учесть ряд моментов:

Наш сервис Elastic Cloud автоматически настраивает эти параметры, делая ваш кластер готовым к использованию по умолчанию.

Elasticsearch записывает индексированные данные в индексы и потоки данных в директорию data. Приложения Elasticsearch записывают собственные журналы приложений, содержащие информацию о состоянии и операциях кластера, в директорию logs.

Для установок на macOS .tar.gz, Linux .tar.gz и Windows .zip по умолчанию data и logs являются поддиректориями $ES_HOME. Однако файлы в $ES_HOME рискуют быть удалены во время обновления.

В рабочей среде настоятельно рекомендуется установить path.data и path.logs в elasticsearch.yml вне $ES_HOME. Установки Elasticsearch с помощью Docker, Debian, RPM и macOS Homebrew по умолчанию записывают данные и журналы в места, находящиеся за пределами $ES_HOME.

Поддерживаемые значения path.data и path.logs различаются в зависимости от платформы:

path:
  data: /var/data/elasticsearch
  logs: /var/log/elasticsearch

path:
  data: "C:\\Elastic\\Elasticsearch\\data"
  logs: "C:\\Elastic\\Elasticsearch\\logs"

При необходимости вы можете указать несколько путей в path.data. Elasticsearch хранит данные узла по всем предоставленным путям, но данные каждого фрагмента сохраняются в одном пути.

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

path:
  data:
    - /mnt/elasticsearch_1
    - /mnt/elasticsearch_2
    - /mnt/elasticsearch_3

path:
  data:
    - "C:\\Elastic\\Elasticsearch_1"
    - "E:\\Elastic\\Elasticsearch_1"
    - "F:\\Elastic\\Elasticsearch_3"

Поддержка нескольких путей к данным устарела в версии 7.13 и будет удалена в будущих выпусках.

В качестве альтернативы нескольким путям к данным, можно создать файловую систему, охватывающую несколько дисков с помощью аппаратного виртуализационного слоя, такого как RAID, или программного виртуализационного слоя, например, Logical Volume Manager (LVM) на Linux или Storage Spaces на Windows. Если вы хотите использовать несколько путей к данным на одном компьютере, необходимо запустить по одному узлу на каждый путь к данным.

Если вы в настоящее время используете несколько путей к данным в кластере высокой доступности, то вы можете перейти на конфигурацию с одним путем для каждого узла без простоев, используя процесс, аналогичный поэтапному перезапуску: поочерёдно выключайте каждый узел и заменяйте его одним или несколькими узлами, каждый из которых настроен на использование одного пути к данным. Более подробно, для каждого узла, который в настоящее время имеет несколько путей к данным, выполните следующие действия.

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

Если вы в настоящее время используете несколько путей к данным, но ваш кластер не является высокодоступным, то вы можете перейти на не устаревшую конфигурацию, сделав снимок, создав новый кластер с желаемой конфигурацией и восстановив снимок в нём.

Узел может присоединиться к кластеру только в том случае, если он разделяет своё cluster.name со всеми другими узлами в кластере. По умолчанию имя равно elasticsearch, но вы должны изменить его на подходящее имя, которое описывает назначение кластера.

cluster.name: logging-prod

Elasticsearch использует node.name в качестве удобочитаемого идентификатора конкретной инстанции Elasticsearch. Это имя включается в ответ многих API. Имя узла по умолчанию соответствует имени хоста машины при запуске Elasticsearch, но может быть явно сконфигурировано в elasticsearch.yml:

node.name: prod-data-2

По умолчанию Elasticsearch связывается только с обратными адресами, такими как 127.0.0.1 и [::1]. Это достаточно для запуска кластера из одного или нескольких узлов на одном сервере для разработки и тестирования, но для устойчивого кластера производства необходимо, чтобы узлы находились на других серверах. Существует множество настроек сети, но обычно вам нужно настроить только network.host:

network.host: 192.168.1.10

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

Без каких-либо сетевых настроек Elasticsearch будет связываться с доступными обратными адресами и сканировать локальные порты 9300 до 9305 для подключения к другим узлам, работающим на одном сервере. Это поведение обеспечивает автоматическое создание кластера без необходимости какой-либо конфигурации.

Если вы хотите создать кластер с узлами на других хостах, используйте настройку статического discovery.seed_hosts. Эта настройка предоставляет список других узлов в кластере, которые могут быть мастер-узлами и, вероятно, будут доступны и могут быть связаны для запуска процесса обнаружения. Эта настройка принимает YAML-последовательность или массив адресов всех узлов, имеющих право быть мастер-узлами в кластере. Каждый адрес может быть либо IP-адресом, либо именем хоста, который разрешается в один или несколько IP-адресов через DNS.

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11 
   - seeds.mydomain.com 
   - [0:0:0:0:0:ffff:c0a8:10c]:9301 

Если ваши мастер-узлы не имеют фиксированных имен или адресов, используйте альтернативный поставщик хостов, чтобы динамически находить их адреса.

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

Поскольку автоматический запуск кластера в сущности небезопасен, при запуске нового кластера в режиме производства вы должны явно указать мастер-узлы, чьи голоса должны учитываться в первой же выборке. Вы задаёте этот список, используя настройку cluster.initial_master_nodes.

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11
   - seeds.mydomain.com
   - [0:0:0:0:0:ffff:c0a8:10c]:9301
cluster.initial_master_nodes: 
   - master-node-a
   - master-node-b
   - master-node-c

См. запуск кластера и настройки обнаружения и формирования кластера.

По умолчанию Elasticsearch автоматически устанавливает размер кучи JVM на основе ролей узла и общего объёма памяти. Для большинства производственных сред рекомендуется размер по умолчанию.

При необходимости вы можете переопределить размер по умолчанию, вручную установив размер кучи JVM.

По умолчанию Elasticsearch настраивает JVM на создание дампов кучи при исключениях из-за нехватки памяти в стандартном каталоге данных. В пакетах RPM и Debian стандартный каталог данных — /var/lib/elasticsearch. В дистрибутивах Linux и MacOS и Windows каталог data расположен под корнем установки Elasticsearch.

Если этот путь не подходит для получения дампов кучи, измените запись -XX:HeapDumpPath=... в jvm.options:

По умолчанию Elasticsearch включает журналы сбора мусора (GC). Они настраиваются в jvm.options и выводятся в тот же стандартный каталог, что и журналы Elasticsearch. По умолчанию журналы вращаются каждые 64 МБ и могут занимать до 2 ГБ места на диске.

Вы можете переконфигурировать ведение журнала JVM, используя параметры командной строки, описанные в JEP 158: Объединённый журнал JVM. Если вы не измените файл jvm.options напрямую, конфигурация Elasticsearch по умолчанию применяется дополнительно к вашим настройкам. Чтобы отключить конфигурацию по умолчанию, сначала отключите ведение журнала, указав параметр -Xlog:disable, а затем укажите свои собственные параметры командной строки. Это отключает все ведение журнала JVM, поэтому обязательно изучите доступные параметры и включите всё необходимое.

Чтобы узнать о дополнительных параметрах, не указанных в исходном JEP, см. Enable Logging with the JVM Unified Logging Framework.

Измените расположение вывода журнала GC по умолчанию на /opt/my-app/gc.log, создав $ES_HOME/config/jvm.options.d/gc.options с некоторыми образцами параметров:

# Turn off all previous logging configuratons
-Xlog:disable

# Default settings from JEP 158, but with `utctime` instead of `uptime` to match the next line
-Xlog:all=warning:stderr:utctime,level,tags

# Enable GC logging to a custom location with a variety of options
-Xlog:gc*,gc+age=trace,safepoint:file=/opt/my-app/gc.log:utctime,pid,tags:filecount=32,filesize=64m

Настройте Elasticsearch контейнер Docker для отправки отладочных журналов GC в стандартный вывод (stderr). Это позволяет контейнеру-оркестратору обрабатывать вывод. Если используется переменная среды ES_JAVA_OPTS, укажите:

MY_OPTS="-Xlog:disable -Xlog:all=warning:stderr:utctime,level,tags -Xlog:gc=debug:stderr:utctime"
docker run -e ES_JAVA_OPTS="$MY_OPTS" # etc

По умолчанию Elasticsearch использует частный временный каталог, который сценарий запуска создаёт непосредственно под временным каталогом системы.

В некоторых дистрибутивах Linux система может очистить файлы и каталоги из /tmp, если они не были недавно обработаны. Это поведение может привести к удалению частного временного каталога во время работы Elasticsearch, если функции, которые требуют этого каталога, не используются длительное время. Удаление частного временного каталога приводит к проблемам, если впоследствии используется функция, которая требует этого каталога.

Если вы установили Elasticsearch с помощью пакетов .deb или .rpm и запустили его под systemd, частный временный каталог, используемый Elasticsearch, исключается из периодической очистки.

Если вы планируете использовать дистрибутив .tar.gz на Linux или MacOS в течение длительного времени, рассмотрите возможность создания отдельного временного каталога для Elasticsearch, который не находится в пути, где будут удаляться старые файлы и каталоги. Этот каталог должен иметь разрешения, позволяющие доступ только пользователю, под которым работает Elasticsearch. Затем установите переменную среды $ES_TMPDIR, чтобы она указывала на этот каталог, перед запуском Elasticsearch.

По умолчанию Elasticsearch настраивает JVM на запись журналов критических ошибок в каталог журнала по умолчанию. В пакетах RPM и Debian этот каталог находится в /var/log/elasticsearch. В дистрибутивах Linux и MacOS и Windows этот каталог находится в корневой папке установки Elasticsearch.

Это журналы, создаваемые JVM при возникновении критической ошибки, например, сегментации памяти. Если этот путь не подходит для приема журналов, измените запись -XX:ErrorFile=... в jvm.options.

В случае аварии снимки могут предотвратить потерю данных. Управление жизненным циклом снимков — это самый простой способ регулярного резервного копирования вашего кластера. Дополнительную информацию см. в Создание снимка.