Важная настройка 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 записывают данные и журналы в расположения вне $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"

Elasticsearch предлагает устаревший параметр, который позволяет указать несколько путей в path.data. Чтобы узнать об этом параметре и о том, как от него отказаться, см. Несколько путей к данным.

Узел может присоединиться к кластеру только тогда, когда он разделяет 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 на сохранение дампов кучи при исключениях Out Of Memory в стандартный каталог данных. В пакетах RPM и Debian этот каталог равен /var/lib/elasticsearch. В дистрибутивах Linux и MacOS, а также Windows этот каталог расположен в корневой директории Elasticsearch.

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

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

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

Чтобы ознакомиться с дополнительными параметрами, не содержащимися в оригинальном JEP, смотрите Включить логирование с помощью унифицированной системы логирования JVM.

Измените расположение вывода логов 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,level,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.

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